PICO-8, motivation, and value

Making a game

I've been trying to make games for a quite a while! Typically my pattern is:

Get excited about an idea Work furiously building an engine for said idea Start fleshing out the engine in all directions, trying to plan for anything and everything I might want After weeks of programming, discover some large design flaw in my engine Start rewriting game with a new paradigm or in a new language or with new tools Finally or nearly finish the engine; now time to start making the game Completely lose motivation because I'm burnt out and I've forgotten what made me excited about the idea in the first place

Maybe some day I'll finish my Zelda Randomizer (before the ROM-based randomizers were a thing!), or my Cave Noir-inspired roguelike, or my competitive text-based Wumpus game, but it seems unlikely at this point!

Enter PICO-8

PICO-8 is a self-contained "fantasy console". It has certain specifications that all games made in it need to adhere to. I was initially attracted to PICO-8 because of its constraints. It immediately solves some problems and makes a lot of decisions for you. I don't need to agonize what my screen size or aspect ratio should be. It's 128x128. I don't need to pick a palette. It's these 16 colors. How will I make music and sfx and graphics? There's a music tracker and graphics editor built in! How will I distribute my game? You can make executables for any platform, and you can target HTML5.

I was also attracted to the community around it. All the code and data for the carts is inherently open source, and the community is helpful and they all iterate on each others' ideas. There are many cool games and demoscene projects in Pico-8. It's really fun to try to get the most out of a platform with heavy constraints.

For my project Heat Death, I resolved to take the opposite approach I normally take: instead of planning everything out and making a comprehensive engine, I instead just sort of hacked everything in. Nothing was planned, and I took the path of least resistance while programming it. If a certain feature started to get hard to implement, sometimes the path of least resistance was to refactor and rewrite the code. When it was easy to share code between enemies or objects I shared code. When it was hard, I didn't.

Hack it in

There was never an insurmountable problem to solve, because the structure of my game was inherently simple. Game development (at least for me) is a very fluid process, and it's a fool's errand to try to create a structure that will support everything you want to do in the future.

I'm always reacting to what I just built, iterating on what worked, what didn't work. With this "hack it in" mindset I was able to prototype ideas very quickly. I wasn't immediately getting discouraged upon realizing I would need to completely redo how something worked in my game.

The fine print