Often we invent games by taking an existing game that works and adding a twist to it, or changing some aspect of its behaviour or theme to something different. But how would we create a game from nothing, without using an existing game as a framework? In particular, how do we make the game complex enough that it’s not trivially ’solved’? (Set aside any game where the physical skill aspect is a significant component, or games with few or no choices where strategy is typically not intended to be a factor such as Candyland or Snakes and Ladders.) I find this a very difficult problem, but to make a start on it requires some appreciation of what makes a game interestingly complex in the first place, and the tools we typically use to create this complexity.

Generally it would seem that most games we play can be described using the extensive form notation from game theory. It’s not as intuitive a representation for individual or simultaneous decisions as normal form notation is, but extensive form captures the important notion of each move opening up a new game state and new possibilities. For example, in Chess there is a single starting state, but that branches out to 20 possible successor states, and from there, the tree branches further to 400 states, and so on. I would suggest that the complexity of the game in terms of how easy it is to ’solve’ it or to come up with the best strategy is closely correlated with a player’s ability to understand this abstract tree of game states. If “a game is a series of interesting choices” as Sid Meier has said, it’s the player’s ability to understand the ramifications of those choices that matter, which is to say that they need to be able to predict to a certain degree the effect that they will have on the tree of game states. If the choices are too easy to make, they’re not interesting, and if you can’t see that some choices are clearly better than others, again it is uninteresting.

With that in mind, it seems that we embody this essential complexity in our games in a small number of ways:

• A combinatorial explosion of discrete state spaces. As noted above, the game state tree for Chess has 400 possible positions on turn 2, and a branching factor of of about 35 on average for successive moves, making an exhaustive study of the possibilities impractical. Therefore you have to plan more generally, making an estimate of which moves are good and which ones are bad and deciding which part of the tree to look at and which ones not to. The high branching factor means that even Chess computers need to do this via something like alpha-beta pruning. A common way in which we can create this large number of possible states while keeping the game easy to understand is to use an abstract game board, as in Chess. A 2D grid gives you an easier way to describe and reason about the state changes while keeping the quantity of options high. Compare the rule “Rooks can move vertically or horizontally as many squares as you want without jumping over another piece” with “A rook at position 1 can move to positions 2, 3, 4, 5, 6, 7, 8, 9, 17, 25, 33, 41, 49, 57. However it cannot move to position 3 if position 2 is occupied, nor position 4 if positions 2 or 3 are occupied, nor… (etc)” Being able to bring prior knowledge of Cartesian coordinates and the notion of adjacency and straight lines helps simplify many possible state transitions into a much simpler rule.
• Hidden information. Typically this takes the form of a player’s hand of cards, or the fog-of-war in a real time strategy game, or even the act of forcing players to move simultaneously and thus having to estimate what the other person will do. This doesn’t make the state tree branch out any further, but it does make it much harder for a player to know which branches can be safely ignored. Compare the choice to leave your Queen under attack by a Pawn in Chess against advancing one of your middle-ranked pieces into enemy territory in Stratego. In Chess you will almost always benefit from taking a Queen with a pawn unless moving the pawn puts you at risk, which is quite easy to check for, so it’s reasonable to assume that is the move you should examine first and in most detail, making the decision quite easy. In Stratego however you simply don’t know whether it’s worth attacking that piece unless you have managed to build up some information about it, so you will need to consider all your other potential moves in roughly equal detail.
• Random factors. Randomness is like adding a 3rd player to the mix – whereas you can predict the actions of the 2nd player (your opponent) as he will always make the best move that he can given the limits of his capabilities, the 3rd player (luck) will play unpredictably, increasing the number of possibilities you must consider, in a similar way to the hidden information above. Indeed, randomness is really just a subset of hidden information, but it’s worth drawing a distinction between the two because hidden information can be potentially knowable whereas random factors cannot. (Though keep in mind the middle ground, eg. of a shuffled deck of cards – towards the end of the game it becomes more deterministic.) Some people disparage random factors as bringing ‘luck’ into the game but really it’s just about risk management. For example, Civilization would be a much less interesting game if you knew that your Phalanx unit would always defeat an attacking Militia unit. Instead you have to balance the probabilities out. You have 66% chance of beating one, 44% of beating two in a row, 30% of beating three, so how many Phalanxes do you need to defend against 3 or 4 Barbarians, given that it’s mathematically impossible to mount a perfect defence? This poses an interesting dilemma for players which again forces them to consider a wider range of options as there is no obvious solution. Greg Costikyan has a great presentation here which shows the different benefits a random factor can bring to a game and it’s well worth a read.
• Continuous state space. Games that utilise physics engines and real-world simulations exploit this to create a wide range of possible situations from a simple set of mechanics. Arguably this is the most popular method used by games today to introduce elements of strategy and tactics to what are otherwise computer-based sports relying on reflexes. It is similar to the Chess rule system in that people have an inherent basic knowledge of geographical space and direction and indeed the laws of physics which they can bring to the game to help them reason about it. Yet the continuous and almost infinite domain in which entities can move makes predicting the exact results a difficult endeavour requiring skill and expertise. You can point a gun in an FPS in an infinite number of different directions, and can stand in an almost infinite number of positions when you do it, and the best combination of these two factors at any one time depends on your opponents (and maybe your team mates) who are constantly moving within that continuous space, as well as your understanding of the implications of the relative positions and orientations. These considerations may not immediately seem relevant to the typical turn-based strategy game, but they are – the same positioning and aiming mechanics, albeit on a simpler scale, exist in games like Scorched Earth or Worms, for example. You obviously no longer have a simple tree of discrete game states here, but from the near-infinite set of possibilities you have to mentally build your own game tree, and select your tactics based on that. When you examine a continuous domain you can pick out discrete areas within it which you can reason about – for example, in FPS games you might mentally divide the area up into rooms, areas in cover vs. areas in the open, paths between weapons or power-ups, and so on. Then you plot a route from one point of interest to another and also use such points of interest when deciding how to maximise your ability to attack someone and minimise their ability to attack you.

