Несколько лет назад на SeishunCon я заново открыл для себя игры match-3. Я играл в Dr. Mario детстве, но такие более соревновательные игры, как Magical Drop, Bust-A-Move и Tokimeki Memorial Taisen Puzzle-Dama, сильно отличаются от неё.


Dr. Mario

В результате я осознал, как много нейтральных решений связано с созданием игры match-3.

На следующем джеме Ludum Dare я решил поэкспериментировать, но сначала за неделю до этого для разогрева попробовал разработать алгоритм «Тетриса», обнаруживающий и удаляющий линии. Мне очень помог этот туториал Unity Plus. [Прим. пер.: у меня ссылка не открывается. Если вы знаете, как решить проблему, напишите мне, я дополню статью.] Разумеется, алгоритм «Тетриса» для поиска заполненных рядов гораздо проще, чем алгоритм, выискивающий разнообразные сочетания совпадающих тайлов.

Если вы хотите изучить эти примеры кода в контексте, то зайдите в мой репозиторий Ludum Dare 30. (Для бесстыдной саморекламы я снова использовал эту логику для игры Shifty Shapes.)

Два мира

Magical Drop 3 (источник: Kazuya_UK)

Самая мудрёная часть создания игры-головоломки в Unity заключается в том, что игра не живёт в пространстве мира. Во всяком случае, живёт не полностью.

В этом её отличие от других жанров. Платформеры, например, почти полностью живут в игровом мире Unity. Transform игрока сообщает о его положении. Коллайдеры (или, в некоторых случаях, raycast) говорят, находится ли игрок на земле, ударяется ли об потолок или столкнулся с врагом. Даже если вы не используете внутриигровую физику, то всё равно, скорее всего, добавляете силу или указываете скорость Rigidbody, чтобы обеспечить распознавание столкновений без затрат.

Игры-головоломки совсем другие. Если в вашей игре нужно щёлкать мышью, то она наверно получает какие-то координаты в пространстве мира, но их обычно преобразовывают в ячейку сетки, которая полностью живёт в коде. Для этого есть понятная причина: гораздо проще создать логику для такой игры как Tetris или Dr. Mario, когда работаешь не с отдельными пикселями, а с блоками или тайлами.


Блоки «Тетриса» определённо не должны прилипать к стенкам стакана

На самом деле, в своих экспериментах я стремился как можно больше придерживаться пространства мира. Я использовал физику для определения «приземления» тайлов и передавал данные в двухмерный массив только для определения заполнения строки. Это казалось более безопасным: в конце концов, то, что происходит в игровом мире реально. Именно это видит игрок, поэтому если хранить данные тут, то нет риска рассинхронизации, правда?

Я ошибался. Как бы я ни пытался настроить систему, она просто не работала правильно.

Туториал Unity Plus, ссылку на который я дал выше, оказал мне огромную помощь. Как минимум, он показал, что правильным подходом был полный перенос логики из игрового мира в абстрактную структуру данных. Если вы ещё этого не сделали, то хотя бы вкратце просмотрите его, потому что в этой статье я расширю логику «Тетриса» до логики match-3.

Преобразование из поля в пространство мира

Как только я понял, что этот переход удобен, остальное было простым. Я создал класс GameTile, отслеживающий цвет, строку и столбец тайла, и на его основании обновлял положение тайла. Вот его сокращённая версия:

public class GameTile : MonoBehaviour {

 private Transform _t;
 private SpriteRenderer _s;

 [System.NonSerialized]
 public int TileColor;

 [System.NonSerialized]
 public int Row;

 [System.NonSerialized]
 public int Column;
 
 void Awake () {
   _t = GetComponent<Transform>();
   _s = GetComponent<SpriteRenderer>();
 }

 Vector3 tmpPos;
 public void UpdatePosition()
 {
   tmpPos = _t.position;
   tmpPos.x = (Column * Board.TileSize) - Board.WorldOffset;
   tmpPos.y = (Row * Board.TileSize) - Board.WorldOffset;
   _t.position = tmpPos;
 
   _s.sprite = Board.Current.Textures[TileColor];
 }

Тайлы в сетке

Заметьте, что в этом случае TileSize является константой, определяющей размер тайла в единицах Unity. Я использую тайлы размером 64?64 пикселя, а спрайт в Unity имеет разрешение 100 пикселей на единицу, поэтому TileSize оказывается равным 0.64. Также я использую постоянное смещение, чтобы середина поля 7?7 находилась в координатах 0,0 пространства мира, а левый нижний угол являлся тайлом 0, 0 в игровом пространстве.

Также я создал массив, определяющий игровое поле как статичное поле (static field) в классе Board. (Board сначала был статичным классом, а потом превратился в синглтон (singleton), потому что мне нужно было изменять значения в редакторе, поэтому он неуклюже сочетает в себе черты игрового объекта и статичного класса.)

