The Worst Game Jam 4: Devlog

This is my first game, so it’s natural that this is my first devlog. I’ve done some game development in the past; but I’ve never put anything together to a point where I felt comfortable releasing it.

The History:

The projects I’ve done have always, in one way or another, extended beyond my capability as a programmer or attention span in general. I always hit a block with what I wanted to do, which ended up causing me to give up on a project. While I may sometimes blame the tools I was using, I think more often the issue lies in the mismatch between what I am wanting from the engine and what the engine is supposedly giving me.

My first game development attempt was in Game Maker Studio, I wanted to try to make a sort of demake-slash-spiritual successor to Dark Cloud 2. At the time I was naieve and thought that, yeah it would take a long time, but I could do it. The order in which I was going about adding features was all wrong. Instead of using each feature to learn new concepts, I found myself stumbling about in the dark, unable to figure out why my code wouldn’t run. I had a few small successes, but mostly I was trying to build one of the worst possible genres of game as my first ever project. Later, I also tried to start projects in GB-Studio, Inform 7 and Godot, but none of these really worked for me. In a way, the engines were all too robust for the types of things I needed to start out making and not really compatible with what I desired at the time.

The Perfect Tool

The perfect engine, coding language, or tooling doesn’t exist for game development, but there’s a lot to be said with finding a tool that meets you exactly where you need to be met in order to achieve success. I used to think that as many handholds as could be provided were what I needed. Pre-made actions for movement, game logic, or even “natural language” coding. What I discovered, though, is that a limited scope, an engine that doesn’t do everything for you, and a limited possibility space were the conditions under which I thrived. PICO-8 was an absolute joy to work with. Getting the little fantasy console to do anything felt amazing and the small scope encouraged me to have negative scope creep. The final game ended up being half the planned length and squeaked in just under the token limit. There may be just enough space left in the game for me to go back and add a leaderboard, but I doubt it.

The Token Limit and Gamifying Development

I mentioned the Token Limit before. PICO-8 is a “fantasy console,” with all the limitations that implies. It’s intended to be somewhere between a GameBoy and GameBoy Color in terms of capability. Cartridges tend to be 64kb or less, the screen has a resolution of 128x128, the console is able to express 32 colors (though 16 of those are hidden) and the console has a limited built-in sound effects engine and music sequencer. The sprite, map, sound effect, and music storage are very limited unless you start programming “closer to the metal” by interacting more directly with memory. The way PICO-8 surfaces the computational limitations it has is almost entirely through the Token Limit. Everything you do in code uses a certain amount of tokens. Set a variable? That’s a token. Create a function? That’s going to be more depending on what it does.

At first glance, the token limit is simply a way to keep developers set in their scope. Don’t go too big. Don’t do too much. Over time, however, I found that the token limit was an excellent teacher. You can see the inefficiencies in your code as you write it because the token counter will suddenly jump up. It encourages you to go back to old code and rewrite it, optimizing it so that it can use as few tokens as possible and ensure you have more space to add features. This constant tug of war with the limitations may sound exhausting, but I found it to be exhilarating. A little game inside the development package for the game I was making. It also gave me hints toward good programming habits generally.

An all-in-one development suite for 1989

The other thing that I found extremely charming about PICO-8 is that it is all integrated. The code editor, sound editor, music editor, sprite editor, and map editor are all right there in the UI. Since games are so small and the entire program is so light, it is incredibly snappy. It had modern niceties like copy and paste, syntax highlighting, and helper functions for some common tasks that may not have been available for other consoles of the era PICO-8 is trying to emulate. It loads changes to a game instantly and has great error handling for basic problems. For more difficult to track down bugs, community folks have built upon the built in function to print to an external terminal to make it even more useful. This all-in approach wouldn’t work for most game engines, and it isn’t perfect here (I mostly used an external editor for my coding) but the built in tools are genuinely very good. The tools being what they are makes me even more excited to get working with Picotron, the fantasy workstation made by Lexaloffle, the developers of PICO-8. It’s got the same sensibilities, but with an expanded set of capabilities.

Working Under Pressure

While I felt like the pressure of the jam was useful for me creatively, I think overall a longer, less pressured development period is also good. I did luck out and basically had four days devoid of any distractions to work on it this time. I don’t think that will be possible next time. That said, I also now know how to do some basic things in code, so it might be easier to get up and running right away. I think two or three weeks might be my normal sweet spot, but I’ll just have to burn that bridge when I get to it. I do also think that it might be nice to do more than two projects in a year, so I’ll probably either join a different jam, or start developing projects between TWG jams.

Developing Past Challenges

My biggest challenge this jam almost certainly was developing the enemy patterns. I found that I loved working on game feel, but with the way I handled enemy spawning and progression, developing the enemy waves was a slog for me. A good worker never blames their tools, but I think that in this case, I wasn’t really using my tools to their fullest. I ended up spawning enemies via huge blocks of function calls, inserting starting positions and speed values into them. It made making changes to them extremely fiddly and boring. Lots of changing a tiny value here and there to hopefully make an encounter more fun. Maybe in the future, I can find a way to develop a tool to make the annoying parts of development less tedious.

I also didn’t love the sound effect creation. I felt like I was mostly throwing pasta at the wall until I had something I didn’t really hate. I didn’t even want to touch the music at all, so I was very relieved when I found the free-use music that I did specifically for PICO-8. It isn’t perfect for the project, but it’s way better than I would have been able to do, so it’s well worth it and I’m endlessly grateful to the folks who made that music free to use.

Let’s See Some Fundamentals Out There

The part where I think my game shines is absolutely in the game feel department. The basics that make a shmup feel good were important to get right for me, so I put the lion’s share of my time into that. Programmatic explosions, tuning the ship movement and collisions, figuring out the perfect fire rates and enemy health values took time, but it was the part of the game I loved most. I feel like I also got the difficulty curve right where I wanted it, although the first and second bosses could have probably been swapped.

I also enjoyed making sprites for the game. I don’t think they’re particularly amazing by any stretch, but it was still really fun and interesting to do. I’m particularly proud of the boss enemies, who look significantly more polished than the player and smaller enemies. Working within the 16-color limitations and small sprite sizes was really fun, too. Like a smaller, slightly less impactful version of the token limit for code.

Cut It, Print It, Put It On a Floppy

That’s the end of it, I think. Overall, I really enjoyed my experience and I am already thinking of new challenges to tackle in my game dev future. Look for more TK games coming down the line!