This week, I died in Minecraft. This may sound a small thing to those of you used to dying over and over again in these cubic worlds, but for me it came as a shock, a disturbing act of violence against me. It was unexpected because I play - and have done now for over a year - on Peaceful. And partly because of this, I have made dying a big deal, something I had strived very hard to avoid. But like many deaths outside digital worlds, this came from nowhere, an unexpected accident that ended my (fictional) life.

The problems had been brewing for a while. Lag had become especially problematic when riding the rails of the elaborate mine cart network other players in this world had built, crossing great spans of the landscape in jerky, unpleasant motion. The world gad been occupied for months, although I'd not had much to do with it since I finished constructing our castle. Although my early Minecraft days were spent mining and exploring, I had long since settled into building as the source of my enjoyment, but since I also wanted to role-play (as much as is possible in such a game) it had to be Peaceful not Creative mode. I'd become comfortable in the world, willing to venture out on map-making expeditions and the like. The lag and crashes were irritations, but I hadn't thought of it as costing me anything but time until this fateful day.

I'd been thrilled to discover a sea coast to the far north of the castle, as our world had been terribly landlocked for me. Eagerly, I got my boat out of the inventory and set sail for a nearby island, map in hand. Then it hit me. A bubble of distorting lag, forcing me to quit out and rejoin. In the world, I'd been thrown from my boat, which drifted back and forth not far from me. I paddled over. Then the second burst of lag struck, this time crashing the game and sending me back to the desktop. Sighing, I restarted the client and returned to the ocean. I didn't know it, but it was already too late.

When I rejoined the world, I was at the bottom of the ocean. I half heard over the players' voice channel something about me dying, but I thought I'd misheard. But when I'd finished swimming up to the surface, I found it would not let me back in my boat. I thought it was just another problem with lag - until my screen was replaced with the simple, stark message: 'You died'. I was stunned... I'd drowned? From excitedly setting sail, to gone forever. One of the other players urged me to respawn and chase after my stuff before it disappeared, but I was still in shock, and besides I always hated that DikuMUD corpse run experience, now associated more with World of Warcraft than its origins. Anyway, there's only 5 minutes to do so before every trace of your life is gone forever, and it had taken me ten minutes to get where I was. I had to face it - I was gone.

The other players carried on regardless as if nothing had happened, exploring underground, dying sheep. My death meant nothing to them. After all, I'd just respawn and wake up in my cosy bed back at the castle, right? But I could not bring myself to do so. Respawning, this death really would mean nothing. But I needed to grieve for this lost soul, this builder of turrets and libraries, this timid cartographer. How could I do that if I just remade the digital flesh from virtual clay, made a clone oblivious to the fact - the terrible fact - of its death by misadventure.

I do not play games with permadeath happily, but here I faced an odd choice since I could choose death, permanent death, and be gone from this world save for the monuments and follies left behind. This felt right to me, it felt like the only way to honour what had happened, even if it meant leaving Minecraft, perhaps forever. For all that I have enjoyed and respected the game, it had always been a little too thick with its play - it could not match the genuine joy I felt wandering around Proteus, and the appeal of multiplayer had fallen once it became apparent that we were just playing in the same sandbox, and only barely playing together. I need more than that. Certainly more than the recently added experience system could provide - the game moved ever more inexorably closer to the Dungeons & Dragons/World of Warcraft legacy, away from the likes of The Sentinel or MUSEs.

So I died in Minecraft. I died, perhaps forever. While the others carried on as if nothing had happened, I loaded up Noctis and began my exploration of a vast and spartan galaxy. A new life, new worlds. Will I go back? Perhaps, I cannot tell if my time with this game is over, but I know I must grieve for this fictional being that died in a terrible seafaring tragedy, sucked down to the briny depths by a vortex of other-worldly origins. Farewell, you blocky worlds! You will always remind me fondly of my own Play with Fire, and what I had always hoped that might become. For now, however, I had died in Minecraft, and I was both dead and gone.

Although videogames are strongly associated with themes of war and violence, the cutting edge of the artistic exploration of imaginary worlds is happening under peaceful regimes. In this piece, I examine four different regimes of play (War, Challenge, Puzzle and Peaceful), their brief history, and their essential nature.

