I've been thinking about the difference between video game software and most CRUD software. With most CRUD software you are expecting future changes, so you have to be more conscious about tech debt. But with video games (at least older ones), once you ship you're more or less done.
I wonder if that gives room to take on extreme debt at the last minute before shipping a game. An example might be when Steve Ellis added multiplayer to Goldeneye on N64 a couple months before launch. Since they were going to ship a finished product, he was probably able to build it much faster without having to worry about code quality.
One thing that's interesting about this insight is that many games are moving away from this model, with regular updates and continued development. This doesn't invalidate your point, of course, but I also wonder how big of a mental shift this must be, because historically, when a game was done, it was done.
That's a great point. One of my favorite games, Enter the Gungeon, had plans for a major release of DLC, but they canned it and replaced it with a much smaller scope of free updates because they had so much technical debt that they couldn't attempt the big DLC release confidently.
It's mostly restrictive on the side of game design. Once your goal is to support a large quantity of software features you automatically fall into the mold of a style of gameplay that will minimize impact on feature development.
In the classical model of ship-once gamedev, certain big-ticket software features tend to be thrown out when the designers are in control, because they're so costly to get right and don't surface as much immediate impact:
* Large-scale persistence(just store a minimal representation and instance that)
* Online features(too much synchronization logic - it hinders almost every other feature!)
* Complex AI and procedural simulation(too much chaotic behavior, limited ability to control outcomes)
The transition we've made has, in essence, been to construct microtransaction service products that do support these more complex features: the game is a platform for the sale of assets, and it is massively online with total persistence and sometimes even robust AI. And when you start doing that, your ability to revise the design diminishes substantially. For the most part, you can't take away assets and features that are already there without a substantial player backlash, which means that games of today tend towards accumulating their way into an incoherent maximalist experience with no particular focus or intended playstyle, all of it following templates intended to encourage monetization:
Make sure the players can customize their character cosmetically, and give them a huge array of skills and powers, but nerf all the unique aspects of these powers so that the game will play roughly the same regardless of what you choose. Present them with opportunities to draw in their friends, and add hooks and incentives to come back repeatedly and to check the in-game store for deals. Provide play opportunities for all segments and demographics of players(following the lines of the Bartle player types).
When this model works, it does extremely well in the mainstream(Fortnite basically ticks all the boxes and is outstanding in its ability to progress as a live service) - but it has the downside of being a compromise for everyone. It makes the game too Byzantine in its complexity, too restrictive in its customization, too carefree in its changes to competitive dynamics, too willing to let annoying minor bugs persist - to say nothing of the cost and complexity needed to pull it off.
So I think there's definitely room for more of a spectrum of products, from the mega-blockbuster down to tiny boutique indie games. But the marketplace is still catching up with the idea of providing full service, and a lot of games are still released with the focus being on developing a franchise or on addressing a specific genre. In many cases the capital requirements needed to do services crush that idea out of the gate.
Well, online games that are basically sold as partially or fully a "service" (e.g. Fortnite), and game engines that are primarily marketed to developers of games are, but I'm not sure I agree that applies to games overall.
It's certainly only a part of games, but this also happens outside of games like Fortnite.
For example, one of my favorite games is Celeste, a fully offline, single player platformer that's about 18 months old. They've had a lot of releases[1], and at least one of them sounded like, to me, like a decision that was made purely because it was easier to implement technically. (I won't get into it here because it's pretty off-topic, but if anyone is interested, I can elaborate. It's "The Prologue Dash cutscene is skippable") There's also one more major content update coming that appears to have new mechanics, and it's already late. That said the game is amazing and I don't fault them for any of that at all...
IMO technical debt does not discern between different types of software. If you make a mistake (or are not 100% correct) you will need to fix it unless you are willing to provide your customers less than perfect software.
Maybe an appropriate way to look at this is that the developer working on the feature could only need the company to take $100 in debt, while another developer needs the company to take on $100,000 in debt for the same work. Typically this difference, unfortunately, does not reflect in the individual developers' salaries.
No, the customers only care about working software, not maintainable, perfect software.
Technical Debt is about taking shortcuts to have something working now, in exchange for more work maintaining and evolving it in the future. If the software doesn't work, it's not debt, it's a bug.
If you are not changing the software, it doesn't matter that a list is hardcoded instead of parameterizable, that the modules are tightly coupled and can't be reused, or that the build must be done following a particular set of incantations in a specific machine. If you are, these are all examples of debt that will come back charging interest.
Properly planned and managed, technical debt is a tool much like actual debt (a loan) that can accelerate your growth and your time to market. Thing is, most teams don't know that they are taking on a debt and don't realize how much interest they are paying each day.
I think the path toward optimizing software for (a) maintainability (b) completeness and (c) bug-free are not necessarily mutually exclusive. I think in general software is fighting all of these battles simultaneously. And so by definition software that is incomplete (ie. without all the features) has the possibility (probability?) of being buggy. Otherwise if it's complete why add features?
Given what you knew at the time you created a definition, and per that definition you could have written 100% maintainable 100% bug-free 100% complete code. It's in uncovering your lack of/ incomplete understanding of your problem that you may need to go back in to that code. Even though at the time it was considered 100% bug-free, complete, and maintainable.
100% maintainable software is NEVER a goal. A hard coded list that will never change is better than a configuration file that needs to be installed someplace and loaded as runtime. If you are right that the list will never change you have made the software more maintainable as you never have to deal all the code to load the configuration from whatever path the user has installed it to. If you are wrong though you will have a lot of work tracking all the releases and what is hard coded in each until you retrofit a loader.
This is the type of choice you need to make upfront often when designing software. If you get it right your system is more maintainable. If you get it wrong your system is less maintainable. Sometimes you don't know in advance which is right.
Technical debt doesn't make the software worse, it makes the codebase worse which degrades the ability to maintain and add features in the future (which is paying interest on the debt, so to speak).
So, in the context of oldschool console video games that ship and then end development permanently, it's absolutely a reasonable decision to add some technical debt if it means fitting one more nice-to-have feature in before launch. Because you don't pay interest or pay down that debt ever. The code is shipped and then it retires, presumably.
The days of fully offline games are long gone though. It doesn't mean that game studios take on less ambitious projects though. Most games are superglued together to get over the finish line and shipped with a massive day-1 patch.
Probably wasn't even true for GoldenEye. They used the same engine for Perfect Dark; sure the assets and game scripts would be changed but the multiplayer code had to be ported and cleaned up I'm sure.
The key defining characteristic of technical debt though is our inability to accurately estimate its true cost. If we could frame the question like you present it the battle would be won
Under schedule pressure that's certainly true, but subsequent products will often start by taking a skeleton of a previous one. In this way tech debt could live on for many additional games unless it's addressed.
Is this actually true? The engine lives for multiple games, and the tooling is often reused as-is, but do games start with existing projects, or do we add new technical debt through the cleansing baptism of copy-paste?
In 1982: all games were written from scratch. You might copy the good parts from a previous game, but there generally wasn't much: poor abstractions meant the game logic and UI was mixed together (in their defense, on the limited CPUs of the day you couldn't have made proper code separation work, and of course the limited CPUs also meant you couldn't create such complex systems where it mattered.)
As games entered the mid 90s games started to get releases, and game engines came out. However each release was treated like an all new project even if some code was reused. Games would customize the engine in ways that wouldn't apply to the next game. Bugs in the engine would be worked around by ensuring that part of the game could not be reached (thus resulting in games that you could never get the 100% complete stat as the engine knew you didn't go through some locked door without a key). Some of the core engine was reusable, but for the most part the engine and game were tested as one.
Sports games tended to be the first to figure this out: every year was a new release of essentially the same features, but different player stats. As such it is becomes obvious quickly the game engine maintenance is a cost, there were few new features (until the next console offered better graphics). Most other games were latter because part of the new game was engine changes to support it, so it was hard to find a stable core to the engine.
Gradually games have seen more and more value from separating the engine from the game. As this has happened engine changes are no longer for one game, but for the possible use by all future games. Part of this is game designers have figured out the right abstractions, things that previously would have looked unrelated and thus change different areas of the engine are now seen as variations on a theme if you squint just right - and we know how to squint
Of course there have always been, and probably always will be one-off games written like 1982. When your game is small this is okay.
Different game companies have reached this at different times. Infocom had mostly figured out their reusable engine in 1982.
> But with video games (at least older ones), once you ship you're more or less done.
Technical debt doesn't care about your release status and can kick in long before you reach the finish line, which I suspect happened with Perfect Dark and many subsequent rare games. How many game delays and cancellations have technical debt as the root cause?
In enterprise projects I've seen enough over engineered crap added at the very start of the project that hampered development for the entire lifecycle.
I wonder if that gives room to take on extreme debt at the last minute before shipping a game. An example might be when Steve Ellis added multiplayer to Goldeneye on N64 a couple months before launch. Since they were going to ship a finished product, he was probably able to build it much faster without having to worry about code quality.
https://www.engadget.com/2012/08/14/goldeneye-007s-multiplay...