(Note: This post originally appeared on http://odiousrepeater.wordpress.com/)

Slowly, indeed far too slowly for my tastes, the mainstream games press and its clientele seem to be taking an increasing interest in games development. Granted, much of the interest stems from a desire for drama and controversy, and much of the time the wrong questions are still being asked (for instance "why does Peter Molineux promise too much" rather than "why would anyone even suggest a stupid idea like that in the first place"). But I'll take what I can get - at least we're getting somewhere, however slowly.

What I'd like to contribute is a unifying theme, a bit of a silver bullet if you will, that applies to many if not all of the stories of development woe we've been seeing lately. Thing is, even the well-researched and competently analysed stories are written in a bit of a vacuum; it seems like their authors don't see the common threads between their own stories and the stories of others because of superficial differences, or because their own understanding of what game development entails is insufficient.

A small digression: before we get started, I wanted to warn that I do a lot of linking to relevant articles and other resources in this post. I do this because I think it’s important to have some case studies to reference. The articles are long, and I understand that getting through all of them would be quite a project. Rest assured that you don’t have to read them in any detail to get through this post. I do recommend watching the videos though.

Anyway, here are the questions I'm going to set out to answer in this article:

1.) What are the common threads between the articles below?

Article about why Japanese games take so long to develop

Article about the cancellation and panic-mode-fixing of the game Singularity

Three articles about the rebooting and/or delaying of the high-profile games DriveClub, Watch Dogs and Final Fantasy XIV

Article about the development of HomeFront and subsequent closure of Kaos Studios

Another article about that same game

Piece about Firefall and Red 5

(And many, many more stories - most of which nobody will ever write about)

2.) How are the identified issues handled in the immediate term by developers and publishers?

3.) How does this all connect to the macro- and business-side changes seen in the industry in recent years, specifically the focus on online, episodic content, social, free to play and indeed indie development?

But while I do realize that the answers to these questions have merit in themselves, I also concede that stories and anecdotes are more interesting, or at least sexier, than facts. Especially bloody stories - metaphorically or otherwise. So here's some blood in the water for you.

About That Time I Got Fired

(A completely fictional story. Totally. Because lawsuits.)

"Really!?" I asked with a degree of honest surprise that the two men sitting across from me had seemingly not expected. I'm not sure what they'd imagined would happen when they told me that I was being fired, but I got the feeling that outrage or pleading or sadness - anything but the reaction they actually got - would've been closer to what they had prepared for. Instead I just sat there, looking at them incredulously for a few seconds.

To understand why we were in that meeting room, and why I was so surprised, we need to go back a few months. I'd arrived for a Lead Designer position at a quite large, financially healthy development studio working on a very exciting, branded game project. The pressure was substantial from day one. The license holder who'd given us the right to use their intellectual property to make our game was also invested in the development of the game itself, and a pretty strict timeline and budget had already been set by the time I entered the building for my first day of work. Worse still, the team was fully staffed up, but no real direction existed and there was quite a lot of friction between various creative individuals on the team. I was also replacing another designer who had been deemed less than ideal to provide creative leadership to a team of that size, but who was also not an idiot, and I felt like I needed to do well where he had done well, and also where he hadn't.

There were a few moments of truth during the course of the game's development. At one point I'd tried putting together a set of way-overdue, cursory design documents to provide enough direction for the team to work on the right things at the right time. The review meeting of that documentation was the first time I had the chance to sit down with the two men who'd later be firing me. This time, however, I was told that I'd just set the bar for writing design documentation for the entire studio. Incidentally, I probably looked pretty surprised to hear that too.

Everything was going quite well, from the publisher visits overseas to the iterations on the very early version of the game finally showing some sort of promise and progress. I had also managed to implement, with the help of some brilliant co-workers, some of the proprietary development practices that I still tour the world lecturing about to this day. The only real points of friction came up when I felt like people were getting a bit too "brainstorm-y" for how late in the day we all had agreed that it was, but such instances were few and far between.

What got me fired was, apparently, a senior management meeting. Initially sold as just a quick, shoot-from-the-hip update between the team leadership and a few key stakeholders, it ended up being a bit more than that. All the attitudes, assumptions and unrealistic expectations that I'd spent my time at the company forcefully removing from within the development team itself, I found were still alive and quite healthy among the people in that meeting. And because I thought that my results thus far spoke for themselves, I felt it reasonable to assume that I had the mandate to be honest and direct in explaining what I had thought was already understood by at least some of the people in the room - that we were in a sort of glorified, overdue pre-production phase and still didn't have the answers to every detailed question. That there was no reason to pin down monetization details that were predicated on gameplay details that were still being figured out. That there was no way in hell that we could make something comparable to a leading MMO with a team of less than 70 people in 18 months.

