Flash Game Dev Tip #8 – Building a Shoot-em-up Part 3 – Return Fire

Tip #8 – Flixel – Building a Shoot-em-up, Part 3 – Return Fire

This tip follows-on from Tip #4, where we added enemies and explosions into our game. But it was a little one-sided. This time the enemy are going to shoot back. And you’ll feel it, by way of a health bar and set of lives in our new HUD. Finally we’ll drop in the scrolling tile-map background and simple menu / game-over states. By the end it will look like this:

Note: I’ve embedded the game at the bottom of the tip.

Return Fire

Last time we added the Enemy Manager, which spawned a regular supply of enemies at us. Each enemy had a launch function which set it moving. Let’s add the ability to fire to that:

This uses a new FlxMath function chanceRoll. The enemy has a 70% chance of firing at you. If this happens we create a new FlxDelay Timer of 1 second + up to an extra 0.5 second, and start it running.

Then in the Enemy update function we check that timer:

As you can see, this is calling the fire function in our Enemy Bullet Manager, passing in the x/y coordinates of the Enemy, which launches a bullet from the bullet pool:

FlxVelocity tells the bullet (this) to move towards the player at the value of speed (which in our case is 240 pixels per second).

Pixel Perfect Collision

If you are unlucky enough to be hit by our new enemy bullets then we need to damage your health.

Previously the game used native flixel collision, which is based on bounding-boxes (i.e. the rectangle that encloses your sprite). This isn’t desirable in a shoot-em-up. It meant the player could get shot without the enemy bullet even visually touching him. To address this we simply add one check into our bulletHitPlayer function:

The additional check is to run pixel perfect collision between the bullet and the player (I also added the same check between the player bullets and the enemies). Voila – now collision is accurate, and all deaths are your own fault :)

If they do get hit, we hurt the player with the value of damage. We also kill the bullet, set-off a small explosion and shake the screen (quake). Flixel will deduct damage from the player health, and if it drops to zero or below it calls kill:

Here we just reduce the lives counter by one, and reset health back to 100. This isn’t the best way to deal with this, ideally we would stop enemies from shooting for a short-while, and actually explode the players ship before bringing him back with a new life. We’ll add that in a future tutorial.

Displaying health in the new HUD

The player has health, and the means to lose it, but no visual display of that. So I created a new class called HUD.as (which stands for heads-up display) to hold the game panel at the top of the screen. It looks like this:

The class is mostly about creating assets:

The scrollFactor commands lock the panel in place, so it isn’t scrolled by the new backdrop (see below).

The score and lives counters are using FlxBitmapFont with a custom-drawn font set (digitsPNG).

Finally we created an FlxHealthBar which we’ve hooked to Registry.player. The FlxHealthBar is an easy way to visually display the health value of an FlxSprite. It’s tied to the Player, and as the health value is modified (when the bullets hit) the health bar automatically detects it and updates itself. FlxHealthBar can do quite a lot, and is part of the Flixel Power Tools which I urge you to check out.

Hello Dolly

So we’ve got enemies firing at you and a brand new HUD to display the damage. So let’s make the final big change for this version – adding in a scrolling background.

The background is a tilemap based on a 16×16 tile set:

I used the map editor DAME to draw the background. Basically because it’s the best map editor I’ve ever had the pleasure of using, and because it’s quick and easy to output from. Here’s a zoomed-out shot of our background, drawn using Tile Brushes in DAME:

I’ll cover using DAME in more depth in a separate future tip, but there are tutorials on the DAME site to get you started. It’s well worth spending some time learning, because it allows for incredibly rapid game development. Once the map is drawn and ready it’s then a case of loading the tilemap into our game, and scrolling it vertically. Here is the complete ScrollingBackground class:

The code above is creating 3 new objects:

  • A 2D starfield background (called stars)
  • Our Tile Map (called map)
  • An invisible sprite for the flixel camera to track/follow (called dolly)

In the update function all we do is move dolly slowly up on her Y coordinate. When she goes off the top of the map (+ an extra 240 pixels) we reset her back to the bottom again. This creates the effect of a continuously looping scrolling background.

I know that traditionally the backgrounds in shoot-em-ups don’t wrap, but at least we have this in place now. While what we have here now is really just eye-candy (i.e. you just fly over it all) that is soon to change :) as we can easily drop-in cool features such as gun emplacements, map scenery to avoid and spawn points for different types of enemies.

Game Over, Man!

So far, so good. But what happens when lives hits zero? A check in the PlayState update function simply swaps us to the new GameOver state, which right now looks something like this:

It’s not pretty, but it will do for now. And if you feel like extending this code further before the next tutorial, at least you have the classes in place now to do just that.

Play Time

Here is the game as it stands at the end of this tip. Have a play! Cursors / Arrows to move, CTRL to fire. The F1 to F3 cheats are still in, and you can press Q to quit at any point.


We’ve come a long way in one tip! Enemy fire, tilemaps, starfields. But we’ve really added very little code, yet got a lot for it. In the next instalment we’ll add some music and sound effects, and then look at making better use of our new tilemap.

