Showing posts with label quests. Show all posts
Showing posts with label quests. Show all posts

Monday, 10 January 2011

The Quest for Quests: Part Nine (Interlude)

You may want to start this series with part one, two, three, four, five, six, seven or eight.

I'm going to take another brief pause in this somewhat interrupted article series to point out a dark tower on the horizon, wreathed in storm clouds, through which wretched things take wing. That is our ultimate destination: the tower of the end game. Before it, we must pass through two great lands: the first, a pile of haphazardly placed blocks of rock and earth, through which water and lava and sand spill, fall and lap; the second, the rolling hills and forests and villages filled with warring medieval kingdoms. You know these places as Dwarf Fortress (or perhaps Minecraft), and Mount & Blade, and both have 'solved' many of the problems of quests that I have highlighted so far.

(The perceptive of you may notice the glint of recent flash of steel, from a hardy duo trapped somewhere in the wilderness before you).

Within a few minutes of playing Mount & Blade, I could feel the tingle in my fingertips of a game that does everything right that I've been writing towards with this series. Trading system instead of fetch quests. Check. Constantly changing world governed by an underlying set of rules that changes the environment while you play. Check. A faction system instead of quest givers. Check. Metagame (conquer the kingdom) which sits above the primary game (Pirates! plus first person sword fighting). Emergent complexity, whatever that means. Check.

So should I lay down my quill and let this quest rest?

Luckily not, because as one apt Rock Paper Shotgun so evocatively writes:

Regardless you do need some fixed content, otherwise everything ends up like the repetitive and dull wandering of Mount and Blade’s mid game.
That is because Minecraft, and Dwarf Fortress and Mount & Blade are all missing that one essential landmark of any great game: that dark tower of the endgame which you can see in the distance. I use the tower as a metaphor, but one of the greatest games, Half-Life 2, makes it literal, a beacon that you can see from almost anywhere inside and out City 17. Your endgame must cut through the moment like a dark stained blade, poisoning every decision the player makes with the final flaw 'what are the consequences'?

For many games, the path to the endgame is easy: Angband has stairs which lead only up to retreat, or down to advance, Mario is always moving to the right. The fight before the finish must be the crescendo. Games with fixed quest content end almost fitfully, because you have consumed all that they can deliver. Dwarf Fortress at least has that dull blade of finality 'Your dwarves have dug too deep.' that mercifully finishes off a fortress that groans with the fat of success, as opposed to the glorious bright eyed failures fallen before it.

The end game ironically is for the most part a given. The pieces you have moved into place, the choices and sacrifices that have built up to it usually come down to a single decision point or few and the best designed puzzle games leave resolution of success or failure to the last possible moment with all sides (in a multiplayer game) in contention as long as possible. Where the end game shines is not in the stalemate avoiding final dance, but in how its shadow is cast on mid game.

The mid game is where you are forced to implement your plans of how to win. In game where you are not faced by the infinite lego set of Minecraft, not everything is possible. There are time constraints, resource constraints, skill constraints, mutually exclusive decisions which force you to take a but not b, a battery of tests which wear down what resources you have available, wastage where your toil amounts to nothing, a slippery slope towards inevitability, set backs outside of your control, gateways through which you can pass one way only, entropy, a rising tide that pulls you in one direction, checkpoints which require minimum standards of you, irreversible decisions, stalemates, fatigue, failure states which trap you into restarting, or worse: mulligans, treadmills, grinds, false economies, exploits which encourage bad behaviour, fool's gold, mudflation, Garfield cards, bad designer prisons and gear reversals.

(To avoid linking to TV tropes and losing you, I'm forced to invent my own private lingo to lose you instead. A Garfield card is something that has the same cost as a clearly more useful item - therefore essentially useless. Reference is Magic: the Gathering's designer Richard Garfield who uses this technique. While I have disparaged it previously, I suspect, like many hill climbing algorithms, sometimes you need to move through low value points represented by Garfield cards to get to higher peaks. A bad designer prison is a part of the game where the rules are suddenly and artificially limited. Think of bosses who are immune to abilities you have used previously, for no good reason. A gear reversal is that point in the game where you are stripped of all equipment.)

Without an endgame, most of these are meaningless. To take one example: Chess defines a stalemate as a series of repeated moves and clearly enforces them. A series of repeated moves in Minecraft could be you admiring the same view each morning. You can 'do-over' a building by cutting down another mountain one valley along, but in chess, your mulligans are misconduct.

To be clear: I'm valuing what you might consider a certain kind of game, a certain kind of way of playing games, and a certain kind of player (more than 800,000 of them at last count) will never take issue with Minecraft's unlimited sandbox world. But games without endgames are much more limiting in terms of the types of play they support, and much more limiting in the types of players they satisfy, for all that they promise no limits.

To see why, consider a variant of Minecraft, which has an endgame: to build the highest tower of any player anywhere in the world, and new building block type governed by more sophisticated physics system which requires the player master it to build high above the clouds. Moreover, the ingredients required to build this tower are collected and limited by interaction with a linear narrative, but where you can get enough resources for sandbox play 'readily' if not right at the start (A certain part of the narrative may consist of tutorials to highlight techniques and physics interactions you may not have considered). We'll call this variant World of Goo.

World of Goo lets you participate in sandbox play as much as you desire, as well as more narrative driven play that Minecraft lacks, and which some people express a preference for which never could be fulfilled by Minecraft. In addition, a third type of player plays competitively, min-maxing their way through the narrative and resource acquisition phases to acquire as much of this tower building resource as possible. Another type of competitive player comes up with unique tower building techniques which require less pieces, or excels in specialist league maps, which try to build the towers with the most unique properties using a fixed number of resources.

There is one key decision that this hypothetical World of Goo makes that loses some potential players who are well-served by Minecraft: it limits the total amount of goo available. But the players it loses are only noncompetitive tower builders, who want to build towers over a certain height 'easily'. You could address this by making an unlimited tower building resource available that is distinct for goo, for which players can buy, or grind over time: call this resource hats. I'm not sure if the tower of hats model is the right approach, but it clearly is a popular direction to take.

All other builder types are well catered for by the sandbox that thought experiment World of Goo makes available, because only goo for towers is limited. And competitive tower builders are under served by Minecraft. In particular, Minecraft doesn't cater at all for (for want of a better term) Chinese mother tower builders - to paraphrase the linked article, tower builders whose limits can only be reached by rising to the rigors of strict competitive environments.

My argument is that Chinese mother tower builders are the reason your games need goo and endgame, not just bl0cks and sandboxes. The designers of many games could not possible anticipate the depth to which some games could be played whether they be Chess or Starcraft, and an endless sandbox cannot alone offer compelling enough a reason for a competitive community to emerge to explore these depths. There is one caveat: if the game has a big enough an audience, all things are possible. Team Fortress 2 has surf maps, Star Craft has maps with unlimited resources and Defence of the Ancients, Civilisation IV a menagerie of mods. But all of these examples have a strong end game component, and clearly defined goals, even if they have mutated beyond the intent of the original designers.

