Twist Turn Shoot Burn: A Postmortem

This was originally written as a blog post on the Ludum Dare website back on October 10th.

Icon.gif

^^^ Click to Play ^^^

It’s now been just over a week since Ludum Dare 47 began, so an ideal time to reflect on how well things are going so far. I’ve been taking part in game jams for seven years now, and this was my 16th Ludum Dare, although you find that every game jam you do has a challenge that you never expect, no matter how many you do (and I’ve done over 50 at this point).

So the game: Twist Turn Shoot Burn is an auto-run ‘n gun, you run around a randomly generated path shooting red things from one of two lanes. Here’s how it was made:

The Idea

349b6.png

As I wrote in my entry post, I wasn’t a real fan of any of the themes. I was actually hoping “Technical Difficulties” would make it to the final voting round, but alas you make with what you do. My usual plan is to brainstorm ideas, with the goal to have at least one idea per theme. Ideas in this case is usually a simple phrase to describe a game’s setting or mechanic.

All I had for “Stuck in a Loop” was this: Run (and shoot) inside a loop.

Yeah, not sure why but even as I slept, my attempts to think of what game I could make around this theme always reverted to this. As such I just gave up and decided how on earth I was going to get a game to work…

Day One

So to people who know my approach to game jams (all five of you…), I have a set of rules that I always follow when working on game jams regardless of length. A lot of these rules were written and refined from experience for efficient development and maintain good wellbeing.

EjL_Em8WsAYHmKA.png

So day one was purely focused to develop on gameplay, and the first thing I needed doing was having the player run around a basic path.

Following rule four (stick mostly with what you know), I figured I’d do a tilemap but I was worried about how to do collisions. My engine’s tilemap system isn’t built to handle slopes and curved paths, and I wanted the player to go around a proper loop. I was worried that I was gonna have to figure out how do write a Sonic-style platforming system. Then I was literally booting up my PC, first thing in the morning, when I realised: I didn’t need to calculate collisions, I just need to calculate positions.

I made each game object stick to a specific position based on an X and Y value (between 0 and 1) what tile it’s currently situated in. The X value would position it from one side to the other, and the Y value would handle gravity and securing it to the floor. I originally had it up and running by midday, however in my original approach, the player would move fine on tiles that moved straight, but would float on turns. It took an hour’s walk, a hour lunch break and about two more hours for me to get it to work correctly.

LD47-00000.gif

It was also during that first lunch break and walk that worked out how to do obstacles. I only wrote four enemies: Same Direction, Opposite Direction, Bounce and Always Flying. I also decided to do something similar to Super Crate Box, have it so enemies would spawn the moment you defeat one. All the enemies use the same movement behaviour as the player, which funnily meant the Always Flying enemy was the hardest to implement because it wasn’t straightfoward to disable gravity.

LD47-00003.gif

You might notice the player had the ability to jump. The original plan was to have the player shoot, jump and change places. I eventually decided to diable jumping because I found myself always changing direction more than jumping.

Day Two

The base game was pretty much done by the end of Saturday, I did want to make the levels more random but I wasn’t sure how to do it, so I decided to leave it as something to implement if I had time. For Day two, it was all graphics and sounds.

This is where rule 5 (“Make Your Content Easy and Noticeable”) comes in. This rule was concieved after Ludum Dare 42, where I spent somewhere around five hours on a detailed player character, despite how small it actually appeared in the game itself.

Piskell is my tool of choice for doing pixel-based sprites, as it’s easy to pick up and test out frame-by-frame animation. All I can say for the player character is that I cannot confirm or deny whether the recent popularity of Among Us or Fall Guys had any roll, but I will say that the 2-bit palette of Downfall was deep in my mind when thinking of the visual design.

Visual effects are also a prerequisite for most of my games, partially because one of my game dev influences being Jeff Minter, and I’m a huge fan of his vibrant nightclub/psychedelic visual aesthetic. The main effects I use were Chromatic Abberation (distorting the red and blue colours), Bloom (make pixels glow), scanlines (TV effect) that constantly offsets, Bad TV Shader (to get the noisey distorted look) and a fisheye lense (to make it buldge out slightly).

LD47-00004.gif

For sound effects, I used sfxia and ChipTone. If I wanted more realistic sound effects and wanted to go with the loose jam rules I’d mix and mash stock sound effects together, but I know with this game’s visual design that I was going with a retro-esque feel.

For music, LMMS. I’ve gotten comfortable with it as a music creation tool, although when I tried to mess around with soundfonts and VST plugins for retro inspired music. That’s when I went back to Jeff Minter’s games and decided to try a drum ‘n bass approach. Fortunatelly I did experiment with this for an earlier Tetris recreation project, and I was able to come up with a 1 1/2 minute long loop that I was satisfied with.

Based on my social media posts, I had everything submission ready by 4:30pm. That meant pleanty of time to get the submission details ready and add in stuff. I added a new enemy at this time, and tweaked around the controls, but I didn’t think there was much that I needed doing. It wasn’t until two hours before the deadline that I decided to give randomly generated levels a go, you can read up on how well that went here.

LD47-00007.gif

Conclusion

I’d say this game went better than I thought it would, I’m always into making small arcadey games and after this pandemic had drained me from doing personal game dev projects, this one just revitalised me in many ways. That’s not to say it was perfect. So time to explain some issues:

  • Camera: I had spent the last hour trying to figure out how to get the camera to focus in on the randomly generated level, instead of the full screen. Unfortunately time had ran out before I could figure it out, so I had no choice but to leave the camera in its full form. The “Player” mode I thankfully decided to leave as an option, as much as I thought it was a fun camera mode, I could tell it was disorientating for some players.
  • The Volume: So when I was working on the music, I had the PC and headphones on full volume, and I thought the volume was perfectly fine. Turns out my headphones aren’t as strong as I thought they were, cause players on some streams were taken aback by how loud the music was. I’ve deamplified the music for the post jam build, but I’ve also had feedback suggesting not to have full volume by default.
  • Menuing: Yeah, I probably could have spent those final hours adding some important stuff to the menus to make it clearer and easier to modify, especially the option to turn off the visual effects that might be an eye strain to some people. In hindsight, I also have a config class that I used in a past game that I could have easily dropped into this game, so saving options would have been a breeze.
  • Linux: As much as I work on Windows, I have a soft spot for Linux and major respect to their userbase. I usually have a Linux Mint distro on hand to easily produce a native Linux build of my games, and let users decide whether to download it or not. This time around, I was curious and posted to a Linux games community (shoutout to /r/linux_gaming on Reddit!) to get actual Linux gamers to try it out. Turns out quite a few couldn’t get the game to work due to a libcurses dependency, and one of the Twitch streamers that tried the game on Arch Linux (shoutout to @marcmagus) found out his gamepad ran funny with axis inputs when he played the game.

So yeah, there’s a lot to deal with. Perhaps in the next update I do to the post build, I should add a long warning for players with senstive eyes and ears before I do anything else. Thanks to everyone for playing, thanks to my friend Kris for helping me with brainstorming ideas and here’s hoping to a good ranking!

Icon.gif

^^^ Click to Play ^^^