Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 28, 2014
arrowPress Releases
July 28, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Dude, Where's My Game - The Truth and Lies of Delays and Cancellations
by Doru Apreotesei on 05/01/14 03:36:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

(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 DriveClubWatch 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 of mine compared me to this man recently. I can take a compliment, no problem.
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:

"Staffers say that the main development of Homefront was actually finished within one year -- with the first two years of its three-year development virtually wasted on ideas that didn't pan out, including nine months spent on a single-player prototype that got scrapped."

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:

"I think the Yakuza team is quite fast considering the scale of their games, and some foreign games can take over 5 years from initial proposal to the actual product release."

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.

A Dungeon from Diablo

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).

Minecraft

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).

League of Legends

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).

Gone Home

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).

Flappy Bird

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).

The Walking Dead

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.


Related Jobs

Integrated Military
Integrated Military — Remote Work Possible, Florida, United States
[07.27.14]

Software Engineer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[07.25.14]

DevOps Engineer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[07.25.14]

Animation Programmer
Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States
[07.25.14]

Server/Backend Programmer






Comments


Christian Nutt
profile image
FWIW, Jonathan Morin (creative director on Watch Dogs) recently told me that the delay was to get emergent gameplay systems functioning correctly in extremely complex interactions -- not something that most people would even notice, he conceded. Certainly not something any people would notice on early plays of the game, or in their initial impressions. Nor would that have an effect, from the sound of it, on things like the game's mission designs.

Ian Richard
profile image
My bosses always told people that our delays and overtime were just polish and bug fixes to make our good game even better. The rest of us were too busy putting out fires and desperately trying to prevent a complete failure.

Maybe Mr. Morin is right and everything is going according to plan to improve greatness to perfection but in my experience that is rarely the case.

I was really looking forward to that game but with recent news... all of my developer instincts are going off. I think I'll pass on the day one buy and let other people gamble on it.

Doru Apreotesei
profile image
Sounds like we've had some of the same bosses, Ian.

Just more proof that there's often an inverse correlation between competence and authority.

I remember this old saying out of the former Soviet Union: "We pretend to work, and they pretend to pay us."

In games, it's often: "They pretend to know what they're doing, and we pretend to believe them." That often holds true in Publisher/Developer relationship as well as between managers and employees.

David Lejeune
profile image
I learned a couple years in when I was working QA that 'delay for polish' was code for 'we've missed every milestone and it is a technical impossibility to ship on our original date.'

Given how often games that have been 'delayed for polish' ship with very little, if any, polish, I can't imagine that most people outside the industry haven't figured this out, too.

David Fried
profile image
Hopefully it adds enough depth that it becomes worthwhile. Then again, I don't know any game company that's going to admit to stripping feature sets that weren't working. It's too much like admitting they don't know what they're doing, which is often the reason they go down the wrong path for so long.

Jennis Kartens
profile image
Great article Doru! Really nice read and probably with a lot of truth to it for most projects.


"So why would it come out solid, but bland and ordinary?"

I wonder rather why it was delayed, since "bland and ordinary" is exactly what I expect of any Ubisoft product ever since they had their AC success and copied those mechanics onto other franchises such as FarCry... in that perspective, WD should've been on time. Maybe rather something technical...

Doru Apreotesei
profile image
Glad you liked it, thanks so much.

While we're on the subject of much-hyped and delayed Ubi games... one has to wonder what's behind that OTHER "true" Next Gen game of theirs being delayed, just now: http://www.ign.com/articles/2014/05/15/tom-clancys-the-division-r
eleasing-in-2015

Let the speculation begin I suppose. The official statement is the same as always:

"We are creating something we are really proud of and we don't want to compromise on quality. We are going to release the game when it's ready."

Paul Tozour
profile image
> So now that we’ve established that “risk” more or less equals “Dead Ends”,

This article makes some good points, but this statement is not really accurate. Most development risks are much smaller and don't equate to a full-on project pivot. I've seen a lot of projects die from "death by a thousand cuts" each one of which was nowhere near causing a "dead end," but which together, killed a project or made it less profitable than it should have been.

You're right that a lot of studios fail to spot the need for a major project pivot when the time comes, or don't admit that a pivot is necessary even when it becomes obvious, but that's not really something you can equate with risk itself. It's only the end state when risk management breaks down so completely that the project requires a full pivot or cancellation.

The real problem from my perspective is the much broader issue of the failure of disciplined risk management across most of the industry. Dealing with dead ends and the need for a pivot is only something you deal with when that risk management breaks down.

We need to focus much more on taking risk management seriously and making it central to our business and development processes.

Doru Apreotesei
profile image
I would argue that vanishing ROI prospects are a Dead End in their own right - I explicitly stated that there are many potential DE scenarios besides the ones I listed. As for death-by-a-thousand-cuts scenarios... did I not mention Duke Nukem Forever?

Maybe I'm having it both ways by throwing so wide a net, but I think I was pretty safely caveat-ed. Could have been even more, evidently.

