Abstract

The design of the game space is a major factor in shaping the player’s movement patterns and the player’s perception of movement (kinesthesia) in computer- and videogames, but very little research has been done into which aspects of the game world affect movement in what ways. Understanding the specifics of how space shapes movement is important in designing varied game worlds that affect the play experience in particular ways. This thesis analyses how different spatial structures give rise to different movement patterns in games with or without context-sensitive controls. The thesis analyses the dynamics between the game world, the controls, and the rules, and employs methods from user experience research to gather qualitative data about how players experience changes to each of these aspects of a game. The results demonstrate concrete relationships between different types of game space and different movement patterns and explain the player behaviour underlying these relationships, which will be especially valuable to those seeking to design environments for games where movement is a central part of the play experience.

Kinesthesia and Game Spaces is my Master’s thesis from the IT University of Copenhagen. It’s 70 of your regular human pages, which comes in just under 90 magic university pages (2400 characters per page). It was handed in on the 1st of November 2011, three months after the original deadline, and I defended it orally yesterday to the grade of 10, which translates into an A on the American scale or a B on the European scale. Not that the grade matters much to me right now, as I’m frankly just happy to have graduated with the least scientific Cand.Scient. in the country after 18 years of education.

I guess this marks a goodbye to this blog’s “University paper” tag.

You can download Kinesthesia and Game Spaces as a PDF weighing just under 2 MB.

Yesterday I handed in a 20-page paper on the topic of emergence vs. progression. I wrote the paper in April to get it out of the way so I could concentrate on my Master’s thesis, then proceeded to do fuck-all on the thesis for the entire month of May because I’m an idiot. The project was focused on the production of Archive X, which was meant to be an arcade-action game but turned out to be a puzzle game instead. In relation to the point of my paper, the game is quite a failure, but in and of itself it’s a pretty decent, if very short, puzzle game.

You might wonder how I could manage to work on two different Unity-based university games (Archive X and Broken Dimensions) at the same time. The answer is that I could not, and I did almost no real work on Archive X other than writing the original pitch document and putting the level geometry together in 3D Studio Max (a painful process which required me to first learn how to use 3D Studio Max). Most of the credit for the game should go to my class mate and programmer Isaac Dart (who is also not responsible for its failure to be properly emergent) and the rest is due to his partner in crime Juan Ortega and our artist Veselin Stoilov. They did most of the work while Ali and I were occupied with Broken Dimensions.

If you’re in the mood for a quick little puzzle game based on a very clever physics/chemistry simulation, feel free to download Archive X (111 MB). If you’re interested in the project and how it was used in my academic work, by all means grab the paper, Designing Emergent Gameplay (7 MB). I actually quite like it, it’s probably the first truly academic paper I’ve written at the IT University.

The exam is scheduled for June 16, and it’ll be my last exam before I defend my thesis.

I wasn’t sure whether to post this. Since I only got a 7 for it (a C on the ETCS scale, roughly a B on the U.S. grading scale), it’s the lowest marked university paper I’ve ever turned in, and sadly I think that’s completely fair. I prioritised Game Design over Game Theory, but most of all I got lazy.

I wrote the paper in literally a couple of days before it was due, I didn’t meet with my advisor at all, and I spent next to no time searching out material to base it on. As an academic work, it’s piss poor. There are barely any references, the structure is weak, the problem itself is poorly stated and even more poorly answered, and the conclusion is completely rubbish – my usual Achilles heel.

All that said, as a sort of super-extended blog entry, I really rather like it. I think I make some good points, I cover the most important aspects of the topic, and I explore three carefully selected examples of games that have approached the concept of Embedded Narrative in different ways. I’m strongly considering to write my master’s thesis about this topic, and just do a proper job of it next time – Embedded Narrative is a concept that interests me to no end.

So take this for what it is: an embarrassingly lazy academic paper narrowly redeemed by proficient writing, but worth a read for game design enthusiasts.

You can download it here shaped like a PDF:
Embedded Narrative in Games

It’s 8 pages and weighs a mere 212 KB. By all means drop any thoughts you might have on the topic or other feedback to the paper as comments on this thread.

Today (well, yesterday, truth be told, as it is currently approaching 2 am) was my Game Design exam. I felt well prepared and I was defending a project that had gone really well, so all in all I had a pretty good feeling about it. On the other hand, Game Design is my thing. It’s inextricably tied to my identity. It’s the one subject I have to ace. It’s like being examined in Being Jonas – it would be incredibly embarrassing to get anything but the best grade.

That’s how I felt, at least. And happily, it went as well as I could’ve expected. I got 12, as did my three group mates. The Danish equivalent of an A+, and it doesn’t get any higher than that.

By way of celebration, here is my individual report about the project , in a handy PDF file of 6 pages spiced up with a few screenshots for easier public consumption. You’ll be happy to know that it’s actually written in English this time.

The hand-in consisted of 4 parts:

1. The playable game itself.
2. Videos of usability testing, playtesting sessions, and a demo playthrough.
3. A design document.
4. An individual report from each group member.

On top of that, today’s examination had three parts to it:

1. A group presentation of 20 minutes.
2. An individual presentation of 10 minutes.
3. 5 minutes for Q&A.

It’s safe to say it’s the most elaborate exam I’ve ever had to do, but because I basically live and breathe game design, and in no small part thanks to the excellent collaboration in our group and my awesome group mates, I sort of had the home court advantage on this one.

Hopefully this will be enough to soften the inevitable blow to my ego when I get graded on the no doubt dreadful Game Theory paper I turned in before Christmas. But I’ll worry about that when the time comes.

As for the game… our plan is to polish it up, eliminating the remaining interaction issues, add another 30 or so levels to the current 12, code in a proper level progression mechanism, add sound effects, and then publish it on the App Store and see what happens. Rest assured I will pimp it here if we get that far.

Since I prefer to spare you the download, I’m posting the entire paper here, but I have also uploaded it in PDF shape in case you prefer to read it with more sensible margins and page divisions and all that jazz. Note that this paper wasn’t an exam project, it was just an exercise, so I’ve basically not bothered with references, and it’s only 5 pages long. Oh, one more thing: the conclusion is extremely weak. My conclusions always are. Enjoy!

Download the paper as a PDF

Introduction

In this paper, I will look at how Counter-Strike and Red Orchestra create a sense of authenticity to the situations in which they’re set. I’ll start by comparing their iconographies to determine their settings, then I’ll analyse how a degree of authenticity is achieved through the specific mechanics of the game design. The way I use the terms mechanics, dynamics, and aesthetics in this paper is taken from the MDA model by Hunicke, LeBlanc & Zubek, 2001-2004.

