Зачем нейросеть берётся за Героев 3
Культовая пошаговая стратегия Heroes of Might and Magic III (Герои меча и магии 3) остаётся эталоном жанра спустя десятилетия. Её механики — исследование карты, тактические бои и развитие города — кажутся идеальным полигоном для проверки возможностей современных нейросетей. В рамках эксперимента автор решил выяснить, способна ли языковая модель Qwen воссоздать эти три ключевые механики в одной игре без участия программиста.
Задача была сформулирована максимально просто: создать упрощённый клон, в котором есть перемещение по карте мира, сбор ресурсов и бой с монстрами, тактическая боевая система, аналогичная оригиналу, и возможность отстройки города. Нейросеть должна была сама написать весь код на основе текстового описания.
Эксперимент показал, что даже при отсутствии у автора навыков программирования можно получить работающий прототип. Однако путь от первой версии до играбельного продукта оказался полон неожиданных трудностей, которые потребовали десятков итераций и тщательной настройки каждого промпта.
Первая версия: что получилось сразу
После первого промпта нейросеть сгенерировала игру, в которой уже присутствовали все три заявленные механики. Карта мира представляла собой поле из клеток, на котором в случайном порядке располагались ресурсы, монстры и замок игрока. Герой имел очки опыта, движения, а также навыки атаки и защиты, как в классических Героях.
В городе можно было строить здания и нанимать войска. Боевая система на этом этапе была полностью текстовой — игрок видел только описание боя без визуального поля. Ресурсы отображались исключительно как золото, хотя в оригинале их несколько видов.
Уже в первой версии проявились типичные для нейросетевой генерации проблемы: побеждённые монстры не исчезали с карты, потери в бою не сохранялись, а при повышении уровня герой получал очки здоровья, которые никак не влияли на геймплей. Тем не менее, сам факт, что модель смогла объединить три сложные механики в одном коде, стал неожиданностью для автора.
Проблемы боевой системы и их решение
Главной головной болью оказалась тактическая боевая система. Попытка реализовать поле 8×8 клеток с разделением на дальний и ближний бой провалилась — код постоянно крашился, а логика перемещения и атаки работала некорректно. Пришлось вернуться к упрощённой текстовой версии, но с важными доработками.
Во-первых, урон теперь рассчитывался как сила атаки юнита, умноженная на их количество. Во-вторых, увеличили число монстров в стеке — изначально в каждом лагере был всего один противник. В-третьих, побеждённые монстры наконец стали исчезать с карты, а потери в армии игрока начали учитываться.
Особую сложность вызвала механика «силы стека». Нейросеть изначально просто суммировала атаку и здоровье всех юнитов, превращая 10 слабых бойцов в одного суперсолдата. При этом потери не уменьшали атаку стека — если у такого «суперюнита» снижалось здоровье, количество бойцов в стеке не менялось. Потребовалось несколько раундов диалога, чтобы объяснить модели, что при потере здоровья должно пропорционально уменьшаться и количество юнитов, и их суммарная атака.
Экономика и отстройка города: от галочек к реальной механике
Первая версия города была декоративной — постройки просто отмечались галочками, но не давали никаких игровых преимуществ. Автору пришлось вручную выстроить логику развития: экономические здания (префектура, муниципалитет, капитолий) увеличивали ежедневный доход золотом, а военные (стрельбище, казармы, монастырь, портал славы) открывали доступ к найму соответствующих юнитов.
Стартовый доход составил 250 золотых в день, а нанимать можно было только крестьян. Для получения более сильных войск требовалось последовательно строить здания — точно так же, как в оригинальных Героях. Это добавило стратегической глубины: игроку приходилось выбирать между быстрым усилением армии и долгосрочным экономическим ростом.
Интересно, что нейросеть изначально не предусмотрела никакой связи между постройками и юнитами — пришлось явно прописывать в промптах, что стрельбище даёт стрелков, казармы — рыцарей и так далее. После этого экономическая система заработала как полноценный элемент геймплея.
Прогрессия монстров и баланс сложности
Поскольку в игре не было вражеского героя (автор побоялся добавлять ИИ-противника из-за риска крашей), единственной целью стала зачистка карты от монстров. Чтобы задача не оказалась слишком простой, ввели механику прогрессии: каждый новый день количество монстров во всех нейтральных лагерях увеличивалось на 1.
Это создало интересный эффект: слабые враги вроде гоблинов оставались manageable, но драконы быстро становились практически непобедимыми. Первые попытки пройти игру провалились — прогрессия монстров оказалась быстрее, чем развитие героя. Пришлось корректировать баланс, уменьшая темп роста или увеличивая эффективность прокачки.
Также добавили механику разведки: перед боем игрок видит количество и силу монстров и может отступить, если шансы малы. Это компенсировало отсутствие тактического контроля в бою — теперь исход сражения зависел не только от силы армии, но и от правильной оценки противника.
Сундуки и другие механики: борьба с багами
Попытка добавить сундуки с сокровищами, как в оригинальных Героях, привела к очередному багу: монетки на карте исчезали только после нажатия кнопки «Новый день». Игрок мог бесконечно собирать ресурсы с одного и того же сундука, просто не завершая ход. Решение оказалось радикальным — после подбора сундука герой терял возможность двигаться до конца дня.
Этот пример хорошо иллюстрирует, как нейросеть, не понимая игровой логики, генерирует код, который формально работает, но нарушает задуманные правила. Каждую такую механику приходилось тестировать и править вручную, объясняя модели желаемое поведение через новые промпты.
Другие мелкие баги включали некорректное отображение ресурсов, сбои при переходе между картой и городом, а также проблемы с обновлением интерфейса после боя. Большинство из них удалось исправить, но на это ушло значительное время.
Время и ресурсы: сколько стоит создание игры через нейросеть
На генерацию итоговой версии ушло около 10 часов — значительно больше, чем на предыдущие проекты (Pong и платформер). Время ответа нейросети увеличилось с 1–2 минут до 5–6 минут из-за усложнения кода. Итоговый объём составил 1289 строк кода.
Автор подчёркивает, что не использовал никаких знаний программирования — все правки вносились через текстовые промпты. Однако на практике это означало десятки итераций, каждая из которых требовала тщательного описания проблемы и ожидаемого решения.
Ключевой вывод: нейросеть способна создать работающий прототип сложной игры, но процесс далёк от автоматического. Разработчик (даже без навыков кодинга) должен чётко формулировать задачи, выявлять баги и объяснять логику — по сути, выполнять роль проджект-менеджера и тестировщика одновременно.
Ограничения и перспективы: что не удалось реализовать
Несмотря на успех, эксперимент выявил серьёзные ограничения. Нейросеть не смогла корректно реализовать тактическую боевую систему с полем и пошаговыми перемещениями — пришлось довольствоваться текстовой версией. Вражеский ИИ-герой так и не был добавлен из-за высокого риска ошибок.
Отсутствие визуальной боевой механики сильно упростило геймплей: исход сражения теперь зависел исключительно от численного превосходства, а не от тактики. Это далеко от оригинала, где правильно расставленные юниты могут победить превосходящего противника.
Тем не менее, сам факт, что языковая модель смогла объединить три сложные механики в одной игре, впечатляет. С развитием нейросетей и улучшением их понимания игровой логики можно ожидать, что подобные эксперименты будут давать всё более качественные результаты. Возможно, в будущем создание прототипов инди-игр станет доступно каждому, кто умеет формулировать задачи.
Практические советы для тех, кто хочет повторить эксперимент
Если вы решите создать свою игру с помощью нейросети, учтите несколько моментов.
Начинайте с максимально простого промпта, описывающего только ключевые механики. Слишком детальное ТЗ на старте может запутать модель.
Будьте готовы к множеству итераций. Каждый баг придётся исправлять отдельным промптом, чётко указывая, что именно не так и как должно работать.
Используйте «разведку боем»: перед сложными изменениями просите нейросеть сначала описать, как она планирует реализовать механику, а уже потом генерировать код.
Не бойтесь откатываться к предыдущим версиям, если новое изменение ломает больше, чем исправляет.
И главное — тестируйте каждую мелочь. Нейросеть может создать код, который формально выполняется, но делает совсем не то, что вы ожидали.
Вопросы и ответы
Можно ли создать полноценный клон Героев 3 с помощью нейросети?
На текущем уровне развития языковых моделей — нет. Эксперимент показал, что нейросеть способна воспроизвести базовые механики (карта, город, бой), но тактическая боевая система с полем и пошаговыми перемещениями оказалась слишком сложной. Полноценный клон потребует ручного программирования или значительно более продвинутых ИИ-инструментов.
Сколько времени заняло создание игры через нейросеть?
На генерацию итоговой версии ушло около 10 часов. Время ответа нейросети составляло 5–6 минут на один запрос из-за сложности кода. Большая часть времени ушла на исправление багов и уточнение механик через дополнительные промпты.
Какие механики Героев 3 удалось реализовать?
Удалось реализовать три основные механики: перемещение по карте мира со сбором ресурсов и боем с монстрами, отстройку города с экономическими и военными зданиями, а также упрощённую текстовую боевую систему. Также добавлены прокачка героя, сундуки с сокровищами и прогрессия монстров.
Почему боевая система осталась текстовой?
Попытка реализовать тактическое поле 8×8 с разделением на дальний и ближний бой привела к постоянным крашам и некорректной работе. Нейросеть не смогла корректно обработать логику перемещения и атаки одновременно. Пришлось вернуться к текстовой версии, но с улучшенным расчётом урона и учётом потерь.
Какие баги были самыми сложными?
Самым сложным оказался баг с «силой стека»: нейросеть не учитывала потери юнитов при расчёте атаки. Также проблемы вызывали сундуки, которые можно было бесконечно собирать, и отсутствие исчезновения побеждённых монстров с карты. Каждый баг требовал нескольких раундов диалога для исправления.
Нужны ли знания программирования для создания игры через нейросеть?
Автор эксперимента не использовал навыки программирования — все правки вносились через текстовые промпты. Однако потребовалось умение чётко формулировать задачи, выявлять баги и объяснять логику. По сути, разработчик выполнял роль проджект-менеджера и тестировщика.
Какой объём кода получился в итоге?
Итоговый код игры составил 1289 строк. Это значительно больше, чем у предыдущих проектов автора (Pong и платформер), что объясняется сложностью объединения трёх разных механик в одной игре.