Создание тактико-экономической RPG на Godot 4

Основы архитектуры RPG-проекта в Godot 4

Представьте: вы открыли Godot 4, создали новый проект и смотрите на пустую файловую систему. Где начать? Если вы нарративный дизайнер, привыкший мыслить сценами и персонажами, а не классами и узлами, первый шаг может казаться самым сложным. Но вот парадокс: архитектура вашего проекта — это по сути тот же сценарий, только вместо актёров у вас узлы (nodes), а вместо декораций — сцены (scenes).

Почему архитектура важнее кода

Многие начинающие разработчики бросаются писать код механик, не продумав структуру. Результат — «спагетти-проект», где изменение одного элемента ломает десять других. В тактико-экономической RPG эта проблема обостряется: у вас переплетаются боевая система, экономика, диалоги и сюжет. Если не заложить правильную структуру с самого начала, к середине разработки проект станет неуправляемым.

В Godot 4 фундаментальная единица — узел. Это объект с определённым поведением: Sprite2D отвечает за отображение спрайта, CollisionShape2D — за физическую форму, Timer — за отсчёт времени. Узлы объединяются в дерево (scene tree), где каждый узел может содержать дочерние. Корень дерева — это и есть ваша сцена.

Структура проекта: папки как акты пьесы

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

Типичная структура для тактико-экономической RPG:

Зачем так подробно? Потому что Godot автоматически отслеживает зависимости между файлами. Если вы переместите спрайт в другую папку после того, как привязали его к десяти сценам, придётся исправлять каждую ссылку вручную. Чёткая структура экономит часы боли.

Автозагрузка: глобальные менеджеры

В Godot есть механизм Autoload — скрипты или сцены, которые загружаются при старте игры и доступны из любого места. Это ваш инструмент для создания глобальных менеджеров (singletons).

Для тактико-экономической RPG вам понадобятся минимум три автозагружаемых скрипта:

GameManager — центральный переключатель состояний игры. Он знает, находимся ли мы в бою, в диалоге, в меню или на глобальной карте. Именно он решает, какая сцена сейчас активна и кто обрабатывает ввод игрока.

ResourceManager — хранит данные об экономике: золото, ресурсы, инвентарь. Он не знает, как отображать эти данные — только хранит и модифицирует.

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

Чтобы добавить скрипт в автозагрузку: Project → Project Settings → Autoload → укажите путь к файлу и имя. После этого обращаться к нему можно из любого скрипта: ResourceManager.gold += 100.

Сцена как самостоятельный модуль

Ключевой принцип Godot — сцены переиспользуются. Сцена персонажа содержит узлы для спрайта, коллизии, анимации и скрипта поведения. Вы создаёте её один раз и используете как шаблон: перетаскиваете на карту столько раз, сколько нужно.

Для тактической RPG это критически важно. Ваша сцена боевого юнита может выглядеть так:

Каждый экземпляр этой сцены — отдельный боец на поле. Меняете сцену — меняются все бойцы одновременно. Это и есть объектно-ориентированный подход в контексте Godot, только вместо классов вы работаете со сценами.

Сигналы: связь без зависимости

Одна из самых мощных концепций Godot — сигналы (signals). Это механизм, при котором один узел «кричит», а другие — слушают. Важно: отправитель не знает, кто его слушает. Это слабая связь (loose coupling), и она спасает от хаоса.

Представьте экономическую систему: игрок покупает товар в магазине. Магазин отправляет сигнал item_purchased(item_id, price). Слушают его три системы: инвентарь (добавляет предмет), UI (обновляет отображение золота) и аналитика (записывает покупку для баланса). Магазину всё равно, кто слушает — он просто сообщает факт.

Сигналы подключаются через редактор (вкладка Node рядом с Inspector) или через код: shop.item_purchased.connect(_on_item_purchased).

Паттерн «менеджер сцены» для переключения

В тактико-экономической RPG вам придётся постоянно переключаться между сценами: глобальная карта → бой → магазин → диалог → снова карта. Godot предоставляет get_tree().change_scene_to_file(), но для сложных проектов лучше создать собственный менеджер сцен.

Идея проста: вы не переключаетесь между сценами напрямую, а просите менеджер сделать это. Менеджер может при этом сохранить состояние, проиграть переход, передать данные между сценами.

Такой подход позволяет, например, передать в боевую сцену данные о том, какие враги и на какой карте, а после боя — вернуться на глобальную карту с результатами.

