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 once made something with HaxeFlixel and Edge, which is a ECS engine: PongECS. In this, every entity has a FlxSprite as a component and newly added components. But it ended up a mess anyway.

    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, Entities would be mapped to a FlxSprite or FlxObject of their own. When a component data was changed, the new data would be copied to the FlxSprite mapped to its Entity.
    For example, we have an Entity with a Position component which stores 2 values x and y, if any of them is set to a new value, the position of the FlxSprite is 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.

  • 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:

  • @gcardozo that's an interesting link. The page right before that on FlxSprite answers my question:

    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 PositionComponent and the FlxSprite depending on if the user called move or 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.

Log in to reply

Looks like your connection to HaxeFlixel was lost, please wait while we try to reconnect.