The end result of all these approaches is that instead of calculating the whole game tree in your head and calculating the correct flow through it, you have to look for patterns and use those to guide your judgement. Your basic skill at the game is essentially your knowledge of the game’s patterns, and the depth of the game is proportional to how hard it makes it for you to understand the full game state tree.

But there’s an interesting meta-game here too, because since you know it’s impossible to know the whole game tree, you know that your opponent is in the same position, and must therefore also be formulating his own patterns to judge the game and formulate his move. This means it’s worth trying to guess your player’s patterns also, and often that is of more use than to attempt (usually in vain) to find the optimal approach – after all, in any one situation you only have to do enough to beat your opponent, not to beat all possible opponents that could exist. (“Remember, when you and a halfling are being chased by a hungry dragon, you don’t need to outrun the dragon…”)

This post is long overdue, for which I apologise. I hope to resume a more regular service before the year is out!

There’s a post on Penny Arcade from a few weeks back which is complaining that a certain game Brütal Legend seems to masquerade as one type of game (ie. a Real Time Strategy game) while actually being something else (a third person action-RPG). The tone of the article is that games shouldn’t be mixing one type of gameplay with another, and the main complaint is that players have expectations of a game playing a certain way.

Personally, I feel this is a false problem caused by narrow-minded reviewers and fans. Games won’t get taken seriously until it’s accepted by both groups that they don’t exist merely to fit into pre-existing categories – although they certainly can choose to do so – but are individual creations and should be judged as such. There’s nothing wrong with genres as descriptive labels, as they carry a lot of useful semantics. What’s wrong is when they move from being descriptive to prescriptive.

Nobody complains that a film’s exact genre wasn’t explicitly specified before you watch it. Crossovers and variations are par for the course and often encouraged. Film reviewing and criticism moved past this single-genre categorisation long ago and a film’s entry on IMDB typically lists several genres for each individual film, reflecting the way in which different aspects are combined into each whole. Games should surely be seen in the same way.

