The “using” mixin in Haxe is one of those rare features that add usability without sacrificing flexibility. Combined with the component-based architecture of the Pushbutton Engine/Hydrax, you can write code for the Hydrax game engine that is short, readable, powerful, and extremely flexible and customizable.
In a nutshell, you use “using” to inject methods to an IEntity object that allow behavior to be dynamically added, with the option of chaining the methods. The statically injected methods add components to the entity where needed.
Read here to learn about Pushbutton Engine components.
Let’s dive in with an example, and explain as we go along.
Building a button
Assume you are in the setup() method of an IPBContext instance. You’ll need to import (using import) the following:
You’ll need a SceneLayer to add the button to:
var scene = addSingletonComponent(SceneUtil.MANAGER_CLASS);
scene.sceneAlignment = SceneAlignment.TOP_LEFT;
var layer :BaseSceneLayer<Dynamic, Dynamic> = scene.addLayer();
Then create the button like so:
var button = createBaseSceneEntity()
.addSvg(layer, Resources.list.TITLEBAR, [new SvgReplace("$T", "The Title")])
Let’s go through it. Firstly, all of the above chained methods are static methods defined in one of the using classes. Except for the first call that creates the IEntity object and the initializeEntity call, all the calls follow a similar pattern:
- Check if the component needed for the required functionality is present.
- If the component is missing, add it.
- Add the functionality, data, behavior, or whatever.
A (hopefully) clear example is the makeReactiveButton call:
public static function makeReactiveButton (e :IEntity) :IEntity
var mouse = e.getComponent(MouseInputComponent);
Given an IEntity, it ensures that a MouseInputComponent is present, then adds the signal listeners that make the component respond visually to mouse/touch clicks.
The great thing about this is that you only have to import the using class. The methods therein ensure that the appropriate components are added or set up correctly. The IEntity/Component architecture of PBE/Hydrax allows you to add (or even remove) behavior at run time, without having to resort to building complicated and unwieldily class hierarchies.
This makes it very easy to swap out components for your own, or add any kind of behavior to your game objects in a clear and readable way.
Also, now your code libraries for building objects consist of mostly static calls. This helps to prevent unnecessary dependencies and generally minimizes bugs as the methods are not tracking any state information.
I hope this post was somewhat informative and readable. Criticism and feedback welcome!
This post will be linked shortly to a concrete demo with source.