HaxeFlixel Study – FlxTeroids, Part 5: Code Study (cont’d)


There isn’t as many interesting code to point out by now since we’ve covered most of them in the previous two posts. However, let’s take a look at something:

Note that FlxObject has variables such as elasticity that helps with the in-built physics. Do check the API for more info on what other variables or functions that you can use. 😀

Also note that while the asteroids bounce off each other quite convincingly, their rotation is not part of the physics. As such, there’s the piece of code above that handles the rotation whenever an asteroid collides with something.

This wraps up the FlxTeroids demo project study tutorial. I apologise if the contents of this series are not satisfactory — In upcoming tutorials I’ll cover parts of HaxeFlixel that isn’t already available elsewhere.

HaxeFlixel Study – FlxTeroids, Part 4: Code Study (cont’d)


Note the #if flash  conditional block. Remember that Haxe can build to several target platforms — and sometimes, some code may not work on a specific platform. This is where conditionals are used.

centerOffsets()  is a convenient function that helps you set your game object’s origin to the center when its width or height has changed.

angularVelocity  and acceleration  is part of FlxObject . One determines the rotation velocity, and another is the movement velocity. For most games which involve any sort of movement, you may end up using these two variables a lot. Check out the API for more info.

The code within the block above confused me at first — for example, where did angle  come from? Oh, that’s because we set angularVelocity  when we press the LEFT/RIGHT keys, and that affects the angle  variable.

What about acceleration.set();  ? What does it do? Quite honestly, I don’t know. Removing that line doesn’t affect anything. In fact, if you look at the top of the code, there’s a _thrust  variable that is never used. I guess the author made changes to the code a couple of times and forgot to remove redundant code.

When you press the UP key, the ship is supposed to accelerate. How does the code  FlxAngle.rotatePoint(90, 0, 0, 0, angle, acceleration); affect movement when the function is called “rotatePoint”? Well, that’s because, if you look at the API, we’re passing the acceleration  variable into the optional ?point:FlxPoint = null  parameter. The value 90  is supposed to be the ship acceleration speed.

So what’s actually happening in rotatePoint() ? Referring to the API, here’s what it does, in point form:

  1. The X  and  Y  values of (90, 0) is the default movement vector — in this case 90 in x-axis. The value 90 is the acceleration speed of the ship. Note that in Haxe, 0 degrees is right, -90 (or 270) is up, and +90 is down.
  2. The PivotX  and PivotY  values of (0, 0) are the rotation’s pivot points. In this case, it’s the center of the player’s ship.
  3. The Angle  value is the ship’s current angle.
  4. The ?point  value is the a FlxPoint (a container for X/Y values) to store the result rotation in.

Assuming the ship’s angle is -45 degrees (facing north-east), the function will take the default movement vector (90, 0) and rotate it around the pivot (0, 0) by -45 degrees, which results in the rotated X/Y vector. The result value is then conveniently assigned into the  acceleration  variable — which makes the ship move.


In the last part of the code, note the player’s bullet logic. Just like the asteroids, bullets are part of FlxTypedGroup and used like object pools. When the player presses SPACE (spacebar), a bullet is recycled for reuse, then fired in a velocity based on the player’s ship angle.

In the next part, we shall study the last source file, and wrap up this tutorial series.

HaxeFlixel Study – FlxTeroids, Part 3: Code Study

If you study the FlxTeroids demo project closely, you can learn a lot of things from it. But just in case you’re completely new and would like some interesting points highlighted, do read on.


Note that the t  variable is a reference rather than the value itself. As such you can reuse variables when adding objects of the same type into the stage.


Note how easy it is to create a simple star field in HaxeFlixel! 😀

The FlxTypedGroup  is similar to an Array, except its purpose can be similar to an Object Pool — you can use recycle()  to reuse inactive objects in the group. Check out the API for more info.

There are two ways to check for collisions in HaxeFlixel — overlap()  and collide() .

overlap()  will trigger when the two objects intersect, but you will have to handle collision the logic yourself.

collide()  will trigger when two objects intersect as well, but it includes physics; The collided objects will push away from each other automatically. You can use this for situations where you know two objects must not stay intersected with one another, such as platformers (between the player and floor).

