Haxeflixel use case; ECS?
I tried (twice) making an entity-component system with HaxeFlixel; it always seems like I'm fighting the architecture -- FlxObject, FlxSprite, etc. just have loads of properties (position, velocity, image, etc.) and are "supposed" to be used as the building-blocks of monolithic classes?
I don't know if I'm getting it. Can someone provide a non-trivial (like non-demo) version of a game that shows how HaxeFlixel is supposed to be used, and/or architected?
I came up with this idea of a ECS engine built on HaxeFlixel, which means HF would run as an underlying system for rendering, updating and other processes.
Inside the engine,
Entitieswould be mapped to a
FlxObjectof their own. When a component data was changed, the new data would be copied to the
FlxSpritemapped to its
For example, we have an
Positioncomponent which stores 2 values
y, if any of them is set to a new value, the position of the
FlxSpriteis also changed. Same thing for othe concepts.
All of this happens under the hood so the users virtually don't know of the HaxeFlixel API at all but indirectly through the API of this ECS engine.
Agustín Pérez Fernández
Phaser is like flixel and it is evolving like a ECS:
Flixel still works better on native devices but Phaser is only for html5.
Bleeblerox said that he wants to do it more component based when he did the notes for the fund raiser: https://github.com/HaxeFlixel/fundraiser/blob/master/beeblerox_notes.md
I think it is a big change that will forever change flixel.
As you can see on this issue, HaxeFlixel is made based on inheritance:
That said, I've recently started a lib for entity-component system, but you still gonna need to define your own components:
How HaxeFlixel is supposed to be used/architected?
You can separate your game in states (title screen, level0, level1, score screen, etc) and work from there, the handbook can help you:
It is pretty common place to extend FlxSprite for your own game's needs; for example a SpaceShip class may extend FlxSprite but could have additional variables for the game like shieldStrength or shieldPower.
Therefore, the main use-case of HaxeFlixel is inheritence-based, using the
Flx*primitives as building-blocks.
For the record, I also created an ECS (actually, three) using HaxeFlixel. Ultimately, I moved away from this approach, because of a) duplication of fields across components (eg. synching the coordinates two-ways between a
FlxSpritedepending on if the user called
moveor if I'm using
FlxSprite.velocity), and b) collision detection just didn't work reliably for some reason.
After moving away from using an ECS, I write less code and go faster, so I'm happy.