Вернуться к блогу
Hola, Amigos! Можно ли за месяц сделать 3D-игру, если в команде пять человек, а полноценного опыта в геймдеве ни у кого нет? Мы решили проверить это на себе.
Каждый год AGIMA проводит RUN IT – спортивный фестиваль для ИТ-сообщества. Команды приезжают пробежать дистанцию, пообщаться с коллегами и показать свои активности на площадке.
В этот раз частью RUN IT стал AI-хакатон: нужно было придумать и собрать проект с использованием искусственного интеллекта, который можно показать гостям фестиваля 5 июля.
Так у нас появилась задача: за месяц собрать небольшую 3D-игру, которую можно показать гостям фестиваля или забега. Сначала это звучало как понятная идея про забег в парке: игрок выходит на маршрут, бежит к финишу, вокруг – дорожки, лес и атмосфера загородной локации. Визуальную основу мы взяли из Мещерского парка, знакомого многим участникам RUN IT. А уже в процессе идея начала темнеть: маршрут превратился в хоррор-пространство, появился монстр, а задачей игрока стало добежать до спасительного финиша.
Изначально все выглядело вполне реалистично. Наша команда каждый год участвует в RUN IT, поэтому мы хорошо знаем атмосферу фестиваля и примерно понимали, что хотим показать. Проблема была только в одном: никто из нас толком не умел делать игры.
На видео – уже готовая игра. Но чтобы понять, как мы до нее добрались, придется вернуться примерно на месяц назад.
Наша команда была совсем не похожа на классическую геймдев-студию. Нас было пятеро, и только один человек был разработчиком. Остальные пришли в эту историю из тестирования, системного анализа, бухгалтерии и рекрутинга.
Олег – тестировщик и капитан команды. Он занимался монстром, его маршрутом и вообще отвечал за то, чтобы происходящее в игре было не просто набором объектов на экране, а хоть немного напоминало историю с напряжением.
Толя – фронтенд-разработчик и техлид. Он давно хотел попробовать себя в геймдеве, поэтому взял на себя Unity, главного персонажа, анимацию, сборку и все то, что коротко называют «интеграцией», хотя на деле это отдельный квест.
Игорь – системный аналитик. На нем была природная часть локации: деревья, кусты и фургон на финише. Его участок быстро превратился в эксперимент с вайбкодингом и генерацией объектов с помощью ИИ.
Ксюша – бухгалтер. Она с нуля осваивала Blender и создавала окружение: лавочки, фонари, урны, барьеры, конусы, поваленные деревья и другие детали парка.
Рита – рекрутер. Она помогала с презентацией, таблицей задач, меню, трейлером и дополнительными атрибутами для игры.
Хотя на старте мы распределили роли иначе, в процессе все перемешалось. Для игры нужны были люди с очень разными навыками, поэтому фактические зоны ответственности быстро стали шире стартового плана: кто-то помогал с моделями, кто-то с меню, кто-то с презентацией, а кто-то забирал задачу, которая в этот момент горела сильнее остальных.
Иллюстрация представляет команду из пяти участников, которая собралась для создания игры Last Run – Last Token
Пять человек – шесть направлений: главный персонаж, монстр, локация, окружение, презентация и финальная сборка. Звучит как завязка хоррора, но именно так все и началось.
«Я вообще не был геймдев-разработчиком. Поэтому в какой-то момент пришлось разбираться не только с тем, как сделать монстра, но и с тем, как вообще устроена игра. Самое интересное – ты вроде бы уже что-то сделал, а потом понимаешь, что оно никак не связано с остальными частями», – вспоминает Олег.
Название появилось раньше игровой механики.
До финального варианта мы успели накидать целый список названий: Ctrl C + Ctrl V, «Не оглядывайся», «Дыши в спину», «Сорванный пульс», «Пятый круг». Остановились на Last Run – Last Token: в названии сошлись забег, ограниченный ресурс и ощущение дедлайна.
А уже потом под название начала складываться игровая механика. В игре появился TOKEN – индикатор состояния игрока: пока выносливость есть, полоска с токеном подсвечивается зеленым, а когда силы заканчиваются – загорается красным. Так состояние игрока стало видно прямо в интерфейсе.
Ближе к дедлайну это совпадение стало особенно заметным: название работало уже не только для игры, но и для процесса ее создания.
Самое сложное выяснилось не сразу. В начале нам казалось, что месяц – это вполне рабочий срок: задача небольшая, есть ИИ, Unity, Blender и понятный дедлайн. Но ближе к финалу стало понятно, что мы не подрассчитали:
Поэтому проект существовал где-то между обычными задачами, короткими окнами после работы и попытками успеть сделать еще хотя бы одну вещь перед сном.
Первое время мы не думали, что точно не успеем, но понимали: такой риск есть. Поэтому уже на старте держали в голове приоритеты, а к середине проекта стало ясно: часть задумок придется сокращать. Ближе к финалу резать пришлось еще жестче.
Главный принцип сформулировали просто: сначала рабочая версия, потом красота.
Проблема была в том, что каждый раз, когда казалось, что минимум уже готов, находилась новая проблема. Персонаж бежит – отлично. Но куда? По локации. А локация пока выглядит как несколько кубов. Хорошо, добавляем деревья. Деревья есть, но теперь хочется кусты. Появились кусты – а вокруг все равно пусто. И так практически с каждым элементом.
Отдельная история – окружение. Если вы никогда не открывали Blender, идея «сделать несколько лавочек и фонарей» звучит достаточно безобидно. На практике это довольно быстро превращается в вопрос: почему эта штука теперь стоит вверх ногами и как вообще вернуть ее обратно?
Ксюша освоила Blender буквально по ходу проекта. Причем ей пришлось не просто научиться двигать объекты, а создать множество деталей для локации: готовые ассеты не использовались, все собирали вручную и с помощью ИИ.
«Я сначала вообще не понимала, что делаю. Мне казалось, что сейчас быстро разберусь и сделаю лавочку. Потом выяснилось, что на одну лавочку можно потратить гораздо больше времени, чем я ожидала. Но когда первый объект наконец появился в игре и нормально там стоял, это было очень приятно», – рассказывает Ксюша.
В какой-то момент процесс стал похож на конвейер: придумали объект, сделали его, проверили в игре, поняли, что он выглядит странно, переделали и пошли дальше. Так постепенно вокруг главного персонажа появился настоящий парк.
Фургон на финише маршрута в ранней версии локации игры Last Run – Last Token.
И именно в такие моменты становилось понятно, что игра действительно начинает складываться.
Как обычный забег превратился в хоррор
Сюжет мы разделили на четыре акта.
Сначала – идиллия. Солнечный парк, трасса, баннеры RUN IT, стартовая арка и финишный фургон впереди.
Дневная стартовая сцена игры: герой начинает забег у арки RUN IT в парке.
Потом происходит сбой. Стартовый сигнал превращается в помехи, изображение начинает глючить, привычный мир постепенно перестает быть таким уж привычным.
Следом начинается трансформация. RUN IT превращается в Last Run – Last Token, атмосфера меняется, а парк из места для спортивного забега превращается в довольно неприятное место для прогулки.
И наконец наступает катастрофа: день сменяется ночью, вокруг появляются разрушения, фонари гаснут, а за игроком начинает охотиться монстр.
Так у нас появился не просто бегун, а небольшая история с завязкой, развитием и финальной целью. В итоге мы получили 3D-хоррор-игру, а не просто симуляцию забега.
Схема основных элементов игры: маршрут, персонаж, монстр, препятствия и финиш.
С монстром получилась отдельная история. Изначально он должен был выглядеть иначе. Но когда появился главный персонаж, стало понятно, что противник должен быть визуально не слабее. Тогда появилась идея сделать монстра Багом.
В английском языке bug – это одновременно жук и ошибка в системе. Для нашей истории это оказалось почти идеальным совпадением.
Мир игры начинает ломаться. Появляются глитчи. Система дает сбой. И этот сбой буквально превращается в живое существо, которое начинает преследовать игрока.
Сравнение ранней и финальной версий монстра Бага для игры Last Run – Last Token.
Так у Last Run – Last Token появился главный образ: не просто страшный монстр, а ошибка системы, которая вышла из-под контроля.
Сделать страшного монстра оказалось только половиной задачи. Вторая половина – заставить его вести себя как монстр.
Он должен был появляться в нужный момент, двигаться по маршруту и создавать ощущение, что игроку действительно нужно от него убежать. А если монстр просто ходит туда-сюда по лесу, пока игрок спокойно пробегает мимо, никакого хоррора не получается.
Олег как раз занимался этой частью и постоянно тестировал разные варианты поведения.
«Самое смешное, что сначала ты думаешь: ну хорошо, есть монстр, пусть идет за игроком. А потом начинаешь проверять и находишь миллион нюансов. Он может застрять, повернуть не туда, появиться слишком рано или вообще потерять игрока. И вот ты уже не делаешь страшную игру, а воспитываешь монстра», – говорит Олег.
При этом мы сохранили атмосферу RUN IT: стартовую арку, беговую тему и маршрут в парке. Просто знакомая дневная локация постепенно превращалась в хоррор-пространство.
Сцена погони: игрок бежит по маршруту, а монстр Баг преследует его через лес.
Отдельной частью эксперимента стал вайбкодинг: мы не пытались сначала изучить каждый инструмент до уверенного уровня, а быстрее переходили к практике. Формулировали задачу, получали от ИИ вариант кода, модели или решения, проверяли его в Unity, правили и снова пробовали. В этом смысле нейросети были не справочником и не волшебной кнопкой, а еще одним участником процесса, который помогал собирать отдельные части игры.
Разные нейросети и сервисы мы пробовали точечно – в основном там, где нужно было быстро получить рабочую заготовку: код для механик и поведения объектов, варианты 3D-моделей, идеи для ассетов и подсказки по интеграции в сцену. Это не было полноценным исследованием каждого инструмента: мы смотрели, что можно быстро встроить в игру, а что проще переделать вручную. Но каждый результат все равно проверяли руками: запускается ли сцена, не ломается ли логика и подходит ли объект под общий low-poly стиль.
Особенно хорошо это проявилось на объектах окружения. Игорь экспериментировал с генерацией деревьев, кустов и других элементов, а потом пытался понять, как все это нормально встроить в игру.
«Я не могу сказать, что у меня был какой-то четкий план. Скорее было: давайте попробуем вот так. Потом: а теперь давайте попросим ИИ сделать это. Потом смотришь на результат и думаешь – нет, это точно надо переделать. Но именно за счет такого подхода удалось довольно быстро получить то, на что вручную ушло бы намного больше времени», – рассказывает Игорь.
Поэтому результат редко подходил с первого раза: одни модели выбивались из стиля, другие приходилось менять по масштабу, а код – адаптировать под конкретную сцену.
И чем ближе был дедлайн, тем меньше оставалось времени на эксперименты.
Споры начались не потому, что команда не понимала задачу. Наоборот, идей было слишком много: визуал, механики, кат-сцены, дополнительные эффекты.
К середине проекта стало ясно: чтобы привезти на RUN IT рабочую версию, нужно перестать добавлять новое и довести основу – старт, маршрут, персонажа, препятствия, монстра, погоню и финиш.
Все остальное оставили в запасе: если хватит времени, вернемся к деталям.
Это было неприятно, потому что некоторые идеи правда нравились. Но дедлайну все равно, насколько сильно тебе хочется оставить красивую сцену или дополнительный эффект.
Когда базовая версия заработала, мы начали возвращать атмосферу: свет, разрушения, детали локации, интерфейс и другие элементы.
И тогда проект впервые начал ощущаться как настоящая игра.
Персонаж бежит по трассе. Перед ним препятствия. Сзади монстр. Впереди финиш.
Теперь уже действительно хочется понять, добежит он или нет.
Игрок преодолевает препятствия на маршруте; на экране видны индикатор выносливости и подсказки по управлению.
За несколько дней до RUN IT игра уже существовала. Но «существует» и «готова» – это совершенно разные вещи.
Нужно было проверить все целиком: как работает персонаж, как двигается монстр, не ломается ли локация, правильно ли запускается игра, работает ли меню, что происходит на финише. А еще у нас были презентация, трейлер и все то, что нужно было показать вместе с самой игрой.
И именно здесь особенно пригодился Толя, которому пришлось собирать воедино то, что до этого делалось разными людьми и в разное время.
«Самое сложное было не сделать какую-то одну конкретную вещь, а собрать все вместе. У каждого что-то работает отдельно, а потом ты соединяешь это в одну игру – и внезапно перестает работать вообще все. В такие моменты особенно хорошо понимаешь, зачем нужен человек, который отвечает за финальную сборку», – говорит Толя.
К финалу стало ясно: стабильная версия важнее любой ранней задумки, даже если она когда-то казалась обязательной.
Рита в этой истории тоже успела поработать практически во всех жанрах: помогала собирать презентацию проекта, следила за таблицей задач, занималась меню, трейлером и дополнительными элементами, которые должны были сделать игру цельной.
«Мне было интересно попробовать что-то новое, сложное и непривычное: презентацию, меню, трейлер, мелкие элементы для игры. Честно говоря, я до сих пор не до конца понимаю, что именно делала в некоторых моментах. Но в этом и был кайф: разбираешься по ходу и внезапно видишь, что твоя часть тоже стала частью игры», – смеется Рита.
Это хорошо описывает проект: роли были на старте, но в финале важнее оказалась готовность подхватить задачу.
5 июля мы приехали на RUN IT с работающей игрой.
1 месяц – от идеи до готовой игры
5 человек – команда проекта
1 разработчик – опыт разработки был только у одного участника
3D – формат игры
Unity и Blender – основные инструменты разработки
5 июля – день премьеры на RUN IT by AGIMA
Не с идеальной игрой. И даже не со всеми идеями, которые были у нас в самом начале.
Для нас главным результатом стала не только работающая игра, но и опыт, который показал: команда может собрать сложный проект, даже когда приходится учиться на ходу.
У нас не было секретного набора из десятка сложных инструментов. Проект вели как обычную командную разработку: Толя создал репозиторий на GitHub, участники работали в отдельных ветках, а изменения собирались через pull request. Для Unity сразу заложили базовую дисциплину: коммитили Assets, Packages и ProjectSettings, не тащили в репозиторий Library, Temp и Builds, а тяжелые файлы держали через Git LFS. Это помогло не потерять сборку, когда в проекте стало много моделей и ассетов. Основу проекта составили несколько понятных вещей:
Unity – основной движок, в котором собирали игру, настраивали персонажа, монстра, логику и сцену.
Blender – здесь создавали и дорабатывали 3D-объекты для окружения: лавочки, фонари, урны, барьеры и другие детали.
ИИ-инструменты – использовали для генерации отдельных элементов, работы с кодом и поиска решений там, где у команды не было готового опыта.
Вайбкодинг – помогал быстрее экспериментировать с кодом и проверять разные варианты реализации.
Навыки самой команды – тестирование, аналитика, дизайн логики, сборка, интеграция и, конечно, постоянные попытки понять, почему то, что пять минут назад работало, внезапно перестало работать.
Да. ИИ помогает с кодом, 3D-заготовками и поиском решений, но игру все равно нужно собирать, проверять и дорабатывать вручную.
Небольшую игру – да. В нашем случае из пяти участников только один имел опыт разработки, а остальные осваивали новые инструменты прямо во время проекта.
Для разработки Last Run – Last Token мы использовали Unity. 3D-объекты и окружение создавали и дорабатывали в Blender.
Вайбкодинг – подход к разработке, при котором разработчик формулирует задачи для ИИ и использует его для генерации и доработки кода, а затем проверяет и адаптирует результат.
Около месяца – с начала июня до премьеры на RUN IT by AGIMA 5 июля.
Для простой демоверсии – возможно, если есть человек, который понимает логику проекта и готов проверять результат. Для стабильной игры программист или технический специалист все равно сильно нужен.
В нашем случае основными инструментами стали Unity и Blender, а ИИ использовался для генерации отдельных элементов, работы с кодом и решения технических задач.
Главный вывод: небольшую игру можно собрать даже без классической геймдев-команды, если быстро делить задачи, проверять результат в движке и не держаться за каждую задумку.
ИИ помог ускориться на заготовках, коде и моделях, но не снял с нас интеграцию, проверку и финальную сборку.
И, наверное, именно это оказалось самым интересным: на месяц бухгалтер стал 3D-моделлером, системный аналитик – экспериментатором с ИИ, рекрутер – человеком, который делает игровое меню, а тестировщик – специалистом по воспитанию монстров.
Да, в процессе было напряжение: кто-то из ребят сильно переживал за сроки и результат, а у всех оставалось ощущение, что часть деталей еще можно доработать. Но мы довольны тем, что получилось: немного удивлены таким опытом и рады, что поучаствовали в этом хакатоне.
Мы пришли проверить, можно ли за месяц сделать игру.
Можно. Главное – однажды сказать: «А давайте попробуем». Результат наших стараний можете затестить сами – Last Run – Last Token.
На этом история не заканчивается. Во второй части разберем Last Run – Last Token изнутри: покажем инструменты, создание 3D-объектов, работу с персонажами, кодом и сценой. Расскажем, где ИИ действительно ускорил разработку, а где все пришлось делать самим.
