In the wake of today’s news that Cyberpunk 2077 has been delayed to September, you may be wondering: why do so many video games get delayed? The answer is extremely complex.
Editor’s Note: This article was originally published on 24/5/17, and has been updated to reflect the latest news.
I heard a few explanations for game delays while reporting for my new book on game development, Blood, Sweat, and Pixels. During this process, I spoke to developers who’ve worked on everything from massive RPGs like Dragon Age: Inquisition to indie platformers like Shovel Knight, asking them lots of questions about why they have to do things like, say, delay their games.
The simplest reason is that, in game development, making an accurate schedule is impossible. Even the most conservative estimates at the beginning of a project can’t account for obstacles that will come up along the way.
Sometimes a level that a game creator thought might take two weeks actually takes closer to two months. Maybe they will find out midway through production that their cool new idea for a combat feature isn’t fun, forcing them to spend months fine-tuning to make it better. And there’s never any way to predict how many bugs will pop up toward the end of development, which is why we so often hear that games are being delayed for “polish” — to catch and fix those bugs. These pitfalls don’t just affect first-time developers. Even the most experienced veterans wind up battling time.
“We are constantly reevaluating our schedule,” said Feargus Urquhart, CEO of Obsidian Entertainment, during an interview last year. “Constantly.”
When Urquhart and his team first started making Pillars of Eternity in the fall of 2012, they plotted a schedule that would take them to 2014. But they ran into numerous complications during production, including scope issues (the planned game was too big), story issues (their lead writer was caught up on Obsidian’s other project, South Park: The Stick of Truth, itself delayed for many reasons), and thousands upon thousands of bugs. Eventually, Obsidian bumped Pillars to March 2015.
“Our Wednesdays are now Scheduling Wednesdays,” said Urquhart. “From 2pm probably until about 5pm, I will be sitting in a conference room, and we will be looking at charts and tables and graphs, and talking to the teams about how they’re managing their schedules and their features and their resources. Where were we last week, where are we this week, where are we gonna be next week, how are things going, are we gonna make our dates, are we not gonna make dates, what are some problems, what do they need help from us.”
Sometimes games are delayed because they’re just not good enough yet. Development studios like Blizzard, infamous for promising that their games will be “ready when they’re ready,” are big on “iteration,” a common game development buzzword that refers to the act of changing and changing a game’s features until they’re just right. Blizzard has delayed games like StarCraft II and Diablo III for that purpose.
“We always like to have a plan,” said Wyatt Cheng, a veteran Blizzard designer who worked on Diablo III. “But we’re flexible on that plan if we have to be. So we have a target, and we try to hit our dates when we can, but we’re also willing to change in light of new evidence, or new discoveries.”
“The quality of the game should be dictating what you’re doing, not a date you agreed to 15 months before,” said Blizzard producer Rob Foote, who also worked on Diablo III.
The recent Specter Knight campaign for Shovel Knight came out two years later than the developers had originally hoped.
Blood, Sweat, and Pixels consists of ten chapters, each focusing on a different game. When I was picking those games, I tried to select a variety of scopes and genres, from massive AAA adventure games like Uncharted 4 to one-man indie farming sims like Stardew Valley. What surprised me most during the reporting process was learning that all ten of these games had been delayed — even Star Wars 1313, which saw several delays before Disney shut down LucasArts, cancelling all of the studio’s projects.
With very few exceptions — namely, annualised series like Madden and Call of Duty — it’s hard to find a video game that hasn’t been delayed. Even games that appear to come out on time have usually seen at least one internal delay before their release dates were publicly announced.
“Things just always take longer than you think they’re going to,” said Sean Velasco, the director of Shovel Knight. Velasco and his team originally hoped to release Shovel Knight in March 2014, then put out the subsequent boss knight campaigns (Plague Knight, Specter Knight, and King Knight) in 2015. Instead, Shovel Knight came out in June 2014, Plague Knight came out in September 2015; Specter Knight came out in March 2017; and King Knight isn’t even out yet.
Even for an NES-style 2D platformer, one without the complicated graphics and polygon counts of today’s big-budget AAA games, it can be tough for developers to determine how long each task will take. When I visited Velasco and his team at their studio in Los Angeles late last year, he was having a minor meltdown over the bosses in Specter Knight, stressing to his teammates in Slack that none of them were very fun to fight. It would take a great deal of extra time for the Shovel Knight team to tweak, improve, and fix them all.
“First off, I would say we’re not very good at estimating a schedule,” Velasco said. “And then secondly, I would say we’re all perfectionists in our own way, and the way that we work slows everything down.”
Game delays can frustrate gamers, but they provide relief for game developers who want to produce a better game, except for the fact that they can extend months of gruelling labour. The developers at BioWare had to delay Dragon Age: Inquisition twice. The first delay, from fall 2013 to October 2014, was necessary to expand the game’s scope and ensure it could have key features like a huge open world and playable races.
But the second delay, from October to mid-November 2014, was far harder on the Dragon Age team. That one was to polish — to fix the tens of thousands of bugs that had popped up during production. And they were already all working endless days to get Inquisition out the door.
“It’s awful to have to tell a team that you’re delaying for six weeks,” said BioWare studio head Aaryn Flynn. “Because you know what that means for them is six more weeks of a lot of effort. It’s like saying oh, that marathon finish line that we thought was here is actually six miles further, sorry guys.”
Often, one of the biggest factors behind a delay is what developers call “blocking” — when one part of the team can’t do work because they’re waiting for another part of the team to finish. Departments like audio and visual effects get hit the hardest during the end of development because they so often have to wait for the rest of the game to be finished before they can work. “That’s where we see so much of the challenge of scheduling these games,” said Flynn.
“You find these dependencies — ‘Oh, I needed that? What do I do now? Oh it’s noon here, what time is it in Stockholm? 8pm. Oh crap. Oh they have gone home? I’m stuck. What do I do today?’” [Stockholm is the home of DICE, the EA-owned studio and creator of the Frostbite engine, which BioWare used for Dragon Age: Inquisition.]
Rockstar said in 2017 that it had delayed Red Dead Redemption 2 to “deliver the best experience possible for our fans.” It really was to be expected. Mega-games like that seldom come out on time, and anyone who can figure out how to reliably release huge games without any delay probably ought to author a book of their own.
Comments
13 responses to “Why Video Games Are Delayed So Often”
I believe it was Polygon that ran its review of the ill-fated XCOM cover shooter game alongside a similar post-mortem on the dead-or-dying Aussie studio that co-developed it, and just how difficult it is to work with studios on the same game oceans apart.
Schreier’s book sounds interesting, but ultimately we’re hearing about game delays like RDR2’s when they are announced, and we instantly switch our fixation to whatever else occupies that original launch space. There are larger issues about and too much attention on it brings about the “entitlement” stuff, as in how dare Rockstar do this to me.
This weird sub-set of games reporting that parrots a game announcement press release while simultaneously being all smarty-pants and saying there’s no way this won’t be delayed is really really awful to read. It comes off as smug and petty.
Because making games, just like any other complex software, is hard.
Yep. Also worth adding – games are amongst the most complex software you can write, and certainly the most interdisciplinary.
I still don’t buy it. I work in an industry that is project and scheduled based, and if we told our client that we underestimated our schedule by 6 months we’d probably never get to work with them again. I’m not exactly comparing apples with oranges there, but if delays are such a routine in game development then they’re scheduling is unrealistic.
You might counter that argument by saying that realistic scheduling would put off potential investors. But if it was my money at stake, I’d be giving it to the team that routinely meets deadlines before I give it to the shortest-schedule guys.
Then you’re not thinking like the typical arrogant, slow-to-learn neolib businessmen who control the big dollars in the game industry (and most other industries, come to think of it). Short term bucks rule in modern capitalism, and to hell with ‘quality’, whatever that is.
In my experience of software development, you can usually only promise two of “on time”, “relatively bug free”, and “has all promised features”.
For many games, the marketing demands that they ship with a certain set of features, and they’ll get bad reviews if they ship with bugs, so often the schedule slips.
It is possible to pick a different set of compromises, such as with the releases by many Early Access game developers. You can easily make relatively bug free releases at a regular schedule if you’re okay with omitting any feature that isn’t ready. And if your release cycle is short enough, then it isn’t a big deal if a feature misses out and only goes public in next month’s release.
My point was that bugs and delays are known unknowns and you should be able to allow for it. There’s a rule of thumb we use: take how long you think something’s going to take, double it and add 10%. That’s what we put in our schedules.
The thing is, it’s not the developers who get to decide the schedule. It’s almost in reverse. The big men in suits at the top of the industry tell them a game has to come out on X date, and they have to make the game to fit that date, even if that means everyone has to work 80 hour weeks for the entire production.
The biggest problem, however, is that the games industry rakes in billions of dollars regardless of schedule or quality, and because it is entertainment software – not enterprise – it doesn’t matter if there’s a problem because the clients are average joes and not businesses. Yeah, maybe some small proportion of gamers will boycott a game release, but the other 25 million will make back all they money they spend and surplus. It’s horribly endemic in the industry and it’s destroying it from the inside out.
That’s all well and good if the developer team has full control of the schedule. However, I suspect in many cases it is the publisher saying “we want the game ready to sell for Christmas” or whatever the launch window they’re after.
At that point, they need to look at this trade off. Is the schedule more important than the list of features, or the stability of the end product? Some games I’ve bought definitely traded off stability for meeting the schedule, with the hope of fixing it afterwards via a title update (e.g. Assassin’s Creed Unity). Other games have come out with far fewer features than expected (e.g. No Man’s Sky).
For games like RDR2, they’ve obviously decided not to compromise on stability or features, so pushed out the schedule.
Some software development is based around very well defined and testable proofs. Sometimes development is done releasing variations of the same product over and over. Even in these cases, estimation is always hard. Even when you are able to have full and complete specification for the work, estimation is really very difficult to get right.
If you want to know if tax software calculates a value correctly you can create a test that feeds in the input and checks the output. Correctly output a number, and the test is passed. Another developer can review the algorithm and have confidence it is right. It may be complex mathematically, but the system is built around having small units that can be proven true and correct.
Games are the opposite of those situations. With a game, the permutations are so complex that this is impossible. How do you test such subjective things as how a characters control feels like to the player? Can you mathematically prove if a game is fun? How do you show that the code that runs the characters control and movement is correct and bug free? How do you replicate every possible path through an open world game?
And how do you, right at the start, define everything that comprises such a game and estimate for all components? The final product will often be so complex that no one person can understand it all, even once written – so how can we effectively work out everything that will be needed before we have started?
Have you ever stopped to think of the hundreds of thousands of artefacts that go into a game? Take for example Ghost Recon Wildlands (or Breakpoint). The detail of the environment is incredible. Roads, rivers, rocks, grass, snow, sand, rain, every building, every item in every building, destructible objects, interactive objects, sounds, dialogue, and cutscenes with outcomes depending on how you played the game. Ever stopped to look at all of the environmental textures in Tomb Raider? The caves, the monuments, the jungle all so incredibly detailed with little plants and vines and moving insects.
Thousands of tasks, millions of permutations of interactions of objects. Then throw in ever increasing game realism like bullet drop over distance, real/low/no gravity, wind, day/night, night/heat vision, breathing, endurance. Ever expanding weapon/vehicle types all with their own characteristics.
Then you have an exec that says we want this ready for Christmas sales in 2 years time. Work out a plan to hit the target. Now execute. What could be hard about that?
If thats not hard enough also throw in creating a new gaming engine like they are doing for Halo Infinite which also is a launch title for the new Xbox console hardware as well. No pressure!
We need to cut these guys some slack.
No! It’s just to attack ME!
TLDR: No plan survives contact with the enemy.
Delays occur because software engineering is unlike building a house or bridge. You can’t necessarily take a piece of code and know that it does what it needs too on the face of it, or does it communicate that in the right way. They aren’t necessarily complete in and of itself, like a door or something.There is also no hard and fast way to even ‘software engineer’ – waterfall? Modified waterfall? Agile – ok, which agile? Scrumm? Xp?
And thats before the human element creeps in. Sickness, service leave, even staff turnover