From patterns to rules: The McGuffin Pattern

I wrote earlier about what I called the McGuffin Pattern.

The basic idea was that if you drive your quest with a McGuffin, like a unique stateless item, the player will be able to figure out the solution to the quest at it's onset. The player doesn't, as a concequence, have to solve a problem; he simply has to provide a specific, choiceless solution. Now, this can work if you want to imply that the player must do a very specific job within very specific parameters. But the player won't own the solution, he will be following orders. If you want the player to commit, you must make him own his choices, and therefore his solutions. At the very least, it must be this way in the general case. The McGuffin pattern hinders that.

Within gaming, the McGuffin pattern is without a question an anti-pattern, so it should not be followed. It should be known, because it should be avoided. And what's more, it doesn't simply concern McGuffins - it can be characters or fairly abstract concepts too, that provide the player with the solution at the onset, and on the other hand, McGuffins can be constructed to avoid the McGuffin pattern. Yes, that makes it sound like I just coined a misnomer, and I kinda sorta did, but I didn't because the pattern emerges through the brainless use of McGuffins 99% of the time. The generalization simply says: If you abstracted the McGuffin out of the equation somehow, while keeping the solution within the definition of the quest, you didn't solve anything at all, dummy.

Now, as a quick interlude: I like rules. Rules partition everything into right and wrong, that which follows rules and that which doesn't. Any good pattern can be made precise and easily applicable through the use of rules. So, what rule can be taken away from this?

Baseline rule of it is: Do not present the player with unfulfilled solutions. Present him with problems.

The fine print should add: And perhaps hints, but never reveal to him the number of possible solutions to the quest at the onset. He needs to figure out the solution. If you want to optimize the players experience so open quests don't confuse him, be certain to inform the player of his progression through 2nd person narrative; but even then, only log what he has done and discovered in a clean cut, unambiguous fashion. And here's the cigar: try to always make hints ambiguous in their certainty: Make them suggestions rather than plans.

The McGuffin can almost always be avoided, if desired. Say the quest is to look for the holy grail. Firstly, try to make the grail an ambiguous item. Now generally, there can be no more than one holy grail, but that's because the holy grail doesn't have a purpose. Suppose it did have a purpose; suppose it gave eternal life if you drink from it. Then, what the player ostensibly needs is to be searching for is something that gives eternal life.

At times, you cannot make the item itself ambiguous though; perhaps it's a holy grail without a purpose, perhaps it's a smoking gun. But the maxim holds: if the item is unambiguous, it's location, or it's validity, must be ambiguous at the onset. The player must make a choice on how to make the solution less ambiguous. Perhaps it turns out that there is no imposter, that the location is obvious, or that the task can really only be completed in one way. But narrowing this down should be a process, and not revealed through the initiating dialogue. Hitman is perhaps the most excellent example; there's typically a myriad of puzzles built into each level, and many have multiple solutions. But there is only 1 goal. The player owns the hit, however, because he owns the process; he was presented with a problem, rather than a solution.

To reiterate the first rule of non-linear narratives :
- Do not present the player with unfulfilled solutions. Present him with problems.