I made some games as a teenager and had the experience that I was basically forced to stop projects because they got too complex. Game Maker had only limited support for things like variable scoping; you really need to isolate components and have them all do their own defined thing to make it not grow too complex or you'll fix one bug and cause two new ones. Even more so as a team, I can only imagine, though I never concurrently worked on game code with more than one person (for longer than a literal weekend project, that is)

Normal software I find is a bit different because things like UI libraries give you a lot of structure already. In game code, you do so many things custom, and performance matters so much (each frame needs to finish around e.g. the 17-millisecond mark) that it's really up to you to apply the necessary discipline

Gamedev here. The process I have to go through to make a good core is never a linear thing.

I'm making a custom netcode right now. I started from a blank folder. I had some design decisions worked out before I started, like I wanted udp transport for messages that didn't require responses (ie inputs), an isomorphic client/server simulation and state snapshot diffs and checksum validation. I had an idea what I wanted the syntax of creating a new request to be, but the rest I knew I'd just figure out as I went.

The way everything fits together has taken a lot of refactoring, and I've disregared 3 prototype sim components. I've written a good 40% of the base types twice over to make it all click better. It's kind of sad how few libraries I've found for a fixed point physics simulation. I've been using one I stubbed together and it may end up growing into something permanent if I don't find something better that checks my boxes. That's just the way it goes.

The only way I get top tier code is if I budget time to do controlled burns as I get a crufty feelings. There's never enough time to do it like that the whole way through a project, but I find that if you're aggressive about doing that the first 30% of the way into a thing, you have a good enough core to hang your less elegant ornaments off of and it wont collapse into a tangle.

Another valuable process when writing things from scratch is finding compact archetypal islands that force your systems into a good versatile shape. Something simple like a boids simulation requires you have so much stuff worked out that if you write it first and stir it around and firm up the foundation, you'll build most of the tools you need for many different kinds of games.

And then there are games like undertale that have all the dialog trees in a single gigantic 1000+ line switch statement.

Determination can make up for a lot of deficiencies in other areas.

Yeah, I was looking at infantry.cpp, and the quality is actually very good for 90s game code. The documentation is good, it's decently well-formatted, and there are assertions. Nice counterexample to the "all successful games have terrible code" conventional wisdom.

> Nice counterexample to the "all successful games have terrible code" conventional wisdom.

That's a modern wisdom from the last 15-ish years when people started to have good enough internet connections that you can get away with publishing a dozens gigabytes patch on launch day.

In ye olde times, it was prohibitively expensive (or in the case of console ROM cartridges, impossible) to distribute patches, so projects were usually planned with plenty of buffer time and plenty human testers. These days it's rush to not collide with the releases of other AAA studios, and human paid-for testers have been replaced by free (or, sometimes, paying) early-access players.

I think survivor bias is at play here. C&C had many sequels, ports, expansion packs that helped make it popular. So of course it had nice code, otherwise we wouldn't have seen such a wide berth of reuse for that code.