(Magnasanti being the artistic vision of one man shredding a game with concrete depth charges).

Tuesday, 30 November 2010

The Quest for Quests: Part Eight (Enumeration 2)

You may want to start this series with part one, two, three, four, five, six or seven.

I would argue the primary function of failure in games is pedagogical: failure is used to demonstrate in a learning situation that you are approaching a problem in the wrong way - or simply lack sufficient ability in the skills required for play. This means we can draw from the large body of work when discussing failure in games.

In the pedagogical sense, there is no failure state while playing a game, except one where the player is unable to or discouraged from learning further - that is, switching the game off. The loss of a life, or permadeath in roguelikes, is merely a behavioural stick to go with the carrots of shiny lights and loud noises. Interestingly, research seems to indicate that dying in a first person shooter actually causes you to relax, which points to a model of tension while learning, relief when freed from the requirement to learn, that fits this learning-based argument. I find it helpful to break down pedagogical failures into two distinct types: failure to learn, where the player is unable to acquire the skills necessary to progress in the game; and failure to engage, where the player stops playing because they have no incentive to play further.

Note that failure to engage doesn't always simply result in switching the game off. Another possibility is that the player stops playing the game that the designer intended: by artificially limiting themselves by deciding that the some of the rules fall outside 'acceptable' or 'believable' behaviour. One example I am particular fond of resulted in the player feedback "I feel like I'm cheating". This is sufficiently different from vanilla failure to engage, because it can result from the player buying into the fiction of the game too much, but usually this results in elevated difficulty, rather than a failure in the strictest sense.

Cheating itself is an example of failure to engage. Cheat codes and 3rd party tools break down the magic circle of the game as designed, but still allow play - just not on the level playing field of the original design. In fact, both cheating and artificial honesty are sufficiently different from failure to engage in the game at all, that they are better termed 'failure to play by the rules' - whether those rules are underexploited, or ignored. If you think these two approaches should be separated out, consider the difficulty that experienced poker players have in playing with a complete neophyte: much of high level poker play is predicated on a mix of bluffing and rational behaviour that a player unfamiliar with the game will be unable to adopt and therefore can be as disruptive to play as someone cheating outright.

But there are clearly issues with failure that move beyond the framework of simply training and engaging the player. I've already discussed failure to win - where we agree within the magic circle of the game that one player has won, but another has lost, accompanied for the losers by some sense of psychological defeat and (in competitive games) lack of financial remuneration; and the failure of choice - where a game system is understood to the point where there are no non-trivial choices to be made.

There is the necessary condition of identifying as soon as possible that the game has entered an unwinnable state. The player may have lost items which are pre-requisites for puzzles later in the game, or lack sufficient resources in order to survive confrontation with the remaining enemies that they encounter. This is again a magic circle based argument, because the actual player experience may still be an enjoyable, learning-based experience, and the blame for the game continuing in this state doesn't fall squarely on the player - it is as much the responsibility of the designer to detect when a game should have ended. I'll label this type failure to finish.

Reloading a game from an earlier save is a type of failure: failure to honor outcomes, that is distinct enough from failure to play by the rules that it warrants its own category. A reload still plays within the game rules, but effectively the player is exploring all possible outcomes of those rules in order to get the preferable choice. The reload can on one level be seen as a cheat tool but a game supported one, in the same way that trying all your letters in a space in iPhone Scrabble to see what is accepted as a valid word is a way of cheating that is completely supported by the software. But it is also a way of constructing a preferred narrative, or merely an alternate one, that itself be construed as valid play - the roguelike Save Scummer takes this to a logical extreme.

Within the magic circle of the game, it is possible to see a thousand incremental failures - death through a thousand paper cuts of lost strategic units. The failure to honour outcomes is as much a way of playing the metagame of choosing which loses to accept within the game. The reaction of many players to a game like Fire Emblem shows that players strongly resist the idea of losing assets that they identify with. This suggests you should design the game so that assets are clearly disposable - by procedurally generating them, for instance. X-Com seems to strike the right balance: the soldiers are clearly expendable, but by naming them, it is possible for the player to begin to begin to identify with them should they survive for any length of time.

There is, through ambiguity, design failure or deliberate intent, the opportunity to create a 'failure to be consistent', which can occur both within the game rules - most commonly board games, and actual play. The masocore genre prizes this as a success rather than failure, and some game designers include deliberate rules ambiguity to make agreeing to the rules of play a fundamental part of the game itself. Likewise, the player can be their own arbitrary god: fair one minute, fickle the next.

Finally there is a failure best termed 'failure to have a sequel'. Games engage the player in a way that constructs not just a narrative within the game, but a whole metanarrative of conjecture, supposition, fan fiction, back stories, promotional material, web sites and wikis, both canon and non-canonical. Players are embedded in this larger narrative, choosing to accept or reject this additional material, but also construct it by the choices they make as they play the game. If a game is not financial successful enough to have a sequel, or the intellectual property becomes mired in complex legal entanglement, or even the direction chosen for the technical sequel does not match the player expectations, then this type of failure occurs. Games are unique though in the way that the player choices must also be honoured or ignored in the sequel: a few (Deus Ex: Invisible War, and Morrowind) are sophisticated enough to posit that all possible outcomes a player was capable of making, in fact occurred.

We move to another brief interlude in part nine, before pressing on towards our goal.

Wednesday, 17 March 2010

The Quest for Quests: Part Seven (Enumeration 1)

You may want to start this series with part one, two, three, four, five or six.

What do we mean by failure in games? Let's start with a simple enumeration of the ways we can experience failure in a game.

The first is losing: a subset of all games - mostly those which are multi-player - are competitive and it is possible to win or lose such games (The rankings may be more sophisticated than the binary state, but assume for the moment that anything except coming first is a loss). Whether a player loses is defined by the rules of the game: this initially appears an important characteristic because most failures I'll be talking about are meta-game; that is fall outside of what would normally be considered part of the game.

But this lack of meta-game component is an incorrect assumption, because the game rules say nothing about the attributes of the players. Take a simple game, like rock, paper, scissors, where the rules are entirely proscribed and easily understood. In a single game of rock, paper, scissors against an opponent you have no other information about there is nothing outside game to influence your decision. But as soon as you play more than one game of rock, paper, scissors against the same opponent you have meta-game information: namely the history of your opponents decisions. It is entirely possible to gain significant advantage through analysis of these decisions - as well as any other information about the opponent - and there are a number of AI programming competitions for similar simple games which take advantage of this fact. In this instance, losing a single game can not be considered a failure, because the information derived from a loss can be used to improve the chance of successive wins.

