(Mini warning: this post turned from a simple idea to a fairly epic 2500 words.  Get a cuppa and a chocolate biscuit before attempting to read.)

To answer that, we need to look at what the current constrains actually are. There are lots of small issues but they nearly all fall into one of two categories: cost or artistic desire.

Cost

It’s a sad fact but the cost of making AAA games has sky rocketed. On average, on the original PlayStation, a team of about 10 people could make a 60$ game in about a year. For the PS2 that went up to more like 30 – 50 people for two years. For this generation of console there is no average – it’s as many people as you can get for as long as you can get. 100 people taking 3 years is fairly normal, but it’s also common for teams made up of many more. If the price of games reflected the increased man-year development time, they’d now cost about 1800$ each.

Why?

As a very broad stroke: all those pretty images take a lot of developing. The quality of the art in games is far higher than ever before, and the code bases that drive everything are far larger and complex than we ever imagined they’d be.

The biggest single factor slowing us down, and thus costing us money, is our tools and pipelines. Turnaround for an idea has slowed to an almost archaic crawl because of the time it takes to create content in a AAA game right now. The knock on of this is that it has a detrimental effect on the quality of the games we are making, and people don’t want to pay 60$ a pop anymore, let alone 1800$. There are two ways of fixing this: as an industry we need to invest in finding a different approach to creating content or we need to develop better tools.  Or, preferably, both.

Different approaches to creating content

Once upon a time, coders creating everything in the game.  Art was a means to an end.  Nowadays we have teams of artists sat at desks across the globe, all beavering away on the small details.  That nice crumbly wall in Uncharted 3 probably had three different artists working on it: one for the basic collision mesh, one for the render mesh and one creating the texture and normal map in the first place.  Throw in a lighting artist or two, and a particle effects guy to make the nice clouds of dust when it gets shot.  Oh, and a guy to make the impact sound effects.  Let alone the coders required to make all these systems work together.

Back in 1993, a role playing game called Dungeon Hack came out. It wasn’t unique by any stretch, but I mention it partly because of how movement systems used to work. The dungeon, as with most games of the time, existed on a grid. Each move you took moved you to the adjacent square, assuming there wasn’t a wall there. The world was rendered in first person, but you had no freedom to look around at anything other than 90 degrees, and move one square at a time. (Completely unrelated to me writing this article Legend of Grimrock, which uses this movement system in a modern game, has just been released.)

From a top down view, a dungeon looked a bit like this:

The main reason I mention Dungeon Hack is because of how the dungeons were actually created.  If you look again at the image above you’ll see that it’s possible to create the layout by using just four files, rotated into position:

By using a pre-defined set of tiles and an algorithm running a randomly generated number to lay them out, a unique dungeon was created every time you started a new game.  Rules then layered on top to place items and enemies.  In theory, there were limitless combinations and once the system for creating the content was up and running new levels could be generated almost instantly.  If user control was desired, an editor allowed players to make their own layout.

Tile based generation still exists in games like Civilisation, but it has proved very difficult to create modern 3D games with such a system, partly because of the demands on artistic quality and partly because of the desire for unique locations to visit.

Prefabs

Prefabs are a more modern way of generating content, and in essence work in a similar way to tiles, except they are stand alone units rather than part of an interconnected network.  Humans are very good at spotting repetition though, which reduces the effectiveness of using this system. Houses fairly quickly get spotted as clones, and players tend to lose interest in discovering new places if they think they’ve already seen everything there is to offer.

Procedural Generation

This is based heavily on maths and simple data structures.  The best example of what can be achieved with this method is still the demo scene:

As with the randomly generated dungeons there is a set of rules controlling the overall scope of the images here.  Similar methods can easily create large scale environments.  There are limitations though, the main one being creating areas that flow well into one and other.

On their own then, none of these approaches really gives us the flexibility or quality that we desire.  But by combining the three methods into a toolset we could help open up new ways of creating large scale content, rather than just relying on adding more artists into the equation.

Character Creation

Every story needs characters, and in this regard there are already tools that allow us to create a lot of unique models quickly.

I’ve used this video before because it’s a great example of what can be created given the right motivation and time.  We can also do very similar for animations: with a base set we can quickly add variety by using additive animations, such as a limp, or letting physics code take control.

The tools are the game

Another way is to give players the ability to create content themselves.  Creating levels for Doom was the reason I got into designing videogames in the first place, more recently Minecraft created a game that was, initially, a tool where players could create their own content.  There’s a huge demand for this type of game, where the editor is effectively the game: FarmVille and DrawSomething are other examples. They are very different types of game from the Mass Effects of the world, but it feels like there should be a way of learning from their methodologies to enable us to improve our content driven games too.

Clint Hocking has already done a very in-depth series of posts on convergence like this, and  in far more detail than I am here.  In his eight part series he suggests that other gamers could provide the context for the story, a sentiment that I agree with but relies on playing online.  EVE Online does this to a degree and some of the stories of conspiracy that come out of it are great reads.  There’s a flaw with this method though: even with relatively small player numbers (compared to World of Warcraft), each player feels like a very small fish in a very large pond.  Your influence on world events is minimal.  The reason people like playing the hero is because of the feeling of power and fantasy it gives them, and single player games give you this ability.

So, we can no doubt create worlds and characters much faster than we currently do, but that doesn’t solve the main issue I’m trying to tackle with this post: is there a way to create a story this way?

Story as a mechanic

Glance back up the page at the diagram of the dungeon for a moment.  There’s another way of showing its layout, and that is to instead show each square that requires a change in direction as a node, and the route through as connections:

If you read my previous article on content this should look familiar: this is, more or less, how we currently move through stories in content driven games.

In games today we take freedom of movement for granted: if we want to go and spend time looking at a blade of grass, we can. This is because movement systems have developed from the very simple set of rules Dungeon Hack et al had, to a complex mechanic. An almighty array of things are happening in the background to grant you that freedom of movement, from how to respond to the amount you’ve moved the analogue sticks through to how the scene behind that broken window renders.

Can we take the same steps with story? Can we create sets of rules that allow the player to drive the available story events at their will? Possibly even the freedom to create their own stories? It’s not going to be easy, and it’s not going to happen overnight, but I think we can.

How?

Firstly, take the steps required to make content creation faster and cheaper.  Then we need to understand what a story actually is. It’s well documented that all stories fall into one of seven types, which seems like a good place to start:

Overcoming the Monster: The hero learns of a great evil and goes on a journey to destroy it. Star Wars qualifies. Braveheart. Jaws. Any movie with Nazis in it. Some of the Rocky movies. (Is it obvious I am a guy?)

Rags to Riches: A sad-sack beginning that leads to a happily ever after. A lot of Dickens’ stuff fits here. Disney princess movies. Harry Potter. Most every rom-com.

The Quest: Everybody loves a quest where the hero goes on a journey to find something, which can be a Lost Ark (literal of figurative), a body (Stand By Me), or even something unknown and unseen, which is known in Hollywood as a MacGuffin. Sometimes the hero brings his entourage, too. A lot of epics are Quest stories. Like The Goonies. Some of my favorite biblical stories are quests, like Abram and The Wise Men.

Voyage and Return: Like The Wizard of Oz, where Dorothy goes to a weird place with weird rules but ultimately returns home better off. I suppose I like Oz alright, but I’d rather give props to Back to the Future, because I’m of that ilk.

Comedies get their own category, too. For some reason, two people can’t be together, which creates all sorts of antics. They eventually figure it out, though. Again, most every rom-com ever, like When Harry Met Sally, or The Money Pit. (Note: you can make anything into a comedy. For example, Monty Python is a funny Quest movie, but the category here refers to a specific kind of plot, not just anything with humour.)

Tragedies are like riches to rags, where the villian gets it in the end. MacBeth and King Lear are classic examples. Or most slasher pictures if you go for that sort of thing.

Rebirth is like a tragedy but where the hero realizes his error before it’s too late, like in It’s a Wonderful Life. Which makes me wonder, are there any slasher movies where the bad guy cleans up and catches a ray of sun at the end?

