Lets all take turns

by ·Comments Off on Lets all take turns

Continuing with yesterday’s integration of the new state machine to track what’s going on, we now have a computer player that can take its own turn instead of a key to press that causes the human player to take a turn. Visually, that looks a little something like this:

There are a few steps to how this all plays out, both with the current state machine and event tracking, and with some additional code in the Player entity as used for a computer player.

To start with, the old code would always transition from the ball dropping state to the human player state. Instead we now currently respond to a ball finishing dropping by either switching to the human player turn or the computer player turn, depending on what state we were in prior to the ball dropping. This is a little naive currently since it does not check to see if a move is actually possible for a player before switching to their state and it doesn’t switch to a state that indicates that the round is ending, but baby steps, right?

We already have the ability to create a Player entity that represents the computer player (it’s a slightly different color, basically) so it is easy enough to create one to represent the computer player. An additional visibility flag was added so that we can selectively hide either (or both) player entities. Currently we just make sure that only the one taking their turn is visible on the screen at any given time.

The bulk of the logic here is in the Player update() method and only triggers for the computer player when it’s visible on the screen. It has its own mini state machine to track what it’s supposed to do. If it doesn’t know what ball it’s pushing, it selects one. If it DOES know, then it walks in the direction that the target ball is in until it gets there. When it gets there, it pushes the ball.

This logic is currently slightly visually prettied up by having it follow the same rules as the player; it has to turn to face a direction before it can walk (or push) in that direction, and it waits to ensure that it’s finished playing the required animation before it takes the next step. This is not currently time constrained at all, and so the “animation” of the computer player walking to the target location plays out as a 30fps animation (not counting the animations that change facings).

This is still missing the fact that the computer and human players should each have their own set of balls to push that get swapped between as they become visible on the screen. There is also that aforementioned lack of “round end” state; if you play the current prototype, after the last ball is pushed you get to see the two players swap in and out as each remaining ball is dropped through the maze, eventually landing on the computer player complaining that it cannot make a move.

A little more fleshing out in this area (and the addition of score values) and we pretty much have a crude playable prototype. Not too shabby for roughly 20 hours of coding effort!

NOTE: When I sat down to start tonight’s session, I discovered that the command I entered to upload yesterday’s code and then push it up to gitlab didn’t work because I mistyped the word “upload” in my chain of commands. As such yesterday’s code didn’t get pushed up until today when I noticed that. I assure you I wrote the code yesterday, though! I made sure tonight that the command actually worked. Lesson learned!