Fire Flier: A Weeklong Gamejam Shmup

[whiletruefork]

Too Much Exposition
I learned about Gunner Parade '22 Game Jam - itch.io by accident and it’s been years since I’ve done a game jam proper and I’ve never really worked in this genre and I’ve got a lot of work things going on and I’m working on what is either a sort throat or COVID (whoever wins: we all lose) so I was like, perfect, let’s do this.

Most of my experience with the classical shmup genre comes from the 90s (Parodius, mostly) and my only extensive experience with top-down stuff was Mars Rising (or arguably Wingnuts?). I’ll be honest: most of my indie gamedev journey is about trying [/failing] to recapture the joy of Ambrosia and Freeverse games from back in the day. I know, intellectually, that what I’m really trying to recapture is the freedom of my early 20s, but don’t tell the rest of me that.

The Pitch
My first instinct was to make this a nonviolent game. I had earlier been discussing a sort of water balloon based Scorched Earth with my 8 year old- the idea being that you were a farmer and to water crops you had to lob water bombs parabolically. This felt like a pretty good crossover idea, and the jam theme is “disaster” so I think it’s a great thematic fit.

You play a fire fighter piloting a water bomber fighting a raging forest fire sparked by a meteor storm:

Asset Forge for the win yet again.

You’ll fly along a corridor of burning forest and you have four mechanisms to engage with. The forest is a scrolling hexagonal grid (so that I can re-use assets from HexTracks). This also gives me a nice, discrete grid of terrain that I can do some cellular automation at for spreading the fire.

Shmups are also traditionally pixel art because of the precision that format allows- I’m ceding some of that precision graphically, but by using a grid (which will eventually get callouts) to clarify what is being targeted and what’s on fire and so on, I hope to mitigate a lot of the fuzziness.

Ignore the extremely high number of boulders; I’m working on the core framework before I go clean up the map balance and graphics. Eventually the plan is for there to be mostly clumps of forest, with barren or rocky areas to offer some respite, plus a smattering of water features (see below).

There are three main mechanics currently planned for the player to manage:

1. Water Bombs
   These will be launched directly ahead of you and automatically fire at an aiming reticule that will move up and down the screen, so timing is important. Water bombs will clear the hex they land in of fire. Optionally charged up to clear the surrounding 6 hexes, too, at the cost of more water expenditure.

2. Meteors
   This is the “flying enemy” analog. I decided that I did not want to have villains in this game, just a disaster that you are on the front lines of and have to contend with largely by yourself. Meteors will take a few forms- some will basically fly down at you (to be dodged or eliminated with your water canon), some will target hexes and drop down onto the map and set new fires, and some will explode and send debris everywhere to be avoided. These will be the source of the “bullet hell” mechanic.

3. Limited Water
   Water doesn’t grow on trees you know. It grows in lakes! There will periodically be lakes and ponds that the player can dip down into to refill their water supplies. This is a short (~5 minutes) score attack game, so my hope with this mechanic is that the limited water encourages a certain economy of firing. Precision will/should matter more than just spraying all your water over the map, because in the latter case you will have to fly by a lot of fires you lack the water to extinguish.

Progress So Far
I’m a day in and I’ve got a decent start:

Granted a lot of the progress here is cosmetic/atmospheric, but the mechanical scope is fairly simple. The immediate next steps are to set up a looping framework so that terrain tiles that roll off the bottom of the screen can be pooled and re-used for incoming terrain. After that, the water-bomb targeting system is next, and with it the start of an an actual scoring framework. Then water economy and filling the plane’s tank. Then meteors. Then polish. We’ll see how it goes.

[ruby0x1]

This is looking good and coming along!

I think one of the interesting challenges will be dealing with visual noise/complexity of the background, if locating/tracking your plane is tricky after looking up ahead, it’ll add that cognitive load.

Since the game isn’t about enemies on the same depth level as you where the background is pulling focus from the foreground, in this game the background is the focus, so the connection between being able to quickly read the gameplay will be a thing. And like you say making it clear what’s targeted and when etc.

Also I like the automata for spreading fire. I dunno how challenging the game is meant to be but I can imagine things like variation in the spread timing. e.g you missed the heart of the fire cell, the wind from your water blast pushed the fire outwards 1-3 cells in all directions, speeding up the spread.

[whiletruefork]

The visual complexity is a concern for sure. I expect that at the very least I will slot some kind of faint wash layer between the plane and the terrain to better differentiate them (I may also add some lights on a layer specific to the plane?). It’s a game jam and I’m increasingly sicker so, you know… Expectations are an evolving situation.

[whiletruefork]

Progress So Far
Well, despite taking the day off of work it’s been slow, since I took the day off of work because I’m fairly sick. Still, I was able to eke out some productivity. @ruby0x1’s comment about visual noise and complexity stuck with me and I’ve recalibrated the aesthetic approach somewhat. Whereas my earlier inclination was to have the player interact with a hex grid directly, I think that the visuals do make it hard to parse. So I’m simplified the targeting system and upped the contrast across the board:

Nature’s hackiest effect darkens the area under where the plane flies to help it stand out from the background (it is a LineRenderer as wide as the screen that is black on one end and transparent on the other), and I’ve added a second directional light that only interacts with the plane’s layer to help it pop (and to up the juice of the periodic blooms of light against the plane’s wings).

The blue ring tracks the plane’s left-right movement, but independently glides up-and-down the screen (it takes about 2 seconds each trip)- this will be where your land-based water bombs land. Implementing the actual bomb interaction is now simplicity itself: I just add a trigger a bit wider than the ring (I’m going to use a sideways capsule collider actually- that way I can give it a little extra length on the up/down direction to provide some leeway on button timing) and when the visual effect lands it will just check for intersecting land tiles and tell them all to be not on fire. Then comes the points!

I expect this part will be done tonight, and that will leave the meteors and refueling mechanics.

Music
My brother in law is doing the music. He was a mainstay in the Cleveland Global Game Jam scene for years, writing original full length music tracks for 5 or 6 games every jam. They are collected on his bandcamp. Pay him to write music for you!

We’ve got a fairly deep collection of tracks that were written for projects that never saw the light of day so one of those may get a fresh coat of paint.

Sound Effects
Will be mouth noises. Sorry.

[whiletruefork]

"Simplicity itself," he says

…When literally describing trying to pre-script a flight path of a missile to hit a moving target. Anyway, suffice to say there were a lot of embarrassing sign errors and arithmetic mishaps.

At any rate, this part was far and above the second most complicated thing left. The only big thing left the map pre-compilation, which isn’t so difficult since I can basically phone it in if I need to, the meteor system, which is FAR simpler than this system since it’s a pure collision model and I don’t need to pre-script movement (I arguably didn’t need to here, either, so more fool me, right?), and then the water tank system which is mostly just extending existing function calls and tweaking mapgen.

[ruby0x1]

seems like it’s moving forward well! I think the bloom on the fire is a tiny bit overbearing but I’m sure after gameplay you’ll finalize all that. good stuff!

[whiletruefork]

I’m torn- it’s a lot, but it also sells the theme and there’s a lot of leniency baked into the water bomb targeting. My big note to self is next time I get sick at the start of a game jam, skip the game jam. But I’ve come too far now.

[ruby0x1]

Yea I could argue successfully clearing the screen would make for a satisfying contrast due to the lack of such loud red all over. So it might be fine (esp for a jam game).

I was also thinking you could drop the opacity of the black gradient line you added based on number of fires, so that when you’ve cleared up all on screen you get a clear/fresh view of the colorful trees, but when there’s lots of fires it’s less colorful. Since you aren’t stressing for seeing what’s going on bringing the bg into focus could feel rewarding.

[whiletruefork]

Submission Time

Ok a lot has changes since last I devlogged. In no particular order:

• Replaced a looping test cycle of 35 rows of terrain with a cellular automata populated map ~450 tiles long (if you last that long you get a kill screen, I guess, since I didn’t bother to put in any graceful handling of overrunning the terrain buffer)
• Replaced the Unity Random.value and Random.Range calls with a custom SplitMix64 approach was suggested in this Roguelike Celebration video from 2020 (I’ve been meaning to test that out for nearly 2 years). This is fun because it gives me fully deterministic randomization with a single entry point. I will probably take this approach going forward because it makes testing MUCH easier.
• Replaced almost all the original terrain graphics with handbuilt Blender stuff- the issue with the initial set was that each hex too squarely held exactly one tree or whatever, making the terrain very noisy-

Compare the old:

…with the new:

I’m very pleased with how these tiles worked out. This and the car game I’m working are really my first stabs at tiled terrain assets and the set I made here work really well, I think. There are only five tiles total- ground, ground with rocks, four trees, four taller trees, and one with just two trees. They are rotated a random multiple of 60° when they are placed.

• Added lakes -Apart from the obvious hexagonal geometry of the lake shores, I think the terrain manages to avoid “tile map syndrome” almost entirely.
• Added meteors that fly at you. Initially large meteors did and then they would calve into smaller meteors but I ended up keeping just the small ones.
• Added a water gun to shoot down meteors
• Added a mechanic where flying over lakes refills your water supply but not enough that you can get complacent.
• Added game over and scorekeeping mechanics
• Added a lobby with minimal instructions
• Added a few mouth based sound effects- enjoy the ludoacoustic dissonance!
• Dropped up/down movement because it was confusing people
• Submitted to the Itch game jam on budget and on time

So, overall this was a fairly solid, if overwrought, gamejam entry. I haven’t done a game jam proper since… maybe 2015, and this was a nice kick in the pants and reminder that I can actually make things.

If I were going to expand this (I may, but it would require a ground-up re-architecture pass) the big things I would add are:

• Score management beyond a one-time “this was the score you just got” screen
• “Standard” maps, at-will random maps, and a shared “daily” seed map
• Better sound effects
• People like meta-progression right?
• Different plane models might be interesting- like one with armor that could shrug off a meteor hit but only had half the water supply or was slower to dodge
• Actual support for resolution changes- I’m not used to Unity’s new UI model

You can grab a free copy of the game here. If you’re curious about any techniques in particular let me know. The source code is a dumpster fire so there’s not much to glean from most of it but the SplitMix implementation is maybe useful and I was pretty pleased with the cellular automata for making the landscape (it’s a fairly simple approach based on the number of tree tiles in the 3 tiles below a given tile- it encourages some winding paths but not consistent paths).

[ruby0x1]

I gave it a quick try and got a couple thousand score before a meteor took me down.

This looks great! seems like it came out really nicely considering the time and modifiers. Was fun to see the progress too here and on the discord, thanks for sharing.

If you generate a huge terrain upfront do you have any screenshots of the full length? would be fun to see the generation.

[BrodyBr]

Good work, dude! This looks incredible, especially for the quantity of assets you have in there!

[whiletruefork]

@ruby0x1: I could generate a screenshot- the algorithm does it blind by just assigning values to a dictionary of Vector3Ints using cubic coordinates, and then I only pull them out as needed (since I didn’t want to have to worry about the overhead of having 4500 instantiated prefabs with active logic on them- though in retrospect I guess I could have dynamically batched them then and saved some heartache).

@BrodyBr: thanks! Mostly basic blender stuff multiplied by basic Unity particle stuff. I might release the models as cc0 assets but I dunno that there’s much demand for hex tiles.