First, however, an extremely brief explanation of how I use the term “authenticity” in this paper.

Authenticity

I’m purposely avoiding the perhaps more popular term “realism” in this paper, because realism can be used in several very different contexts. It’s most often used to describe the visual fidelity of the game, and is used equally for describing the graphical technology powering them or the stylisation degree of the game’s artwork. Though the stylisation of the artwork is relevant to the topic of this paper, I’m more interested in how the realism paradigm applies to gameplay: as I use the term “authenticity”, it covers the effort to accurately represent (or at the very least invoke) a certain situation through the gameplay mechanics.

Setting

To begin with, I will now take a look at the respective settings of Red Orchestra and Counter-Strike with the central aim of identifying the differences in what the player might expect from each game.

Red Orchestra takes place on the east front of World War 2, where each map represents a battle between German and Soviet forces. I would expect most players to be familiar with this setting primarily through history classes and documentaries as well as fictional works such as films or books. As such, they might expect very harsh conditions with large forces suffering incredibly high casualty rates on both sides. Players might also expect slow and inaccurate weapons (by modern standards), unless they have been playing certain other World War 2 games, and when it becomes clear that tanks are available in many maps, it would not be unreasonable for players to anticipate that these are powerful but offer their crews very little assistance, and so would be difficult to use.

Counter-Strike is set in the modern day, each map representing a fictional encounter between terrorist groups and anti-terrorist forces. I expect that players’ reference frames would be a combination of terrorist fiction a’la Tom Clancy (be it in book, film, or game form) and the occasional news report from the “War on Terror” or events where SWAT teams or similar have been deployed. Whether the scenario is hostage rescue or bomb defusing, players might expect terrorists to strike in small groups, and anti-terrorist assault teams tend to be small and well equipped. Thus, the setting calls for somewhat smaller scenarios than Red Orchestra’s World War 2 setting.

Objectives

Both Counter-Strike and Red Orchestra have designed their gameplay mechanics around the paradigm of authenticity. The most straight-forward manifestation of this is the objectives of the different teams: Red Orchestra maps use capture points which either constantly award a team points while they’re under that team’s control, or start out entirely under control by one team who must then prevent the other team from capturing them. In my own experience, this tends to create a constant back-and-forth between the teams as they struggle for control of all the capture points. It also seems to match the type of conflict we expect from conventional warfare, where largely symmetrical forces vie for dominance over a strategically significant area.

Counter-Strike likewise uses objectives that support the anti-terrorism fiction quite well. Terrorists commonly use explosives to destroy landmarks and kill civilians, and hostage situations occasionally arise when the terrorists are cornered by government forces – these are the two scenario types that Counter-Strike: Source uses by default. Due to the nature of the fiction, scenarios will always be asymmetric: in bomb defusing maps, terrorists must bomb a particular location to win (usually one of a couple of options), while the counter-terrorists must defend this location or move in and defuse the bomb after it’s been placed. In hostage rescue maps, the terrorists start near the hostage and must prevent the counter-terrorist team from reaching the hostages and escorting them out to an extraction point. However, in both cases, the game can also be won by simply killing all members of the opposing team. This is possible due to Counter-Strike’s spawn system, which I will describe later.

Establishing objectives that make sense within the fiction are a fairly uncomplicated way to encourage certain behaviours in the players and achieve a measure of authenticity, but the paradigm of authenticity can also be found on more fundamental levels of the gameplay. Below, I will focus on specific areas of the core gameplay and analyse how authenticity is encouraged on this low level. I’ve chosen to divide the core gameplay mechanics into those pertaining to movement, weapons, and health or death.

Movement

Movement speed tends to be a significant factor in shaping how a game is played. Unashamed tournament games such as Quake or Unreal feature very fast and fluid movement, allowing players a high degree of flexibility and accommodating fast response times.

Counter-Strike has three modes of movement: run, walk, or crouch. The fastest mode of movement – running – is the default, and a key must be pressed to slow down. Crouching while moving has the advantage of making your footsteps silent, making it possible to sneak up on enemies. Though Red Orchestra also defaults to running, this isn’t the fastest movement mode in the game. Red Orchestra has a grand total of 5 movement modes, in order from fastest to slowest: sprint, run, walk, crouch, and prone. The fact that Red Orchestra does not default to the fastest movement mode seems to encourage slightly more cautious gameplay than Counter-Strike, where fast movement is often of the essence.

Both games have a way to limit your movement somewhat, especially to prevent the infamous “bunny-hopping” manoeuvre whereby players in a multiplayer game can repeatedly jump around their enemy to make themselves harder to hit. Counter-Strike’s method is simply yet effectively to slow the player down for a moment when the player lands after a jump. At the same time, the player’s accuracy is reduced slightly while in the air by way of increasing the probabilistic projectile spread of the player’s weapon, indicated by the slight expansion of the crosshairs.

Red Orchestra’s method is a little less subtle, but perhaps somewhat less arbitrary: players in Red Orchestra have a stamina indicator which is filled by physically stressful activity such as jumping or sprinting, while moving slower or standing still will cause it to gradually empty. When the stamina indicator is full, the player will be unable to jump or sprint for some time. Both of these features – Red Orchestra’s stamina bar and Counter-Strike’s momentary accuracy and speed penalties – serve to discourage grossly unauthentic player movement.

Stance plays an important role in Red Orchestra, mainly because several are included, but also because most of the game’s maps feature large expanses of terrain with little cover between objectives, and staying low can be the only way to avoid enemy fire. Much attention has been spent on the details to ensure that the different stances accurately recreate the most important affordances and restrictions that players would expect in real life, and to make sure each stance has its usefulness. For example, when moving while prone – the stance which affords players the smallest chance of being seen (and/or shot) – the player character folds his arms in front of him, making it impossible for players to fire their weapons while crawling. A particularly clever detail is that player characters’ heads are raised slightly when crouched and moving compared to when they’re crouched and stationary, which lets the players look over obstacles and quickly duck behind it for cover by simply ceasing to move if they come under fire. Aiming down the barrel will similarly raise the player characters’ heads a little, allowing the player to shoot from behind cover.

Finally, Red Orchestra has one major functionality in terms of movement which Counter-Strike lacks: leaning. By pressing a button, players can lean their character to the left or right to look around a corner or past a tall obstacle without exposing themselves completely. All these extra options for how to control your character in Red Orchestra support a considerably more slow and cautious play style than Counter-Strike tends to foster.

Weapons

It’s clear that a lot of attention has been put into making the weapons in both games look and behave as players would expect. This is most immediately obvious in the fact that they all represent real weapons such as the AK-47 or the MP5 in Counter-Strike or the MP40 or the Mosin-Nagant in Red Orchestra. More importantly, however, the weapons serve the same general purposes in the game that you’d expect them to do in real life (whether based on first-hand experience, war movies, or Wikipedia). In Counter-Strike, shotguns are useful up close but rubbish at a distance, and vice versa with sniper rifles. In Red Orchestra, bolt-action rifles fire far too slowly to be effective in close quarters, for which a sub-machine gun is preferable, but you’ll appreciate its range and accuracy if you’re fighting across a field.

The really interesting thing is the difference in how each game achieves this authenticity. Because Red Orchestra is so uncompromisingly detailed, it manages to create a lot of its most authentic dynamics by virtue of its simulation, where Counter-Strike must use slightly more artificial means to invoke the same dynamics. Weapon accuracy is a good example of this difference: when a bullet exits a rifle barrel, it will generally do so at a 0 degree angle, unless something is wrong with the bullet or the barrel. Any inaccuracy will be due to poorly adjusted sights, loss of projectile velocity at range, the effects of recoil on rapid fire, or simply bad marksmanship. Whereas Counter-Strike chooses to represent all these factors by the expansion or contraction of the crosshairs, Red Orchestra attempts to simulate most of them. Recoil in Red Orchestra will genuinely shake your aim, bullets will actually begin to drop when fired over great distances, and where the crosshair in Counter-Strike makes it far easier to aim than in real life, Red Orchestra not only provides you with no crosshair if you’re not aiming down the sights, your weapon is also slightly detached from your viewpoint, such that you won’t always be aiming at the centre of your display. Even when you use the iron sights, your aim shakes slightly to simulate your breathing.

Another ruthlessly authentic detail in Red Orchestra is that the game keeps track of the player’s individual clips of ammunition. Where most FPS games (and indeed Counter-Strike) simply divides your ammunition into two bullet “pools” – the bullets in your weapon and the bullets you’re carrying with you – which means you’ll always get a full clip when you reload your gun, Red Orchestra keeps track of how full your clips are, introducing the risk of working through all of them and eventually reloading only to find yourself with less bullets loaded than before.

Finally, I should mention that both games feature several pieces of tactical equipment that help players recreate authentic military tactics. Both games have smoke grenades, which can be especially invaluable in crossing some of those large exposed expanses of land that Red Orchestra usually features. Counter-Strike also gives players access to flash bang grenades, a piece of equipment which is central to modern assault tactics.

Health

The importance of health and death mechanics to shape the pace and feel of a game and to create a sense of participating in an authentic combat situation can probably not be underestimated. Broadly speaking, having more health points tends to make the game seem less realistic (if nothing else then because it encourages reckless behaviour that common sense dictates would get you immediately killed in real combat). Further, locational damage is widely regarded as a base necessity for authentic combat: getting shot in the head should have a greater probability of being fatal than being hit in the leg.

Both Counter-Strike and Red Orchestra give their players very little health compared to tournament games such as Unreal or Quake. Rather than dancing circles around your opponents, chipping away at their health, a single hit will often be enough to kill an enemy in Red Orchestra or Counter-Strike. Needless to say, this makes proper use of cover, tactical equipment, and teamwork much more important. As previously mentioned, Counter-Strike does allow players to buy more health in the form of armour, but in Red Orchestra, the only way to survive is not getting shot.

Both games also feature locational damage, though there’s a great difference in the fidelity of each game’s health systems. Counter-Strike doesn’t keep track of the health of individual body parts, but simply calculates damage taken in certain locations differently – a headshot deals substantially more damage than a shot in the chest, and armour that protects the head is more expensive than an armour upgrade that only covers your torso. By contrast, Red Orchestra shows players specifically where they’ve been shot, and hits to different areas of the player character’s body have additional effects such as making players drop their weapons if they’re shot in the arm.

Death

The re-spawn mechanics are one of the major differences between the gameplay of Counter-Strike and Red Orchestra. The death mechanics of each game are tied closely into their overall structure: Counter-Strike matches consist of a number of (usually fairly short) rounds, at the beginning of each of which most of the game state is reset – only the money and score of individual players as well as the equipment of players who survived the previous round is carried over. Since players only re-spawn at the beginning of a round, it’s not only possible but in my experience quite likely that one team will win the game by simply killing all enemy players.

By contrast, Red Orchestra uses a wave re-spawn system, whereby players are briefly queued for re-spawn such that they’ll usually re-spawn in small groups near the frontlines, ready to return to action. It’s possible for either side to run out of reinforcements if they die too much, allowing one side to win by killing enough enemy soldiers, but there will never be a situation where a single soldier is left on one side to fight a large group of enemies, which ensures that Red Orchestra always feels like a very large fight. This dynamic also means there’s usually a lot less waiting to be done in a Red Orchestra match than in a Counter-Strike match, where a spectator mode is all that keeps you in the game while you wait for the round to end so you may re-spawn.

Conclusion

It’s immediately obvious that Counter-Strike is a faster and in many ways simpler game than Red Orchestra. The difference is great enough that if you only look at these two games, you might even forget that Counter-Strike is meant to be realistic at all. I believe Counter-Strike was designed with enormous concessions to fun and accessibility, whereas Red Orchestra’s design is far more uncompromisingly authentic. However, my analysis of both games has confirmed my early impression that the fundamental difference between Counter-Strike and Red Orchestra is the detail level. The feature set of Red Orchestra is considerably larger than Counter-Strike, which a simple look at the key bindings of each game should be enough to reveal. This fact means that Red Orchestra’s simulation naturally produces a highly authentic aesthetic that the designers of Counter-Strike have had to “brute-force” into the system by introducing somewhat arbitrary features. Of course it seems likely that the authenticity Counter-Strike strives for is less to do with the real world and more to do with the worlds of action films and spy novels.

I won’t be posting all of it here, because some of it isn’t very good and a lot of it is directly related to Project Hyperion, the upcoming RPG I’m working on with the OTP team, which is under wraps for now. The short short I’m posting today (a bit of a steampunk pastiche written on the 14th) has nothing to do with Hyperion though, and I think it turned out pretty well, so I’m disregarding the fact that it went substantially over a page and posting it for your consumption. I hope you find it to be worth your time.

A Dark Turn of Events

Lord Wordsworth’s voice came in weak and tinny through the surface cable, “Agent London, your depth is nearly a nautical mile, do you have the goal in sight?” London squinted at the bow of the wreck in front of him, dimly illuminated by his electrical torch, “Affirmative sir, I’m disengaging in 10 seconds.” London activated the thruster pack on his back and cut through the murky water towards the wreck. “Understood,” Wordsworth replied gravely, “good luck, Agent. We’re all counting on you.”