(source http://lenwilson.us/seven-stories/)

The story outlines that most single player games use falls into ether Overcoming the Monster or The Quest which is something else that we ideally will address as the medium matures.  Aside from that though, these seven rules of thumb give us a great basis for the forming of a mechanic.  How so?  Well, a mechanic is really just a set of rules, and each of these seven categories has a very definable goal for each story category.  This means that we can create a fairly simple set of IF statements to set the story goal based on the category chosen.  Whether that category is chosen by the player or randomly doesn’t matter.

Of course, a good story requires much more than that: it also requires structure. Typically these are defined into sections called Acts. Act 1 introduces the audience to the characters and scenario, Act 2 fleshes everything out, and Act 3 has the conclusion.  More rules, which means we can add another layer of complexity to our mechanic.

The numbers of main characters, their traits and motivations: all these can be defined to some level either by the player or with weighted random selections (which is where you guarantee at least one of type X and so on).

Would a story generated in this fashion be any good? Well… probably not. The missing touch is, of course, humanity. This, then, is where the player really comes in: their decisions and actions influence the actions and motivations of the computer-controlled characters alongside them. The game would adapt on the fly, so if the player decides to be friends with the bad guy for instance, a new enemy or threat would have to emerge. But the player could have the freedom to influence the story as they move through it.

The thing we still can’t do very well is to create dialogue: both in the writing of it and in the audible generation of it. Computer generated voices still sound horribly robotic, and that instantly ruins any sense of immersion or belief. (Unless, of course, you’re doing a game about robots.)

There’s another problem as well, which is the second of the issues I mentioned at the start of this article:

Artistic Desire

This is the biggest problem really: what story do we want to tell? As shown above, the general structure of a good story is always the same, and Act 3 is the conclusion. Without closure you don’t really have a story in the sense that literature and film define them. As humans we like telling stories, we like crafting them and we like the warm feeling inside that we get when we, the the hero, reaches the end.

Unless, instead, we turn our game into something more akin to a soap opera.  They have moments of closure as story arcs come to an end, but the world in which those arcs exists continues to persist and expand.

Can we do the same with a game?

Do we want to?

Understanding

It seems to me, from the way the petition is worded, that despite investing hundreds of hours in the trilogy many gamers don’t understand the logistics involved in creating a videogame.  It could be argued that they shouldn’t need to – we watch films without knowing all the intricacies involved in getting the image and sound to the screen, so why should gamers need to know about the blood, sweat and tears that go into making games?

While some films do spark huge reaction towards the director from fans, those fans often find other outlets for their reaction, with alternative endings turning up on youtube or comic strips or even novels.  There are rarely the tools made available for alternative endings to be made for videogames, which in turn leads to fans putting pressure on developers.  Funding issues aside, there’s a big reason why a game driven by content cannot have infinite endings: it’s simply not possible to create and test that much content.

To expand on that statement, the way the Mass Effect trilogy melds the experience to the player’s actions puts a phenomenal sense of power and creation into their hands, and this naturally gives the impression that the game is crafted specifically to them.  Unfortunately, it’s not.

Exhibit A

To give an example of how a content driven game is designed I’m going to have a quick look at Dragon’s Lair. If you haven’t played it, the premise is very simple: a beautiful animation plays out and, at a pre-defined point, something happens which the player needs to react to with a button press. This is a video of the full game being played all the way through:

The playthrough doesn’t show many of the player deaths because the player knows what they’re doing. But behind the smooth flowing animation is a system that’s waiting for a player input. If the player misses the window of opportunity the game branches, and the player dies.  If they hit the window, they progress.

Different companies refer to these as different things – nodes, branches, gates.  They’re effectively all the same and, for this post, I’ll stick with the latter.  This example is the simplest gate required to create player choice.  Each and every sequence has been hand crafted, and the game planned out in intimate detail.

To design Dragon’s Lair and sketch out the flow it probably took a few weeks, though actually creating the content took 7 months and 1 million dollars (source).  That was in 1983, so in today’s money that’s a lot more.  And all this for a game that can be completed in just over 10 minutes, as shown in the above video.

Testing

As well as creating the content and code, it all needs to be tested.  Test plans come later down the development line, when the framework of the game and the main mechanics are close to being locked.  Once that happens it’s possible to create a list of tests and expected results.  From here the test team can do regular checks to ensure the game is behaving as intended.

A test plan for the the diagram above might look something like this:

One sequence with a single gate therefore might lead to eight tests.  Possibly even more.  For now though that’s enough to highlight why testing is one of the most difficult parts of making games.  It stands to reason therefore that in a game more complicated than Dragon’s Lair there’s going to be far more possible outcomes.  At any one point the player could have done one of a hundred things, let alone the thousands of small inputs they’ve made to get to where they are.  If a bug surfaces the developer then needs to find a way to recreate it so that they can understand what’s going wrong and then, hopefully, fix it.

I should note at this point that something like a shooting mechanic is very different from gated content, because that’s a system that has a set of defined rules.  When the player does certain things (such as presses the fire button) the rules determine what happens, not the content.  So the test plan doesn’t have to account for pressing the fire button at every possible position the player can get themselves into.  The sort of gates I’m describing here really only come into play at big story points, such as the ‘choose route’ type option presented to the player in Gears of War for instance.

Scaling up

Now we know the level of detail required for a single gate, we should now look at how we cope with multiple gates.  In Mass Effect each conversation often has a few possible outcomes, especially when they’re with key characters.  The interaction required by the player is very different from the reaction-heavy animation window system employed by Dragon’s Lair, but the underlying system is very similar:

Suddenly we’re facing a bit of a crisis – one conversation with three possible outcomes, each with just two more attached to them has led to six unique paths.  And the game design wants over a hundred conversations…  There’s no real way that we can create that many unique gates.  So, instead, we create paths that feed back into themselves further down the line:

You’ll notice that by using this system it’s entirely possible that the player won’t have to go through every gate to get to the end – in fact it’s desirably to do this to try and encourage replays.

Choke Points

You can keep even more control over the number of possible outcomes by creating larger, single, gates that the player has to go through to complete the game, but where they’re free to choose whatever route they desire in between:

The orange boxes in this case are choke points.

With a game like Mass Effect there are multiple choke points, but the entire game is constructed of so many that the player doesn’t have to go through every one to get to the end of the game.  In fact, there’s very purposefully a great deal of routes through the game.  But every single route has been planned, designed and has had content created for it.

This type of design method isn’t just limited to stories, but can be used for level design or ability trees too.  A good example of a game that uses this method for all of these systems is Bioshock. Several levels give you objectives that you must complete to ultimately move forward, but you can do those objectives in whatever order you desire.  Equally the story feels to develop around you, the player.  It’s up to you whether or not you delve deeper into the myth and seek out the audio diaries, and of course there’s the choice of how to deal with the little sisters.  Layered on top of that are you abilities and upgrades, all at your choice.  It works really well, all the way up until the point where you meet Ryan.  At that point all players must go through a single choke point with only one outcome.  Thus their choice is removed.  My protest with Bioshock was simply to stop playing – I still have no idea how it actually ends.

Mass Effect 3 has obviously created a similar reaction, though a much stronger one than my silent protest.  Throughout the trilogy players have been making what they believed were unique decisions, and the games responded accordingly.  The achievement by Bioware is staggering, and from an external perspective very inspirational.  Logistically though, there could never be enough endings to satisfy every possible outcome, and hopefully this post has gone some way to showing why not.

Disclaimer: I don’t work for EA or Bioware, and wasn’t involved in the creation of Mass Effect at any point.

This was common across the world, and open sewers don’t just smell horrid but they spread disease. The people behind the construction of Pompeii evidently knew this and came up with a simple, but effective, solution. Building it on inclined land was the start, and the aquaduct was placed to come into the town at the top. Twice a day, at dawn and dusk, the sluices were opened to wash the streets. To further serve this purpose the roads were deeply set, and crossing stones added at regular intervals for people to get to the other side without having to step down into the sludge. Finally, said crossing stones were all made to one size – the width of the rear axel of the carts that delivered the goods.

I’m guessing by now you may be wondering what this post is doing on a technology based blog about videogames. The design of Pompeii stayed in my mind for two reasons. One, because it was so well laid out and the entire city was constructed to a set of rules that had obviously been clearly defined early on. And secondly because, compared to more modern cities I wondered how we’d lost the knowledge and reasoning behind the design of Pompeii. How were cities built later on so far behind?

Which brings me to this post: recently I started replaying a few games from years ago, initially just to see if they did actually stand the test of time or if my rose tinted glasses were getting in the way of my better judgement. After even just a few short hours with a couple of games (Ultima Underworld and Doom) I was relishing a few of the mechanics and wondering why we don’t have them today in single player games.  It seems I’m not completely alone in thinking this, as Eurogamer have recently done a retrospective on Doom, and I don’t think I’m just being sentimental: I truly believe that some AAA games have lost some of their heritage.

This isn’t about graphics, sound, music or physics as there’s little doubt that modern games have advanced hugely in these areas. I’m not a complete believer that better graphics equals a better game though, as to me a strong art direction wins every time over pandering to the latest graphical technique. Saying that, there’s little doubt that better graphics and sound are a large part of what has helped peel back the once very geeky image of gaming. We’ve also improved the general accessibility of games massively, control systems are generally better refined and tutorials guide players into how to play a game far more professionally than we ever used to. So, what have we lost?

The three main things that stuck out to me were:

1. Navigational freedom
2. Weapons
3. Player death.

Navigational Freedom

This isn’t just about how you get around your environment, but what the reasons are behind that freedom. Ultima Underworld and Doom are very different in their approach to how you progress through the game. Ultima Underworld doesn’t present you with very many locked doors, and often invites you to delve deeper into the dungeon. The main thing holding you back is the knowledge that your character isn’t strong enough to tackle the enemies that lurk beneath. You want to get as strong as you can before taking the darkness head on. Doom, on the other hand, often presents you with a locked door early in a level and says ‘go find the key and don’t come back until you’ve got it’. Both allow you to take your own route though, often presenting you with multiple routes, secret areas and shortcuts for the way back. It’s true that you can spend quite a bit of time being lost, even though both games have very extensive maps. But there’s one key point to both of these games and, from my memory, many others of the time: it’s up to the player to set the pace at which they progress.

In our efforts to be more cinematic in our approach to games today we end up pushing players through whole levels, trying to maintain a filmic like pacing. For sure, these moments can be exhilarating and do have their place but, I think, we’ve taken some of the control of their destiny away from the player, making games that feel very linear even though they might not be.

Weapons (and weapon inventory)

This is probably the part of games that have changed the most in recent times. Back in the days where Doom, Duke, Half-Life and Quake ruled supreme players could carry all the weapons they could find and choose when to use them. Weapons used to have a very clear hierarchy – number 5 on the keyboard was more powerful than 4. You knew this and you saved a few rockets for when you really needed them, and that feeling of potential power and domination when you found a new weapon seems sorely lacking in modern titles.

Part of this is down to the restrictions on it – when you find a big weapon in a modern game you know you’ll either run out of ammo or have to put it down to open the next door. It’s been created for the current spectacle and little else. The other part is just how complicated the underlying maths has become in our desire to provide a more realistic experience, which is a shame. I still haven’t found a game that’s as satisfying to play as Doom is when armed with a shotgun, plenty of ammo and a room full of imps.

Player Death

With regards to player death, modern games have lost their soul. Going back to Ultima Underworld for a moment and, after I’d got to grips with the controls, I dived deeper into the abyss assuming that the knowledge from my previous play throughs would stand me in good stead. Alas, I was not a top level Avatar anymore and the poisonous bite from a green bat was sufficient to start my health depleting at a rapid rate. In a panic I dived into water to swim to where I thought there was a ledge with a plant that could cure me, only to be met with a creature from the deep. In spite of the old graphics, clunky movement and awful music, the game had me completely gripped, every part of my physical body tense as I struggled to swim to safety. Dying meant something, and I knew full well I hadn’t saved the game and the last hour of play would be lost.

The consequence of dying in most games today is minimal, whereas staying alive used to be one of the primary mechanics pinning an entire game together. It wasn’t realistic, but hunting for that magical health pack, or saving it until you really needed it, became a key goal which encouraged exploration around the world. Now we just sit behind a wall and wait for our health to regenerate. It’s simply not as much fun and, really, no more realistic.

Going forward

So how do we get back these mechanics that we’ve lost?  Well, firstly, we should decide that we do actually want them back.  It’s possible that we do, but not in completely the same guise as before.

To allow for more navigational freedom it feels like we should develop a better way of telling stories.  Cinematics are all well and good, but they can turn a game into little more than a glorified Dragon’s Liar.  Interactive cinematics often result in player’s throwing chairs at key characters as they deliver a plot point.  The best story in a game to me is Shadow of the Colossus, because the player becomes completely integral to it – your actions are directly relevant to the outcome.  I know that the mechanics of the game annoy some people, as does its difficulty, and it’s a shame that they stopped some people experiencing one of the highlights of gaming.  This kind of story telling should be able to transcend into other genres, and the way to achieve it is to develop the mechanics and story together, rather than as separate entities.

Weapons too are something that need to be developed as part of the whole, rather than just as ‘we need 7 weapons’ or ‘X had a rocket launcher so we should too’.  Think about the reason behind the weapon and why it exists in the game.  If there isn’t a definable reason for it, then you probably don’t need it.  Spend as much time as possible dedicated to the low level mechanics involved in the weapon to make it as satisfying as possible to use.  This isn’t just about rates of fire and damage values to tweak down the line, but recoil and reload animations, enemy reactions, blood and, possibly most importantly, the sound effects.  Make it fun.

Death is interesting because the biggest problem with it in games isn’t dying at all, but the balancing of the game.  As designers we need to stop setting up areas where we expect the player to die or even where we want them to die in order to stretch the game out.  Dying should be the consequence of the player, and it should feel that it is their fault.  That is their punishment.  As soon as you feel you died because something was unfair the game has broken its spell, and becomes frustrating.  Auto-saves should be there as a backup rather than a reliance.

The game I’ve seen with the best save game system is still Severance: Blade of Darkness.  It auto-saves for you at the start of the level, and you’re free to save again whenever you want.  Underneath the save game name is a title, which changes depending on how much you save.  Save little and you are “Brave warrior”.  Save a lot and you are “Scared little child” (I can’t remember the exact titles but they were along these lines).  So, so, simple and yet so effective.  As with the story telling this is the kind of thing we should be doing – using the psychology of the player to deepen their connection with the game and how they are playing it.

Maybe that is the lesson to learn here: don’t just look to the past, but look into the future.  What do you want your player to feel when they play your game, and what do you want their thoughts to be about?  How do the mechanics in your game complement that, and how do they invoke a passion for what they are doing?

Naturally, it’s not that simple in practice. The biggest hurdle that a game faces during its development is that it’s not really ready for external testing to take place until very near the end, at which point it’s too late to be able to change much. Bugs get in the way and skew the testing, we already know that doesn’t work / animations / effects / UI / etc aren’t in yet / we don’t have any time to change anything anyway. The person you got in for testing was an idiot that didn’t know what a console was.

I used to believe all of that. If you still believe it, this post is here to tell you that you’re wrong. It’s never too early to focus test, and if the test is run properly it will be invaluable: it will make your game better and it will save you money.

The lesson

Looking back I think the point where I realised that focus testing was invaluable was when we were making Rogue Trooper, though I didn’t realise it at the time. In fact, at that time, I fully believed the paragraph above: I’d made a number of games, I’d been a Lead Designer several times and I was confident in my skills and the team. I was, almost undeniably, a pain in the ass to work with – mostly because of my refusal to delegate. At no point was this truer that with the level design: having made countless levels for Doom, Quake and then all the games that I’d worked on I truly believed I knew everything there was to know about making a good level. I did the initial white boxes for almost every level in Rogue Trooper and, because of that, found it very difficult to relinquish control and look at them with the critical eyes that I should’ve been using as the Lead Designer.

Nowhere was this more evident than in the first few steps of the game.  Here’s a (very rough) recreation of the initial layout of the start area to the game:

The design seems pretty simple and the expectation was that the tutorial would be overlaid onto this and players would do the following:

The path back to the start was put in purely as a method for getting players back to the start and forcing them to jump over it because I wanted to teach climb next. Jumping is a key mechanic in the game, not because it’s a platform game but because it’s useful for diving out of the way of enemy fire. I wanted to teach it to players early on.

At this point in development we had the basic feature set for the game in place and running on PS2 – we’d done a green light demo to get the main development funded and had most of Rogue’s fundamental moves worked out, and we had very basic AI. The game was a long way off being finished but you could get around, climb, use cover and shoot enemies. We had ways of putting debug text on screen: we could have created a rudimentary tutorial. Basically: we should have put the white boxes into focus testing.

We didn’t for the most of the reasons I mentioned in the second paragraph.

What we did do was get team members to play through the levels, and do fairly lengthy technical analysis on the layouts with the lead programmer to ensure he was happy that we weren’t going to blow the PS2 up when we started layering art on. Refinements were made and we carried on: an artist spent several weeks making the detailed geometry, textures and lighting. A designer spent several weeks polishing up the gameplay and animators started creating the cinematics required to tell the story. Lots of money got spent.

Once it was all polished, and the mechanics of the game had been refined, we finally entered focus testing. The result was, at the time, heart sinking. Instead of doing what the development team had been doing, and what I expected, most people instead did this:

And not just once. Not just twice. They just did this. Round and round. Some people got it, but not the majority.

Some of it was due to the tutorial triggers only firing once – if someone missed the instruction on how to jump the first time they never saw it again. So we changed that and put it back into focus testing. The results were a little better, but not much. One guy spent 15 minutes trying to work out how to get out of the trench. My reaction at the time was “you stupid idiot!!!!” (note: there may have been more swearing than this). Only later did I come to realise, and come to understand that, if a design can’t be understood, it is usually not the person at fault: it is the design that is wrong. (This is an important lesson: learn it well for it will make you a better designer.)

There were plenty of other issues with the tutorial as well, some which were quick fixes and some similar to to this that required changes to the art. Which then had knock-on effects to the animations and so on. If we’d tested the level when it was in the white box phase it would have taken 10 minutes to fix. By the time we came to fix it, it took well over a man-week.

Using focus testing right

So, with such an arsenal of excuses at our disposal, how do you go about using focus testing right? Well, the clue is in the name: concentrate on a single thing that you want to test.  Is it a mechanic? A layout? A boss battle? Whatever it is, make sure that only the thing you want to test is exposed to the people you get involved. Take the testing of a mechanic for example: don’t create huge environments or spend time making something pretty, but instead concentrate on the core elements. Spend time working on the controls, any animations, sound and visual effects that are required. Look at how you’re teaching that mechanic – how is it going to be introduced to the player?

Looking back on the experience from Rogue Trooper, we were trying to teach the player how to jump before they could walk. Which in turn was systematic of our approach to making the game in the first place – we spent a lot of effort on lots of mechanics to give the player choices, then presented them with an action game. Gears of War came out around the same time and did two things – cover based shooting and active reload. Epic ensured that their key mechanics were honed to perfection and then built the game around them. Valve do the same with their games, and it’s also why Call of Duty has become so huge.

So when people ask you to keep adding more features, focus test them. Point out that less is more – time spent on polishing key mechanics will always produce a better game over one with many. Try to follow these simple steps when creating something new:

1. Decide what you want testing.
2. Create a prototype for that test.
3. Allocate sufficient time to organising the test.
4. Ensure the people that need to see the results are involved.
5. Keep a track of all the problems raised.
6. Respond to the key issues.

In the day-to-day deluge of tasks and information that flies around, it will seem hard to achieve this. It’s something that should really happen at the start of the project. Once a large team has come on to create content and flesh out the rest of the experience, it’s kind of too late. I know that’s an ideal world scenario that rarely happens, but when it does great games are made.

To most people reading this I imagine that it’s more or less second nature to sit at a keyboard and used AWSD and the mouse to move and look around, or to pick up a joypad and use the two analogue sticks to do the same. We know that space is probably jump, shift is run and control crouch. To someone that doesn’t play games though these controls are not second nature and, because of this, the act of moving a character through a 3D environment is a challenge in itself. Add aiming and shooting on top and you’ve already hit the capacity of a large proportion of your audience.

So, straight away, there’s a disconnect between what we, the games savvy people, see as a challenge and what the larger audience see as a challenge. Without the larger audience connecting with our game and buying it we can’t make a living. So the obvious conclusion, surely, is to make it easier to move around and thus make 3D games more accessible.

Evolution

Of course, it wasn’t always as it is today:

In text adventures we’d use commands like “Go North” to move around and, if we were allowed to go that way, be greeted with an explanation of where we now were. We’d sit there and sketch out the world on a pad next to us, marking hazards such as deep wells that brought the game to a end.  In effect, they were computerised ‘choose your own adventure‘ stories.

From there graphics came along. The interaction method started off the same for a while, then direct control of an on screen avatar, be it by using the keyboard or a mouse, came about. Platform games were born, where new skills of timing jumps and avoiding enemies in realtime  Then 3D graphics appeared – Wolfenstein 3D allowed us to slide around in a flat world continually pressing walls to see if they revealed secret passages, and the controls were simple because you only had a few things to do.

Doom introduced a 2.5D world – you could still only stand on one vertical plane at a time, but they could be different heights. Ultima Underworld, out around the same time as Doom, allowed for slopes and (I think) was the first game to let you look up and down. It was clunky to control but it didn’t matter – it was an extra level of immersion. Then Duke3D brought mouse-look to the world, and thus the invert mouse argument was born.  Quake brought us true 3D worlds to roam around and create.

I have little doubt that you already know all that.  The reason to write it is two fold:

1. There are millions of people out there who have access to a computer, and possibly own a console, that don’t know it.
2. Quake came out in 1996.  Control methods for moving the player around have not fundamentally changed since then.

Consistency

If you’re someone who can drive a car, try and think back to the first time you sat behind the wheel and started trying to drive it. Those first few moments of “oh shit” as a ton of metal starts to move under your command, your right foot. The learning curve is massive, but the reward is worth it.

To people that fall into category 1 above, every time they sit down in front of a game it’s like learning to drive. The problem with games is that, unlike cars, we aren’t very consistent with our controls. We don’t just switch over the indicators / windscreen wiper sticks, we keep swapping where the accelerator is too.

This isn’t going to change – it’s what makes games unique. But hopefully it offers an insight as to why people keep defaulting to buying big franchises: they already know how to play the game. Remember when GTA clones were coming out every month? (Well, it seemed like they were.) You’d try one, run up to a car and press TRIANGLE. If you didn’t jack the car and drive away, you put the game down. “Why can’t they just copy the controls?”.

This is what the games playing public, the people that make up the main proportion of our potential sales, want. But, as games designers, we rarely give them. I’ve been guilty of this too: simply copying another games main controls feels wrong, like some sort of plagiarism. We fear what the reviews will say. We worry about being scorned at by our peers. And, most importantly, we want to try new features out. In AvP I wanted to focus the Predator towards environmental navigation, to really try and tackle jumping up into trees accurately in first person. I know that we didn’t quite succeed, the final result wasn’t really a fluid enough experience, but there was certainly no place for iron sights with that character. So what to do? How do we strike the balance between creating something new, yet keeping it familiar?

Is there a way forward?

One thing is certain: it will require a very brave developer with a strong publisher backing it to break the mould that we’re currently in. Look at Heavy Rain for example, which tried something fairly radical with its interactions and character movement. Upon first pick up, unfortunately, it was almost impossible to walk in a straight line. You could get better at it but by then it was already too late: a lot of people had already turned off what was otherwise a great game.

Technology has tried to answer this as well – 3D headsets have been created but generally cause motion sickness. Accelerometers make you flounder around like a fool. Eye tracking cameras work to a point, but you end up looking at your wall rather than your TV. Few people can afford, both in cost and space, several monitors.

So what is the answer? I think there’s probably three parts to it heading into the future.

The first part is mentioned above and, to a large degree, has been happening over the past few years. Consistency in controls across games makes them more accessible. Keep the basics of movement and shooting the same as the big games and people will be able to play it.

The second is education – “assume nothing, it makes an ass out of u and me” (ass / u / me in case you haven’t heard that before). Tutorials are a sod to write, especially when you only lock your feature set a week before beta. So try not to do that: gently introduce your player to your mechanics. Expert players will breeze though it, learners will take it slow. Make sure that there is sufficient time in the schedule to do this.

The third is up to the populace as a whole – games are more widely accepted than they were even 10 years ago. People that don’t even realise they play games are spending hours attached to Angry Birds. There’s a whole swathe of people that are slowly learning what we learnt 20 years ago, bringing their skill set up to match. We just need to be patient with them.

There is a final suggestion, which is to devise cunning new ways of moving characters through a world. There are options out there, though they restrict some of the freedom of choice that we currently have. That’s not necessarily a bad thing: too much freedom can be a double edged sword. Choose your own adventure games used to be all we ever needed: could they be again?

Purely by coincidence, half an hour previously I’d been playing the trial version of From Dust.  I love God / creation games of old; I spent many an hour on Populous 1 and 2, A-Train, Sim-City and a game on the Amiga I can’t remember the name of (you got asked by the AI “Can I be on your team?” if you were doing well…).  I’m a veteran games designer with 12 years professional experience.  Yet I can’t get past the 3rd level in the demo where you’re given a 4 minute time limit.  Partly because my heart sunk as soon as I saw such a restrictive mechanic on a game that on the surface appears to be about freedom and player choice, and partly because the game rules didn’t allow me to do what I wanted: create a dam further upstream and thus stem the flow of water down.  But every attempt failed because the sand gets washed away.

So why do we do this?  Why go to all the effort of creating all this wonderful technology and content, only to restrict access to it with rudimentary mechanics?   Do we not trust that the pure act of playing a game is enough?  Or are we too stuck in our ways to believe that there is a better approach out there?

Chess

I find the best way to work out how to make things better is to try and compare your current problem with something that you know works, and try and understand why that thing works and hopefully then apply that very same logic to your problem.

Which is a long winded way of saying I’m going to look at Chess.  Chess is great, I’ve loved it for years – I was even Pendle Junior Champion back when I was at school, a fact which I’ve bored my friends with on countless occasion.  This doesn’t mean I’m any good at chess, just that I was lucky that year and the competition didn’t turn up.  But I enjoy playing chess a lot, partly because of the mental workout it gives me and partly because it’s a nice feeling when you win.

And this is where video games seem to differ from pretty much every other type of game we play: single player video games rarely have a win condition.  The reward is simply to unlock more content, to ultimately progress until you’ve exhausted it all.

So why not?  Why do we make life so difficult for ourselves – content, after all, costs an absolute fortune to create (see my previous post about why, or Phil’s recent post for alternative methods to making it all by hand).  Surely we can become more creative with our mechanics and introduce some real win conditions, and expect that players will enjoy the act of playing the game itself to want to play it again?  The best example I can think of is probably Sid Meier’s Civilization.  Can we apply this sort of logic to, say, a first-person shooter?

Teaching point

One argument for restricting content is because you’re teaching players how to actually play your game.  Peter wrote about teaching players a few months ago, and I don’t want to rehash his points here except to iterate that gradually introducing your player to the mechanics is very important.  It is a difficult balance point to find: too fast and you risk overwhelming them, too slow and you risk boring them.  As a games designer I’ve spent a lot of time trying to weave tutorials into initial levels of the games I’ve worked on, and it’s tricky.  There’s a definite pressure to make them integral to the story and not have just a separate tutorial bolted on before each new mechanic, even though if you don’t highlight to player’s that they’re being taught something half won’t pay attention.

Challenge

Challenge is the other answer for why we restrict content – we want to keep increasing the challenge as the player progresses, so even if we did let them skip to level 10 they wouldn’t get anywhere because they wouldn’t be good enough at the game.  This makes sense in a new type of game, or one where you have very bespoke mechanics.  But in a first person shooter where, if you don’t copy Call of Duty’s control scheme you’re instantly deemed a failure? (that’s possibly a little harsh but remember this article on Cracked?) Everyone knows what to do, and could probably get by.  They might struggle, but surely that’s their choice?  They’ve paid their money so why not let them?  If I skip to the last page in a book to see whodunnit, I know that I’m cheating and could possibly spoil it for myself.

Multiplayer

You’ll notice that I’ve been careful thus far to highlight that the content unlocking applies mostly to single-player games.  And a few of you have no doubt been thinking “we’ve already solved this, it’s called multiplayer”.  And, to an extent, you’d be right.  But at the same time, completely wrong.

There’s a big line in the sand between the people that want to play single player and those that want to player multi.  Of the 20+ million copies of Modern Warfare 2 sold, how many people actually play online on a regular basis?  Those figures aside, the unlock process for the multiplayer is possibly even more content biased than the single player.  Sure, the maps come round on rotation, but until you’ve played countless hours you can’t get access to the best kit.  I know there are mechanics in there to allow you to get a taste, but we’ve lost the old mantra that made Quake so brilliant: the maps were all about the item placement and knowing the best route to them, and knowing when to hide when someone picked up Quad damage.  Today it’s about grinding your way through the weaker weapons, getting lucky occasionally and finally getting on an even playing ground.  I know we spend hours balancing the weapons so the later ones aren’t too overpowered and you have a chance from the off, but the cool toys are usually reserved for the people that put the most hours in.

Isn’t this just a rant?

Well, yes.  It is a bit of a rant and I’ll stop now.  I don’t have answers to the issues faced of content creation except that we need to improve our tools so that it’s cheaper to create more.  I do believe that we can create mechanics for both single and multiplayer games that rely on less content and more on the act of playing.  It’s not something that’s going to happen overnight, and it’s going to take a brave, high profile, game to lead the way.  Hopefully a team somewhere are working on just that.

The tools we use

It’s getting older every day, but the games industry is still a relatively new industry and that’s more apparent than anywhere else when we look at the tools we use to create the games.

We have code teams that can create amazing effects in real time, at 60fps.  We have artists that can recreate Rome, build Alien planets and animators that can make the stars dance.  But, at any point that we decide we need a bigger hole, we just get more men with spades.  It’s very rare for anyone to take the leap and get a JCB along to do the job for us.

So why not?  Why is it so often perceived that it’s cheaper to hire in some more people and train them up rather than improve the tools that we use to make the games with?  Unfortunately, because it is.  But why?

Commercial Software

This is the off-the-shelf stuff that every team uses: Photoshop, 3D Studio Max, mudbox, Dev Studio, through to Microsoft Office and version control software.  They’re pretty standard across the world, though there’ll be the usual fight as to whether the 3D artists use Max or Maya, and possibly mudbox or zbrush.  But the concept is the same – several thousand pounds / dollars / euros gets you a fully featured piece of software designed to do something.

As an example, here’s a video someone made of how to sculpt a head inside mud box:

That looks pretty quick yeah?

No.

Let me explain.  While it is fairly quick to create a head like this, this head is nowhere near ready to be put into a game at this stage.  Just going over the basics it would need several textures to create the skin, eyes and hair (possibly all on one page, but unlikely in today’s world).  Then it would need a rig putting inside it – a simplified structure that all the vertices inside the model get assigned (and weighted) to, thus allowing for it to be animated.  The list goes on and, with today’s tools, it takes a talented character artist between 4 to 8 weeks to make a character ready for a game.

Ten years ago, that same process took roughly 3 days.

For sure, that’s a sweeping generalisation.  And initially making characters on PSOne took far longer but, by about the same time in the PSOne’s lifecycle that we’re currently at with the xbox360 and PS3, a good character artist could knock out characters at a merry pace.  It all comes down to the complexity of the model and what it is for – a background character shouldn’t have as much time spent on it as the player character does.  And the visual quality of the art created today is, without doubt, far greater than ever before.  And our tools are better.  But they could be even better.

In-house software

Every game developer has software unique to them, be it a simple batch process to copy data over from the server onto the development kits through to a fully featured engine and tools suite.  It depends greatly upon the size of the company, its age and the general consensus towards developing internal software.  There’s a balancing point between reinventing the wheel and cutting edge research project that is very difficult, and costly, to find.  Realtime Worlds created this amazing character creator for All Points Bulletin:

For whatever internal reasons the company as a whole didn’t work, but whoever worked on this editor deserves a lot of credit and it’s things like these that I hope we’ll see a lot more of in the coming years.

Where next?

I’ve picked on one very focussed area of games development for this post, but it’s equally possible to use similar examples across the board of content creation, from level design to cinematics.  The problems facing the traditional industry are very real: we’re under a lot of pressure to bring costs down and create games faster because, traditionally, we’ve been able to do that on the previous rounds of hardware by this point.  There is little doubt that we need to improve our tools and methods for creating content, but the difficulty is finding out where the tipping point lies: where the cost barrier of more men Vs better tools comes into play.  It’s not easy, but if you’ve got a great idea for a tool that could be of help to you, write it down and get someone to make it for you.  It should pay dividends in the end.

As we all know the user interface is, as shown in my amazing diagram above, the bit that sits between us humans and them computers.  It takes input from us and gives us a response back.  It’s one of the simplest concepts to understand, yet one of the hardest things to actually get right.  Software companies spend a fortune on research into user interfaces because they can make something successful or render something clever too difficult to use.  Games companies do spend a fair amount on UI, but often as a disconnected unit from the rest of development.  You can really tell when a UI team has been brought on towards the end of development to plug in their bit, and 2D HUD elements dominate the experience.  Conversely, you can really tell when a team understands what UI is and why it’s so important.

Everything is the user interface

The biggest thing that it takes time to understand is that everything in a game is the user interface.  It doesn’t matter what kind of game it is but, as my experience lies in third and first person shooters, I’ll use those as an example.  Everything from the width of your doorways to the height of the walls that surround the player is part of the user interface.

As an example, on the right are two pictures.  Spot the difference between the original shot from Uncharted 2 and my photoshopped one.  If you’ve played the game you’ll instantly know, and even if you haven’t it should be fairly obvious: there’s a good chunk of yellow on the top image.  This is the visual language Uncharted uses – the player can climb on yellow things, and therefore this is a strong signpost to the player in the world.  2D elements aren’t required to be overlaid on top.

This is a strong example, but things that may seem trivial can be used to guide a player around.  It’s common to add a flashing light to a doorway you want the player to go through, or adding a memorable silhouette on a distant horizon as a landmark: each and every element gives information to the player as to where they should be going.  Its ability to spot patterns is one of the most amazing parts of the human brain, which can be a blessing and a curse.  A blessing because it enables us to be very subtle in some of the language we create for the game, and a curse because we have to remain thoroughly consistent with it.  To achieve this you need to have your visual language set and clearly communicated to the team, because if they don’t adhere to a set of rules the game will suffer.

The point here is that, in Uncharted’s case, it’s not just about painting anything that can be climbed yellow: it’s also about making sure that there isn’t anything that the player can’t climb painted yellow as well.  That consistency is the key.  Does this turn Uncharted into ‘hunt the yellow thing to climb next’?  Yes, a bit.  But that’s not a criticism: it’s part of the fun.  The developers realised that and become more creative with what is yellow – sometimes slightly obscurely but often clear enough that when you do find it (or the hint system kicks in) you feel that you were at fault for not finding it earlier, not the game.

(I’m aware that Uncharted 2 changes from yellow to red ledges at one point, something that I’m sure caused a lot of discussions on the team.  Ideally I don’t think it should have changed, though by the point that it did players were so far into the game that they inherently understood the rules of what could and couldn’t be climbed on because the rest of the art style remained consistent.)

Heads up

There was a big trend a few years ago to try and get rid of the traditional heads up displays (HUD), a feeling that it was an outdated method of relaying information to the player and that we can do better.  It depends a lot on the type of game, but when done well a game without a traditional 2D HUD can feel very good.  The problem is, it’s very rarely done well – King Kong is still one of the best examples of it.  So why is it so difficult?

Well, a lot of it actually comes down to these:

There’s a big desire from designers (and I’m guilty of this as well) to make sure that every button on the controller is mapped to a function.  And there’s a lot of buttons.  Which means a lot of features.  Which, in turn, means a lot of things to give feedback to the player on.  There’s a whole other discussion to write about with regards to balancing your feature set to the needs of your game, and also why gaming on a smart phone is so much more accessible, but for now I’ll conclude with this for designers: it’s absolutely fine to use every button on the controller, but be aware of the knock on effects that has to the user experience.  Every function you create, every feature added, has to be understood by the player.  There are many ways of achieving that, but don’t just believe that a 2D HUD can do the job for you.  It can go a long way, but if you get your entire art and level team on board as well you’ll discover there are many more tools in the box.

Well, to start with, here’s a small anecdote.  I was in the kitchen department of a big retail store recently when a cast iron casserole dish, in orange, caught my eye (not dissimilar to the one pictured).  It was on sale for half price.  I picked one up and headed to the counter, happy and cheerful at the bargain I was getting.  In the queue I looked at the box a bit more and suddenly realised that it wasn’t a Le Creuset casserole dish at all, but some other brand.

I have no doubt that the item I had in my hand was of equal quality and would happily serve me tasty stews for years to come.  But it wasn’t the brand I wanted, so I returned it to the shelf and walked out.

Such is the power of brand.

So what is brand?

Brand comes in many flavours, and I’m going to look at the two which I think are most relevant to the games industry.

The first is the brand experience.  The aim of this is to assure customers as to what the quality of the product is that they’re buying. This isn’t to say that every brand is of outstanding quality: this is instead about consumers knowing ahead of time what they’ll get. The purpose of the brand here is to remove the sense of risk, and instead instil a feeling of security in the customer.  This is why people will go into MacDonald’s when they’re on holiday – they know ahead of time what they’re going to get.  That small local burger bar next door is a risk. Some people relish in taking those risks, finding the new thing.  Others love the security that a brand will bring.

The second flavour is the brand image, kudos, or bragging rights.  I’m wearing Diesel jeans and therefore I must be better.  We end up in a situation where there really isn’t any discernible difference between brands, but we’ll have big fights in the playground to prove that my choice is the best.

How does this relate to games?

I’ll get to soon.  Before I do, it’s important to understand a bit about how the games buying market works. The games that sell in huge volumes, such as FIFA or Call of Duty, appeal to a very wide audience – far more people than the relative few who read gaming magazines, websites and post on forums. So how do they find out about games?

Well, obviously marketing is very important at this point – to sell something you need to tell people about it.  And this is where it can be difficult to understand from inside the industry: a small article or review of a few hundred words in a mainstream magazine (in the UK we have Nuts and Empire for instance) can be far more influential to sales figures than a 10 page mega-article and cover in PC Gamer.  I know: it makes no sense.  It simply shouldn’t be.

An important note here is that brand isn’t just about marketing clout. Yes, Activision spend a lot of money each year advertising Call of Duty at the Superbowl. But there’s something more than just money and the quality of the game. It’s to do with the knowledge from the mass market that they know the experience they will get from that game.  That’s why yearly releases can work, and why we get so many sequels.  It’s what the market wants.

Creating brand

The difficulty with brand is that it can take a long time to create that brand awareness.  A successful brand may have taken a very long time to get there – Apple is now the second largest brand in the world, yet ten years ago they were looked down upon many. So how do you create a brand for your game when you may only release one version of it?

I think that this is where games are the closest to films and, because of this, can learn the most from them. In a lot of films the brand isn’t the film itself but its director or its cast. The 1979 Superman film only got funding because it had Marlon Brandoattached to it. Even though he was only in a few scenes his name gave the film the brand it needed to get audiences in to theatres. From that point on the film stood on it’s own credentials.

It can be very difficult for a single person to become a brand in the games industry though.  And, in fact, it’s not necessarily a good thing: it’d be very tricky for Sid Meier to release a first person shooter as his brand is strategy games.  And AAA games are made by many, many people.

Building up a specific development team can work really well, Team Ico being one of the biggest that comes to my mind.  This isn’t always practical though – companies rarely have the luxury of keeping a whole team together for multiple projects as people get pulled off to help on other projects at different times or, indeed, left the company altogether.

So the most obvious course is to build up your company’s brand.  Take-Two have done a great job in promoting Rockstar (or, possibly, Rockstar have done a great job of supporting Take-Two…).  As with a lot of companies it took several goes at Grand Theft Auto before it really took off – GTA3 on the PS2 was the game that really shot Rockstar into the limelight, and from there their brand has been to create seemingly open world, story led, games.  Red Dead Redemption and LA Noire weren’t made by the Edinburgh studio, but they were branded as Rockstar games and have sold millions of copies.  Would that have happened without the brand image attached to it?  They would have sold well for sure as they’re good games, but I doubt they’d have sold aswell.

To move towards some sort of conclusion then, it is possible to use brand to your advantage inside the games industry.  It may take a while, but it is worth building up and will reap huge benefits if you are successful.  Your company image should be the strongest it can be, and the only way to do that is to be consistent in the quality you put out.  Achieving that quality is not going to be easy when there’s deadlines to meet and bills to pay, and the people most important in creating this quality are yourself and your staff.  Make sure you should treat your employees well and ensure that they are invested in the company as well: make them feel a part of the bigger picture, not just the next pay cheque.

Looking after your brand

Yes, I know, I just concluded already.  Damn it.  A final note on brand though – it can also be damaging.  This is a tricky area because all you have carefully created can be washed away with a few bad games.  The market will forgive you once, but it probably won’t a second time.  Once your brand is damaged your company could well be in trouble: sales of a great game could very easily be hampered by a bad reputation.  This happens across all companies and is a large reason for rebranding, from changing of a logo to a completely new name.

Brand saturation also needs to be considered.  Overdo something and people will get bored, or decide not to buy every single year’s instalment because they don’t see the worth.  Once you hit that point you should hit the breaks and ease off a little, and find out how to inject new life into your next iteration.

One of the best skills you can learn as a designer is the ability to deconstruct another game, to be able to see through its patterns and understand what makes it tick. From there you can analyse the rules behind the game, which can then help you reflect on the game you’re making and reverse the process.

This analytical skill exists in all businesses, and many creative industries revel in writing – and reading – retrospectives on how something was achieved. This is starting to happen more in games now as well, and it’s a fantastic way to share knowledge. It is not a sign of weakness to admit to having made mistakes, especially if people can learn from your experience and avoid similar pitfalls. And it can be enlightening to see how a different team approached a similar problem.

To give a guide of how to analyse a mechanic I’m going to look at Tetris, and use it to highlight elements you should keep in mind when designing your game.  I used Tetris for this before and my reasons are twofold: it’s nice and small, and it’s been played by pretty much everyone with access to a computer.  It also follows what I believe are the golden rules that all games should:

1. It has clear and consistent rules
2. It has clear goals (these are different)
3. It has an increasing challenge
4. It is always fair

And, like it or loathe it, it has been very successful over the years. If you want a quick refresher, have a quick play on JSTetris.

Starting an Analysis

The first step to analysing something is taking an overall look at it. Step back from an individual element and look instead at the overarching concept behind the thing you’re analysing. In this case, with Tetris, it’s quite easy: the main concept is to create order: place the pieces neatly together to score points.

Once you’ve worked out what the main concept is you’re ready to begin looking at the rules.  These aren’t mutually exclusive by the way: if you’re struggling to find the concept then start writing any rules you spot down and they may well help you find what you’re looking for.

The rules of Tetris

So, we know that Tetris is about creating order.  From here the rules should be pretty easy to find.

Rule 1: Starting with the obvious, there are seven pieces:

Rule 2: Each piece has a unique colour for easy recognition

Rule 3: Each piece is made up of 4 units.

Rule 4: The play area is 12 units wide and 22 units high (see the image to the right).

Rule 5: One piece at a time falls from the top of the screen.

Rule 6: The order the pieces appear in is random.

Rule 7: The player is shown which piece will come next.

Rule 8: The player can rotate and move a piece left or right.

Rule 9: A piece comes to rest a short time after it touches either the base of the play area or another piece.

Rule 10: If a complete horizontal line is created then that line is removed.

Rule 11: The player scores points:

1. Each time a piece moves down a line.
2. Each time a piece comes to rest.
3. Each time a line is removed.

Rule 12: The player scores bonus points for:

1. Forcing the piece down faster than the fall rate.
2. Clearing multiple lines at once.

Rule 13: As the player achieves preset score limits the level increases, speeding up the fall rate of the pieces.

Rule 14: The game ends when the falling block comes to rest touching the top of the screen.

Now what?

So, we now have our rules.  There are some variants of Tetris but, possibly apart from Rule 2, I think that’s the core set that have been there from the very start.  Each rule is strictly adhered to and clearly shown to the player, even if never explicitly taught.  As long as they know the controls, most people will pick it up quickly.

How does this relate to working out the rules behind a AAA game?  Well, in big releases it’s definitely trickier to isolate a specific mechanic and extract the ruleset behind it.  This is because there’s often a lot of overlap between mechanics.  It’s also because not all games manage to keep them consistent.  But it is possible.

Without going into as much detail, a quick analysis of the Active Reload in Gears of War.  The concept behind the mechanic is to make reloading your weapon into a mini-game and reward players who take a risk.  The rules behind it are fairly simple:

1. While the reload animation is playing, a progress bar is shown with a “sweet spot” indicated.
2. If the player presses the reload button at the right point, reward them.
3. If the player presses the reload button at the wrong point, punish them.
4. If the player doesn’t press the reload button again, just reload the gun as normal.

The reward is to finish the animation slightly quicker and give a damage boost to the first few rounds of the fresh clip, and the punishment is to make the reload animation last a little longer.  It’s a great system that works well, for two extra reasons:

1. The final few rounds in a clip make a noticeably different sound.  This makes players understand that the reload is about to begin without having to look at an ammo counter, and at the same time acts as a reminder to look at where the bar will appear.
2. The “sweet spot” is in the same place each time per gun.  So, pretty quickly, it becomes a natural rhythm to hit the sweet spot with your favourite weapon.

Once you’ve found your rules, it’s time to:

Focus on your goals

As before, it’s possible that you’ll start spotting the goals before you’ve found all the rules and, as before, finding the goals can help you look for rules.  But what are goals and how are they different from rules?

At any one time all games have three goals:

1. Long term: The overarching aim of the game.
2. Intermediate: What am I currently trying to achieve?
3. Short term: The second-to-second play.

This looks incredibly simple, and a lot of games have very similar goals.  With tetris they are incredibly clear:

A quick history lesson

All industries and economies are cyclical, and the videogames industry is no different.  Each cycle is roughly 6 to 8 years long, tied nicely to the big hardware releases.  In the PC market the cycles have often been driven by big hitting games that push new technology, often tied to the latest game that id software released. (I am aware this is a very broad generalisation – this is a quick history lesson after all.)

When a new console, or must-have graphics card, came out there was always the rush of early adopters: the hard core group.  These people want to show off their latest purchases, take days of work to play the few games that are released at launch and write their experience on forums across the globe.

Between a year to eighteen months later the price of the hardware drops, more games come out and the golden age for the console arrives: user bases rise, software sales soar.  Skip to the latter years and people have become a bit bored of the latest iteration of what was their favourite game and have become more picky about what they buy.  They want something new and shiny to play on.

We’re currently in the latter stage of a cycle right now.  But there aren’t any new consoles on the horizon.  (I’ll discuss the Wii-U in a future post I think.)  Why not?

Developers aren’t ready yet

I’m not trying to be controversial here, I’m simply stating facts: developers have not yet mastered the current technology sufficiently to bring costs of AAA development down.  In fact, quite the opposite is happening: costs are going up.  John Carmack summed up why in a recent interview with Eurogamer:

John Carmack: It’s interesting in that I don’t feel this current generation is close to tapped out. It’s different from previous console generations. If you go back a couple of generations, like a PSone or something, there were hundreds of programmers that knew what every bit in that machine did, and really had tried all the different reasonable directions you might go on there.

I don’t think there is a person in the entire world that even knows one of the current generation of consoles to that level.

Usually at this point in the cycle code bases have matured and the teams working with it know how to get the best out of it.  That is happening to some degree, but we’re not there yet.  To make a AAA release you either need lots of time (Rage is taking 5 years) or lots of people (Assassin’s Creed II apparently had over 450 at the end).  Ultimately we don’t yet have the tools at our disposal to create content cheap enough to populate the current systems.  And sales just aren’t cutting it enough.  It is possible to make insane amounts of cash but a lot of games aren’t doing that.

So why not?  Well, there’s the lull that always happens towards the end of a cycle.  But there’s a bigger change:

Gamers are changing

This isn’t to say that there isn’t still a whole batch of 18 year olds out there waiting to scream abuse down their headset at me when they kill me in the latest Call of Duty. That demographic isn’t going to change for a long time to come and I don’t think they’ll ever become bored of knife killing me from across a map, even if I have.

So, the early adopters are right there waiting for a new console to spend their money on.  But the spending power of that demographic simply isn’t big enough to support a new round of hardware.  Yet more money is being spent on gaming across the globe than ever before.  So what are all these people buying?

Well, you guessed it: they’re buying games on facebook and their mobile phones.  The types of games that are being bought and the price that they’ve being bought for has rapidly changed.  And here comes the reply from my crystal ball: I don’t think we’re going to see another round of “traditional” gaming consoles.  Consoles as we know it are going the same way as the arcade machines of the 90s and, while we’ll look back on them with rose tinted glasses, we’ll know we’re in a brighter future.

The interesting thing is that I’ve been pondering this article for a while now, and a few days before posting Brenna Hiller on VG24/7 has beaten me to it, which in turn reflects on the conclusion from David Wong’s article on Cracked (which I nearly didn’t link as pretty much every games related article in the last week has done so, but if you haven’t read it it is worth a look).  These in turn reflect on the thoughts of John Carmack, industry analysts and so on that cloud gaming is the future.

I think they’re wrong.

The power is in your hands

Computers get faster and faster all the time, because of Moore’s law (I’m not a relation as far as I know).  One of the top facts I used to love pointing out to people, even 8 or so years ago, was that you have more computing power in your cell phone than Apollo 11 had to land on the moon.  And that was before smartphones came along.  If space travel had progressed at the same speed as mobile phones do, we’d probably be able to get to Mars for a weekend break (assuming we’d found a loophole in the laws of physics).

The just announced PlayStation Vita is rumoured to have close to the graphical computer power of a PS3.  And it’s in your hand.  That’s pretty crazy, and faster machines are only going to get faster and smaller and, respectively, use less power.  And this is why I don’t think cloud gaming is the future.  Cloud computing definitely has a huge role to play in the future of gaming, but I think games running on distributed computers somewhere while you effectively portal into them isn’t going to be required.

With the combination of the amount of power you’ll have in your hands coupled with WiDi technology you’ll be able to transmit whatever is on your portable device onto whichever TV you like.  iOS5 will bring this functionality to iPad2 + Apple TV, and it’s only going to get better.  Cloud storage for games is definitely going to play a big part as well, Steam Cloud has been with us for over 2 years and you can save a game ‘Ruin’ on your PS3 and continue it on your PSVita.  But I think the computing power will be in your hand, that single device that can play whatever you want it to play.

This suits developers too – as the hardware in your pocket gets up to speed with the hardware we’ve working on for the last 5 years, toolsets and pipelines continue to get better.  APIs will develop to the point where it doesn’t matter what platform we’re working on – the game will just work.  There won’t be a single console manufacturer because the hardware won’t matter: the games will.

The games we’ll play

I think games are changing, because the desires of the audience are changing.  There is still going to be a demand for the big AAA games, but people are finding it harder and harder to justify spending £40 on a game they may not like when they can get lots of fun out of something for 79p, and play it wherever they are.  I don’t think we’re quite as close to gamification as Jesse Schell believes, but we’re definitely heading in that direction.

5 simple LEDs on the dashboard of my car have turned driving economically into a game.  My reward is cheaper fuel bills.  The smartphone era has made gaming more sociably acceptable than ever before.  We’ll still create 40-hour epic RPGs and Call of Duty games, and we’ll be able to play them whenever we like, wherever we are.  Against whoever we want.

And it’ll be fun.

Of course I could be completely wrong.  I won’t deny that I’ve struggled a bit with a nice tidy conclusion to this piece, so please jump in and give me your thoughts on where we’re heading.  What happens next?

In fact, it’s one of the strangest parts of working in videogames.  Job roles are getting more defined nowadays but there is still a long way to go.  Some areas have been fairly well set for a few years now: artists tend to split into character, environment, lighting or special effects.  And the last couple of rounds of console hardware has seen programmers become more specialised too, concentrating on gameplay, graphics, physics and the like.  Animators animate and the sound guys work out how things should sound.

But exactly what a designer does on a day to day basis is something of an unknown.

As with art and code, we designers fall into various categories.  Some design mechanics, which includes writing a lot of documents, statistic calculations and working closely with gameplay programmers.  Some design levels, which requires a lot of planning and close work with the level artists.  Some spend all their time knee deep in the toolset plugging data in.  Some do a bit of everything.  I’m not going to cover all of these in this post: instead I’m going to focus on what the lead, and the senior, designers do.

Everyone is a designer

One of the first lessons that you have to learn when you start making videogames is that absolutely everyone believes they are a designer. From your immediate colleagues to the man passing on the street: everyone has an opinion on what the game you’re currently working on should be like.

Usually this takes the form of an idea ripped straight from their favourite movie.  This is usually Indiana Jones or Aliens.

The job of the lead and senior designers on a game is to try and turn such ideas into something tangible and something cohesive.

Tangibility

This is the biggest part of being a lead designer.  Assuming that an idea fits inside the scope of your game, taking it and turning it into something tangible is tricky.  It doesn’t matter if it’s your idea or someone else’s: you have to delve deep into the high concept and learn how to break it down into components that can be made.

Continuing on the Indiana Jones theory, someone who happens to pay the bills has come along and said:

We’re going to make a game.  It’ll be awesome.  There’ll be this scene where you’re running away from a boulder down a narrow corridor, things crashing around you all over the place, holes opening up in the floor to jump over, spikes and traps everywhere.

Sounds great.

A designer’s job is to take this and turn it into a whole load of questions.  That single paragraph very quickly throws many up:

• Is it 3rd or 1st person?
• Which is the bigger threat – the boulder or the environment?
• Are there multiple routes?
• Does the player have control over the position of the camera?
• What can the player do?  Run?  Jump?  Duck?  Dive?
• Does the player have any weapons?
• How many lives does the player have?

The list could easily go on.  And each question breaks down into many more.  Once these questions have been asked, it’s then a job of making the decisions to answer the questions.  And then turning those answers into tasks that you can take to other people on the team to do.

For instance, lets assume that we’ve decided that the camera is 3rd person and not in the player’s direct control.

This breaks down into a task for a programmer to create a camera system that can run along a preset route (a spline), have a focal point (often the player but overridden to show traps) and junctions to allow the player to change direction.

A level designer will need to rough out the corridor, placing traps and working out where the boulder will roll down from.  They’ll then need to use the tools created to place the camera splines and test that it works, iterating the position of the traps, height of the ceiling and so on to make sure the player experience is as smooth as possible.

The character artist will make the player character and the animator will need to know all the types of move they need to animate (running, jumping, diving, various deaths that can occur), and so on.

These tasks are created in unison with the other people involved so they can be put into the schedule and made sure that the tasks fit.

The main designer working on the area of the game is responsible for ensuring that everyone knows what they’re working towards, what the aims are and feeding back on progress.  The also need to work out what tweaks and balancing is required to make it fun.

Cohesion

The other main duty of a lead / senior designer is to ensure that everything that goes into the game fits into the game.  This falls into two distinct parts: making sure that no one on the team is working on something that is irrelevant, and managing the expectations and desires of everyone involved with the game.

Irrelevance

Because games constantly evolve over their development process it is very common for designs and ideas to become outdated fairly quickly.  Ideas that have been discussed and written down and tasked can very quickly get chopped and changed.

All the leads on a project should be keeping a good eye on what the latest developments are on the design, but the lead designer has to make sure that they communicate out quickly and concisely any big changes.  The producer on the game should be a big support in this regard, but it’s often very tricky when teams grow in size.  Keeping up-to-date with what eighty odd people are all doing is a full time job, and this is one of the main areas where AAA games development needs to improve.

Expectations

As I said above, everyone is a designer.  Everyone has an opinion.  A good designer will be able to take the ideas that fit with the aims of the design and weave them into the fabric of the game, while calmly explaining why certain ideas don’t fit.

This can be very difficult because some ideas come along and sound great.  But a game isn’t just a collection of great ideas, just like a football team isn’t just a collection of great players.  Everything has to work in unison to achieve greatness, and this sometimes means shelving what in its own might be wonderful, but might upset the balance of the game.

Because of the way games are often funded there is always a lot of expectation from the people paying the bills, specifically the publisher.  Managing their expectations while retaining their confidence in what is being made is one of the hardest skills to learn.  This responsibility doesn’t fall solely onto the shoulders of the lead designer, but they are an integral part.  The best way to achieve this is via pillars.

Pillars

(This is actually the conclusion, just under a different title.)

One of the big pushes in the last few years has been for developers to really define the pillars of the game, a few core statements that summarise the ultimate goal of the game.

This is a very good thing, and you should definitely strive to define the pillars as soon as possible.  Well defined pillars help in all areas – from managing tasks on a day to day basis right up to helping the marketing team sell your game.  They should act as a filter: any idea that gets proposed should be checked against the pillars.  If it fits neatly against them all then it’s worth considering as something to develop.  If it doesn’t, put it in the box of ideas for the next game.

They should be short and snappy.  They should be understandable in an instant and not full of pontification.  An example: ‘the most realistic racing game ever made’.  Simple, clear and easy to dismiss people when they come along and ask for the cars to have weapons.

If you’re working on a game and you don’t have the pillars defined, or the whole team doesn’t know them, then get onto your lead designer.  It’s not just down to them to define the pillars, but it is completely their responsibility to ensure that everyone on the team knows what they are.

And that’s what a videogame designer does.

(This is an updated version of the post from my blog a few weeks ago.  Hopefully this is a better version.)