Paradoxically, it is also possible to play two losing games alternately, and still end up winning overall (See this wikipedia article on Parrondo's paradox). So our intuition that losing in a game is equivalent to failure is incorrect for even simple games against another player.

Is it possible to lose against a computer opponent in the same sense that you can lose against another person? This is an important question, because if this is the case, it means we can lose in a single player game - the significance of which we'll look at later.

I'm going to use a simplified version of rock, paper, scissors to analyze this question: call it paper/shotgun. In this variant, we have two players, each of whom get to choose either paper or shotgun. If both make the same decision, player 1 wins - if the decision differs, player 2 wins. We'll encode paper as 0, and shotgun as 1, and then each player's decisions on successive games will resemble a binary string e.g. 001000111110...

Now if this binary string is perfectly random, there is no information that can be derived from the string - it's just noise. However, if the string is less than random - that is, there is information that can be derived because the string is compressible and an underlying set of rules is used to generate the string - then it is possible for one of the player's to derive the underlying system generating the other player's decisions and then start to win successive games. If player 1 is a set of rules, and player 2 is a perfect AI, then once the rules have been derived, player 2 will win consistently when it is possible to do so. If player 2 is less than a perfect AI - such as an actual human being, he may not be able to derive the rules perfectly, in which case successive plays can be used to refine the ruleset and improve the winning ratio.

Not there may still be random inputs to player 1's strategy, which prevent player 2 winning perfectly. But once player 2 has derived the underlying system of rules to player 1's choices, or has done so to the best of their capability, the game degenerates into application of the counter to the ruleset derived: it becomes a mechanical process.

This is the second failure in games: where player understanding of the game degenerates to a rote process which requires no analysis. Take tic, tac, toe. The entire game tree (the combination of all possible decisions) has been mapped and so any rational approach to playing the game is will result in a draw.

But people are not rational, which is why a game like tic, tac, toe still exists and is considered a game. You may choose to play it to explore the game tree and confirm that a draw is the logical outcome. You may choose to play against an opponent who is not aware of the correct decisions at each juncture of the tree, to prove your superior rationality, or to lose deliberately as a sop for their ego. On one level, people enjoy rote, mechanical processes because our brains are wired to enjoy a mix of novelty and mundane, as opposed to complete novelty the entire time - some pleasure in rote processes have enabled our ancestors to survive and evolve. The presence of grinding in so many games is testament to this.

Denigrating degenerate games and grinding is as much about game design snobbery as it is about the game itself. I dislike rule sets that result in degenerate game play, but I have to acknowledge that these games exist and are successful, and are an important part of many more sophisticated games. Organising your cards in Solium Infernum, clicklets in Bunni Game: How we First Met and kiting in Torchlit are all examples of mechanical processes which contribute to the feel of the game.

In the discussion so far, I have assumed that the player is capable of improving their ability to play the game as they play successive games or progress through successive decisions in a single game. That is not necessarily the case: and the third example of failure is failure to learn.

Failure to learn is about treating the game as a pedagogical instrument - a teaching device. In parts eight and nine, I'll be talking about how games teach, and more types of failure in games, and what other game designers and the wider world have been saying about failure.

Sunday, 24 January 2010

Why are games difficult?

You may want to start this series with part one, two, three, four or five.

Demon's Souls was lauded as one of the best and most challenging games of 2009, for the difficulty of both the game play and the placement the apostrophe in the title. It is this difficulty that was seen as a breath of fresh air by many jaded critics and game players, who had supposedly grown fat and weak on the Facebook Farmvilles and amusement park ride MMOs, with their watered down game mechanics designed to hook in and succor what Gevlon refers to as morons and socials.

Demon's Souls was criticised as one of the most harsh and unforgiving games of 2009, for the difficulty of both the game play and the placement of the apostrophe in the title. It is this unnecessarily hostile environment that continued the tradition of poor design catering only to hard core critics and game players, who have the obsessive compulsive disorders necessary and basement bedrooms at their parents' place necessary for the multi-hundred hour play times required by treadmill MMOs, with their grindtastic game mechanics designed to hook in and succor those Tobold parodies in the Rise of the Leet King.

Difficulty in game design is something I hold dear to my heart - mostly because I have written a game which is too difficult for me, or many others to ever contemplate completing. Witness the crushed and torn bodies of the many Shadow Fairies that litter the latest Angband competition ladder and the self-evident pride of the masochists posting that they've made level 5 (out of 50 - and level 50 is much, much more challenging again). As Konijn puts it:

Anyway, I think at this point, I give up. You cannot win with this character, there's instakill from a number of sources even while playing very carefully. I number my savegame tries, this is number 22, so you cant say I didnt try ;)
and then keeps playing...

The current shining exemplar of the roguelike genre, Dwarf Fortress, has a motto 'failing is fun', but roguelikes have always been notoriously difficult...

Let's start at the beginning. Tobold poses the question succinctly in a follow up post to the Leet King letter:
When you say World of Warcraft is too easy, how exactly should a good, hard game differ from that?
(An aside: the only literary technique more misplaced than writing a humorous opening to a serious question on the Internet - the mistake Tobold admits to - is posing a rhetorical question. It works in the context of the original post, but as soon as you're quoted elsewhere, people just assume you're stupid and answer the question, rather than following the link and finding out you've already got some answers. So only an idiot someone trying to be difficult would title an article with a rhetorical question. So if you're going to link to this, please call it 'The Seventeen Ways Games can be Difficult' - or something like that).

He misses a trick: the question shouldn't be how can we make games harder? It should be why are games difficult at all? And it's this, more fundamental question, that I'll be attempting to answer here.

Why are games difficult? We have conquered the world as a species, we are better off than every previous generation, we are - you especially - inherently bad-ass. As Neal Stephenson points out, provided you accept evolution as a theory, you are currently expressing more badassedness than any creature that has ever lived and died ever, by definition. And yet we can be challenged and beaten by something as a simple as a game - some lines on a ground, and some differing coloured pebbles.

We can be beaten because of random factors. As soon as you introduce the possibility of randomness in a game, there exists the possibility of events outside of your direct control. Something as simple as a dice, or a spinner, or something less biased like entropic heat exchange, can be used to simulate externalities: the environment around you, other competitors - either because you don't have the players available to represent them directly, or to represent conflicts for which it would be inconvenient or dangerous to play out in reality - the want of a nail for the shoe of a horse. Reality is more outrageous and unbelievable than the most fantastical fiction, and randomness is a fair arbiter of unlikely consequences.

Even when you are able to directly resolve events without a random number generator, stochastic forces ensure that the outcome is not pre-determined. In fact, many games require that. You may immediately think of games of chance, gambling, horse racing, boxing, but the continuum of indeterminacy extends to all sporting events. If the outcome of any sprint is that Usain Bolt is the winner, then no one will sprint against him - unless there is sufficient incentive to change the race to be 'by how much is Usain Bolt the winner' or 'by what amount will the world record held by Usain Bolt be reduced by this week'. Even pursuits as sedentary as chess can be influenced by illness, distraction, the mindset and level of preparation of the competitors.

Other players are the next reason games can be difficult. Multi-player suddenly increases the variability of the challenge enormously, both in directly competitive games, and cooperative games (PvE). Should I choose the optimal strategy, which requires that my opponent or my partner is also playing to this optimal strategy? If there are suboptimal strategies with reduced risk of loss, which one of these is predictable, which one less so? The skill set required to directly read the mind of the opponent, or yomi, and the complexities and strategies of game theory can be expressed in games as simple as rock, paper, scissors, or as complex as the stock market.

Implicit with competition is the notion of different outcomes. Games can be difficult because we don't necessarily have a binary notion of risk vs. reward in all games. And even games which are differentiated by simple winning and losing, the consequences of the strategy employed can vary widely depending on whether we anticipate repeat play with the same opponent, or if we carry resources (star players, information about the opponent's preferred strategy or risk aversion, preponderance of particularly strategies in the environment of possible players) from one game to the next. Whether you should be a hawk or a dove depends on who you flock with, in the prisoner's dilemma, your choice matters more on whether you'll meet your potential betrayer as a cellmate.

Reward or risk over time is another important factor. Unlike the perfect world of game theory, we are finite beings with immediate wants and needs, and long term goals. Over a sufficiently long term, everyone is a loser - dead, as well. There is evidence to suggest a negative correlation between time spent (computer) gaming, and income - does the time you devote to winning this hundred hour RPG meaning you're losing out on the bigger game of life? Even in the game, if there is a strategy that earns you 50G per hour, why are you employing a tactic that only earns you 25G in the same time.

But that's unfair - I hear you say, complaining on the forums and asking Blizzard to reach for the nerf bat. What I want to do in the game should be just as rewarding as the actions those people who bothered to go out and do the research are doing? Strategy X is clearly cheating, because I can't or won't do it, or don't enjoy doing it. Welcome to the world, scrub. You're not playing the game if you're not playing to win. You're playing some weird made up in your own head game that no one else on the server is actually playing. Feel free to keep doing it, but get out of the way of the real players.

But sometimes you just don't have the abilities needed to play at the highest level. Or the twitch reflexes.
Or the Internet connection. Or the money. Or clean water and parasite free food and a source of income able to keep you above the poverty line with a diet rich in enough protein and other essential nutrients to avoid crippling chronic disease. It should be self-evident that life is unfair, from the moment of conception, and it is only the badass inheritance of your genes that keeps you floating atop the cesspool of the real world, fighting over the last scrap of food at the table.

And that's before you sit at the table. When you do, are you playing black or white? Do you move first or second? Are you Protoss against Zerg, or Terran against Terran? Did you spawn in the jungle, next to elephants, or in the hills next to copper? Does your starting planet have enough iron, Quinns? The rules of the game may start out asymmetrical, with a playing field tilted towards or against you.

There is one asymmetry that everyone starts out with when they first play a game - they don't know the rules of play. The process of learning a game can be simple or challenging, but it is clear that we can derive significant enjoyment simply from exploring the possible space set up by starting with simple rules and gradually introducing game play elements with greater complexity. Critically lauded puzzle games like Braid and World of Goo as well as block busters like Half Life 2 rely on this technique to propel narrative and game play forward, and games like Civilisation, Diablo and most MMORPGs dangle the carrot of newer and shinier toys to play with at almost every opportunity. The recent after adventure report of a Solium Infernum game starts out with games journalist Kieron Gillen tripping up on straight forward failing to read the fine manual, through staying awake at night writing angry letters in his head to the designer when an ambiguity in the rules interpretation puts him at a disadvantage, through to him rules lawyering with the best of them via email to try to bring down the front runner in the end game.

And even when you know what rules drive the game forward, and what ones to drive around, you may still not know what is happening in the game. Fog of war, hard to implement in board games, far easier in computer games, will shroud the map, letting you know a little of what is going on, but not enough. Incomplete information is an art lost these days to the single player game and almost entirely the province of multi-player, thanks to the rise of gamefaqs.com and game assistance tools in MMORPGs. Roguelikes are fighting a rear guard battle here, with randomly generated dungeons, permadeath and identify systems, but even some of the staunchest Angband players now advocate the elimination of identify, and full 'monster spoilers' available to all players. Which is a shame, because as poker and Demon's Souls, with its in game tip sharing, both demonstrate, incomplete information is a powerful and addictive game mechanic when done right.

Related to incomplete information, but important enough that it warrants separate discussion, is incorrect information - exemplified by the difficulty spike. Jeff Vogel argues strongly that you should never bushwhack your players; that is design a section of the game which they cannot complete at the point they reach it. I class this as incorrect information, because players will blithely waltz pasts the signs saying 'certain death here, do not enter!', the skulls, wet with fresh blood, the wall of helpful townsfolk blocking the entrance with prophecies of doom, with a notion in their head based on the difficulty of what the last challenge required, not what the next one will. The continued expenditure of millions on protecting us from the last terrorist threat, not the next one, shows us humans incapable of predicting terribly well, but very good at remembering what just happened. From a game theory point of view, we play using an optimisation strategy based on what we know, and when the strategy ends up depleting resources we had planned to keep for later, we find it difficult to continue.

Incorrect information is the most harmful when inappropriately in the user interface to the game. At some level, almost all computer games are about a user interface strategy. If we can design an AI to play the game perfectly, and simplify the UI to a single button press to start that AI, I would argue we still have a game, but the user interface to that game has been solved. At the other extreme, the complex button sequences and twitch reflexes of FPS or fighting games are a user interface hurdle that proves to be insurmountable for some potential players.

Moving beyond a discussion of simple user interface design, there are more subtle interface disparities between play at an intermediate level and advanced level, or between single player and multiplayer. I've argued elsewhere that Civilisation IV fails as a game on one level, because the elements of the game that it emphasizes in the user interface - a broad spread of technologies, boom or turtle strategies, building lots of interesting units - completely mismatch the strategies required at high level play - forest chopping, rushing strategies, the stack of death. If the optimal strategy is to have horse units built by turn 10, as you lower the difficulty level, you should be getting rushed by the AI with horse units at turn 11, then 12, and so on. Similarly, your single player game should usually be designed to make you better at multi-player, because the high level, interesting play typically only develops in multi-player some months after release. The newly introduced Dungeon Finder in World of Warcraft appears to be revolutionising the game, because it makes the tactics needed for the end game: the trinity of tank, healer, DPS - the easiest and most effective strategy for advancement at prior levels.

But what allows these differing levels of play in the first place? What makes for increasing levels of strategy, plays and counter plays? Even games with perfect information, minimised asymmetry and easily learned rules like Chess and Go, have almost unlimited scope for interesting play, because the rule set allows for a combinatorial explosion of possible game play spaces. These different from tic-tac-toe because there are too many possible combinations of moves for any one player to know the perfect strategy for any situation. Chess and Go differ from Starcraft and Streetfighter because the possible moves that have to been examined for exploits goes beyond the rock, paper, scissor choices of rush, turtle, boom or strike, block, throw.

