So I didn’t quite finish the game design document it turned out. The ideas and concepts had been decided on, though I had not designed any algorithms or class structures in order to structure and implement the game.

I wrote out some pseudocode to cover the beginnings of the puzzle-game prototype. It was decided it was going to be a match-3 genre of puzzle game, so consideration had to be given to how to represent the tiles, the puzzle grid, populating the initial game board, moving tiles and checking for matches.

Writing these were very useful, it helped me address some issues before starting to code them. It also gave me a structure to follow when I started to code, helping me work towards my goals.

Tile classes were created, that were of various colours, and could also be flagged to contain a “special ability” or a less favorable “enemy buff”. They would also possess a collider in order to detect ray casts for the control mechanism.
The puzzle grid was made up by the arrangement of the tile game objects, spaced out evenly, unaffected by unity’s built in gravity system. In addition to positioning the elements to construct the puzzle grid state, a 2D array was also created to represent the current game state. This 2D array would house references to each of the tile objects in the game, with the index of each tile being the x and y coordinates of the tile.

Populating the initial game board made use of an object pooling class, which will make the game more efficient as it’s being played. The challenge here was to generate a gameboard where no existing “matches” existed. An algorithm to detect if there were a row or column of 3 or more of a tile type was designed and implemented. This would be used before placing any tile during the puzzle grid initialisation, ensuring that no “matching tiles” would exist in the initial puzzle grid. The final thing was to randomly assign some tiles with special abilities or enemy debuffs. The amount of these would be set via a manager class, and would need balancing once the prototype has completed.

Movement of tiles was next needed. Raycasts were used on mousedown and mouseup in order to detect players dragging and releasing. If the mousedown and mouseup were both over tiles that were adjacent to each other (not diagonally), the objects would swap their positions, and the gamestate 2D array would update its references. Valid swaps however would need to result in a match being made, so it was implemented that a move only happened should a match result in the move. Once the match was checked, the tiles would swap positions as previously described, then the match would be implemented - which deactivated all affected tiles.

Tomorrow I hope to start work on refilling the puzzle grid after matching, along will implementing the “falling of blocks” should any tile below them get removed during a match.