# A few questions about entity states

This topic is 2473 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

This is the first time I'm trying to make a 2D game, so I'm having quite a few difficulties in getting things right. Right now I'm trying to figure out exactly how the entity state machine should work.

1. I noticed entity states are... well, stateless. Basically, they just act on the data in the entity accordingly, they hold no data of their own. When an entity forwards events to its states it does it like this:

 void Entity::handleEvent(const Event& event) { // We pass this to the state so it could act upon the data in // the entity in a manner appropriate for the given event. state_->handleEvent(event, this); }

That means that I don't really ever need more than one instance of a particular entity state; doing something like [il]entity.setState(new StandState)[/il] is therefore highly wasteful. Then again, making each entity state a singleton hardly seems appropriate. What do you suggest I do?

(The same can be said about game states, so whatever the solution to this is, I guess it can be applied to game states as well.)

2. The state of the entity sprite. Most of the time, whenever the state of the entity changes, the sprite that is used to represent it must change as well. How should the entity representation be notified of the change in state?

Then again, should it be notified at all? It seem that if the representation needs to be made aware the entity has changed, then it (the representation) starts having an internal state. I would much rather have it stateless so that I require only one instance of every representation (just as before).

##### Share on other sites

1. I noticed entity states are... well, stateless.

That happens. It might not necessarily continue to be the case.

What do you suggest I do?[/quote]

Continue to use the objects normally. "Special cases aren't special enough". The fact that a bunch of objects contain no state does not prevent you from using them like ordinary state-having objects, in much the same way that the fact that Granny Smith apples are green does not change the way that you eat them.

2. The state of the entity sprite. Most of the time, whenever the state of the entity changes, the sprite that is used to represent it must change as well. How should the entity representation be notified of the change in state?

Then again, should it be notified at all?[/quote]

How are you causing the state change? The simplest way is to have the update function return the next state object (either itself, or a new one, or ...), and let the entity update a) call the state update; b) accept the new state and start holding onto it; c) make any other corresponding changes.

Although... have you considered that maybe the sprite should be a part of the state, rather than the entity itself? Or maybe it should not be held as data at all, but retrieved on demand when you render? Have you considered that rendering might be functionality provided by the state, as well 'updating'? That also allows you to handle things like, e.g. in certain states the sprite should blink and in others it should stay always visible.

It seem that if the representation needs to be made aware the entity has changed, then it (the representation) starts having an internal state. I would much rather have it stateless so that I require only one instance of every representation (just as before).
[/quote]

Don't try to arrange things like this. You are wasting effort in an attempt to waste more effort (justifying some kind of singleton registry setup that you then have to maintain), all so that you can re-use objects (which is of dubious value). If you worry about reuse, first target, you know, the actual image resources and stuff like that.