Closely related to complexity is emergence, where behaviour that could not be predicted by the game designers, but can be discovered by the players appears in the game. This differs from complexity in the way that chess pieces don't change colour or float in the air when the board reaches a particular configuration, but it is possible to scale a building in Deus Ex or Half-Life using some well placed limpet mines. It is the provinces of speed runs and ROM programmers.

Whereas play is the province of mod designers and role players. We can always make a game more difficult, by choosing to make it more difficult, limiting ourselves artificially to a different set of standards, or changing the rules of the game and exploring the results. I'll be the nurse, you be the doctor this time - scrub as strength instead of weakness. Even for a seasoned play to winner like David Sirlin, play provides the opportunity for some well-needed research and development time. If I play as Blanka, can I find some bug or exploit against Guile, my favourite character, that an opponent in an upcoming tournament may try to use against me? What about if I blank on the day? Who should I choose instead if I don't make my crouch low punches reliably?

And finally, we can choose to extend play in the moment, for pleasure's sake. The day is dawning over Africa in Far Cry 2, so I'm going to walk to the next assassination, admiring the god rays filtering through the trees, the mist, the sniper lining up a bead on me... I know I should move on from Aeris, but I'm going to try to rescue her one last time. Yorda and I will sit here a moment, and watch the birds flock, even if it brings the darkness one step closer to taking her from me...

To summarise, games can be difficult because of:

1. Random number generators
2. Indeterminacy of outcomes due to unpredictable external forces
3. Other players
4. Complex risk vs. reward trade offs
5. Finite playing time
6. Self-limiting performance
7. Inequality
8. Asymmetry
9. Learning the rules
10. Incomplete information
11. Incorrect information
12. User interface
13. Disparity between beginning, mid and high level play
14. Complexity
15. Emergence
16. Play
17. Pleasure

So to ask how do we make a game harder, is to ask how we can vary these factors in an interesting way.

There's a whole lot here to take in, and I have skimmed over topic areas that warrant an article in themselves. This has been a diversion from the path we were taking, but an important one, and for part seven, I'll be getting back on track, and making a second attempt to talk about failure.

Friday, 22 January 2010

The Quest for Quests: Part Five (Failure)

You may want to start this series with part one, two, three or four.

Normally I write these article series in situ in the browser, using the java based text editing tool. But the article I was planning to write on failure felt like a more substantial topic, so I ended up creating an .rtf document in Text Edit and starting jotting down notes and thoughts about failure. It has been this document that has sat on my desktop for over two months, terrifyingly incomplete and unformed, since I finished part four of this series. A single word staring at me every time I started my computer.

Failure.

Think of the fifth part of this article series as an ellipsis, rather than an admission of defeat. Travel forward, a little wiser, a little tender, to part six, where I'll be talking about a topic closely related to failure, and a little dearer to my heart: difficulty.

(Fret not, I intend to return to this at a later date).

Saturday, 31 October 2009

The Quest for Quests - Part Four (Assumptions)

You may want to start this series with part one, two or three.

Quest content design is hard: which is why so many quests are either Bounties or Fed-Ex quests. In their simplest form, a Bounty is a 'go get me x of y', and a Fed-Ex is 'take a to b'. But even these simple forms raise many interesting questions and hidden assumptions - and are worth examining further.

Bounty Quests

Bounty quests traditionally involve killing n rats where n > 0, but can equally be seen as collecting n items, for similarly sized n. But rats are traditionally difficult foes in quest design, because they make the following assumptions:

i. n rats exist to be killed
ii. the rats to be killed move slower than the player and remain in accessible locations which are known to the player
iii. the player always has access to the appropriate rat-killing equipment
iv. rats in the boundaries of the agreed quest location are only killable by the player, never by anything else including natural causes, or are else recreated through spontaneous generation if they are killed by other means despite the absence of a procreative rat population due to the ongoing rat holocaust
v. by rats, the quest giver and player automatically agree that this includes or excludes rats of a particular age, gender or profession, completely distinguishable and agreed postmortem, and that the moment of gestation of a rat is definitively known
vi. the quest giver has the omniscience to know when the player has killed n rats, or the rat evidentiary material required by the quest giver only ever exists on a rat in a singular form and cannot be subdivided and is only produced due to the specific actions of the player, or there is a thriving black market in rat body parts to the exact value of the quest reward
vii. if rat evidentiary material is required, this material is perfectly preserved in perpetuity and contained within an immaculate boundary which extends beyond the player's body sufficiently to interact with this material in a defined way, or if it should decay or be lost, the rat population should replenish itself miraculously
viii. the killing of rat n, is more interesting and challenge an exercise to the player as rat n-1, which was as fulfilling as rat n-2, and so on

Assumption viii strongly suggests that there should be an increasing challenge as the player progresses through the quest. One approach may be to simply have the initial encounter be with 1 rat, the next with 2, then 3, and so on, which will guarantee that nth rat will be as interested, provide n is on the Fibonacci sequence, or the remainder included in the final encounter. Another approach may be to scale the difficulty of locating or fighting each rat higher than previously, which could be achieved by placing them randomly across a location of varying difficulty (the player will naturally migrate to the easier rats first).

As you can see, the amount of effort required to ensure that Bounty Quests cannot be failed can be considerable, and are often diametrically opposed to suspension of disbelief. If we simplify a Bounty Quest so that we just count the number of times we perform an action, instead of counting the successful outcomes of an action, we end up with a Do Something quest. The Do Something quest is an instruction to do an action so many times: such as chin up exercises in Metal Gear Solid 2, or the fight tutorials in Zelda: the Wind Waker. The Do Something quest is far easier to measure, but does not necessarily gauge skill, just determination.

If you are interested in measuring skill, you could get the same effect as a Bounty Quest but with easier to control the outcomes by using an Arena, where we place the player in a defined area, and measure their actions. Similarly, puzzles, skirmishes and mini-games can be used to measure player mastery of a set of skills without the complex boundary conditions that a Bounty Quest demands. The benefit of the Bounty Quest is that we allow the player to suspend the quest while having achieved partial completion, and potentially replenish the resources they require from elsewhere in the game world. I would argue that this benefit comes at considerable complexity and inflexibility.

Fed Ex Quests

Let's look at the set of assumptions required to perform the minimal Fed Ex quest for which the game designer has made it absolutely trivial for the player to complete:

