Розробка системи навігації (NavMesh/Pathfinding) мобільної гри

Розробка системи навігації (NavMesh/Pathfinding) мобільної гри

Уявіть: мобільна RTS зі ста юнітами. Кожен використовує A* — FPS падає до 10. Наші системи навігації вирішують це. Ми займаємося розробкою навігаційних систем для мобільних ігор 5+ років, реалізували понад 20 проектів з NavMesh та pathfinding. Якісна навігація — різниця між іграбельним проектом і занедбаним прототипом. Розповімо, як вирішуємо задачі: від статичного NavMesh до Flow Field для рою агентів.

Ворог, який ходить крізь стіни, або NPC, що застряг у кутку — це не баг, це відсутність нормальної системи навігації. На мобільних пристроях додавання сотні агентів з повним pathfinding може впустити FPS до 15. Ми використовуємо комбінацію NavMesh, A* та Flow Field, щоб забезпечити плавний рух при мінімальному споживанні CPU. Наш досвід показує, що правильне налаштування NavMesh вже на етапі запікання усуває 80% проблем з навігацією. Ми гарантуємо, що кожен агент дійде до цілі без застрягань.

Як працює NavMesh на мобільних пристроях?

NavMesh — це спрощене представлення рівня, по якому може переміщатися агент. Будується один раз при завантаженні рівня (або заздалегідь запікається в редакторі). В Unity — вбудований NavMeshAgent, в Godot — NavigationServer3D.

Ключові параметри запікання NavMesh, які впливають на якість:

Agent Radius: 0.4      // радіус капсули агента — NavMesh будується з відступом
Agent Height: 1.8      // висота — для виявлення низьких проходів
Max Slope: 45°         // максимальний кут підйому
Step Height: 0.4       // висота сходинки, яку агент долає

На мобільних пристроях важливо: запікайте NavMesh заздалегідь в Editor, а не в runtime. Runtime baking (через NavMeshBuilder.BuildNavMeshAsync) займає 100–500ms і створює GC тиск. Для динамічних перешкод використовуйте NavMeshObstacle з Carve = true — він вирізає себе з NavMesh за 10–30ms.

Чому A* не завжди підходить для масових агентів?

Для пошуку шляху Unity використовує вбудований A* алгоритм з евристикою Euclidean distance. Для більшості мобільних ігор це оптимально. Але є сценарії, де стандартний A* не справляється:

• Динамічні перешкоди — гравець виставив барикади, двері закрилися. Рішення — NavMeshObstacle з Carve = true, але перерахунок затратний. Альтернатива для частих змін — Flow Field pathfinding: заздалегідь розраховуємо векторне поле для цілі, агенти слідують по полю без індивідуального пошуку шляху.
• Багато агентів до однієї цілі — зомбі-ігри, tower defense. A* для кожного агента окремо при 100+ агентах вбиває продуктивність. Flow Field розраховується один раз для всього поля — агенти зчитують значення своєї комірки. O(1) на агента проти O(n log n) для A*.

Flow Field в 5–10 разів швидше A* при 100+ агентах — перевірено на реальних проектах. В одному кейсі ми знизили витрати на розробку на $2000, замінивши A* на Flow Field.

// Unity: базовий Flow Field запит для тайлової карти
public class FlowField {
    private Vector2[,] directions;
    private int width, height;

    public void Calculate(Vector2Int target, bool[,] obstacles) {
        var costField = new int[width, height];
        var queue = new Queue<Vector2Int>();
        queue.Enqueue(target);
        costField[target.x, target.y] = 0;

        while (queue.Count > 0) {
            var current = queue.Dequeue();
            foreach (var neighbor in GetNeighbors(current)) {
                if (!obstacles[neighbor.x, neighbor.y] &&
                    costField[neighbor.x, neighbor.y] == int.MaxValue) {
                    costField[neighbor.x, neighbor.y] = costField[current.x, current.y] + 1;
                    queue.Enqueue(neighbor);
                }
            }
        }
    }

    public Vector2 GetDirection(Vector2Int position) => directions[position.x, position.y];
}

Як реалізувати плавний рух NPC?

Pathfinding дає маршрут — список точок. Steering behaviours перетворюють це в плавний рух:

• Seek / Arrive: рух до цілі з уповільненням при наближенні
• Obstacle Avoidance: обхід динамічних перешкод через Raycast (дистанція 2–3 юніти)
• Separation: агенти не накопичуються в одній точці (радіус 1.5 юніта)
• Cohesion: група тримається разом (для зграйної поведінки)

