Vibe Coding для игр: как управлять контекстом и избежать краха проекта при разработке с ИИ

Когда ИИ забывает, что делает игру игрой

Начинаешь проект. Unity, C#, пара скриптов для персонажа. ChatGPT генерирует отличный код для прыжков, анимаций, коллизий. Через неделю у тебя 50 файлов, сложная система диалогов, инвентарь, квесты. И вот ты просишь ИИ "добавить проверку квеста в диалоговую систему".

А он в ответ: "Что за диалоговая система? И что такое квест?"

Контекст сбросился. Или деградировал. Или перепутался. Ты в панике пытаешься объяснить заново, но каждый следующий ответ хуже предыдущего. Проект превращается в спагетти-код, который даже ты сам не понимаешь.

Знакомо? Это не твоя вина. Это фундаментальная проблема Vibe Coding в геймдеве.

Почему ИИ теряет нить в геймдеве быстрее

Игровые проекты — это не просто код. Это:

• Состояние игры (game state), которое меняется каждую миллисекунду
• Зависимости между системами (физика → анимация → звук)
• Ресурсы (текстуры, модели, звуки) со своими путями и зависимостями
• Сценарии (scripts) и префабы (prefabs) в движке
• Временные линии (timelines) и анимационные контроллеры

ChatGPT или Claude не видят твой проект. Они видят текст. Когда ты пишешь "измени скорость персонажа", ИИ не знает:

1. Где лежит скрипт персонажа
2. Какие другие системы от него зависят
3. Как это повлияет на баланс игры
4. Какие значения уже настроены в инспекторе Unity

Вот почему через 2-3 недели активной разработки качество генерации падает на 80%. ИИ просто не помнит, что он делал вчера.

1 Создай LLM-специфичный контекстный файл

Первое правило — никогда не полагаться на память ИИ. Создай файл CONTEXT_FOR_AI.md в корне проекта. Но не просто README. Это должна быть инструкция, которую ты будешь копировать в каждый промпт.

Вот как выглядит рабочий контекстный файл для игры:

# ПРОЕКТ: DARK FOREST RPG

## АРХИТЕКТУРА
- Движок: Unity 2022.3 LTS
- Язык: C# 9.0
- Паттерн: Entity Component System (чистый ECS, не Unity ECS)
- Система сохранения: JSON + шифрование AES

## КЛЮЧЕВЫЕ СИСТЕМЫ
1. PlayerController.cs - управление персонажем
   - Использует CharacterController, не Rigidbody
   - Скорость: walk=3.5, run=7.0, jumpForce=8.0
   - Анимации через Animator, параметры: Speed, IsGrounded, Jump

2. DialogueSystem.cs - диалоги
   - Формат данных: List<DialogueNode>
   - Каждый узел имеет: id, text, options[], nextNodeId
   - Интеграция с QuestSystem через событие OnDialogueChoice

3. QuestSystem.cs - система квестов
   - Структура: Quest { id, title, description, objectives[], reward }
   - Объективы: сбор предметов, убийство врагов, диалоги
   - Состояния: NOT_STARTED, ACTIVE, COMPLETED, FAILED

## ВАЖНЫЕ КОНВЕНЦИИ
- Все публичные поля начинаются с заглавной буквы: public float Speed
- Приватные поля с подчеркивания: private int _currentHealth
- События используют делегаты Action<>, не UnityEvent
- Префабы лежат в Resources/Prefabs/
- Скрипты в Scripts/ с папками по системам

## ЧЕГО НЕ ДЕЛАТЬ
- Не использовать GameObject.Find() - только ссылки в инспекторе
- Не хардкодить теги и имена сцен
- Не создавать синглтоны без необходимости
- Не смешивать Update() и FixedUpdate() логику

Этот файл — твоя библия. Перед каждым сложным промптом копируй его целиком или части. Да, это занимает место в контекстном окне. Но лучше потратить 1000 токенов на контекст, чем 5000 на переделывание сломанного кода.

2 Разделяй и властвуй: контекстные сессии

Самая большая ошибка — пытаться делать всё в одном чате. Не делай этого. ИИ путается, контекст переполняется, качество падает.

Вместо этого создавай отдельные чаты для:

В каждой сессии свой контекстный файл. В архитектурной — общая структура. В геймплейной — конкретные значения скоростей, сил, таймингов.

3 Автоматизируй контекстное обновление

Ручное копирование контекста утомительно. Особенно когда проект растет. Решение — скрипт, который собирает актуальный контекст автоматически.

Создай Python-скрипт (или bash, или что угодно), который:

• Читает структуру папок проекта
• Извлекает ключевые комментарии из кода
• Собирает информацию о зависимостях
• Генерирует свежий контекстный файл

