1 free read left. Create a free account for unlimited reading + AI research.
Create free accountLet's say you're starting up a new project, and everything's going great. Code is being written, content is being designed, and art is getting made. But then, right before you think you're just about finished, all hell breaks loose. Bugs that you thought would take minutes to fix take hours, and each of those fixes introduces two more. Content isn't fitting together like it used to, and those perfect art assets don't look right anymore. And worst of all, there isn't enough time or money to change any of it. How did this happen? The answer, technical debt has finally come due. This episode is brought to you by Raid: Shadow Legends. Check out the game at the link in the description below, and if you're a new player, you can receive 50,000 silver and a free champion. Technical debt is what happens when problems caused early on in development aren't dealt with until later, causing them to be significantly more difficult or expensive to address. Because
technical debt works the same way as financial debt. If a loan isn't repaid, it continues to compound until the principal of the loan ends up being much higher than the original amount. In game development terms, a small problem can grow and grow without anybody even noticing until it's too late or too large to fix. The decision to fix an issue right away or leave it until later is something that every software team has to deal with. Because it's a trade-off. Early on, it's important to get new systems working quickly, so designers and artists can start building out content. However, this can cause features to get hacked in without regard to potential bugs they might be causing. Not to mention, technical debt is by no means limited to just writing code. Designers might be throwing together levels with little to no organization, or artists may be submitting assets with excessive polygon counts or texture blemishes. When a project is just starting out, these errors tend to be overlooked because they aren't seriously blocking anybody from getting any work done. Everyone just assumes they'll get
fixed at some point, that someone else will deal with those issues down the road. Or, as often as not, no one quite knows how to solve these errors, and everyone just needs to keep moving on to other tasks. This is a problem because the cost of redoing any of that work might be exponentially more expensive during the later stages of development. Many critical systems may rely on buggy hacked-in code, and a simple fix that would have taken a programmer about 30 seconds in the beginning could potentially cause the entire game to no longer function at this point, not to mention require weeks to find. Because who knows? The programmer that put it in in the first place maybe isn't even on the team anymore. Or maybe levels have hundreds upon thousands of poorly named objects jumbled together. Finding the specific thing in that level once took a designer or artist a few seconds, but now may take minutes. And adding all that up could cause hours upon hours of wasted production time. And to top it off, sometimes these things don't immediately occur to people as problems.
After all, your designer can find everything just fine in their chaotically arranged level. But as soon as other people start to work on it, well, let's just say they can't. And the same's true of poorly commented code or disorganized assets. Organizing everything at this late point could take someone hours, days, or even weeks. Other causes of technical debt are scheduling or shifting project specs. If an engineer is given a tight schedule to complete a large feature, they'll have to cut whichever corners they can to get that system delivered on time. And those choices that have to be made will be hard or even impossible to undo. For instance, let's say a programmer is tasked with creating an enemy AI. They're told that the game is only single player. So, they create an AI system that's designed completely around reacting to the one human player. Now suppose someone above them has made the decision that the game should really have co-op multiplayer, and we're not saying who or what kind of office they're sitting in or how expensive
those suits may be. Don't worry about any of that. Now, the programmer may have to redo the entire system so the AI can properly react to multiple players. Not to mention, the level designers had positioned AI around the levels based on how it originally functioned. So, now they may have to redesign entire portions of their levels to compensate. For both the programmer and designer, addressing that spaghetti-ing problem is now preventing them from working on other features or content. And keeping this doomsday train a-rolling, technical debt can become so unmanageable as to cause games to get delayed indefinitely or outright canceled. Because sometimes the development has gotten so tangled or off track that it's easier just to throw it all away and start over, as the recent news regarding Metroid Prime 4 might suggest. But on the other end of the spectrum, it's also important to note that there are cases with legitimate reasons not to care so much about the technical debt that's being accumulated. Game prototypes are often hacked together to test out early
concepts and ideas to evaluate if those ideas are worth pursuing in detail. And there's no sense in crafting polished, airtight game systems for a prototype knowing that those systems are likely to get scrapped after a single play test. In fact, some studios even have policies of throwing out all prototypes and starting over when the real production begins. Or sometimes they even have separate teams to handle prototyping and production, respectively. There's also the intentional decision to leave in errors that are deemed too costly to fix or unlikely to seriously impact the game experience. A bug that causes a game to crash every time it occurs is always more important to fix than a strange graphical glitch that only happens every once in a while. And with the ease of post-launch patching, it would shock you to know that sometimes games are rushed out the door for a holiday or sale deadline with a ship now, fix later mentality. But, let me tell you, fixing anything when your game is live ends up being way, way more expensive. So, don't make that decision lightly because we've
all seen how the existing player base can sometimes react to those changes. Yikes. In the end though, minimizing technical debt is a huge challenge because it's impossible for anyone to really know what might happen in the future. Therefore, the best way to manage it is just to be aware that it will happen. But, there are some ways to reduce the potential for debt. Most importantly, by adopting good work methodologies at the start of a project and sticking to them. Code style guides along with regular code reviews may seem like a waste of valuable time early on, not to mention your programmers will grumble about them, but they can save enormous amounts of work when it comes to the end game. And taking a few minutes here and there to clean things up or organize assets properly will benefit everybody down the line. So, when choosing how to spend your team's valuable development time, I think it's helpful to remember this old adage. If you don't have time to do it right, you won't have time to do it over. Once again, thanks so much to Raid
Shadow Legends for sponsoring this episode. Have you been looking for your next great mobile RPG? One with, oh, I don't know, giant boss fights, PvP battles, and hundreds of champions to collect and customize their gear? Well, Raid Shadow Legends has all of that in spades. Now, admittedly, I'm just starting my adventures with Raid, but I've already been super impressed with how darn good this thing looks on my phone. And the champion animation and design is top-notch. Seriously, if I could pull off dressing like Galek 24/7, I totally would. Mental note, go to the gym more. Uh sorry, where was I? Oh, yeah. And best of all, you can play at your own pace because you can download the game right now and start playing for free. So, click the link in the description below and new players will receive 50,000 in starting silver and an epic champion to call their very own.
Technical debt in game development refers to the accumulation of unresolved issues, disorganized assets, and suboptimal code early in a project that become exponentially more expensive or difficult to rectify during later production stages. Much like financial debt, these problems compound over time; what begins as a minor, overlooked shortcut can eventually destabilize core systems, leading to significant delays, increased labor costs, or, in extreme cases, the total cancellation of a project.
This phenomenon is not limited to programming. It encompasses poor organizational practices in level design, inefficient asset management by artists, and the impact of shifting project requirements, such as adding multiplayer functionality to a system originally built for single-player use. While teams often ignore these issues to maintain momentum during early development, the resulting technical complexity often forces developers to spend weeks troubleshooting or redoing work that could have been addressed in minutes during the initial phase.
However, the accumulation of technical debt is not always a failure of management. It is often a calculated trade-off. Prototyping, for instance, requires rapid, "hacked-together" solutions to test concepts that may ultimately be discarded. Furthermore, studios may intentionally defer non-critical fixes to meet strict release deadlines, relying on post-launch patches. To mitigate the risks of unmanageable debt, the analysis suggests that teams should prioritize consistent work methodologies, such as enforcing code style guides and conducting regular reviews. Ultimately, the most effective strategy for production pipelines is to acknowledge that technical debt is inevitable and to adopt a disciplined approach to organization, adhering to the principle that if there is no time to do a task correctly the first time, there will certainly be no time to redo it later.
Game Developers Conference · 2024