Разработка мобильной RPG-игры
Мы понимаем: RPG — самый объёмный жанр по количеству взаимосвязанных систем. Инвентарь, квесты, диалоги, прокачка, боевая система, карта мира, save/load — и всё это должно работать согласованно, не создавая противоречивых состояний. Именно здесь «работает на прототипе, ломается в продакшне» — самая частая история. Наш опыт 10+ лет и 50+ реализованных RPG-проектов позволяет избежать этих ловушек. Оценим ваш проект за 1 день — свяжитесь с нами.
Как избежать state inconsistency?
Возьмём типичный сценарий: игрок принял квест «убить 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. Наши тесты подтверждают: 99,9% сохранений без потерь.
Диалоговая система и нарратив
Хранить диалоги в 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-ссылки и только реальные экземпляры в инвентаре как объекты.
Почему Composition over Inheritance?
Наследование создаёт жёсткие связи. Когда появляется MagicSword с эффектом поджога, приходится создавать новый подкласс. В компонентной модели добавляем BurnEffectComponent — и всё. 80% ошибок инвентаря в наших проектах были связаны с неправильным наследованием. Переход на компоненты сократил баги на 70%.
Боевая система и turn-based механики
Для пошаговых RPG — State Machine на каждого участника боя (PlayerIdle → PlayerSelectAction → EnemyTurn → AnimatingResult → …) через паттерн Command для боевых действий. Каждое действие — объект ICombatAction с методами Execute() и Undo(). Undo() нужен не только для «отмены хода», но и для корректной работы анимационных прерываний.
Для action-RPG — смотри архитектурные решения из раздела хардкорных игр: ECS для симуляции, MonoBehaviour для представления.
Сохранения в облаке
| Платформа | Технология | Инструмент |
|---|---|---|
| iOS | CloudKit | Нативный плагин или Game Center |
| Android | Google Play Saved Games | Snapshots API |
Обязательно реализовать conflict resolution: если игрок играл офлайн на двух устройствах, нужна стратегия слияния (по timestamp или по прогрессу).
Инструменты разработки, которые экономят время
- 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 логики
Что входит в работу
- Проектирование архитектуры: схема данных, система событий, диаграммы состояний (документация)
- Реализация прототипа: MVP боевой системы, инвентаря, диалогов
- Интеграция всех систем: квесты, персонаж, магазин, облачные сохранения
- Тестирование: unit-тесты, PlayMode тесты, нагрузочное тестирование боёв
- Публикация в сторах: настройка App Store Connect и Google Play Console, подготовка метаданных
- Пост-релизная поддержка: 3 месяца баг-фиксинга, патчи контента, мониторинг
Сроки — от 6 до 24 месяцев в зависимости от масштаба. Стоимость рассчитывается индивидуально. Получите консультацию — обсудим ваш проект.