 public const float TileSize = 0.64f;
 public const float WorldOffset = 1.92f;

 public const int BoardSize = 7;
 public static GameTile[,] Tiles = new GameTile[BoardSize, BoardSize];

В туториале Unity Plus двухмерный массив использовался для хранения целых чисел, я же решил хранить в этом массиве ссылки на мои объекты GameTile. Это позволило мне передавать данные от тайлов и к ним напрямую (как вы увидите позже), что упростило удаление тайлов и создание анимации.

При внесении изменений в состояние игрового поля мне нужно было просто пройти циклом по всему массиву поля и сообщить каждому тайлу, где он должен находиться:

 public static void UpdateIndexes(bool updatePositions)
 {
   for (int y = 0; y < BoardSize; y++)
   {
     for (int x = 0; x < BoardSize; x++)
     {
       if (Tiles[x,y] != null)
       {
         Tiles[x, y].Row = y;
         Tiles[x, y].Column = x;
         if (updatePositions)
           Tiles[x, y].UpdatePosition();
       }
     }
   }
 }

Заметьте, что в каждом случае мы выполняем преобразование из абстрактного игрового пространства в пространство мира. Игровые объекты Unity не хранят сами важную информацию о состоянии игры, они всегда являются только отображением этого состояния.

… и обратно

В моей игре был единственный случай, когда нужно было выполнять преобразование из мира в игровое пространство: когда игрок щёлкал мышью на пустое пространство, чтобы бросить на поле тайл. Для этой задачи я создал большой коллайдер под всем игровым полем и прикрепил к нем следующий скрипт:

 void OnMouseDown()
 {
   if (GameState.Mode == GameState.GameMode.Playing)
   {
     mouseClick = Camera.main.ScreenToWorldPoint(Input.mousePosition);
     mouseX = (int)Mathf.Round ((mouseClick.x + WorldOffset) / TileSize);
     mouseY = (int)Mathf.Round ((mouseClick.y + WorldOffset) / TileSize);
     PutNextTile(mouseX, mouseY);
     Soundboard.PlayDrop();
     GameState.ActionsTaken++;
   }
 }

Вот, собственно, и всё. Заметьте, что в сущности в нём выполняется действие, обратное UpdatePosition(), где игровое пространство преобразуется в пространство мира.

Распознавание и удаление совпавших тайлов

Удаление совпавших тайлов

Это самая хитрая часть. Наверно, именно ради этого вы читаете статью.

Горизонтальное совпадение (как в «Тетрисе») реализовать довольно просто: нужно всего лишь искать смежные тайлы в одной строке. Даже добавление горизонтальных или вертикальных совпадений (как в Dr. Mario) является просто вариацией этой темы. Однако отслеживание набора смежных тайлов в одновременно горизонтальном и вертикальном направлении потребует рекурсии.

При каждом действии, изменяющем игровое поле, мы запускаем проверку. Первое, что мы делаем — копируем весь массив поля в другой массив:

 static void CopyBoard(GameTile[,] source, GameTile[,] destination)
 {
   for (int y = 0; y < BoardSize; y++)
   {
     for (int x = 0; x < BoardSize; x++)
     {
       destination[x, y] = source[x, y];
     }
   }
 }