London steered towards the half-rotten mermaid on the bow of the old ship, counting down the seconds in his head. The old figurehead was slippery with algae and difficult to hold on to, but he managed to pop the cable that attached him to the HMS Charles Dickens out from the back of his suit and wrap it firmly three times around the figure. Then he took his harpoon gun and a small transmitter off the cord and – having checked that the transmitter still worked – turned to face the deck.

The Richard III had evidently been an extraordinary vessel in its day. A massive ironclad ship-of-the-line, it had 50 gun emplacements and a deck very nearly the size of a cricket field. It was sunk only after days of bombardment, caught between three armoured frigates and the shore fortress that had once kept watch on the bay. Even then, it had remained in one piece. Somewhere in this ship were the dread pirate Charles Morgan and his gang, the Smiling Skull Crew. They had taken something important that the Queen wanted back, and Agent London was coming to get it.

He soared across the barnacled fo’c'sle, past the first mast towards a gaping hole in the deck. Approaching the edge of the hole, he angled his shoulder-mounted torch downwards to examine the chasm, when a harpoon shot out of the darkness and missed his face by inches. Acting on instinct, London punched his control lever and was thrust through the hole into the belly of the ship.

His torch illuminated the petrified face of a pirate through the man’s helmet for a split-second before London crashed into him and their momentum punched a new hole through the rotten wood behind him. The pirate struggled to regain his bearings, but London acted fast, smashing the glass of the man’s helmet with the butt of his harpoon rifle. He stayed on top of the drowning man until he was sure the pirate was dead, then London got back on his feet and surveyed his surroundings.

Weeds and barnacles had all but claimed this part of the ship. Looking up, the moon beyond the surface far above him was nowhere to be seen, and his own torch was all he had to navigate by. He turned it off tentatively, and now he could see a faint light emanating from a stairwell further into the ship. Leaving his thruster off, he moved through the upper cannon room as quietly as his clunky diver’s suit would allow, until he was standing at the top of the stairs looking down. At that very moment, another pirate turned the corner at the bottom of the stairs.

London moved to the right and pressed himself tight against the perforated remnants of the wall. Keeping one eye closely on the slowly ascending enemy and scanning his surroundings with the other, careful not to be surprised from another direction, London drew his knife – a long, jagged weapon that had tasted the blood of many pirates before this one. When the pirate’s heavy boots finally touched the top step, London struck swiftly, severing his air supply. London had the circumstances on his side: on the dark depths of the ocean floor, no one can hear your screams.

On the lowest floor, London found his quarry: an ornate jewel box carrying the royal seal. It seemed almost too fortunate that no more guards had been stationed to watch over it, and of course it was. As he turned around, royally crested box securely attached to the special magnet on the abdomen of his suit, he found himself suddenly face to face with the dread pirate Charles Morgan himself – and did his eyes deceive him? That was Lord Wordsworth at the pirate’s side, aiming a harpoon squarely at London’s head! What unspeakable betrayal was this? London discretely activated the transmitter attached to his thigh.

“I’m truly sorry old chap,” the Judas spoke over the short-range radio, “I do wish our professional relationship did not have to come to such a sad conclusion as this, but I fear there is only one way this can end.”

The filthy pirate captain sneered behind his suit’s visor as he finished the Lord’s sentence: “with you as fish food, London.”

The agent fixed Morgan with a piercing glare: “I should know that you would be too cowardly to face me in a gentlemanly fight, Morgan.” Then he shifted his eyes to Wordsworth, who found himself unable to meet his old friend’s gaze and looked instead at the floor, “But I underestimated your insidious influence. I won’t ask what heinous deal you two have struck, but if you expect me to simply lay down my rifle and let you execute me like some manner of honourless criminal, you are tragically mistaken.”

If the pirate had even an ounce of doubt about his own impending victory, his voice did not reveal it: “certainly not, Agent, I must say that would be a disappointment. Go on – reach for your harpoon and see if you can put a spear through me before I pierce your throat with my own.”

London shook his head, “what kind of reckless fool do you think me, Morgan? You have three men pointing harpoons at me, and you expect me to accept those odds?” Finally a flicker of uncertainty in Morgan’s eyes, he was no doubt wondering if there was an element of this situation that he had overlooked. London continued, “I have an altogether different outcome in mind.” Smiling defiantly, he detached the transmitter from his thigh and held it up in front of Morgan and Wordsworth.

Lord Wordsworth’s gasp was audible even through the distortion of the radio, but before he had time to warn the confused pirate at his side, an enormous tentacle crashed through the wall between them and swept the pirates off their feet, hurling them into the wood behind them. London punched the thruster lever and sped through the newly created exit as the tentacle withdrew from the shipwreck. Harpoons whooshed through the water past him from members of the Smiling Skull Crew now guarding the deck against London’s escape, but with his torch off, he was next to impossible to make out in the dark water, and soon he had disappeared.

Agent London would have to thank the brilliant engineers back in headquarters for their ingenious squid-attracting device, but first he would return to the Charles Dickens where he would have ample time on the way home to prepare his report to Her Majesty: He would be pleased to report that the mission was a success, but less pleased that Lord James Wordsworth had made himself a traitor to the crown of England, having sold his loyalty to the highest bidder, the dread pirate Charles Morgan.

Once again, Agent London had done his country proud.

Here’s the third and final part of my post-mortem of The Nameless Mod. I’ve chosen to cut it up into three posts because it’s very long. Two days ago, I posted the introduction. Yesterday, I gave you the five things that went right. Today, I’m wrapping it up with five things that went wrong. You can also download the whole thing minus illustrations as a PDF

1. We spent no time on pre-production

In stark contrast to Deus Ex’s luxurious six months of pre-production, we literally had none. Actual game assets were being produced from day one; before we’d even decided what the game was going to be about or what sort of story we would write, artists were churning out character textures and level designers were building maps. A month or two of recklessly disorganised brainstorming segued into a confused, hurried documentation process where we struggled to keep up with our own ideas. Since the project was entirely anarchistic in the beginning, nobody had to wait for permission to start pumping out assets, and little to no coordination took place between different designers or artists.

In and of itself, “don’t eliminate pre-production” may seem like a pretty obvious piece of advice, but what we were actually trying to do, in hind-sight, was iterative design: We were experimenting with the engine and the tools at our disposal, testing the capabilities of our team, and throwing our every idea at the game with no sense of restraint in order to see what worked and what didn’t. The approach could’ve worked out a lot better than it did if we’d made a conscious effort to evaluate the decisions we made and deliberately pick out the elements we wanted. Our team size and structure was even quite suitable for an iterative design model; we had around ten highly dedicated people working on it back then, and there was no management or budget to worry about, so we were free to mess around and distil the useful ideas from the poor.

