Making a game with Flash Develop + Flixel: Part 6, Cameras and Text

Previously:

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

Before we can jump into code for this post, we need to cover what exactly a camera is. Instead of having viewports or even subsections of the screen, Flixel has FlxCameras. These cover different areas and can be set to follow the movements of sprites or other objects.

By default, Flixel creates one camera and centers it on the running state and its objects. Whatever dimensions were set in the FlxGame object, those are the same as the camera. Move outside those bounds and the sprite essentially disappears from view.

Changing the values for the default camera, then, allows us to move as a sprites is moving. Within a larger map, the camera will stay centered and the world will appear to scroll as a sprite moves within it.

However, before we change the values, we need to know two things:

  1. The total dimensions of the “world”
  2. Which object to follow

We also need to set all this up before a FlxState is running, otherwise it will use the default values by, well, default.

In order to do all that, we need know something important about Flixel (and ActionScript 3): create does the making, not a constructor. In other words, the very first thing called is a “create()”. To have anything set or run before a object officially starts, it needs to be within that function.

And, since a FlxState will already have a create function, we need to override it just like we have for update.

Now that we have the create function overridden, we can update the default camera by changing the world bounds to match the size of the map, setting the camera bounds to match that, instructing the camera to follow the player, and then updating the player object’s own list of cameras.

Compiling and running the game won’t show any real change.

step1

We are still moving around within the tilemap setup several parts ago with the same green character from the last part.

However, what we have changed, even if the game doesn’t show it yet, is the ability to have a very large world instead of the 340 x 240 established back in Part 2.

To do that, all we need to change is the “map1.txt” file. Because MapTilemap reads that and, in turn, the size of the game world is based on its dimensions, we can expand the world by editing only one file.

Before we do that, let’s expand out tile set and then add in our new tiles with the edit to “map1.txt”

(Note: I’m pulling from my previous guides on drawing ground, wall, building, doors, and plant tiles.)

step2
Click this image for the actual tilemap.

Using our new tiles, we can make a much larger map. (Download or copy-and-paste from this file.)

Which translates into a greater world to explore.

step3

(Note: We can’t actually use the door tiles as actual doors yet. Right now, they are merely part of the background.)

With our (brave) new world, we also want the ability to give visual feedback to the player in the form of text. These would be descriptions or even dialogue shown as the result of an interaction.

What we want then is FlxText. This will allow us to show text on the screen.

However, there is a problem. FlxText is designed to show text, nothing else. If we want a background and the text, and the ability to press a key to progress through messages, we need something more advanced.

For that, we can use an extended FlxGroup composed of two FxSprites and a FlxText: FlxDialog!

(Note: A FlxGroup is a collector object. It can hold any other FlxObjects, including other FlxGroups. It’s like an array or other data structure, but designed with extras like updating and drawing its members as well.)

And then, to use it, we update our PlayState with a simple interaction of pressing “Enter” and seeing a dialog box. (With pressing “Space” to dismiss it.)

However, if you now compile and run the code, you will notice something very funny. If we press “Enter” but don’t press “Space”, the dialog box will follow the character around. We need to make sure the character stops while messages are being shown.

For that, let’s add a public Boolean value within PlayerSprite.

And, of course, we then update out PlayState as well, adding in code to stop when starting a dialog box and un-stop the character after it has been completed.

Finally, we have the ability to generate and walk around in a large world. We also have the start of a dialog system where actions can generate visual feedback in the form of text.

In Part 7, we add NPCs, and begin to track what the player has interacted with in the game.