For the second day in a row I abandoned my plan to get to work on the state machine that will drive the different parts of the game. This time around it was less because I wanted to work on something else and more that I wanted to think a little more on how exactly I want to go about working it. That requires sitting down and thinking a bit of all of the states I’m going to need and I didn’t have time to do that and code, so I did some coding again instead.
So what we have is a little bit of code cleanup and some extensions to yesterday’s AI code to make it a little smarter.
This is actually something that I had originally planned on implementing with the core AI, but due to the issues I was having yesterday (for example getting the meaning of what false means when you try to move the ball downwards backwards and banging my head trying to figure out why the simulation was not working) I didn’t quite get far enough to do it.
The basic gist is that when the AI was selecting a move, it was scoring the different moves based on the current situation in the maze instead of on the future. For example, given a move that would get the ball half way down the screen before getting blocked by an arrow and getting the ball a quarter of the way down the screen blocked on a gray brick, it would choose the former (lower is better position-wise) even though it would be able to get the ball all the way to the bottom of the screen when the gray brick is eventually removed.
To add some insight and (apparent) future planning to the AI selection, all we have to do is make gray bricks not block the ball while the simulation is running. This allows the AI to do a best guess on where the ball will ultimately end up, even if it doesn’t get there right now (or maybe never). In order to accomplish this I added the isSimulation parameter added to various MazeCell methods yesterday to the blocksBall() method.
So now a gray brick will always never block the ball, even if it’s visible currently, because eventually it won’t be and the ball will continue on at the end of the round. Additionally this pointed out a little bug in the Brick ballTouch() method; during simulation it would score passing through ANY brick as if it was a bonus brick, causing the AI to select a path that passes through more gray bricks for no explicable reason whatsoever.
Since I was in the vicinity I also cleaned up a couple of places that were still using the currently running animation to determine if a ball or brick was visible instead of the recently added boolean flag that tracks that value. I also added in the last of the animations to the Player entity so that we can create a player entity now.
Tomorrow I am definitely going to sit down and work out on paper a bit more what kind of FSM states I’m going to need so that I can best determine how/where to implement it.