 static bool clearedTiles = false;
 public static void MatchAndClear(GameTile[,] board)
 {
   clearedTiles = false;
   // Создаём копию поля для проверки
   CopyBoard(board, toTest);

// Продолжение ниже...

Зачем? Мы увидим позже, что так будет гораздо проще определить, какие тайлы мы проверяли.

Мы начинаем процесс с «грубого» перебора. Пройдём от ячейки к ячейке (сначала строки, потом столбцы), проверяя каждую ячейку. Для каждой проверки мы сбрасываем некоторые переменные, используемые для отслеживания проверки, а затем вызываем отдельную функцию (которую позже применим для рекурсии):

// Продолжение MatchAndClear()...

   currentTile = null;
   collector.Clear ();

   for (int y = 0; y < BoardSize; y++)
   {
     for (int x = 0; x < BoardSize; x++)
     {
        TestTile (x, y);

// Продолжение ниже...

Давайте рассмотрим эту функцию TestTile:

 static void TestTile(int x, int y)
 {
   // Тайл уже проверен, пропускаем
   if (toTest[x,y] == null)
   {
     return;
   }
   // Начинаем проверять блок
   if (currentTile == null)
   {
     currentTile = toTest[x, y];
     toTest[x, y] = null;
     collector.Add(currentTile);
   }

// ** Пропущенные строки - мы вернёмся к ним позже **

 // Если мы обрабатываем этот тайл, то проверяем все тайлы вокруг него
   if (x > 0)
     TestTile(x - 1, y);
   if (y > 0)
     TestTile(x, y - 1);
   if (x < Board.BoardSize - 1)
     TestTile(x + 1, y);
   if (y < Board.BoardSize - 1)
     TestTile(x, y + 1);
 }

Если функция обнаруживает, что ячейка имеет значение null, то пропускает её. Ячейка с null означает, что она или пуста, или мы уже тестировали её. (Именно поэтому мы скопировали её в отдельный массив — так проще произвольно манипулировать новым массивом.)

Если ячейка имеет значение, то мы делаем следующие действия. Во-первых, мы запоминаем её как «текущую» ячейку, ту, которая находится на вершине рекурсивной цепочки. Затем мы удаляем её из копии игрового поля, чтобы не проверять дважды. Также добавляем её в список (List), чтобы запомнить, сколько смежных тайлов одного цвета мы нашли.

Есть два состояния, которые могут возникнуть позже в рекурсии, но мы поговорим о них потом. Проверив ячейку, мы берём четыре ячейки вокруг неё и выполняем для них ту же проверку.

«Текущая» ячейка уже установлена, и это значит, что мы не на первом уровне рекурсии. В этих вызовах функций у нас есть три варианта для каждой ячейки.

Во-первых, ячейка может быть null, и это снова значит, что мы уже проверяли её, или она пуста. И в этом случае мы снова ничего не делаем.

Во-вторых, ячейка может не совпадать с «текущей» ячейкой. В этом случае мы не считаем её «проверенной». Наша рекурсия проверяет наличие одного набора смежных тайлов одного цвета. Только потому, что этот тайл не является частью текущего набора, не значит, что он не является частью какого-нибудь другого.

// Из TestTile() выше... 

 // Тайл не совпадает, пропускаем
 else if (currentTile.TileColor != toTest[x, y].TileColor)
 {
   return;
 }

В-третьих, ячейка может быть того же цвета, что и «текущая» ячейка. В таком случае, она «проверена», поэтому мы устанавливаем ей значение null в копии игрового поля. Также мы добавляем её в List, который используем как накопитель. Это одно из состояний, которое мы пропустили в примере выше:

// Из TestTile() выше... 

 // Тайл совпадает
 else
 {
   collector.Add(toTest[x, y]);
   toTest[x, y] = null;
 }

Функция продолжит выполнять рекурсию, пока не закончатся все варианты, добравшись или до пустой ячейки, или до конца поля. В этот момент мы возвращаемся в основной цикл грубого перебора для обработки результатов.

Если в накопителе есть больше трёх тайлов, то мы нашли совпадение. Если нет, то мы проверили один или два тайла, но нам не нужно выполнять никаких действий:

// Продолжение из MatchAndClear() выше...

       if (collector.Count >= 3)
       {
         foreach (GameTile tile in collector)
         {
           ClearTile(tile.Column, tile.Row);
           clearedTiles = true;
           Soundboard.PlayClear();
         }
       }
       currentTile = null;
       collector.Clear ();
     }
   }

   if (clearedTiles)
   {
     SettleBlocks(board)
   }
 }

Здесь, как мы рассмотрим позже, я просто включаю анимацию. Простейший подход, однако, заключается в том, чтобы пройти циклом по нашему накопителю и вызвать DestroyObject для игрового объекта каждого совпадающего тайла. Так мы убьём двух зайцев одним выстрелом: избавимся от внутриигровых объектов и присвоим ячейкам в состоянии игрового поля значение null.

Падение тайлов

Падающий тайл

Определённые изменения — например, падение тайла или удаление тайлов, в этом случае — оставляют тайлы без опоры, и этот случай нужно разрешить (конечно, если это требуется по правилам вашей игры). И на самом деле это довольно простой алгоритм.

Теперь мы проходим столбец за столбцом, а затем строку за строкой. Порядок здесь важен.

В каждом столбце мы проходим снизу вверх, пока не находим пустую ячейку. Затем мы помечаем её. Следующий найденный тайл мы просто смещаем вниз, в это положение, и добавляем единицу к индексу «пустой ячейки»:

