Разработка игры на AI-агентах: от идеи до релиза через декомпозицию и управление контекстом

Почему 90% AI-игр остаются демками (и как попасть в оставшиеся 10%)

В 2026 году каждый второй разработник пробовал создать игру с помощью ИИ. Каждый десятый даже начал. Но до релиза доходят единицы. Почему? Потому что большинство подходят к AI-агентам как к волшебной палочке: "Напиши мне игру про космических котиков" и ждут шедевр.

Не работает. Совсем.

Я выпустил полноценную игру на AI-агентах. Не демку, не прототип - продаваемый продукт в Steam. И главный инсайт: успех зависит не от промптов, а от системы. Системы декомпозиции задач и управления контекстом.

Проблема: контекстная амнезия и "зона тупости"

Представьте: вы три часа объясняли агенту архитектуру игры. Он написал отличный код. Вы просите добавить новую фичу. Агент смотрит на вас пустыми глазами и предлагает переписать всё с нуля.

Это контекстная амнезия. И она убивает проекты.

Вторая проблема - "зона тупости". Когда агент, получив слишком много контекста, начинает генерировать бессмысленный код. Или зацикливается на одной идее. Или забывает, что уже реализовал половину функционала.

Решение: декомпозиция как искусство

Вы не можете дать агенту всю игру сразу. Но можете разбить её на части, которые помещаются в его контекстное окно. И научиться передавать контекст между этими частями.

Это не просто "разбей на задачи". Это целая философия. Я называю её "Epic-первая разработка".

1 Начинаем с Epics, а не с кода

Epic - это не просто большая задача. Это самодостаточный модуль игры с чёткими границами. Примеры Epics для игры:

• Система передвижения персонажа (включая физику, анимации, коллизии)
• Инвентарь и система предметов
• Боевая система
• Диалоговая система NPC
• Система сохранения игры

Каждый Epic должен:

1. Иметь чёткие входные и выходные интерфейсы
2. Быть реализуемым за 2-3 сессии работы с агентом
3. Содержать собственную документацию внутри кода
4. Иметь тесты (да, агенты умеют писать тесты, если правильно попросить)

2 Выбираем инструменты: VS Code + Codex + Dora CLI

В 2026 году выбор IDE для AI-разработки критически важен. Я пробовал всё: от специализированных AI-IDE до старых добрых редакторов с плагинами.

Победитель: VS Code с тремя компонентами:

Почему именно эта связка? Потому что она решает главную проблему: агент теряется в большой кодовой базе. Dora CLI с SCIP-индексацией даёт агенту карту местности. Без этого он как слепой в лабиринте.

3 Создаём контекстные контейнеры

Вот где большинство ошибается. Они дают агенту весь файл (или даже несколько файлов) и ждут чуда. Но контекстное окно переполняется, и агент начинает "гадать".

Вместо этого создаём контекстные контейнеры - специальные файлы, которые содержат только нужную информацию:

# context_container_combat_system.py
"""
КОНТЕКСТНЫЙ КОНТЕЙНЕР: Боевая система
Версия: 1.2
Дата создания: 15.02.2026

ОСНОВНЫЕ КОМПОНЕНТЫ:
1. Класс CombatManager - управляет всем боем
2. Класс Weapon - оружие с уроном и модификаторами
3. Класс DamageCalculator - расчёт урона с учётом брони

ИНТЕРФЕЙСЫ:
- get_damage(target, weapon) -> float
- apply_effect(target, effect_type)
- is_alive(entity) -> bool

ЗАВИСИМОСТИ:
- Требует system_movement.py для позиционирования
- Требует system_inventory.py для оружия из инвентаря

ОГРАНИЧЕНИЯ:
- Максимум 8 участников в бою одновременно
- Урон рассчитывается каждый кадр
"""

# Только сигнатуры, без реализации
class CombatManager:
    def __init__(self):
        pass
    
    def start_combat(self, participants):
        """Начинает бой между участниками"""
        pass

class Weapon:
    def __init__(self, damage, weapon_type):
        self.damage = damage
        self.weapon_type = weapon_type

class DamageCalculator:
    @staticmethod
    def calculate(base_damage, armor, modifiers):
        """Рассчитывает итоговый урон"""
        pass

Этот файл - карта для агента. Он видит структуру, интерфейсы, зависимости. Но не забивает контекст реализацией. Когда нужно изменить боевую систему, даём агенту этот контейнер + конкретный файл для изменения.

4 Работаем с агентом: сессионный подход

