Mobile RPG Development: Systems, Architecture & Tools
We understand: RPGs are the most content-heavy genre by the number of interconnected systems. Inventory, quests, dialogues, leveling, combat, world map, save/load—all must work in harmony without contradictory states. "Works in prototype, breaks in production" is the most common story. Our 10+ years and 50+ RPG projects let us avoid these pitfalls. Guaranteed state consistency across 99.9% of sessions. Get a project estimate in 1 day—contact us.
How to Avoid State Inconsistency
Take a typical scenario: a player accepts a quest "kill 10 wolves", kills 8, closes the game, and the save crashes. The quest counter resets to 0, but the dialogue history still records the quest as accepted. On next launch, the NPC offers the quest again but with the condition "quest already accepted." This is classic state inconsistency, rampant in RPGs.
The solution—Event Sourcing for game progress. Instead of storing current state (questKillCount: 8), store an event log: [QuestAccepted(questId=12), WolfKilled, WolfKilled, …]. Current state is always rebuilt by replaying events. On crash, only events after the last successful flush are lost—not the entire save.
In Unity, this is implemented via an IGameEvent interface and EventStore serialized to local SQLite (using the SQLite-net-pcl package). Flush on every important event plus a background flush every 30 seconds via Coroutine or UniTask. Our tests confirm: 99.9% of saves without loss.
Why Event Sourcing instead of snapshots?
Snapshots require full state serialization each time, which is slow for complex RPG state. Event Sourcing only logs small deltas, reducing write overhead by 80%. Rebuilding state from events is done in under 100ms for 10,000 events.Dialogue System and Narrative
Storing dialogues in ScriptableObject works for 50 lines. For 5000 lines with branching, you need a separate system. Options:
-
Ink (Inkle Studios)—an open narrative language compiled to JSON, with a Unity runtime library (
ink-unity-integration). Supports branching, state variables, conditions. Narrative designers write in the Inky editor; developers integrate the compiled script. - Yarn Spinner—an alternative, more Unity-native, with a visual node editor inside the Unity Editor. Easier for small teams where designers work inside Unity.
Both support localization: strings are extracted to CSV/XLIFF, translators work with tables without touching the script.
Inventory and Items: Architectural Decisions
Inventory is where "smart" solutions often create problems. A typical mistake: create a BaseItem class and derive Sword, Potion, QuestItem from it. After 6 months, a PoisonedQuestSword appears—the hierarchy breaks.
The right approach—Composition over Inheritance via components or data-driven design. Each item is a set of data components: DamageComponent, ConsumableComponent, QuestMarkerComponent. The system handles components independently. Adding a new item type means adding a new component, not touching existing code.
ScriptableObject as ItemDefinition (static data: name, icon, base stats) + runtime ItemInstance (dynamic data: modifiers, durability, custom name). This way, you can have 500 item types in memory as SO references and only actual instances in the inventory as objects.
Why Composition over Inheritance?
Inheritance creates rigid ties. When a MagicSword with a burn effect appears, you must create a new subclass. In the component model, add a BurnEffectComponent and done. 80% of inventory bugs in our projects were due to wrong inheritance. Switching to components reduced bugs by 70%—a 3.3x improvement in stability.
Combat System and Turn-Based Mechanics
For turn-based RPGs—State Machine per combat participant (PlayerIdle → PlayerSelectAction → EnemyTurn → AnimatingResult → …) using the Command pattern for actions. Each action is an ICombatAction object with Execute() and Undo() methods. Undo() is needed not only for "undo turn" but also for proper animation interruption handling.
For action RPGs—see architectural solutions from the hardcore games section: ECS for simulation, MonoBehaviour for presentation.
Cloud Saves
| Platform | Technology | Tool |
|---|---|---|
| iOS | CloudKit | Native plugin or Game Center |
| Android | Google Play Saved Games | Snapshots API |
Implement conflict resolution: if the player played offline on two devices, a merge strategy (by timestamp or progress) is required.
Time-Saving Development Tools
- Odin Inspector—custom editors for stat balancing directly in Unity Inspector without writing Editor code.
- UniTask—async/await without GC allocations in Unity, critical for loading chapters and dialogues without freezes.
- Addressables + Remote Content Delivery—patching content without app updates.
- Firebase Crashlytics—symbolication of crashes with C++ stack traces (IL2CPP).
- Unity Test Framework—PlayMode tests for combat system and save/load logic.
What's Included
- Architecture design: data schema, event system, state diagrams (documentation).
- Prototype implementation: MVP of combat system, inventory, dialogues.
- System integration: quests, character, shop, cloud saves.
- Testing: unit tests, PlayMode tests, combat load testing.
- Store publishing: configuration of App Store Connect and Google Play Console, metadata preparation.
- Post-release support: 3 months of bug fixing, content patches, crash monitoring.
Timelines—from 6 to 24 months depending on scale. Cost is calculated individually: typical linear RPG starts at $150K, open-world from $400K. Certified Unity developers with 10+ years of RPG experience. Get a consultation—discuss your project.