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

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Разработка системы навигации (NavMesh/Pathfinding) мобильной игры
Сложный
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Разработка системы навигации (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*.
Характеристика A* Flow Field
Вычислительная сложность на агента O(n log n) O(1)
Поддержка динамических препятствий Требует перестроения пути для каждого агента Требует перерасчёта поля (1 раз для всех)
Память Малый (путь агента) Средний (векторное поле размером карты)
Рекомендуемое количество агентов До 50 50–500
Лучший сценарий Разреженные агенты, редкие изменения Роевое поведение, стабильная карта

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.

Детали оптимизации кода

Для Flow Field используем NativeArray<Vector2> с Job System — это даёт 10x ускорение на мобильных устройствах.

Процесс работы

  1. Анализ уровня — статическая геометрия, динамические препятствия, число агентов (не более 500 на среднем устройстве).
  2. Выбор алгоритма — NavMesh + A* для типовых сценариев, Flow Field для массовых агентов.
  3. Настройка NavMesh — параметры baking, интеграция с геометрией.
  4. Реализация steering — настройка плавности, обход препятствий.
  5. Оптимизация — LOD, интервалы обновления, Job System.
  6. Тестирование — на целевых устройствах с Unity Profiler (FPS, память).
Этап Длительность Что входит
Анализ 1 день Оценка геометрии, числа NPC, производительности
Проектирование 1–2 дня Выбор алгоритма, спецификация AI
Реализация 3–10 дней Кодирование, интеграция с игровой логикой
Оптимизация 2–3 дня LOD, Job System, профилирование
Тестирование 1–2 дня Проверка на 3–5 устройствах

Что входит в работу

  • Готовая система навигации с исходным кодом
  • Документация по настройке параметров NavMesh
  • Обучение команды (2 часа онлайн)
  • 2 недели технической поддержки после сдачи
  • Адаптация под target-устройства (iOS/Android)

Закажите разработку навигационной системы — получите консультацию и смету в течение 24 часов.

Ориентировочные сроки

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

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

AI и ML в мобильных приложениях: CoreML, TFLite и on-device модели

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

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

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

TensorFlow Lite — кросс-платформенная альтернатива для Android и Flutter. На 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 при классификации.

Параметр CoreML TFLite
Платформы iOS, macOS, watchOS Android, iOS, Linux, embedded
Хардварное ускорение Neural Engine, GPU, CPU NNAPI, GPU (OpenCL/OpenGL), CPU
Поддержка квантизации FP16, INT8 (с coremltools) FP16, INT8, dynamic range
Кастомные операции Через MLCustomLayer (Swift) Через делегаты (Java/Kotlin)
Размер бандла модели ~3–5 МБ (MobileNetV2 quantized) ~2–4 МБ

Что делать, если нужна генерация текста на устройстве?

Запуск небольших языковых моделей на устройстве стал реальностью в последние несколько лет. 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 токенов/секунду.

Ограничения реальны: модели больше 4B параметров на мобильных устройствах по-прежнему медленны. Для сложных задач рассуждения on-device LLM уступает GPT-4o в качестве. Гибридный подход — on-device для коротких задач и приватных данных, облако для сложных запросов — часто оптимален. Оценим ваш кейс и предложим баланс производительности и приватности — пишите.

Интеграция 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, логирует запросы, защищает ключ.

Что входит в работу (deliverables)

  • Обученная и квантизированная модель под целевое устройство (документация по метрикам)
  • 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 в ваше приложение под ключ. Закажите аудит существующего решения — бесплатно оценим потенциал экономии серверных затрат (в некоторых проектах экономия достигает $10k в месяц).