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.

One thought on “HaxeFlixel Study – FlxTeroids, Part 2: Design

Leave a Reply

Your email address will not be published. Required fields are marked *