Code archaeology
- devlog
tags:
From a turd on skis to a farting wienernoid office worker?
I almost never refactor any of my code. In addition, I rarely ever add comments to my code, nor think much of variable or function names, nor correct my spelling errors. In Autopeli, the split-screen driving game I made, I accidentally put the wheels on the cars the wrong way, so they drove in the wrong direction at first. Why flip the wheels if I can just multiply acceleration by -1? That’s how all my code is - fixing bugs with the first solution that comes to mind, even if it was stupid and I knew it. Never properly fix anything if you can add an ugly hack instead. This works for me, and isn’t an issue for my small game projects - that is, until the game turns into something bigger, or if I decide to take a half-a-year break from the project. Such is the case with this office farting game I’ve been getting back to making. There are still so many remnants in this game of what I started out with - it even has the skis still. I’m just deleting them right as the character is spawned…
Want to have a fun time making games? Make them physics-based
Figuring out what script to modify to make changes to how the items spawn in the game’s random-generated offices was easier to figure out than it was to hunt down the script that handles grabbing objects (it was a script called PoopTrail.gd …). Still, adding new items to be spawned caused this bug I’ve seen tens of times when making this game during the 1+ years I’ve now been on/off working on this. Turns out a lot of the office generation logic relies on just raycasts that, for a couple of frames, check what’s around the spawned object, and based on that, the object is either kept or destroyed. And if something goes wrong, you’ll absolutely notice it :–)
This is probably at least part of the reason that’s kept me from taking better care of my code - to me, game development absolutely needs to feel fun, and fast-written, badly upkept projects providing these awesome bugs for me to enjoy, and eventually solve, are fun to me, and my not-so-much-maths-oriented, still problem-solving–loving brain. And as how Godot (the game engine I use) works is, you’ll probably end up with a project that is at least somewhat modular, so it’s likely not just your thousands-of-lines-long Game.gd spaghetti-code script that handles all game logic. (Mine is “just” 1456 lines as I’m writing this…). And with physics-based game projects, you can instantly focus on game feel* and make it the core of what your game is about. Sprinkling some (poorly-written) code on top of that is secondary.
* kids today might call it game juice, but to me, that’s a different thing, and I’ll rant about it in a future blog post, I’m sure
That being said, I also very much enjoy getting projects done and finished, too, so that others get to enjoy them as well, but that’s a very different part of what I like about game-making, and making and sharing in general. It’s a good motivator to keep your project at least a little bit organized, so it has a chance of being a more proper end product, too. It’s all about the balance, like most things are.
Should I make the turd on skis game too? Probably. It’d have an obvious title too: Turd de Ski.
Share on Bluesky / Share on Mastodon / Copy link to post
