Here we are at the second to last day of Devember 2016, so time to pour on a little development speed, I guess. This means I need to put down my 3Doodler and actually write some code. We actually got a lot done today, including this little visual tweak:

Today started off with cleaning up a lot of loose ends, the first of which was the inclusion of a game over scene. Like in Rx last year, this is a simple scene that calls the update and render method of the main game screen to keep a display of the final maze still on the screen while providing a menu that allows for replaying the game again with the same settings as last time or quitting back to the main menu.

This could have been implemented directly in the game scene, but this paves the way for future enhancements to the game over screen without having to cruft up the main game code, which is always a good idea, I think.

There was a little issue in yesterday’s changes in that the game scene would reset the score every time it generated a maze, which means that in a multiple round game the score kept getting reset. This was a simple redaction of that logic that I missed yesterday (shame on me for not paying attention to the score while testing).

In keeping with the spirit of the original game, every round after the maze is generated instead of assuming that it is the human player’s turn we randomly select a player and make it their turn to start with. This means that (roughly) 50% of the time the computer gets the first move instead of the human player.

There are also a small boatload of visual tweaks to things. On every round start, the human and computer player positions are reset back to their starting locations, and the computer starts at the far right instead of where the computer is. This just looks cleaner.

Also, instead of the two (undocumented) keys that would swap between the player and human balls (which was primarily for debugging) this is now a toggle key; when you press it, the computer balls appear and when you press it again the player balls come back. These keys only work while it’s the players turn, and while the computer balls are showing, the player is not allowed to move around or push a ball (to stop them from pushing a computer ball).

Lastly, there is the new visual tweak that is visualized in the animated gif at the top of the post. When a ball is scored, instead of fully vanishing away at it’s current location, it will do a half vanish and then fly across the screen towards the score of the player that is getting the score as the vanish continues.

This is a little bit of a hack; the engine as currently written waits for the ball to fully vanish before it triggers the callback that indicates that the ball should be scored. What it should ACTUALLY do is trigger the callback right away, and then the scoring code could jump the ball while it’s lerping instead of playing two halves of the animation.

I didn’t go that route because that is a more invasive change than I want to make at this time of the night. However I did feel like it was important to visually show the ball moving towards the score value when it’s scored to help reinforce what’s happening, which seems particularly important at the end of the round when a lot of balls are going away.

This could be cleaned up more, such as a longer time between the balls vanishing, better animation, etc. That’s the sort of visual polish that you tend to worry about once you’ve got everything core done, though.

Tomorrow is the last day of Devember, so we’ll see what final changes are made. I’m waffling on music and sound because at this point I think a better thing might be to include little title cards between the states that tell you whats happening. Also I’m not sure that music enhances a game like this for me. I guess I could be a stickler and say that the original probably didn’t play music, since it was a DOS game. I don’t know that for sure, though.