Ресурсы Godot: данные как отдельные файлы

Godot умеет сохранять данные в формате ресурсов .tres — это текстовые файлы, которые можно редактировать прямо в редакторе. Для RPG это золотая жила: вы можете создать ресурс типа UnitData с полями name, health, attack, sprite и использовать его как шаблон для каждого типа юнита.

Теперь в редакторе: Resource → New UnitData → заполняете поля → сохраняете как res://Resources/Data/Units/Knight.tres. В скрипте юнита загружаете: @export var data: UnitData. Дизайнер (то есть вы) может балансировать юнитов, не открывая код.

Практический кейс: минимальная структура демо

Для демо-версии тактико-экономической RPG достаточно следующей начальной архитектуры:

| Компонент | Тип | Назначение | |-----------|-----|------------| | GameManager | Autoload | Управление состояниями игры | | ResourceManager | Autoload | Золото, инвентарь, ресурсы | | NarrativeManager | Autoload | Прогресс сюжета, флаги | | SceneManager | Autoload | Переключение сцен | | WorldMap | Сцена | Глобальная карта с локациями | | BattleScene | Сцена | Тактическое поле боя | | DialogueUI | Сцена (UI) | Диалоговое окно | | ShopUI | Сцена (UI) | Интерфейс магазина |

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

Архитектура — это не бюрократия. Это карта вашего проекта. Без неё вы блуждаете впотьмах. С ней — каждый следующий шаг очевиден.

Тактические механики на практике: передвижение и действия персонажей

Почему в Final Fantasy Tactics или Fire Emblem каждый ход ощущается как шахматная партия, а в самодельных тактических играх персонажи часто «проскальзывают» сквозь стены или зависают между клетками? Разница — в правильной реализации сетки (grid), поиска пути (pathfinding) и конечного автомата состояний (state machine). Именно эти три кита держат тактический геймплей, и именно их мы реализуем в Godot 4.

Тайловая сетка: фундамент тактики

Тактическая RPG строится на тайловой карте (tilemap). В Godot 4 используется узел TileMapLayer (вместо устаревшего TileMap). Каждая клетка на карте — это координата Vector2i(x, y), и каждая координата хранит данные: проходима ли клетка, какой на ней тип местности, стоит ли на ней кто-то.

Для начала создайте сцену BattleMap с узлом TileMapLayer. В редакторе тайлов нарисуйте простое поле: несколько травяных клеток, пара каменных стен, возможно — вода. Это ваш первый тактический уровень.

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

Обратите внимание на класс CellData внутри скрипта. Это внутренний класс — удобный способ хранить данные, связанные только с этим скриптом. Каждая клетка знает своё положение, тип местности и кто на ней стоит.

Поиск пути: алгоритм «волны» для тактики

В тактической RPG вам нужно не просто найти путь от A до B, а показать все клетки, куда юнит может дойти за один ход. Классический A* здесь не оптимален — он ищет один кратчайший путь, а нам нужен «пузырь» доступных клеток.

Решение — алгоритм «волны» (он же flood fill с ограничением по дальности). Представьте, что вы бросаете камень в воду: волна расходится от точки старта, и каждая следующая «ступень» волны — это +1 к дистанции. Когда дистанция достигает move_range юнита — волна останавливается.

Этот алгоритм — сердце тактического передвижения. Он учитывает стоимость перемещения по разным типам местности: по траве — 1 очко, по песку — 2, по воде — практически невозможно. Именно так работают Fire Emblem и Tactics Ogre.

Визуализация: подсветка доступных клеток

Алгоритм возвращает массив координат, но игрок должен видеть результат. В Godot 4 для этого идеально подходит TileMapLayer с отдельным слоем подсветки или Polygon2D-оверлей.

Простой подход: создайте второй TileMapLayer поверх основного и рисуйте на нём полупрозрачные тайлы в позициях из массива reachable. Когда ход завершён — очищайте слой.

Конечный автомат: управление состояниями хода

Каждый ход юнита проходит через чёткую последовательность: ожидание выбора → перемещение → выбор действия → выполнение действия → завершение хода. Если управлять этим через набор if-ов, код превратится в монстра. Решение — конечный автомат состояний (finite state machine, FSM).

В Godot FSM реализуется через узлы: каждый состояние — отдельный дочерний узел с собственным скриптом. Родительский узел активирует нужное состояние и деактивирует остальные.