Tycho at Penny Arcade should really know better and I am disappointed at his attitude, wanting to classify games as Either This Or That and not wanting people to experiment with crossover. Imagine if we’d thought that way 15 years ago. To paraphrase his quote towards the end of the article, “I love action games, but I don’t want to play an action game while I’m playing an strategy game”. Bye bye to the entire RTS genre then! Luckily, some people at the time noticed that although the strategy aspect did suffer a little, you gained something from the urgency of the action. And thus a new approach was born. Mixing a bit of this with a bit of that is how biology has improved species for millennia.

It’s arguable that in this case the tutorial doesn’t educate the player adequately and therefore gamers fall back to genre stereotypes, coming undone when they hit the boundaries of the metaphor. But it’s nobody’s job to explain a game in terms of other games or existing genres. If all games are to be presented and judged that way then we’re in for a boring future bereft of creativity where games can only borrow from within their genre to ‘innovate’ (if such a word could be said to apply). Cross-pollination between genres would seem to be frowned upon and God help those who might actually come up with a completely new game type. I don’t think that’s the future we want to see.

I recently made a post on this issue over at Gamedev.net, and thought I’d clean it up a bit to post over here, as I think it’s worth talking about. Designers are often looking for new and better ways both to create and present their design documents, and rightfully so. Just as programmers may try different languages, techniques, tools, and IDEs, designers should be looking at better tools and methods to allow them to capture their ideas, organise and prioritise them in a sensible way, and to present them to a variety of audiences, perhaps the most important of which during the implementation phase of the project being the programming team.

Our team used a Wiki for the current project, and while this choice carried several benefits, it also had several shortcomings. The positives barely need expressing to anybody familiar with Wikis – they allow collaborative work, ad-hoc reorganisation, easy cross-referencing, automatic outlining and table-of-content generation, built-in version-control, etc. Therefore I will expand upon the negatives. None of these problems are fatal, but it’s easy to fall foul of them without realising it if you’ve not used one before. So here’s what I learned from my personal experience.

Every page should be categorised. Use sub-categories if they make sense. In this modern world of tagging things rather than grouping them into hierarchies, or following Google’s “search not sort” mentality, it’s easy to overlook  the categorisation. Don’t do this! Otherwise there can be parts of the design that nobody sees. Nobody is going to recursively click every single link in the document, nor is anybody going to exhaustively read every page that is returned for any given search term.

Instead there should be discrete categories and anybody who needs to understand a certain aspect or feature of the game should quickly be able to see a clearly marked subset of the document that is relevant to them. Following from this, if you have a design team who are collaborating on the document it is useful if individual designers take sole responsibility for certain categories, ideally the features they designed or primarily work with. Each category should stand alone as a fairly complete sub-document, with external links existing just for reference. Otherwise you end up needing to be familiar with the whole doc to get anything done, which means you’ve lost most of your benefits over a normal linear document.

Be prepared to produce hard copies of the categories. Obviously this is not really an issue if you work remotely. But if you share an office, being able to print off parts of the document conveniently is vital. A hard copy is much more convenient to use in meetings, for writing notes on, etc. Nobody wants to be pulled into a meeting about Feature X when there is no possible way you can bring all the specifications for Feature X with you to refer to. And if you can’t refer to the documents, you tend to end up designing in parallel to them.  If you can’t print off part of the document, you tend to find that people start designing features outside of the wiki for convenience purposes. And you don’t want that because suddenly your design becomes ephemeral and ethereal – an email here, a JIRA/Bugzilla comment there, a note on a pad somewhere else, because everybody was writing without direct reference to the original document.

