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
\$\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.

|improve this answer|||||
\$\endgroup\$
  • \$\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 '16 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 '16 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 '16 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 '16 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 '16 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.