 static int? firstEmpty;
 public static void SettleBlocks(GameTile[,] board)
 {
   for (int x = 0; x < BoardSize; x++)
   {
     firstEmpty = null;
     for (int y = 0; y < BoardSize; y++)
     {
       if (board[x, y] == null && !firstEmpty.HasValue)
       {
         firstEmpty = y;
       }
       else if (firstEmpty.HasValue && board[x, y] != null)
       {
         board[x, firstEmpty.Value] = board[x, y];
         board[x, y] = null;
         firstEmpty++;
       }
     }
   }
   UpdateIndexes(false);
 }

После завершения нужно не забыть снова вызвать функцию проверки совпадений. Очень вероятно, что падающие тайлы создали пустые строки.

На самом деле, если в игре ведётся счёт, то это упростит отслеживание комбо или множителей очков. Все эти повторения падений и удаления блоков являются рекурсиями того первого вызова, запущенного действием игрока. Мы можем понять, сколько всего совпадений возникло после действия игрока и какое количество уровней «цепочек» потребовалось для каждого действия.

Анимации

Игра уже работает, но пока она не понятна интуитивно, в основном из-за отсутствия анимаций. Тайлы исчезают, а затем появляются на нижних строках. Сложно понять, что происходит, если не следить внимательно.

Это тоже сложный момент. Игровые объекты всегда являются отражением состояния игры, поэтому тайлы постоянно расположены в сетке. Тайлы всегда занимают то или иное место: тайл может быть в строке 1 или 2, но никогда — в строке 1,5.

В чём заключается сложность? Нам нельзя одновременно манипулировать игровым полем и анимацией. Вспомните, как работает «Тетрис» или Dr. Mario — следующий тайл не падает, пока все тайлы на поле не «улягутся». Это даёт игроку короткую передышку, а также гарантирует отсутствие непредвиденных состояний и взаимодействий.

Кстати, при начале нового проекта я рекомендую создавать перечисление (enumeration) «игровых состояний». Мне никогда не приходилось писать игру, в которой не нужно было знать состояние игры: сам процесс игры, пауза, отображение меню, диалоговое окно, и так далее. Лучше всего спланировать состояния на ранних этапах разработки, таким образом можно сделать так, чтобы каждая написанная вами строка кода проверяла, должна ли она выполняться в текущем состоянии.

Признаюсь, что моя реализация неуклюжа, но в целом идея такова: при удалении или падении тайла мы задействуем изменение состояния. Каждый объект GameTile знает, как обрабатывать это изменение состояния, и, что более важно, знает, когда нужно сообщать игровому полю, что он завершил свою анимацию:

 void Update () {
   if (GameState.Mode == GameState.GameMode.Falling && Row != LastRow)
   {
     targetY = (Row * Board.TileSize) - Board.WorldOffset;

     tmpPos = _t.position;
     tmpPos.y -= FallSpeed * Time.deltaTime;
     if (tmpPos.y <= targetY)
     {
       Board.fallingBlocks.Remove(this);
       UpdatePosition();
       Soundboard.PlayDrop();
     }
   }
 }

После завершения анимации удаления игра должна проверить наличие падающих тайлов:

 private static float timer;
 private const float DisappearTimer = 0.667f;
 void Update()
 {
   if (GameState.Mode == GameState.GameMode.Disappearing)
   {
     timer -= Time.deltaTime;
     if (timer <= 0)
     {
       GameState.Mode = GameState.GameMode.Playing;
       SettleBlocks(Tiles);
     }
   }

После завершения анимации падения нужно проверить наличие совпадений:

   if (GameState.Mode == GameState.GameMode.Falling && fallingBlocks.Count == 0)
   {
     GameState.Mode = GameState.GameMode.Playing;
     MatchAndClear(Tiles);
   }
 }

Этот цикл повторяется, пока у нас не останется больше совпадений, после чего игра может возвращаться к своей работе.