# Common ways to keep up with character state in a 2D game?

I am currently developing a 2D Blockdude clone for learning purposes and am wondering about storing character state in the game. For example, the character can be facing either right or left. What are some common ways of handling character state? Unfortunately, the question is so broad none of my searches have come up with anything (or maybe I'm searching for the wrong terms). Should I be using a state machine?

How I'm doing it now using the "character facing" example (code is Java):

enum CharacterFacing {
RIGHT, LEFT
}

class Character {
CharacterFacing facing;

Character() {
facing = CharacterFacing.RIGHT;
}

// called when the player hits the left arrow
void moveLeft() {
facing = CharacterFacing.LEFT;
}

// called when the player hits the right arrow
void moveRight() {
facing = CharacterFacing.RIGHT;
}
}


Because the "facing" state is so simple, I've also thought about just a boolean:

class Character {
boolean facingRight;

Character() {
facingRight = true;
}

// called when the player hits the left arrow
void moveLeft() {
facingRight = false;
}

// called when the player hits the right arrow
void moveRight() {
facingRight = true;
}
}


Because the "facing" state is so simple, I've also thought about just a boolean:

I like to answer by listing how I would approach problems of this type:

1. Start with the solution that need the least amount of "new stuff" (new classes, new functions, new variables, new constants etc..)

2. Once you need more, add it (in its "least amount of new stuff" - form).

3. Always be ready to change your classes. Most changes will involve the removal of features as well as addition. That's good. Be never afraid of changes. If you start to "not want to change this stuff anymore - it might break", this is a first sign that you need to think of simpler solutions.

4. Learn your refactoring tools of your IDE to make less errors when changing.

5. Most important: This is not a dogma. Its a guidance. You will break this rule. Often.

So for your specific question: Since the boolean is one less type to declare and 3 lines less code, go for it (as a rule of thumb - not an dogma ;)).

Until you like to have more than two possible values or you start to get confused by the code and always have to look up what exactly the boolean was. In either case refactor the code then to use an enum, the state-object pattern, split the class into a hierarchy or whatever seems the easiest solution with your new requirements then.

PS: yea.. its not my idea.. Other were first. ;)

Should I be using a state machine?

I won't really call it a state machine personally. Its more like a clean method of knowing which way the player is facing rather than having say magic numbers for example i.e.

if (direction == 15) // what is 15?


15 means nothing to me, whereas

if (direction == CharacterFacing.Right)


Is so much more clear and leaves no room for interpretation, i can easily see that this code will come into play when the character is facing right. So i'd say yes, there's nothing wrong with using a 'state machine' even in this most basic of ways. It just keeps things clean and nice to read.

P.s - I don't think there's a difference between using enums & bools, i mean they both do exactly the same job, i suppose the only difference with boolean's is that like you have done, there's more work involved in making sure the "facingLeft" bool would have to be set to false & vice versa in the opposite movement functions. Its all about personal preference really.

Looks sensible.

In this case, it might sometimes be useful to store it as an int instead, but only use values of -1 (left) and 1 (right). Then, when the character starts walking, you don't need to check direction, but you can simply do:

float dt = /* amount of time elapsed since last frame */;
float speed = /* character walking speed */;
position.x += dt * speed * facing;