In the past few years, I both started going to the gym and I was gifted a Playdate. Both of these things reached their perfectly logical conclusion in me making LOCKER PANIC, a tiny game about being socially anxious and quickly finding the correct locker upon entering a locker room. As I kept making it, I kept rambling about my progress to my friends in a Discord thread that no one actually read. This is my attempt to make that devlog a little more public, readable and enjoyable to follow.
A Beginning
Let's start at a beginning. I have always eyed game development. But I had absolutely zero experience. Well, unless we're counting when over a decade ago, I used flixel to make an extremely simple 2D platformer where literally the only mechanic was moving left and right (and okay, jumping, but not on anything) past PowerPoint slides (I gave a presentation on indie games at school, and felt this was more fun than a normal PowerPoint). But I don't think that really counts, because the point is, for as much as I kept daydreaming up game ideas, and with me even recently making a board game, all ambition was always halted by one thing: my fear of learning to program code.
So when the Playdate finally made its way into my grubby mitts, and I discovered Pulp, which made it seem like coding was completely optional, well, I eagerly started tinkering with it.
I pretty quickly realized that Panic's claim that it was up to me whether to use Pulp's code editor or not was a dirty lie. I mean, I guess, if I wanted to basically just make spaces to walk around in and trigger dialogue, sure? But any sort of mechanic, those juicy bits in games that I found fun to think up? HA. Fat chance. But not all lies are harmful, some can help you along. Because, despite code still being an ever-present necessity, Pulp was still a million times less intimidating than GameMaker, or Unity, or Godot, or Ren'Py, or whatever else.
More limits and less possibilities, as well as it being not just an engine but also a simple pixel art and music/sound tool meant that I felt like I could just get started with tinkering. I wouldn't need to watch a multi-hour tutorial series ONLY to just figure out the engine's UI. So I tried out a few things:
Making a Weirdogs game about cleaning motel rooms.
Making a game that would give people a short introduction of the world of our actual play podcast campaign, AGATHA.
Making a simplified version of a horror-themed hidden object/visual novel hybrid idea I've had for a while.
None of these attempts saw me getting very far. I think the main issue was that even though I didn't set out to make big games here, they still were based off of existing ideas. Even if I started small, in the back of my mind, I had a bigger vision I wanted to try and reach, which made the small beginnings feel too insignificant. They were just a small part of the final product, and there would be so much work left to do to get there. So, apart from making a few screens for each idea, just enough to sustain the fantasy of making a game, and very briefly dipping my toes in code with the motel room cleaning mechanic, I did not actually get far with these projects at all.
Other, more urgent projects came. I became a parent. I took a long time away from all those initial attempts at making Pulp games. And then, eventually an idea presented itself that was free of any pre-existing baggage. An idea for a game that was just... a game I could MAYBE make within the confines of my skills and Pulp's features.
Another Beginning
Eventually, after the first four months of being a parent, my wife and I started finally getting back to the gym. And because my mind is a terrible thing, constantly seeking to add new ideas and concepts and potential projects to my endless to-do list, took the seed of "man, Pulp is a lot more complex than I thought, but I WANT to make something with it, I just need an even simpler idea than the Agatha one" and nurtured it with "lol I always operate by some weird internal logic when I go into my gym's locker room in an attempt to find the locker where I need to have the least amount of social interactions or eye contact as possible... that could be a puzzle game mechanic maybe", and lo, and behold, "WHAT IF I MAKE A PULP GAME ABOUT FINDING THE RIGHT LOCKER IN A LOCKER ROOM" appeared to me.
It would be a while before I actually got around to attempting to bring that idea into reality. It helped that once that tiny bud had sprouted out of the old brainsoil, I'd get reminded of it every time I went to the gym. "Hey, are you gonna do something with that idea?", my brain would ask, again and again.
And once the baby had a relatively consistent sleep schedule that freed up my evenings more, and I felt swamped enough by other projects I needed to do but wanted to avoid (while still maintaining an air of productivity rather than just relaxing)... that's when the time was apparently right, and I answered "sure, okay".
I devised a game that would present the player with a set of stacking rules, such as 1) needing to choose the locker furthest from the entry, 2) choosing a locker furthest from any other person, or 3) passing as few people on the way to the locker as possible (the latter of which was not an idea I ended up implementing after all).
The Actual Dev Log Part of This
April 18th 2026
The first thing I tried to tackle was figuring out how to do a simple countdown timer - for once, NOT trying to make elaborate art that would make me feel excited about playing the game I was building (but then quickly losing steam because I'd imagine all the other art assets I'd need), rather making sure I could deliver the mechanic. Programmer Art is a thing for a reason, Simon.
Although the gameplay concept was mainly a puzzle, I felt that there needed to be some kind of time pressure, because in a real locker room, you also wouldn't just stand at the entrance for a minute to think about the optimal locker to pick. It was a split-second decision made upon quickly scanning the room, and I wanted to replicate that experience.
I found code by JBG on the Playdate Dev forums that helped me implement a basic timer. However, I quickly felt stupid that after messing with this for maybe an hour or two at best, I did not have an immediate deep understanding of a programming language that was entirely new to me (reasonable, right?). The issue with the code was that time passed normally going from 20 to 10 seconds, but then sped up incrementally once the timer dropped lower. But pretty soon after my frustration, I found code by orkn that addressed this issue. I still felt stupid though! Because, after all, I just copied something someone else did (so reasonable).
Regardless, in one evening, I still had managed to implement one of the pillars of the gameplay. And the timer could even be reused in some of the other ideas I'd had!
April 21st 2026
I managed to implement an actual gameplay loop and found a way to switch between rooms that wasn't dependent on Pulp's default "Exit" tiles, but rather pressing A (on screens displaying the game rules), and standing on a specific tile when the timer ran out. This had, again, just been accomplished by me repurposing code that had been shared on the Playdate Dev forums, this time by Flomize.
Now I had a good foundation to build the rest of the game upon. This was a fun way to approach things. Not fully planning everything from the start and knowing exactly which levels I wanted the game to have, but having something playable and functional, even if it was absolutely tiny.
April 22nd 2026
With a lot of experimenting, I ended up being able to introduce failure states to the game. One of the mechanics was that I didn't want players to be able to pass strangers. I used the triggering tile mechanic from Flomize and repurposed it. I manually placed these item tiles around my NPC sprites, which would then "collect" the failure state and reset the level. The "x" the tiles displayed was a placeholder to make placement easier, and I would later make the sprites fully blank.
I ran into the issue of the item tiles remaining "collected" and then immediately failing the level as soon as it was reset. Similarly, I realized that a success in a previous level remained collected as well, and you could win succeeding levels simply by... not doing anything.
I added a reset of both the failure and success states players would get upon collecting the tiles into the level load functions, and the issues were solved - and I slowly felt like I was actually starting to maybe understand PulpScript's logic a tiny bit.
One thing that seemed weird to me though, was what stuff would need to be put in the player script to work. All the text I had displayed in the "rule" and "failure" rooms I included in the player script and had triggered through the code checking which room the player was on. It would have made so much more sense to me if I could have just written that code into each room's individual script instead. Though I guess at least this approach would require me to not switch between different scripts as often?
Another frustration appeared in needing to manually make line breaks in the text display, and not even being able to enter actual breaks but needing to type "\n" which just led to me having to always test out the text appearance in-game and needing to readjust it again in the code afterwards.
April 23rd 2026
I only made one level that night, but spent a lot of time trying to polish up the rest of the game, rewriting "rule" instructions to make them clearer, reworking level titles, reworking line-breaks, and making the solutions for the tutorial levels more consistent according to the rules.
I started thinking about the scope of the game some more, wanting there to be 10 "full", non-tutorial levels. That seemed like a good enough length to layer the rules in an interesting way without the mechanics getting boring, or needing to introduce even more rules to keep escalating the complexity. I wanted the game to be SMALL, so I could finish it before running out of steam.
Having worked on the game for three nights in a row made me feel accomplished, and like I had actual momentum. The real reason I kept pushing myself to keep working on it was that I was afraid I'd forget what I was doing if I lost the momentum. Fear is a powerful motivator.
April 24th 2026
I was very tired that night so I only built three more levels. And then one more. And yet one more. I then brainstormed about concepts for the remaining levels. So much for being very tired!
I also started reconsidering the title of the game. The very first title I gave the game when I created the file in Pulp was "Stall Staller" but that made it seem more like a bathroom than a locker room. I also considered "Loco Locker" or "Loco Room", though I decided against it. Even with the player character's anxiety over finding the right locker being a strong exaggeration of my own feelings, I didn't want to imply that this kind of behavior was "crazy". I also considered "Locker Lockdown", but eh. "Locker Panic" was better. It would do.
April 26th 2026
One of the levels I wanted to implement was one with a sideways layout. I just wanted to have a way of throwing off the player from their routine after a few normal levels, and wanted to heighten that by also flipping the controls (so, UP would be RIGHT, for example). What's a more classic video game trope than inverting controls? I managed to get as far as actually changing one direction, but once I tried implementing it for all four directions, the behavior went totally crazy. Additionally, I was able to clip through walls with this new movement inversion, which was less than ideal. I eventually posted on the forums about it since I genuinely had no idea how to solve this and could not find existing code for this kinda thing.
April 27th 2026
I designed the remainder of the levels. And with knowing that I wanted moving NPCs/obstacles in one of them, I decided to watch one of SquidGod's tutorial videos.
April 28th 2026
SquidGod's video had helped me move the NPC sprites around, but the thing was - I had a different "damage" system set up, where the surrounding tiles would actually damage the player rather than the tile with the NPC on it. So, I also needed to move the surrounding tiles. I tried to automate this at first but ran into issues. Instead of bouncing off the wall like the NPC did, the trigger tiles would combine into one, or replace the NPC tile.
I eventually ended up hard-coding this. 144 lines of code for just ONE moving NPC because I couldn't figure out the smart way to do it!
But --- I only planned for ONE level with moving NPCs, so I felt like it was okay for me to do this manually. Of course, if I had wanted to have more levels, with moving NPCs, it would've been worth investing time into figuring out how to do it right, but that's not the game I was building for now. A problem for future Simon to solve in a different project, perhaps.
April 29th 2026
On the forums, MintFerret had responded with a good solution to the movement rotation and had even offered a fix for the player character clipping into walls. However, there was some kind of issue with the code. When bumping against a wall, the player would get moved diagonally.
I tried and tried to come up with fixes for this issue, but kept failing. I became extremely frustrated, because it felt like with my limited understanding of PulpScript I could only guess at possible solutions and then would invest a lot of time in trying them, only for them to not work out. Even worse, there was no real way for me to know why my attempts at solving the issue didn't work, so it didn't feel like I was learning anything from the process!
I almost considered dropping the project altogether, but realized that was ridiculous. I'd already invested so much time in it, and the rotated movement mechanic was really just a nice gimmick, not something essential to the game. So, as you can see in the final build of the game, I just left that level at displaying all the sprites sideways, but keeping the default D-Pad movement.
May 1st - 2nd 2026
Having given up on trying to get the movement rotation to work, I instead spent a lot of time polishing what I'd already built and tying things together. I fleshed out the game ending, and added an intro. Really all that was left before being ready to share the game for playtesting now was creating music, sfx and artwork for the rules and failure screens.
But upon starting to mess around with music, I quickly found that I knew as little about creating music in a sequencer as I did about programming. I did wish that Pulp's weird little piano feature would actually allow you to record the keys you're pressing rather than having to manually place notes, because that would have felt more intuitive.
May 8th 2026
Out of necessity, and also a little bit out of frustration over the music providing a bigger hurdle than I'd anticipated, I took a bit of a break from the game. But I got back to it a few days later and worked on more music attempts. I eventually decided I'd accept it sounding imperfect. The game itself, after all, was also pretty imperfect! And that was fine. It was my first game.
May 9th 2026
After creating artwork for the rules/failure screens in Photoshop and importing it into Pulp (honestly kind of a pain in the ass - I know there's tools that make it faster but I'd have needed to figure those tools out first, so I opted for tedium instead), I actually had a pretty clever idea, if I may say so myself: I used the newly existing tiles to make the title screen for the game look more intriguing. The simple text I'd written with the room tiles now had a lot more character, without me needing to fully create a new splash screen artwork entirely.
I did some playtesting of the game, fixed a flaw I noticed, and just did a whole lot of polishing. It was exciting to have the game really start to feel like a complete little experience.
I was starting to consider adding a hint system that would allow people to choose to receive help upon failing a level. But I wanted to wait and see whether people would even feel it was necessary, or whether they felt the game's puzzles were all pretty straight forward.
I had by now also gotten a better understanding of PulpScript and felt like I saw a lot of ways I could've handled various code solutions more efficiently. The thought of going back and tidying up this project was extremely undesirable though, so I decided to just keep that stuff in mind for any potential future projects.
May 15th 2026
I took another break and then finished up some final polish on that day and share the first full build with some friends for playtesting. May 15th! And I'd started serious work on the project on April 18th! I'd made a full (albeit very small) game in less than a month! This was an exciting feeling.
May 16th 2026
After some honest feedback about the music, I decided to try and attempt replicating "Hall of the Mountain King" in the Pulp Song Editor, based on someone else's 8bit cover of the song. I later got some feedback on my original music fitting the game's panicked vibe, even if it wasn't super pretty, so I eventually decided to stick with it. Especially since I'd created a bunch of variations on the music, used across different levels. Doing the variations on the new music felt like it would've taken more time than I wanted to invest in a change that I didn't feel fully convinced about.
I also fixed some issues that had been raised by playtester Quippersnapper, created icon and wrapper graphics and added an extra scene to the game's good ending to make the transition between two very different scenes feel smoother.
May 22nd 2026
Quippersnapper and Grawlich gave me some feedback that made me feel like the accessibility features / hint system I had previously pondered were a good idea, I attempted to implement this system. It was a pretty simple setup. Basically, any time players would go to the failure screen for a level, a "failures" stat would be bumped up to 1. When the corresponding level would reload, it would check whether that stat was set to 1, and if it was, players could choose to either increase the time limit, or show the "solution" tile. I later changed the required "failures" stat to 2 in order to trigger the features, so that players wouldn't feel like they were expected to get things right on the first try.
In implementing the time limit increase, I did something kinda weird. Unlike before, time now passed at twice the speed that actual seconds do. Once players would choose to "slow down", time would actually pass at real-world speed. I initially wanted to just bump up the time limit by 5 seconds but there were some issues with my implementation (it didn't immediately bump it up after choosing that option, only on the next load of the level). In experimenting with alternative solutions I found this one, and I felt it was kind of a cool ludonarrative thing? Like, if you're stressed out and not taking a moment to slow down, time feels like it passes faster, and this could be a way to mimic that feeling. Though I also wondered whether it would just make people think the game's timer is broken from the start.
May 23rd 2026
I did some more polishing and fixing, and added a third, secret, ending upon Quippersnapper's suggestion! I also started setting up the itch page for the game. I was torn on whether I should try to submit the game to Catalog! It was, after all, extremely fast to get through if you didn't struggle with any of its challenges. But at least I knew, regardless of that choice, I definitely wanted the game playable in browser on itch.
May 24th 2026
Despite being dead tired, I sat down to get started on writing this post. And then I just wanted to keep going and stayed up too late to finish writing it in one go lol.
Closing Thoughts
I still am undecided on whether I wanna submit this game to Catalog. I think I'll wait and see what people's reception to its itch release is. I'm in no hurry here.
The main thing that matters is - I made a video game, with zero prior experience in coding. That's really exciting. As I mentioned earlier, I think Pulp's limitations really helped make it feel less intimidating than any other game making tools I'd previously looked into, even if there still was a much bigger need for coding than I initially expected.
I am strongly considering going back to some of my initial game ideas in the future now that I have a lot more experience in Pulp. I kind of doubt I'd wanna try switching to the Playdate SDK soon, or any other non-Playdate engines. Just gaining more experience in Pulp seems the most appealing way to expand this new-found skill for now, even if what I learn here might not carry over directly to other ways of making games.
If you played the game, or read this post, thank you! I hope it was interesting to follow along.