Making an Old-School Game

A jaunt through a field of constraints

I just participated in PiCoSteveMo. What’s that? It’s a month-long game jam for making a PICO-8 game inspired by a Stephen King work.

Oh, did that just raise further questions? Hold on.

  • “What’s a game jam?” It’s an event where you try to create a video game from scratch.
  • “What’s PICO-8?” In the creator’s words, “PICO-8 is a fantasy console for making, sharing and playing tiny games and other computer programs.” If it helps, think of it as a constrained virtual environment for running little games and programs. But there’s also an integrated editor for code, and graphics, and sound and music. And a standard library on top of the embedded Lua language. Actually, “fantasy console” is probably easier.
  • “Who’s Stephen King?” You’re kidding, right?

Why did I do it? Well, partly because it’s hosted by former Flagrantino Casey, and he’s talked about it and PICO-8 a lot. Partly because it just seemed interesting. And honestly, partly because I’m a silly, silly man — there’s been so much going on in my life lately, and why not add one more thing to do? I’m glad I did, because it turned out to be really fun and rewarding.

I think I’ve made it clear that I don’t necessarily think of myself as a very creative guy, but I do really like working on the craft. And also I super feel the terror of the blank page. Constraints and prompts are great. So the combination of a clear prompt (“write a game inspired by a Stephen King work”) and constraints (do it in a month, use PICO-8 — which has its own constraints) really sparked my interest. Also, I nerd-sniped myself by making a throwaway snarky comment like “sure, if I could somehow find a way to make a game based on ‘The Jaunt’… oh wait I just had the idea”.

So began a journey that started with a purchase and download of PICO-8, and then a tutorial zine and working through that. And finding various other incredibly useful resources, like the manual, and the PICO-8 Wiki, and NerdyTeachers, and Lazy Devs Academy, and Gruber, and so much on the Lexaloffle BBS.

In keeping with the spirit of the jam, I toyed around a bit with PICO-8 enough to get some things working (like going through the examples in the tutorial zine), but then I didn’t work on my project until the first of November. And then I really dove in, documenting my progress in a sort of devlog community thread.

So much of the experience fell somewhere between comfortable and uncomfortable. Yes, I’ve been programming for a long time, but there are many forms and focuses in that field. And there are many frameworks for working in. Thankfully, I was already familiar with the init/update/draw game loop through my interest in Processing (in particular the JS version, and its `setup()` and `draw()`). However, that sort of thing makes me put far more in global state than I like. And the restriction PICO-8 has on tokens can put some major incentives on having variables in the global namespace rather than nicely encapsulated in objects, or having logic in-line rather than in separate functions.

None of this is to say that what PICO-8 does is wrong. The constraints are deliberate choices, and are incredible aids in the creative process. They force you to consider what really belongs in your game, or at least what different things are worth to you. This mostly goes for the token limit, but is also definitely felt with the graphics and sound limitations. The “fantasy console” gives you one single platform to deal with — one resolution, one color palette, one sound library — and you’re freed from having to worry about all the different options here. (Note that this is very reminiscent of the Java Virtual Machine “write once, run anywhere” promise.)

And the game loop is incredibly helpful for breaking down the frankly thorny problem of handling game input + logic + visuals into easier-to-handle pieces. I may feel uncomfortable with putting more into global state, but I can’t say I’d feel better if I had to somehow manage updating game state and the screen 30 times every second all on my own. (And PICO-8 lets you do that, if you’re so inclined. I’m not… yet?)

One thing I especially appreciated was getting a good reason to dive into Lua for real. I’ve toyed with it before, but nothing serious — probably my biggest thing was making some improvements to someone else’s Tabletop Simulator mod. (There it is, programming + games again.) And I somehow thought that’s what Lua was for — scripting in games. I’d just heard of it being used in video games so much that I somehow internalized the idea that it was created for that purpose. And I was correct in a sense, but not entirely. Lua was created in 1993 (a few years before Ruby, Java, and Javascript; a few years after Python and Visual Basic) and designed to be embedded in other applications to allow greater flexibility and customization. And I really enjoyed it! I mean, apart from array (sorry, “table”) indices starting at 1. Again, I’m not going to say Lua is doing it wrong, but array indices starting at 0 is so ingrained in me — my thought processes, my habits, my math — that this caused no small number of bugs.

That was no big deal, though. My experience as a programmer helped me in a good few ways, especially in noticing the patterns where I have trouble and making some helper and utility functions to give me guardrails.

So I got to really enjoy this creative process and these constraints. It’s funny to look back on various times during the month when I cycled through:

  • feeling like there was still maybe too much freedom
  • feeling like the constraints were helpful but still nice and loose
  • bumping against some hard wall like screen size and resolution, or color palette
  • accepting the situation and finding a solution I enjoyed
  • lather, rinse, repeat

And just like in any effort, there was the biggest constraint of all: time. There’s no relaxing this, no pushing against it and winning. In fact, that went for me in both the obvious way of having to finish this game in a month and carving out moments to work on it, but also how much of the game was built on events happening at specific times, or at least specific intervals. That worked out fine with actual gameplay, but it really bit me when I wanted to make a tutorial and had to figure out ways to pause in the middle of events or delay them so that the player could have time to read and understand what they’re being taught.

As I said in a devlog post, the things I did there weren’t quite “NPC train hat funky”, but I’m starting to understand how things like that happen. I’ve definitely learned some lessons about how to do this better in the future, just as I’ve learned over the years how to write better code for flexibility and testing.

Oh, testing. That’s something that would be a great luxury here. Can it be done? Can I get myself to do it? I’ve never been good at testing visuals and UI interactions.

In the end, I made something that I consider successful and I’m pretty proud of — check out JaunTender on itch.io. But more than that, I really enjoyed the experience, and I felt I learned a lot and had a good time doing it. I learned these skills and about this framework, sure, but I also feel I learned a bit about myself, and experienced some growth as well.

Looking forward to more, for all of it.

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.

Published on December 15, 2025