3
\$\begingroup\$

In this below example, I've combined libgdx ashley and AI state machine. Do you think it's a good idea to handle the logic in state machine or stick on handling the data logic on System?

public enum TrollState implements State<Entity> {
     MOVE_AWAY() {
         @Override
         public void enter(Entity entity) {

         }

         @Override
         public void update(Entity entity) {
              PositionComponent position = Mappers.position.get(entity);
              ...
         }

         @Override
         public void exit(Entity entity) {

        }

        @Override
        public boolean onMessage(Entity entity, Telegram telegram) {
             if (telegram.message == 0) {
                 Gdx.app.log("Slime", "Waaaah, goo away, big daddy! yummmmmmy");
                 return true;
            }
            return false;
        }
     }
}
\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

Unless there's a specific reason you'd need (want) to process the data in a State you should probably stick to Ashley's own EntitySystem. Without you yourself expanding the functionality of State, EntitySystems are for sure more flexible, as in you can tell it to not process the system, you can do something when it's added / removed etc.

Also the development team for Ashley probably optimized their framework as much as possible, meaning that even though it might be a small increase the EntitySystems are probably faster.

If you wish to use Ashley together with GdxAI's States perhaps you could implement it by creating a Component and EntitySystem that handles the states for you:

// Component example
public class StateComponent<T> implements Component {
    private State<T> state;

    public StateComponent(State<T> state) {
        this.state = state;
    }
    //  Other methods omitted for clarity.
}

// System example
public class StateSystem<T> extends IteratingSystem {

    private YourCustomStateMachine machine = new YourCustomStateMachine();

    public StateSystem() {
        super(Family.all(StateComponent<T>).getFamily());
    }

    @Override
    public void update(float deltaTime) {
        super.update(deltaTime);
        // Make sure to update machine in the update() method so it only 
        // runs once per frame and not once per entity.
        machine.update();
    }

    @Override
    protected void processEntity(Entity entity, float deltaTime) {
        //Process the entity and update states as usual.
    }
}

For a more generalized question on Finite State Machines and Component Based Programming see this question.

\$\endgroup\$
6
  • \$\begingroup\$ So are you saying that, you recommend useing FSM states as state only and handle the data logic purely to the ECS system. \$\endgroup\$
    – ronscript
    Jul 25, 2016 at 19:18
  • 1
    \$\begingroup\$ Exactly. In fact, you should maybe even have a StateComponent and StateSystem have those store your entities state as well (if you don't already have it set up like this). \$\endgroup\$
    – Charanor
    Jul 25, 2016 at 19:27
  • \$\begingroup\$ That's the word I want others to metion, That using StateComponent and StateSystem is better. I have these in my mind, but still having doubts because FSM states and states could make a redundant data. \$\endgroup\$
    – ronscript
    Jul 25, 2016 at 19:29
  • \$\begingroup\$ You could edit and make a brief explanation about StateComponent and StateSystem, so I could mark this as an answer. \$\endgroup\$
    – ronscript
    Jul 25, 2016 at 19:31
  • \$\begingroup\$ what do you recommend to use in StateComponent, integer of state/states or an enum of state/states? \$\endgroup\$
    – ronscript
    Jul 25, 2016 at 19:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .