I'm writing this a day after finishing the game. Is that too early for a post-mortem? I wouldn't know, I've never done this before.

Background

When I started thinking up a concept for the game, I quickly settled on a couple of pillars.

1. Small-scale. My entry last year suffered from having too much open space with little to do, which dragged down the pace. To prevent myself from making that mistake again, I quickly settled on a constrained space. On a whim, I chose to use a 4x4 grid for every level and stuck with it.
2. Event-sourced-ish. I work at an event-sourcing company (not as a developer, don't judge them by my code) and over the years I've heard a lot about the advantages and implementation of event-driven applications. I decided to try implementing something like this in my project.
3. Time travel. This felt like a logical step. Event-driven systems tend to allow you to scroll back and forth through time, and time travel felt like a nice way to play within the constrained 4x4 grid.
4. A device. I wanted the game to feel like operating a physical device, with different switches and knobs for the various features. I also imagined parts being added to the machine throughout play.

Preparation

I quickly settled on making this in HTML, CSS, and JavaScript. Next to TIC-80/Lua this is the environment I'm most comfortable with, and it would easily allow me to set up the device using 3D-transformed CSS elements. Ahead of the challenge, I set up a project where I built the basics of the 3D advice. I also borrowed some code from my last two entries, so I had a CSS CRT simulation, input handlers, Dijkstra's algorithm, and a handful of helper functions ready to go. I also put in a PR for an open source midi library so I could use some midi music in my project.

I had a rough idea for the game in my head, but didn't plan anything out on paper. I mentally divided the project in six rough chunks for the six days, so I'd have a spare day for things that would go wrong.

What went right

I created basic event-driven system easily and in way less time than I had planned for. To celebrate this, I allowed me to spend the time saved playing with the aesthetics. The Gruvbox color palette worked very well for what I was trying to achieve, and I quickly and easily slapped together a little music player (inspired by Quadrilateral Cowboy) to add to the device.

What went wrong

While a basic event-driven system was quickly implemented, it didn't account for the type of time travel I was using. I didn't want to just go back in time, I wanted to go back in time and add events to the timeline. This meant some events should be affected by the time travel, and some shouldn't. This also meant events weren't allowed to spawn other events, since this would mean the events would duplicate whenever the player would go back and forth in time. Getting this to work properly took me almost two additional days, forcing me to drop the item/equipment system, character progression, an in-game tutorial, and more advanced AI.

What I should've done differently

While the time travel issues were a big time sink, I don't think I handled it poorly. I just lacked the experience required to get it right immediately, which is exactly the reason to do these kind of jams.

What I should've done differently is the enemy AI: enemies should move. At the moment, they only twirl around until they see the player, making the world reactive instead of proactive. I don't know how I managed to overlook this during development and testing, but I did.

Overall, the game could've done with being a bit more approachable, with more information and better feedback for the player.

What's next?

I usually start planning changes and updates for my jam projects, only to never get around to them. This time, I'm happy to let this one be. It was fun to work on and I'm happy with the result, but it's time to move on.

I do think I'll adopt and expand the event-system. I'm still hoping to finish/redo my unsubmitted 7DRL2023 project, and the event system would be perfect for that.