Разработка мобильного симулятора
Симуляторы на мобильных — широкий спектр: от фермерских игр с таймерами до полноценных физических симуляций транспорта или строительства. Объединяет их одно: сложные взаимосвязанные системы, которые должны работать согласованно и обеспечивать «живое» ощущение мира даже при закрытом приложении.
Офлайн-симуляция: как мир живёт без игрока
Главная техническая особенность симуляторов — offline progression. Игрок возвращается через 8 часов, и за это время должны были произойти события: созрели культуры, выработались ресурсы, завершились производственные цепочки.
Наивный подход — при открытии игры запустить цикл с шагом deltaTime и посчитать всё с момента последнего сохранения. Это работает для простых систем. При сложных взаимозависимостях (ресурс A нужен для производства B, B нужен для C, и у A может закончиться запас в середине периода) — нужна дискретная симуляция с фиксированным тиком.
Реализация: сохраняем lastTickTimestamp. При открытии вычисляем missedTicks = (now - lastTick) / tickInterval. Запускаем симуляцию на missedTicks шагов с tickInterval (например, 1 минута). Каждый тик — детерминированный: применяем производство, потребление, события. Ограничение: maxOfflineTicks (например, 8 часов = 480 тиков), остальное — теряется или накапливается в overflow buffer.
Физика в транспортных и строительных симуляторах
Для физических симуляторов (автобус, кран, дорожное строительство) в Unity используем Configurable Joint для сложных сочленений + Rigidbody.AddForceAtPosition для физически корректного управления. Стандартные WheelCollider хороши для базовой автомобильной физики, но для нестандартных транспортных средств их limitations быстро появляются.
Важно: физические симуляторы с большим количеством Rigidbody (30+) на сцене требуют настройки Physics.simulationMode. Использование SimulationMode.Script (ручной вызов Physics.Simulate(fixedDeltaTime)) даёт точный контроль над порядком шагов — критично когда физика сочетается с игровой логикой.
На Android физика с Vulkan и ARMv8 — значительно быстрее из-за NEON SIMD оптимизаций в PhysX. Если таргет — low-end Android с OpenGL ES 3.0, ограничивай количество активных rigidbody через Sleep Threshold и Rigidbody.IsSleeping().
Менеджмент-симуляторы: агентная модель
Для симуляторов типа «тайкун» (ресторан, аэропорт, больница) — агентная модель. Каждый NPC — автономный агент с Behaviour Tree или Utility AI. Unity NavMesh Agent для перемещения, кастомная система задач для действий (взять заказ, принести, убрать).
При большом количестве агентов (50+) переходим на ECS-based agents через Unity DOTS: позиции и состояния в NativeArray, путём вычисляем через Job System. NavMesh Agents на DOTS пока в preview, но для 2D изометрических симуляторов своя тайловая навигация через A Pathfinding Project* (Aron Granberg) даёт лучший результат.
Сохранение сложного состояния
Симуляторы с сотнями объектов и их состояниями — это сотни килобайт данных сохранения. JsonUtility Unity не справляется со сложными графами объектов. Используем Newtonsoft.Json (com.unity.nuget.newtonsoft-json) с кастомными конвертерами или MemoryPack для бинарной сериализации (быстрее в 5–10 раз для больших объёмов).
Автосохранение через UniTask.Delay на фоновом потоке — сериализация в Task.Run, запись на диск в UniTask.SwitchToMainThread минимальным способом. Крэш во время записи не должен портить существующее сохранение — пишем во временный файл, затем атомарно переименовываем.
Сроки: фермерский симулятор с основными механиками — 4–7 месяцев; полноценный тайкун или физический транспортный симулятор — 9–15 месяцев.