Mini Jam 166 Retrospective.

Hey everyone, I wanted to do a postmortem on the jam process and how I arrived at this particular game, so here you are, hope you find it interesting!

Mini Jam 166 Dev Notes:

The Initial Plan:

I was looking into attending a jam, and I saw that the Mini Jam that had just started had a restriction on the color green. I thought that was particularly interesting, so I decided to make a game for it. I also had a number of things I wanted to work on, specifically, creating a proper pixel art style project.

I had recently done an endless runner style game in Godot 4.3 alpha, and I thought this would be a good opportunity to continue along those lines, and show off what Godot 4.3 could do with parallax, one of the many plans that eventually faded into the limitations of time… One of the initial design problems this brought up, is that with no green, many of the things I would put in the background – trees, bushes, grass, hills, were off limits. With this in mind, I decided to make a game where you’re running high in the air, so those objects wouldn’t be present.

My initial plan was to have buildings that would skew, with the idea that where on screen you made the jump would influence the actual distance. Then I would adjust the players position on screen based on their speed, allowing them to speed up or slow down and introduce various obstacles to dodge. As they could only travel at night, the idea was that going faster would be riskier, but if they didn’t move fast enough, they would run out of time to deliver their package. The plan was to have a progress bar on top of the screen to show the overall progress, and over five nights, you would travel five environments until you got to the end of the game, either reaching the end of the progress bar and winning, the end of your five nights, and getting a bad end, or falling to your death at some point for a game over.

I created my initial pixel art character, set the screen resolution down to what the GBA used, 240 x 160, and got to work on the resizing code. The resizing setup was the biggest most pointless waste of time in my project. For some time, I’ve found it annoying that the resized games when you force them to keep aspect ratio so that the pixel art isn’t distorted, black bars will often appear at the edges of the game. To ‘fix’ this, I wanted to go with a Super Game Boy system, where I would provide a border to go around the game, and resize the internal box in whole number multiples.

Challenges:

I ended up trying a number of different approaches in a shotgun manner, trying to find the combination of ease of use and functionality that would let me do this. The problem is that the correct way to do this seemed like a time sink to learn since I had never worked with it before, so I ended up using a worse solution with some drawbacks, most importantly that I couldn’t use Godot’s built in camera + parallax system. I figured that would be fine though, so I just went with a static player and moving background elements.

At this point, it was time to animate my character. I decided to do a simple bones-style animation since that’s what I had done last time I made a project like this. In retrospect, I think this was a mistake. Half way into doing the posing for the 8 frame animation I was steaming with how much time it was taking me. I managed to leverage this somewhat in the end, but at the time, I was really frustrating, since I felt I could have been done with a sprite based animation in half the time.

To me, it made a lot of sense to set a running across the rooftops game at night. This reminded me of the cyberpunk genre, so I dedided to go with the main character being a courier and popped a briefcase in his hands. I made a building I repeated to have him run across, and added in the collision, gravity, and functional part of the jump.

I decided that the plot of the game was that you can only do your courier job in the overnight hours, so I added a light to the scene, and set it up so that it started fairly blue, faded to black, then came back up to a light red. I set the intensity of the light pretty low at that time, as I wanted it to be more of a subtle lighting effect than anything else.

When I was working on the building, I had some of the windows lit. I realized that it was a bit odd for the same windows to be lit all the time, so I made all the windows identical, and put light objects in all of them, that I could turn on/off in code. I tied it in to the day/night cycle, so that the later at night it became, the less likely it would be that a window was lit. Given my plans at the time, this was a waste of time, but it became very important in the end.

Graphically, dealing with the jump became complicated. I didn’t want to do a full animation for jumping, so first, I just paused the animation when in the air. At the time, this looked pretty good, if a bit goofy sometimes. If I knew what I was going to end up doing, I just wouldn’t have changed the animation at all. I think I should have made this a lower priority in general. In the end, I ended up doing some needlessly fancy logic to have the animation play after the jump until it hit a take-off frame, pause on that, and when the player started falling to continue the animation until hitting a landing frame, pause on that, and then resume on landing. Despite my anticipation, it didn’t look that great, and it was a fair bit of coding for something fairly simple.

Around here, I realized then that my buildings didn’t have a lot of space for random obstacles, and while I had planned to retune the jump mechanics to allow for controlled jumps, there just wasn’t a lot of room to jump twice on a single building. Rather than trying to do a larger building sprite, and redo the scrolling logic, I decided that there just wasn’t going to be obstacles on the rooftops, I would have to do something else.

Music Break:

While I gave my mind some time to solve the problem of where to go, I made a music track in FL Studio. I knew I wanted to make some good music for my game, and I had been working on my music skills lately. I wanted to get that dark mysterious cyberpunk feel going, and really focus on the stress of the game, so I worked in the minor. For me, the most interesting thing I did, is after making some basic drum loops I liked, I replaced two of the percussion instruments with tech/synth feeling musical stabs. I wasn’t too happy with how little what was supposed to be my melody stood out in the final mix, but it was supposed to be fairly chill and tense, and I felt like I did a decent job of that, so after mixing it down and doing some basic mastering I added it to the game. I think it was worth it in the end, but it did take a good chunk of time for me despite only being a 30 second loop.

Leveraging Existing Work:

At this point, I realized the darkness of the game, as light as it was, was kind of annoying, but it was also a way to tackle an existing problem, jumping from one building to another, all the same size, when you can see each building easily enough wasn’t enough of a challenge. Using the bone-style animation I had done, it was easy to put a flashlight in my character’s hand, and now he would use his existing animation to swing it around as he ran, shining it at various parts of the stage in front of him as he went. I combined this with turning up the time of day light, so you can’t see anything at all during the night hours except the lights from the windows, which are now an important part of the gameplay, and what your flashlight hits.

Around this time, I got a question about how long a 1.3 second delay is in terms of input, so I put together a little demonstration, turning my flashlight on or off based on button press. Rather than scrap this when I went back to work, I put some code into the game to make your flashlight occasionally malfunction and shut off. After playing with the turn-back-on time delay, I found that right around 0.7 seconds it started to feel stressful, so I made that the amount of time it stays off for, enough for you to start to be uncertain where you are.

After working on the music, I went ahead and generated sound effects for jumping, falling, and completing the level in LabChirp, and added them where appropriate. I changed my time-based game end to a system where it would enable winning, and then you would win the next time you landed on the ground after a jump, which was made easy by my needlessly complex jump ‘animation’ which thurougly tracked your jump state. Falling was defined as having left the area I had defined as my ‘area the game takes place in’ for my resizing code.

At this point, I was dangerously low on time, so I set up a quick room change system, and duplicated the room, putting together variants of the room with variants on the windows. I wasn’t happy with the final versions of any of the art I did in this section – my pyramid didn’t extend down far enough, and my trees didn’t extend up high enough, and the motes of light in them were quite lacking in a few ways, but I was on a time crunch. I leveraged the art I made for the icon, and the suitcase from it as the central focus of the final you win screen, and completed work on it with a minute left.

I then struggled with the exporting for about 45 minutes… I suppose it was to be expected given that I hadn’t done an export since the version change, and I wanted to push to include an HTML version which I had never done before so that people wouldn’t have to download the game to play it and so would actually give it a try. One of the downsides of this is that you don’t really see the resize code in action unless you can resize the window… so the silly little feature that took hours to get working, and complicated the rest of the build for the most part won’t really be seen by anyone.

What I would do differently:

When I look at it, the core, core thing I needed to do, and the source of all the problems is that I did not get the needed vital things in game for my design before I started worrying about nice to have things, like lights in windows, a day night cycle, and getting rid of the black borders/allow stretching when scaling the game. Most of the nice to have things ended up becoming core features, because they had to be in order to make a game out of what I had made under the time constraints. It wouldn’t hurt to have done more work on day 1 and 2 as well to take some of the pressure off of day 3… It would also have been nice to have gotten at least a beta verson online ahead of the deadline. Then I could have done some testing if nothing else.

What changed:

Cut:

Obstacles on the buildings

Adjusting player speed + overall progress bar

Falling cut-away animation

Going inside object + animation

Skewing objects

Parallax objects*

Executed:

Running animation

Night/Day cycle

Jumping from high above the ground

Music

Sound

Added:

Darkness as a mechanic

Windows and other environmental lights

Swinging flashlight

Flashlight failures

What I would want to add now:

Longer, brighter, pre-night section.

Guarenteed flashlight working time between failures

That speed/progress mechanic would still work great

Clouds/Stars paralax

Longer light beam

Flashlight fix QTE to speed up recovery?

Dedicated victory music

Proper main menu (play credits quit)

Credits scene

Improved objects for stage 2 and 3

Improve stage 3 lights.