Previously:

• Making a game with Flash Develop + Flixel: Part 1, Installing and Configuring
• Making a game with Flash Develop + Flixel: Part 2, Coding a simple example
• Making a game with Flash Develop + Flixel: Part 3, Input and Objects
• Making a game with Flash Develop + Flixel: Part 4, Tilemaps and Collisions
• Making a game with Flash Develop + Flixel: Part 5, Objects and Animation
• Making a game with Flash Develop + Flixel: Part 6, Cameras and Text
• Making a game with Flash Develop + Flixel: Part 7, Adding NPCs

(Want to bypass the long explanations and see the final product? Here, download this post’s code as a ZIP file.)

So far in this guide, I have written about extending many of the Flixel classes like FlxSprite, FlxTilemap and even FlxGroup. However, returning to the core trinity of Flixel objects (Preloader, Game and State), we can add more States to a game. While it needs at least one to function, Flixel has the ability to switch between them easily.

We can also start to think about States as being fundamental changes to mechanics within a game. Navigating a menu isn’t the same as moving a sprite around the screen. A character or statistics page is different too. All of these could be different states for a game to manage.

In fact, to add a simple menu to our game, we would create a new class, extend FlxState, override its update, and then wait for some input before finally switching over to the PlayState.

To have something to show to the player, we can create a simple image that has the title and some instructions like “Press Enter” or “Click to start.”

After saving that image as a part of our project, we can embed it in the MenuState as the background for the state.

We also now need to change line 17 in the ExampleRPG object.

Instead of starting with PlayState, it should launch MenuState instead.

Note on line 29 of MenuState I’m using FlxG.fade. It’s one of several visual effect functions built into Flixel. By calling it, I tell Flixel to fade the entire viewing area for one second by filling the screen slowly with the selected color and then call a function when done. In this case, I used the color black (0xff000000) to fill the screen as a transition before moving to the PlayState.

By using effects like this, we can prevent a jarring visual switch of moving from one state to another. It also works well for moving between areas too.

In fact, we can use this as the visual transition for moving between map areas too. However, before that can happen, MapTilemap will need to change. And we will need more tiles too.

Along with our new tiles, we also need more tilemap data too.

For “house1.txt” we have:

5,9,9,9,9,9,9,9,9,4,
3,1,1,1,1,1,1,1,1,2,
3,1,1,1,1,1,1,1,1,2,
3,1,1,1,1,1,1,1,1,2,
3,1,1,1,1,1,1,1,1,2,
3,1,1,1,1,1,1,1,1,2,
3,1,1,1,1,1,1,1,1,2,
3,1,1,1,1,1,1,1,1,2,
3,1,1,1,1,1,1,1,1,2,
6,8,8,8,8,8,10,8,8,7

Now, we need to change MapTilemap into MapGroup.

Instead of being a single Tilemap, it will manage the different maps, switching from one to another when needed. All of the tilemap data (currently) will be embedded with MapGroup with different tilemap per set of data.

Using the setTileProperties function of Tilemap objects allows us to set up specific triggers and allow certain types of collisions. That way, all other tiles will collide with the player sprite but for the one value we pick (12 for the map and 10 for the house), a callback function will be called.

These callback functions have a specific ordering to their arguments too. The tile with the value is the first and the FlxObject (PlayerSprite is a FlxSprite which is a FlxObject) is the second.

In these two cases, we are ignoring them and using the MapGroup to add and remove each tilemap, moving the player as necessary.

As a final fix, we need to update PlayState to use MapGroup instead of MapTilemap:

And thus, we move from the map to a room.

In Part 9, we organize the code into more modules by placing NPCs with objects representing maps, associating characters with places.