Unfortunately we made the major mistake of not eliminating anything at all. Everything people created and every idea anybody had went straight into the design documents. In that way, we managed to waste what was actually a pretty healthy pre-production process because we treated it as full production. A lot of the bad ideas and decisions that made it into the game back then, we managed to replace or fix later down the line, but some of it can still be found in the final product because it’s simply too time-consuming to fix. File that one under “how not to do Agile development”.

2. We didn’t understand all the code

They say those who don’t know history are doomed to repeat it, but sometimes you know going into a project that you’re going to face some major problems, and there’s very little you can do about it. The sometimes makeshift nature of parts of Deus Ex’s code was one such problem we faced. Now, far be it from me to criticise the Deus Ex programmers – they did an amazing amount of work and unlike us, they were working under deadlines. But by their own admission, the artificial intelligence in Deus Ex wasn’t as well designed as it should have been and suffered even further for being constructed precariously on top of the Unreal Engine code.

To us, the problem wasn’t just that we didn’t want to mess too much with the AI code, and that we never had access to Unreal’s source code to fix some of the more persistent bugs we encountered, but that we didn’t fully understand how the code was meant to be used in the design. Our AI problems are the most illustrative example of that, but unfortunately not the only one. Deus Ex’s AI, it turns out, is pretty stable when it just has to be friendly or when it just has to be hostile. When you start mixing friendly and hostile (and perhaps even neutral, if you hate yourself) behaviours in the same area, the illusion begins to fall apart. What we did was to mix friendly, hostile, and neutral characters in the same levels, and then switch their alliances around depending on the player’s previous choices. It blew up in our faces, and it never stopped blowing up.

I suppose there were two ways we could have solved this problem: One was to sit down and rewrite all of Deus Ex’s AI code as early as possible. This wasn’t an option due to our extremely limited programming resources, so the remaining solution was to look very carefully at how Deus Ex’s characters had their AI set up and how the different settings were used, and then stick to that; but once we finally realised that, implementing such a solution was tantamount to scrapping everything and starting over from scratch.

Some of our levels really pushed the capabilities of the creaky old Unreal Engine. We had to cut almost half of this one and replace all its background lights with ambient "zone lighting" to make it stop crashing; and to be honest, it's still too big.

3. We had to compromise on quality

By the time TNM was released, our standards were pretty high. We screened our actors thoroughly for audio quality, we rebuilt entire levels dangerously late in development if there were too many problems with them, and we’d long since stopped implementing any feature if we didn’t feel that we could take it all the way. But of course, beggars can’t be choosers, and we sometimes had to compromise because we couldn’t pay people. The two areas where I think this is most obvious in the final product are level design and voice-over. For the voice-over, it was a hard and bitter struggle to secure solid actors for the major characters, but I think we largely made it. In terms of minor characters, the picture looks a little different: Many of them were recorded by ourselves or our girlfriends or by random fans. Even our good actors occasionally had sub-standard recording quality, which becomes obvious far more often than it should.

In terms of level design, the problems were technical as well as aesthetic. Some of our level designers were quite good at producing pretty architecture, but didn’t seem to grasp the design principles that made Deus Ex’s missions so exciting. Others had brilliant ideas and a great understanding of design, but their levels looked boxy and uninteresting. Some levels that were otherwise nice and well designed had been constructed entirely off-grid, causing substantial technical issues later on, and it’s painfully apparent that we never had an art director or a concept artist, making our levels vary erratically in style and tone. Far too late did we understand the concept of dividing level design tasks amongst a designer and an environmental artist, and even then, we never had the resources to do it in the first place.

Though this problem was emphasised because we were forced to make do with the generosity of volunteers, I imagine that too short a supply of talented team members who meet your standards of quality is a problem even commercial projects face, and I suspect that if I had a fool-proof solution for it, I could use it as the basis for a whole new article. In the future, we aim to conquer the problem by counting on a small team of only the most skilled and dedicated rather than designing a project that demands the participation of 50 contributors of varying talent and enthusiasm. In short, we’ll embrace the indie ethos and stop pretending we’re an AAA studio.

4. We didn’t test enough

We tried though. We gradually brought over twenty testers in to play the game starting several years before we were finished, and set up an online bug tracking system for them to report back to us with. We set up a forum specifically for the testers, and we sent out guide documents to everybody detailing how to install the test build, what sort of bugs they could expect, how to report them, etc. We evaluated our bug database and set up priority fix lists towards the end of the project to make sure all the really problematic bugs were fixed before release. When TNM was released, it had no major bugs that we knew about.

And yet the first journalist we sent the release candidate out to, before the download link was publicised, found a bug in the kill counting code which would close off an entire map prematurely due to a recent fix between the two last release candidates. We then spent an entire week fixing bugs in some sort of infernal post-crunch, followed by another month of slower, steady fixes. By the second patch, we’ve fixed around 240 problems, and we’ve more or less brought TNM into the state we thought it was in when we released.

There are three things we could’ve done to improve our quality assurance. First and most importantly, we should have been more careful to test our own work during development. Far too often, features and assets went into the game without any testing. In a game as heavily dependent on emergent gameplay as Deus Ex, it’s critically important to apply very thorough testing to everything you implement: If we had tested each of our new additions in combination with as many different factors as we could think of, that would’ve significantly reduced the amount of combinations that slipped through the cracks. Secondly, we should have set up some auto-testing: One of our programmers coded up auto-testing scripts a couple of months before we were done, which was far too late – we only managed to apply it twice before release. Since our plot had so many branches and variations along the way, being able to fast-forward through certain common branches would’ve been a great help earlier in the project.

Finally, we should have managed our testers more strictly. Unfortunately I’m not sure most of our testers would’ve responded very well to tighter management, but I suspect five dedicated and well managed testers would’ve been far more useful than a score of testers left mostly to their own devices. We tried to get our testers to commit to particular kinds of playthroughs, hoping we’d get all the branches covered, but it never worked because most people who volunteered to test weren’t interested in committing to anything beyond playing the game and writing down the major bugs they found. In summary, our primary mistake was that we skipped the organised alpha testing and went straight to beta testing.

One of our design tenets was that every mission should have some sort of gimmick or setpiece to set them apart from each other. For example, our final mission takes place on a space station, leading to much new oxygen- or zero-gravity-related gameplay.

5. Our project is a PR nightmare

The final and perhaps the hardest problem we faced was making people understand that our game wasn’t shit. We’d spent a lot of time making sure that people wouldn’t be alienated by our game and that we had plenty of depth and internal consistency to keep everybody interested, but we’d completely underestimated what a huge turn-off the basic idea of the mod was to so many people. Every site where we published our trailer, and every forum thread where people began to discuss the mod, one sentiment would immediately surface like a knee-jerk reflex: What an idiotic concept. Why would anybody spend seven years working on this fan-boy circle-jerk of a game?

