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.

Something interesting happened today. For a couple of years, myself and colleagues had mulled over a certain ‘killer feature’ that we wished our networking layer had, as it would have made our time implementing gameplay features much easier. Today, while doing some long awaited R+D work on said layer, I found that feature. The sheer size of the codebase meant that what we’d wanted for years had lain dormant and undiscovered all that time.

In actual fact, its only call site was commented out with a note saying that it was too slow to use in practice, but I have a feeling that it could have been easily optimised and saved us man-months of work.

Why hadn’t we found this before? Well, it’s a very large code-base and most of the people who originally developed it are long gone. Unfortunately there was obviously not much time for or interest in documentation back when it was written, and we’re too busy making actual games to be able to invest time in checking all these low level components which already work.

I see a couple of lessons in this:

• Enforce documentation as company/team policy. When the brains behind the code are no longer at the company, that’s when you need documentation to replace that lost knowledge. Unfortunately it’s too late to write it then. Designate a proportion of a coder’s time to documenting their code, so that an equal or greater proportion of some future coder’s time can be saved. (Failure to do this also results in scheduling problems, where some future coder is expected to perform a task as quickly as the original coder did, despite lacking the insight into the code that the first person benefited from.) I know it’s hard to sell documentation time to a publisher or whoever, but I’m sure that many projects lose more time from problems that arise when coders don’t fully understand the code that they’re working with.
• Write less code. Sometimes, documentation just isn’t going to happen, or is inadequate, or whatever. One way to mitigate this is to write fewer lines of code. The fewer lines of code you have, the less likely it is that there are large areas of the codebase that nobody looks at or understands. It also brings reliability benefits – if you halve the number of lines in your code base, it stands to reason that each file, function, and line gets read twice as often on average, and double the eyes means more of the bugs get spotted. Cutting the lines of code may not be easy to do, but most codebases have some duplication they can lose. In C++ templates and polymorphism can do a lot for you here if you think ahead rather than resorting to copy and paste. If you’re lucky enough to move to a higher level language then you get this benefit for free, since most are far more concise than the equivalent C or C++.

There are interesting implications for team size, too. To reduce the risk from lost code knowledge, you ideally want a lot of coders, and to rotate them round several subject areas. This way, knowledge is spread out redundantly and the loss of any one coder should not impact the general understanding of the system. On the other hand, large teams start to incur prohibitive communication costs, where documenting and explaining your modules can end up taking longer than creating them. And rotating people around areas of the code tends to reduce code quality, both through making people less concerned about defects in their code (since they may never have to touch it again), and through not being able to become an expert in a certain area.

You need enough programmers to be able to develop the required system in the timescale available, but too many and you’re going to have dark corners of your code base that few will understand and they can actually cost you time. It may be that there is an optimal number of programmers that can work on any given software project. Does it vary according to the programming language in use? Or maybe according to the type of software being developed?

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!

Sorry for not updating recently; real-life has been a bit busier than usual and I’ve had little time to ruminate on game development of late. But then this was always going to be a sporadic endeavour rather than a regular column so have patience! I’ve plenty of posts drafted up, they just need editing and finishing off.

Until then, a note on the length of time required to enjoy or complete games today. Personally I love RPGs, and especially those permitting a large degree of freedom for exploration such as Oblivion or the Might and Magic series. Even with more linear games I tend to have a cautious play style, spending 30 minutes on Doom 2 levels that had a ‘par’ time of 2 minutes, spending 8 hours on Thief 2 levels that others finished in 1, and so on. Recently I clocked up my 200th hour on Oblivion, and although I am tiring of it somewhat, it still holds a lot of interest and novelty to me at this point. Strangely, the time I spend on these games far exceeds that which I spend on explicitly ‘replayable’ games, such as Sid Meier’s Civilization, TrackMania, or any number of RTS games.

Anecdotally it seems like many people, perhaps older gamers, seem to want shorter and more focused entertainment these days. Is this just because they have played so many games and have less tolerance for obvious filler content? I’ve watched young children play certain platformers where they’ll happily try the same jump 20 times before they get it right, while I would probably have lost patience before half that many attempts. Or is it simply because older gamers have more free time to spare and they would rather see more variety and experience more victories in that time than playing one very long game would allow? It certainly seems the case that the industry is providing us with such games – And even when playing time isn’t decreased, the play area has shrunk and traded wide expanses for fine detail – compare Oblivion’s world of 16 square miles to Daggerfall’s 62, or look at the tiny compartmentalised levels in Thief 3 when compared to the sprawling cityscapes in Thief 2 such as the ‘Life Of The Party’ mission (the size of which which even this speed-run manages to portray effectively).

How does this trend for shorter games compare to the hours sunk into MMOs like World of Warcraft? Those of us who grew up with MUDs will recognise that this phenomenon doesn’t necessarily come from the presentation values, which in MUDs were almost non-existent, or even from the quality of the game design, since most MUDs gave you the equivalent of a text adventure with the worst parser since 1982 and an unbalanced version of the Dungeons and Dragons combat rules. Was it almost entirely from the socialising and the exploration factor? Maybe the combination of the two? (Brian Green has some thoughts on the relevance of different player types in a post made a couple of years ago.)

As much as I love long games, I know I could enjoy so many more if they were quicker to complete. I currently have over 30 games installed and which I play to a lesser or greater degree, but the 2 I spend the most time on being Deus Ex and Oblivion. These preclude me from making much progress on some other games (Bard’s Tale 2, Fallout, and Football Manager 2005 to name three that I’ve put on the back-burner for now) since the longer narrative driven games require a certain degree of attention and continuity. It’s easy to forget where you stashed some equipment or which NPC you meant to talk to next if you only play the game once a month, for example. So I suppose that is the downside of the games that are more demanding of time. Modern games are getting better at maintaining this state in the game for you – both Oblivion’s and Deus Ex track your objectives for you, whereas I have reams of hand-drawn maps for the Bards Tale games – but there is only so much they can do without giving you an in-game notepad which you scrawl notes into when you save and quit for the night.

What’s your preference – short play times or longer? Do both essentially give you the same value for money, and the payoff for your hours invested? Do you feel cheated by a game that ended all too soon, or by apparent filler put in to space out the content?

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.

Welcome! Within this blog I hope to cover a variety of topics related to computer games and their development, which is likely to include the following areas at a minimum:

• Critical reviews of games as I play them (most old, some new), steering away from focusing on presentational aspects and more towards abstract game systems and overall aesthetics;
• Implementation considerations relating to computer game development, typically regarding tools, libraries, and programming idioms;
• Use of languages other than C++ in game development, especially Python, but potentially others including Lua, Javascript, C#, PHP, ActionScript, etc;
• Artificial intelligence algorithms and techniques as they relate or could possibly relate to games;
• Game design concepts, typically in the genres that interest me most such as role-playing and strategy, but hopefully with wider application;
• Procedural generation of semantic content and other methods of reducing the spiralling cost of content creation;
• Wider industry issues such as working practices, social issues such as the “do games cause violence?” debate, and perceptions of games and gamers in the media;
• …and the obligatory discussion of issues raised by other ‘bloggers’ in similar areas as they arise.

I apologise in advance for the wide scope here, but I hope in a way to show that a wider view of game development is beneficial compared to specialising in one or two key areas, and that an understanding of both programming and design is necessary to make the most of the medium and the development process.