Adding a "Match 3 to Clear" Rule in the Unity Puzzle Game Tutorial! Deletion Logic and Color Management [Part 7]

Previous post↓

In this lesson, we implemented a mechanism where connected balls of the same color disappear when there are 3 or more.
Up until the last lesson, we had the "drag to select balls" functionality working, but now we are entering the phase of creating actual puzzle game rules.

Reference: Increasing ball types / Processing to clear when 3 or more balls are matched | Unity Forest - How to make games

Creating a mechanism to correctly count selected balls

First, in the first half, we started by processing how to correctly count the number of selected balls.
Especially important was the introduction of the isTouch variable.
Previously, there was an issue where if you touched a ball that was already selected again, the count would incorrectly increase.
Therefore, we added the condition
&& !h[0].collider.GetComponent<BallObject>().isTouch

and changed the mechanism to
"only add if the ball has not been selected yet."
From the moment isTouch is set to true, that ball is treated as selected,
which prevents double counting.
Furthermore, by referencing isTouch in Update so that the Emission color changes automatically,
the selection state has become visually easier to understand.

Determining the ball count and clearing on MouseUp

In ReleaseObject(), which is executed when you release your finger (mouse),

we were able to implement the flow of:
Getting the number of selected balls
Destroying them if there are 3 or more
Clearing the selection state and resetting

var cnt = touchBallList.Count;
if (cnt >= 3)
{
Destroy(go);
}

In this way,
the branching logic for whether balls disappear based on the number dragged was completed.
Note that if they disappear even when only 2 are selected,
it is caused by forgetting to write isTouch = true or a mistake in the conditional logic.
As the code becomes more complex, these kinds of input omissions become more likely to occur.

Second half: Managing ball types (colors) with enum

The next thing we worked on was
a mechanism to give each ball a type (color).

▼ The flow is the following 3 steps

1. Define color types as an enum in GameResources.cs

2. Assign a color randomly during generation in BallGenerator.cs

3. Reflect it in the appearance via Start() → ChangeColor() in BallObject.cs

The point here is that
since types can be managed collectively with an enum, it is flexible for adding colors later.
Also, we used Linq for the process of choosing a color randomly.

Enum.GetValues(typeof(GameResources.BallColor))
.Cast<GameResources.BallColor>()
.ToList()[UnityEngine.Random.Range(0,4)];

It looks long, but it is just writing the flow of "List of enumerations → List → Pick one randomly" in a single line.

Summary of Part 7: Moving forward step by step while facing increasingly complex code

In this session, since the work was centered on copying code, there were few moments of confusion regarding the overall flow of the process. On the other hand, I strongly felt that even the smallest mistakes, such as omitting an isTouch input or missing a conditional expression, lead directly to abnormal behavior. For example, this was a session where the difficulty of writing code in Unity became apparent, as unintended behaviors like "disappearing even though only 2 were dragged" occurred due to a slight oversight in writing. Furthermore, new concepts such as Raycast, conditional branching, list management, enum, and Linq appeared one after another, and the difficulty of grasping which process is responsible for what has also increased. However, behind that complexity, the game's mechanics are definitely becoming more authentic.

With the "clear when 3 or more match" process now complete and the ball type management implemented, the core rules of the puzzle game have taken shape.

I will do my best next time as well.

#Unity #GameProduction #GameDevelopment #UnityBeginner #IndieGameDev #LessonsLearnedInGameDev #PuzzleGame #UnityPuzzleGameCourse #Random.Range