One of the many intriguing observations in Sheri Graner Ray’s Gender Inclusive Game Design is the report that young boys, when asked to come up with a game concept, almost always suggest something involving violence and death. This male bias towards martial themes has infected the digital games industry for many years, to the extent that it has often obscured another male proclivity, the preference for challenge. If we accept puzzles as a form of challenge, it was a considerable number of years before videogames offered an entirely different approach to play – the opportunity to play in complete peace. These overarching ways of organising a game are what I am terming the regimes of play, and for the purposes of this piece I’ll consider four such regimes, although in practice many different divisions could be drawn.

Firstly, War, which describes any violent regime in which the player not only kills but risks being killed – Space Invaders or Defender, for instance. Characteristic of the War regime is the use of weaponry, usually (but not always) some kind of gun. As I have discussed before, the gun is one of the dominant representative forms in the contemporary digital games market. The War regime is so quintessentially ‘gamey’ that it is easy to forget that the most successful digital games have not been under this rubric – Tetris, The Sims, and so forth represent no weaponry at all. Nonetheless, this regime appeals to the core male audience for games, and there are many successful franchises that utilise it. The prevailing trend, in fact, has been a move from operating within the War regime towards representing war simpliciter e.g. away from abstract space combat representations and towards actual 'real world' war – Call of Duty being the obvious poster child.

Secondly, Challenge, in which the player risks failure (which may be represented as death) – Pac-man or Pong, for instance. Under the Challenge regime, players may also expected to repeat tasks until they succeed – as in Donkey Kong or Frogger. Indeed, part of the balancing act that games face under the Challenge regime is how to balance the player’s frustration against their eventual success – set the bar too high, and few players will persevere. Set the bar too low, and many players will quickly lose interest. But when the bowl of porridge is just right, it’s a magic formula for success – as can be seen clearly in Angry Birds, which manages to play on the near-miss effect to give players the strong feeling that they can beat it with ‘just one more try’. In common with War regimes, any particular Challenge regime can lean towards being punishing or forgiving i.e. more frustrating versus less frustrating. The prevailing trend in the digital games industry since inception has been for increasingly forgiving games that still deliver challenge, and which have consequently reached out to an ever-wider audience.

Thirdly, Puzzle, in which the player does not directly risk failure, except by being too confused to continue. In digital games, the Puzzle regime is almost as old as War, being essential to all the text adventures and their descendents from Colossal Cave Adventure onwards. Under the Puzzle regime, players are allowed to play without either weaponry or fear of death – but at the cost of being stuck when they cannot work out what to do. Experiments in the 1980s did pursue ways around this problem, such as Magnetic Scroll’s Jinxter (1987), which used an unusual fail-continue structure such that even if the player fails to solve a puzzle, the story still progresses. However, the game was impossible to complete without correctly solving all the puzzles, rendering its innovation impotent. The Puzzle regime is far and away the least commercially successful form – but since the personality preferences of programmers and game designers lean heavily towards the enjoyment of difficult puzzles, the form never disappears and a lively niche market has persisted.

Lastly, Peaceful – the rarest of all play regimes, and thus the most interesting for art/games to explore. The roots of this regime lie in the dungeon and village structure of early computer role-playing games: Japanese developers began exploring what happens if you ditch the 'dungeon' aspect of this model in the mid-1990s. Harvest Moon (1996), a Peaceful computer RPG set on a farm, ultimately led (via a series of clones) to Zynga’s mega-hit FarmVille (2009). At a similar time, Nintendo included a “Birdman” mode in Pilotwings 64 (1996), which offered players the chance to fly around the fictional world of the game under a Peaceful regime with no stated purpose or goal beyond personal enjoyment. The colossal success of games such as FarmVille and Nintendogs demonstrate that Peaceful is not only a viable commercial regime of play, it is capable of attracting an incredibly wide audience. It is worth noting that Minecraft not only offers a Peaceful regime, it effectively offers two different Peaceful regimes (Peaceful and Creative) – which almost certainly contributed to its success.

This spectrum of regimes of play runs from the “hot” excitement and anger of War and Challenge, through the “cooler” frustrations of Puzzles, to the thinner experiential play of the Peaceful regime. Art/games since 2005 (the year of both Façade and The Endless Forest) have been experimenting with what can be offered in this space, with Dear Esther and Proteus being recent additions to the artistic exploration of the kinds of thin play only possible under a Peaceful regime. It seems far more likely that innovative play experiences will come out of this side of the regimes of play than out of the well-worn track of War, Challenge and Puzzle – but never underestimate the essential creativity of the digital games community when it comes to finding new ways to approach old ideas.

