Proceduralism: Part Eight (Content)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one, two, three, four, five, six and seven of this series.]
What do I mean by content?

This is one of the foundational ideas of procedural content generation: that there is something we can generate procedurally which has an impact on game play. From the PCG wiki:

Procedural content generation (PCG) is the programmatic generation of game content using a random or pseudo-random process that results in an unpredictable range of possible game play spaces. This wiki uses the term procedural content generation as opposed to procedural generation: the wikipedia definition of procedural generation includes using dynamic as opposed to precomputed light maps, and procedurally generated textures, which while procedural in scope, do not affect game play in a meaningful way. The concept of randomness is also key: procedural content generation should ensure that from a few parameters, a large number of possible types of content can be generated.

When I wrote the original Death of the Level Designer article series I set up PCG in direct opposition to PG, but they can clearly be seen as a continuum: dynamic lights and other traditional procedural generation techniques don't affect your ability to play the game until they do (see e.g. the flashlight in Doom, HDR bloom blinding you, trying to snipe through procedurally textured grass and so on).

Here I'm going to be more specific about my use of the word content: I'm going to define it in opposition to what I referred to as architecture in part six. Architecture is when you generate something procedurally and then try to fit game play to it, content is when you generate something procedurally for only game plays sake, and then let the player try to fit meaning to it.

[Edit to add: I'm using the word content in two different ways. As the C in PCG, content includes architecture, but I think it is relatively uninteresting. Topology is more interesting, but if you're just designing a maze for mazes sake: because you're game is set in a labyrinth for instance, then it doesn't help much. A better example would be buildings. If your building interiors are designed primarily to look like real building interiors, it is architecture, but if they're primarily designed to have waist high cover and door ways you can hide behind, it is 'content' driven in the way I'm defining in this article.]

A concrete example should help you. Later versions of Zangband (an Angband variant) feature a procedurally generated wilderness. Briefly, the wilderness map is a 2d array where each cell has three values: law, population and height, where each value is generated using Perlin noise and then normalised to guarantee that extremes of each value exist somewhere in the wilderness. The actual terrain selected for each grid location in the map array is selected from a 3d Whittaker diagram (basically a way of choosing a terrain type where adjacent values are usually similar, but with boundaries between terrain), where each axis is the law, population and height value. Each grid location is subdivided into a 16x16 map array where individual terrain features are generated as defined by the terrain in the Whittaker diagram - sparse trees, grass and occasional pools of water in savannah terrain for instance.

Zangband terrain looks beautiful, and natural up close, but has no bearing to any real world situation because the values used to pick terrain have no relationship to reality. Law is the (inverse) difficulty level of monsters generated in the terrain, population is the frequency of said monsters, and height is a randomiser to ensure that there's sufficient variety in terrain of similar population and law values (remember, the Zangband map is a 2d array), with a value picked for sea level so that a certain percentage of the map is water. High population are converted to towns and cities, high population, high law areas are fields, and low law areas include more dangerous terrain types like pools of acid and lava to complement the increased difficulty of monsters in those regions.

The Zangband procedural generation is, with the exception of height, a content-based PCG system. There is a direct relationship between terrain and the difficulty of the region, which the player can discover, with some explicit linking to player preconceptions (pools of lava), and some less direct linkages (are snowy forests more difficult, or simply at higher altitudes?).

While I said the values used to generate this terrain have no bearing on reality, the player is going to make sufficient meaningful connections between terrain and reality when they play the game. This is possible because the fine grade scale of the game looks plausible: everywhere the player looks appears that it might correspond to something in reality, so the player doesn't notice that the macro scale is nonsensical: actually not nonsensical, but generated completely around game play requirements, instead of ensuring the game matches an approximation of the real world.

While Zangband's wilderness generation code is elegant it doesn't play terribly well in its current form. There's no hard barriers (except for city walls) so it is very easy to move from safe terrain to deadly terrain without recognising the significance of the change, and the destinations you are looking for (dungeons) are sparsely populated because of a design decision to have different dungeon types without enough variety in what can occur in each dungeon. Both those problems can be fixed: one of the first posts for this blog is about wilderness generation using Voronoi diagrams where I propose generating the wilderness more as an undirected graph from randomly generated points on a plane, where some edges are eliminated from the Delaunay triangulation by putting up barriers, and some points are filled with untraversable terrain (mountains, seas, lava) while ensuring that all traversable nodes remain connected.

And I've written about how to make dungeons interesting in the Unangband Dungeon Generation article series: by subdividing the dungeon into one or more 'ecologies' of different but related monster collections which are used as selection lists for what monsters should exist here, and then decorates the dungeon rooms with randomly selected items and terrain types biased towards those which are related the most powerful monster in the dungeon ecology. The assumption here is that the player wants information about the most important thing on the current dungeon level - the most powerful monster that they are going to face, and so ecologies and decorations are selected which relate to some feature of that monster - if it breathes fire, the ecology may have other fire breathers and there may be burn marks on walls and floor and trees, if it is evil, there may be evil monsters and blood spattered furnishings, if it summons wolves, there will be at least one type of wolf available to choose from.

The correlations if you see an orc are only weak: you might be seeing it because the boss was an orc, and the ecology was partially filled with 'orc' monsters, or because the boss was an evil priest and the ecology had 'evil' monsters, or because the boss was a black dragon and it was a black orc (matching on names, instead of creature flags). Each ecology could be built from several such matches so you have multiple hints (and to ensure more variety); similarly the dungeon features chosen were heavily biased (5:1) or (10:1) to pick a feature with a similar match process, but could always pick a random one instead.

This ends up with a biased randomness, where you are being fed enough clues and enough noise that while you think something is going on behind the scenes, you are never quite sure if each piece of information in isolation is relevant. Information is a commodity when it comes to procedural content, but also a litmus test: it's not procedural if it can be spoiled.

The breakthrough in designing this came when I realised that there should be multiple ecologies on a level - with boundaries between each ecology which were filled with weaker related monsters, and that the architecture of the level (huge hallways, narrow burrows, natural caves) could be independent of what was filling it. Prior to those two conclusions, levels had ended up boring, but with multiple overlapping themes the dungeon became a lot more interesting. (For instance, Terraria has three axis in which themes overlap: depth, type of rock, and the presence of water or lava.)

That's because biased randomness was necessary but insufficient: you also require juxtapositions - where something unexpected occurs the player is forced to come up with a way to rationalize it. People are good at telling stories: the positioning of an arrow trap, a skeleton and a snake in Spelunky may be read as the dramatic death of a former explorer, whereas each of these elements separately may lack this meaning.