#!/usr/bin/env python3
import os
import re
from pathlib import Path

class ContextGenerator:
    def __init__(self, project_root):
        self.root = Path(project_root)
        self.context = []
    
    def scan_csharp_files(self):
        """Ищет ключевые комментарии в C# файлах"""
        for cs_file in self.root.rglob("*.cs"):
            with open(cs_file, 'r', encoding='utf-8') as f:
                content = f.read()
                
            # Ищем комментарии типа "// CONTEXT:"
            matches = re.findall(r'//\s*CONTEXT:(.*?)(?=\n\s*//|$)', content, re.DOTALL)
            if matches:
                rel_path = cs_file.relative_to(self.root)
                self.context.append(f"\n## {rel_path}")
                for match in matches:
                    self.context.append(match.strip())
    
    def generate(self):
        self.scan_csharp_files()
        output = "# AUTOGENERATED CONTEXT\n\n"
        output += "\n".join(self.context)
        
        output_file = self.root / "AI_CONTEXT.md"
        output_file.write_text(output, encoding='utf-8')
        print(f"Контекст сохранен в {output_file}")

if __name__ == "__main__":
    gen = ContextGenerator(".")
    gen.generate()

Запускай этот скрипт перед каждой сессией с ИИ. Контекст всегда актуальный. Никаких устаревших данных.

Промпт-инжиниринг для игр: что работает, а что нет

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

Плохой промпт (так делать не надо):

Сделай систему инвентаря для RPG игры

Почему плохо? Слишком абстрактно. Какой движок? Какая архитектура? Какие ограничения?

Хороший промпт:

[КОНТЕКСТ ПРОЕКТА]
Проект: Dark Forest RPG, Unity 2022, C#
Архитектура: Entity Component System (самописный)
Существующие системы: PlayerController, ItemDatabase, UI_Manager

[ЗАДАЧА]
Создать систему инвентаря со следующими требованиями:
1. Максимум 20 слотов
2. Поддержка стаков для расходников (до 99)
3. Разделение на категории: оружие, броня, зелья, материалы
4. Drag & Drop между слотами
5. Сохранение в JSON

[ОГРАНИЧЕНИЯ]
- Не использовать PlayerPrefs
- Не создавать синглтоны
- Интегрировать с существующей ItemDatabase
- UI использовать Unity's new Input System

[ФОРМАТ ОТВЕТА]
1. Класс InventorySystem.cs с публичным API
2. Класс InventorySlot.cs
3. Класс InventoryUI.cs для отображения
4. Пример использования в PlayerController
5. Тесты для основных методов

Видишь разницу? Второй промпт дает ИИ всю необходимую информацию. Он знает контекст, ограничения, ожидаемый формат. Шанс получить рабочий код — 90% против 10% у первого промпта.

Когда Vibe Coding убивает архитектуру

Самая опасная вещь в Vibe Coding для игр — это незаметная деградация архитектуры. Начинаешь с чистого ECS. Через неделю появляется первый синглтон. Еще через день — статический класс с глобальным состоянием. Еще через три дня — спагетти-зависимости между системами.

Почему так происходит? Потому что ИИ оптимизирует под задачу, а не под архитектуру. Попросил добавить звук при подборе предмета — получил прямую зависимость InventorySystem → AudioManager. Быстро. Удобно. И смертельно для проекта.

4 Архитектурные чекпоинты

Каждые 2-3 дня проводи архитектурный ревью. Не смотри на функциональность. Смотри на:

• Циклические зависимости между модулями
• Появление синглтонов и глобального состояния
• Нарушение принципа единой ответственности
• Жесткие связи между несвязанными системами

Создай файл ARCHITECTURE_RULES.md с жесткими правилами:

# АРХИТЕКТУРНЫЕ ЗАПРЕТЫ

1. НИКАКИХ СИНГЛТОНОВ
   - Вместо: AudioManager.Instance
   - Использовать: Dependency Injection или события

2. НИКАКИХ ПРЯМЫХ ВЫЗОВОВ МЕЖДУ СИСТЕМАМИ
   - Вместо: Inventory.PickItem() → Audio.PlaySound()
   - Использовать: Inventory.OnItemPicked событие

3. НИКАКОГО ГЛОБАЛЬНОГО СОСТОЯНИЯ
   - Вместо: GameState.CurrentLevel
   - Использовать: LevelManager с подпиской на изменения

4. ВСЕ ЗАВИСИМОСТИ ЧЕРЕЗ ИНТЕРФЕЙСЫ
   - Вместо: class Inventory { Database db; }
   - Использовать: class Inventory { IItemDatabase db; }

