This LD was much less of a trashfire than last the LD: I actually finished a project! (Even if it is majorly butchered compared to the original designs for the game).

The Good

• I had two major goals for this LD: I wanted to learn how to best use LuaJIT with Love2D (by experimenting with code architecture) and I wanted to experiment with LuaJIT's FFI by utilizing C types and data structures near-exclusively. I accomplished both of those things, so well that it has actually convinced me to change how I approach programming with Love2D. I might write a post talking about how to best utilize LuaJIT fully with Love2D, if there is any interest, but it's a bit out of the scope of this post.

• Among the effects of using the FFI was, paradoxically, faster code writing. Having to consider what size of data to use put me in a headspace that really ended up speeding up the design of the code. It's kind of weird, but I got into an amazing flow for the first quarter of the compo.

• I liked my art. It isn't particularly good, but it utilizes the NES palette, and I had a good time making it. A lot of the art assets actually went unused, in the end, but that's how these things go.

• I did most things counter to how I might usually approach programming stuff. This made things interesting, both in good ways and bad ways.

The Bad

• I'll be blunt, this theme wasn't my first choice, nor my second, third, .... It took me a while to come up with a game idea.

• The game ended up being way less than what I had planned. The original plan for the game was to have it be set up arcade-style, where you'd have different levels, and you'd mine for stuff with a limited inventory. What you mined would change your score, and you'd need to meet a specific score to proceed to the next level. In-between each level, you could use the stuff you mine to make better equipment, but it would deplete your total score (which means you'd need to get more stuff in the next level to make up for the stuff you spent). If time permitted, you might have had enemies that could have actually hurt you by lowering your score, or something similar. That core design felt solid, and I think what the game became pales in comparison to its original design: you collect jewels, try to get the highest score. Even now, after not being able to hack it, I still feel like the game I wanted to make wasn't unreasonable in terms of expectation.

• I really wanted to get around to sound/music design in the game, but I never ended up having the time to.

• Using the FFI introduced some bugs I'm not used to dealing with, including segmentation faults and other related memory errors. I even had my game dump memory contents at me at some points, which was genuinely frightening! These errors were, thankfully, mostly easily solved.

The Ugly

• The thing that went the worst was probably in the middle, I decided to experiment a bit with how I'd handle the level. Normally, I might just have solid blocks (or, in this case, the stuff you can mine) all be individual 'objects', and then use some form of bounding box collisions mixed with spatial hashing to make it all run smoothly. This go around, I had the idea to instead represent the map using a C struct of two-dimensional arrays with one 8-bit value and one boolean value: the type of the tile, and the light of the tile. And then, the array number could act as the x and y position of every tile. I was surprised as how well this ended up working, and decided that I'd just do grid based tile collision.

• This worked really well at first, but things got a little wonky since the character's position was a 16-bit integer, and the tiles were 8x8. This shouldn't have been difficult, but I started having bugs, mostly the character would get stuck along walls, which seemed impossible to me but there must have been some sort of typo in the code. After a good while trying to debug it with no problem that stuck out to me in the source, I decided to instead just re-write it. I then ended up with one of those errors that programmers have nightmares about: I would segfault at seemingly random points. In this case, if you were to go directly to the left as soon as the game started, it would segfault, but otherwise it was fine. I could not, for the life of me, figure out why this ended up happening. I'm still not 100% sure what the problem was, but I was able to fix it by changing some of the code around that allocated memory (I've been using the FFI to manually allocate the memory using malloc). I was incredibly burnt out after spending so much time trying to debug the program, and was horrified upon learning that I had spent almost 6 hours in one sitting debugging this in my game!

• This was the principle error this go around, focusing too much on fixing a bug, and burning out. With LD ending earlier than usual, I decided that if I went to sleep that night, there would be no way I could finish any game, which was true but also made the rest of the compo really unpleasant as I had to fight sleep deprivation plus burnout.

• At the very end, and I'm talking like I had to fix bugs in the submission hour, and I discovered this about 10 minutes before submission hour ended, I discovered a bug in my controller/keyboard input engine which made controlling the game via keyboard impossible, a bug I never caught because I developed using a controller. I ended up having to re-program movement very quickly (thankfully, the game only requires 5 buttons). I submitted the game with about 3 minutes to spare.

Overall, an extremely fun experience. I enjoyed myself immensely, and I'm extremely thankful for the opportunity this event and its community provides, both as an excuse to just make something, as well as making me approach game making in new ways that forces me to grow.

Notes for the Future

• Create more of an engine to use; I used an ECS-like and an input engine, which both worked well for the majority of the time, but I should have engines for collision detection as well as drawing stuff (post-release, realized that the screen was stuck at a tiny resolution and had to figure out a way to resize everything and have it all still align properly). Spending a lot of time on these things was unnecessary and ultimately just took away from adding more mechanics to the game.

• Don't hyperfocus on buggy code; if it's too buggy, just rewrite it or try to do something different.

• Don't do six hours of fruitless debugging (in retrospect, this one seems kinda obvious...)

• Come up with a better road map for the game's development, I think this would have made a big difference in terms of final game content.

• Write more posts during the compo. I won't give myself too much trouble for this, since most of my time was spent on the project, but I think it's good to get feedback from people as you work on your project.

Thank you for reading.