Ensure that pages can be locked against edits, and are when appropriate. Programmers will follow the specification as closely as they can and will clear up ambiguities with the designers as needed. But the very nature of expressing s0ftware in natural language means that occasionally a designer will write something and the programmer will implement it in a way that fails to catch the spirit of what was written while nailing the syntax 100%. This is unfortunate but is essentially a problem that designers and programmers can work through, the designers learning to be more explicit and less ambiguous with their descriptions and the programmers learning to spot situations where this might be the case. A worse problem is when designers are free to work and rework their design during implementation. A collaborative document like a wiki makes this far too easy and tempting to do. Designers, wanting the best for the game and to provide the best service to the programmers, have a tendency to go back and ‘improve’ and ‘clarify’ their designs after you’ve already started or even finished implementing them. They think they’re being helpful or diligent, but actually they can cause a major discrepancy between design and implementation. Of course, in their head, the discrepancy was already there, but in the programmer’s head, the design has appeared to change significantly.  When this happens during implementation, it can be frustrating to the programmer and cause some work to be scrapped and rewritten. Worse is when it happens after implementation, and the first that the programmer hears of it is when the QA department find that discrepancy and file a bug against it, implicating the programmer for not following the design.

Once designs are given to the programmers to work on, lock the page, and force future amendments to go through an approval process. The history and revision control feature is not enough for this. QA are not going to rigorously compare the coder’s source control commit times to the designer’s wiki revision history when noting a discrepancy between ‘The Design’ and ‘The Implementation’. More than the others, this is a management issue rather than a technology issue. The same problem could conceivably happen with any design doc. However the wiki technology makes it much easier to make little adjustments here and there without anybody noticing until the damage is done.

Ensure that all pages have one owner. A good design is often a big design. In Wiki terms this can mean tens or hundreds of separate pages. As the project moves forward, some features grow, some shrink, some are removed or replaced entirely. Obviously all these changes should be signed off with the implementors as mentioned already, but then the document must remain up to date. On a regular basis coders and QA staff will use the wiki as a reference, sometimes going back to a page they’ve not used for weeks, or using the search functionality to uncover the relevant page. What is critical therefore is that what they find must be relevant and pertinent to what they’re working on. Otherwise their time is wasted: at best, they have to search again (and again), and at worst, they take some action based on this outdated design which wastes their time and potentially that of other people too.

For this reason, every wiki page should be owned by a person on the design team, and that someone should keep the page updated in sync with any changes made to the design so that the information is always correct. If you have the information categorised adequately then each category can have an owner and this becomes quite simple. But without someone being accountable, it’s assumed that someone else will keep it up to date, and this won’t happen because nobody will exhaustively check every page to see if any are out of date. If it’s not practical to have a single owner for a feature or category (as might be the case if it is being co-designed by 2 people, for example), designate one of them as having responsibility for the wiki pages.

Be disciplined regarding scratch-pad, discussion, or brainstorming pages. Wikis are a good middle ground for discussing and evolving a design. They are more convenient than email in terms of having all the information in front of you, and less time-consuming than meetings where all but one person is doing nothing but listening. Unfortunately this means that the game design document can end up with annotations, discussions, vague ideas, and other noise scattered in among the signal.  This can make it hard for programmers to see what is the agreed design and what was just discussion and ideas relating to the topic. Sometimes the problem is in the other direction and key design decisions are left stated in these discussions and not migrated to any clear specification area.

Use a separate namespace if your wiki provides such a thing to keep the normal searches free of this noise. The MediaWiki ‘Talk’ or ‘Discussion’ pages are a good way to handle this, leaving the main pages with the official docs. At the very least flag the page with a big disclaimer message or template that quickly tells programmers or QA that the content of this page is not gospel and is subject to change without notice. Designers should migrate authoritative information from these pages to the proper specification pages as appropriate.

Hopefully that is all useful to someone!

Apologies in advance for the length of this entry; there’s a short summary in the last paragraph if you’re pressed for time!

A few weeks ago, in a moment of extreme boredom, I stopped to watch the snooker player Stephen Hendry score the maximum possible ‘break’ of 147 points. (13 minute video.) Snooker is not the world’s most exciting sport unless you are a devotee, and I am certainly not a devotee. Yet with my game designer hat on, the game of snooker and the way Stephen Hendry had to play to achieve this score both become quite interesting on an abstract level.

