When you build something that will have new requirements in ten years, implemented by different developers, then you can motivate spending time on code hygiene.
For a game anything that won’t be in the next game you can duct tape. The parts that will go into hundreds of games over a decade is the “engine” and I suppose in that you’d find the same sort of discipline and hygiene as in any other long term code base.
My employer, as well. We have three teams where the main code bases were started ~2001, when the company founded. One of these teams has code that started as Java applets that are now .NET Core. We have another ASP.NET system that they are currently migrating today. The other two teams, building Windows desktop applications, are now invested in web technologies, like browser engines and WebRTC on our A/V side.
I cut my teeth in the embedded industry, and we were supporting at least one product that I recall working on there that had code that had started in the early 90s.
It's incredible to think about. There was a nice thread yesterday that touched on this topic, as well. [0]
I think this is true for the majority of games.
But I wonder if it remains true for the most successful.
e.g. GTA V released in 2013. Apparently as of 2018 it saw $6B in revenue. Though, surely a lot of this has to do with the new content they introduce to incentivize microtransactions.
Fortnite was a paid early-access game in July 2017, but had a free-to-play battle-royale mode by September 2017. Minecraft came out of beta in 2011.
I can agree with "just ship it, quality of code is not a concern" for an initial release. I wonder how much bad code affects big and successful products, though.
e.g. Ubisoft's Ghost Recon Breakpoint was very buggy, even though it looked like an iteration on the Ghost Recon Wildlands game just two years earlier.
I miss the 'be big and better each release', fire and forget of the 90s but it's long gone.
For better or worse, it's nice to get new features in games you love, but it were also great times when you knew a game was "it", when you finished, it was done, and there were no mandatory updates.
I don't buy websites that were made 20 years ago. Almost every commercial site has seen multiple rewrites in that timespan.
But I often have to work on website code made 10 years ago. THe fact that it's used does not matter much. The interesting difference here is how long will the code be maintained.