A Flixel Guided Tour


For the sake of simplicity, this tutorial will use the Flixel library only. If upon completing (or failing to complete) the tutorial you feel like Flixel just isn't for you, I heartily encourage you to try FlashPunk. Even though there is no tutorial for FlashPunk in this issue, there are a lot of great online resources for it. However, a lot of new designers have had good luck with Flixel, so we're going to put together a short tour or explanation of how a Flixel game is put together so things aren't too overwhelming when we get to the nuts & bolts of the tutorial later. Games have a lot of different stuff in them, but we're going to take this first game pretty slow. Flixel is an "object-oriented" library or API, which means it is a collection of source code files, and each file represents a different kind of basic game element, including characters (or "sprites"), sound effects, and a helper or "container" for the game itself. Let's start with that one! The FlxGame Object: FlxGame is a special object that is only created once, and you only really use it right at the start of the game, to set up some important basic properties. Other than that, it just acts like a container and manager all in one. FlxGame is in charge of keeping track of your game objects and making sure they get updated and drawn, so it does most of its work behind the scenes. The FlxState Object: To help keep things organized, Flixel uses a simple "state engine". What this means is different parts of your game that have different behavior can be written or scripted in different files. For example, most Flixel games have a "menu" state, and a "play" state, so you don't have to muck up your gameplay code with menu display or list controls. All your real game design work and game objects will be done as part of a "state", not part of FlxGame. The FlxSprite Object: A FlxSprite, or "sprite", is a graphical representation of a game object. It might be the player's avatar, or a collectible powerup, or a giant boss vehicle, or some atmospheric particle effects. By adding sprites to the game's state, you can change their position and draw them to the screen and make a game. The only visual objects that aren't sprites in Flixel are big level-objects, like: The FlxTilemap Object: Since levels are so big, it can be helpful to have a special object to store them and draw them more efficiently. FlxTilemap takes a array of numbers, and uses those numbers to draw tiles (little squares of level graphics) to the screen, like Super Mario Bros. or Legend of Zelda. It can also use those numbers to determine what objects you can run into, or collide with, and which tiles should be treated as non-existent. Just like a FlxSprite, FlxTilemaps are first created and then added to the game state. FlxG And FlxU: These oddly named objects, or classes, are short for "Global" functions, and "Utility" functions respectively. They contain a bunch of helpful things that we use a lot in game development, like checking for keyboard presses, or bumping objects into each other. That's all we're going to use to make our Mario-esque platforming game. To recap, our ingredients include a game object, which contains a state object, which in turn contains sprites and a tilemap. If the game was a Russian nesting doll, FlxGame would be the biggest doll, FlxState would be the medium doll inside, and inside FlxState there would be a whole pile of tiny dolls. So let's make our biggest doll first!

Tour 1

bla bla bla