SakeTami
castpixel
castpixel

patreon


How to make a bullet-hell SHMUP in 3 days

This is a post-mortem and game design analysis of my Ludum Dare game “FuseCell” made in 3 days with a competition theme of “Running out of Power”

Getting Inspired

As soon as the theme “Running out of Power” was announced, I knew I wanted the experience my players get to not be one of limitations. Running out of power can be interpreted to mean a timer, a finite time window for the player to do something and then the game ends abruptly (figure 1, left). 

That didn't appeal to me at all, so I immediately felt I needed to give players the ability to re-supply on power so that the game doesn't stop. I also thought passively bleeding energy is one less degree of freedom, so why not give the player control over when they want to spend her energy (figure 1, right). That was the basic shape of interaction I wanted for my main mechanic.

 Figure 1


The thought of a recharge mechanic reminded me of Ikaruga with its rule of absorbing same-color bullets to fill up the special gauge. I decided a recharge mechanic would be a kick-ass power to have in a shmup. Bullet hell shmups are always letting players use powerful experimental weapons, plus working within an established genre cuts down on design times, which is ideal for a jam. So, taking the theme and running with it, I determined shooting could be my energy discharge mechanic, and absorbing energy from enemy ships could be my recharge mechanic.


Ikaruga

Crafting the main game mechanic

Veteran game designer and absolute sweetie Dene Carter https://twitter.com/Fluttermind and the book “Clockwork Game Design” he recommended, have tried hard to impress upon me that fun game design is about:

  1. One main mechanic per game (or one per task, for more complex games), which all other mechanics should both reinforce *and* not contradict
  2. A choice, at any given time, between an easy, low-risk action, and a risky but high reward action.
  3. Asking what you want the player to feel, and tailoring the rules of the game to create that feeling and experience in the player.

My primary game mechanic was established : I wanted the player to feel very limited by her energy supply (figure 2), but also badass because of her ability to recharge.

Figure 2: shooting expends your energy bar

To reinforce the risk of the primary mechanic, I thought I should add a radius to the recharge ability. The direct consequence is that if the player decides to recharge, she will have to get up close to the enemy and suffer the consequences (which were not yet determined).

At this point (end of day 1, I think, and still working with abstract graphics) I had made the player’s ship (the black square) extend up to 4 energy tendrils when an enemy (circle) is near. The tendrils follow the enemies until they’re out of the sphere of influence (the semi-transparent circle). This is indication that the player can absorb those 4 enemies as long as they’re connected via energy tendril to the ship (figure 3)


Figure 3 Refining the behavior of the energy tendrils

At that point I hadn’t coded any collision with the player, no way for the player to be damaged, no consequences to using the absorb ability. To further drive the point of risk/reward home, and inspired by my favorite and excellent horizontal shmup ProGear, I decided to implement two things

  1. Single-hit death from bullets (pretty much a standard for shmups)
  2. Single-hit death from impact with airborne enemies

Therefore enemy types became


Here is the thinking behind this design decision:

Land-based enemies don’t kill you on impact, but also can’t be absorbed to replenish your energy. This means the only way to kill them is by shooting at them, which is the action that depletes your energy. The pieces of the puzzle were starting to fall into place. You’re motivated to kill the tanks because of the deadly bullet spray they unleash otherwise. But in order to kill them, you need to master the absorb ability.

Airborne enemies are the ones you need to absorb energy from. However that poses a risk because you have to go near them. Even those that don’t shoot at you can kill you on impact, so you need to choose your timing and position (more decision-making can mean more involved and more fun gameplay). You can always kill them by shooting at them, but then you’re expending energy *and* wasting your recharge sources. 

Next I decided that a nice visual way to display the absorb ability is to tractor-beam the enemies toward the player’s ship (figure 4). With a “glomp” sound effect. I know, super silly. It’s the reason why I like cartoony art direction: it lets you get away with more experimentation.

Figure 4: Glomp!

Refining the main game mechanic

Next up: the recharge mechanic was working fine, however it felt a bit overpowered. There were no consequences in using it. I wanted to give it something extra to keep it grounded in reality, so to speak. Up to now it was mainly the game design informing the theme. Now it was time for the theme to inform game design: What would be the limits of a super powerful experimental energy-leeching aircraft? How about overloading? Yes, if I could make the absorb mechanic into an “active gun-reloading” minigame that would totally do! 

Figure 5: the charge bar!

So enter the charge bar and the rules I made up for this minigame (figure 5):

Whenever one or more airborne enemies are in range, pressing Action Button 2 makes a charge bar appear. The longer you press, the more the bar fills up. Whenever you release, you get three outcomes depending on its length:

 


On top of that, again guided by the shmup genre, I thought I’d implement a super-bomb. Building on the existing mechanic, I guesstimated that a successful MAX recharge twice in a row - which means the player has mastered the absorb ability- would feel good and further the risk/reward. Remember, you have two chances to mess it up. If you successfully make a bomb, this fireball appears, clearing all the bullets on screen and dealing constant damage to all the enemies it touches for 2 seconds (figure 6) When the fireball is done, you’re left with half your energy (50/100) so that you can’t repeat the super-bomb immediately without recharging first.