Добавляй этот файл в каждый промпт, связанный с архитектурой. Заставляй ИИ следовать правилам. Если нарушает — перегенерируй ответ.

Инструменты, которые спасают от контекстной амнезии

Чистые промпты и ручное управление контекстом работают. Но есть инструменты, которые делают это лучше.

Cursor с его контекстными агентами

Cursor (о котором мы писали в статье про OpenSpec и Cursor) умеет сохранять контекст между сессиями. Создаешь агента под конкретную задачу — он помнит архитектуру, соглашения, даже твои предпочтения в коде.

Beads для семантического поиска

Beads индексирует код и позволяет ИИ находить релевантные фрагменты. Попросил добавить новую способность персонажу — Beads найдет все связанные классы: AbilitySystem, AnimationController, InputHandler.

JanusCoder для мультимодального понимания

JanusCoder (про который подробно в отдельной статье) видит не только код, но и структуру проекта, зависимости, даже диаграммы. Для игр, где важна визуальная составляющая, это бесценно.

Чего никто не говорит о Vibe Coding в геймдеве

Есть три вещи, о которых молчат в туториалах, но которые ломают 80% игровых проектов на ИИ.

1. ИИ не понимает игровой баланс

Можешь попросить: "Сделай меч сильнее". ИИ изменит damage с 10 на 15. Но он не знает, что:

• У врагов 50 хп, а у босса 500
• Игрок атакует 2 раза в секунду
• В игре есть критические удары с множителем 2x
• Другие оружия должны оставаться полезными

Результат? Меч ломает баланс. Игрок убивает босса за 10 секунд. Игра становится скучной.

2. ИИ не чувствует "геймдизайн"

Геймдизайн — это не код. Это ощущения. Чувство достижения, напряжение, катарсис. ИИ может сгенерировать систему прокачки. Но он не поймет, почему игрок должен чувствовать рост силы после 2 часов игры, а не после 10 минут.

Как в статье про ИИ как младшего коллегу — он исполнитель, не дизайнер.

3. ИИ не предсказывает синергию

Создал систему ядов. Создал систему огня. Попросил ИИ добавить комбо "огненный яд". Он сделает. Но не предскажет, что комбо окажется настолько сильным, что сломает все остальные механики.

Игровой баланс — это сеть взаимосвязанных систем. Изменение одной точки влияет на всю сеть. ИИ видит только точку.

Стратегия выживания: как не сгореть

Итак, ты хочешь делать игру с ИИ. Как не повторить ошибки сотен разработчиков, которые бросили проекты на полпути?

1. Начинай с прототипа, не с архитектуры
   Сделай минимальную игру за 3 дня. Без сложных систем. Проверь, работает ли твой workflow с ИИ.
2. Создавай контекст с первого дня
   Не откладывай. Первый скрипт — первый контекстный файл. Первая система — первое правило архитектуры.
3. Разделяй ответственность
   ИИ — для рутины, шаблонного кода, багов. Ты — для архитектуры, баланса, геймдизайна. Как в статье про неосознанный вайб-кодинг: слепая вера в ИИ убивает проекты.
4. Тестируй каждую генерацию
   Не доверяй ИИ. Каждый сгенерированный код запускай, тестируй, ломай. Особенно в играх, где баги видны сразу.
5. Имей план отката
   Если через месяц ИИ начинает генерировать ерунду — будь готов откатиться к ручному коду. Храни контрольные точки проекта.

Что будет дальше с Vibe Coding в играх

Сейчас мы в каменном веке управления контекстом. Копируем файлы в промпты. Создаем отдельные чаты. Пишем скрипты для генерации контекста.

Через год появятся специализированные ИИ-ассистенты для геймдева. Они будут:

• Понимать архитектуру игровых движков (Unity, Unreal, Godot)
• Знать стандартные паттерны геймдева (компоненты, системы, менеджеры)
• Предлагать решения для баланса на основе статистики
• Генерировать контекст автоматически из проекта

Но пока этого нет — мы должны справляться сами. С инструментами, которые есть. С методологиями, которые работают.

И главное — помнить: ИИ не заменит геймдизайнера. Не заменит продюсера. Не заменит тестировщика. Он заменит только ту часть разработчика, которая пишет шаблонный код. А это, если честно, не самая интересная часть работы.

Последний совет, который спасет твой проект:

Каждый раз, когда хочешь попросить ИИ сделать что-то сложное, задай себе вопрос: "Понимаю ли я сам, как это должно работать?" Если ответ "нет" — сначала разберись сам. Потом объясни ИИ. Не наоборот.

Потому что если ты не понимаешь свою игру — никакой ИИ не поможет. А если понимаешь — ИИ станет твоим лучшим инструментом. Не заменой. Инструментом.