We were pretty crest-fallen: We’d gone to such lengths to make sure TNM was a game, not just a joke, and many people wouldn’t even give it a chance because they immediately assumed the worst. But to make matters worse, we came to realise that we’d frontloaded all the Internet references, the fan culture and the memes and the in-jokes right in the first mission of the game. Part of this was unavoidable: The first mission served by necessity to introduce the player to our setting, so all the opaque references and Internet semiotics were presented to you immediately. Once out of the first introductory hub area, the setting would quickly slip into the back seat to leave room for the plot itself, but too many people seemed to never reach it, having lost all interest long before then. Since The Nameless Mod is free to download, we have no demo, but in terms of convincing people to invest their time in playing through TNM, that introduction area is all we have, and it seems to be doing a rather poor job.

Perhaps our greatest mistake was to tell people that The Nameless Mod was inspired by a real community that existed on the Internet at one point in time. I suspect people in general would be a lot more susceptible to our quirky cyberspace setting if they thought we’d just invented it as a Snow Crash-esque sci-fi take on the Internet, because then they wouldn’t associate us with the reviled genre of “forum fan fiction” to begin with, and once playing the game, they wouldn’t be expecting in-jokes everywhere. Much of the feedback we’ve received has implied that people constantly see in-jokes and obscure references when by far most of the game’s fiction was either invented specifically to suit the plot or the setting or twisted so far out of its original shape that it no longer bears any resemblance to the events or the people it was inspired by.

A well-known games journalist graciously defending our concept wrote: “no wonder everyone makes games with space marines being gruff”. I’d like to think people are generally open to new concepts, but I’ll admit that our premise and our setting do us no favours. Not, however, because TNM is too weird – there have been many successful games far stranger than The Nameless Mod and our world is quite recognisable when it comes down to it. But at the same time it reminds people of a genre of fiction which is almost never executed well. If we’d managed to set ourselves further apart from that genre with all the PR material we sent out, and if we’d done more to change people’s expectations before firing up the game, I think we’d had a much easier sell.

In Closing

In some ways, The Nameless Mod is a triumph for Agile development and iterative design processes. Not only did we learn how to make the game we were trying to make, we learned almost everything we now know about game development and project management. We learned these things by trial and error, and our errors pushed us to seek out the information we needed and apply it to our own work.

It’s unfortunate that we wasted so much time messing up and making bad design decisions. Part of this was because we didn’t manage feature creep as well as we could have, and part of it was because we got carried away with perfectionism, constantly recreating old assets to match our new standards. If we’d known what we were doing right from the start, TNM could probably have been released in 2006.

It’s been an incredible project though, and it’s changed some of our lives substantially. I think we ultimately came out on top of most of our mistakes, and we’re very excited to move on to the next challenge. With all the feedback we’ve received on The Nameless Mod, hopefully we won’t repeat any of the mistakes we’ve made. And now we have this post-mortem to help us remember them.

This is the second part of my post-mortem of The Nameless Mod. I’ve chosen to cut it up into three posts because it’s very long. Yesterday, I posted the introduction. Today, you get the five things that went right. And Tomorrow I’m finishing with five things that went wrong. You can also download the whole thing minus illustrations as a PDF

1. Designing for the niche

It took us far longer than it should have, but we eventually figured out how Deus Ex worked, what made it great, and what we had to do to maintain its core gameplay. We made the decision early on to stay loyal to the original game; Deus Ex was very well designed and had a clear high-level vision, and understanding the design principles behind the original game allowed us to support and polish the existing gameplay and create a new setting and plot reflecting but not imitating Deus Ex’s.

Judging from how TNM has been received, this was definitely the right choice. When developing a mod (or, one would imagine, an expansion pack or a piece of downloadable content or similar), it’s a safe bet that the people who will be interested in your product are the hard core fans, and so it’s not a bad idea to design your game for them. With this in mind, TNM had more freedom than Deus Ex and significantly more replayability. It also had a greater emphasis on role-playing, more long-term choice and consequence, and was a lot more difficult. None of these features help when it comes to accessibility, but to people who already knew Deus Ex’s gameplay well, our design seems to have hit the sweet spot.

Furthermore, most of our design choices were aimed at tipping the balance of the gameplay elements further towards role-playing and adventure dynamics: Talking to NPCs who react to your play style, making long-lasting choices, exploring large and detailed environments, tackling problems with thorough use of your character’s skills and abilities, etc. In other words, exactly what many role-playing fans seem to feel is missing from more commercially viable RPGs. It was obvious that people wanted more Deus Ex, and I believe we succeeded in delivering that, while adding our own stamp of uniqueness to the experience.

To familiarise himself with Deus Ex's GUI code, one of our programmers, Nick, implemented Pong with it. Then he got a bit carried away and did Tetris too. Then we demanded he also create Breakout and Lights Out. These minigames can be played by accessing certain PCs in the game world, and the players love it.

2. Turning a joke into a setting

One of our main concerns was how the scope and the aim of the project had gradually changed over the first couple of years. The Nameless Mod had started out as a small-time project aimed at a very limited audience, but after a year of development, we realised that we’d spent so much time and energy on the game already, we had to appeal to a greater audience – even though no money was involved, we felt that the more work went into this game, the more people needed to play it in order for our hard work to be justified.

Unfortunately, the game we were working on had a distinctly limited appeal: It was self-insertion fan fiction full of in-jokes, with a plot held together almost entirely by obscure gags and references to personal interpretations of events of no interest to anybody outside our small community. It was a mess, and it had to change. The primary way we did this was to bring people on board who had little to no attachment to our community and get their feedback. The fundamental causalities and motivations of the plot were rewritten, the setting was continually fleshed out and supported by explanations and player training, the fiction was tied together to make it more self-contained, the dialogue was repeatedly rewritten and edited to have fewer references and more character, and I did my absolute best to imbue the game with as much cultural relevance as possible, hoping people outside the development team would find it meaningful.

We started alpha testing relatively early, before the game was playable even half way, bringing in testers who had no knowledge of the Deus Ex community to get their general opinions and impressions about the game, and we improved the game in many ways with their help. The feedback we picked up immediately eased our worries: The game generally felt consistent, internally logical, and engaging. Nevertheless, we kept polishing the game as testing progressed and more people joined our QA team, realising that the unpromising concept of The Nameless Mod would be a hard sell. Judging from what chatter we’ve been picking up post-release, the general consensus seems to be that everybody hates the concept of the game until they actually play it, and that may be the greatest compliment we could get, in that we seem to have pulled off what most people considered impossible.

