Flixel is an open source game-making library that is completely free for personal or commercial use. Written entirely in Actionscript 3, and designed to be used with free development tools, Flixel is easy to learn, extend and customize.


Flixel includes some basic features common to
many game engines or other game libraries.
  • Display thousands of moving objects
  • Basic collisions between objects
  • Group objects together for simplicity
  • Easily generate and emit particles
  • Create game levels using tilemaps
  • Text display, save games, scrolling
  • Mouse & keyboard input
  • Math & color utilities
 Flixel also includes some new “advanced” features, which we’ll explore in more detail on the features page.
  • Record and play back replays
  • Powerful interactive debugger
  • Camera system for split screen
  • Pathfinding and following
  • Easy object recycling


One of the new features in Flixel is the introduction of a flexible and powerful camera class called (unsurprisingly) FlxCamera. By default, a new Flixel game project starts with one camera that is the same size as the Flash Player window, which can be referenced at FlxG.camera. You can replace that camera or add additional cameras to create effects like “split screen” views, or “picture in picture” style displays, or even mini-maps. Each camera is an independent display object, with its own zoom, color tint, rotation, and scaling values. Finally, each game object maintains its own camera list, so you can easily instruct certain objects to only display on certain cameras. Adventurous game makers can also check out the more complex Mode source code for more ways to use cameras in-game.


Pathfinding just means figuring out how to (or if you can) get from A to B. FlxTilemap has a new function FlxTilemap.findPath() which returns a FlxPath object, which is just a collection of “nodes”, or FlxPoint objects. Think of it as a list of (X,Y) coordinates in space, going from the starting location to the ending location. Once you have a valid path, you can pass that data to any FlxObject using FlxObject.followPath(). That function tells the object to start following the path, and you can specify the speed, direction (backward, yoyo, etc), and even tell the object to only follow the path horizontally (handy for objects with gravity applied). These flags mean that you can use paths for more than just character AI – they’re also useful for elevators, moving platforms, and looping background animations.


Replays are a powerful new feature in Flixel. Replays are essentially a list of what keyboard keys were pressed, and what mouse inputs were given, during a specific time frame. Because Flixel is largely deterministic, we can use that information to recreate a gameplay session that someone else recorded, as long as we have the same SWF. Replays can be used for debugging, arcade-style “attract modes” or in-game demos, and even for cutscenes. Replays can be manipulated using the “VCR” panel on the debugger overlay, or directly through functions like FlxG.loadReplay(), FlxG.recordReplay(), and FlxG.reloadReplay(). Adventurous game makers can also check out the more complex Mode source code to see an example of loading a replay from a file to create an “attract mode”.

Groups & Collisions

Game objects in Flixel are can be stored in FlxGroup objects. Groups can be added to the game state to help automate and organize updating, drawing, collisions, camera control, scroll amounts, and more. When you want to avoid calling resource-intensive functions like FlxG.collide() more than a few times in each game loop, you can use nested groups as a way to simplify those calls. For example, let’s say your game objects are divided into three different groups: Apples, Pears, and Bananas. And you want to see if the fruit have landed on the ground yet. You might be tempted to call FlxG.collide() three times: FlxG.collide(Apples, ground); FlxG.collide(Pears,ground); and so on. However, you can create a fourth group, called simply Fruit, and add each of the other groups to it. Then you can just call FlxG.collide(Fruit, ground); and you should see your performance improve notably.

Tilemaps & Auto-Tiling

Flixel’s FlxTilemap class was inspired by old video games, in which the environment was constructed using a grid of square “tiles”. Each grid cell gets a number, or index, which refers to a particular square graphic. That tile graphic is then placed at the appropriate grid number. Tilemaps have many advantages: it is easy to figure out what tiles should be drawn on screen, what tiles an object overlaps, and what special properties each tile might have. Flixel also includes some built-in algorithms for automatically placing wall tiles and floor tiles based on a simple binary (1s and 0s) array of tile data. It is a simple system with a lot of flexibility, which makes it perfect for rapid prototyping.


In games, “particles” and “particle emitters” refer to a whole class of behaviors that are usually used for special effects and flavor. The “emitter” is the source and manager of the actual “particle” objects that are spewed out and/or floating around. FlxParticle is just an extension of FlxSprite, and FlxEmitter is just an extension of FlxGroup, so a particle system in Flixel isn’t really that different from any normal group of sprites. It just adds some special behavior for creating and launching particles, and the particles themselves have some optional, special behavior to bounce more believably in platformer situations. FlxEmitter also has built-in variables that let you specify velocity ranges, rotation speeds, gravity, collision behaviors, and more.

Game Saves

Flash includes a simple way to save data locally, and the FlxSave object allows you to interface with it. This system is not ideal for all things; for example, if you are doing online high scores, this won’t really work. If you want players to be able to move and trade save game files, this isn’t a good fit either. However, for fast and simple saving of local data, especially things like unlocked progress or user preferences, FlxSave is an easy and built-in option.


Adam started working on Flixel in March of 2008, and released the first public version in June 2009. Probably the most commonly asked question about Flixel is “where did it come from?” so we’ve included a short explanation here.“I tried a few different times to make a little game engine type thing that would allow me to make retro games. That just seemed like a fun thing to be able to do for fun on a weekend. I tried it in C++/Python/OpenGL right when I left school, maybe 7 years ago? Anyways, it was a failure. Once ActionScript 3 came out, I was able to do some of the pixel-level stuff that I was really interested in. However, by the time I got my hands on AS3, I was more interested in just making little games, and seeing what patterns evolved. I kept making more complex games by reusing the code from the last project, and eventually those parts that I was seeing in every project got moved to their own folder. I think a lot of coders out there have a folder like this on their hard drive somewhere.”

One Response

  1. ungwhzskyz March 9, 2021

Add Comment