Download the source code and SWF from the Flash Game Dev Tips Google Code Project page.

Posted on April 5th 2011 at 11:28 pm by .
View more posts in Flash Game Dev Tips. Follow responses via the RSS 2.0 feed.

19 Responses

Leave a comment
  • nic
    April 7th 2011 at 4:06 pm

    nice wonderful
    but i think test file is missing something!? debug come up with this error flxgame is not found

  • April 7th 2011 at 4:59 pm

    Nothing is missing, you just need to read the readme.txt file in the zip :) It says to get Flixel 2.43 and drop it into the src folder (along with the Flixel Power Tools) – both are on the google code project site.

  • April 16th 2011 at 7:32 am

    Great sample, great article! Do you plan to port it to the Flixel 2.5?

  • April 16th 2011 at 11:41 am

    Yes, once 2.5 settles down (it’s still in quite a state of flux) I’ll write a tutorial on how to port a 2.43 game to it :)

  • April 16th 2011 at 12:40 pm

    Great news! Btw, thank you for such useful and polished work! I plan to use it in my current project (Ninja vs Zombies flash game), so may I insert link to your site in the credits if you don’t mind?

  • April 16th 2011 at 12:45 pm

    Of course, feel free. But you’re under no obligation to do so, just happy you’re finding it useful.

  • bouma
    May 21st 2011 at 1:25 pm

    i m trying a lot of things, its impossible to make it work.
    what are the packages to put into the src ?
    i see some “import com.photonstorm.flixel.”
    the real place of photonstorm is in plugin…All the paths look wrong.

  • May 21st 2011 at 3:28 pm

    This tutorial is for flixel 2.43 and a quite old version of the flixel power tools. You can either wait until I port this tutorial to 2.5 or download the Tip 8 folder from Google Code and use the version of flixel and the tools you’ll find in there.

  • May 28th 2011 at 1:16 pm

    These tutorials are great, thanks!

    Something I’d like to see tackled in a tutorial, even if just in pseudo-code would be enemy movement patterns, so rather than having them just random spawn and wander down the screen, they would spawn in pre-determined locations off-screen and move in a particular way in small groups similar to most games in this genre. I don’t recall ever seeing a flash game with this included so maybe it’s really hard or something, but if you can give even a few hints on how to do this, I (and I imagine many others) would really appreciate it.

  • May 29th 2011 at 12:23 am

    God damn your graphics are hot.

  • Deathcraft
    October 23rd 2011 at 10:05 am

    Thank you very much for this tutorial! I think that i will be able to develop a clone of Tyrian now :) I want to ask – is this possible to use some parts of your code – i.e. the starfield – in my game?

  • October 23rd 2011 at 11:26 am

    You can use all of the code in your game, it’s completely free for personal or commercial use. You just can’t use the graphics (you can use them for a prototype, but not a released game)

  • Mick
    January 10th 2012 at 3:48 am

    In the pixel.as from this game you say “It could easily be a PNG instead”
    I’m new to flash and spent a couple of hours looking of how to do this? any chance you could point me to the right direction? or better yet show where I could see how to do this?
    what I’m trying to do is I have an image.png which is 288 by 32 it has 9 rectangles 32×32 (these rectangles have see through areas and basically are little images)

    how instead of your little bitmap pixel for the emitter would I get it to spawn the little images?

    any help would be much appreciated thank you!

  • David
    February 1st 2012 at 2:51 pm

    Hi Richard,

    thank you so much for making this tutorial! It’s absolutely amazing!

    I just have short question.

    How can i use FlxVelocity to shoot bullets at enemies? Since Registry.enemies is a FlxGroup and not a FlxSprite.

    Any hint is highly appreciated!

    Best regards


  • April 11th 2012 at 5:59 pm


    Great tips you got here. I used pieces of this tutorial on a game iv already been working on. The only issue I’m having is I can’t get one of my enemies to return fire. Not sure what the issue is.

    Thanks again for showing us this tutorial!

  • April 11th 2012 at 6:14 pm

    Maybe the enemy is firing but you just can’t see the bullets? Try hiding some traces in the “fire” functions to see :) and then next plot out the bullet x/y coordinates. It’s possible it might be off-camera. Glad you liked the tutorial though, thanks.

  • James
    August 14th 2013 at 12:24 am

    I know this is old now but I wondered if you could help with a question.
    I’m using my bullet manager in my Registry.as, and in my playstate I’m adding in the create function like so: add(Registry.bullets); This all works fine and my bullets fire and collide with walls etc

    however my problem comes when I reset my state using FlxG.resetState(); I get an error/crash because the bullet group is static. Is there a way round this still using your bullet manager code?

  • August 15th 2013 at 7:05 am

    Make sure you clear your bullet manager out as well when you swap states. Add a “reset” or similar function to it, that clears all the sprites down, stops them from updating, etc.

  • Mario
    September 19th 2013 at 5:54 pm

    In Flixel 2.5 we don’t have property scrollFactor for GlxGroup. How I can this replaced?

Make yourself heard