1. The item is provided by the quest giver
2. The player can carry the item easily and safely without impact their existing abilities
3. The player cannot drop, lose, consume, sell or destroy the item in question
4. The item has no utility value to the player
5. The player cannot find the item elsewhere
6. The player can reach the requested destination
7. The destination is at a fixed point in space
8. The destination is known in advance
9. There is no time limit
10. The shortest path to the destination is clearly indicated at all times
11. The shortest path to the destination requires no expendable resources be consumed
12. When the player reaches the destination, they automatically complete the quest
13. There are no other quests which it would be useful to be closer to the destination than the start of this quest
14. The reward for completing the quest is greater than any other bonus that the player could acquire with the same time and effort elsewhere
15. The completing the quest does not change the accessibility of any other game content

Some of these assumptions are involve complex logic, such as 1, 3, 4, 5, 6 and 12, where the wrong design can result in the player not being able to complete the quest at all. For instance, if the game designer has chosen to make quest items act like other objects in the game, which results in them sharing common code (command interaction, menus, physics engines and so on), the presence and reach-ability of quest items must be guaranteed at all times.

Taking a simple example of being able to drop an quest item from the player inventory. In this instance, the player must:
a. Be able to pick the item up again
b. Not be able to drop the item in an inaccessible area
c. Not be able to prevent themselves from reaching the area they dropped the item again
d. Any other actor which picks up the item must not be able to make it inaccessible
e. Any other interaction in the game must not be able to destroy or move the item so it becomes inaccessible
f. If the location containing the item is freed from memory, it must first be saved to non-volitile in a form which it can be retrieved in subsequently
g. Data structures and code must be bug free so that the item cannot be duplicated or lost

And so on. Note that some of the above assumptions may not be achievable at all within a reasonable development time frame.

Given the complexities of assumptions which can result in a game state where a player cannot complete a quest, it is amazing the lack of effort spent on varying the assumptions for which the failure states are far simpler to control, or impossible to achieve at all. Consider assumption 2. What if there were multiple parts to quest item, of which the player could only carry some of at one time. There is the classic puzzle example of crossing a river with a fox, a hen and grain, of which only two fit in the boat at any one time, and where the the fox cannot be left with the hen on either bank, and the hen cannot be left with the grain. These sorts of simple logic problems can be woven into a quest fabric where failure states can be controlled in a much more straight forward way.

Another approach to assumption 2 would be to turn the quest into an optimisation problem. Consider an example where the whole quest item consumes multiple valuable inventory slots, but parts of the quest item can be carried in single slots. The choice is then: do I give up equipment already in these slots (which presumably gives me greater capability to reach the quest destination), or do I make multiple trips, and so take longer to complete the quest? In these types of optimisation problems, there is no failure state, only a clearly delineated series of trade offs that the player must make. Assumptions 13 and 14 similarly encourage the player to think in terms of optimal route selection.

Take care when designing these problems that the process of solving it is interesting for the player. Inventory optimisation is already an interesting decision in Angband, so the inventory slot example is appropriate for that game, but in a game where the player never reaches their inventory capacity, this mechanic would be a waste of effort .

Let's turn the notion of Fed-Ex quest on it's head for a moment. If we start by violating assumption 14, and then progressively replace unique quest items with commodities through out the other assumptions, one natural conclusion is that the counterpart to the Fed-Ex quest is a trading game, such as Elite. In this genre, fungible, easily replaced items can be purchased and sold in multiple locations, and the player focuses on the strategy of buying low and selling high. It is possible to simulate this trading game using multiple Fed Ex quests to send the player along the optimal path, but this makes the assumption there is an easily discoverable path - which may not be the case in a game which simulates market conditions by varying prices over time. You may argue that the code complexity for an interesting trading game is high, but it is no more complex than some of the challenges I highlighted in simply allowing the player to drop quest objects. The fact that Fed Ex quests are more prevalent than trading games is because most games featuring Fed Ex quests don't allow you the luxury of dropping quest items.

If no tangible item is involved in a Fed Ex quest - e.g. no item that has any impact on game play other than a UI representation, we ensure that the quest meets assumptions 1 to 5 by default, and greatly simplify the implementation of the quest code. These simpler quests usually have the option not to deliver the quest item, so that the item has nominal meaning: this is usually a narrative fig leaf covering the fact that the player is simply going to a particular destination for the quest, where not delivering the item is the equivalent of 'I don't want to advance the story yet'. In any event, whether a player is given the choice or delivering the item or not, the result of this simpler Fed Ex quest is the Go To quest, where the player is told to go to a location, and does so. Assumptions 6 -15 then fall into two categories: violating assumptions 6 - 14 are ways of keeping the journey phase of the Go To quest interesting, violating assumption 15 is a way of keeping the consequences of the Go To quest interesting. The Go To quest can be seen as the atomic counter-part to the Do Something quest I discussed above. All quests consist of these two actions (Go To and Do Something).

Keeping the journey interesting is a function of ensuring the moment to moment game play is interesting - important in a game even without quests - while keeping the consequences of completing a quest interesting is traditionally seen as a much a function of narrative as it is of game play. It is consequences I want to talk about in the next part of this series, of success, of choice and of failure.

Friday, 23 October 2009

The Quest for Quests - Part Three (The Map)

You may want to start this series with part one and part two.

The traditional approach to quests in games is hand written design, followed by scripted implementation. This is not to disparage hand-written design: the map for Shadow Complex is a beautiful, complex document, which was used to prototype the game in Adobe Illustrator and proved robust enough to virtually be identical in design to the final implementation. Scripting for quests is a natural approach, because the process of completing a quest appears procedural. First you do this, then you do this, then you do this. And scripting gives you the flexibility to have a wide variety of start and end conditions for a quest: because scripting languages allow you to set up complex logic to verify that these conditions have been met.

But it is these start and end conditions that make scripting problematic because every script requires that these pre and post conditions be correctly met. I've deliberately changed to calling these pre and post conditions, because the terminology is also used in programming to define the inputs and outputs of a function. And as should be clear from Unangband, the risk of taking a programmatic design to systems introduces the potential for bugs. This raises the bar for quest design, because every quest requires programmer-level understanding of game, which limits the total pool of people who can contribute quests to your game (or requires that you check every quest yourself). So the advantage of scripting quests: allowing complex pre and post quest logic, is the same as the disadvantage of quests. Scripting paradoxically limits your ability to use it to good effect.

That is not to say that a data driven design allows you to avoid pre and post conditions, but these are implemented once, in the programming section of the code, where exceptions can be rigorously handled in a single segment of code, as opposed to required for every script. You could equally argue that you can encapsulate the complex logic for pre and post conditions for scripts in functions to the same effect. But at that point, your scripts are not going to look dissimilar from data structures - just without the advantages that a data driven design gives you.

To see those advantages, I'm going to start with the strongest example of data driven quest design that I can find. Or, more correctly, I already have. That example is Shadow Complex, inspired by the Metroid series of the games, and the quest data structure used is the map.

