Player states #5

Small story on how I started looking into and implementing game states.

When I started looking into game development I had no idea about the game loop concept. That's the first thing you learn. In JavaScript developers used to perform the update and render work with setTimeout, now everything changed to requestAnimationFrame who is actually synced with the computer's frame rate.

Coming from making applications and web pages, that's an interesting concept to grasp.

Anyway, after a while, your game gets bigger in code base, actions, events that an entity can perform. That leads to extreme complexity in your entity logic update code.

If the player is not under attack then he can eat but if his life is below or equal to 0 then it needs to teleport to the start point. That kind of if/else structure leads to madness.

Luckily I have taken some time off from the project to read about Game States in the Game Programming Patterns book by Bob Nystrom. I strongly recommend revisiting it over and over when you deal with some game programming specific problems.

This allows me to prioritize an entity states and to separate and keep each state logic inside itself. There is some shared logic on the Entity class itself, but that is generic.

I have managed to now work and debug each state independently.

When you press "lay bomb" key, I check if the state "LAY_BOMB" can be triggered on the Player class. If green then I trigger it with this.state.trigger("LAY_BOMB", args?). The args parameter is optional and I use that for more complex states that involve references to other objects.

Now "LAY_BOMB" state has a maximum number of update_ticks and render_ticks. Once these are depleted the state destroys itself. This also allows the player to lay a bomb without waiting for the "LAY_BOMB" animation to finish - like in Dota.

Here is the full video log: