The first implementation of the new plugin system has just landed in the dev branch of Flixel Community. Since it represents a big improvement and a lot of opportunities for future developers, I thought it would be a good idea to explain how the new system works.

The old plugin system was created to enhance Flixel’s features without the need of deeply changing the engine core code. An example is the FlxTimer plugin, created to help with timers and delayed function calls. The plugin API was very limited, forcing developers to tinker with Flixel code to achieve a more complex functionality. A plugin could use all data available in Flixel, but there was no easy way to know what was going on, e.g. be informed that the current game state was about to change.

That’s where the new plugin architecture comes in. The idea was simple: Flixel will dispatch messages related to important events, which can be anything from a state switch to a frame update. The approach we have chosen to implement this was signals. It’s easier to handle than events and it is lighter on the performance too. Here’s an example:

class Test extends FlxState {
  override public function create():void {
    // Subscribe to the preUpdate signal.
    FlxG.signals.preUpdate.add(myCallback);
  }

  public function myCallback():void {
    FlxG.log("Flixel is about to update the game state.");
  }
}

Developers can subscribe to signals using the FlxG.signals entry. In the example above, a class subscribes to the preUpdate signal, which will be dispatched by Flixel before every game update. The signals approach plays an important part in the new plugin system, because they abstract the engine code. A plugin developer doesn’t need to change any Flixel code anymore to be notified about something.

There are a few signals implemented already, but more will eventually be created as the need becomes more clear. Under the hood, it’s extremely easy to create and dispatch more signals. All we have to do is add an entry to FlxG.signals and, at the right place in Flixel code, dispatch the signal:

public function someFlixelMethod():void {
    // ...
    // Somewhere in the Flixel code, dispatch the signal
    FlxG.signals.preUpdate.dispatch();
    // ...
}

Flixel shipped with two built-in plugins, FlxTimer and DebugPathDisplay, which were based on the old system (with a few hacks in the Flixel core). Those plugins were already ported to the new architecture, which means they can be added or removed during runtime now :). While porting those two plugins, I decided to do the same with FlxReplay. As illustrated by the GIF below, this feature allows players to record a game session for later viewing:

The code related to FlxReplay was deeply integrated in the Flixel core, but after some days of hard work, it was completely decoupled and moved to a plugin. Yay!

Some of the tasks on our TODO-list include the use of the new plugin system to implement more features that would not be part of a vanilla Flixel, but now they can be activated on demand by developers. That’s a huge gain for modularity and will help us keep things simple when adding more complex features.

Stay tuned for upcoming  features in the next release of Flixel Community!