К чему приводят тестовые задания или как я реализовал Match-3 для терминала

Вы когда-нибудь играли в Match-3 в текстовом терминале? Вот и я бы не подумал, что поводом для этого, может стать очередное тестовое задание.

В разработке я уже около 10 лет и в последнее время начал задумываться, а не уйти ли мне в геймдев? Учитывая, что большую часть времени я посвятил разработке приложений на Unity, а 3D моделированием увлекаюсь ещё со школы.

И вот, после очередной порции откликов на интересующие вакансии. Я получаю ответ от компании X:

Благодарим Вас за отклик на вакансию «Senior Unity C# Developer». Готовы ли Вы выполнить тестовое задание?

Как правило я игнорирую вакансии с обязательным выполнением тестового, но это только в том случае, если задача меня абсолютно не заинтересовала, и я не смогу найти проделанной работе полезного применения. Поэтому если и берусь, то делаю его так, как нравится мне самому. Может поэтому я и не дошёл до этапа собеседования?

Задание

Написать логику осыпания игрового поля Match 3

Базовый функционал:

• реализовать построение игрового поля из любого конфига (json, SO и т.д.)

• поле должно быть размером X на Y клеток и может иметь пустоты

• клетки в первой строке сверху, при нажатии на пробел, должны генерировать фишки которые падая вниз заполнят всё поле

Продвинутый функционал:

• фишки осыпаются с нарастающей задержкой относительно друг друга

• если в каком-то столбце нет генератора (пустота сверху), фишки опавшие вертикально в соседних столбцах, начинают сверху осыпаться диагонально в образовавшиеся незаполненные клетки

Космос:

• после осыпания всего поля можно нажать на любую фишку и эта фишка вместе со всеми соседями такого-же цвета уничтожатся, а образовавшаяся пустота так-же заполнится согласно правилам осыпания написанным выше

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

Стоит добавить, что на всё про всё даётся 7 дней и тестовое не оплачивается.

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

Спустя три вечера, на руках у меня был полноценный прототип Match-3 игры.

Получилось вполне сносно. Но давайте разберём более интересную часть, код и как это всё устроено.

Обратите внимание, что ниже рассматривается код из первой реализации, который можно найти в ветке simple_implementation. Финальный код можно найти в main ветке на GitHub.

Основная магия происходит в классах реализующих интерфейс IBoardFillStrategy.

public interface IBoardFillStrategy {     string Name { get; }      IEnumerable<IJob> GetFillJobs(IGameBoard gameBoard);     IEnumerable<IJob> GetSolveJobs(IGameBoard gameBoard, IEnumerable<ItemSequence> sequences); }

IJob это любая работа которую необходимо выполнить после заполнения или изменения состояния игрового поля.

public interface IJob {     int ExecutionOrder { get; }      UniTask ExecuteAsync(CancellationToken cancellationToken = default); }

Свойство ExecutionOrder отвечает за порядок выполнения. Работы с одинаковым ExecutionOrder будут выполняться параллельно. В качестве работы может быть, например анимация элементов.

Вот так можно плавно показать элемент с анимацией масштабирования:

public class ItemsShowJob : Job {     private const float ScaleDuration = 0.5f;      private readonly IEnumerable<IUnityItem> _items;      public ItemsShowJob(IEnumerable<IUnityItem> items, int executionOrder = 0) : base(executionOrder)     {     _items = items;     }      public override async UniTask ExecuteAsync(CancellationToken cancellationToken = default)     {         var itemsSequence = DOTween.Sequence();          foreach (var item in _items)         {             item.SetScale(0);             item.Show();              _ = itemsSequence.Join(item.Transform.DOScale(Vector3.one, ScaleDuration));         }      await itemsSequence.SetEase(Ease.OutBounce).WithCancellation(cancellationToken);     } }

Использовать получившуюся анимацию можно при заполнении игрового поля:

public IEnumerable<IJob> GetFillJobs(IGameBoard gameBoard) {     var itemsToShow = new List<IItem>();      for (var rowIndex = 0; rowIndex < gameBoard.RowCount; rowIndex++)     {         for (var columnIndex = 0; columnIndex < gameBoard.ColumnCount; columnIndex++)         {             var gridSlot = gameBoard[rowIndex, columnIndex];             if (gridSlot.State != GridSlotState.Empty)             {               continue;             }              var item = _itemsPool.GetItem();             item.SetWorldPosition(_gameBoardRenderer.GetWorldPosition(rowIndex, columnIndex));              gridSlot.SetItem(item);             itemsToShow.Add(item);         }     }      return new[] { new ItemsShowJob(itemsToShow) }; }

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

Алгоритм для обработки последовательностей совпавших элементов будет ненамного сложнее:

public IEnumerable<IJob> GetSolveJobs(IGameBoard gameBoard, IEnumerable<ItemSequence> sequences) {     var itemsToHide = new List<IUnityItem>();     var itemsToShow = new List<IUnityItem>();      foreach (var solvedGridSlot in sequences.GetUniqueGridSlots())     {         var newItem = _itemsPool.GetItem();         var currentItem = solvedGridSlot.Item;          newItem.SetWorldPosition(currentItem.GetWorldPosition());         solvedGridSlot.SetItem(newItem);          itemsToHide.Add(currentItem);         itemsToShow.Add(newItem);                  _itemsPool.ReturnItem(currentItem);     }      return new IJob[] { new ItemsHideJob(itemsToHide), new ItemsShowJob(itemsToShow) }; }

