alt Hacker NewsIt's interesting that he brings up Diablo 2 and Diablo 3 (and Quake for that matter), though, because I think it really foregrounds why these discussions are so fraught.
I worked in early AAA in the late 90s, and it's true that games were often quite rough around the edges. But they were also often biting off WAY more than they could chew, inventing genres and innovating like crazy, often in messy ways that didn't always work. But that meant players were often also routinely and genuinely surprised by the experiences they encountered in even big budget games.
He lists a bunch of quality of life and balance issues that were fixed in Diablo 3 compared to Diablo 2... but, well, Diablo 2 was obviously _important_ in ways that Diablo 3 wasn't. It's a much greater game.
And lurking in the background is the hard fact that often the progress with software (certainly game software) entailed turning to much better software engineering standards, using much better external libraries or game engines with much larger teams, and relying on much more process to capture and filter all those rough edges... and along the way, you've built a much, much larger team with a much larger burn rate, and so all those experiments and innovations become much more dangerous and need to be corralled and controlled and mostly stifled, and as the cost of all this to build skyrockets your entire game design _has_ to focus on your business model and your microtransaction story and your live services first and foremost, because you've boxed yourself into a corner where that cash flow issue is the central fact of your game / software design.
(I experienced this evolution first hand in the FPS space)
All of which is to say, I think there are multiple different axes at play here for evaluation, and it's probably fair to say that software _undefinably_ was much worse in the past along some of them... but not all of them. And there are probably deep tensions and tradeoffs between some of those axes.
I think this entirely discussion really is muddied, though, too, by the fact that hardware got radically better over this entire arc as well, and so many programming techniques in the past that made software more brittle or crash prone hinged on memory and computation optimizations techniques that really had nothing to do with the software culture of then or now. It was just a response to the realities of the hardware.
Also, aside from the dupe bugs, his "improvements" in Diablo 3 I consider it's downside. Changes that are framed as QoL changes in games are very frequently just reductions in risk or investments in your character.
His general outlook seems to be that the small teams of the past creates more rough edges and that the larger teams on modern AAA games creates a smoother experience but requires more concern for income because the cost is so much higher for the larger team.
I get that comparison but I think he's totally missed the advantages of the small team. The cheaper dev cost means less risk of financial ruin if the game fails which means innovations are less risky. Less developers means the vision of one person can shine through more which results in a more creative end-result, for better or worse.
The "too many cooks" in the kitchen is a real problem of modern software, especially games. Huge budgets mean games need huge audiences to be successful which means everyone needs to like it. The death of productivity software is, unsurprisingly, anything that stands in the way of productivity. The save bugs he mentions are real killers. But for games, as an art form, the turn from focusing on the vision of the artist to the desires of the audience makes for uninspiring work.
I'll take bugs all day long if it comes with a unique experience.