Вернуться к блогу
О том, как родилась идея Last Run – Last Token, почему обычный спортивный забег превратился в хоррор и как пятеро сотрудников Amiga за месяц решились сделать 3D-игру практически с нуля, мы подробнее рассказали в первой части истории о создании 3D-игры с помощью ИИ.
Теперь – под капот. Как выбрать движок, если ты не геймдев-разработчик? Как превратить сгенерированную модель в нормальный игровой объект? Как заставить монстра действительно преследовать игрока? Что делать, если AI написал код, но код не сделал то, что от него ждали? И почему скрипт, который должен был просто расставить деревья, в итоге начал сажать их прямо на дорогу?
В этой части разбираем техническую сторону Last Run – Last Token: Unity, Blender, 3D-ассеты, анимацию, C#, Git, вайбкодинг, автоматизацию и все те маленькие проблемы, из которых на самом деле и состоит разработка игры.
Для игрового движка мы выбрали Unity. Не потому, что команда хорошо в нём разбиралась, а скорее наоборот. Нам нужен был инструмент, в котором можно быстро собрать 3D-сцену, импортировать модели, настроить персонажа, камеру, окружение, препятствия и базовую игровую логику.
Плюсом была огромная экосистема Unity: документация, туториалы, готовые решения и ответы на типовые ошибки. Для полноценной разработки можно долго выбирать технологический стек и сравнивать разные движки. У нас такой роскоши не было: до дедлайна оставался месяц, поэтому нужен был инструмент, в котором можно быстро разобраться и сразу начать собирать прототип.
Unity стал нашей общей точкой сборки. Персонаж создавался отдельно, монстр отдельно, деревья и лавочки – отдельно. Но в конце всё должно было оказаться в одной сцене и каким-то образом работать вместе.
Отдельные модели и скрипты становятся игрой после сборки сцены, настройки и проверки маршрута.
И здесь мы впервые столкнулись с главным правилом 3D-разработки: отдельно работающие детали ещё не означают работающую игру.
Первый технический сюрприз оказался очень простым: можно сделать красивую модель, посмотреть на неё в Blender и решить, что всё готово. А потом импортировать её в Unity – и обнаружить, что она огромная, стоит боком, потеряла цвета или вообще не вписывается в сцену.
Поэтому почти каждый объект проходил один и тот же цикл: создать или сгенерировать модель, проверить внешний вид, импортировать в Unity, настроить масштаб и материалы, поставить в сцену, а затем снова проверить. И именно последний пункт повторялся особенно часто.
Модель могла отлично выглядеть сама по себе, но оказаться слишком большой для игрока. Дерево могло красиво смотреться в лесу, но полностью перекрывать дорожку. Объект мог нормально выглядеть при одном освещении и практически исчезать при другом.
В итоге мы довольно быстро перестали считать генерацию финальным результатом. AI помогал получить основу, а Unity показывал, работает ли эта основа в реальной игре.
Это, пожалуй, один из главных технических выводов проекта: в 3D нельзя оценивать ассет только по тому, как он выглядит в генераторе или редакторе. Важны конечный контекст – сцена, камера, масштаб, свет и взаимодействие с игроком.
Главный персонаж был одним из самых заметных элементов игры. Модель мы получили с помощью Hunyuan, и сначала казалось, что большая часть задачи уже решена. После генерации её всё равно пришлось немного доработать и перекрасить вручную. Затем появился следующий вопрос: как заставить этого персонажа нормально бегать?
Сначала мы попробовали настроить анимацию вручную, покадрово выставляя позы. И очень быстро поняли, почему анимация – отдельная профессия. Даже простой бег начинает выглядеть странно, если немного ошибиться с положением рук, ног, корпуса или темпом движения. Персонаж вроде бы должен бежать, а получается что-то среднее между быстрым шагом и попыткой убежать от собственной тени.
Для полноценной разработки можно было бы потратить на это гораздо больше времени. Но у нас был хакатон, поэтому мы нашли онлайн-сервис, который позволял загрузить модель, автоматически добавить скелет и применить готовые анимационные пресеты. Перед стартом персонаж оставался в позе покоя, а затем переходил в анимацию бега.
Для нашего формата это оказалось гораздо эффективнее ручной анимации. Мы не пытались героически сделать всё самостоятельно, а искали самый короткий путь до рабочего результата.
И здесь хорошо проявилась одна из главных особенностей AI-assisted development: ценность не всегда в том, что нейросеть делает задачу вместо тебя. Иногда она просто помогает быстрее найти рабочий pipeline и не потратить половину проекта на то, что не является его главной задачей.
С монстром была похожая история, но с другим фокусом. Сделать модель – одна задача. Сделать так, чтобы игрок действительно испугался, – совсем другая.
Баг должен был не просто стоять в лесу и выглядеть страшно. Он должен был быть полноценной игровой угрозой: появляться в нужный момент, двигаться по маршруту и создавать ощущение погони.
Поэтому мы проверяли, насколько хорошо он виден за спиной игрока, не слишком ли он большой или маленький, не теряется ли в окружении, как выглядит при разном освещении и достаточно ли быстро приближается. И самое главное – действительно ли хочется от него убежать.
Тут особенно хорошо проявилась разница между 3D-моделью и игровым объектом. Страшный монстр в Blender совершенно не обязательно будет страшным монстром в игре. Всё решают камера, расстояние, освещение, скорость, силуэт и момент появления.
Иногда мы меняли не самого Бага, а всего лишь его положение относительно игрока – и сцена сразу становилась намного напряжённее.
Дальше началась самая рутинная часть. Для локации нужны были деревья, кусты, фонари, лавочки, урны, камни, барьеры, конусы, поваленные деревья и другие детали, которые превращают пустую 3D-сцену в настоящий парк.
Сначала казалось, что можно просто постепенно расставить всё руками. Но быстро стало ясно: вручную проще расставить отдельные объекты – фонари, лавочки, урны, барьеры и конусы. А вот лес из деревьев и кустов при такой карте мог занять весь оставшийся месяц.
Поэтому автоматизировать решили именно создание леса.
Для Unity мы написали C#-скрипт, который позволял массово размещать деревья и кусты на сцене. Первые модели деревьев и кустов появились благодаря Python-скриптам для Blender.
Работало. Почти.
Проблема была в том, что скрипт прекрасно понимал свои правила, но совершенно не понимал нашу игру. Он не знал, где проходит дорожка, где находится озеро и что игроку вообще-то нужно где-то пробежать.
Поэтому часть деревьев и кустов оказывалась там, где им совершенно не следовало быть.
В итоге мы пришли к гибридному варианту: скрипт массово расставляет объекты, а человек проверяет результат и вручную чистит проблемные места.
И это оказалось одним из самых удачных решений проекта. Мы не пытались заставить автоматизацию сделать всё идеально. Ей отдали рутинную часть, а себе оставили контроль над результатом.
Для хакатона это было оптимальным вариантом: скрипт экономил время, а ручная проверка не давала уровню превратиться в случайный лес, через который невозможно пробежать. После автоматической расстановки сцену пришлось оптимизировать: вручную настроить дальность прорисовки и удалить лишние детали за пределами поля зрения игрока.
На бумаге маршрут выглядел просто: старт, дорога, препятствия, монстр, финиш. В игре всё оказалось сложнее.
Игрок должен понимать, куда бежать. Препятствия должны мешать, но не блокировать путь полностью. Нельзя оставлять места, где персонаж застревает, и нельзя давать слишком много очевидных срезов. Финиш должен быть заметным, а монстр – создавать давление, но не превращать прохождение в случайную борьбу с багами.
Мы довольно быстро поняли: красивая карта не равна хорошему уровню. Особенно много времени ушло на границы трассы: их отложили на поздний этап, а затем пришлось подгонять под извилистую дорогу и масштаб, в котором нейросеть выдала объекты. После добавления границ персонаж начал застревать в неожиданных местах – и на дороге, и за её пределами. Поэтому маршрут снова проходили вручную, искали проблемные точки и правили их.
Хороший уровень появляется после тестовых забегов. Мы пробегали маршрут, смотрели, где застреваем, передвигали объекты и снова запускали игру. Потом понимали, что теперь слишком легко, добавляли препятствие и снова тестировали.
Это была одна из тех частей работы, где никакой генератор не мог заменить человека. Только реальный забег показывает, удобно ли играть.
Отдельным приключением стал Git. С обычным кодом всё более-менее понятно: появился конфликт – открываешь файл, смотришь изменения и разбираешься.
В Unity всё интереснее. Изменения происходят не только в коде. Есть сцены, префабы, метафайлы, настройки и другие элементы проекта, и далеко не всё удобно объединять вручную.
В какой-то момент два человека могли одновременно изменить одну часть проекта – и вместо новой механики команда получала новый квест: «Почему у меня вчера всё работало, а сегодня нет?»
Поэтому для будущих проектов мы бы сразу жёстче разделяли зоны ответственности: отдельные сцены, понятную структуру папок, правила работы с ассетами и чёткую договорённость, кто отвечает за финальную сборку.
Это кажется скучной организационной мелочью ровно до того момента, пока до дедлайна не остаётся несколько часов.
Четыре изменения в процессе, которые команда учтёт в следующем игровом проекте.
За время проекта мы использовали нейросети в самых разных задачах. Лучше всего они помогали там, где нужно было быстро выйти из нуля: получить основу 3D-персонажа, сгенерировать варианты моделей, улучшить Blender-скрипты, получить C#-код для Unity, разобраться с ошибкой, попробовать несколько вариантов реализации, поправить материалы или найти визуальное решение.
Отдельно AI помогал с созданием видео для трейлера. Там тоже было важно не просто получить готовый результат, а несколько раз попробовать разные варианты и выбрать тот, который лучше вписывался в общую историю игры.
Особенно это помогало людям без опыта в конкретной области. Человеку, который никогда не писал C# для Unity, гораздо проще начать с запроса к ИИ, получить первый вариант скрипта, запустить его, увидеть ошибку и уже разбираться с конкретной проблемой.
То же самое работало с Blender и 3D-моделированием. AI не превращал нас в специалистов за один вечер, но заметно сокращал расстояние между «я вообще не знаю, как это сделать» и «так, у меня есть первый вариант, теперь давайте посмотрим, почему он не работает».
Для хакатона эта разница огромна. О том, где ИИ ускоряет работу, а где ответственность остаётся за человеком, подробнее рассказываем в статье «Что ИИ может заменить в разработке, а что не заменит».
При этом были задачи, где нейросети практически сразу передавали мяч обратно нам.
Например, проверить масштаб объекта в сцене, понять, хорошо ли выглядит анимация именно в движении, оценить читаемость монстра через игровую камеру, проверить удобство маршрута, найти места, где игрок застревает, разобраться с конфликтами Unity, собрать финальную сцену, настроить атмосферу и протестировать прохождение целиком.
Можно сгенерировать код, но только запуск покажет, работает ли он. Можно получить красивую модель, но только Unity покажет, подходит ли она для конкретной сцены. Можно попросить AI придумать препятствия, но только человек, который реально пробежит маршрут, поймёт, интересно это или бесит.
Поэтому наш подход получился довольно простым: AI генерирует и подсказывает – команда проверяет и принимает решение.
Если результат не работает, его приходится переделывать. И иногда переделывать несколько раз.
ИИ ускорял подготовку вариантов, но качество игрового результата определяли ручные тесты и решения команды.
Самая большая опасность хакатона – не баги. Самая большая опасность – идеи.
Каждая новая идея звучит отлично: «А давайте добавим ещё разрушения». «А давайте сделаем несколько видов монстров». «А давайте добавим больше препятствий». «А давайте ещё вот этот эффект».
Проблема в том, что за одной такой фразой обычно прячется ещё десять технических задач.
Поэтому в какой-то момент мы зафиксировали MVP – минимальную рабочую версию игры. В ней должно было быть только самое необходимое: персонаж бежит, монстр преследует, есть понятный маршрут, препятствия, финиш и цель, которую понимает игрок. Главное – игру можно пройти от начала до конца.
Всё остальное – свет, UI, меню, разрушения, эффекты и полировка – добавлялось уже после того, как базовая версия заработала.
В первый билд вошёл проходимый игровой цикл, а свет, звук, интерфейс и эффекты команда оставила на следующий этап.
Именно это решение в итоге позволило нам успеть. Такой подход используют и при разработке MVP цифрового продукта: сначала проверяют ключевой сценарий, а затем расширяют функциональность.
Сначала мы сделали игру, которая работает. Потом начали делать игру, которая выглядит хорошо. А уже потом – игру, которую хочется пройти.
За месяц мы прошли довольно длинный путь: от отдельных 3D-моделей к полноценной сцене, от сцены – к маршруту, от маршрута – к игровому процессу, от первого скрипта – к автоматизации, от идеи монстра – к реальной погоне. И всё это пришлось собрать в один работающий проект.
Last Run – Last Token стала для нас экспериментом в формате AI-assisted development. Мы использовали нейросети для генерации моделей, поиска решений, работы с кодом и скриптами, визуальных задач и создания отдельных материалов для проекта. Unity стал основной средой разработки, Blender – инструментом для 3D-объектов, а автоматизация помогла не утонуть в рутинной работе.
Но главный вывод оказался совсем не про инструменты.
ИИ действительно может сильно ускорить создание игры. Но игру он за вас не соберёт.
В 3D недостаточно получить красивую модель – её нужно импортировать, настроить, поставить в сцену и проверить. Недостаточно получить код – его нужно запустить. Недостаточно сделать красивую карту – по ней должен нормально пробежать игрок. Недостаточно создать монстра – он должен действительно работать как часть игры.
Именно поэтому самый ценный результат нашего эксперимента – не набор сгенерированных ассетов.
Мы действительно сделали игру.
Пять человек. Один месяц. Почти без геймдев-опыта.
И да – в неё можно поиграть.
Если хочется увидеть, чем закончился эксперимент, посмотрите на итоговую игру.
Мы пришли проверить, насколько далеко можно зайти с ИИ за один месяц.
В итоге дошли до работающей 3D-игры. И, кажется, это был только первый забег.