This, and apparently the "tone" with which I made my case, didn't quite sparkle with some of the attendees. Which brings us back to where we started; the meeting room where I was fired, about a week after that management meeting. I signed the papers, shook my boss' hand, and after a brief chat walked back home to decompress and look for a new job. I'd expected a medal for saving the project a lot more than I'd expected to get fired for pretty much the same reason.

A friend compared me to this man recently. Thanks! :)

Eventually, gradually, I'd end up feeling vindicated. First by the steady trickle of other team members either being sacked or leaving of their own volition, indicating the usual type of mismanagement and panic. Then by the departure of some of the people who'd been across from me in that management meeting I'd so unforgivably botched. Then by the constant re-staffing of the creative leadership (of course my immediate successor was sacked too), and rebooting of the game, the changing of its engine, the rumours of brand owner dissatisfaction and finally the deafening sound of silence - to this day the game isn't launched. It's gone over time and budget several times over, and I wouldn't be surprised if the next thing we hear is a cancellation notice or at least another delay, rather than a launch date.

So why does this make me feel vindicated? Because this specific scenario is exactly the one I predicted, and did everything in my power to avoid. It’s a scenario that stems from a problem that I’ve both before and since that project spent much of my time and energy trying to solve. The problem is that of waste - more specifically, the problem of the Dead End.

The Dead End: Destroyer of Worlds

The Dead End (or DE for short) is one of the biggest issues plaguing game development to this day. For various bad reasons, it's also one of the least understood and least discussed problems. One reason is that there are different types of Dead End that need to be avoided in different ways, by different members of the development staff. But all DE’s have in common that they put the game in a state from which it cannot (or at least should not) be developed further and/or launched, hence the name. To illustrate how some seemingly different scenarios can all end up putting the project in the same bad place, I've written a short and by no means exhaustive list of a few different kinds of Dead Ends. Do note that these can and often do happen on the same project, and that there sometimes is a causal relationship between them.

The Conceptual/Design-Related Dead End

This type of DE is where you find that one or more of the game's crucial systems or content are not panning out as expected and substantial redesign is necessary. We're not talking about small, isolated changes here - we're talking about the video game equivalent of finding during the course of production (usually way too far in) that the car you're building has two steering wheels in it. And even if the systems or content are not counteracting each other, they can still be intertwined to a degree where removing or tweaking one invariably requires the removal or substantial rework of the others. In the process, the feature set of the game usually suffers and much of the content that was built to support said feature set is forfeit. Sometimes this means losing 10 hours of a 20-hour game, just to describe it in player-facing terms. Sometimes it's even worse.

Example: The Reveal Video of Remember Me

To illustrate an example of a probable DE of this kind, let's look at the initial gameplay video from a 2012 build of the game Remember Me. Those of you who've played the game will notice that the final product was quite different from what's in that video. Indeed, the 2012 version is showing off stealth gameplay, a mini-map strongly suggesting free-roaming and free-climbing gameplay, substantial "world simulation" (civilians going about their business and the like), a more sandbox-style mission structure in places and a substantially more open memory remix feature set.

It is extremely unlikely that either the publisher or developer decided that these features, as they looked in the video from 2012, suddenly weren't good high-level ideas anymore. No, the likely scenario is that the video is more or less fake for the benefit of the press event it was unveiled at, and that behind the smoke and mirrors were a large number of unresolved conceptual (and other kinds of) problems. And because the problems ended up being unresolvable in one or more cases, the whole game ended up being more simplistic. One potential culprit is the free-form stealth gameplay. Take that away and having non-linear missions and progression becomes less important or interesting overall, and more trouble than it's worth. Not to mention the whole world simulation bits.

To provide another example: here’s a video from South Park: The Stick of Truth presented at a Ubisoft press conference prior to the game’s release:

(Mild spoiler alert) Those who have played the game far enough will know that in the final game the player is actually not taught that ability by Randy. It’s unclear what kind of changes had to happen to accommodate this rewrite, or indeed if the rewrite existed to accommodate some other type of change. It was most likely exclusively a content change for aesthetic purposes with no real impact on game systems, thus hardly a Dead End in the true sense. But I still thought I'd mention it because it’s a long article and farts are funny.

