Another Devember day, another coding goal smashed; now clicking on the ball causes it to visually move through the maze, so you can see the progress instead of just the finished track of how it arrived at it’s destination. This is pretty simple to pull off, but it shows that it doesn’t take much for the project to have a visual leap in quality (if my crude graphical representations can be called such).

 

Here we have yet another contrived level showing off the new features. Instead of just seeing the ball at it’s final location we get to watch its travels through the maze. Among other things this makes the switching of the arrows seem more appropriate as you get to see them trigger as needed instead of all at once as it did before. It’s also easier to understand what movement the ball is taking as it makes a more convoluted path.

We already had the pieces in place for this particular task; a method that could be invoked with a given ball and position in the grid which applies all of the appropriate logic to determine where the ball goes next (if anywhere). All we need to do is invoke this method on a set interval as time passes, updating the visual location of the ball, until we’re told the ball is not moving.

To do this, we first start the ball moving by registering a click on the ball as we did before. Here we remove the ball from the grid by setting the cell that it used to be in to be empty and store that ball entity into a member variable that represents the ball that it currently moving. This variable acts as our sentinel value to tell us if a ball as actually dropping.  Also, since the ball is no longer a part of the maze, we need to have our rendering code be sure to draw the ball manually while it’s in motion. Before we leave we record the current engine tick (or frame, if you will) so that we can time how long it will be until the next movement has to happen.

In our frame update method, we check to see if we’re dropping the ball or not. We also compare the current engine tick to the time that the ball was last moved to see if enough ticks have elapsed for us to want to move the ball again. If we’re dropping the ball AND enough time has passed, we can invoke our method to see where the ball went.

At this point, if the ball did not move, we know we’re done, so we can insert the ball back into the maze at it’s final position and clear the member variable that represents the dropping ball. If the ball DID move, then we just need to update the time of the last movement so that we know that it happened on this tick, so that we can time out the next movement. Everything else is taken care of for us by the code we already have written, including the teleporting around and picking up bonus tiles.

This is still visually rather crude; the ball shifts in whole cell increments, when it could render itself partially between the two cells it’s moving between, but that’s something we’ll leave for polish later. Also, the teleport is a little too instantaneous; there should be something graphical happening there. This is why I originally implemented the vanish/appear animations for the balls, but now I’m thinking that a simple linear interpolation of it jumping to the new location might be a better visual indication; that way you can track the ball as it moves.

For tomorrow I’m thinking that I should fill in some last bits of logic for the ball movement. Specifically, we should detect when all of the balls have been pushed and use that as a signal to trigger the vanish of all of the gray bricks, and then we need to be able to iterate through all of the balls still on the screen and give them one last nudge to see if they’re going to move any farther before they finish up their movement.