Одна сессия = одна законченная задача. Не "допиши всю игру", а "добавь критический урон в DamageCalculator".

Структура сессии:

1. Загружаем контекстный контейнер Epic'а
2. Загружаем файл для изменения
3. Даём чёткую задачу с примерами входных/выходных данных
4. Проверяем результат сразу (не откладываем!)
5. Фиксируем изменения и обновляем контекстный контейнер

5 Управляем зависимостями между Epic'ами

Самая сложная часть. Боевая система зависит от системы передвижения. Инвентарь зависит от системы предметов. Если менять одну систему, ломаются другие.

Решение: карта зависимостей. Простой JSON-файл, который показывает связи:

{
  "combat_system": {
    "depends_on": ["movement_system", "inventory_system"],
    "used_by": ["ai_system", "quest_system"],
    "version": "1.2",
    "last_modified": "2026-02-15"
  },
  "movement_system": {
    "depends_on": ["physics_engine"],
    "used_by": ["combat_system", "exploration_system"],
    "version": "2.1",
    "last_modified": "2026-02-10"
  }
}

Перед изменением любой системы проверяем карту. Если меняем movement_system, знаем, что нужно протестировать combat_system и exploration_system.

Реальные ошибки (и как их избежать)

За время разработки я наступил на все грабли. Вот самые болезненные:

Ошибка 1: Агент забывает собственный код

Ситуация: агент написал отличную систему диалогов. Через день просим добавить ветвление диалогов. Агент предлагает переписать всё с нуля, потому что "в текущей реализации нет поддержки ветвления" (хотя она есть).

Решение: всегда сохраняйте промпты, которые давали агенту. Создайте файл prompts_history.md. Когда агент забывает, покажите ему его же промпт из прошлого.

Ошибка 2: Конфликт стилей кода

Один агент пишет с snake_case, другой - с camelCase. Один использует async/await, другой - колбэки. Получается мешанина.

Решение: создайте .code_style файл с правилами. Давайте его агенту перед каждой сессией. И используйте линтеры - они ловят расхождения лучше человека.

Ошибка 3: Бесконечные рефакторинги

Агент любит "улучшать" код. Сегодня он оптимизирует алгоритм поиска пути. Завтра - переписывает его на более "элегантный" лад. Послезавтра - возвращается к первоначальному варианту.

Решение: зафиксируйте правило "рефакторинг только по запросу". Если код работает - не трогаем. Все улучшения - отдельными задачами с обоснованием.

От прототипа к релизу: что меняется

Когда игра из прототипа превращается в продакшен, подход к работе с агентами должен измениться:

Самая частая ошибка: продолжать использовать агентов как на этапе прототипа. В бета-тесте это гарантированно сломает сборку.

Инструменты, которые реально работают в 2026

После релиза игры я протестировал десятки инструментов. Вот что осталось в рабочем стеке:

• GitHub Copilot Workspace - для декомпозиции задач. Лучше всего справляется с разбивкой Epic'ов на подзадачи
• Claude 3.7 Sonnet - для code review. Находит странные решения, которые пропускают другие агенты
• Cursor с режимом Agent - для рефакторинга. Понимает контекст лучше аналогов
• Windsurf - для работы с игровыми движками (Unity/Unreal). Специализированные промпты для геймдева

Что дальше? Будущее AI-разработки игр

Сейчас мы в каменном веке. Агенты тупые, контекст маленький, управление сложное. Но тенденции на 2026-2027:

1. Контекстные окна 1M+ токенов станут стандартом. Можно будет загружать всю игру целиком
2. Специализированные игровые модели - обученные на коде Unity, Unreal, Godot. Понимающие специфику геймдева
3. Визуальные агенты - которые могут редактировать текстуры, создавать анимации, настраивать материалы
4. Мультиагентные системы - где разные агенты работают над разными аспектами игры одновременно

Но даже с этими улучшениями одно останется неизменным: нужна система. Декомпозиция, управление контекстом, контроль качества. Без этого вы создадите ещё одну демку, которая умрёт в архиве GitHub.

Мой главный совет: начните с маленькой игры. Не MMO, не open-world RPG. Простой платформер или головоломку. Пройдите весь путь от идеи до релиза. Набьёте шишек, поймёте, как работают агенты в реальных условиях. И только потом беритесь за большой проект.

И да, сохраняйте промпты. Каждый удачный, каждый неудачный. Через месяц у вас будет собственная база знаний. Которая ценнее любой статьи или туториала.