Разработка мобильной RPG-игры
RPG — самый объёмный жанр по количеству взаимосвязанных систем. Инвентарь, квесты, диалоги, прокачка, боевая система, карта мира, save/load — и всё это должно работать согласованно, не создавая противоречивых состояний. Именно здесь «работает на прототипе, ломается в продакшне» — самая частая история.
Проблема согласованности состояния
Возьмём типичный сценарий: игрок принял квест «убить 10 волков», убил 8, закрыл игру, игра крашнулась при сохранении. Квест счётчик сбросился до 0, но в истории диалогов запись об принятии квеста осталась. При следующем запуске NPC предлагает квест снова, но с условием «квест уже принят». Это классический state inconsistency, который в RPG встречается повсеместно.
Решение — Event Sourcing для игрового прогресса. Вместо того чтобы хранить текущее состояние (questKillCount: 8), храним журнал событий: [QuestAccepted(questId=12), WolfKilled, WolfKilled, ...]. Текущее состояние всегда восстанавливается воспроизведением событий. При крэше теряются только события после последнего успешного flush — не всё сохранение целиком.
В Unity это реализуется через IGameEvent интерфейс и EventStore с сериализацией в локальный SQLite (через SQLite-net-pcl пакет). Flush на каждое важное событие + фоновый flush каждые 30 секунд через Coroutine или UniTask.
Диалоговая система и нарратив
Хранить диалоги в ScriptableObject удобно для 50 строк. При 5000 строках диалогов и ветвлении — нужна отдельная система. Варианты:
Ink (Inkle Studios) — открытый язык для нарративных игр, компилируется в JSON, runtime-библиотека для Unity (ink-unity-integration). Поддерживает ветвление, переменные состояния, условия. Нарративный дизайнер пишет в Inky editor, разработчик интегрирует готовый скрипт.
Yarn Spinner — альтернатива, более Unity-native, с визуальным редактором нод прямо в Unity Editor. Удобнее для небольших команд, где дизайнер работает внутри Unity.
Оба решения поддерживают локализацию: строки извлекаются в CSV/XLIFF, переводчик работает с таблицами, не касаясь скрипта.
Инвентарь и предметы: архитектурные решения
Инвентарь — место, где «умные» решения чаще всего создают проблемы. Типичная ошибка: создать BaseItem класс и наследовать от него Sword, Potion, QuestItem. Через 6 месяцев появляется PoisonedQuestSword и иерархия ломается.
Правильный подход — Composition over Inheritance через компоненты или Data-Driven дизайн. Каждый предмет — это набор компонентов-данных: DamageComponent, ConsumableComponent, QuestMarkerComponent. Система обрабатывает компоненты независимо. Добавить новый тип предмета — значит добавить новый компонент, не трогать существующий код.
ScriptableObject как ItemDefinition (статичные данные: название, иконка, базовые статы) + runtime ItemInstance (динамические данные: модификаторы, durability, кастомное имя). Так можно иметь 500 типов предметов в памяти как SO-ссылки и только реальные экземпляры в инвентаре как объекты.
Боевая система и turn-based механики
Для пошаговых RPG — State Machine на каждого участника боя (PlayerIdle → PlayerSelectAction → EnemyTurn → AnimatingResult → ...) через паттерн Command для боевых действий. Каждое действие — объект ICombatAction с методами Execute() и Undo(). Undo() нужен не только для «отмены хода», но и для корректной работы анимационных прерываний.
Для action-RPG — смотри архитектурные решения из раздела хардкорных игр: ECS для симуляции, MonoBehaviour для представления.
Сохранения в облаке
На iOS — CloudKit через нативный плагин или через Game Center (iCloud saves). На Android — Google Play Saved Games (snapshots API). Обязательно реализовать conflict resolution: если игрок играл офлайн на двух устройствах, нужна стратегия слияния (по timestamp или по прогрессу).
Стоимость и сроки зависят от масштаба: лёгкая RPG с линейным сюжетом — 6–10 месяцев, открытый мир с несколькими классами, крафтом, мультиплеером — 14–24 месяца. Первый этап — всегда проектирование структуры данных и схемы сохранений. Переделывать это на середине разработки — дорого.
Инструменты разработки, которые экономят время
- Odin Inspector — кастомные редакторы для балансировки статов прямо в Unity Inspector без написания Editor-кода
- UniTask — async/await без GC allocations в Unity, критично для загрузки глав и диалогов без фризов
- Addressables + Remote Content Delivery — патчинг контента без обновления приложения
- Firebase Crashlytics — символизация крэшей с C++ стек трейсами (IL2CPP)
- Unity Test Framework — PlayMode тесты для боевой системы и save/load логики