States :: Journal #004

Not sure about these titles. They’re getting a little too generic for me. Changed the format a little.

Anyway.

Realised over the weekend that before I travel any further, I need to implement States within the foundational code. Nothing fancy, just your basic state machine understanding.

That is, in the context of this project. Each of the objects in the game will have a state. Actually, they’ll probably have more than one state type. An object can be moving AND dying.

So. The first thing was .. where to implement them? In the Object class, or in the children classes? It stands pretty clearly that it should be in the Object. And now that I’m typing it out, things become clearer.

My biggest concern was that certain objects don’t have the same states as others. The player can attack the enemy. But the enemy can’t attack the player, they can only attack the player’s base. The base can’t attack anyone. It is stationary throughout the entire game (at the moment).

But now, writing this out, it’s pretty obvious. I was restricting the design, which is a NO NO. I can restrict the code to cover all these eventualities .. that’s simple validation. But the objects themselves are where the state functionality needs to lie.

Of course, I might discover that the child classes do need their own state functionality. Time will tell.

I haven’t had a chance to implement this yet. Have been cleaning up a few blogs, doing other stuff. Hopefully soon.