Last week, I presented some pitfalls and pro-tips for developers looking to audit their game design or narrative materials with a focus on how to set off in the right direction for a productive audit. In this second and final instalment, I look at some of the bad assumptions that can render audit feedback useless or just downright misleading.

Pitfall: We Can Ignore Story, Right?

The belief that “story doesn’t matter” because it’s all about the game design is endemic to the games industry. If by “story” we’re talking about the narrative material that occurs entirely outside of game play (such as cut scenes), then there is some truth to this, but even then it’s all too easy to be distracted by personal or cultural prejudices. It’s easy to say that Metal Gear Solid succeeded despite it’s overly verbose story materials – hell, I even believe this commonplace myself. But it’s striking that fans of Metal Gear Solid rarely complain about it being verbose. Similarly, when fans of Final Fantasy (from VII onwards, at least) talk about what they love about those games, they don't complain about the excessive story content provided they liked the game overall. The vast majority of players (93%) recognise that story adds to their enjoyment of a game – and they should know!

More importantly than this, however, the relationship between a game design and its narrative content – what I would call, since writing Imaginary Games, its fiction – isn’t just peripheral. Puzzle games not withstanding, no major game I am aware of has succeeded by creating a dynamite set of game mechanics and then deciding upon an appropriate gloss (although occasionally people take someone else’s design and then apply a different setting). You don’t add the setting after working out the entire design because the fiction of a game isn’t peripheral. If you start with the design of, say Sid Meier’s Pirates!, you are not going to finish up with a pet management game, a World War II shooter or a flight sim. You’re going to end up with a pirate game. You can transplant it to fantasy or science fiction settings, but you aren’t going to interfere with the core fiction of your reference title because it is integral to the mechanics. And this is true of just about everything except the most abstract of designs (such as puzzle games).

Most game auditors will come at the relationship between game mechanics and setting in an odd way – some will expressly disavow the importance of “story”, and developers should be cautious of these viewpoints when they emerge. The number one reason for the success of a videogame – any videogame, targeting any audience – is that it appeals to its players. And the first port of call for that appeal is the fiction, the setting. Of course, players want a game that’s fun to play too, but contrary to common opinion there is much more latitude about a game’s mechanics than there is about its fiction. If players don’t want to play in your setting, they aren’t playing your game no matter how fun it might be. As soon as you’ve chosen your setting, you have locked in your audience as anyone who enjoys imagining that kind of fiction, and excluded anyone for whom that setting is a turn off.

Pro Tip: You usually can’t fix problems in the fiction of your game by an external audit – so your team needs to be on the ball about it. The problem is, most game design auditors erroneously believe that the fiction is entirely mutable, and most game narrative auditors are brought in far too late to conceivably suggest a sensible change of direction. If setting is a concern (and it should be!), consider getting a quick narrative audit of your concept documents before you do anything else.

Pitfall: What Matters to Your Players?

I’ve spent my entire career as a consultant trying to spread the word that players are more diverse than the games industry gives credit. It's a position that was outlandish when I first started preaching it, but thanks to Nintendo, social games and the ever-widening audience for play, I have ultimately been vindicated. Yet despite this, the majority of people working in the games industry still plan projects as if the cause of success is internal to the systems of the game – if we just get our systems right, the audience will appear. Perhaps. But you would be wise to know what matters to your players rather than just believing that “if you build it, they will come”.

Game design audit’s can produce strange feedback when it comes to taking into account the needs of the players, and it is wise not to take all such comments at face value. This is especially true for a game that is targeting a non-standard audience – which is to say, for a game targeting someone other than 15-25 year old males. When an auditor writes terms like “players” or “kids” in sentences like “players don’t want such-and-such”, be suspicious. All players are not alike, and things that some players detest are bread-and-butter to other players. The more qualified such statements are, the less problematic they become, but even then no-one has a perfect handle on the audience for games. How could they? It’s an incredibly diverse range of people, and one player’s deal-breaker is another’s driver of play.

The most secure test of a game is play trials with actual players, but of course you have to have already built the game before this is possible, and the purpose of game audits is usually to troubleshoot before investing heavily in materials. The best sanity check is often comparison to other successful titles: if your key reference title enjoyed commercial success but has few rivals, you’re exploring a potentially viable niche – but be sure to explore why the game has few rivals. Conversely, if your key reference title enjoyed commercial success but already has loads of competitors, you’re probably wasting your time ploughing money into an already crowded market. A great game audit should be able to discuss your project in the context of other titles in the market, and in the context of your intended audience – audits that talk about games as if they were one-size-fits-all will not help you.

