https://www.reddit.com/r/EnterTheGungeon/comments/9ykpgc/onc...
(I'm guessing the biggest factor is the massive investment required to make a game nowadays.)
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.
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...
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.
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.
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.
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.
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.
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.
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...