Ambush! — быстрая дуэльная игра о боевых построениях и захвате фишек противника. Когда-то один из членов нашей команды создал настольную версию этой игры, а в рамках студенческого проекта в ФИИТ мы решили превратить её в полноценную компьютерную с мультиплеером. Рассказываем, почему выбрали не Unity, а Godot, что учились делать впервые без опыта и с какими проблемами столкнулись.

О проекте

Ambush! — это компактная стратегическая игра для двух игроков. Каждый из них по очереди ставит фишки на квадратное поле, чтобы составить комбинации, указанные на картах, и захватывать этими картами фишки соперника. 

В рамках проекта мы поставили цель разработать MVP цифровой версии игры. Для этого адаптировали настольные механики под формат компьютера и реализовали сетевой мультиплеер через Steam. В качестве движка решили использовать не привычный нам Unity, а Godot. Он недавно получил новую волну сторонников и активно развивается.

В 2023-2024 годах количество разработчиков, использующих Godot, значительно возросло. Многие это связывают с тем, что его самый популярный конкурент — Unity — резко поменял условия своей лицензии и ввёл оплату за каждое скачивание игры. Вот неплохой источник о том, как поменялась ситуация в 2026-м.

К тому же, движок стал более популярен на YouTube. Например, крупный в инди-сфере канал с туториалами по игровым движкам, Brackeys, полностью переключился с Unity на Godot.

А ещё, создатель настольной игры, которую мы решили переделать в цифровую, участвовал на Godot в Game Jam, и оказалось, что на нём гораздо приятнее писать, чем на Unity.

В команде проекта было 2 человека, которые совмещали по две роли:

• Один — геймдизайнер и программист;

• Вторая — художник и тестировщик.

Также мы приглашали потестировать игру нескольких друзей.

Правила игры

Нужно размещать свои фишки так, чтобы собирать комбинации, которые указаны на картах, и захватывать фишки врага. Чтобы победить в игре, необходимо выставить все свои фишки первым.

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

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

Разные фишки по-разному размещают на поле. Лагерь всегда находится в углу карты, он  неподвижен. Щит можно разместить только на соседних клетках вплотную с другой вашей выставленной фишкой, лук — в любую клетку по диагонали рядом с вашей фишкой, меч — по-вертикали или горизонтали с другой вашей фишкой.

Когда разыгрывают карту, по комбинации можно захватить чужие фишки: заменить фишки соперника своими по указанной схеме, если они стоят рядом и в комбинации участвует ваша фишка указанного типа. Положение букв на карте обозначает требуемое положение фишек на поле. Если позиция «AAB», то для захвата нужно, чтобы в тройке было две стоящие рядом фишки одного типа и одна — другого. Можно совершить «цепочку»  захватов по этой карте за ход, если в процессе захвата вы смогли заменить фишку соперника на свою и сложить ещё одну комбинацию с сыгранной карты. Фишки соперника уйдут в его резерв, а карта потратится. Лагерь также может участвовать в комбинациях, но его нельзя захватить.

Если вы выставили все фишки из своего резерва — вы победили!

Этапы реализации проекта

Шаг 1. Собрали референсы

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

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

Основными референсами стали Hive, Root и Hearthstone. Все эти игры очень хороши в боевых построениях, стратегических и тактических планах по захвату фишек или клеточек врагов. Мы хотели взять лучшие практики этих игр и избежать недостатков.

Главным референсом для игрового процесса стала Hive. Мы хотели сделать похожую игру, но со скрытой информацией и возможностью для участников играть более интуитивно — меньше продумывать свои шаги в деталях. Референсы Hearthstone и Root послужили отличными примерами, как перевести настольную игру в цифровой формат.

Шаг 2. Оформили мудборд

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

На него мы поместили:

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

• текстуры пергамента и старой бумаги — для оформления карточек и интерфейсных фреймов;

• круглые фишки с текстурой дерева или камня, с рунами и грубой краской;

• символы, будто вырезанные ножом на дереве или камне — для их стилизации на фишках и картах;

• изображения с приятным сочетанием зеленого, жёлтого и коричневого — цвета игры;

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

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

Мудборд помог нам закрепить единое понимание стиля и заранее договориться о примерном визуале игры. К нему мы обращались при работе над графикой, с ним было проще принимать решения и избегать визуальной разобщённости.