За формирование последовательностей элементов, которые передаются в стратегию, отвечает метод Solve интерфейса IGameBoardSolver.

public interface IGameBoardSolver {     IReadOnlyCollection<ItemSequence> Solve(IGameBoard gameBoard, params GridPosition[] gridPositions); }

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

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

Было решено исправить это недоразумение и максимально упростить процесс добавления специальных блоков. После внесенных изменений, для добавления специального блока, достаточно просто реализовать интерфейс ISpecialItemDetector<TGridSlot> и передать его в GameBoardSolver.

Вот так, например можно реализовать поддержку блока камень:

public class StoneItemDetector : ISpecialItemDetector<IUnityGridSlot> {     private readonly GridPosition[] _lookupDirections;      public StoneItemDetector()     {         _lookupDirections = new[]         {             GridPosition.Up,             GridPosition.Down,             GridPosition.Left,             GridPosition.Right         };     }      public IEnumerable<IUnityGridSlot> GetSpecialItemGridSlots(IGameBoard<IUnityGridSlot> gameBoard,         IUnityGridSlot gridSlot)     {         foreach (var lookupDirection in _lookupDirections)         {             var lookupPosition = gridSlot.GridPosition + lookupDirection;             if (gameBoard.IsPositionOnGrid(lookupPosition) == false)             {                 continue;             }              var lookupGridSlot = gameBoard[lookupPosition];             if (lookupGridSlot.State.GroupId == (int) TileGroup.Stone)             {                 yield return lookupGridSlot;             }         }     } }

Для отслеживания состояний ячейки используется интерфейс IStatefulSlot.

public interface IStatefulSlot {   bool NextState();   void ResetState(); }

Теперь, специальные блоки автоматически передаются в метод обработки совпавших последовательностей, после того как NextState вернет false.

public override IEnumerable<IJob> GetSolveJobs(IGameBoard<IUnityGridSlot> gameBoard,     SolvedData<IUnityGridSlot> solvedData) {     var itemsToHide = new List<IUnityItem>();     var itemsToShow = new List<IUnityItem>();      foreach (var solvedGridSlot in solvedData.GetUniqueSolvedGridSlots(true))     {         var newItem = _itemsPool.GetItem();         var currentItem = solvedGridSlot.Item;          newItem.SetWorldPosition(currentItem.GetWorldPosition());         solvedGridSlot.SetItem(newItem);          itemsToHide.Add(currentItem);         itemsToShow.Add(newItem);          _itemsPool.ReturnItem(currentItem);     }      foreach (var specialItemGridSlot in solvedData.GetSpecialItemGridSlots(true))     {         var item = _itemsPool.GetItem();         item.SetWorldPosition(_gameBoardRenderer.GetWorldPosition(specialItemGridSlot.GridPosition));          specialItemGridSlot.SetItem(item);         itemsToShow.Add(item);     }      return new IJob[] { new ItemsHideJob(itemsToHide), new ItemsShowJob(itemsToShow) }; }

Получившийся результат:

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

Так как изначально логика была разделена на слои и не было жёсткой привязки к Unity, перенести удалось практически весь код, реализовав только логику отрисовки игрового поля в терминале. Для реализации асинхронности в Unity проектах я использую UniTask, а он помимо всех плюсов, которые я описал в своей предыдущей статье, имеет ещё и .NET Core версию и доступен как nuget пакет. Всё это вкупе, позволило реализовать версию для терминала всего за один вечер.

Вот так тот же уровень выглядит в терминале:

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

Например, обработка способа ввода. В начальной реализации вся логика была скрыта в классе Match3Game, который сам описывал логику взаимодействия с игровым полем получая интерфейс IInputSystem. Но если мы посмотрим на интерфейсы ввода с клавиатуры и мыши, то заметим, что у них мало общего.

public interface ITerminalInputSystem {     event EventHandler<ConsoleKey> KeyPressed;     event EventHandler Break;      void StartMonitoring();     void StopMonitoring(); }

public interface IUnityInputSystem {     event EventHandler<PointerEventArgs> PointerDown;     event EventHandler<PointerEventArgs> PointerDrag;     event EventHandler<PointerEventArgs> PointerUp; }

А так как логика в классе Match3Game опиралась на управление при помощи пальца или мыши, появились лишние проверки, которые при управлении с клавиатуры вовсе не нужны. Например, проверка и блокировка диагонального перемещения элементов, что с клавиатуры сделать невозможно. Конечно, можно и на базе IUnityInputSystem реализовать управление с клавиатуры, как я сначала и сделал, но выглядело это как костыль. В итоге было решено сделать класс Match3Game абстрактным и вообще выпилить из него интерфейс IInputSystem, предоставив возможность самому менять местами элементы игрового поля вызывав необходимый метод.

В итоге, как вы уже могли догадаться, всё это вылилось в разработку кроссплатформенной библиотеки, которую можно использовать для создания Match-3 игр.

Библиотека распространяется под лицензией MIT. Поэтому не стесняйтесь использовать её в своих проектах. А все исходники, примеры и документацию можно найти на GitHub.

Ах да, чуть не забыл. Во время публикации пакета на площадке OpenUPM выяснилось, что все пакеты собираются с использованием старой версии npm, отчего директория Match3.Core моей библиотеки, просто не попала в пакет. Но связавшись с автором он обновил npm до актуальной версии. Кто бы мог подумать, что простое тестовое может внести столько вклада в open source сообщество?

А как вы относитесь к тестовым заданиям?