Technical Dead End

A technical DE is somehow related to the tools and technology used to power the game or its development. Like with all Dead Ends, it's predicated on faulty assumptions (after all, very few people ever knowingly risk finding themselves in an unrecoverable scenario). While there's no implied logical contradiction or design flaw in this type of DE, the loss of technical quality may still result in a game that's unplayable or unenjoyable to such an extent that the team ends up having to work just as hard to get around these issues as they would with conceptual ones.

Example: This video comparing the Demo and Final versions of Aliens: Colonial Marines

The video above speaks for itself (indeed, it's narrated). Where the Remember Me video showed off a feature set and design philosophy that didn't make it into the final product, this video highlights the differences in technical fidelity between the demo version and the final product.

It's pretty straightforward what happened here. The development team had a visual target that they were shooting for which they ended up incapable of hitting. What's quite interesting is the effort that was put into the "fake" gameplay footage that was originally shown off. Because of the gameplay similarities between the two videos, I can't help but feel that the original demo was, in fact, a playable demo that was prettied up to an unattainable degree. But if that were the case, why couldn't that same level of fidelity carry over to the final game? Well, it could be that the play session was pre-rendered in some fancy way that took the actual play session into consideration - someone fed the gameplay data into an engine that re-rendered everything at 5 frames per second, and that footage was later sped up. It could also have been some sort of hack job of an engine that only worked as far as that demo allowed, but was too inflexible to realize the rest of the game. It could be that middleware deals fell through, leaving the development team with a bare-bones graphics engine.

Regardless, something happened which made it impossible for the development team to deliver on their (frankly quite realistic) expectations, and they had to double back and scramble together a playable game with disappointing technology and assets in order to be able to launch anything at all.

Marketing/Political Dead End

There are instances of the two above-mentioned Dead Ends where the affected game may not be very fun or simply broken by too many bugs and therefore not launched. A third kind is where a game may in fact not only be solid, but also fun and polished - and still not get launched. I call this the Marketing/Political DE category.

Maybe the game is conceptually healthy and making steady progress, but it's simply not fast enough. If the publisher deems that reducing the game's feature set is not an option, the original date will end up overshot, which could be catastrophic for a product that's designed to launch within a certain type of timing window. For games that are movie tie-ins, this is such a massive no-go that it's more likely that the broken product is put on the shelves.

It could also be that everything is running very well in every regard, and then a competing product from a different publisher is announced. If that product's promised feature set or content or technology is superior and/or its launch date is more attractive than that of your own project, you may find yourself doubling back to shoe-horn a bunch of "improvements" into your own game to keep it relevant. Which obviously raises the probability of the previous 2 DE's, among other problems, and is guaranteed to delay the game further.

This category is also home to the games created by people with an ostensibly noble sense of "perfectionism", who will not release the game "until it's good enough". Trouble is, the reason these games are never good enough is that the same people aren't the right ones for the job - their quality threshold is higher than they themselves are capable of hitting. It's extremely possible that this kind of "perfectionism" will end you up in a Dead End that looks more like a death spiral; you think you're making progress, but you aren't really.

And by now the example I'll use will probably be obvious.

Example: These two articles on Duke Nukem Forever.

The death and rebirth of Duke Nukem Forever: a history

Learn to Let Go: How Success Killed Duke Nukem

Another example, again from the aforementioned South Park game, is that of the Nazi references that resulted in a recall of the game in German markets and a delayed launch.

How Developers Cope

When developers and publishers talk about "risk" they will mean a lot of different things. But whether they know it or not, the absolutely biggest risk to any project is a Dead End - either one of the types I've mentioned above or some other sort. Recently a former co-worker of mine wrote the following on Twitter:

It's a very poignant statement. Because while some issues like unfounded work load estimates and a fluctuating production pace are usually foreshadowed and can be mitigated against quite effectively, finding that you're making the wrong game (conceptually, technically or otherwise) always seems to catch people by surprise, and always means that massive amounts of work is potentially going to get thrown away and never help the game in any way.

I like to use the following quote from the Gamasutra article about Homefront I linked to above:

Imagine if the amount of time spent working on Dead Ends had instead been put into making the final product better. Hell, imagine if only half that time had been spent that way - but I digress.

So how are these problems avoided by the people who acknowledge them? Well, there are many methods for each individual problem, some more effective than others. Nintendo are champions of extremely stringent pre-production processes where pretty much every single risk is eliminated in a vacuum before level design is even considered. They also don't promise stuff that they haven't already delivered internally first - notice how late in the process they seem to announce their games to the public. The thing with Nintendo, though, is that they have loads and loads of cash to fall back on. Very few of their projects are developed in such a way that a given amount of time is given for pre-production, while also demanding a fixed launch date. Experimentation and production is kept separate for most of their games.

This is also a viable strategy for less wealthy third parties. There are ways of putting together early prototypes that feel close enough to the final quality while establishing a viable baseline for the final game if some of the more advanced ideas later end up not panning out. Look at this video from Platinum Games' Bayonetta prototype for instance:

A skilled team can put something like that together relatively quickly, and really - much of Bayonetta's final gameplay is more or less present in that video. If all they ended up doing was polishing that feature set to perfection, Platinum could very likely have still created most of the game's levels and assets at an acceptable level of quality without fear of having to throw anything away.

Another method is to simply take the "hit" of an extremely expensive first game with loads of waste attached to it, and then commit to making a large amount of sequels. "Sequelitis" as it's sometimes called is generally acknowledged as a cynical strategy of making games that the publisher is sure will sell, but it's just as much about dodging DE's. Let's look at a quote from that Sakurai interview I linked to earlier:

This is all well and good, but the scale of the Yakuza games is far less important than their predictability. Now, I'm no expert on the franchise, but I'm going to bet that as the scope of the products went up, their predictability did too. Scaling up the production values is generally a lot less risky for a game where you not only have a clear expectation of sales, but also know for a fact that you're virtually guaranteed to not run into Dead Ends. How can you know? Because if some new feature doesn't pan out, just revert to the feature set of the previous game with prettier graphics. The market generally doesn't punish that nearly as much as it would a missed holiday season.

There are still other approaches, more than I even care to mention. From various silver bullets like "lean" or "agile" philosophies/methodologies imported from other businesses, to newer and very game-centric methods like the Tiered Pyramid Method. And while these are all well and good in trying to improve the ways we do our day-to-day work and avoiding the dreaded Dead Ends, the industry as a whole has been shifting itself around at a macro/business level for the last ten if not fifteen years.

A New World Order

Now that we’ve established what Dead Ends can mean to individual games’ development, let’s revisit the concept of “risk”, but at a higher level. Whenever you hear CEO’s and Chairmen of Boards and other business-side people talk about their companies’ strategies, they will invariably mention risk. Whether they know it or not, much of the time they will in fact be talking about Dead Ends. Because while lot of things qualify as some sort of risk, the absolutely worst kind of risk is the Dead End, which by definition puts the game in a state where it cannot or at least should not be launched. The game then requires costly rework just in order to be marketable. It’s hard not to feel at least a little sympathy for the executives who might pay for a project to rival Grand Theft Auto in scope and quality, but end up with much less because half the game’s features and content had to be scrapped.

So now that we’ve established that “risk” more or less equals “Dead Ends”, let’s put the theory to the test. It’s hardly controversial to state that much of the industry’s efforts is moving away from so-called AAA, core game development. But how do some of the newer, non-traditional trends relate to the Dead End problem? Well, let’s take a look at a few examples:

Procedurally Generated Content

What it is:

Content (like levels, weapons, characters and entire campaigns) created by the game’s systems rather than the game’s developers themselves. The most popular examples of this type of content are various kinds of Role-Playing Games like the Diablo franchise (pictured) or the Borderlands games.

Why we do it:

Because the content-generating systems can combine predefined parameters to create more content than could ever be cost-effectively built by hand. For games where the whole selling point is a large set of content, these systems are absolutely crucial. Indeed, whole genres would become prohibitively expensive Dead Ends if not for these kinds of systems.

User Generated Content

What it is:

Content created by players, either through proprietary in-game tools, or with the very tools the developers themselves use. These tools are generally provided free of charge. Notable examples include Minecraft (pictured).

Why we do it:

Because some game genres require new content throughout their lifetime to remain interesting and viable, but the business model post-launch may not be able to sustain the expense of continuously keeping a team of content producers occupied post-launch. Some games like Starcraft, Counter-Strike and Warcraft have gotten new leases on life thanks to user-generated content, and made the whole E-sports venture viable in a way that it’s hard to imagine would’ve happened otherwise.

Online/Social Gaming/Free2Play

What it is:

Games that are connected to the internet and that are designed for players interacting with one another in different ways. Players can generally compete directly and/or indirectly, or co-operate to get further into the game. Notable examples include Clash of Clans and League of Legends (pictured).

Why we do it:

Because the interactions double as content in their own right, and increase player retention through various methods. In Free2Play games especially it’s very important that there is a large community of players, even non-paying ones, because that automatically increases the conversion rate (from non-paying to paying) and player spending. It also makes for very cheap content; players will play the same scenarios over and over again in a way that they never would against artificial opposition. If not for these social interactions, whole genres would effectively be Dead Ends for practical, if not conceptual or technical reasons.

Content Driven Games

What it is:

Games that, rather than focusing on creating content through systems choose to “brute force” the problem, keeping the systems simple and intentionally designing the content by hand. Some notable examples from not too long ago include Dear Esther, The Stanley Parable and Gone Home (pictured).

Why we do it:

Because there’s virtually no risk of Dead Ends. And while creating a lot of unique content is time-consuming per hour of play time (spending man-weeks of work on just the assets for one five-minute room is not uncommon), there is clearly a market for the type of experiences I mentioned above. And in many cases it’s better to work in a non-cost-effective but predictable fashion and be guaranteed to have a product at the end of the day, than to spend a lot of time on a bunch of systems that are total overkill for what your game needs to accomplish.

Smaller Projects

What it is:

Simply games with fewer features and less content. Like Flappy Bird (pictured).

Why we do it:

Because it drastically lowers the penalty for running into Dead Ends in absolute terms. It also allows us to experiment on multiple fronts, see what players like better and then focus more on those games in the future.

Smaller Usable Iterations

What it is:

Creating the game in small, usable chunks, and then releasing more of these chunks throughout the lifetime of the game. Examples include most online games, games with post-launch Downloadable Content (DLC) and episodic story-driven games like The Walking Dead (pictured).

Why we do it:

Because it lets us gauge consumer interest quicker, get paid throughout the course of development, and adjust the development roadmap of the game based on actual player behaviour. As a bonus, we also get to put together “complete” editions once all the content packs have been released.

Crowd-funding/Early Access

What it is:

Getting money directly from consumers based on an initial pitch on sites such as Kickstarter, and/or involving the players in development by charging for the privilege of playing a very early build and providing feedback.

Why we do it:

Because it lets us share the risk of Dead Ends with the user base and even sell some of our overhead to them. Sometimes fans will even donate free labour.

(Note: Of course there are plenty of games that do one or more of the above at the same time.)

Final Words

I hope this article has been at least somewhat illuminating, and that thinking of risk in terms of Dead Ends, and applying that prism when evaluating delayed, overpriced or disappointing games sheds some light on what may have happened – though it’s very difficult to ever know for sure what happens behind closed doors.

Incidentally, one of the most anticipated games of the last few years, namely Ubisoft’s Watch Dogs, has recently found its way into the hands of reviewers, and many are reporting a well-crafted but somewhat… bland and ordinary game. Remember, the game was quite famously delayed a while back, ostensibly to improve it to the point of excellence. So why would it come out solid, but bland and ordinary?

I can’t know what happened to Watch Dogs. But is it really likely that a game with that much hype and effort behind it had no more ambition than to become “just” another well-made free-roaming action/adventure? Or could it be that the opposite was true; that it was too ambitious, and that its most ambitious ideas simply didn’t pan out?

In that case, I wouldn’t be the least surprised if what actually happened during the delay was not that features and content were added. Rather, I find it much more likely that the delay was the consequence of the team finally acknowledging that a substantial portion of the game had, in fact, hit one or more Dead Ends. And in order to create a marketable product, that portion of the game had to be removed and replaced with something more ordinary, but functional (funny how one of the taglines of that game is "everything is connected", no?). Keep that idea in mind the next time you play a 5-year-in-development game that plays and looks just like a 3-year one. Maybe that’s because 2 or more years was lost on stuff that never actually made it into the game in any way, shape or form.

In other news, Warner Bros. recently announced the delay of Avalanche Studios’ Mad Max to 2015. I don’t have the slightest clue why. But you should feel free to speculate. And once you’re done speculating, consider scrolling back up to the beginning of this post and take the time to read some of the articles I referenced. I’m sure that your newfound knowledge will cast them in a somewhat different light.