In the Metroid series of games, the limits to your playing space are not scripted. They are instead limited by the current powers that you have - doors require rockets or ice beams to open, lava requires upgrades to your armour, small spaces require you can transform into the Morph ball in order to fit through them. This is a straight forward lock and key design, where the keys can be re-used. What is most important about this design: it is much more robust than a scripted approach. As can be seen in Metroid speed runs, it is possible to break the individual locks, without necessarily breaking your ability to continue playing the game. In a traditional scripted approach, if you somehow bypass a section of the map and do quests out of order, the designer must have explicitly considered this in the pre and post conditions of individual scripts. With the map-as-quest, you can do sections out of order without anyone having considered the ramifications of doing so. It is still possible to end up stuck if you skip multiple power ups, and end up falling into a section of the map which requires these power ups to traverse out of. But falling is the most general case of one-way movement which otherwise only rarely occurs in map design.

And the map as quest allows us to use a mature game design tool set where we are able to prove important attributes about the map, such as connectivity, in a way that we cannot necessarily prove with scripts. We can also take advantage of procedural generation to create sophisticated maps which are more complex in one sense than any script could be.

You may feel at this point I've performed a sophisticated three-card monte to prove data driven design superior to scripting. Every game has a map, and the important thing is the scripted triggers embedded in these maps, and not the maps themselves. In a sense you are correct because it is entirely dependent on whether you have made the map interesting to traverse. In other words, is it about the quest or about the questus interruptus?

Walking to Mordor

If your map degenerates to a series of nodes, interconnected by a graph of edges, then there is no point trying to represent the map as anything more sophisticated. Puzzle Quest is refreshingly honest in this approach, and it's how I've represented the Unangband wilderness. I don't necessarily think it's the most successful map design - it is another great example of data driven quest design though - but it is much more successful than games where you get a quest, then solely use the minimap in the top right corner of the screen to get there. In simple to traverse maps, the push component of the narrative that I talked about in part two is the most important, because there is nothing sophisticated required by the pull component of the narrative. Once you know where you have to go, there is no compelling puzzle stopping you getting there.

If on the other hand, the map is non-trivial to traverse, then pull narrative can become more important. In the idealized pull narrative, you already know the destination, and there is a compelling puzzle blocking you from reaching that destination. For Far Cry 2, this is the checkpoints between you and the destination, both those marked on the map and hidden, and the area around the destination, which you have been given the opportunity to explore previously. Metroid goes one step further, and just shows you compelling puzzles, with the implicit promise of a destination, or reveal, behind the puzzle. This has the effect of both a push and pull, but without the explicit quest narrative pushing you or a destination being shown pulling you.

We should really revisit our theory of how quests and narrative interact at this point. We've found at least two examples which fall outside the bounds of the push and pull based narrative structure velocity I described in part two. The first is a single, compelling push and pull at the start of the game, which is constantly interrupted as you move towards the destination (the Lord of the Rings model). The second is no push or pull at all, but puzzles in multiple directions without destinations (the Metroid model). Both appear to be about interruptions of some kind, one built from the top down, and the other from the bottom up, which allows me to segue to my own interruption until part four.

Tuesday, 20 October 2009

The Quest for Quests - Part Two (The Puzzle)

(You may want to start this series with part one.)

I apologise again for the authorial ellipsis of the previous part of this series. It was one of those fumble in the dark, looking for a light and likely to be eaten by a grue moments where I had to write out my thoughts and objections before I could get to the gist of what I want to say. I should be far more direct from here on in.

My chief objection to quests is how they impart narrative velocity. Narrative velocity is the reason you move forward through the game - you want to continue to see additional content because you've been excited about the rules of the game and of the world it is embedded in. Your disbelief has been suspended, you're experiencing flow, you have invested in the characters and so on. Think of it as all the good reasons to continue playing.

There are two ways to impart this velocity: you can be pushed, and you can be pulled. A push is direct: you are told you have to move forward, but you don't know the unknown you are moving towards. A push is required during the early phases of the first time you play a game, until you've figured out the rules. But it would be wrong to think of the push as the tutorial phase of the game. Many games use push the whole way through, in the form of quests and quest givers. A push can be mechanically very simple: the push in Super Mario is 'move to the right'.

