This is a 4.4MB C# source file for A Game About A Dragon... which is on Steam.

It's not even the entire game. 107K lines. No loops. The author didn't know about loops and to my absolute horror the update function calls itself in order to "loop". Read that again. In order to loop, it throws another function onto the stack. How it doesn't crash immediately, I have no freaking idea.

You'll also notice a lack of classes, as well as far as I can tell, arrays. Tons of global variables. The "update" function is 95,000 lines long.

Also, apparently the award winning game Undertale has a switch statement that's over 1,728 lines long.

Here we are, wasting all this time trying to learn elegant ways to control code rot in our codebases, and caveman are running around smashing two rocks together and getting on Steam.

On the bright side, I do feel a little better that my code isn't that horrific. But I'm also not making any money off my games.

It looks like the Update function calls itself at the end of the function block. The C# compiler is probably smart enough to convert it to a tailcall. Basically, it's a lucky accident that it works at all.

But yeah, that's... well, to quote Dave Strider of Homestuck fame:

I can't give the coder too much flak. He at least acknowledges how bad it is. Hell, I wrote code like that when I first started out with QBasic, all those years ago. We were all newbies once.

Reminds me of the VB code my cousin used to write. Then I taught him about object-oriented programming and loops and it got much better.

Kinda reminds me of Amazing Tetris, my first completed game written in Free Pascal. It probably wasn't THIS bad, but I didn't know about OOP back then, so no classes or inheritance in the entire code (which, to be fair, probably isn't even that much of a problem in a Tetris game, which barely benefits from inheritance in the first place). Also had a ridiculously long main.pas file, where like 90% of my game update code were, including the complete options menu (and pretty much any other menu). Honestly, I still somewhat have the habbit of making really long source files and functions. I only ever split code into multiple functions when I'm actually reusing it somewhere. In a Tron-like racing game I programmed at Games Academy, almost all of the update code of my main player class was just a single lage update() function with almost no functions.

Regarding the time argument, yeah, that's a huge factor. There are major differences between code I write at work with limited time, code I write at home for fun and code I write at home for "serious" stuff and plan to reuse later. For the first category of code, functionality usually is the most important thing and there just isn't always enough time to put in the effort of making the code prettier, cleaner and more readable. For the second category, there is enough time, but no real necessity for write good and reusable code, so "everything goes". For the third category, there IS a necessity for writing good code, as well as enough time, so here I usually write the best kind of code, which means often going back to old code to making it prettier and better. Of course this also means slow progress, but that's worth it, since those are kind of my "dream projects". The real problem here is rather how often I completely restart a project because I decide that the current project in the current state just doesn't suit my needs anymore. Happened all too many times. With my current project, I'm on a good course, though.

Regarding what RPG Hacker says: That's why I wouldn't ever want to do programming professionally. I like to take the time and put some care into my code so that I can still understand it a year down the road. My JS game engine, minisphere, has some of the nicest C code you'll see anywhere (not to say I didn't make some questionable decisions along the way, but I'm slowly working on rectifying them, me being a refactoring fiend), but that's only because I'm not running up against a deadline--so I can take my time and do releases only when they're ready.

At the end of the day, game software is basically the same program with a bunch of hard-coded logic thrown into specific places. It's hard to really improve upon that anyway. Generally the game state is one big blob. Interactions happen in ways differently than business software. At least doing everything at once avoids the usual gotchas that people naturally attempt to do with gaming OOP: mario.draw() or mario.check_collision(block). That's probably worse than just hard-coding everything into the main file because you'll probably end up having to hack around your abuse of objects and inevitably it will lead to bugs.

Of course, game software is typically not maintained. You write it once, ship it, and that's that. You'll never maintain it. You'll never go back to fix anything. Hell, if it shipped on a console you can't. At best you'll port it to other platforms and you'll do it as quick 'n dirty as you can. That's the difference.

If this guy were to go back to this game in 6 months and try to figure out what was happening he might curse his past self. That said, it looks like the XNA or equivalent framework was used to make it and he probably has that structuring to thank for making it as straightforward as it is. He doesn't have any of the framework stuff that we'd have in Allegro to sort through. If he had to write that too he might not have ever made a game at all, let alone one that could reach Steam. That's the downfall of Allegro...

He could probably reduce the size of the code quite a lot with a smarter design, but the size probably isn't a huge hindrance and it works so fuck it. The biggest pain is probably just making a change X times. But a good editor, which he probably wasn't using, can automate that... A determined and ignorant programmer won't mind those tedious changes though.

Kinda, yeah. But typically only for a few weeks after release. Even then, this is only the case because, thanks to the power of patching, games are now released earlier than they used to (usually before they're fully ready and/or without having gone through the same kind of thorough QA that games on past consoles necessarily had to go through before release). I think what bamccaig meant was actually maintaining software for years to come. Like, for example, Windows. Microsoft doesn't release a version of Windows and then, a few weeks later, just abandons it and moves on to the next project, just to get back to the old Windows a few years later and do a quick and dirty port of it. No, after they release a new Windows version, they provide that version of Windows with updates for years to come, and even when a new Windows version is eventually made, it reuses a majority of the code of the old version.

In that regard, I actually have to disagree with bamccaig a little. Sure, games are usually programmed for one-time use and are rarely touched upon after release. However, this doesn't go for game engines. Game engines are usually written for reuse, especially in professional environments, so even as a professional programmer, you want to put at least SOME care into maintaining your code. This doesn't necessarily apply to hobby programmers, of course.

The only updates that they'll push are generally going to be abuses of the platform. Probably severe bugs that prevent the game from being played if you're lucky, but I recall PS3 games that were never patched and you just had to pray as you went through certain levels that you didn't get stuck.

Some games they might try to fix if they released before it was really ready to meet a deadline, but it'll just be the end of the development cycle overlapping with release/deployment. It's not maintenance mode. It's still development mode.

Most updates are probably superficial, like removing controversial content, adding or tweaking tracking/DRM/intrusions, advertising, etc. Updates are usually pretty rare after the first few months of release even on platforms where it's technically possible. Unless it is hurting sales there's no point for the game studio to spend any extra resources on making changes. They move on.

The exception is long-term online games, like GTA: Online or MMOs or whatever else. Those will get content updates to keep them relevant.

While D just makes your ears bleed.

Perfectionism is a curse. I've never been proud of anything I've made so far and always rewrite over and over again. I've stopped the rewriting games part generally now, because I ended up writing a script language, scrapped it and am now busy building a compiler for a language that I'll probably end up throwing away at some point.

Const is 'pure', immutable values are easy to reason about. The majority of variables don't need to mutate in most programs. Optimizers are more free to make assumptions about immutable values. Accidentally mutating a const will result in a compile-time error.

How so? Quite the opposite, he has trained himself to suffer countless copy and paste errors. He needs to start on the path to untraining it.

All this talk about copy & paste kinda reminds me of Limbo of the Lost!

I understand a copy and paste error to be where you legitimately copy and paste something but forget to change everything you wanted to change. Since he has done so much copying and pasting, he will be an expert and not forgetting to change things. You're right that he needs to train himself not to copy and paste so much, of course - but once he's done that, at least he'll still copy and paste reliably when he does need to