H.E.R.O: The Tutorial

Moving on to the second game tutorial based on old atari games. This one covers many important points in game development. H.E.R.O is my favorite Atari game, and it translated very well into Flash. It is a platform game, with a screen based game play (meaning the screens change as the sprite moves across the obstacles, refreshing itself instead of scrolling.) This screen mode simplifies some things and make others more complicated. I certainly prefer the scrolling type of game but I wanted to be as faithful to the original as I could.

As a platform game it doesn’t offer a lot of challenges. No slopes, for instance. But it allows me to explain one of the most important topics in game development: collision, and what are the best practices to handle it. The framework I used in this game is the one I use most often, with a very important triad of classes: GameSprite, ScreenManager and GameController. I’d say that in 99% of the games I build, particularly arcade games, but any game that has something moving dynamically, I will use these three classes combined to control that movement.

The Game

H.E.R.O which is written as an acronym for…. something I have no idea what, is about a little guy with a motorcycle helmet, and a propeller backpack; running and flying around carrying dynamite sticks. He needs to climb down these weird looking platforms, all the way down to the dungeons, in order to rescue someone, who I will call the hostage.

I wrote three levels for this game, meaning I entered XML data for three levels, but you could have as many as you would like.


Let’s start the tutorial going over the XML that is used to create the game screens. The root tag is “levels” and within that we have all the individual “level” tags which will wrap, well, guess what? Within each level tag comes a “screens” and inside that the “screen” as many of those as we have screens inside a level. So the basic structure looks like this:









The screen has attributes to store information about it. Whether or not it is lit, and what is its entry point and its exit point, since some screens might be exited/entered from the left, right, top or bottom. Anyway, all that information is stored in the screen tag like this:

Then the screen tags will contain two container tags, one called “blocks” and one called “extras”. The first will list the platforms (including walls) used in the screen, and the extras node will list the extra elements added to the screen, such as enemies, lamps, the hostage… Let me show you individually what they look like. First the platform:


The first thing I list is the type of platform. Block means the basic platform, Wall means this platform can be exploded. And Laser means it is a laser wall and if the player touches that, he is zapped dead! The positioning is handled a little differently in the Y part. Since the screens in this game are always divided into three horizontal sections, each 80 pixels tall, all I need in order to position the Y of the block is grab the ratio which I will use to multiply by 80 (blocks have the registration point on their Upper Left corner.) Then comes the tile property that tells how wide the block is. Again I will multiply the value listed here by 16 which is the base width of blocks in this game.

And this brings us to an important point: Atari games were all tiled, as far as I know. I could have done this game as a Tiled game, as I did Phantom Tank; tiles would certainly make the collision logic a lot simpler. But I wanted to show you the other way of building platform games, a more loose way if you will. For now, it wouldn’t hurt you to remember: Tiles equal grids and those equal better collision control. But when I teach you Phantom Tank you will see what I mean. So it’s not strange that there is so many left over logic here from a tiled system. It makes things easier.

The fill and the stroke attributes list the color hex values for the blocks. The sprites for the blocks are comprised of three parts. A top and bottom stroke block (I call them “bands” in the code) and a large block in between, which I call bg.

It would make a lot more sense, the way things are currently build in the game, to store the colors for each level in another XML or another XML container, that way you wouldn’t need to repeat these values. But I wanted to be able to have different colored blocks within the same screen, for a later version. But if you would like to make that change, go ahead. It could simplify the creation of a possible level builder application in Flash, one that would spit the XML for the levels.

Now let’s show the extras. They are:

These nodes list the class name linked to the extra, and their position. Notice here I skip the tile logic.

The only important thing to remember is that you MUST have a Hostage in the last screen, and ONLY there. Touching the hostage ends the level.

Of these extras, the only thing that can move is the one I called the Moth (which in retrospect is a horrible name.)

The Sprites

I always like to make them extend Sprite and never MovieClip if I can help. For no good reason, really. So the player sprite will have a movie clip inside of it with all the different animations for each state: Walking, Standing, Flying, Dying. This movie clip I call states.

Hostage too has a states movie clip inside it, which is referenced through code, but the other extras don’t need to have particular frames referenced, so even though they will also have a movie clip inside them with their individual animation cycles, these movie clips are never referenced through code.

Another important thing is registration points. It is never good to vary them, unless you have a good reason. However, this game contains many of different types of registration points, and the reason for it is the way the sprites must flip (when scaleX is inverted.) Depending on how they must flip, the X value of the registration point will vary.

Objects that collide with platforms are generally registered at Bottom Center because it simplifies the Math for bottom collision with platforms. Just be aware of what the math in the code is referencing. If you decide to change any of the registration points, be sure to change the math. Or even better, replace all the code with boundary logic.

The Framework

If you did the Tennis Tutorial, you will recognize a lot of the classes used here and the way they interact with each other. But here is a quick overview:

– Everything is added to stage and removed from stage through the GameStage class.

– A GameController class inits the game, inits a new level, ends a level, inits a new life, and does all actions pertaining to game over. So basically, GameController will control the states of the game, as well as contain the main loop that tells each element to move and go crazy.

– A GameData class stores all data about the game, number of lives remaining, the number for current level, total number of levels, number of bombs, the score, and the XML data that is used to build the levels.

– I like to store as many of the game’s constants in a separate class called GameConstants,

– and I store a reference to the main elements in the game inside a class object called StageElements and can retrieve the references from there.

So this is the basic framework and it makes a lot more sense when you review each part separately as we’ll do now.