3 ms·

> For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares

> For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares if your code is elegant and bug-free? Having worked on some 24-hour game jams and similar, I've found completely the opposite. It's when you're in a real hurry that you really can't afford bad code. Writing better code will make it easier to get it right, will put less pressure on my working memory, will let me try things faster and make those last-minute changes I wanted, will make adding features towards the end easier rather than harder and, crucially, will both reduce the chance that I need to do intense debugging and make debugging I need to do easier. Working with good code just feels lighter. The thing that breaks 24-hour projects isn't writing code too slowly, it's writing yourself into a corner or hitting some problem that derails your work, takes hours to solve or doesn't even get resolved until after the deadline. A game jam isn't the place to try to squish all bugs, sure, but that's a question of what you're doing, not how. I still want to write good code in that situation because it makes my life easier within the time constraints, and because, even if I'm fine with some bugs, there are still lots of bugs that render a game unpleasant or unplayable. I'll need to fix some bugs no matter what; I'd rather fix fewer, easier bugs than more, harder bugs! The same thing applies to longer time horizons too. When you have more time you have more slack to deal with bad code, but that doesn't mean it makes any more sense to write it! And, of course, once you get in the right habits, writing solid quality code becomes basically free... but, even if it really did meaningfully slow you down, chances are it would still be worth doing in expectation.

jimbokun 1y ago
I agree. I think it's a misconception that writing good code must take longer than writing bad code. At least if you want it to vaguely satisfy some requirements.
raxxorraxor 1y ago
Well, you probably would disregard some fancy asset loader and instead just statically include some files instead. Or if you need to do some pathing and your quickest solution is some breadth first search. Perhaps it isn't "bad code", but still a bad solution that could quickly be implemented and be solved by a lot of computing power. Of course you may use ready-to-use modules that provide such features as well..., but it may be prohibited by competion rules, I don't know...
- tikhonj 1y ago
  Using a different algorithm is a change in what you're doing, not how you're doing it, so I'd see that as qualitatively different from writing bad code.
norseboar 1y ago
I second this. I've done lots of game jams and I think the "messy code" threshold for me is like, 1-2 hours away from the deadline at most, on files nobody else will touch. It depends on the type of cleanup, but factoring out common logic really doesn't take that long. As the above comment says, in my experience bugs introduced from messy code are way more likely than the time savings of not cleaning up code. The usual exception I'd make are things that like, mostly the same but not quite (e.g. a function to fade out a light over time vs a function to fade out a color over time). Often I find requirements for those diverge over time, so I'll just leave some repeated patterns across both.
taeric 1y ago
There is something to this, but I'm fairly convinced that the key to writing fast clean code is to write more code. Pretty much period. Sucks, as that is effectively arguing for rote repetition in the tasks. And it is. But, that works. Really well. Stated differently, show me someone that can write clean code in a hurry, and you have shown me someone that has written this before.

jimbokun 1y ago

I agree. I think it's a misconception that writing good code must take longer than writing bad code. At least if you want it to vaguely satisfy some requirements.

raxxorraxor 1y ago

Well, you probably would disregard some fancy asset loader and instead just statically include some files instead. Or if you need to do some pathing and your quickest solution is some breadth first search. Perhaps it isn't "bad code", but still a bad solution that could quickly be implemented and be solved by a lot of computing power. Of course you may use ready-to-use modules that provide such features as well..., but it may be prohibited by competion rules, I don't know...

tikhonj 1y ago
Using a different algorithm is a change in what you're doing, not how you're doing it, so I'd see that as qualitatively different from writing bad code.

norseboar 1y ago

I second this. I've done lots of game jams and I think the "messy code" threshold for me is like, 1-2 hours away from the deadline at most, on files nobody else will touch. It depends on the type of cleanup, but factoring out common logic really doesn't take that long. As the above comment says, in my experience bugs introduced from messy code are way more likely than the time savings of not cleaning up code. The usual exception I'd make are things that like, mostly the same but not quite (e.g. a function to fade out a light over time vs a function to fade out a color over time). Often I find requirements for those diverge over time, so I'll just leave some repeated patterns across both.

taeric 1y ago

There is something to this, but I'm fairly convinced that the key to writing fast clean code is to write more code. Pretty much period. Sucks, as that is effectively arguing for rote repetition in the tasks. And it is. But, that works. Really well. Stated differently, show me someone that can write clean code in a hurry, and you have shown me someone that has written this before.