Today was a day of adding visual feedback to the game. This process took a little restructuring of the main update loop. The end result is great, it is now possible for the player to track what happens when they perform a switch, as seen below!

The main issue was that everything was being proccessed in one update cycle. This meant that within one frame, the following things happened:

• the switching of tiles

• the matching of switched tiles

• the dropping down of existing tiles into gaps

• the addition of new tiles to the board

• any new matches caused by the new tiles

• the repetition of the last 3 steps until no matches occur

The player had no hope of understanding what was going if these were all to be processed in the same game frame. Even if we were to add animations, it wouldn’t work! Because delaying removal of tiles from the game for the sake of animation would break the mechanics - it would think tiles were still there when they weren’t meant to be etc.

Had to come up with a way to break down the game into the different states listed above. The update cycle would check the game state, and only run the code for one particular state until it was “finished” doing what it was meant to be doing. This meant many frames could occur as the game moved from state to state. This also meant we could wait for animations to process, and only move on to the next “state” once they had completed. This would avoid the issue of slow animations affecting the game mechanics unintentionally.

Once that was done, it was time to get some animations involved! I used DOTween, a tweening library that is tried and tested and I had previous experience using it (albeit a limited amount!). Within some hours we had nice tile switching, tiles dropping and tiles matching animations. It made such a difference, and despite me knowing this game is just a clone - it still felt pretty awesome to have it come together.

The next struggle game with having to reconsider and finalise the rules around “matching”. The algorithm I initially implmeneted would go through each tile from bottom left to top right, and perform matches when a chain was found. The downside to this was that if two chains relied on the same tile, the second chain would no longer be detected as a chain - as the common tile betwen chain 1 and chain 2 was removed when chain 1 was “matched” and removed.

A silly amount of doodling in PyxelEdit allowed me and the awesome people on twitch to narrow down the way we wanted our puzzle to work. Discussions were had about what counted as a chain, would a variety of “L” shapes and “hammer” shapes count as one chain, and how to store information about each chain. It was decided in the end, keeping in mind the desire to make the game mechanics as clear and transparent to the player as possible, that chains could only travel in one direction, but any chains sharing a common tile were also possible.

Eventually a new algorithm for scanning the whole puzzle grid and collecting information about the chains was designed and implemented. Despite the game functionality not changing drastically, these changes will give us much needed information further down the line - where we need to know about the chains that were matched to reward the player accordingly.

The next aim is to add a few more animations to show the player clearly what were the “chains” matched. This will help the player processed what is happening, but more importantly understand the mechanics about how chains are created. This knowledge will allow players to then plan and implement strategies that they can confidence in working as expected.

I’m meant to be moving on to prototype the tower defence element tomorrow, but we shall see how time goes, as this part of the puzzle is important to get right in order to give information to the tower defence element of the game.