NavMeshAgent включає базові steering behaviours. Для тонкого налаштування — RVOSimulator з пакету com.unity.ai.navigation (алгоритм ORCA). Це дає реалістичне уникнення зіткнень без взаємних застрягань.

Як забезпечити продуктивність на мобільних?

Не перераховуй шлях кожен кадр. NavMeshAgent.SetDestination() при кожному виклику запускає новий pathfinding запит. Для переслідування гравця достатньо перераховувати кожні 0.3–0.5 секунди:

private float pathUpdateTimer = 0f;
private const float PATH_UPDATE_INTERVAL = 0.3f;

void Update() {
    pathUpdateTimer += Time.deltaTime;
    if (pathUpdateTimer >= PATH_UPDATE_INTERVAL) {
        agent.SetDestination(player.position);
        pathUpdateTimer = 0f;
    }
}

LOD для навігації. Агенти за кадром вимикають NavMeshAgent, використовують телепортацію до waypoints. Вмикаємо повний pathfinding тільки при потраплянні в frustum. Це економить 30% CPU.

Unity Job System для A*. Якщо потрібен кастомний pathfinding на великій карті — IJob + NativeArray<> виносить обчислення з main thread. Burst Compiler дає ~10x прискорення. В одному з проектів ми знизили час прорахунку шляху з 5ms до 0.4ms.

Налагодження та візуалізація

Pathfinding складно налагоджувати без візуалізації. В Editor малюємо NavMesh path:

void OnDrawGizmos() {
    if (agent != null && agent.hasPath) {
        Gizmos.color = Color.yellow;
        var corners = agent.path.corners;
        for (int i = 0; i < corners.Length - 1; i++) {
            Gizmos.DrawLine(corners[i], corners[i + 1]);
        }
    }
}

Ми також використовуємо Unity NavMesh документація для перевірки параметрів baking.

Процес роботи

