Asteroid.hx

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.

PlayerShip.hx

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.

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.

MenuState.hx

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.

PlayState.hx

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.