Один разработчик, Claude Opus 5.5 и месяц работы: Galdhold — моя воксельная action-RPG
Всем привет! Мой ник почти везде - dpsmpx.
Делаю Galdhold — воксельную action-RPG с открытым процедурным миром. Начинал практически с нуля, а примерно за месяц с небольшим довёл проект до запускаемых сборок для Android и Windows. Работаю один, а основной ИИ-помощник в разработке — Claude Opus 5.5.
Это не история «написал один промпт — получил готовую игру». Чем больше кода и игровых систем, тем важнее не только писать их быстро, но и контролировать, чтобы они не противоречили друг другу.
Что есть в Galdhold сейчас?
Это не только мир из кубиков. Мир генерируется процедурно, в нём есть разные регионы, смена дня и ночи, погода и свет от факелов. Игрок добывает ресурсы, изготавливает инструменты и снаряжение, использует верстаки и наковальню. У предметов есть прочность, сломанные вещи можно ремонтировать.
В бою работает система «Резонанса»: сражаясь, игрок накапливает ресурс, а при его заполнении получает возможность провести финишер. Форма завершающего удара зависит от семейства оружия: меч, топор, копьё, кинжал, кулаки, дальнобойное и магическое оружие отличаются не только цифрами урона.
Отдельный акцент — поселения. Жители не задуманы просто как неподвижные декорации: у них есть личные запасы, они едят, могут торговать своими вещами. У деревни есть общий склад, а достаток и уклад влияют на её запасы. Так что разговоры, торговля и состояние поселения связаны с тем, что в нём происходит. Есть задания, сюжетная цепочка и репутация.
Ещё один необычный момент: у проекта нет набора сторонних графических и аудиоресурсов — графика, звук и музыка генерируются процедурно.
Как я контролирую разработку с ИИ
Главный вывод за время работы: недостаточно отправить нейросети большое ТЗ и ждать результата. Нужно организовать среду, в которой агент не теряет контекст, не меняет уже принятые решения по своему усмотрению и не пытается переделать полпроекта ради одной задачи.
Я разделяю работу на небольшие конкретные задачи с понятным результатом и критериями приёмки. Перед реализацией фиксирую план и границы изменений. Важные решения записываются отдельно, а не остаются где-то в переписке.
Документация тоже разделена по назначению: ROADMAP задаёт этапы и фиксирует, что входит в первый релиз; DECISIONS хранит принятые решения; TODO содержит только актуальные незавершённые задачи и подтверждённый технический долг; CHANGELOG — историю сделанных изменений; ARCHITECTURE описывает устройство проекта и связи между системами.
Готовность определяют не слова агента «готово», а сборка, проверки и воспроизводимый результат. Я использую быстрые целевые проверки для отдельных изменений и полный прогон на контрольных точках. Если проверка ловит регрессию, разбираюсь с причиной и закрепляю поведение тестом, а не просто маскирую симптом.
В последнем полном CI-прогоне репозитория прошли 6582 из 6582 проверок; сборка и отдельная проверка Windows также завершились успешно.
Сейчас я сосредоточен на версии 1: довести игру до согласованного состояния, проверить Windows-версию и подготовить выпуск в Steam. Это ещё разработка, а не объявление о готовом релизе.