Pro Tip: Everyone wants the next big thing, but no-one knows what it is. It’s risky going after a completely original design, but not as risky as developing a title that has hundreds of competitors. Game audits will often be unable to see originality as a plus, and frankly it often isn’t a plus. Most original titles fail. However, if the audit steers you towards crowded markets, you’d be better off taking the risk than playing safe – because as soon as there are more than three successful franchises courting a particular genre and audience, it’s no longer a safe move to try and tag along. Take chances but do so wisely – and a good audit can help you do this.

Disagree? I’d love to hear your thoughts in the comments.

Over the years, I’ve been involved in dozens of game audits – the process whereby the content of the game (either on paper, or as a build) is assessed externally from the developer in order to help improve the project. I’ve been on both the kicking and the receiving team for audits – as the consultant brought in to provide feedback, and as part of the team getting that feedback. Game audits can be exceptionally useful. But they can also be a colossal waste of time and money. I would recommend that any team considers auditing their design or narrative materials – but I would also advise taking the feedback with a pinch of salt.

In this two-part series, I’ll offer some tips and warnings about auditing a game that may help developers going down this path. This week, I’ll look at how to set off in the right direction for a productive game audit – and what will happen if you don’t get it right.

Pitfall: Did They Get Everything They Needed?

The single biggest reason that a game audit fails miserably is when the auditor isn’t given everything they need to understand the game. Often this happens because the game design documentation is inadequate at capturing the development culture that the game is created by (which is unavoidable). Sometimes it happens because the design isn’t explicit about its reference titles, inviting a string of erroneous assumptions about what the game is supposed to be. Sometimes it happens because of a failure to take into account different target audiences. And sometimes it happens because the auditor is kept in the dark about information they actually need to do their job.

The worst of these I’ve been involved in was a Western-style cRPG project with a design entailing a span of many decades, and a central character passing through different stages of life. An audit was called by the publisher on the story materials – and the auditor was given the Narrative Design but not the Game Design documentation. As a result, they assessed the story materials as if the game was an action game, and provided feedback that was so wildly wrong-headed it was essentially impossible to get a useful direction from it. Fortunately in that case, I had subcontracted for an independent story review with an auditor who was given the design documents to take into account, but what the two audits revealed was the radical gulf between the understanding of the publisher and the understanding of the developer. This project was never completed.

Pro Tip: if you intend to audit design or narrative documentation, make sure the people in charge of those documents know about the audit and can prepare the documents with an external perspective in mind. Most game documentation is intended for the developer’s eyes only, with the decision processes undocumented because the team themselves don’t need a record of this. For audit, those decisions can be crucial, so make sure the paperwork includes context, reference titles and justifications for apparently odd decisions.

Pitfall: Are They the Right Person For the Job?

I’ve noticed that developers and publishers jump at the chance to get a “big name” game designer or writer involved in their project, thinking that commercial success is something that can rub off in the audit process like luck from kissing the Blarney Stone. It is my experience that while “big name” auditors can provide stellar feedback under the right circumstances, no game has enjoyed commercial success as a result of this kind of ‘star audit’.

One of the chief problems in this regard is that while most game designers consider themselves able to design any kind of game, no game designer is actually equipped to do so. If you have never worked on a role-playing game (tabletop or computerised), your shouldn’t be auditing one. If the game is targeting teenage girls, don’t get an audit from an expert in First Person Shooters. It seems obvious when you spell it out, but everyone has their strengths and weaknesses and the worst kind of audit is one that involves fitting a square peg into a round hole.

Although everyone who has built a name for themselves as a game designer or writer has (by definition) successful titles they can point to, what this usually means is that they have worked within a development culture capable of delivering games of that style, genre or for that particular target audience. They may well know what has worked for them – but do they know what doesn’t work for your style of game by virtue of their success on their style of game? The risk of getting in a superstar to audit is that what they really know is how to make games in a particular way – unless you’re certain you’re developing in an equivalent circumstance, their feedback is less likely to help you than critical input from someone specialising in the appropriate areas.

Pro Tip: Audit feedback is most useful when it can help you avoid mistakes, and for this prior experience within a particular field relevant to your project is more important than specific commercial success. The reasons specific titles succeed involve far more than just the game design or narrative materials. Market success is not a transferable skill – but experience of development problems is transferable. Hire auditors with breadth of experience wherever possible, and avoid “big name” audits except when the crossover in design is a near-perfect fit.

Next week: Bad Assumptions