Розробка мобільного симулятора
Симулятори на мобільних — широкий спектр: від фермерських ігор з таймерами до повноцінних фізичних симуляцій транспорту або будівництва. Об'єднує їх одне: складні взаємопов'язані системи, які повинні працювати узгоджено та забезпечувати «живе» відчуття світу навіть при закритому додатку.
Оффлайн-симуляція: як світ живе без гравця
Головна технічна особливість симуляторів — 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 хороші для базової автомобільної фізики, але для нестандартних транспортних засобів їх обмеження швидко з'являються.
Важливо: фізичні симулятори з великою кількістю 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().
Менеджмент-симулятори: агентна модель
Для симуляторів типу «tycoon» (ресторан, аеропорт, лікарня) — агентна модель. Кожен 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 місяців; повноцінний tycoon або фізичний транспортний симулятор — 9–15 місяців.







