CAGD 377 - Blog Post 2

Plague Break

Plague Break is a match 3 game with combat and roguelite elements where you play as a survivor struggling against the zombie hoard. Creating matches allows you to damage enemies; special tiles can be mixed into a match to do bonus damage or to heal yourself. Managing your board state carefully is critical to your survival.

Match 3 Systems

• Player Input

The first thing to tackle for this sprint was the player input. For this I began by implementing a swipe directionality detection algorithm which interprets player input such that it is known whether a north, east, south, or west swipe has occurred. During implementation of the game board I set this code aside in favor of a simplistic 'pick up and move' approach to reduce variables during debugging.

A demonstration of player input

As you can see above, the player can touch a piece to pick it up. While held, the piece will follow their finger. As I progressed on the match 3 mechanic, I added the ability to swap pieces based on the release location of the finger. It may be necessary to return to the swipe input system depending on designer feedback but I found the ability to pick pieces up and move them around to be entertaining in its own right. Additionally, it opens avenues for new gameplay mechanics if the team has time for them.

The match 3 system was somewhat more complex than the implementation of the basic player input system. It required a small but notable amount of problem solving, as did the board generation itself.

 • Game Board

First I'd like to discuss the board generation. In order to have a proper match 3 game, there must be pieces that can match with one another and these pieces should not generate pre-existing matches.

An example of the game board generation

As you'll note above, appropriate pseudo-random generation has not yet been achieved. I emphasized this intentionally by running the match check function on the entire board following the board generation's completion to make it clear where matches had been generated.

Currently, pieces generate in a manner that is not fully random - there is checking to prevent creating horizontal matches, but it is not fully functional yet. This has not been classified as a bug yet because the board generation was created simply as a test for the match mechanic. In other words, proper pseudo-random generation is a task that is planned for the next segment of development.

 • Match Checking

The main goal of this sprint was to implement the core gameplay elements e.g. game piece matching and the ability to damage enemies from doing so.

The match 3 system

In the above gif we can see that matches of any length can be made as well as matches that are simultaneously part of multiple match groups (such as an 'L' match). This is accomplished via a recursive check through all matching pieces for both the piece the player was holding and the swapped piece.

I decided to implement the match checking recursively in order to avoid the inefficiency of checking the entire board any time the player updated it. It did introduce complications to the code that resulted in the completion of the mechanic being slower than expected. This did not take too much additional time, however, and considering that the matching is the core system of the game it seems appropriate that it received the attention necessary for it to perform in a robust and efficient manner.

Battle System

The other core element we wanted to achieve this time was the battle system. When the player completes a match they're able to deal damage to the enemies on screen. This was not a challenging feature to create but it is critical for it to function well.

An example of the player damaging enemies

I encountered a surprising hiccough while working on the damage system. As shown, the player can damage the enemies with individual enemies being destroyed based on the percentage of the health remaining in the wave. The trick of this was to ensure that there is always at least one enemy remaining on screen that is only destroyed when the wave's health reaches 0.

The above formula is my current approach for solving the issue. The -1 term is critical here - by treating the check as though there were 1 less enemy in the wave we can shift the breakpoints for when an enemy is destroyed such that the last enemy is only destroyed when the wave is at zero health.

I do foresee issues with the above approach but perhaps more pressingly is the ability for the player to complete huge matches at a time which can, potentially, result in dealing enough damage that the check (which only runs once per damage instance) will 'skip over' destroying an enemy. This would result in the player's experience being harmed. They dealt a huge amount of damage, the enemies should be defeated! This remains an open problem that will need to be resolved in the future.