1 free read left. Create a free account for unlimited reading + AI research.
Create free accountEvery once in a little while, some big budget game is released in a horribly buggy state, and the gaming public at large asks, "Why with a hundred million dollars at their disposal, couldn't the studio launch something that worked? And why wasn't the game delayed so that it could be fixed?" Today, I will attempt to answer those questions. First, let me start off by saying that I am not defending the practice of launching buggy games. It's bad business, and it means that something got done wrong. But exactly where and when that something went wrong isn't always as obvious as it first appears. On a macro level, it often boils down to two fairly straightforward categories: scheduling issues and production issues. Let's start with the production side. Here, there are three possible causes for a bug-filled game getting released. One, we can't fix it. Two, it'll cost more to fix than we will make fixing it. Or much less frequently, three, we just didn't catch it in testing. What players
sometimes fail to realize though is that the we can't fix it or the it'll cost more than we'll make to fix it scenarios aren't a case of mere laziness and certainly not malice. Bugs like these are often the result of decisions made super early in the development process, and by the time the consequences of those decisions are visible, there's very little that can be done about them without a complete overhaul. For example, since we just recently had a case of this, buggy animations. If a game ships with a load of obvious animation problems, it could be the fault of incompetent animators, but it probably isn't. Often, issues like these are technical, a result of how the game engine handles animations, how the animation system itself works. And that system is built early in development, way before a single asset gets put into the game. So, you're not likely to start running into the edge cases where that animation system starts breaking in unexpected ways until a lot later, once the game is mostly put together. And by that point, the flawed animation system you've built is such an integral part of the game engine that removing or even
altering it could break tons of other systems, setting development back months and leaving tons of expensive employees sitting on their hands for weeks. Now, truly great studios have all sorts of practices for testing these things early and lots of fail-safes to fall back on, but problems like these are really tricky. And even the best studios sometimes get thrown when they hit a really fundamental or sometimes undiagnosable bug in some core part of their engine 2/3 of the way through production. And there's another side to this problem. Sometimes these unforeseen bugs aren't even the studio's fault, at least not directly. See, many studios don't actually build a lot of their core engine anymore. Modern game engines are such a huge investment to build that it often makes much better business sense to license one of the many quality third-party options out there, like Unity or Unreal, and then flesh those out even further with middleware tools like Fmod or Havok. It's often the best option, but it does mean relying on a series of third parties. Every developer
I know has a story of that time where they were waiting on a crucial feature which the engine company promised but never delivered, or of having to integrate a patch from a middleware developer that suddenly broke everything. And by its very nature, the decision to use such software happens very early in the project cycle, well before any of those potential problems could possibly be foreseen. By the time bugs start surfacing or some critical feature never gets added to the engine, it's too late to go back. And that means that it's often too late to ship anything but a buggy game. But perhaps even more frequently, buggy games get shipped due to scheduling issues. Players will often ask things like, "Why don't they just push back the release date?" But a lot of people don't realize just how much is tied up in that release date. Marketing spend can begin as much as a year in advance of release, and things like magazine covers and TV ad buys, those are often locked in months and months before launch. These aren't things which you can just reschedule at will, at least not without huge expense.
Then there's launch windows in general. Everybody can probably think of some game that they love which didn't get the attention it really deserved because its launch week was dominated by something like a Call of Duty or any given Blizzard game. Publishers really want to avoid those scenarios, too. So, they carefully coordinate all of their launches and try with varying degrees of success to make sure that all of their games get at least a week where they don't have to compete with some other major title for attention. Pushing back a game's launch, even just a fortnight, can put it right in the shadow of a competitor and screw all of that up. Then there's the need to move on to other projects. Major AAA developers, especially ones owned by a publisher, move, or at least are supposed to move, like clockwork. When a title is done, that team is rolled on to a new project. Or sometimes they're temporarily brought in to help on other titles that the publisher's studios are working on while a portion of the team spins up the next project. This means that delaying a game
isn't just delaying that game. It's also delaying that team's next game or delaying projects that team was meant to help with after launching their own. And this can be an even greater issue when working with outsourced developers because today you'll often find that some assets, levels, or parts of the game weren't built by the main studio, but by some outsourced team elsewhere in the world. And these external studios, they've got to move from one project to the next, too. They've got their own production schedule to keep. If some unexpected bug bubbles to the surface in that outsourced content, many of these external studios are actually great about going above and beyond to try and help fix it, but if they've already moved on to another project by the time that bug is encountered, they may not be able to help. And if so, the main studio on the game either has to run with what they've got or remake all of that work themselves, putting things further and further behind. And I know it's easy for us as players to brush off factors like increased development costs because the publisher or the studio having to spend
more money isn't our problem, but this is a business. AAA games represent highly calculated risks, a precision investment of millions of dollars based on a carefully calculated prediction of how well that game might sell. And sometimes, not always, but sometimes, as much as the artist in me hurts to say it, sometimes the objectively better business decision is to not sink more millions into that investment. So, should we be shipping buggy games? Obviously not. We have to keep looking for ways to test things early and to leave ourselves some fallback options if things go wrong. And sometimes this stuff is just a matter of studio discipline. But when you're building software as complex as this, bugs are going to sneak up on the best of us. And it's often not as simple as just delaying the game a few weeks to iron those bugs out. Sometimes, due to decisions made months or even years before launch, those bugs are embedded into some part of the engine that can't be replaced. Or sometimes those bugs are out of the studio's hands entirely, still waiting on an update from a
middleware developer that never happened. And sometimes, even when it is theoretically possible for the team to iron those bugs out, the potential cost of doing so is simply so great with so many irreversible decisions about marketing spend and release schedules already made that the publisher chooses to move forward anyway. And I don't say any of this to excuse releasing broken buggy titles. Nor am I saying that it's wrong for you to be upset about being sold a broken buggy title. I'm just saying to be aware that the bugs in that broken buggy title, they might be more than a delay could ever fix. See you next week. Mhm.
The release of buggy AAA games is rarely the result of developer laziness or malice, but rather the consequence of complex, early-stage production decisions and rigid scheduling constraints. When a game launches in a broken state, it is often because fundamental technical issues were discovered too late in the development cycle to be rectified without a complete system overhaul. These issues frequently stem from core engine architecture or reliance on third-party middleware, where developers are beholden to external partners for patches and promised features. By the time these dependencies fail or deep-seated bugs emerge, the cost and time required to fix them often exceed the project’s viability.
Scheduling pressures further complicate the ability to delay a launch. Marketing campaigns, including high-cost advertising and media placements, are often locked in months in advance and cannot be easily rescheduled. Furthermore, publishers must navigate crowded release windows to avoid competing with major titles, meaning a short delay could push a game into a period of lower visibility. These logistical constraints are compounded by the need to transition development teams—including internal staff and external outsourced partners—onto new projects immediately upon a game's completion.
Ultimately, AAA game development functions as a high-stakes financial investment. While studios strive for quality, the decision to ship a flawed product is often a calculated business choice made when the cost of further development outweighs the projected returns. While better testing and internal discipline can mitigate these risks, the inherent complexity of modern software means that some bugs are deeply embedded in the engine or entirely outside the studio's control, rendering simple delays ineffective solutions for systemic production failures.
The games and companies this document names on the inner ring, other documents about them on the outer one. Select a cover to see it up close and open it in a new tab; drag to move, pinch or Ctrl + scroll to zoom.
Game Developers Conference · 2024
Comments