Figure 6: yes, I wasted an hour making this 3-frame fireball. It still didn’t look destructive enough, but it gives you the general idea

AI

Enemy patterns in bullet hell shmups are an integral part of level design. Up to this point, I had managed to pixel some rough enemies, give them a tiny bit of animation and personality, and had placed them in the level like so:


This is one of the things the Construct 2 editor does brilliantly. I gave the level a passive scroll speed, so it auto-scrolls to the left, and every enemy that enters the screen becomes “Activated”. From then on, it’s about simple trigonometry:

The frog enemies just do a sine up-and-down wave movement. No shooting.

The flying cannons start moving horizontally but every second their angle of motion increases by 8 degrees, which means they eventually leave the screen while moving diagonally and to the left, in a nice arc. They shoot one bullet in the direction of the player every now and then.

I thought, for variety, I’d make some of the flying cannons red, and give them a much more circular path to follow (i.e. an 8 degree increase in their movement angle every 0.1 seconds). I also made them faster. The end result is they appear to aggressively sweep the screen, shoot three bullets, and then retreat.

The tanks are static, moving with the level, but produce a circular bullet barrage (using a loop that runs 36 times, increasing the angle of each bullet by 10 for each loopindex) 


I thought enemy hot air balloons would be a nice touch. I made them big and impressive, but their hitbox is limited to only the cannon they carry. Their behavior is straightforward: they go up and fire a three-way shot, regardless of the player’s position. To illustrate this, I used a quick and dirty trick, and just added a second frame with a target on it to the sprite animation. Looks pro, doesn't it.


BOSS


Again, silliness. I made the rook body invulnerable. You need to shoot its head. I thought the boss could spawn smaller airborne enemies to both kill you and provide a source of energy for your ship, but then I thought I could do one better: I made the Rook shoot huge, slow cannonballs that can kill you and that you can either shoot at or absorb. Problem solved.

After you’ve depleted the head’s hefty HP count, you get to the second boss form, a silly tank turret that shoots the same circular barrage as the ground tanks. Once you’re done, there’s a semi-satisfying explosion and you’ve won the game.

Art

I focused on making enemy and friendly fire super visible (fuchsia and yellow respectively) and it seems to have worked well.

The few concessions I made to graphics were that I took the time to make:

1. a passable 10-frame explosion. Explosions are super important in shmups.

2. A passable stage background

3. A passable lightning effect animation plus a square wave driving its opacity from 50% to 100% every few milliseconds, so it would flash slightly. 


Scoring System:

In support of the main mechanic, I wanted a scoring system that provides for individual players to show some self-expression. Therefore I implemented some hard and fast rules:

These rules might need some tweaking. And probably adding a few zeroes at the end ^-^

Music

I composed in FL studio. I wanted something uplifting and heroic, but not grimdark. Airship themes, marching bands and disco string sections all sort of mashed-up in my head while I lay it out in a hurry. EMU’s old +Symphony.sf2 soundfont is fun for prototyping large ensembles (download it and see).

Sfx

BFXR is an amazing piece of software, due to its presets and customization. But it’s also a fantastic exploration space: if you know how to edit your results a little bit, pressing the “randomize” button a bunch of times can really yield sfx you didn’t even know you needed. It’s like sailing a sea of possibilities and encountering new treasures.

A trick I learnt from Klik and Play (currently Multimedia Fusion) back in the day is: whenever I have a lot of similar sounds going off concurrently, I silence them all before starting a new one.
I.e. whenever I sound an explosion, I completely cut off any other explosion sounds (stop all sounds with a tag “explosion”) and then play “explosion.wav” with a tag “explosion” (that’s the way Construct 2 handles sound events)

.

Couldn’t implement

  1. AZERTY-friendly controls. I know, my friends who use AZERTY keyboards always get the short end of the stick, because I never plan ahead
  2. Two player support - during the Jam I fired up MAME and played Detana Twinbee (for research and to unwind). I remembered how awesome the two-player co-op mechanic is in this game. If the two players can manage to position their ships properly, their combined weapon is a lot stronger than the sum of their individual weapons. Sadly I had no time to even think about adding controls for a second player, and my code was spaghetti at this point ^-^’


3. Saving the high-score so you’ll be tempted to try again

4. Advanced bullet patterns. I.e. bullets that slow down, speed up, change course after being fired, etc. 

5. A second level. I was completely exhausted and also finished in the nick of time, so one level would have to suffice as a proof-of-concept at least.

As always, don't hesitate to ask me anything. 


Play the game here

Thank you for reading <3

How to make a bullet-hell SHMUP in 3 days

Comments

This was fascinating and inspiring in equal measure, I loved reading it - thanks for taking the time to type all of that up!

Yann Best

Great stuff!! Thanks for the analysis and design process! ^^


More Creators