Шаг 3. Посоветовались с экспертами

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

Геймдизайн

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

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

UI–дизайн

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

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

В остальном мы прислушались к рекомендациям: построили дерево пользовательских сценариев 一 схему, которая описывает возможные действия игрока и их визуальное сопровождение. Это помогло нам систематизировать интерфейс, сделать его более предсказуемым и удобным.

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

Шаг 4. Отрисовали ассеты

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

Чтобы понимать объём работы, сначала создали приблизительный макет в Figma из серых прямоугольников и белых фреймов. Это помогло, но все люди, которые заходили в проект, думали, что страница просто не загрузилась.

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

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

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

Шаг 5. Разработали механики

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

Перенос настольной версии

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

Единственное, что действительно вызвало проблемы, это дрэг-н-дроп. Стандартный функционал дрэг-н-дроп в Godot не предусматривает, что перетаскиваемая вещь будет двигаться за курсором, пока тот зажат. Также только один элемент интерфейса может «слышать» курсор, поэтому элемент поля не сможет его увидеть, пока курсор не отпустит фишку. Человек, писавший этот модуль, прошёл через стадии отчаяния, депрессии и принятия, но перенос фишек на поле всё же сделал. Решение оказалось простым: нужно было запретить фишке слышать курсор, пока он его держит. 

Архитектура и иерархия объектов

Было несколько забавных моментов.

Объект «Карта» у нас лежит в «Хранителе карт», «Фишка» 一 в «Хранителе фишек». Если вы подумали, что объект игрока лежит в хранителе игрока, то, увы, нет. ? «Хранитель игрока» содержит «Хранитель карт» и «Хранитель фишек». Звучит как какая-нибудь иерархия из научной фантастики.

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

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

Для решения этих проблем мы два раза переписывали логику, после чего они решались, но появлялись новые — в основном, с мультиплеером и системой, которая оказалась неповоротливой для него.

Шаг 6. Реализовали мультиплеер

Для этого мы использовали Steam API.

Элементы нашей игры 一 объекты, они сообщают (сигнализируют), когда что-то случается, например, если переместили фишку или активировали карту. Нам предстояло найти способ для передачи оповещений о происходящем от объектов второму игроку, так как ему тоже интересно, что делает соперник. При реализации этой возможности мы столкнулись с особенностями сетевой синхронизации.

С сетью наша схема работала не так, как мы ожидали. Она не могла понять, какой именно объект что-либо сообщает, потому что мультиплеер подразумевает два компьютера и два контекста. Десятки маленьких объектиков: фишки, ячейки на поле, карты — и все на одно лицо. Они не могли просто передать себя по сети, поэтому для каждого из них мы создали  универсальный идентификатор. С ним другая сторона видела не просто сообщение «я камушек», «я на ячейке», а какой именно камушек и на какой он ячейке. 

С внедрением идентификатора нам пришлось пересмотреть структуру игры, но это позволило синхронизировать происходящее между игроками. 

С какими проблемами столкнулись на этом этапе? 

Для начала игры всем нужно выдать карты и фишки. При входе или перезапуске игроки подключаются не одновременно — кто-нибудь всегда первый. Игра «приходит» к нему и отдаёт объекты, потом идёт ко второму игроку и передаёт объекты ему. Иногда случается, что второй игрок в этот момент ещё не загрузился и не понимает, что ему выдали и зачем, а после загрузки игра считает, что ему уже всё передано, хотя это не так. Решить эту проблему можно рестартом игры.

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

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

Результат и планы на будущее 

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

В долгосрочной перспективе хотим расширить возможности игры: 

• добавить одиночный режим с ИИ-противником, чтобы в Ambush! можно было играть без напарника; 

• реализовать режим Hotseat для игры вдвоём за одним экраном; 

• создать интерактивный туториал, который проведёт игрока через пробную партию, объясняя правила на практике. 

Немного выводов про Godot от программиста и дизайнера игры

Интерфейс у Godot мне показался более приятным, чем у Unity. 

Для Godot сделали специальный свой язык, GDscript, который позволяет избежать многословного бойлерплейта, который часто получается с С#.

Но, вообще, это всё мелочи, главное — что в деталях функционал Godot мне показался более сподручным и продуманным.

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

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

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

Если у вас остались вопросы по Unity, Godot или игре — задавайте их в комментариях.