The big weakness with this biased randomness + juxtaposition approach to creating interesting content (and the simulate everything approach of Dwarf Fortress) is that you need a lot of content to make it interesting because otherwise you never have enough possible combinations to create any significant meaning. Luckily the total cost of creating a new creature in Unangband is incredibly low, somewhat more so for the complicated raw format that Dwarf Fortress uses, but compared to a 3d model (or in some instances a 2d sprite), it pales into insignificance.

Where the advantage is in the marginal cost: the cost to add an extra creature is generally fixed for a procedurally generated environment because once the rules are in place you can generate an infinite number of new levels; whereas in a hand-designed environment you have to potentially change every single level by hand if you should change an assumption about how a creature moves or the player acts, and as the total playable space goes up, the cost of additional content in that space goes up even faster. Procedural generation is how Terraria has been able to add so much content since release.

It is possible to combine procedural and hand-designed content without requiring a huge overhead of content types, by creating vignettes (small scenes) of artist created content which can be inserted into a larger procedural space. Some procedural generation systems consist of nothing but templates of hand-built scenes combined in such a way they can fit together. To make them effective, the vignette should have some random content so that it remains unpredictable when it is encountered over multiple playthroughs, as well as some interior space where the theme of the larger procedural area around them can break through (rather than merely restricting the template to a single theme). Part of the genius of Spelunky is that it consists of pieces of small platforming 'beats' combined together in a way that is only perceptible after multiple play throughs (Darius Kazemi suggests about 500 or so). I would also suggest considering adding bread crumbs of content which can be procedurally placed in the path leading to the vignette to help further integrate the template and the wider level.

Unangband does one better in that it has a room generator that is deliberately designed to create interesting rooms by placing content about the room in a combination of patterns and random placement. Briefly, two overlapping rectangles are created, and then content is placed in either the north, south, east, west or intersection of the two rectangles while a description of the room is created using a Markov chain. The tableau that is created can mimic player actions: bodies and blood can be scattered around the room in a manner similar to the consequences of player combat - creating additional resonance and meaning. More games could benefit from the procedural placement of the detritus of fire fights and assassinations.

Another piece of the content puzzle is progression. I've referred to increasing difficulty level already, but it needs to be stated that increasing reward levels are equally important. You can be sure that any newly generated weapons or treasures are going to be interesting for the player by ensuring that they will be more powerful than what the player has already found (give or take some random variance). Similarly, more challenging monsters are inherently interesting, to a point. To avoid the treadmill of more powerful items + more powerful monsters feeling like Ground hog day you should also expand the range of permitted behaviours: firstly by introducing them singly (ranged attacks, alternative movement) and then in combination.

The final piece of the puzzle is making sure your content is porous and well connected. This allows the player to find the optimal difficulty level for the way they want to play, and to move to freshly generated spaces when the content they have already encountered is exhausted. Terraria does this by allowing a new world to be generated at any time, Angband by allowing new levels to be created on the fly and so on.

But increasingly, developers aren't just relying on the player to find and create interesting content in procedural games, they're inventing methods that rely on simulating player wants and needs. The AI director in Left4Dead and Dark Spore is the best known example, but there are a number of others, and the most promising avenue of new research into procedural generation techniques. And I'll be looking at those in part nine.

Proceduralism: Part Seven (Education)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one, two, three, four, five and six of this series.]

I was going to be talking about content, but I think there's an important point that is worth underlining now, especially seeing as the previous post ruffled a few feathers.

One of the key challenges about procedural content generation is that so much of it is 'intuitive'. Not intuitive in the sense that it is easy to understand, but intuitive in the sense that you have to use your intuition to figure out what works and what doesn't work.

You will sit for hours, watching your algorithms generate content over and over, tweaking the parameters until you are satisfied with the outcome. It is an incredibly powerful feeling, like being a god in some sense, in that you are literally creating (and destroying) worlds with the click of a button or invocation of the command line. Even the smallest change can butterfly into unintended consequences or beauty, and there are a surprising number of times where accidents turn into final implementation. My favourite is the erosion simulation from Tribal Trouble, where a thermal erosion algorithm failed to produce the desired results, until the sign was reversed on the equation being used - turning a sophisticated model into a nonsensical result which happened to look better.

I've coined what I call Doull's Law: 'Any time saved using procedural generation will be wasted watching the resulting screen saver', to try to capture at least the amount of time this takes, if not the power of this idea.

The consequence of this centrality of intuition, is that you have to be told the story of developing a PCG algorithm, instead of just seeing the final code, in order to understand what was done and why. Projects that describe the process of development like Project Frontier, Procedural World, rune | vision, Making Worlds, Procedural Planets, Dungeon League, Polygon Map Generation, Infinity: the Quest for Earth, L.o.V.E. and Spore and all the other creation stories are incredibly important: not just as beautiful repositories of code and images and ideas, but as foundational documents to their procedural worlds.

And I believe, fundamentally, why procedural generation has never become mainstream, is that it takes time, especially time spent coding, to develop this procedural literacy. If you look at, for instance, the Braving Procedural Generation thread on TIGsource, you see variations on the same, simple cellular automata cave generation over and over, because each person who falls in love with PCG has to go through the same learning process themselves to try to discover this intuition.

That is why I set up the PCG wiki [1]- to try to improve the overall literacy in this field. And the feedback to the survey I'm running at the moment has been incredibly positive, but almost everyone feels like they don't know enough to contribute back. My vision ultimately is to have an online PCG paintbox on the wiki, that'll let you explore cellular automata, and height maps, and fire propagation and so on, all in your browser so you can experience this feeling without coding - I just don't have time to create such a beast.

Back on track in part eight.

[1] That and I needed a bibliography of PCG.