Also note that even though the API accepts two arguments, you can just provide one instead, as shown in the code  FlxG.collide(asteroids); . This is because asteroids is a FlxTypedGroup , and collide()  will check for collision among all the objects within the group. Very convenient!

Also note that you can overlap or collide two FlxTypedGroups , and it’ll automatically trigger collision between objects from the two groups.

The screenWrap()  function is very convenient. Check the API for more info.

The FlxTween library is convenient for various animations. You might end up using it on many occasions 😀

The kill()  function is part of FlxBasic that can be conveniently used to disable a game object. You can later then use reset()  or revive()  to reenable the game object.

In the case of FlxTeroids — when asteroids are killed, you can instead use recycle()  to revive them. Note that we pass the Asteroid class as parameter into the recycle()  function. This is so that if there are no available inactive asteroids in the group, it will create and add a new asteroid into the group.

You may need FlxTimer  on several occasions, such as “spawn enemy every X seconds”, so take note of its existence 🙂 Check out the API for more info.

We shall continue studying the code in the next post.

HaxeFlixel Study – FlxTeroids, Part 2: Design

Let’s take a look at the FlxTeroid project that was generated.

In the assets  folder, there are only 4 images. In case you’re wondering why you can’t see the images from your preview, it’s because the images are white lines on trasparent background.

Looking at the source  folder, we can see 5 files — you can take a look into each file and examine what they do, but here’s a summary of each file:

  • Main.hx — the entry code for the game.
  • MenuState.hx — the menu screen.
  • PlayState.hx — the game screen — handles all game logic such as score, bullet/asteroid/player collision, and asteroid spawning.
  • Asteroid.hx — handles create (large/medium/small size), destroy and movement logic.
  • PlayerShip.hx — handles movement and shooting logic.

Notice that there is no class for the player’s bullets. That’s because bullets in FlxTeroids move at a constant speed and wrap around the screen UNTIL it hits an asteroid — which causes it to die. There is nothing special about it.

So when would we need a Bullet.hx file? — An example would be: when the bullet has attributes (e.g. “strength” or “bullet type”); or unique functions (e.g. “split bullet into 5 smaller bullets upon death”).

Okay, now what defines the whole game? Let’s lay down the rules:

  1. Player always begin in the middle of the screen
  2. Begin the game with 3 large asteroids at random positions, and zero score.
  3. Every 5 seconds, spawn a new large asteroid at random position.
  4. If bullet hits an asteroid, destroy it and spawn smaller asteroids.
  5. If the hit asteroid is smallest, don’t spawn any new asteroids.
  6. For every hit asteroid, award player with points.
  7. If anything moves out of the screen, wrap it.
  8. If player hits an asteroid, kill player.
  9. Player input — LEFT/RIGHT to rotate, UP to move forward/accelerate, SPACEBAR to shoot bullets.
  10. If player releases the UP button, his ship maintain its velocity in the current direction. Remember, the ship is in outer space — there is no deceleration.

For a simple game like FlxTeroids, there are quite a number of rules already, compared to our previous Pong clone. Imagine how many more rules a polished game would have!

In our next post, we’ll dive into the source code and pick out interesting bits as learning material, and conclude this tutorial series.

HaxeFlixel Study – FlxTeroids, Part 1: Project Setup

Today, we’ll learn how to dissect a HaxeFlixel demo project’s code, so we can learn how things are done. This way, you can go off to learn from all the available demo projects if you ever feel the tutorials are insufficient.

The project we’ll be taking a look at today is FlxTeroids, a HaxeFlixel demo project, which qualifies as a solid MVP example.

So where is the sample project code? You don’t need to use Git or go to the Github page — Your default HaxeFlixel command already has them all! Just type this in your console:

And you’ll see a whole list of sample projects that you can create. As of writing, the FlxTeroids project is [3], so just type 3 and press Enter and your sample project will be created.

Just to see if it works — cd  into your folder and test it with lime test neko . You should be able to build the game:

flxteroid-ss1 flxteroid-ss2

In the next post, we shall take a look into the code, and identify the design for the game.