00:00
00:00
MSGhero
Free time is nice time.

Nick @MSGhero

Age 30, Male

Somewhere in the North

Joined on 12/15/10

Level:
17
Exp Points:
2,848 / 3,210
Exp Rank:
19,855
Vote Power:
5.85 votes
Rank:
Police Sergeant
Global Rank:
6,514
Blams:
456
Saves:
937
B/P Bonus:
12%
Whistle:
Normal
Trophies:
6
Medals:
661
Supporter:
11y 4m 25d
Gear:
3

Speed vs elegance

Posted by MSGhero - July 21st, 2017


For Enki Adventures, I've been dealing with a fundamental coding problem. Is it better to quickly shove things together to make them work or solve problems elegantly?

Chris DeLeon makes videos where he creates prototypes very quickly, like this platformer. His code isn't organized, and adding features would be a major pain, but it works, especially for Ludum Dare and Game Jams.

I took that approach when generating procedural terrain in my game. Things worked, but I had 1300 lines of code in a single file and a lot of things that would make programmers make a face. Now, I'm rewriting the whole thing far more elegantly. But when I finish refactoring everything, the game will look the exact same. It's for the best, naturally, as I'll be able to make future changes more quickly. But I wonder if I could have avoided all this mess by doing the elegant solution first.

It's probably not possible to come up with a clean solution first, especially when doing something new. You might spend all your time figuring out the "best" way to do something and not spend any time actually doing it.

I guess it's a tradeoff, and I guess the path I'm taking is working. It'll lead to a great blog post about terrain generation once I'm done, complete with algorithms and crappily drawn pictures explaining them.

Stay tuned.


Comments

I generally equate elegance with conciseness, so when I'm coding I generally try to stick with the simplest/shortest solution. That means that I'll avoid factoring things out into reusable generic functions until I can actually save lines by doing so. I find that doing this lets you pick out which parts of the code are naturally similar, which in turn leads to more natural code reuse and organization, versus guessing that a generic function with a generic interface will be useful, even though you are currently using it in one place.

So I do start from inelegant code, but I clean it up as I go as I see fit, and generally, I try to avoid committing messy code. Then again, at my job, my coworkers place no value in rewriting code for the sake of making it better, so if I (or more often, one of my coworkers) commit bad code, I'm pretty much stuck with it. I hate my coworkers.

I would hate to have a programming job. Other people's code ugh.

I'm noticing in this refactor, some places I tried to make a very generic function. I look at them now like "Why does this exist?" I was probably trying too hard.