Keeping the ball rolling

Although the plan for today was to include some light level editing for the purposes of testing, I went down a bit of a rabbit hole first with regards to refactoring the movement code a bit. This wasn’t terribly involved but I ended up using up my development time by doing a piece-wise check in of the relevant code to make the changes easier to follow (in case anyone is doing that).

The upshot of this is that this allowed the last of the movement code to be put in place; the ball, once redirected by an arrow, should continue travelling in the same direction as long as it’s rolling over balls that are already in the maze.

The ball can now keep rolling over other balls

The ball can now keep rolling over other balls

As we see here, now if an arrow pushes a ball to the side and it ends up sitting on top of a ball, it will keep moving in that direction until something else stops it. This can be a gray brick, a drop, or an arrow that is not facing in the correct direction.

The way this is achieved is actually rather simplistic (and dare I say elegant? I think I dare not; you judge). The Ball entity now has a new property that indicates what direction it was last moved in. This can be LEFT, RIGHT, DROP, JUMP or NONE as appropriate for the action at hand (JUMP being used for entering a Teleport).  The movement code makes sure that every time the state of the ball movement changes, this property gets updated.

Additionally, the code added yesterday that adds methods for letting a MazeEntity know and control how it is interacting with the ball has been extended so that these methods get told what Ball is currently moving. This is important for the Arrow entity, since it is what knows whether it is pushing the ball to the left or to the right. However, this means that we can now implement logic in the Ball class that is similar to the arrow, providing a push to the ball in the same direction it was already moving.

A side benefit of this is that the boolean value that was added to ensure that two touch events could not trigger back to back is no longer needed (and as been removed). This is because the exact state of this happening (a move type of JUMP) is now tracked explicitly right in the ball, so there is no need to track it with external code.

While I was making these changes, I modified the signatures of the API functions as well; I changed their names to be more descriptive (also helpful in ensure that no dangling uses have gone unnoticed), included the reference to the Ball, and made a bit of a performance improvement to the code.

Specifically, it seemed a little weird that we would pass a Point in, let the code possibly modify it, then check to see if the point was modified or not on return. For one thing this is just wasteful; in order to do this we need to make a duplicate of the Point we have to call in, so that we can compare. It seems better to instead have the method return either null ORPoint; then we would know that it did something and only create the point when it’s actually necessary to do so.

I wrote a large portion of this code all in one shot (changing method signatures and names) but I wanted to check it in in smaller chunks to make the code changes easier to follow. One of the great things about Git is that this is fairly easy to pull off with things like stashes. However, it does end up being a bit time consuming.

For tomorrow, possibly the debug level editing code that I intended to do today, or I may proceed with the (more satisfying) visual movement of the ball going through the maze step by step. There is a big snow storm due in my area, so I may end up with more time to code or I may end up in the middle of a power outage; time will tell.