Between the Boughs by Evergreen Games

making Out of Time

this is a postmortem on my recent game for the 2025 GMTK Jam, Out of Time! You can check it out here!

in the months leading up to the 2025 GMTK Jam I was working on ESPER//EXILE and beginning to ask myself what might come next. the question of increasing my reach was starting to come up, and I felt that participating in a game jam could be a good way to do so. it seemed like the GMTK Jam might be the largest game jam these days, but unfortunately it was going to conflict with my birthday. already being a bit tired from finishing my last game too, I assumed I'd skip it.

well, I guess I changed my mind! a day before my birthday I thought I could give it a shot. after all, a lackluster jam game might be better than nothing. I knew I'd be busy for much of August, so this would be my last chance to work on something for a little bit. the technical implementations for Blintzy's Shattered Dream had gone a little long and strained some of my motivation. working on a game jam started to feel like just the right thing!

so what I decided was to constrain myself and make something in the 24 hours before my birthday. I could make something tiny and light on technical challenges and give myself a nice little snack of gamedev before my birthday and busy August picked up.

I was gazing at the jam page on the edge of commitment, running through my thoughts about ideas I could make. I know GMTK itself revolves a lot around puzzles, and that sounded like a fun new thing to try for me. making a traditional level-based puzzle game would give me a formula I could jump right in with, helping keep the amount of things I needed to come up with gentle. with that established, I started running my imagination about "Loops" (the jam theme), and quite quickly my mind wandered to Minit by jwaaaap, kitty calis & friends. it felt just perfect!

design

with that, I'd began thinking about how an experience like that could make a novel puzzle game. I wanted the time loop to be a foregrounded element, so for most of the levels I kept the time between loops really short. this would make it the kind of game where you have to solve the puzzle without changing the level state much. for that, a puzzle where navigation was the key challenge felt appropriate. unlike Minit, you as the player could be unconstrained by the time loop and explore the area freely. I thought that would reduce the level of stress of the game and emphasize the level space itself.

I added doors as level exits, and right away thought having keys might be nice too. having keys would give the game a layer of complexity that I could adjust for each level. I liked that, having something like that I could weave into the game's fundamental language. it wound up being a really fun tool in level design, in addition to giving me something immediate to design around in each level across the entire game. it gave each level a nice dramatic structure, a part 1 of "how do I get the key?" and a part 2 of "now how do I get to the door?". that's something I could play with to create unique narrative experiences for each level. a few people have remarked to me that there's an amazing amount of levels for it being a 24-hour game, and I think having the key to tie the game together helped an awful lot to do so.

after that, I thought it would be fun if you could unstick other things from the loop too, just like you are. I started getting the image of the player being this sort of time traveling character, or like a good version of Dio from JoJo's Bizarre Adventure. I added functionality to let anything unstick from time, and I thought it would be nice to portray them as "bullets", first for their immediacy and second for whatever strategy might arise from the ranged aspect. by constraining time bullets to only moving left and right, it gave me another dimension to design puzzles around. rather than hard-coding things to be unaffected by time bullets, I could just design levels to where certain things were unreachable by them. this let me design "sprint" levels where you have to hurry with the unfrozen key before the level loops. the time bullets also gave me a bit of an image of Danganronpa, which I found fun.

my approach to designing the levels was to try and achieve these goals with each level:

I wanted to focus on novelty, where each new level showed off another neat thing or had a fun bit of drama or visual composition. as much as I could, I wanted to create an experience that felt cute and pleasant much moreso than brain-breaking. which is a really good thing, because it seems this wound up having a good amount of bite nonetheless!

for this game, both the levels and game elements were designed as I went. this way, the conversation between me and the game could develop in a similar way as the conversation between the player and the game--each level was me exploring the design space for myself too. I'd make each new game element as I went, at the same time they were being introduced in the levels. this is another thing that I believe helped me make as many levels as I did, by keeping my process tidy and aligned with the player experience.

if I approached it with the intention of making something difficult, I think it's entirely possible I would have wound up with something unfinishable for all but the most hardcore puzzle fans. it's yet another good reminder to me that my perception of challenge is quite skewed as a creator, and it might even go doubly so for a puzzle game!

I wanted to be careful to craft the tension curve (like a difficulty curve!) thoughtfully for this game, since I know puzzle games can create cognitive overload easily. to that end, it seemed like levels where new game elements were introduced were a nice spot to break the tension. since I knew the challenge was increasing, I also placed a few intentionally easier levels to provide a bit of a break.

I'm quite pleased with the spiral level towards the end, where all you do is walk through the spiral to the eventual door at the center. when I was trying it, freeing up my mind for that moment was both a nice reprieve and a source of uneasiness. the drama of the level composition gets to combine with the absence of a puzzle to solve to feel a bit uncanny. this way it could be both a "port in a storm" and an "eye of the storm" leading up to the big final challenge.

for that level, I knew I wanted it to be something you'd solve in reverse, giving it a feeling like time was wacky. I also wanted to incorporate all of the game elements, but not bring out any new interactive properties. I wanted the focus to be on the level alone here and going through that dramatic arc. I wanted it to feel kind of dizzying and overwhelming, like your character (and likely you the player) were becoming after all this adversity. I was overwhelmed and exhausted myself at this point, so I couldn't polish the level quite as much as I wanted to. I was just happy to be near the finish line.

narrative

when originally designing the game, I wasn't decided on how puzzle-y I wanted to make it. I thought just as much, it could be a very light puzzle experience that was mostly focused on the texture of a space stuck in a loop, like a diorama in motion. I also considered something musical, since the looping nature of the game brought my mind to drum loops. both of those still sound like lovely concepts to me. I decided to stick to doing a conventional experience for simplicity, and so making a straightforward puzzler seemed natural. I've played a good number of block pushing games, so my mind went there first before I allowed it to diverge with other game elements.