Compared to most computer games, it’s very simple in terms of mechanics. To borrow one of Chris Crawford’s elements of terminology, it only has one ‘verb’ – use the cue to hit the white ball at coloured balls, with the intent of ‘potting’ the coloured balls in one of the six pockets. But then several rules come into play based on which balls you hit and where they end up, dictating the score you get and whether you get another shot or not. Strategies naturally emerge from a player’s awareness of the rules, balancing need to score points with the desire to deny the opponent points. eg. by playing safety shots. Yet this all comes about when there is only one significant way to interact with the game. Compare that to first person shooters for example, where you often have several different types of weapon (allowing typically for both direct and indirect fire), consumable items for health and defence,  different stances/poses/actions to cross obstacles or use cover, and so on. RPGs are perhaps even more full of verbs; you might have melee combat and ranged combat methods, spells you can cast, items to pick up, potions to drink, people to interact with and talk to, horses to ride, maps to view, etc. These games are all well and good but it seems apparent that we can stand to learn something from examining how just 1 action can produce interesting gameplay.

Probably the main thing to take away from the games like snooker, pool, billiards, etc., is that the main action can be applied in slightly different ways to vary the outcome – adverbs, if you will. Choosing the direction to hit the white ball in is like choosing who to shoot at in an FPS, but you also get other choices here. You can attempt to hit the ball harder so that it travels further after hitting the second ball. You can also apply spin to the ball, making the white ball change direction after contact, or even sending it on a somewhat curved path in the first place. Such choices are too often absent in video games – you choose who to punch or to heal or to send a magic missile towards, but often the choice begins and ends there with the ‘what’, having no say over the ‘how’.

It’s apparent that once a player gets good enough to pot the balls quite effectively, they have to start planning ahead and looking to how they can not only pot a ball, but make it easier to pot a subsequent ball. Again, this is where the adverbs come in and the player will apply force and/or spin to attempt to not only pot the coloured ball they’re aiming at but to position the white ball effectively in order to pot the next. But there are trade-offs here, since hitting the ball too hard or with spin affects accuracy, and hitting it too softly might mean the coloured ball you’re attempting to pot doesn’t reach the pocket at all. You have to compromise your current shot a little in order to hopefully benefit your second shot a lot; but if you compromise your current shot too much, you don’t get that second shot.

A classic game from the 80s that had an aspect of this was Laser Squad (play it online here), forerunner of the X-Com games. A simple turn-based tactical squad combat game, you move soldiers around and shoot at each other. But when you shoot at somebody, you get a choice of either an aimed shot or a snap shot. The aimed shot is more likely to hit, but the snap shot takes less time and therefore gives you chance to shoot again or find cover. You had to weigh up which was most worthwhile, taking into account how many successful shots you thought you’d need to take down the opponent, how their distance from you would affect the chance of hitting them, how much ammo you had left, and so on. You knew you wanted to shoot the enemy, but there was an interesting choice in how you went about it.

Like many other abstract games such as chess, you can plan several moves ahead in snooker. But the combinatorial explosion in snooker is continuous rather than discrete and you never truly know exactly where the white ball is going to be for your next turn until it stops. This is an interesting property of any game that models physics, a system that is understood by players well enough to make broad predictions easy but exact predictions almost impossible. This allows for a sliding scale of competence as players get better at judging the outcome of their actions without there ever being a point of total mastery. (I hope to elaborate on this sort of gameplay aspect in a future post.) Games like Armadillo Run and Crayon Physics are very literal examples of this sort of mechanic, but there can probably be more subtle examples too.

Snooker allows for the possibility of combinations (4:38 to 5:14 in the original video) where you involve more than just two balls in the action, typically bouncing one coloured ball off another to pot one of the two. This is generally a more risky shot but sometimes is the only one on offer, or perhaps offers a potentially greater reward if successful. This sort of mechanic is a bit more common in video games, especially in fighting games where explicit combinations are very common, often giving you the opportunity to score more damage but taking longer and exposing yourself to more risk in the process. But it’s rare to be in a situation where you absolutely need to pull off the special move, and more often it’s better to keep it simple when losing. Would games be more interesting if occasionally you were effectively compelled to use the high risk, high reward strategy on occasion? The infamous decapitation attack of classic 8-bit fighting game Barbarian might not go down well with modern players who have little tolerance for such a severe penalty for making one small lapse of concentration, but in a player vs. environment game where the NPCs lack such fragile egos it could be an interesting and rewarding way for a player to snatch victory from the jaws of defeat.

Another interesting aspect I noticed in the snooker video was that the fact that the pink ball was not in the prescribed place on the table was considered quite important. Due to the standard initial layout and the routine of returning coloured balls to their spots, snooker players get used to balls being on their initial spots most of the time. A similar phenomenon could be observed in some first person shooters where the spawn location of weapons and health can form a crucial part of a player’s route around the map. But just as a good player must know how to play the pattern and get from one such point to another, they must also avoid being a sitting duck if the powerup has already been taken or the position is occupied. Expressed as an explicit yet abstract design mechanism, this is setting up a distinct pattern that is visible to players, while allowing it to vary. This gives players several levels of mastery; first, they learn where the items are; second, they learn the optimal routes between them; then, they learn how to improvise if something isn’t where they expect to find it or find it too heavily guarded, and so on.

Finally, snooker’s concept of a maximum break relates to the metagame. Once Stephen Hendry had reached 80 points, he had effectively won the game due to there not being enough points left for the opponent to catch up. Technically, it would be possible for him to lose, should he commit enough fouls that award points to the opponent, but in practice such an occurrence is rare enough that the current frame is usually conceded by the opponent once this stage is reached. However, in snooker it is common to play on until the current break finishes, even though the eventual score has no effect on the game in hand. Prize money was at stake here for getting a maximum break, and further cash is available to the player who scored the highest break of the tournament. Yet in actual terms of the rules the score in each break is essentially irrelevant. Something similar can be seen in things like secret areas in 3D explorer-shooter games, tracking how many kills in a row you have in Unreal Tournament, or seeing how far through Thief you can get without being seen at all. All these aspects sit somewhat on top of the game proper, but provide for an extra view on the same gameplay.

One interesting aspect of the break in snooker is that the score is largely independent of the quality of your opponent. This makes it relatively meaningful to compare them no matter who you play against. Computer games with a similar mechanic could have an online high score table, providing the score is accumulated against a standardised opponent or in a system where the opponent’s strength is less important. This takes the player beyond the individual game they played in and adds them into the set of all gamers who play that same game. This adds the asynchronous multiplay aspect that people like Ian Bogost talk about, and which seems likely to grow in popularity via web-based systems such as Facebook and Twitter. (This was done quite well in the form of play-by-mail games in the past, so it will be interesting to see if any of the techniques used there make a comeback.) XBox achievements work along much the same lines. And TrackMania is an example of a game that provides the typical synchronous multiplay when you race other players, combined with an asynchronous aspect in terms of the local and global rankings that persist from race to race.

All this suggests to me that a lot can be done with just 1 game mechanics. Although adding in extra mechanics and observing the varied dynamics that emerge from their combination is a perfectly valid route to adding interest to a game, more can be done with individual mechanics. Find some ‘adverbs’ to allow the player to make some risk/reward tradeoffs, possibly buying future success with increased risk now, or vice versa. Make outcomes understandable but not trivially predictable so that players can make plans and learn how to anticipate the outcomes. Attempt to provide ways in which the mechanic can be re-used or combined to offer high rewards or a difficult escape route out of a dead-end situation. Set up patterns and predictable situations that players have to learn, but vary them on occasion so that adaptability and resilience to change is a useful skill that can set the experts apart. And see if it’s possible to add some sort of scoring system that sits alongside the game, not necessarily influencing the gameplay directly, but providing metrics that players can choose to compare themselves on, adding interest and replay value.