As for whether the DE is its own problem or just an end state, I think that's a discussion that needs more than a comments field to do justice. I think we both agree, however, that one wouldn't end up in a situation requiring a large-scale pivot, as you put it, if one were better at early detection. That said, game projects are so horrendously complicated that it's extremely rare to see the type of risk management where people can follow a feature and content direction to its conclusion and, even without having built a single prototype or dummy asset, know that the direction's going to hit a wall.

Maybe you've had different experiences. If so, I'd like to be on projects that you manage.

Paul Tozour
profile image
I've been on a lot of projects that faced Dead Ends (some of which survived), but I've also worked on a lot of remarkably smooth projects that didn't really face any.

The latter still could have benefited a lot from a more disciplined approach to risk management, even though they never faced any dead ends.

The concept of 'risk' also applies to upside risks. If I sell a game and make $1m in profit, I'm financially successful, but if a different decision in development could have earned $2m in profit, that's a risk. And there weren't any dead ends in the process.

I don't mean to sound pedantic, but these distinctions are important.

> That said, game projects are so horrendously complicated
> that it's extremely rare to see the type of risk management
> where people can follow a feature and content direction to
> its conclusion and, even without having built a single prototype
> or dummy asset, know that the direction's going to hit a wall.

Oh, sure. But early prototyping and building dummy assets are activities that fall under the "risk management" umbrella, in addition to a lot of things the industry as a whole *doesn't* do.

Doru Apreotesei
profile image
"I don't mean to sound pedantic, but these distinctions are important."

Generally I agree; I'm kind of aware that I was doing a lot of simplification for getting the main thesis across, but there are quite a few caveats in there.

And sure, lost opportunity is strictly speaking a risk too - but then I don't see how that specific example is a good fit for a post primarily focusing on "the truth and lies of delays and cancellations". Making a 1 mil profit is very rarely something that gets a game cancelled. Especially after launch..?

"Oh, sure. But early prototyping and building dummy assets are activities that fall under the "risk management" umbrella, in addition to a lot of things the industry as a whole *doesn't* do."

Yes, that's in fact acknowledged in the article. I'm not really sure we're actually disagreeing here.

Paul Tozour
profile image
Just making the point that readers shouldn't take that line literally.

Risk management is what's really important ... development dead ends are a symptom but not the disease.

Doru Apreotesei
profile image
Agreed on both fronts, but with the caveat that until smaller risks amount to Dead Ends, they aren't quite as likely to result in delays and cancellations.

Matthew Fundaun
profile image
I once saw a youtube skit on this sort of thing: https://www.youtube.com/watch?v=BKorP55Aqvg

Worst part is all the engineers and such in the comments saying 'It's funny because it's true'.

I'm actually reminded of GAME_JAM and the related crash, too. Mismanagement and miscommunication certainly isn't restricted to video games, but it's still pretty agonizing to see this sort of Cassandra Truth.

I originally started my programming major because I wanted a job in making video games, but when I see stories like this, it makes me think I might be better off elsewhere.

Robert Carter
profile image
Ive had the same thought. I feel like Ive only just started my career and Ive already hit two Dead Ends described in the article. You put your heart and soul (not to mention free time) into a project for years at a time, only to have the project spiral downward into oblivion.

Ive tried a little work outside the industry, and though the pay and hours were better the pace was so slow it felt agonizing. I may not like 365 days of crunch but man, its almost worse to have 365 days at a snails pace.

I ended up back in the industry and am all the happier for it. Thank you Doru for the amazing article!

Robert Green
profile image
Great article Doru. I think these two comments reveal more than you let on:
"we were in a sort of glorified, overdue pre-production phase and still didn't have the answers to every detailed question"
"The thing with Nintendo, though, is that they have loads and loads of cash to fall back on."
The former is the reason for a lot of Dead Ends (TM) in my experience, and the fact that Nintendo have a lot of cash to fall back on may be precisely because they have such a great reputation for quality, which in turn may be largely due to avoiding Dead Ends to begin with.

Doru Apreotesei
profile image
That's right Robert. It's funny that Nintendo are often held up as examples of everything that's right with game development... but it's a bit of a skewed statistic. I mean, it is with everyone, but especially with Nintendo.

Because nobody is ever going to hear about all the games they've cancelled. Those are just quietly killed.

So their track record is, statistically, quite skewed.

And not a lot of other developers/publishers can afford to take hits like that.

Robert Green
profile image
I'm not sure we're on the same page there. My point was that before you write someone off as an outlier, you first have to check if they're an outlier because they're actually the best example of what you're trying to talk about. In this case it may be that Nintendo are the best at avoiding Dead Ends and making sure their games are fun before going into full production, and that's exactly why they have made so much money.
I'm speculating, but it sounds plausible to me.

Doru Apreotesei
profile image
Mmm, it's possible. But it's also not falsifiable at the moment. We'd have to know their hit/miss ratio. And misses usually come to the surface _accidentally_. Like when they were delayed and later cancelled or perhaps when they ended up being the death of the companies working on them.


none
 
Comment: