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

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

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

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

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

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

В общем, задача показалась интересной. Было решено реализовать космос, добавив продвинутого функционала, и разбавив это всё базовым. Я бы и не подумал, что только алгоритмов заполнения игрового поля мне в голову придет 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 сообщество?

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