1. Аналіз рівня — статична геометрія, динамічні перешкоди, кількість агентів (не більше 500 на середньому пристрої).
2. Вибір алгоритму — NavMesh + A* для типових сценаріїв, Flow Field для масових агентів.
3. Налаштування NavMesh — параметри baking, інтеграція з геометрією.
4. Реалізація steering — налаштування плавності, обхід перешкод.
5. Оптимізація — LOD, інтервали оновлення, Job System.
6. Тестування — на цільових пристроях з Unity Profiler (FPS, пам'ять).

Що входить в роботу

• Готова система навігації з вихідним кодом
• Документація по налаштуванню параметрів NavMesh
• Навчання команди (2 години онлайн)
• 2 тижні технічної підтримки після здачі
• Адаптація під target-пристрої (iOS/Android)

Замовте розробку навігаційної системи — отримайте консультацію та кошторис протягом 24 годин.

Орієнтовні терміни

• Базова навігація через NavMeshAgent для 5–10 типів агентів — 3–5 днів.
• Кастомна система з Flow Field, динамічними перешкодами та LOD оптимізацією — 2–4 тижні.

Зв'яжіться з нами для обговорення вашого проекту. Ми безкоштовно проаналізуємо сценарій і запропонуємо оптимальне рішення.

Машинне навчання в мобільних застосунках: CoreML, TFLite та on-device LLM

Ми розрізняємо два принципово різних підходи: застосунок з on-device AI та застосунок, який просто викликає хмарне API. Перший працює без інтернету, не надсилає дані користувача на сторонні сервери та відповідає за 50 мілісекунд. Другий залежить від затримки мережі та тарифного плану. Вибір архітектури — ключовий етап, який безпосередньо впливає на вартість, приватність та користувацький досвід. Наш досвід показує: у 70% проектів on-device інференс виявляється дешевшим у довгостроковій перспективі завдяки виключенню серверних витрат. Економія може сягати 40% щомісячних витрат — отримайте консультацію, ми порахуємо для вашого кейсу.

Як вибрати між CoreML та TFLite для on-device інференсу?

CoreML — нативний фреймворк Apple для запуску ML-моделей на пристрої, описаний у документації Apple. Підтримує Neural Engine (A11 Bionic та новіші), GPU та CPU як fallback. Моделі конвертуються у формат .mlmodel через coremltools з PyTorch, ONNX або TensorFlow. Конвертація — не завжди тривіальна: кастомні шари вимагають реалізації MLCustomLayer, а квантизація до INT8 іноді помітно знижує точність на специфічних даних. Ми гарантуємо, що підсумкова модель проходить валідацію на реальних даних до та після конвертації.

TensorFlow Lite — крос-платформна альтернатива для Android та Flutter відповідно до специфікації Google. На Android використовує NNAPI (Neural Networks API) для апаратного прискорення — з Android 10+ NNAPI стабільніший, до цього краще явно використовувати GPU delegate через GpuDelegate. Типова помилка: модель навчена на нормалізованих даних у діапазоні [0,1], а в застосунку на вхід подається [0,255] — інференс працює, але з безглуздими результатами без помилки. Ми включаємо модуль автоматичної валідації вхідних даних у SDK.

Для задач класифікації зображень, детекції об'єктів та сегментації доступні готові оптимізовані моделі. YOLOv8 у CoreML форматі запускає детекцію кадру 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite з GPU delegate — близько 8 мс на Pixel 7 при класифікації.

Що робити, якщо потрібна генерація тексту на пристрої?

Запуск невеликих мовних моделей на пристрої став реальністю за останні роки. Apple Intelligence використовує власні моделі через Private Cloud Compute, але для сторонніх розробників доступні інші шляхи.

llama.cpp з Metal backend на iOS — робочий підхід для phi-3-mini (3.8B параметрів, 4-bit квантизація, ~2.3 ГБ). Інференс: 15–25 токенів/секунду на iPhone 15 Pro. Для інтеграції в Swift використовуємо Swift Package llama.swift або обгортку через C-інтерфейс llama.h. Бінарник до застосунку не додаємо — модель завантажується при першому запуску та зберігається в Application Support. Наші сертифіковані розробники налаштовують інкрементальне завантаження, щоб не блокувати перший запуск.

На Android аналог — Google AI Edge (колишній MediaPipe LLM Inference API) з підтримкою Gemma-2B. Працює через GPU delegate, на Tensor G3 чіпі Pixel 8 Pro — близько 20 токенів/секунду.

Інтеграція OpenAI API та інших хмарних моделей

Для сценаріїв, де cloud inference допустимий, інтеграція OpenAI, Anthropic або Google Gemini — це HTTP клієнт + streaming SSE. У Swift зручно через AsyncThrowingStream для стрімінгових відповідей. У Kotlin — через Flow.

Критично важливо: API-ключі ніколи не зберігаються в бандлі застосунку. Навіть обфускований ключ витягується з IPA за 10 хвилин через strings або frida. Правильна архітектура: мобільний застосунок → власний backend → OpenAI API. Backend контролює rate limiting, логує запити, захищає ключ.

Що входить у роботу (результати)

• Навчена та квантизована модель під цільовий пристрій (документація за метриками)
• SDK для інтеграції (Swift/Kotlin/Flutter) з прикладами виклику
• Тести продуктивності на 3–5 реальних пристроях
• Інструкція з оновлення моделі OTA
• Підтримка при проходженні модерації App Store / Google Play (перевірка відповідності Guidelines 4.2, 5.1)
• 2 тижні технічної підтримки після релізу

Типовий пайплайн проекту

1. Аналіз завдання — вимірюємо latency, privacy, size, підтримувані пристрої.
2. Прототипування моделі — в Python, оцінка accuracy на цільових даних.
3. Конвертація та квантизація — під CoreML/TFLite з валідацією.
4. Інтеграція в застосунок — модель обгортається в сервісний шар (легко замінювати CoreML → TFLite → хмара).
5. Тестування — на реальних пристроях, вимір FPS, RAM, батареї.
6. Деплой — через TestFlight / Firebase App Distribution, моніторинг метрик.

Терміни: інтеграція готової CoreML/TFLite моделі — 1–2 тижні, розробка кастомної моделі з мобільною оптимізацією — від 6 тижнів, on-device LLM чат з персоналізацією — 4–8 тижнів.

Чому ми беремося за складні кейси?

10+ років досвіду в мобільній розробці, 50+ впроваджених AI/ML рішень, гарантія сумісності з актуальними версіями iOS та Android. Всі проекти проходять code review та навантажувальне тестування. У вартість вже входить підготовка документації для модерації та навчання вашої команди.

Зв'яжіться з нами — ми допоможемо вибрати архітектуру та впровадити ML у ваш застосунок під ключ. Замовте аудит наявного рішення — безкоштовно оцінимо потенціал економії серверних витрат. Отримайте консультацію експерта — напишіть нам сьогодні.