Всё началось с простого эксперимента: попросить нейросеть придумать игру. Не реализовать заранее написанное техническое задание, а предложить саму идею — такую, которую потом можно будет запустить и попробовать.
Первую модель я запомнил как Fable. В истории проекта действительно сохранился августовский коммит с подписью Claude Fable 5. Из этого разговора вырос «Некромант по найму»: игра, в которой мышью рисуешь линии, а скелеты выполняют связанные с ними приказы.
Сейчас в ней есть разные бойцы, постройки, оборона котла, натиски, рогатка, распознавание фигур, несколько ракурсов анимации и английская версия. Но всё это не лежало в первоначальном промпте. Мы постепенно придумывали, добавляли, пробовали и переделывали игру вместе с нейросетями. Иногда очередное улучшение действительно делало её интереснее. Иногда после большого объёма работы становилось понятно только то, почему прежний подход не работает.
Особенно хорошо это видно на двух вещах: меняющемся смысле нарисованной линии и скелете, которого никак не удавалось научить нормально ходить.
Сначала была линия
В первом сохранённом прототипе от 20 августа всё было значительно проще нынешней игры. Браузер, Canvas, арена, Котёл Душ и несколько скелетов. Игрок рисовал рунную линию, расходуя ману. Скелеты выбирали линию поблизости и патрулировали её. Линия постепенно исчезала; без работы подрядчики возвращались к котлу и прохлаждались.
Защита котла от волн врагов уже существовала. Но стратегии с дорогами, постройками, несколькими видами войск и рогаткой ещё не было. Даже поведение скелетов было другим: в ранней версии они ходили вдоль рисунка, а не занимали места в строю, как позднее.
Вместе с механикой появился и мир. Некромант открыл контору, скелеты стали работниками на аутсорсе, а нападающие — проверяющими из ада. Улучшения можно было оформить как поправки к трудовому договору. Так возникла удобная связь между правилами и юмором: ограниченное время жизни линии уже не выглядело абстрактным таймером. У договора просто заканчивался срок действия.
В ответе нашлось не только описание мира, но и конкретное действие: проводишь черту — и персонажи реагируют на твой рисунок. Его уже можно было реализовать и попробовать руками.
Но одного необычного жеста для игры оказалось мало.
Добавить возможностей проще, чем понять, зачем они нужны
Прототип быстро обрастал содержимым. Появились разные руны и противники, активные способности некроманта, души, ловушки, торговец, обучение и сюжетные картинки. Затем начался перенос на Godot.
У разработки с агентами есть соблазнительный темп. Можно сформулировать очередную идею и довольно скоро получить работающий вариант. Это помогает не застревать на обсуждении. Но одновременно становится очень легко нарастить больше механик, чем ты успел осмысленно проверить.
Наличие кода ещё не отвечает на вопросы игрока. Почему я должен нарисовать линию здесь? Что изменится, если я нарисую её иначе? Зачем мне сейчас вмешиваться, если оборона и так справляется? Можно сделать ещё одну способность и не приблизиться к ответу ни на один из этих вопросов.
В сентябре захотелось более стратегической игры: сложнее карты, больше армия, важнее положение бойцов. Однако просто заменить башни в tower defense на скелетов, стоящих вдоль временной линии, было недостаточно. Нужно было понять, что именно даёт рисунок — кроме необычного способа расставить защитников.
Так мы вернулись к исходной идее и поменяли смысл её главного действия.
Когда исчезновение линии стало приказом
Новый вариант получил рабочее название «По истечении договора». Пока линия существует, скелеты держат строй. Когда участок исчезает, связанные с ним бойцы уходят в атаку. Можно продлить договор, подрисовав линию, или расторгнуть его досрочно и выпустить отряд сейчас.
Раньше исчезновение в основном требовало восстановить то, что было. Теперь оно само становилось событием, которое можно использовать. Держать линию дольше означало сохранить оборону. Дать ей закончиться — освободить бойцов для атаки. У игрока появился выбор не только места, но и момента.
Это была одна из самых интересных дискуссий с моделями. Среди вариантов была линия, по которой просто поступают новые бойцы, и линия, удерживающая строй до истечения срока. В сохранившемся разборе Астра защищала второй вариант. Аргумент был предметным: если линия существует двенадцать секунд и поставляет по два бойца в секунду, её во многом можно заменить кнопкой «отправить двадцать четыре бойца». В варианте со строем срок действия задаёт отложенный манёвр.
Другие модели предпочли поставку. Но итоговое решение приняли в пользу строя и выпуска в атаку. Мне нравится этот эпизод именно отсутствием магии: несколько нейросетей не сошлись в единодушном ответе, а полезным оказался конкретный довод о механике.
Сам по себе такой довод, конечно, ещё не доказывает, что играть будет интересно. Он лишь объясняет, почему стоит сделать именно этот прототип и проверить его.
Сверху — ранний браузерный прототип, август 2026. Снизу — постановочный промокадр настоящего игрового движка на версии 0.3.0, октябрь 2026. Это сравнение этапов, а не демонстрация последней 0.4.0.
Условная схема: маршрут патруля превратился в построение с ограниченным сроком действия и выпуском приказа. Это объяснение механики, не игровой интерфейс.
Рогатка появилась из неудобного движения мышью
Дальше игра снова росла, но уже вокруг более определённого центра. Появились разные роли бойцов, найм и постройки, дороги и более сложные карты. Подрядчики, вахтёры и счетоводы давали возможность разделить удар, защиту и дальний бой.
Рогатка возникла из гораздо менее торжественного наблюдения: мышь хотелось тянуть в другую сторону. На словах можно долго объяснять, куда должен смотреть вектор атаки. Рука тем временем ожидает знакомого действия: оттянул назад — отпустил вперёд.
Эту гипотезу и попробовали. Затем вокруг рогатки появились сила натяжения, точный срыв по наведённому прицелу, замедление и отклик на удар. Стратегия стала требовать более активного участия: важно не только подготовить строй, но и вовремя им распорядиться.
Для меня это хороший пример того, как на самом деле меняется проект. Рогатка не была пунктом большого первоначального замысла. Она выросла из неудобства в уже работающей игре. После этого изменились и ощущения от боя, и требования к тому, насколько понятно игра показывает подготовку и результат приказа.
В последней на момент написания версии, 0.4.0-alpha, различаются уже и сами приказы ролей: основной натиск подрядчиков, подвижный сомкнутый фронт вахтёров и огневой вал счетоводов. Это продолжение той же идеи: одинаковый жест должен давать понятное действие выбранного отряда.
А потом скелету понадобилось пройти несколько шагов
С анимацией история оказалась гораздо мучительнее, чем можно предположить по отдельным красивым картинкам. Мы пробовали генерировать кадры, получать движение через видеомодели, делать скелетную анимацию, морфинг — в общем, заходили с разных сторон. По моим ощущениям, результат раз за разом получался уродливым.
Один кадр мог нравиться. Несколько кадров рядом тоже могли выглядеть убедительно. Но стоило включить цикл — персонаж менялся, подрагивал, ехал по земле или двигал ногами так, что лучше бы стоял на месте.
Трудность не сводилась к разрешению картинки или числу кадров. Нужно было одновременно сохранить самого персонажа, получить осмысленные фазы движения, удержать масштаб и точку опоры, замкнуть цикл и нормально перейти из покоя в ходьбу, а затем в удар. Небольшая ошибка в любой из этих связей превращалась в заметную странность.
В архиве остались очень узнаваемые попытки. Генерация по позам иногда давала почти одинаковые фигуры вместо разных фаз. Лист спрайтов лучше держал внешность, но хуже слушался конкретного движения. Перенос движения через видеомодель требовал согласовать композицию управляющего ролика и референса: иначе модель цеплялась за исходную картинку и не переносила нужное действие.
Риг тоже не оказался волшебной кнопкой. Персонажа можно аккуратно разрезать на части, связать костями, заставить их двигаться — и получить убедительную марионетку вместо убедительно идущего скелета.
Почему неподвижный ботинок иногда полезнее красивого кадра
Постепенно стало ясно, что нужно разделять две задачи: кто отвечает за движение и кто — за рисунок. Генеративной модели хорошо удавалось помогать с внешностью, но поручать ей одновременно идентичность персонажа, точную фазу шага и непрерывность всего цикла было ненадёжно. В одном из подходов движение задавал риг, а модель использовалась для художественной обработки уже подготовленных кадров.
Это не избавляло от технических ошибок. Например, в одной версии таз двигался, а меш ноги не следовал за ним должным образом. Ботинок описывал дугу относительно неверной исходной точки. В другой проблема была в темпе: персонаж перемещался по карте с одной скоростью, а его ноги изображали другую. Получались коньки.
Хорошая проверка для такой ошибки очень простая по смыслу. Пока стопа опирается на землю, она должна оставаться примерно на одном месте относительно земли. Если тело движется вперёд, стопа в локальных координатах персонажа должна уходить назад с соответствующей скоростью. Красивый силуэт не компенсирует нарушение этой связи.
Понадобились и отдельное управление стопой, и проверка переноса веса, и согласование темпа анимации с движением персонажа. В истории работ есть, например, переход к третьей кости ноги — щиколотке: ботинок перестал быть просто продолжением голени и получил возможность сохранять собственный угол к земле.
Архивное сравнение v5 и v6. Это два соседних этапа доработки, а не «самая первая попытка» и не сравнение всех использованных моделей.
Важна и ловушка автоматических проверок. Если оценивать только стабильность изображения, почти неподвижная фигура может выглядеть замечательным результатом: ничего не скачет, пропорции не меняются. Только она не идёт. Значит, вместе со стабильностью нужно проверять наличие самого движения и соответствие его назначению.
Для меня это оказался очень наглядный урок: метрика должна ловить нужную ошибку. Отсутствие дрожания ещё не означает хорошую походку.
Что изменилось с Астрой
Перелом я запомнил так: после множества неудачных вариантов я попросил Астру просто улучшить анимацию — и в первый же заход получил движение, которое наконец воспринималось как нормальное и качественное. По моему пониманию, основой была скелетная анимация. Позже пришла следующая заметная итерация — развороты персонажей.
К тому моменту в проекте уже накопились персонажи, риги, инструменты и неудачные пробы. Астра работала с этим материалом, а дальнейшую доводку продолжали разные агенты. Но именно тот заход я запомнил как первый действительно хороший результат.
Практически полезным оказалось то, что задача стала решаться через устройство движения: опору, геометрию ноги, темп и переходы. Можно было обсуждать уже не только «выглядит плохо», но и конкретно показывать, где ботинок скользит, почему меняется рост и что происходит на первом кадре после остановки.
Одинаковые выбранные фазы архивного листа до и после художественной обработки. Движение задано ригом; после обработки приходится снова проверять позы, чтобы улучшение рисунка незаметно не изменило шаг.
Повернуть картинку оказалось недостаточно
Когда основная походка стала приемлемой, хорошо проявилась следующая проблема: персонажи могли идти боком относительно своего пути. Простого отражения спрайта по горизонтали хватало для движения влево и вправо, но не для ухода в глубину экрана или движения на зрителя.
В октябрьской итерации появились разные ракурсы. Восемь направлений собираются из пяти исходных видов и трёх зеркальных. В зависимости от движения видно переднюю часть, бок, спину или промежуточный ракурс. Это касается не только выбора картинки: шаг должен соответствовать выбранному виду, а удары и падения — сохранять персонажа и точку земли.
Материалы подготовки направленных анимаций. Разные ракурсы позволяют персонажу идти по дороге вперёд, а не скользить по ней боком.
Выбирать ракурс нужно по фактическому перемещению. Если боец обходит препятствие, он должен повернуться вслед за этим обходом, а не продолжать смотреть в сторону далёкой цели. Одновременно смена направления не должна ломать уже начатую атаку и её момент попадания.
Такие мелочи плохо видны в перечне возможностей. «Восемь направлений анимации» звучит как ещё одна строка. В живом бою это меняет то, насколько естественно воспринимается толпа и насколько легко понять, куда она движется.
Кто в этой разработке принимает решения
У нас не было момента, когда нейросеть получила один промпт и принесла готовую игру. Было много отдельных разговоров и итераций: придумать вариант, реализовать, запустить, посмотреть, заметить проблему, объяснить её, переделать.
Часть идей предлагали модели. Часть появлялась у меня после игры. Иногда я просил конкретную механику, иногда описывал ощущение: неудобно тянуть мышь, мало экшена, персонаж идёт неестественно. Модель превращала это в гипотезу и реализацию, после чего снова требовалась проверка.
Очень полезным стало разделение реализации и проверки. Агент, который только что написал код, знает, как тот должен работать, и рискует увидеть именно это. Другой проход может обнаружить, что новая анимация есть в папке, но в бою выбирается старая; что технически корректный приказ непонятен по экрану; что красивое действие срабатывает только в специально подготовленной ситуации.
При этом автоматический бой отвечает лишь на часть вопросов. Он может обнаружить ошибку, сравнить результаты и проверить повторяемость. Но победа бота не доказывает, что человеку интересно. Даже увеличение числа действий не обязательно означает, что у игрока стало больше осмысленных решений.
Поэтому человеческое «мне это кажется скучным» или «рука хочет сделать наоборот» остаётся полноценным входом в разработку. Его нельзя отменить зелёной таблицей тестов. Зато можно превратить в более конкретный вопрос и проверить следующую версию.
Где игра находится сейчас
На момент написания это бесплатная альфа 0.4.1 с русской и английской версиями. Из маленького эксперимента получилась игра, в которой рисование линий связано с построением армии, временем действия договора и выпуском приказов. Появились разные роли, активные способности, фигуры и более подробное обучение.
Это всё ещё разработка. Я не хочу изображать её завершённой историей успеха: хорошие отдельные механики ещё нужно соединять в понятный и интересный опыт, а анимация, управление и объяснение правил требуют новых итераций.
Самым неожиданным для меня оказалось то, насколько далеко можно уйти от первоначального запроса, сохранив его маленькое зерно. Началось с «придумай игру». Осталась линия, которую я рисую мышью. Всё вокруг неё — и даже смысл её исчезновения — успело измениться.
А самым трудным оказалось не получить ещё один вариант. Вариантов нейросети умеют предлагать много. Трудно понять, какой из них стоит оставить, почему он работает и что именно нужно изменить в следующем.
Скачать текущую альфу для Windows, macOS и Linux можно на сайте игры, исходники лежат в публичном репозитории проекта. Если вы делали игру вместе с нейросетями, интересно сравнить опыт: на каком месте быстрый прототип у вас превращался в долгую работу над качеством?