We often get orders for mobile simulators – from farming timer games to full-scale physical simulations of transport or construction. They all share one thing: complex interconnected systems that must work in sync and provide a "living" world feel even when the app is closed. We develop such projects turnkey: from concept to store release.
How to ensure offline progression without data loss?
The main technical feature of simulators is offline progression. The player returns after 8 hours, and events should have occurred: crops ripened, resources generated, production chains completed.
A naive approach: on app open, run a loop with deltaTime step and calculate everything from the last save. This works for simple systems. For complex interdependencies (resource A needed for B, B for C, and A may run out mid-period), you need discrete simulation with a fixed tick.
Follow these steps:
- Save
lastTickTimestampand game state each tick. - On resume, compute
missedTicks = (now - lastTick) / tickInterval. - Run simulation for
missedTickssteps withtickInterval(e.g., 1 minute). Each tick is deterministic: apply production, consumption, events. - Limit
maxOfflineTicks(e.g., 8 hours = 480 ticks); overflow is lost or accumulated in a buffer.
| Method | Complexity | Performance | Suitable for |
|---|---|---|---|
| Simple loop on open | Low | High | Simple linear processes |
| Discrete simulation with ticks | Medium | Medium | Interdependent chains |
| Hybrid (ticks + triggers) | High | Low | Very complex event-driven systems |
For games with market economy (prices change every 15 minutes) we use a hybrid approach: ticks for base production and separate events for external influences. This reduces CPU load by 30% compared to full simulation.
Physics in transport and construction simulators
For physical simulators (bus, crane, road construction) in Unity we use Configurable Joint for complex articulations + Rigidbody.AddForceAtPosition for physically correct control. Standard WheelCollider is good for basic car physics, but its limitations quickly appear for non-standard vehicles.
Important: physical simulators with many Rigidbody (30+) on scene require tuning Physics.simulationMode. Using SimulationMode.Script (manual call Physics.Simulate(fixedDeltaTime)) gives precise control over step order – critical when physics combines with game logic.
On Android, physics with Vulkan and ARMv8 is significantly faster due to NEON SIMD optimizations in PhysX – achieving up to 2x speedup over OpenGL ES 3.0. If targeting low-end Android with OpenGL ES 3.0, limit active rigidbody count via Sleep Threshold and Rigidbody.IsSleeping().
| Parameter | Vulkan / ARMv8 | OpenGL ES 3.0 / ARMv7 |
|---|---|---|
| Physics speed | High (NEON SIMD) | Medium (no NEON) |
| Max active Rigidbody | 60+ | 30 |
| Recommended simulationMode | Automatic or Script | Script with manual control |
Why agent-based model fits management simulators?
For tycoon simulators (restaurant, airport, hospital) – agent-based model. Each NPC is an autonomous agent with Behaviour Tree or Utility AI. Unity NavMesh Agent for movement, custom task system for actions (take order, deliver, clean).
For 50+ agents, switch to ECS-based agents via Unity DOTS: positions and states in NativeArray, path calculations via Job System. Unity DOTS – official package for ECS. DOTS agents are up to 5x faster than MonoBehaviour agents for 100+ NPCs. NavMesh Agents on DOTS are still in preview, but for 2D isometric simulators, custom tile navigation with A* Pathfinding Project (Aron Granberg's A* Pathfinding Project) gives 3x better performance.
Example: waiter behavior in restaurant simulator
Agent: waiter. Behaviour Tree: - Take order (move to table, receive order) - Deliver order to kitchen (move to kitchen, pass order) - Pick up ready dishes (move to serving area, take tray) - Serve dishes to customers (move to table, give tray) - Clear dishes (move to table, take plates) Parallel: if free – take new order. If customer leaves without paying – call manager.Saving complex state
Simulators with hundreds of objects and their states – hundreds of kilobytes of save data. Unity's JsonUtility can't handle complex object graphs. We use Newtonsoft.Json with custom converters or MemoryPack for binary serialization (5–10x faster for large volumes). Autosave via UniTask.Delay on background thread – serialize in Task.Run, write to disk in UniTask.SwitchToMainThread with minimal impact. Crash during write must not corrupt existing save – write to temp file, then atomic rename.
What's included
- Concept document with architecture and metrics.
- Prototype of key mechanics (offline simulation, physics, agents).
- Full code with comments and README.
- Build instructions (iOS/Android).
- Post-release support – bug fixing, optimization, updates for new OS versions.
Timeline and cost
Development timeline: from 4 months for simple simulators to 15 months for complex projects with physics. Cost is calculated individually – contact us so we can assess your project within 2 days. Typical budgets start at $15,000 for a basic simulator, with proven results from 7+ years of experience and 15+ projects in stores.
We guarantee high-quality work and transparent communication. Reach out – we'll discuss your simulator details. Get a consultation for your project right now.