A pull, however, is indirect. You know what the destination is already - 'finding all the coins' in the Super Mario example. The pull comes from the fact the game has made this destination compelling to you. This destination could be as simple as 'reaching the end of the level' - this is a pull, not a push, because the end of a level is known quantity (a 'you've reached the end of the level' screen) - it's the beginning of the next which is unknown. The pull is the payoff from getting there (loud music, bright coloured lights, operant conditioning).

Both pushes and pulls involve a promise from the designer which keeps you moving forward. The promise of a push is 'I will reveal to you something more impressive than you have already seen'. The promise of a pull is 'This thing I have shown you will be as good as you think it is'. With these promises you can see how a combination of pushes and pulls can be used to impart continuous velocity through a game.

But if the challenge of the designer is to deliver on two quite closely related promises, the challenge for the player is quite different. With a push, the player is given a to do list by the designer - as simple as 'keep moving'. With a pull, the player compiles their own to do list - again, as simple as 'get there'. The payoffs of 'Wow' (amazement at narrative resonance) for pushes and 'Yeah' (gratification of operant impulses) for pulls are psychologically quite similar, but the process of player agency is completely different: either externally applied, or internally generated.

It is this internal generation of pull based narrative velocity which is unique to games and why traditional narrative techniques are only weakly effective in motivating a player to continue playing. The two techniques are diametrically opposed in form: the novelty of push countering the repetition required of pull (See The Function of Narrative in Games: A Theory for further argument on the power of repetition in game narrative). Traditional game design requires a balance between introducing new things, and providing the payoff for each new thing introduced (Giving toys, and letting the player play with them).

And this is why, as I intimated in the previous part of this series, the puzzle is such an effective paradigm for quests in many ways. Puzzles operate mechanically as 'given this set of tools, how can I reach the payoff at the end of this known problem?' - they are almost exclusively pull based. You solve a puzzle because it's there and you have been conditioned to solve it. There is almost no narrative backstory required to push you towards it.

But the strength of a puzzle is not just about the logical deduction necessary to solve the problem - for games it is equally about the psychological rewards for using each of the tools, in reality toys, in solving the problem. That is why puzzle games like World of Goo are so successful, while adventure games have done so badly - the difference in the operant payoff between negotiating with a text parser and stretching a viscerally represented ball of malleable goo.

The quests of Far Cry 2 to me feel so successful because they are essentially the same problem repeated with new combinations of shiny, operantly rewarding toys: the weaponry you unlock as you progress. Far Cry 2 is biased far more to pull than pushed based narrative velocity, whereas most traditional quests are push based.

So for the rest of this series, I'll be looking at the quest mechanics I touched on in part one: quest content, branching dialog, main quests vs side quests, procedurally narrative structure, open world vs hub and spoke, and trying to rewrite them as pull, puzzle based mechanics instead of push, narrative mechanics, and see if the results are more compelling. But first I'll touch on an issue dear to me, script vs data driven design, and give an overview of how a data driven design can solve some of the problems of the traditional scripted quest structure. For that, you'll have to travel far from here, to part three of this series.

Sunday, 18 October 2009

The Quest for Quests - Part One (The Cast)

I've played a lot of quests recently: Puzzle Quest, Vampire: the Masquerade, The Chronicles of Riddick: Escape from Butcher Bay, Far Cry 2, Cthulhu: Dark Corners of the Earth, S.T.A.L.KE.R.: Clear Sky and the demo for Armed Assault 2, and stumbling out of these games, it is my intuition that the concept of quests in games is deeply troubled one.

But first, an apology. What follows is a rambling forage through the inventory of games I've picked up recently, attempting to look for the right item to use. You'll see plenty of misapplied (ad)verbs from a list which appears at the outset only partly appropriate (only two RPGs?), and attempts to force a somewhat inappropriate syntax to parse. It should get a lot easier to read in part two and beyond when I check the spoilers for the right answer, and come back and solve some of the puzzles I skip over here. This is not a deliberate technique at obfusticating the answers - it's simply bad design and underwhelming and tangled prose.

It doesn't help that in many of these games, quests themselves are broken and bizarre. I've discussed elsewhere the fascist fantasy politics of Puzzle Quest, and a stillborn review I'm writing of Cthulhu staggers around in a semblance of life stalled by a character not recognising a quest item I hold. Equally, I blame ready access to gamefaqs.com, a refuge from broken user interfaces and game bugs, for spoiling the meat of some of the story delivered in quest form. But to my refined roguelike palate, it's not the stories which are problematic, but the way quests are used to shape and propel the game play.

Strangely, it is the most repetitive of these games, Far Cry 2, which has felt the most quest friendly, with the similarly story-lite free form quests of S.T.A.L.K.E.R. and Armed Assault 2 providing an incentive to play through the bugs (to a point: in S.T.A.L.K.E.R.: Clear Sky, I gave up at the buggy warehouse in Garbage, reproduced with both the old bugs and additional bizarreness from Shadow of Chernobyl). All three games feature an attempt at procedural narrative, clumsily told. Armed Assault 2 builds clipped dialog from context specific information ('Machine. gunner. at. 300 metres. ahead'.) - whereas the rapid fire dialog of Far Cry 2 is delivered by different characters playing similar roles, in an ostensibly dynamic, but in reality quite symmetrical structured narrative. S.T.A.L.K.E.R (either version) plays best when the Russian jokes remain untranslated.

Contrast these failures in story telling with the pitch perfect notes played by the certain characters in Vampire: the Masquerade - Troika making the Source engine sing to be the only game to make me feel like I was cheating on my wife by playing it; and the wonderful opening scenes and smart decision in Cthulhu to have characters turn the uncanny valley into the Atlantic trench (A line I'll reuse in the review should I finish it). In Chronicles, Riddick's bad guy persona voiced with journeyman effectiveness by vin Diesel conveys a compelling series of events, and the broken inmates of Butcher Bay are no less believable than the damaged stalkers of Chernobyl.

As an aside, Source remains the only engine with verisimilitude to deliver something which successfully approximates a human being in game. Every other 3d game engine seems to me to leave their 'people' with a Cthulhoid plasticity - although Far Cry 2 is not far from the mark. Only military shooter Armed Assault 2 and Puzzle Quest from the above list have characters with close to what could be called 'normal' mental states, with every other game I've listed featuring a range of inhumanity and mental pathology - let's just use that as an excuse for their facial tics, stiff movements and unnatural sheen.

So the story component of the traditional narrative driven games is not the source of my quest frustration. But then what is?

It's not the quest content. All the games feature plenty of fetch and kill this quests, as well as light puzzle action and lever pulling. I will admit to fixed puzzles being my least favourite part of quests, but nothing which a quick perusal of gamefaqs.com can't fix. I'm not especially interested in solving word games, or shuffling through inventory screens looking for the right item. Luckily, the world agrees with me that the death of the genre which featured these the most - adventure games - was more than timely.

It's not branching dialog. The games which feature it wholesale, Puzzle Quest and Vampire, avoid the typical pitfalls of branching dialog by allowing real and interesting choices respectively to make most of the conversation decision points both natural and not obvious. In Puzzle Quest, you are presented at points choices which are more freedom vs. obedience than good vs. evil, and the seemingly consequence free outcomes allow you to shape the internal morality of your character to suit the tale at hand. In Vampire, negotiating the moral morass of social interaction is as important a choice in character development as your combat skills, and where maximising your seduction skill seems a natural decision. The only oddity is presenting choices where your character sets out to deliberately antagonise without clear motivation why you would do so: I'll have to sample those on another play through.

It's not the tension between the main quest and side quests. The RPG trope of rushing off to save the world, but then stopping to rescue a cat stuck up a tree, then solve the marital problems of two strangers, then choose the right colour curtains for a neighbour, etc. didn't feature in any of the above games - although the primary driver to find Lord Bane mysteriously disappears towards the end of the first chapter of Puzzle Quest. Vampire: the Masquerade has side quests which are more compelling than the main quest simply because they feel more important (stopping a plague, finding a serial killer, solving family disputes) than the somewhat dusty and archly political orders of a vampire prince.

It's not the procedural narrative structure. The narrative in Far Cry 2 is only procedural in form, not function. You experience a narrative where your buddies are selected dynamically, telling their individual story vignettes in different orders as they send you on the same stock missions, while the larger hunt for the Jackal has only a fixed number of possible outcomes: all controlled by decisions you make. I can't tell you if this variation in form changes the emotional arc of the narrative because I haven't finished the game. But it's the mechanical moment to moment interactions which give Far Cry 2 it's emotional punch - watching a wounded enemy lie writhing on the ground in pain, waiting for his comrades to try to collect him, the brief pause before the clinical assassination of a target. Far Cry 2 is procedural because these moments are procedural: fire, weather, the AI, guns jamming and malaria flaring.

It might be the way the worlds are structured. The 'good' quest games I highlighted are all open worlds, where you are free, essentially, to explore the entire terrain of the game with minimal gating of content; while the 'bad' quest games have a hub and spoke design, with most of the content being unlocked by completing previous quests. This is a continuum - S.T.A.L.K.E.R.: Clear Sky has one significant gate which requires the main quest arc be partly completed, Far Cry 2 a couple, but the locked doors of Vampire: the Masquerade and Riddick are a frequent barrier, and Puzzle Quest refuses to open it's fantasy network up until you progress. Cthulhu is a cleverly disguised corridor shooter for the most part: with a few limited hubs that have only a little more scope than Half-Life.

Paradoxically, I believe the fixed puzzles I don't like are the solution to the dilemma I find myself in. Having said that, I've still not answered why I feel uneasy about quests, and to get that answer, I'll have to ask you to wait here for part two.