4 ms·

A friend of mine in gaming though had an insight I found illuminating. The difference with games though is that there’s often an element of “One and Done” in th

A friend of mine in gaming though had an insight I found illuminating. The difference with games though is that there’s often an element of “One and Done” in that unlike much of web development, the starting from scratch for the next generation is more of a given. There is less need for long term support as games are expected to meet its twilight much sooner. With web development however, it is a regular risk assessment and there must be a true meeting of minds to decide that a rewrite is worth it.

rgoulter 7y ago
> There is less need for long term support as games are expected to meet its twilight much sooner. 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.
- SmellyGeekBoy 7y ago
  I'm not sure about the others but Minecraft's code was notoriously bad for years, but it didn't seem to hold it back.
  - mcphage 7y ago
    Honestly I think the bugs _helped_ Minecraft—bugs in the terrain generation made for interesting scenery that was popular to share, and bugs in the multiplayer code helped build the community as people shared how to get things like minecart tracks to work.
- friendlybus 7y ago
  Games with online multiplayer are frequently closer to saas than fire and forget. This change started happening publicly mid 2000s with people like ncsoft describing games this way. I miss the 'be big and better each release', fire and forget of the 90s but it's long gone.
Aardwolf 7y ago
A lot of games are receiving years or even decades of updates now though, such as minecraft, terraria, factorio, stardew valley, ... 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.
- jnty 7y ago
  Minecraft was on the cusp of that change, and it's pretty telling how much of a hellscape the code was for years.
alkonaut 7y ago
The product I’m building since 15 years evolved from a 32 bit desktop app (with dependencies from the early 90s) into a heavier 64 bit desktop app 10 years (hundreds of man years) later, and further into cloud services that weren’t even a term when development started. 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.
- scruple 7y ago
  > The product I’m building since 15 years evolved from a 32 bit desktop app (with dependencies from the early 90s) into a heavier 64 bit desktop app 10 years (hundreds of man years) later, and further into cloud services that weren’t even a term when development started. 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] [0]: https://news.ycombinator.com/item?id=22042186 https://news.ycombinator.com/item?id=22042186
clarry 7y ago
I mean I still buy and play games that were made 20+ years ago. Shame they have so many bugs we can't really fix. I don't buy websites that were made 20 years ago. Almost every commercial site has seen multiple rewrites in that timespan.
- louhike 7y ago
  The thing is, when a game is shipped, it won't be updated for more than 5 years usually (I think 5 years is pretty long for games actually). 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.
- thrower123 7y ago
  For many old games, it's not even certain whether the source code even exists any longer. I'm always impressed with the sometimes herculean efforts that fan communities will achieve to patch and fix old abandonware games.
  - RockIslandLine 7y ago
    IMHO, this is a failure of the copyright model. All information required to build software should be required to be escrowed at release.

rgoulter 7y ago

> There is less need for long term support as games are expected to meet its twilight much sooner. 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.

SmellyGeekBoy 7y ago
I'm not sure about the others but Minecraft's code was notoriously bad for years, but it didn't seem to hold it back.
- mcphage 7y ago
  Honestly I think the bugs _helped_ Minecraft—bugs in the terrain generation made for interesting scenery that was popular to share, and bugs in the multiplayer code helped build the community as people shared how to get things like minecart tracks to work.
friendlybus 7y ago
Games with online multiplayer are frequently closer to saas than fire and forget. This change started happening publicly mid 2000s with people like ncsoft describing games this way. I miss the 'be big and better each release', fire and forget of the 90s but it's long gone.

Aardwolf 7y ago

A lot of games are receiving years or even decades of updates now though, such as minecraft, terraria, factorio, stardew valley, ... 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.

jnty 7y ago
Minecraft was on the cusp of that change, and it's pretty telling how much of a hellscape the code was for years.

alkonaut 7y ago

The product I’m building since 15 years evolved from a 32 bit desktop app (with dependencies from the early 90s) into a heavier 64 bit desktop app 10 years (hundreds of man years) later, and further into cloud services that weren’t even a term when development started. 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.

scruple 7y ago
> The product I’m building since 15 years evolved from a 32 bit desktop app (with dependencies from the early 90s) into a heavier 64 bit desktop app 10 years (hundreds of man years) later, and further into cloud services that weren’t even a term when development started. 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] [0]: https://news.ycombinator.com/item?id=22042186 https://news.ycombinator.com/item?id=22042186

clarry 7y ago

I mean I still buy and play games that were made 20+ years ago. Shame they have so many bugs we can't really fix. I don't buy websites that were made 20 years ago. Almost every commercial site has seen multiple rewrites in that timespan.

louhike 7y ago
The thing is, when a game is shipped, it won't be updated for more than 5 years usually (I think 5 years is pretty long for games actually). 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.
thrower123 7y ago
For many old games, it's not even certain whether the source code even exists any longer. I'm always impressed with the sometimes herculean efforts that fan communities will achieve to patch and fix old abandonware games.
- RockIslandLine 7y ago
  IMHO, this is a failure of the copyright model. All information required to build software should be required to be escrowed at release.