the thing about development hell is that often there is no "the game as originally envisioned" to be pined for or found with "just a little more time"

a lot of times you end up in development hell because the core vision is vague, contradictory, keeps changing, has big holes in it. It's not that those games fell short of their original ideals so much as they were trying to build a brick house on a swamp

sometimes, if you're lucky, you firm it up in the right places and it stabilizes

other times it just sinks

I just finished a three-year stint on a AAA game project that has been "in development" for at least six years. This client has now gone back to essentially pre-production. One of the things they're struggling with is carrying around a huuuuge amount of technical debt for games that never shipped.

We're talking things like an inventory system (built two games ago) that was never fit for purpose stacked on top of a backpack system (built three games ago) that was a colossal hack, which has to interact with "pockets" (built one game ago) for the player character to put their weapon in. Except that the inventory system is on an entirely different backend than the pocket system and doesn't replicate equipped weapons correctly, so the UI team (that's me!) has to assign a weapon picture directly to a player weapon slot based on their pocket index.

Throughout the project, I would poke the lasagne only to find it rotten all the way through. There was no "original vision" to RETVRN to. The vision was always inspired by whatever game was currently in vogue. As a UI programmer, I was constantly asked to display information to the player that simply did not exist. But because it was always for an "important demo," my team would have to fake the data themselves. This was a very bad idea (and I told them as such!!) because it meant that upper management would look at the game and see massive improvements while it was just another layer of load-bearing paint.

i was on a project that i joined at a point where they had spent years in the kind of "preproduction" where you allocate a chunk of time to figure out what you're trying to make by doing a build that you know you'll throw out when you figure out the real goal. then you throw it out and start fresh from a better position.

except they had neither thrown it out nor figured out a design. chunks of it had been thrown out and restarted at random, with no more vision of the final product than they'd had years ago. at all times, they were working on some funding or conf demo milestone that precluded any actual game development; half the time it was a "vertical slice" that was just pretending to be a vertical slice because there was nothing, even on paper or in someone's brain, to be a slice of.

every task i would get was a trap: there's no way to build anything in a way that supports the design when there is no design. you either go out on a limb with a system you've designed, which you get told is wrong even though there is no right, or you do your best to accommodate multiple of whatever options you imagine they might end up wanting and never find out if you succeeded or not because they never commit to any design. when this happens, it's like you didn't do the work at all; nobody has a task to interact with the result of your task so eventually they forget about it and task it to someone else again and now there's three inventory systems. you try to just take ownership of a feature because nobody else has, and get your hand slapped, so you go talk privately to the many designers who have been hired and find out the same thing is happening to them.

this is obvs cartoonishly bad mismanagement but some of these traps are distressingly easy to fall into the second you're not doing strictly-for-free indie development: the second you're working towards "the build" for "the conference" or "the milestone" instead of just chipping away at the game, there's a huge risk you never get back to what you were supposed to be doing. there's always another build