I may as well open the writing here with a fairly weighty topic! Comments welcomed.

In recent times there has been growing recognition of “games as art”, a term which is necessarily as vague as the wide scope of “games” and “art” allows, but which tends to evoke very specific images. The mainstream games industry tends towards heavily simulation-based 3D games with increased levels of fidelity in terms of rendering, sound, and animation, and ever-increasing amounts of ‘content’ (ie. art, sound, maps, writing, etc.) that the player gets to experience. ‘Art’ games by comparison are inevitably more modest efforts, often rendered with primitive technology (by today’s standards) and have minimal consumable content (where content could mean ). And rather than marching towards increased realism, often the game’s presentation and/or purpose is deliberately abstract, at least in part, and it falls to the player to find the meaning in it. Often there is a creator’s statement, typically designed to be read after the player has played the game and attempted to decipher it for themselves first and to add further elucidation on the developer’s influences and intentions in creating that game.

Probably the most famous examples of this are Rod Humble’s The Marriage and Jason Rohrer’s Passage and Gravitation. These can be enjoyed in as little as 10 minutes each and fully appreciated in a few moments more, after reading the author’s notes on each game.

In a time when games are generally assessed based on their content – eg. how good the story is, how interesting the maps are, how smooth the animations look – it’s good to see games being appreciated in a way that gets right down to the essence of the game rules. The ‘art’ in other games is the content and the game the delivery mechanism for you to enjoy someone else’s world or their story. But the messages these games are carrying are conveyed in the way that the way that the player actually interacts with the game mechanics – gaming in its purest form.

However, these messages are not actually intrinsic to the game mechanics, but come from metaphor, via the references to real life that the mechanics evoke. They’re the gaming equivalent of the abstract painting or formless sculpture that means little until you read the plaque next to it, perhaps transforming your perspective revealing an impressive interpretation of the subject matter. But sometimes, it instead spells out a rather far-fetched justification for what appears to be an aimless or uninspired work. (Does a preserved shark in a tank take on new meaning when labelled as ‘The Physical Impossibility Of Death Tn The Mind Of Someone Living’? Some say yes, some say no.)

It’s great that we have games that can actually mean something and can make you think. But in these examples, the game is more the medium than the message, a way to draw your attention to a subject outside of the game. It’s not so extreme as the case with a story, where the story can be delivered by game, by book, by film, by epic poem, by any number of means, and yet maintain its core features – the game is an integral part of the experience in works like Passage and The Marriage and can’t be easily extracted without removing the message too. But can game mechanics ever be appreciated in their own right, the way readers appreciate The Lord Of The Rings even if they accept Tolkien’s denial that it was a World War allegory? Charles J Pratt over at the Game Design Advance blog posed the key question several months ago: “what if [game] mechanics can’t create meaning or express anything on their own”? Lord of the Rings has intrinsic ‘artistic’ value in the same way that Michelangelo’s Sistine Chapel painting does or Tchaikovsky’s 1812 Overture does. It helps to know something about the Bible or the Napoleonic Wars when studying the cultural aspect of these works, but they’re not required to appreciate the beauty and artisanship involved. Can game mechanics exhibit similar qualities, and be widely appreciated even when they don’t represent a metaphor for something meaningful elsewhere in life, and on the other hand aren’t a vehicle for a traditional story that could have as easily been told in prose or film either?

Maybe one day the game balance of fictional combat units in a real time strategy title will be appreciated by non-gamers. Or perhaps the multi-layered control scheme for a fighting game will command respect, or the complex combat resolution rules and modifiers in a turn-based role-playing game, or the fealty and alliance systems in a massively multiplayer online game. Creating each probably requires a bit of vision, a bit of experimentation, and a bit of plain old effort, the same qualities required when writing a book, directing a film, or painting a landscape. But we seem to be quite some distance from seeing all these things in the same light.