once I introduced the friends you have to save, I knew what I wanted the implied narrative to be: some kind of tragedy has happened, and for one reason or another time has been suspended in a loop. now you can try to save all your friends and escape to safety!

for me, atmosphere and narrative is often the most important thing about a game, something that can make me enjoy a game no matter what the genre is. I enjoy being immersed in aesthetic and conceptual spaces, especially ones that feel nice or give me something interesting to think about. though I was constrained here and wanted to focus on the "game" parts first, I still wanted to weave those interests of mine in somehow. so adding the friends to save both added the final layer of complexity to each level's structure and let me add a touch of warmth to the game. it's a nice contrast with the rest of the game being tense and moody.

my favorite friend to save was later on, where there's a waterfall coming down and some spikes before it. originally, they were going to just be hit by the waterfall, but then the level would be solved by just stopping the water. I wanted this level to be more complex, so I added spikes and blocks to push (with the secret solution that you can freeze this friend!). now your friend would be running to escape the waterfall, not having realized the spikes in front of them. I liked this as an empathetic moment, showing an extra layer of vulnerability that reflects how hard it is to act perfectly in a time of crisis.

it took a while to know how I wanted the game to end. to keep things simple, I originally planned to have the "level complete!" screen show a "game complete!" and let that be it. but I realized without any extra work, I could make the completion screen be a level itself, just without a door. I thought it would feel really nice to have a moment of serenity at the end, where you and your friends are all in safety. when I got to making it, the idea of it being a beach party came up naturally. I added the food and little umbrellas, as well as the little kissy you can do by bumping into them. it wound up feeling like a really nice moment to bask in!

code

this project worked in the constraints it had thanks to the existing code I'd written in pico-8 for ESPER//EXILE and Blintzy. I have a pretty mature "pattern" system that lets me define sequences of instructions each frame, and I can do things like loop them. it's really nice and flexible, and somewhat resembles Game Maker timelines for anyone familiar. unlike what you might expect, the patterns don't actually loop here though! instead, at the end of each loop, the level just reloads while keeping a list of exceptions for things not bound by the loop.

I only had to write one particularly new system for this game, which was a level system. I knew I wanted the level creation to be primarily tile-based, so I could just go into pico-8's map editor and have an intuitive experience making levels. Blintzy only uses tiles for the background, but that wouldn't be as feasible here for something that'd have a lot of game objects, the level making experience would just feel awful. so I wrote a system that would associate each tile with a different game entity, and that worked quite nicely to serve my needs.

it required a little scaffolding to get it working nicely and not re-instantiating persistent objects each loop without making my design experience clunky. I got it working by giving each entity a originx and originy value, which would be compared against the level data to make sure persistent entities wouldn't spawn twice.

finally, it used a modified version of the code Blintzy uses to spawn each level's entities. I can define level data like this:

level={
	looptime=60,
	tutorial_text="You're out of time!",
	entities={
		{2,{
			pushable=false,
			musthit=true,
			pattern={
				0={fn=go_down},
				// etc...
			}
		}}
	}
}

what's happening here is with a Lua table, I'm first defining properties for each level. then I have the entity information. in Blintzy, I tell the game which entity type to spawn and where. here, I'm giving it a sprite index (the "2"). when the level constructor loops over the tiles from the map data, it'll check this list so see if there's anything with the same sprite index. if so, it writes those properties over the entity's default data, which you can see an example of below. I really like this system! thanks to it, I was able to make entities have specific behavior each level in a pretty easy-to-manage way.

the entity system I used was also a simplified version of what I have in Blintzy. that game has a pretty sophisticated pseudo-component system with "tags", where I can write universal behavior that applies to anything with the tag. here, those tags are just regular boolean values that lived next to the entity's other parameters, like so:

entity={
	sprite_index=1,
	pattern={},
	pushable=true,
	suspendable=false
}

I made another table to call an update function for anything with the associated tag.

update_map={
	pushable=push_update,
	// etc...
}

for anyone interested, the game's full code is viewable by checking the lexaloffle BBS post here and clicking the button that says "code" on the game player.

in all, I'm really fond of both these simplifications to Blintzy's systems. they're simple, flexible and ergonomic and helped me get straight to thinking about the game logic and level design without too much extra fuss for me to worry about.

by the end of this project I was really starting to feel the strain of using pico-8's code editor, but there's something I'm really attached to about using it too. I really like pico-8 as this self contained thing, so I've stayed reluctant to move out of using it by itself. plus it's cute! I start feeling strain when my code gets long. it'll start being a lot of work to scroll up and down the code and keep a high-level sense of where everything is. that sense of a mess starts to affect me pretty quickly, which also made the later stage of development here harder than I'd have liked.

in the future, I might give in and start using an external editor. or I might even take a break from pico-8 in general, as it's begun to feel a bit claustrophobic to me. there's a lot of up and down there, because I like that I've been able to develop such a mature and handy codebase in it, and I've gotten quite good at working with it. I'll have to see what feels right once this busy august wraps up.

conclusion

overall I'm quite proud of what I was able to make here in just 24 hours. I learned how rewarding making puzzle games can be, and it felt like a reminder that I'm capable of a lot more than I give myself credit for. following my conclusions after making ESPER//EXILE, it's re-emphasizing that the skills for me to work on now lie in continuing to improve my art, music and marketing ability. I also learned that while I can very much make a game in 24 hours, it comes at a cost. I spent the next 3 days burnt out. and while it's what I set out to do, this game being very much a "programmer game" is making me think that in the future I maybe could try making something more art-driven, like my beloved friend alix's works.

with that said, I'd like to give a shoutout to all my points of inspiration for this project:

thank you everyone!