A lot of that is polish to make the game feel great. You should play Matty’s game Jumper. The game was made with Game Maker back in the early 2000s, which was targeted to low-code users back then. The game mechanics are very similar to Celeste. Despite the lack of polish, it’s still a very entertaining game.

Not the person you were replying to, but that takes me back! Back in those days I was in early high school and Jumper was one of the games I looked up to when I was learning Game Maker. I completely forgot about it.

Frankly this still doesn’t seem technically challenging. It does seem like a different sort of design challenge though to get all of the little mechanics correct. This isn’t like inventing a new algorithm though. I suspect implementing this is more like constantly iterative tweaks and “feeling out” whether the controls are right.

The end result looks complicated but no sort of specialized engineering skill seems necessary to achieve the result. Just grit and design talent.

I think you're discounting too much the level of skill that 'grit and talent' requires. Cos it is exactly inventing a new algorithm - just not via mathematical proof or vigorous formality.

It's kind of weird how terrible this code is (according to software design 'best practices'). 5k lines in a single file, tons of repetition that could be replaced with more compact code etc.

I would think the author was a novice programmer, but looking at the creator's history they've already made Towerfall, another hugely acclaimed game (and one I still play to this day), about 5 years before this was released.

Yet the game itself is extremely polished.

I kind of have no idea where to take this thought, except that successful auters have very different sensibilities than garden variety programmers.

> (according to software design 'best practices')

that's because these best practices aren't geared towards producing something good - it's geared towards making something easy to understand for someone else, and easy to maintain when requirements change.

It is also designed for the lowest common denominator programmers - so that many can work on the same code base, over a long period of time.

For games, none of these goals matter at all.

Yep, absolutely. A lot of game code has really big files. Although not exactly the gold standard for code style, the Source Engine does have a significant level of even though almost every file is 1k+ SLOC.

Here's the base Source Engine movement code for example: https://github.com/VSES/SourceEngine2007/blob/master/src_mai...

I mean, stuff like this isn't really defensible:

    switch (index)
    {    
        case 0: return sound0;
        case 1: return sound1;
        case 2: return sound2;
        case 3: return sound3;
        case 4: return sound4;
    }

Look perfectly readable and easy to understand.

only because there's no `default` case.

You could argue that having `sound` as an array, and index into that array is better, but once again, what does "better" mean here?

this code works as is, you will not get an array index out of bounds error. If this is quick and easy to write, what else could you ask for?

Games are (sadly IMO) mostly write-only software.

Its because best practices are written by people who dont write alot of code. Most of them are lowest common denoninator bs.