[Edit to add: I know we'll have achieved that level of literacy when we start talking about a Cepero nave, or Young trees. At the moment all we have is Perlin noise, which is a bit high frequency for my liking :) ]

Proceduralism: Part Six (Architecture)

[You'll probably want to read the original article series that inspired this follow up, then start with parts one, two, three, four and five of this series.]

Edge Magazine recently featured an article, Building Worlds with a Single Click, which highlighted and praised two exciting new projects by independent developers: Project Frontier by Shamus Young and Procedural World by Miguel Cepero, both of which feature beautiful procedurally generated worlds.

The thing is, we've got very good at building procedural worlds - so good that virtually every example uses the same small underlying set of well understood systems: noise, L-system based architecture, Whittaker diagrams and so on that even a single programmer working in their spare time can implement. Just to pick a few featured in the World Building page on the PCG wiki: Making Worlds, Procedural Planets, Dungeon League, Polygon Map Generation. And of course, there's Infinity: the Quest for Earth, L.o.V.E. and Spore; all of which feature incredibly detailed environments created by incredibly talented and smart programmers.

And all these amazing worlds? Almost everyone is focused on building these curate's eggs - which, if they eventually end up being released as a game, become a disappointing, empty and lifeless one.

[Edit: Miguel Cepero has responded to this post, and quite rightly points out that the above statement is not a nice thing to say, specifically when his and Shamus Young's project should not be judged on this basis as they have not been released. I would like to apologise for making this generalisation, which the article in Edge magazine points out is the big challenge that all these projects face.]

Does almost all procedural generation amount to, as John Carmack puts it, is "a really crappy form of data compression"?

My procedural spider senses tingle as soon as I see a procedural generation system that uses one of the following two approaches:

1. Mazes (and by extension BSP-trees)
2. Height maps

because I've yet to play a game where I've exclaimed 'Wow, what a great height map' (except Populous, but we'll get to that) and the pleasure of solving a maze isn't the same as the pain of having to play through one.

I've also seen a rise in recent suggestions and several implementations of Metroid-style procedural generation featuring gated lock-and-key puzzles to partition a map, on the assumption that being forced to traverse through a non-linear space looking for a key is some how interesting. This is putting the cart before the horse: Metroid (and Zelda) use this technique to force the player to explore an already interesting (and hand-designed) location, not because looking for a key is itself challenging. The lock-and-key puzzle is merely a dressed up fed ex quest where you're not told the location of the package you have to deliver (or worse, you stumble across the package without knowing its destination address).

When we talk about architecture in game play, we don't think of buildings and naves and antechambers: we refer to choke points, and cover, and objectives. The topology of the space is much more important than its aesthetic or fidelity. The most successful (and perhaps only successful) procedurally generated game spaces so far are all based on Rogue, with its simple room and corridor design.

With a room and corridor design we get four important features:

1. Corridors - which act as natural choke points at each end, and cover if you are in them
2. Convex shapes - spaces where you can see everything in the space from everywhere else
3. Concave shapes - spaces where some space is hidden from another (more cover)
4. Loops - which allow you a safe haven by traversing the loop to recover when chased by enemies of the same speed or slower

Elite, the other arguably successful procedurally generated game space, remains interesting because it is a procedural objective generator. Here you are searching for trade routes between high tech industrial and low tech agricultural worlds: the topology is interesting only because every edge is a potential goal.

Populous, Dwarf Fortress, Minecraft and Terraria all cheat procedural generation in two important ways: they allow you to modify the topology of the space and they encourage you to make interesting content in that space to which you become attached. An uninteresting dead end can be transformed into a useful corridor, or lit by a torch to mark that you've 'already been here' or mined for valuable ore. The procedural generation systems they use may make beautiful places, but it is the player's job to change them into interesting spaces.

It helps in the case of Minecraft and Terraria that much of the procedurally generated spaces mimic Rogue's room and corridor layout. Strategy games generally generate a mix of the Rogue-type (open areas, choke points defined by inaccessible terrain) and generation of objectives through resource scattering (call this Civilisation-type PCG).

Even with a room-and-corridor design, the architecture, or more correctly topology of a space is insufficient to lead to great procedurally generated games. As I discovered when working on Unangband dungeon generation, it is the contents of these generated spaces that is the most important part of procedural generation. And that is why it is so frustrating to see developer after developer get trapped in architecture, distracted by beautiful world building, and not concentrating from the start on the creating content.

And I'll be discussing content in part seven.

Critical leaps

In all the sound and fury of the reaction to Portal 2, it is hard to have a more subtle critical dialog about the game. There's two main points worth exploring: which go in two different directions and which I have hinted to earlier.

1. The disparity between the overall critical response and the overall end user response. This is part of a wider conversation about the complexity of reviewing a game at release. I don't mean this needs to be a conversation about the ARG, in fact I'm not especially interested in it beyond watching the car crash of Valve's clever and inspired marketing and overwhelming end user expectation. If Portal 2 was an unqualified success, the end user grumpiness would be quickly silenced. But the fact is that the critical response is so overwhelmingly positive, when in fact there are problems with the game - such as the weaker story with some really ham-fisted moments and plenty of missed opportunities; that if you don't warm to the two-dimensional characters, Wheatley especially, you'll be left out in the cold; that you need to play co-op to experience puzzles which are actually challenging; the final encounter ends in a train wreck of cut scenes and music.

2. The feeling that Valve's game design somehow doesn't ring as true as it used to. I had the same problems with Left4Dead 2 as I do with Portal 2: for almost the whole game there is this feeling of one obvious path, which for me ended up me rushing through the levels waiting for the 'good bits' to begin. Paradoxically, it took me 9 hours to complete but almost all the delays were me missing switches and not using angled ramps for their intended purpose[1], which meant I would repeatedly try weird alternate solutions. The puzzle design in single player rarely involves any planning or experimentation: it's all spoilable in the sense that once you figure out the problem, implementing the solution is trivial. I particularly miss the sense of escalation to the 'you've got to be kidding me' level of complexity of the first Portal, something Valve has done well since Half-Life: instead here is all big is better, and 'distance fog makes levels awesome'.

The biggest flaw to me is the sense that games should be aspiring to something other than this. Maybe I'm over reading what is an encapsulated game experience, but the AI director and limited experiments with procedural level generation lead me to believe Valve was moving in a different direction. Portal 2 feels like a dinosaur raising it's head to watch the oncoming Minecraft block asteroid.

[1] Spoiler: Which is always jumping.

Designing a Magic System Redux - Part Four (Pick any two)

You are encouraged to read parts one, two and three of this article series, and are strongly encouraged to read the original Designing a Magic System series of articles if you have not already done so. It turns out I had this article sitting in draft for about six months, so some of the Team Fortress 2 figures are a little out of date.

One thing I've tried to play with in Unangband is alternative character development models to the standard RPG tropes: experience and levels. Not that you'd ever guess by playing the game which appears hugely focused on level increase through experience gained from killing monsters. But a high level character in any Angband variant is incredibly fragile without the equipment that they will have gained along the way, which makes Angband much more about the correct selection and management of discovered items in the inventory, than it is about level gain or monster slaying.

I've discussed previously the differences between skills and classes, and some of the general disadvantages of each approach. I've also gone into detail about how to design a magic system, and how it may be worthwhile looking at differing systems of progression, without going into detail about the implementation details.

I want to talk about these details here - taking two specific progression designs from Unangband and give you the reasoning behind each of them; with specific regard to making the choices interesting.

The weakness of a lot of progression systems is that the choices are uninteresting. Take how most RPG skill systems work: where you buy skills from one or more talent trees using a pool of points which increases the longer you play the game. The choices in most of these systems are not exclusive, and instead merely become an ordering decision, that is, if you buy skill A, you can always buy skill B later on, and there is no difference ultimately in whether you choose A first or B first, provided you get both.

This problem is exacerbated in when the cost of skills deeper in the tree escalates - the Civilisation series of games being a good example - because you can skip buying one of the more expensive skills to effectively 'catch up' on all the cheaper skills you elected not to purchase previously.

The effect in both instances is that the characters end up being homogeneous midway through their progression - and only start to differentiate themselves at the higher level skills, instead of through out the talent tree.

You may argue that a particular system has skills which work in synergy, so that it is always worth picking skill ABCD in sequence, instead of EFGH, because the skills combined are worth more than e.g. ABGH. But in that instance, you're actually presenting less choice to the player, because ABGH users will be beaten by ABCD or EFGH users, so that despite having 8 skills in this example, there are only two real choices.

You may also argue that a particular system has pre-requisites so that to get skill C requires that you have learned skills A and B, E requires A and C, and so on, so that the skills at the tips of the tree are entirely dependent on which skills you have chosen earlier. But by using pre-requisites, you're again restricting the range of possible choices to only be meaningful at the tips of the talent tree, as opposed to choices further up the trunk.

There are several ways to avoid this. The first is by either using slots or sockets, so that the player can only choose a set number of skills to equip out of the possible talent trees. The inventory system in Angband is an example of using 22 slots to carry all possible discovered items, and the equipment system an example of using sockets to carry a single weapon, shield, amulet, light source, 2 rings and so on. A particular socket may hold weak, middle or powerful skills, so that you are forced to pick only one of the set of possible skills of each grade.

Take Team Fortress 2 as an example. At the time of writing, the sniper has 2 possible primary weapons, 3 secondary weapons, and 2 melee weapons. Using only 7 weapons, we have 12 possible sniper combinations because of the division of weapons into these 3 exclusive buckets. And if we could choose 3 items to carry, from 7 items total, there would be (7x6x5)/3! = 35 choices in all. Whereas a talent tree of 7 skills from, for example, 100 Rogues, would have at most 3 branches of up to 3 depth. Assuming a similar 3 selection limit, and approximating the possible choices by using a combinations with repetition counting approach, there can only be (5x4x3)/3! = 10 choices.

In general, if you have lots of skills and don't allow the player a large number of selections, you are better choosing a slot or socket approach. If you do allow a large number of selections, relative to the total number of skills available, the analysis of choices available in the talent tree by using a combinations with repetition approach breaks down, and you are instead limited by the depth of each talent tree which at best behaves like the slot approach. The socket approach has degenerate cases where the talent tree behaves better, but in general is far easier to design.

The second way to avoid this is with a sliding window approach, which is what I use in Unangband for developing abilities for familiars. A sliding window allows you at best only a subset of choices at any particular time, and periodically the window slides, so that early choices are no longer available, and later choices become available. With familiars, you can choose a new ability every two levels, and every four levels the window slides 10 abilities further on into the list of possible abilities. Since the window is also 10 abilities big (but in general does not have to be the same size as the slide distance), effectively you can choose 2 abilities out of 10 different abilities every four levels. This gives you approximately (10*9)^12 choices over the course of the game, at the cost of designing 120 different familiar abilities and putting them in an approximate order of power.

(I would hate to have to design talent trees containing 120 skills to give the same variety of choice.)

I could, of course, provide far more choices by allowing the player to pick from any of the 120 familiar abilities every time they advanced two levels (the slot approach), but aside from the game balance issues of allowing some high level monster abilities from the start, there is the real consideration that the human mind is limited in its ability to comprehend more than a limited set of choices, and breaks down its rational decision making process if presented with too much choice at once.

This limit also suggests an upper bound for the number of available talent trees to choose from, as well as the number of slots or sockets and the number of choices to be presented per socket. A lot of this is avoided in Angband because you only encounter so many items at once, and must discard choices that you've no room for in your inventory or equipment.

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).

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.

Designing a Magic System Redux - Part Three (Magic Items)

You are encouraged to read parts one and two of this article series, and are strongly encouraged to read the original Designing a Magic System series of articles if you have not already done so. This article also incorporates most of the text from another blog post which you may want to refer to the comments of.

I've been working on adding items with multiple 'pvals' to Unangband, and this is probably the most wide ranging set of changes I've made to the code since I began developing.

In Angband-speak, a pval is the value associated with a particular magic item flag: the +3 in a ring of Strength +3. Angband and many variants only allow you to have one numeric value per item, which was also historically overloaded with additional meanings such as the number of charges a wand would have. I've separated out that meaning (there is now a separate charge value) - and I'm now in the process of allowing items with multiple different numeric values e.g. a ring of Strength (+3) and Size (+7).

I'm not the first variant to have done this: so I'm taking an approach similar to Sangband, where the pvals are represented by a small numeric array of values, and then the flags to which pvals can apply become a bit array. So you end up with a situation where you might have pval[1] which is +3, and pval_flag[1] which is Strength, which in combination mean Strength +3.

The alternative is to have an integer array equal to the size of the possible different flags: the example here would be pval[STRENGTH_INDEX]=3. This obviously uses up a lot more memory and storage for each item, but with modern computers, the performance impact would be negligible. I've chosen the Sangband approach as much as a design constraint as a technical constraint - I have a hunch that people will have problems comparing two items which have more than 7-10 different discrete numeric values.

I have made a decision which increases the amount of code I've had to alter but should make it simpler long term, by also making item abilities such as to-hit bonus and to-damage bonus, weight and armour class, included in the pval framework I'm developing. To make this clearer, I've retitled them avals, short for ability values. An item now has abilities, associated with avals and which vary over an integer range, and flags, which are either on or off.

One possible abuse of the ability to use Angband items in multiple ways is the ability to throw ammunition instead of shooting it from a bow or crossbow. Ammunition is light, which means you can carry a lot of it, and throwing it is 'abusive' because the damage bonus that is applied to firing ammunition is also applied to thrown ammunition, without penalty. This is exacerbated in Unangband because the damage bonus was until the latest version counted twice for thrown weapons and not multiplied by missile launchers, which meant that throwing an arrow (+9,+9) may be more effective than firing it from a longbow.

The damage bonus in this example is insensitive to it's context - it is applied equally when the item is thrown, set in a trap, or fired from a missile weapon. And if you think the ammunition example could in some way be construed as sensible, consider that the damage bonus a bow applies to arrows fired from it, would also be applied if you threw the bow instead.

At the moment, I'm changing this: damage bonuses will be able to be context sensitive - a weapon that adds damage while fighting, won't necessarily benefit shooting, but may, for example, benefit being used in a trap.

I have the flexibility to allow missile weapons with incredibly good trap damage but no shooting damage bonus, but it is unlikely that a player would ever choose such a weapon over a missile weapon with superior shooting damage and no benefit in traps. Whereas if the weapon was multi-functional, it is more possible the player will attempt to take advantage of 'free' additional functionality at some point. I can do either approach with the approximately same level of cleanliness in the code: it is a data design issue, rather than code overhead cost.

There is a separate but related question about worn vs. wielded items. If a sword improves your ability to fight with it, does it also improve your ability to fight with another weapon if you hold it in your off-hand or even just strap it to your body? In particular, if you get one more blow per round with it, do you get that blow if it would be from another weapon?

On consideration, there are two related ways of thinking about magic items: firstly, how the abilities (avals) accumulate if the character is using multiple items which have this ability, and secondly whether the player inherits the power (ability, flag) of the magic item at all.

The simplest example is weight: if a character picks up two objects, both of which have weight, how is the character's overall encumbrance affected? This example is seemingly straight forward: the weight of the two objects is added together to give the total encumbrance.

But what if we measured encumbrance as the sum of weight, plus volume, plus length, which may be a more realistic way to model how difficult it is an item to carry? It may be possible to stack the two items side by side, so that the length of the total isn't the sum of the longest axis of each of them. So even this simple example can be complicated through extrapolation.

Then there is the problem of accumulating numeric values. +3 to hit, and +6 to hit is seemingly straight forward (+9 to hit), but how does one item which gives 50% resistance to fire, add to another item which gives 33% resistance to fire? Should it be additive, so that the player gets 83% resistance to fire? Or multiplicative, so that the player gets 66% resistance (1- (1-.5) * (1-.33))? I am a big fan of geometrical progression for resistances - because they provide a big impact initially which tapers off, but is still useful when added together. In the most straight forward geometrical progression scheme, level 1 resistance gives 50% resistance (1/2), level 2 gives 66% resistance (2/3), level 3 gives 75% resistance (3/4) and so on.

This also depends how you model fire damage to start with. What does 50 hp fire damage actually mean? Is 100 hp fire damage twice as hot? In which case, if you are modeling resistance to fire damage as ability to tolerate a temperature range, someone with 50 resistance may be able to ignore 50 hp completely, but take 50 hp damage from a 100 hp attack.

Specific versus damage bonuses are another tricky component to balance. In Angband, weapons have the ability to slay particular types of monsters for double, triple or higher damage, or branded with an element which does additional damage from fire, cold and so on. The Angband approach is to use the highest multiplier, rather than add the multipliers together. This is simplifies the creature design process as the designer is free to create a creature which is a hybrid of e.g. dragon and undead, without having to worry about this creature taking more damage from the weapon which is effective against both dragons and undead than against creatures which are just either dragon or undead.

The same applies to brands, even though we could model a weapon with multiple brands as doing both extra extra fire damage (which creatures immune to fire ignore) and extra cold damage (which creatures immune to cold ignore). If we treat this weapon as doing extra damage from each element, instead of picking the highest multiplier, creatures which are neither immune to cold or fire would take both sets of damage, which would make weapons with multiple brands much more effective than weapons with multiple slays.

But should this 'highest multiplier' approach be used across multiple items where e.g. a character could have a weapon with a fire brand, and also a ring which imparts a fire brand to the weapon. If yes, then there is no benefit to specialising in fire-based equipment, while there are plenty of draw backs. If no, and the multipliers add together, you have to balance for the maximum per item multiplier is multiplied by the number of possible items that the player can gain benefit from at the same time. Be sure to come up with a good reason for being unable to wear a ring on each finger and toe, and pierced through any available flap of skin.

With the inheritance question, it is clear some abilities are straight forward: they should be applied to the player if the item is equipped (fire resistance), or only apply to the object in question (proof against destruction by fire). It is specifically the 'use the item in question to perform a task' abilities which are not so clear. Take the ability to increase the amount of damage the player does.

As I highlighted earlier, it makes no sense to have the bow's damage bonus apply to the weapon when throwing it. So to address this, damage gets separated into 'damage while shooting', 'damage while setting traps' and so on. These are simple enough to apply to the player: or are they?

The dual wield problem, when a character is using a sword in his primary hand, and a dagger in his secondary, show that this is not necessarily straight forward. Does the dagger's 'damage while fighting' apply to attacks with the sword? In all likelihood, not (If you disagree, replace damage with fire brand. Does the dagger's fire brand also brand blows from the sword?). So we have to consider 'damage while fighting' as a specific property of the item, which we add at the time the item is used, as opposed to inherited by the player.

But this means that the same item ability is used in two different ways: an amulet of 'damage while fighting' is inherited by the player, but a dagger of 'damage while fighting' is only applied when we use the dagger. In which case, it may be simpler for some items to have a straight 'damage bonus', which is used whenever the item is being used, but not inherited by the player at all, whereas other items have a specific 'damage while shooting' bonus, which applies only when the item is being fired.

(I'm going to complicate this by also having rings apply some abilities only to items wielded in the hand they are worn on. This will be the left-hand for shooting and secondary weapons, and the right-hand for primary weapons.)

In the part five, I'll look at how Unangband evaluates the relative power of magic items, taking into account the inheritance or non-inheritance of various flags while keeping the above issues in mind.

But first, in part four, I'll take another look at skill acquisition.

Mashups

I try to use the reviews at ASCII Dreams as writing experiments: from fiction writing, to New Games Journalism, to advocacy for games which I feel have been overlooked (good and bad). I started wanting to say something about Arma II, but ended up with a completely vanilla, and somewhat negative review. But luckily, I'd also been thinking about the similarities in design between Arma II and S.T.A.L.K.E.R. - particularly the visual design and I suspect common texture assets - and how it would be great to play S.T.A.L.K.E.R. in the Arma II engine (or at least a sequel to the original) which has the open world capabilities that GSC were never able to achieve.

That is why my A.R.M.A. II review ended up as a mash up of what I originally wrote, interleaved with paragraphs from an earlier S.T.A.L.K.E.R. review. To underline the point - and give you a chance to figure out what was going on before I did the reveal here - I've shamelessly interleaved the majority of the Eurogamer reviews of Half Life 2, and Grand Theft Auto: San Andreas to review another great mash up Half Life 2: San Andreas. (This second review also highlights the amount of interchangeable discussion about the hype each game warranted at the time which the reviewer felt they had to address).

Unlike other mashup culture, game mashups are unlikely to occur, unless officially sanctioned, because combining the disparate underlying technology is a much harder feat than remixing a song, or interleaving two strands of literature. The best known game mashup combines the rules, characters, art and level design of multiple different 2D games in a new game engine: 3D engines are more complex because of the need to decompile the 3D level which may incorporate textures, bump maps, lighting, collision and physics geometry, navigation meshes and scripting which may be implemented differently between engines. It is possible that a seam or gap in one 3D engine may be unimportant but might result in characters falling through the floor of the world in another engine. Similarly a 3D map - or even objects like guns in the HUD - may only contain geometry visible from locations that can be accessed when traversed using the rules which limit movement in that game; when accessed by an avatar which can move more freely, the map may fall apart like a Hollywood set.

Open worlds pose the additional challenge of bespoke map design: there is no common 3D standard for maps of the scale and streaming speed required of a particular world, whereas the BSP levels in Half-Life or static meshes of Unreal 3 may be interchangeable between games. It may be possible to virtualize the game in such a way that the video card representation of the level could be imported into another game to avoid having to build a custom import tool for the map itself: this would involve virtually mapping out the scene graph in the same way that special effects artists map out the geometry of the real world in order to digitize it.

The abstraction of games into engine, data and scripts (using common script languages like Lua) point to another possibility which has not been explored as much: importing the game data into another engine or rule set. Unangband's monster list consists in part of monsters invented in other Angband variants and then pulled across and reshaped to fit the Unangband game world.

Amateur enthusiasts are also prepared to spend significant amounts of time reimplementing older games in newer engines, but this is more to preserve the fidelity of the older game to keep up with the sensibilities of modern gamers than to mash up two games into a third. Open source reimplementations of games like FreeCiv allow different rule sets, to allow mashing up a game with it's sequels, but little beyond that. And fan fiction-like appropriation of one game into another, notably Little Big Planet's level's derived from Mario, Metroid and elsewhere, point to another possibility: user generated content allowing mimicry of multiple older games in a newer space. Think a Second Life world which has the island of Morrowind offshore from Liberty City.

What games would you like to see mashed up this way? Feel free to contribute a 'fake' review if you want. My inspiration for these particular mashups grew from playing both games at around the same time, and letting the ideas peculate and pollinate between the two in my mind. What games are you playing together at the moment?

Review: Half Life 2: San Andreas

At a time like this when you've got a game with such massive expectations heaped upon it, it's almost futile trying to offer anything but the most positive comments you can possibly come up with. With Half Life 2: San Andreas, where we've been fed more pre-release information and preview opportunities than just about any game in history, it seemed impossible that the game couldn't be anything other than absolute mind blowing genius. Everything we'd seen, read and heard spelt out that this was a title so far ahead of the sorry pretenders that there simply could be no other game out there worth playing. The game of the generation. The game to end all games. Technically advanced, bigger, better, even more controversial. But you all know how it works. They would say that wouldn't they? The first commandment in the law of games is 'Thou shalt hype'.

At this point the Internet is quite possibly melting as hundreds of thousands of devotees all around the world simultaneously stress Valve's servers to breaking point. We haven't seen the likes of it. It's truly a momentous, agonising wait as we cross fingers and toes that Valve hasn't screwed up and underestimated demand; we were fearful, but like something approaching the Space Shuttle launches of our youth over two decades past, we have lift off.

But it was not always like this. Half-Life slipped out to zero fanfare, and worried PR types pleaded with journalists to not mention the violent aspects of the game, lest the British tabloids pick up on it and demand to have this 'sick filth' banned (only three years late, eh?). Even Opposing Forces emerged a healthy shade of pink, with a mere handful of screenshots to tease us with in the run up to release. The same deal with Blue Shift. And then suddenly Valve decided to go from one extreme to the other, literally bombarding our mail box with new shots, exhaustive documents going into meticulous detail about the various new features that have been shoehorned into the game. Then followed three preview events, but yet not one opportunity to wrestle the joypad off them; and no opportunity to review the game until the finished boxed copy was finally delivered just three days ago. It was akin to a starving man being forced to watch a culinary dish being prepared, cooked, tasted and savoured in front of him. "Look, smell, but don't taste. We'll give it to you when we're good and ready." Oh the agony.

But not everyone has such a smooth, seamless ride. As we rocket into the stratosphere we can just about make out the crimson faces of those left behind, venting furious, jealous, indignant anger at Valve for managing to mess up their dream journey, furious that even retail boxed copies fail to authenticate. It's a moot point, and a discussion that's still raging.

Somehow we preferred the enigmatic media blackout of old. Leave the surprises to be discovered. Let the word of mouth spread the game's gospel. That's how the last two worked; did Valve really need to go to such lengths to effectively spoil a lot of the game's surprises? The game could have hit the shelves today with zero advertising and no reviews and still sold out. It's that type of game. The less we know about it, the more we want to find out what's in there. The pre-release media splurge was a novelty; we thirsted for every morsel to begin with. Of course we did. Everyone did. Towards the end of the campaign, though, we actually couldn't believe quite how much Valve was prepared to spill and we politely declined to attend the final preview event for fear of spoiling it for ourselves, never mind everyone else. The very charm of the Half-Life games was the element of surprise; the exploration factor. Ringing your mates up excitedly reporting on your progress and all the craziness you've come across. Comparing notes. Playing through San Andreas did reveal a few surprises, nevertheless. It's that sort of game. You could write an entire book on the game and still only find yourself skimming over certain elements of it.

But after the roar of take off, a serene silence gives way. The G-Man looms large and loud and it takes somewhere in the region of two seconds to realise what all the fuss is about. Another stylish intro. A quickening of pulse, a shallowing of breath. A downtrodden yet magisterial air as another commuter journey begins. An atmosphere to savour. An oppressive beginning that gives a small taster of what we're about to experience; a world we have been trying hard to imagine for months, years. Blocking it out of our minds, trying not to spoil it for ourselves, yet filling time and column inches with games barely even worthy of the name, rushed out into the market only to let us down and chip away at our eternally optimistic resolve. Valve's approach was different. Valve's purpose was to take things forward whatever it took, however much it cost, and seemingly no matter how many people it pissed off along the way. And now the future is here.

But we're not here to exhaustively run through the myriad of things you can do in the game, but more whether they're actually fun and whether the game's really what it's cracked up to be. The first thing that cannot be overstated is that Valve really weren't making it up when they said it was a big game. It positively redefines the concept of what constitutes an epic game. There is absolutely no question that San Andreas is in the region of twice as big as previous Half-Lifes. Maybe even three times, depending on what lengths you'll go to. To even work your way through half of the missions alone would take more time than it would normally take to finish two average sized action-adventures. In value for money terms it's hard to imagine another game like it.

If Half-Life 2: San Andreas achieves one single thing, it's to put into sharp focus how far gaming has come, and more specifically how far behind some of its competitors in the FPS genre really are. Some doubted that the Source engine could match the technical brilliance elsewhere, but it has not only surpassed anyone else's achievements, it has done so without forcing people to invest in ludicrously expensive hardware. Reports persist from amazed gamers with mid-range set ups that have been blown away by how well the game runs on their systems. That Half Life 2: San Andreas looks more convincing, more understated, more realistic, more interactive and definitely more stylish than its peers yet manages it with far lower overheads is not only an impressive feat, but commercially a masterstroke. Not letting a fair chunk of your loyal customer base play the game because your content delivery system can't cope, however, isn't - although some would argue that the fact that a hacked version of the game didn't appear until day of release meant that the ends were worth the means. To an extent we'd have to agree; how much more money was earned as a result of slowing down the hackers we'll never know; but a hunch says it's a lot.

Pile on the extras and it's almost too much to comprehend. Pimping missions, Trucking, Driving school, Ammu-Nation challenges, Dating, Territory occupations, and more join the usual distractions on offer such as Taxi driving, Vigilante, Ambulance, Fire fighting and the ongoing quest to find hidden items; in San Andreas' case they're not as prevalent as you'd expect, but seek and you shall find.

But we don't want to get bogged down in the relative merits of Steam, the shoddy packaging of the boxed version or any of the periphery issues that have clouded this momentous launch (the forum's choked with enough vitriolic bile to melt Gabe Newell's face as it is). We're here to talk about the game. And what a game. 14 chapters, 18 or more hours (skill/approach dependent) of almost relentless, fat free entertainment that's the gaming equivalent of watching several blockbuster action movies back to back. If this game isn't worth the asking price, we don't know what is.

As veterans of previous campaigns it's easy to come to hasty conclusions about San Andreas. Your expectations really don't help. What we perhaps expected was more of the same. Much more of the same, with tweaks, technical improvements and the benefit of an entirely contrasting set of scenarios, characters and, naturally for a game set in 1992, the soundtrack. What you don't expect or even particularly acknowledge at the time is how the game lurches dramatically in different directions, often throwing you completely off balance into the bargain, and not always in a positive sense.

Sometimes we like to utter a few sentences on the back story to give you a flavour of what to expect, but Valve being Valve has elected to keep things as enigmatic as possible. It's not possible to know this by just playing the game (and there's no manual anyway), but apparently the game takes place 15 years after the Black Mesa incident. No one knows (or even hints) what has happened in the intervening years, or why you're on your way to City 17, or what role you're supposed to perform once you get there. Suffice to say it's a grand city under an oppressive police state rule, with scary looking Tazer wielding-grunts (known as the Combine) armed to the teeth should anyone step out of line. It's part Big Brother, part Matrix with Eastern European architecture lending the setting an impossibly beautiful backdrop almost totally at odds with the climate of fear that perpetually pervades the environment.

You start out, of course, in Los Santos as Carl Johnson - a twentysomething former Grove Street gang member returning to a less than enthusiastic welcome after five years in Liberty City exile. Soon it becomes apparent the game's much less of a clichéd Half-Life; it's about a low-down bum working his way up the crime tree, and far more focused on the ins and outs of gang culture, the relationships between the 'family' and restoring the gang pride of old. Soon, of course, stamping your authority on the immediate vicinity and taking out frustrations on the rival Ballas gang becomes the priority.

Although this is 'the future' we're dealing with, it's a more realistic vision of the future, blending the more pleasing elements of the architecture of past with the cold sky scraping steel monoliths of the future. This isn't A.N.Other Blade Runner rip off, with neon skylines and hover vehicles. It's something distinctly fresh, and believable, all rendered with craft, life, logic and intelligence. If the devil is in the detail, then Half-Life 2 is Satan in a party hat, kicking back with a beer and engaging his fiendish accomplices in a toast to the future. Cheers.

Ruling Los Santos proves to be an early highlight, and immediately sets the game apart from the other Half-Lifes by virtue of its focus on dialogue, narrative and constantly going that extra mile to set the scene - not just via the between-mission cut-scenes, but through regular colourful exchanges as you're driving, and all manner of banter during each mission. As a cinematic experience it goes to inordinate lengths to get things right, with a quite staggering attention to detail providing endless opportunities to truly immerse the player in a convincing environment where every character, every pedestrian feels as part of the day to day life as you are. Check out the huge roll call for the pedestrian voice actors to see the crazy lengths Valve has gone to make sure the ambience of the environment matches up to the quality on show elsewhere.

The moment you start wandering the game's first locations a feeling of arriving somewhere special kicks in and barely lets go until the credits roll 13 chapters later. As if to deliver a cheeky nod about being in a new playground, Valve even drops one in the game's opening location, almost entirely pointlessly, other than to remind us all that's what this is all about. It's not about re-inventing the wheel, but pimping up that wheel with spinning hubcaps, bass boxes, neon strips and gadgets that would humble even Bond himself.

Once again the voice acting and radio stations are simply incomparable to any other game out there. If anything, the musical variety is even greater than before, drawing on a greater diversity of genres, ramping up the DJ humour to almost genius levels of parody and providing an excellent template for the game that no other game has yet to come anywhere near close to matching. Even after 40, 50 hours, you're still hearing fragments of dialogue, spoof adverts and songs that you've somehow never heard. It's the sort of thing you'd be happy to pay money for on its own; that it's such a throwaway part of the game just goes to show how far Valve is willing to run with this excellent concept. Sure, the music won't always be to your taste, but somehow in the context of what you're doing it all fits, so you don't mind while the truly cringeworthy "All My Exes Live In Texas" or "Queen Of Hearts" play for the third time that evening, or, if you do, flicking to another of the ten stations is but a mere D-pad nudge away.

But Freeman is no double-O. If anything, he's the most personality-free zone in the history of gaming. Once again he never speaks, you never see him (not even so much as a reflection) yet everyone greets him like the ultimate living legend. Not bad for a "man of few words". If he ever uttered a thing our hearts would probably stop with the shock, but somehow the game gets away with pulling the same silent narrative trick of the original, engaging you this time with characters of far greater emotional depth than any FPS has dared to venture. All of this comes, as the original pioneered so successfully, from a combination of scripted set pieces that you watch silently unfold and various events that kick off with your arrival. By necessity and by design it's another story-lead on-rails shooter, and can only stray outside of those barriers to a minimal extent. To some this may come as a slight disappointment when it transpires that there is generally only one way to solve whatever your current dilemma is, but where Half-Life 2: San Andreas succeeds beyond any doubt is in its ability to consistently and repeatedly create richly diverse and believable environments that enrapture the play experience with a suspension of disbelief that makes the thrill ride just as enjoyable as we expected to be.

And as if the pedestrian voices and DJ scripts aren't enough, you get hit by the likes of Samuel L Jackson and Chris Penn making you realise just how good and how compelling gaming narrative can be when you're prepared to hire the right talent for the right price. The constant swearing might not be to everyone's taste, but when you've got a Valve game about hardcore gangsters, what does the audience really expect? In truth, some of it does veer a little into the realms of shock for the sake of it, and the way certain characters flit in and out of the storyline doesn't always make for a coherent, logical plotline, but for the most part they're enjoyable, amusing, and energetic, and a lesson to many publishers as to not only use as a plot device, but for pure entertainment and reward for the efforts you've put into playing some often intensely challenging missions.

Just like any game there are high points and low points, but when you bask in the warm glow of completion there are so many high points to recall it seems almost pointlessly pig-headed to find serious fault with what you've just experienced. If you can seriously come away from Half-Life 2: San Andreas disappointed, then ask yourself which first-person shooter is better, and why? For the vast majority of us, the overwhelming emotion will be the pure joy of having experienced something that sets new high marks in so many areas as to reaffirm your belief in the ability of game developers to push things forward.

Review written with edits under fair use provisions. Please refer to here and here for original material.

Review: A.R.M.A. II

It turns out, ten hours into Arma II, that everything great about the single player campaign I've experienced so far can be found in the demo, as well as most of the terrible parts. The terrible parts almost entirely consist of attempts to script parts of the game engine - hilarious scenes where you are liberated from capture, but your guards don't react to the flash bang attack and silenced bullets to the head until their walking animations finish playing some ten seconds later; or you encountered villagers on the road arguing about the invasion and then drive through them like a ten pin strike on your return.

And this attachment to your fellow stalkers forms early in the game, possibly at the first encampment, where other loners gather on the edge of the Zone, unsure of whether they'll move inside or stay here as outsiders. The black marketeer you start out getting missions from seems less enamoured of humanity: he points out the in-game stalker rankings and suggests you can work yourself the way up the list, perhaps by shortening it a little. He gives you assassination missions - I accepted the first, and then didn't have the guts to go through with what seemed the pointless murder of one man among many.

The great parts involve pointing your sighting reticule at a ten pixel high man a kilometer away and clicking the mouse button to make the clump of pixels fall over. It is impossible to describe how rewarding this experience this is without including the Herculean effort required to get to this point: the monotony, the battle with the overburdened control scheme (which makes perfect sense and is easy to use once you master it), the graphical and AI glitches, the lack of foreshadowing which allows you to blunder into the enemy and spend the entire firefight writhing on the ground in a pool of blood, the poor check pointing and game design which makes you wonder if you're doing the sensible thing at all. Arma II highlights the importance of authorial intent in games: not in the sense of a scripted roller coaster providing a guaranteed quotient of fun, but in the sense of 'am I doing the right thing traveling 15 real world minutes in this direction or am I just wasting my time?'. Ironically, for a game which needs this direction more than most, there is an incredible paucity of walkthroughs and FAQs on the Internet.

What keeps you attached is the relentless and inhospitable nature of the zone. The mutated beasts that roam it, and the anomalies that sparkle in the twilight. Existence is fragile here. And the world is alive and continuously changing. If you confront the pack of blind dogs, they're as likely to surround and savage you - no matter how powerful the punch your automatic weapons pack. But if you leave them alone, you'll come back to find them chewing on the body of a fellow traveller. And when you find a scoped rifle, you can watch the pack sit and play in the distance, animals to the end. Guilt grows until every encounter becomes a mess of indecision.

The first five seconds of any time you move is also great: the incredible fidelity with which your interaction with the environment around you, crawling through grass, peering around a corner, running to cover, the squeak of your rubber boots as you start a forced march, the way the grit and dust accumulates on your wind shield. The problem is the 15 minutes following those first five seconds during which you continue to crawl forward, run in a straight line, drive while staring out the tiny view port of a LAV-25, the blur of Eastern European villages and fields and meadows and forests. Especially if it's the indeterminate wait while you lie bleeding out, while the bodies of those colleagues trying to heal you accumulate around you. If this is an accurate simulation of war, then it must be even more terrifying than I suspected.

I avoided the bandits who shot at me unprovoked and bypassed the military under the bridge while they engaged in a fire fight elsewhere - but murdered my way through a checkpoint into the second zone area. I had to progress; and there seemed no other way. Then a distress call: some of my fellow stalkers were in trouble in a junkyard. A bloody and messy close encounter in which, submachine gun ammo depleted, I had to engaged point blank with a sawn off shot gun and pistol. The grass became strewn with bodies between the wreckage of old cars. I was angry that I'd been forced to this pointless existence.

Arma II has one innovation that makes it stand head and shoulders above any other open world game: you can get someone else to do the driving. Bring up the map, press space bar and click, and (provided you've marshaled everyone into the vehicle correctly) your driver will execute a ten point turn and then smoothly drive you to your destination.

One of the bandits lay dying, groaning, cursing. I aimed down the pistol at him. Damn you for this. And shot him, unblinking.

(Based on others experiences of the game, I wouldn't trust a pilot to do the same).

It wasn't until later, presented with this option again, I reconsidered. Did everyone have to die? Everyone has a name here. A roll-call of stalkers, bandits, people, some suggestive of a history, a physical defect. It shows you the name when you loot the body, to remind you, under the gun sight when you aim. I looked down the barrell of my much improved rifle at the mercenary clutching at his guts.

Arma II is a awe inspiring accomplishment of a game; but one which needs the camaraderie of multiplayer, the tyranny of others to share your miserable, muddying experience on the battlefield. Find yourself a real person to walk you through the learning curve, in the same way that you could shyly sneak down to the local game hobby shop to learn how to push around miniature armies on hexagonal paper. Read Tactical Gaming Done Right to get excited about it, then reach out to some military simulation grognards.

The enemies: When you find an injured enemy, you are not given a choice. You cannot talk to him, heal him, help him in any way. If you walk away, he'll die. You can't loot the body while he's alive. It becomes a trade-off. Guilt, as the blood spatters and the body twitches and rolls. No one carries much here: vodka, some sausage, anti-radiation drugs. The price of a life. But if you walk away, his cries follow you, pleading, angry, alone.

Decisions.