I've done more work on Thwimbly in the past three days than I've done in the past six months I think. it's not what I was supposed to be doing, but it is what I did (I have so much laundry and cleaning to do
)
Some of that work will come out in the next update to the demo, but a lot of it is level design for the later worlds (hecking finally I have
ideas for this thing). And what I've come to realize is just how much of a
house of cards this game is code-wise.
Some of that is to be expected, with the game's first mechanics being programmed by me
FOUR YEARS AGO in summer 2021. My only other major gamedev projects when I started this experiment were my Space Invaders clone Gravitaz (
link to play in browser), and a twin-stick shooter I really want to get back to sometime. Neither of those games come even close to Thwimbly in terms of complexity. Gravitaz topped out at 1500 lines of code (though if I was programming it elegantly it should probably be closer to 1000). Thwimbly is currently at 6002 lines, plus some 1300 sprites (incl. dupes)? it's got to be close to a thousand hours into this thing at this point? 347 commits tracked in Github since I uploaded it in spring 2022.
Part of the problem with the house of cards is inheriting 19-year old me's garbage code practices. Thankfully I started the game with object-oriented principles so various entity types share a common data type (compared to Gravitaz where each projectile type is a completely separate code structure, adding to the bloat).
Thwimbly was also never supposed to hecking get this big, it was supposed to be a small project while I waited for the Picotron framework to come out. Between having too many ideas and Picotron not getting released till last spring, I had plenty of time to scope creep myself slowly enough that I wouldn't notice until it was too late. At this point I've basically capped out the amount of space in TIC-80, so thankfully there's a hard limit on how far I can scope creep, and the end is in sight.
Anyways, there is truly some garbage in the codebase. like the entity draw calls specifically avoiding certain entity types (all hard coded because of course they hecking are) because I need to draw them in a different way later. What I should have done was use some sort of layer system or flag to draw this entity type differently later, but at this point I'd rather not change it since it technically works.
also I've done 99% of the code in this low-res pixel editor because it's just way too easy to just Ctrl+R to run the game and test, then Esc to change a val and then repeat. It's super fast to iterate and honestly probably half the reason I've kept going as long as I have.
The thing that made me realize how "house of cards" this codebase is was attempting to make these jumping plant guys work with conveyor belts. here's a funny gif of me not realizing what the jump trajectory would look like.
please ignore the blurriness, I scaled this gif down because it was too large to upload otherwise.
Anyways, I don't have flags for groups and each entity is basically just running a script for just that entity type (i.e. no children anywhere ever, partly because this game was never supposed to get this big and partly because Lua does not support object oriented coding, you have to hack it in yourself). Because of this, using the conveyor to move all entities would move ALL entities. Only about half of the entities behave as expected when applying velocity. There's a lot of really messed up code in there for platforms, portals, static bouncepads, etc because I didn't realize how easy it would have been to organize things better.
What I ended up doing to make the conveyors work is to basically hardcode them to only work with these jumping plant guys. There's just not enough consistency in how entities behave when being given an x velocity to trust it to not implode.
I was originally planning on doing some sort of level design competition when the game came out, daring people to hack it and do all sorts of weird stuff with it, but there's just so many things like this where it only works in very specific contexts. this game was not meant to have minecraft-core inter-entity interactivity initially (try saying that five times fast). It's slowly moved that way over time, and me trying to stretch 19-year old me's code is causing me to cringe so hard because there are so many ways I could have made this more flexible and prevented so many headaches. It's like I was afraid of functions or something.
and like, I totally should cringe at my code from 4 years ago, it's proof that I'm
learning and growing.
heck man, since I started this project I graduated with a mechanical engineering degree, took classes where I had to write computational fluid dynamics algorithms to solve partial differential equations. I'm so hecking excited to start on a new project with a blank slate where I can put what I've learned to the test.
that's part of the reason I don't want to go back through and fix all of these things, just try and finish this darn project so I can move on rather than scope creep and take another year to refactor the entire codebase. if it doesn't impact the player experience then it isn't worth fixing. (I really should refactor the player collision code though)
in other cringe, here's a comparison between the original art for level one and where it is now:
anyways, go make something bad and learn from it so you can do it better next time. I can't hecking wait