Каждое состояние — это отдельный скрипт. Например, IdleState ждёт клика по юниту, MoveState обрабатывает выбор клетки и анимацию перемещения, ActionState показывает меню действий (атака, способность, ожидание).

Действия юнита: атака и способности

После перемещения юнит выбирает действие. Самое базовое — атака. Логика атаки в тактической RPG обычно проста: определить цель в радиусе атаки, нанести урон по формуле, проверить, жив ли враг.

Формула урона может выглядеть так: Урон = Атака атакующего − Защита цели. Если результат меньше 1, урон равен 1 (чтобы нельзя было стать неуязвимым). Это формула из Fire Emblem, и она отлично работает для прототипа.

Обработка ввода: мышь и сетка

В тактической RPG ввод — это в основном мышь. Клик по клетке должен переводить координаты экрана в координаты сетки. В Godot это делается через метод local_to_map() у TileMapLayer:

Добавьте визуальный курсор — спрайт, который следует за мышью и «привязывается» к центру клетки. Это значительно улучшает ощущение тактической игры: игрок точно видит, куда он целится.

Практический кейс: ход боевого юнита

Соберём всё вместе. Полный цикл хода выглядит так:

Каждый шаг — отдельное состояние, отдельный скрипт, отдельная ответственность. Если завтра вы захотите добавить «Использовать предмет» — вы создаёте новое состояние, не трогая существующие.

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

Экономическая система и игровой интерфейс

Почему игроки Darkest Dungeon тщательно считают каждое золото перед вылазкой, а в большинстве самодельных RPG экономика ощущается бессмысленной — золото копится, тратить некуда, и к середине игры баланс разваливается? Ответ — в принципе дефицита и связи экономики с геймплеем. Экономическая система не существует в вакууме: каждое золото должно стоить решения, каждая покупка — влиять на тактику.

Три столпа игровой экономики

Любая экономическая система в RPG держится на трёх элементах: источники дохода, каналы расхода и регуляторы баланса. Если хотя бы один из них слаб — система ломается.

Источники дохода — откуда игрок получает ресурсы: награды за бой, продажа предметов, доход от контролируемых территорий, квестовые награды. В демо-версии достаточно двух-трёх источников.

Каналы расхода — куда игрок тратит ресурсы: покупка снаряжения, лечение, наём бойцов, улучшение базы. Ключевое правило: расходы должны быть вынужденными. Если игрок может обойтись без магазина — экономика мертва.

Регуляторы баланса — механизмы, которые не дают экономике «перекоситься»: инфляция (цены растут), налоги, случайные события (пожар уничтожил склад), ограниченные запасы у торговцев.

Модель данных: что хранить и как

Прежде чем писать UI, определите структуру данных. Для экономической системы RPG вам понадобятся как минимум:

Инвентарь игрока — список предметов с количеством. В Godot удобно использовать Dictionary, где ключ — ID предмета, значение — количество.

Обратите внимание на сигналы gold_changed и inventory_changed. Они позволяют UI обновляться автоматически, без постоянных проверок в цикле _process. Это паттерн реактивного интерфейса: данные изменились — UI перерисовался.

База предметов: Resource как контейнер данных

Каждый предмет в вашей игре — это набор характеристик: название, описание, цена покупки, цена продажи, иконка, эффект. В Godot 4 для этого идеально подходят ресурсы (Resources).

Теперь в редакторе: правый клик в файловом менеджере → New Resource → ItemData → заполняете поля → сохраняете как iron_sword.tres. Создаёте базу предметов как каталог файлов — каждый предмет отдельным ресурсом.

Для удобства загрузки всех предметов используйте базу данных — словарь, который загружается при старте игры:

Магазин: интерфейс покупки и продажи

Магазин — это UI-сцена, которая обращается к ResourceManager и ItemDatabase. Важно: магазин не хранит данные о золоте или инвентаре — он только отображает их и отправляет команды.

Структура сцены магазина:

Экономика и тактика: неразрывная связь

Самая частая ошибка — экономика, которая не влияет на бой. Если лучшее снаряжение даёт +2 к атаке, а разница между лучшим и худшим врагом — 50 HP, игроку всё равно, что покупать. Экономические решения должны быть тактически значимыми.

Пример баланса для демо:

| Предмет | Цена | Эффект | Тактическое значение | |---------|------|--------|---------------------| | Зелье лечения | 30 зол. | +25 HP | Спасает в критический момент | | Железный меч | 100 зол. | +5 атаки | Убивает врага на 1 ход быстрее | | Кожаная броня | 80 зол. | +3 защиты | Выживает на 1–2 хода дольше | | Катапульта (расходник) | 150 зол. | AoE урон 20 | Меняет расклад боя |

Каждая покупка — это выбор: лечить сейчас или накопить на меч? Купить броню танку или меч дамагеру? Именно эти решения делают экономику живой.

Баланс доходов и расходов

Чтобы экономика не сломалась, нужно контролировать поток ресурсов. Простой подход: после каждого боя игрок получает фиксированную награду, но между боями вынужден тратиться на лечение и пополнение расходников.

Пример расчёта для демо из 5 боёв:

Такой темп создаёт ощущение постоянного выбора и не позволяет игроку «перекупить» всё.

Инвентарь: UI и UX

Инвентарь — это не просто список предметов. Это инструмент принятия решений. Хороший инвентарь показывает не только что у вас есть, но и что это значит для текущей ситуации.

Минимальный UI инвентаря для тактической RPG:

Практический кейс: цикл «бой — магазин — бой»

Соберём экономический цикл для демо. Игрок видит глобальную карту с точками: боевые миссии и город. После боя — получает золото и предметы. В городе — магазин, где может потратить золото на снаряжение и расходники. Затем — следующий бой.

Ключевой момент: магазин должен быть доступен только между боями, а не во время боя. Это создаёт ритм: напряжение боя → расслабление и планирование в городе → снова бой. Именно этот ритм делает экономику осмысленной — вы готовитесь к неизвестному, распределяя ограниченные ресурсы.

Для реализации этого цикла используйте GameManager.current_state: если состояние EXPLORATION — магазин доступен; если COMBAT — нет. Магазин проверяет состояние при открытии и отказывается работать, если сейчас бой.

Экономическая система — это не цифры. Это арена для принятия решений. Каждое золото, каждый предмет — это вопрос: «Что для меня важнее прямо сейчас?» Если ваша экономика задаёт этот вопрос — она работает.

Диалоги, выбор и влияние нарратива на геймплей

Почему диалоги в Disco Elysium запоминаются на годы, а текстовые окна в большинстве инди-RPG игроки пропускают, нажимая «Далее»? Разница не в качестве текста — хотя он важен. Разница в том, что в Disco Elysium каждая реплика меняет что-то в игре: открывает новый путь, влияет на характеристики, определяет, кто ваш союзник, а кто — враг. Диалог — это не кат-сцена, это игровая механика.

Структура диалога: узлы и связи

Диалог в тактико-экономической RPG — это граф (graph): узлы с текстом, соединённые рёбрами выбора. Каждый узел — это реплика персонажа. Каждое ребро — это вариант ответа игрока. Ветвление может быть линейным (один путь), параллельным (несколько вариантов ведут к одному результату) или расходящимся (разные варианты — разные последствия).

Для хранения диалогов в Godot 4 лучше всего подходит JSON-файлы. Они читаются человеком, редактируются в любом текстовом редакторе и легко загружаются в игру.

Каждый узел содержит: speaker (кто говорит), text (текст реплики), choices (варианты ответа). Каждый выбор может содержать: next (куда ведёт), effect (что меняет в игре), condition (условие доступности).

Загрузка и парсинг диалогов

Скрипт DialogueManager загружает JSON, строит граф и отдаёт данные UI-компоненту. Важно: менеджер не отображает диалог — он только управляет логикой.

NarrativeManager: память о решениях игрока

NarrativeManager — это «дневник» игры. Он хранит флаги (булевы значения: сделал ли игрок выбор) и переменные (числовые значения: репутация, счётчики). Именно он позволяет игре «помнить» решения.

Флаги — это ключ к ветвящемуся нарративу. Если marvin_friendly == true, то в третьем акте Марвин предупредит игрока о засаде. Если knows_marvin_scam == true, то при следующей встрече откроется особый диалог. Каждый флаг — это семя, из которого вырастает уникальный опыт игрока.

UI диалога: отображение и ввод

Диалоговое окно — это Control-сцена, которая слушает сигналы DialogueManager. Минимальный набор элементов:

Влияние нарратива на геймплей: конкретные механики

Теперь самое важное: как диалоги меняют геймплей, а не просто рассказывают историю. Вот пять конкретных механик, которые можно реализовать в демо:

1. Открытие/закрытие путей. Флаг helped_merchants открывает торговый маршрут на карте. Без этого флага — путь заблокирован, игрок вынужден идти окольным путём через опасную зону.

2. Изменение состава врагов. Если игрок в диалоге оскорбил лорда, в следующем бою появятся элитные наёмники. Если убедил лорда — бой проще, но награда меньше.

3. Доступ к уникальным предметам. Торговец продаёт «Меч предков» только если reputation >= 70. Репутация растёт через диалоговые выборы.

4. Союзники в бою. Если игрок спас деревню в первом акте, жители-ополченцы присоединяются к отряду в финальном бою. Если нет — придётся справляться в меньшем составе.

5. Экономические последствия. Выбор «Обложить налогом крестьян» даёт +200 золото сейчас, но village_loyalty падает. Через три боя — крестьяне перестают поставлять припасы, и цены в магазине растут на 30%.

Практический кейс: цепочка «выбор — последствие»

Разберём конкретный сценарий для демо. Игрок приходит в деревню после первого боя. Староста просит помочь с разбойниками в лесу.

Выбор A: Помочь → бой с разбойниками → награда 100 зол. + флаг helped_village → в следующем акте деревня даёт бесплатные припасы.

Выбор B: Отказаться → пропускаем бой → экономим время и здоровье → флаг ignored_village → в следующем акте деревня закрыта, приходится покупать припасы по завышенным ценам.

Выбор C (если perception ≥ 4): «Разбойники — это ваши бывшие жители» → открывается переговорный путь → нет боя, нет награды, но флаг diplomatic_solution → в финале обе стороны помогают игроку.

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

Типографика текста: читаемость и атмосфера

Последний, но важный штрих — оформление текста. Godot 4 поддерживает BBCode в RichTextLabel: [b]жирный[/b], [i]курсив[/i], [color=red]красный[/color]. Используйте это для выделения имён персонажей, ключевых слов и эмоциональных акцентов.

Выберите два шрифта: один для диалогов (читаемый, с засечками или без — зависит от стиля), второй для интерфейса (компактный, технический). Размер — не менее 16 пикселей для диалогов. Фон панели — полупрозрачный, чтобы не перекрывать игровой мир полностью.

Диалоги в тактико-экономической RPG — это не текст между боями. Это третья ось геймплея, наравне с тактикой и экономикой. Когда выбор в диалоге влияет на следующий бой, а результат боя открывает новый диалог — рождается целостный игровой опыт.

Сборка, тестирование и отладка демо-версии

Вы потратили недели на механики, экономику и диалоги. Всё работает — по крайней мере, вам так кажется. Но стоит другу запустить игру, как он застревает в стене на втором бою, золото отображается с отрицательным значением, а диалог с торговцем зацикливается. Знакомо? Именно поэтому тестирование — не финальный этап, а непрерывный процесс, который начинается с первого написанного скрипта.

Стратегия тестирования: что, как и когда

Для демо-версии тактико-экономической RPG нет смысла внедрять автоматические тесты — это избыточно для масштаба проекта. Вместо этого сосредоточьтесь на ручном тестировании (manual testing) с чётким планом.

Разбейте тестирование на четыре слоя, каждый из которых проверяет свой аспект игры:

Слой 1: Механики. Работает ли перемещение? Наносится ли урон? Тратится ли золото? Это базовые проверки — «включается ли свет при нажатии выключателя».

Слой 2: Взаимодействия. Что происходит, если переместить юнита на клетку, где уже стоит другой? Что если купить предмет при ровно таком количестве золота, сколько стоит предмет? Что если использовать последнее зелье? Это проверка граничных случаев (edge cases).

Слой 3: Цепочки. Проходит ли полный цикл «бой → награда → магазин → следующий бой» без ошибок? Сохраняется ли прогресс между сценами? Это проверка интеграции систем.

Слой 4: Опыт. Понятен ли интерфейс? Чувствуется ли прогрессия? Не слишком ли легко или сложно? Это юзабилити-тестирование, и для него вам понадобятся внешние тестеры.

Чек-лист для демо тактико-экономической RPG

Вот конкретный чек-лист, который стоит пройти перед сборкой. Каждый пункт — отдельный сценарий, который нужно воспроизвести в игре:

| Категория | Что проверять | Ожидаемый результат | |-----------|---------------|---------------------| | Перемещение | Клик по доступной клетке | Юнит перемещается с анимацией | | Перемещение | Клик по занятой клетке | Ничего не происходит | | Перемещение | Клик за пределами дальности | Курсор не подсвечивает клетку | | Бой | Атака по врагу в радиусе | Урон наносится, HP уменьшается | | Бой | Атака по врагу вне радиуса | Действие недоступно | | Бой | Убийство врага | Враг удаляется, начисляется награда | | Бой | Гибель своего юнита | Юнит выбывает, бой продолжается | | Экономика | Покупка при достаточном золоте | Предмет в инвентаре, золото уменьшается | | Экономика | Покупка при недостаточном золоте | Сообщение об ошибке | | Экономика | Продажа предмета | Предмет удаляется, золото увеличивается | | Диалоги | Выбор варианта ответа | Переход к следующему узлу | | Диалоги | Выбор с условием (флаг не выполнен) | Вариант скрыт | | Диалоги | Влияние выбора на геймплей | Флаг устанавливается, последствие наступает | | Навигация | Переход между сценами | Сцена загружается без ошибок | | Навигация | Возврат из боя на карту | Прогресс сохранён |

Инструменты отладки в Godot 4

Godot 4 предоставляет мощные встроенные инструменты, о которых начинающие часто не знают.

Панель Output — сюда выводятся все print() и ошибки. Но для структурированной отладки лучше использовать push_warning() и push_error(): они подсвечиваются разными цветами и видны сразу.

Remote Inspector — при запущенной игре переключите панель Scene на вкладку Remote. Вы увидите живое дерево узлов и сможете менять значения свойств в реальном времени. Это бесценно для тестирования баланса: меняете HP врага прямо во время боя и смотрите, как меняется сложность.

Плагин DebugDraw — для визуализации скрытых данных. Рисуйте сетку доступных клеток прямо поверх игры, показывайте HP врагов числом над спрайтом, подсвечивайте триггерные зоны. В Godot 4 для этого можно использовать draw_line() и draw_rect() в узле, который обновляется каждый кадр.

Профилирование: поиск утечек производительности

Даже в 2D-игре возможны проблемы с производительностью. Godot 4 имеет встроенный Profiler (вкладка Debugger → Profiler). Он показывает, сколько времени занимает каждый скрипт за кадр.

Типичные проблемы в тактической RPG:

Экспорт проекта: сборка .exe

Когда тестирование пройдено, наступает время экспорта. Godot 4 позволяет собрать игру в исполняемый файл для Windows, macOS и Linux.

Перед первым экспортом необходимо установить Export Templates: Editor → Manage Export Templates → Download and Install. Это ~400 МБ шаблонов, которые Godot использует для сборки.

Затем: Project → Export → Add → Windows Desktop. Основные настройки:

| Параметр | Значение | Зачем | |----------|----------|-------| | Export Path | build/game_demo.exe | Куда сохранять | | Embed PCK | Включено | Всё в один файл, удобно для распространения | | Binary Format | 64-bit | Современные системы | | Icon | Ваш .ico файл | Иконка в проводнике | | Console | Выключено | Не показывать консоль (включите для отладки) |

Параметр Console — ваш друг при отладке: если включить, рядом с игрой откроется чёрное окно консоли, куда будут выводиться все print(), push_warning() и push_error(). Выключайте только для финальной сборки.

Тестирование на чистой машине

Критически важный шаг: протестируйте сборку на другом компьютере или в чистой среде. На вашей машине могут быть установлены зависимости, которые маскируют ошибки. Распространённые проблемы при экспорте:

Чтобы избежать этого, используйте только пути res:// и проверяйте настройки импорта для каждого ресурса: Inspector → Import → Export.

Сборка чек-листа: финальная проверка

Перед тем как отправить демо тестерам, пройдите этот финальный чек-лист:

Работа с обратной связью

Когда тестеры присылают отчёты, классифицируйте баги по критичности:

Самый ценный баг — тот, который вы не можете воспроизвести. Просите тестеров записывать точную последовательность действий: что нажали, в каком порядке, что было на экране. «Игра вылетела» — бесполезный отчёт. «Открыл магазин, купил зелье, закрыл магазин, кликнул на врага — вылет» — это отчёт, по которому можно найти баг.

Демо-версия — это не уменьшенная копия игры. Это доказательство концепции: механики работают, цикл увлекателен, нарратив цепляет. Каждый исправленный баг, каждый отзыв тестера — шаг к тому, чтобы доказательство стало убедительным.