3. Managing complexity

Deus Ex was a complicated game with many different genre elements and many interacting and overlapping gameplay systems creating joyously unpredictable results in the hands of its players. Lead Designer Harvey Smith famously used the phenomenon of grenade climbing (utilising the fact that wall-mounted grenades have collision cylinders to scale a wall by jumping from grenade to grenade) to illustrate the dangers of emergent gameplay. We’ve always considered the benefits of emergent gameplay to be well worth this “undesirable emergence”, and so one of our main goals was to add even more complexity to the game, both on the narrative level and the mechanical level.

In terms of gameplay however, we had an easy time compared to Ion Storm: Rather than having to invent an intricate web of game systems ourselves, we had the luxury of simply expanding on and tweaking a tried and tested set of mechanics. We chose to keep almost every object from Deus Ex (be it items, augmentations, or skills) and just add our own creations to this already sizeable collection. When we did change objects from the original game, it was to add further features to skills or augmentations that were widely considered to be less useful than their alternatives. We also had a lot of fun adding further layers of interaction to the game world, identifying such incidental interactivity (flushable toilets, readable emails, playable pool tables) as one of the great strengths of Deus Ex.

The real complexity came from our extremely ambitious plot design. I’ll be the first to admit our ambitions in this area passed far beyond the boundaries of reason. One of the major points of criticism of Deus Ex was that you were apparently offered a choice of whether to leave an organisation, only for that choice to be made for you. I wouldn’t call this a reasonable criticism, considering how much extra work such an option would’ve called for and how poorly it would’ve worked with the overall concept of the game, but we still decided to give the people what they wanted: two parallel, mutually exclusive storylines.

The key to basically creating two games in one turned out to be – perhaps unsurprisingly – reuse of assets. Early experience taught us that levels were the most expensive type of content, so we had to minimise the amount of unique maps per storyline. The cheapest resources turned out to be dialogue and gameplay scripting. Thus, we let most of our missions take place in maps that served other purposes as well, for example having one faction task you with breaking into the headquarters of the other faction and vice versa. By switching out all the plot-relevant dialogue depending on the storyline, but keeping the same maps, weapons, and characters (as either enemies or allies depending on the player’s choices), we were able to create drastically different plotlines without too much unnecessary work.

That said, designing levels to be your home base in one case or a hostile mission area in another case, and writing and scripting characters to be either allies or enemies complicated the game logic more than was perhaps necessary, putting incredibly high demands on quality assurance – but I’ll save that for the What Went Wrong section.

Weapon renders are a bit of a modding cliché, but heres one anyway! Our weapon designs were pretty much improvised by our 3D artist, but we managed to come up with unique functions for them that didnt just duplicate weapons from the original game.

4. We released!

We actually finished the game after 7 years of work. Though many were itching to count us among the many over-ambitious total conversions that would never release anything before the developers eventually gave up and called it quits, we never stopped working on the mod. We had periods of low activity, but at any given time, somebody was always making progress towards finishing The Nameless Mod.

The fact that we released was largely down to three factors, chief of which was sheer determination to see this through. Though TNM started out as a pure hobby project, a couple of us realised along the way that game development was something we wanted, nay needed to do for a living, and we’d be damned if TNM wasn’t going to be the greatest portfolio piece in the history of game design. There was also a pervasive sense that we’d come too far to give up on the game now – one does not simply sacrifice 4-6 years of free time on a project only to walk away from it when the end was in sight.

Even with this hell-bent determination to see things through to the end, we would never have finished anything if we hadn’t started to reign in our own creativity. Feature creep was the engine that kept us running up to a certain point, but then it started to become a real problem – we weren’t making nearly enough progress towards actually finishing the game, instead spending our time on whatever new features happened across our minds. Somewhere around 2006, we started making lists of what we had left to do and plans of how to finish it all. In other words, we became more responsible, more organised, and more professional. Eventually we entered feature lockdown, then complete content lockdown, and then we were done. Turns out the way to get things done is with good management.

5. Post-release support

After 7 years of development, most of us were really eager to put TNM behind us and start up a new, independent project – something we might actually be able to make money from eventually. Unfortunately that would have to wait. By the time we released, Deus Ex was a very old game, and in our infinite ambition, we’d been messing with the native code and adding a couple of our own features to it, such as an OGG music player – in short, it crashed a lot. Furthermore, it turned out that thousands of players are better at finding bugs than 20 volunteer testers (who would have thought?)

We started fixing bugs the day The Nameless Mod was released. When we built the release version, we were almost certain there were no significant bugs left, but hundreds of people signed up to our forums to tell us otherwise. The first patch was released after one very long, very hard week of the worst crunch I’ve ever experienced, and fixed around 140 bugs. The second patch was released a month later with over 200 fixes. Though this sounds like a lot, it’s actually fairly good considering the scope and complexity of the game, and the fact that we had very few really dedicated testers and no systematic testing procedures in place.

Most importantly though, we got them fixed very soon after release, with the help of our community, and we’re not done with the game quite yet. We’re also cooperating with a few other well known Deus Ex mods to help make sure their work is compatible with TNM. Finally, we’ve been providing thorough support to people with installation problems or other technical issues, going so far as to monitor TNM discussions on other forums to intervene with help when it’s needed. All of this, combined with some very open and honest communication throughout, has earned us a lot of good-will with the community that we might otherwise have lost to a reputation for releasing a bug-ridden mess of a game.

Promotional artwork of Trestkon.

Now that GameCareerGuide has had their 30-day exclusive on my post-mortem of The Nameless Mod, I’ll be reposting it here for posterity and convenience, and in its original UK English. It’s fairly long though, so I’m spreading it across three posts. Today, you get the introduction. Tomorrow, the five things that went right. And Friday I’m ending it on a raised index finger with five things that went wrong. You can also download the whole thing minus illustrations as a PDF

If we’d known what we were getting ourselves into, we’d have run away screaming. The Nameless Mod for Deus Ex stands out for a couple of reasons. First of all, it’s a single-player total conversion, which isn’t the easiest or most popular category of modification on the Internet. Secondly, it’s enormous: The Nameless Mod features over 14 hours of voice-over, the average length of a playthrough is 15 hours, and that’s just playing one of two significantly different, mutually exclusive plotlines. Third, and arguably most notably, The Nameless Mod has been finished and released to very favourable reviews. The project was in development for 7 years, 2 months, and 11 days by an international team of hobbyists who never met each other. It placed enormous demands on communication, leadership, and quality assurance, and to top it all off, it started as that most reviled of genres: Forum fan fiction.

Back-Story

The Nameless Mod for Deus Ex, released 9 years after Ion Storm’s magnum opus, strives to reproduce the multilinear design and unique aesthetics that made Deus Ex such a widely beloved classic. While expanding on Deus Ex’s core gameplay, the Nameless Mod also introduces players to an outrageous new world which is at once an homage to, and a satire of Deus Ex, its community, and the Internet at large. Playing as Trestkon, a respected veteran returning to his old Internet forum, the player is charged with investigating an apparent abduction which takes him deep into the history and politics of the community.

Game Data

Release date: March 15, 2009.
Genre: first-person action/role-playing game; cyberpunk spy thriller; pop culture satire.
Core team size: 1 producer, 1 lead designer, 1 dialogue manager, 2 programmers, 5 level designers, 1 3D artist, 4 2D artists, 1 sound designer, and 3 composers.
Additional contributors: 4 programmers, 6 level designers, 6 2D artists, 4 writers, 6 sound designers, 5 composers, 23 testers, and 74 voice actors.
Length of development: 7 years, 2 months, and 11 days from conception to release.
Notable technologies: Unreal Engine 1 and the Deus Ex SDK including UnrealEd and Ion Storm’s ConEdit. One of our programmers added OGG music support.

The Concept

I would be lying if I said we had a game of TNM’s final scope in mind when we started out in January 2002. We were originally planning a single “fan-mission” – one or two maps connected by a simple, quickly grasped plot, with the twist that the characters in the mission would be based on the users of GameSpy’s PlanetDeusEx forums where the team was formed. It was a premise that betrayed our low expectations for the size of the audience we would be able to reach: we were just making this for our own community. However, the self-indulgent concept turned out to be a huge help in attracting qualified help. Everybody who joined got to be a character in the story, and who doesn’t want to see themselves in a game? As the team grew, the scope of the project slowly grew as well, and the concept was expanded. We decided to take it even further, making the plot actually take place on the forums, in a virtual world inspired by the stories and the imaginary spaces we’d created for each other.

The most central part of the concept was never actually discussed nor given thought for the first large part of development – it was a given, an unspoken rule that we all agreed upon: we would remain loyal to the original Deus Ex gameplay. Unfortunately our project initially suffered from a lack of conscious design: As we didn’t have a lead designer until a couple of years into the project (I was a dedicated writer to begin with), we had nobody responsible for analysing and recreating Deus Ex’s gameplay, which is why our initial designs missed the mark in several important ways. Our first concept was designed to be one very large hub level with complete freedom to move to the connected maps and handle the missions in any order. A prototype of the hub map revealed several problems with the single-hub structure, greatest of which was Deus Ex’s old Unreal Engine 1 and its hard limit on level size.

Through four revisions of the first design, we eventually settled on a design more closely matching Deus Ex’s own structure: A largely linear plot with branches and variations along the way, taking you through several hub levels. Unlike Deus Ex, however, we chose to branch the main plot into 2 parallel storylines early on. We also chose to connect our three hub maps and distribute the missions across them all so the player could move freely throughout the game world with a single “point of no return” about half-way, giving us an opportunity to reset the game world and move time forward to show the effects of some of the player’s actions. The result of these decisions was a game structured much like Deus Ex, but with far more freedom for the player to change the plot and far more optional content, but also a significantly shorter critical path.

The amount of information we supplied our level designers with varied a lot depending on how much faith we had in their design skills. One of our designers was a professional, so we just sent him this MS Paint schematic illustrating the structure of the mission and its primary objectives.

The Production

Initial development was incredibly chaotic. We had no well defined team structure and no communication infrastructure to coordinate our work. Level designers began to build maps before the plot had been written, characters were created based on the online personas of the forum users and were then written into the story afterwards, and weapons and items were constructed on the basis of a cool idea with no thought as to how they would fit into the game. The design documents were retroactively written around game assets that were already being created, taking input from everybody on the development team and anybody else who cared to contribute on the forums.

Over the course of several years, we gradually got a handle on the project. By trial and error, we worked out a sane workflow and a reasonable team hierarchy, established reliable communication channels, and developed a solid understanding of our own project and the game it was based on. Whether by natural evolution or a lack of imagination, our final team structure was very flat, with our producer Lawrence Laxdal and myself functioning as the intersections of all communication. We became more demanding of our contributors and learned to quickly let go of anybody who didn’t keep their promises. Moreover, we all became better at our respective crafts. Though this was a benefit for obvious reasons, in terms of scheduling, our perfectionism proved to be a problem. We estimate that 90% of everything we created in the first 2 years was later replaced, redone, or removed as our skills improved and we saw the flaws in our previous work.

When almost all our level assets were completed and we had a playable alpha, we took a good hard look at what we had done and what we still needed to do, and then we began to cut down on the feature creep. We’ve almost regarded feature creep as a form of currency with which we’ve paid our team – for every hour somebody has contributed towards finishing the game, we had to let them spend X amount of time working on their own pet features. As the project neared completion, we reduced X until the project entered feature lockdown around the summer of 2008. By this time, only the most dedicated team members were left.

The final stage of production was dialogue audio and quality assurance. The process of recording the over 195,000 words of dialogue in TNM began several years before release and is notable for making use of a large amount of professional or semi-professional voice-over artists who contributed entirely for free. For this enormous project, we created an online database system which kept track of every character in the game, every conversation node attached to that character, each character’s actor, the status of their lines, and which of our audio engineers was working on them or had worked on them. Early on, we recruited somebody specifically to oversee the voice-over process, and towards the last phase of the project, Lawrence and I ended up spending most of our time helping out as well. We always knew the large amount of volunteers would be a liability to the time frame of the project, but in the end we managed to wrap up the recording process about a month before we were finished with QA, much to our surprise. Three release candidates later, The Nameless Mod was finished.

If we’d known what we were getting ourselves into, we’d have run away screaming. The Nameless Mod for Deus Ex stands out for a couple of reasons. First of all, it’s a single-player total conversion, which isn’t the easiest or most popular category of modification on the internet. Secondly, it’s enormous: The Nameless Mod features over 14 hours of voice-over, the average length of a playthrough is 15 hours, and that’s just playing one of two significantly different, mutually exclusive plotlines. Third, and arguably most notably, The Nameless Mod has been finished and released to very favorable reviews.

The project was in development for seven years, two months, and 11 days by an international team of hobbyists who never met each other. It placed enormous demands on communication, leadership, and quality assurance, and to top it all off, it started as that most reviled of genres: forum fan fiction.

And then I go on to talk about the development process and describe 5 things that went right and 5 things that went wrong, in the usual fashion. It’s as honest as I could make it, and I hope you can find the time to read it, even though it’s quite long. The post-mortem may be found here.