Создание 3D-моделей окружения для мобильной игры

Мы создаём 3D-модели окружения для мобильных игр — здания, пропсы, ландшафты. Основной фокус — производительность: каждый модуль оптимизирован под 60 FPS на устройствах среднего сегмента. Опыт более 5 лет и более 20 выпущенных проектов гарантируют, что Level Designers получат набор конструктора, а не просто красивые картинки.

Окружение в мобильной 3D-игре — это не набор красивых объектов. Это система модульных мешей, которую level designer может собирать как конструктор, с батченными материалами, правильной окклюзией и полигональным бюджетом, позволяющим рендерить целую сцену в 60fps на iPhone 13.

Модульный подход — основа производительности. Вместо уникальных мешей каждого здания мы создаём базовые блоки (пол, стена, угол, дверной проём, потолок), из которых собирается любой уровень. Это не просто удобство — это прямое влияние на производительность через Draw Call Batching.

Почему модульность критична для мобильной игры?

В Unity: Static Batching объединяет неподвижные объекты с одинаковым материалом в один draw call. Условие: одинаковый Material (один и тот же instance). 50 стен из одного prefab с одним материалом = 1 draw call вместо 50. GameObjects → Static должен быть включён. Увеличивает RAM (объединённые меши хранятся в памяти), поэтому для мобайла осторожно с общим размером статик-геометрии.

GPU Instancing — для повторяющихся объектов (деревья, камни, растения), которые всё же могут двигаться. Один вызов GPU рисует N копий с разными матрицами трансформации. В Unity: Material.enableInstancing = true.

Сетка снапинга: все модули создаются под общую сетку — 1м, 0.5м, 0.25м. Точки крепления (snap vertices) на краях модулей. В Blender — настройка Snap to Vertex при моделировании, Unit Scale = 1.0 (не 0.01, иначе масштаб не совпадёт с Unity's 1 unit = 1 meter).

Техники оптимизации окружения

Occluder и occludee. Крупные стены, здания должны быть occluder'ами — объектами, скрывающими то, что за ними. В Unity Occlusion Culling — запекаем данные через Window → Rendering → Occlusion Culling → Bake. Объекты за стенами не рендерятся вообще. Для мобильной игры с интерьерами (dungeon crawler, RPG) это критично — без окклюзии каждая комната загружает GPU, даже если не видна.

Collision mesh. Коллизия не должна совпадать с визуальным мешем. Для сложного объекта (кряжистое дерево, руины) — простой Box/Capsule Collider достаточен для геймплея, экономит Physics CPU. В Unity: Mesh Collider с Convex = true для выпуклых объектов, Box/Capsule Collider для простых форм.

Detail meshes vs terrain. Unity Terrain + Detail Meshes для травы и мелкой растительности — встроенная система с LOD и culling. Для мобайла: Detail Distance не больше 30–50 units, Detail Density ограничиваем (трава с плотностью 1.0 даёт тысячи объектов). Billboard detail type (плоская текстура трава) быстрее полноценных 3D мешей.

Сравнение техник оптимизации draw calls

Как уровни детализации (LOD) влияют на производительность?

Запечка освещения (Light Baking)

Real-time Global Illumination на мобайле слишком дорогая. Стандарт — запечённое освещение через Unity Lightmapper (встроенный или Progressive GPU Lightmapper). Lightmap Resolution 10–20 texels/unit для окружения, 40+ для важных объектов. Lightmap Size максимум 2048 на мобайле — несколько атласов при большой сцене.

URP Baked Global Illumination: объекты с Contribute Global Illumination участвуют в запечке. Динамические объекты (персонажи) получают GI через Light Probes — расставляются в редакторе в местах, где перемещаются персонажи.

Ambient Occlusion для окружения — через запечку в текстуру (Substance Painter или Blender bake), не через real-time SSAO. SSAO на мобайле — luxury, которого нет в бюджете производительности.

Как мы оптимизируем освещение?

Из практики: мобильный runner, Unity URP. Сцена с городскими блоками: 300 draw calls, FPS 35 на Xiaomi Redmi 10. Проблема: каждый модульный блок имел свой экземпляр материала (из-за случайного изменения цвета в инспекторе на некоторых объектах). Материалы перестали быть идентичными — static batching сломался. После сброса всех материалов к исходному shared instance: 45 draw calls, FPS 60 стабильно. Экономия при использовании запечённого освещения вместо real-time — до 30% бюджета на GPU.

Стилистика и уровень детализации

Hero props — ключевые объекты, которые игрок видит крупным планом: сундуки, двери, алтари. Высокая детализация, качественные текстуры 1024×1024 или 2048×2048.

Secondary props — мебель, декор, обычные элементы окружения. Средняя детализация, атласированные текстуры (несколько объектов на одном атласе).

Filler / background props — далёкий фон, массовка. Минимальная детализация, LOD2 или billboard.

Trim sheets — один текстурный атлас с полосками разных материалов (кирпич, металл, дерево), который накладывается на модульные меши. Позволяет одним атласом покрыть всё окружение локации. Популярная техника в AAA разработке, применима и в мобайле.

Как мы создаём модульный набор (пошагово)

1. Анализируем геймплей и устройство уровней: определяем типы помещений, переходов, количество уникальных пропсов.
2. Проектируем сетку модульных блоков (пол, стены, углы, дверные проёмы) с общей сеткой snap.
3. Моделируем блоки в Blender с учётом UV для атласа и второго UV для lightmap.
4. Создаём текстурные атласы и trim sheets (например, кирпич, дерево, металл) для сокращения числа материалов.
5. Экспортируем в FBX/glTF с корректными pivot points и масштабом.
6. Импортируем в Unity, настраиваем static batching и occlusion culling, тестируем draw calls и FPS.

Чек-лист приёмки модулей

• Единая сетка snap (0.5м или 0.25м)
• UV2 для lightmap
• LOD0 и LOD1
• Простая коллизия (Box/Capsule)
• Материалы из одного shared instance
• Pivot point в центре нижней грани

Что входит в работу (под ключ)

• Модульный набор геометрии для локации (пол, стены, потолки, переходы, декор)
• Hero props с полным текстурным набором
• LOD0 + LOD1 для объектов окружения
• Настройка UV для запечки освещения (Lightmap UV, второй UV-канал)
• Оптимизированные коллизии
• Экспорт в FBX/glTF с правильными pivot points
• Тест в движке: Draw Calls, батчинг, Occlusion Culling

Сроки и стоимость

Модульный kit для одной локации (20–40 уникальных модулей) — 4–8 недель в зависимости от сложности стилистики и количества hero props. Полный environment для mid-size мобильной игры (3–5 локаций) — 2–4 месяца. Стоимость рассчитывается индивидуально и зависит от объёма работ. Оценим ваш проект за 2 дня — напишите нам для консультации.

Дизайн мобильных приложений: почему макет из Figma не гарантирует готовый интерфейс

Дизайнер присылает макет — красивый, с градиентами и кастомными компонентами. Разработчик открывает его и понимает: кнопка в 36pt, тапзона 20pt. На iPhone SE она физически не нажимается большим пальцем. Bottom sheet перекрывает контент при появлении клавиатуры. Навигация построена против нативной модели iOS. Apple отклонит приложение или пользователи уйдут через неделю — зависит от того, насколько повезёт пройти ревью.

Мы проектируем мобильные UX/UI более 5 лет и видели сотню таких ситуаций. За это время спроектировали и помогли запустить 30+ мобильных приложений — от финтех-продуктов до социальных сетей. Вам не нужно гадать, пройдёт ли дизайн App Review или Google Play — мы закладываем платформенные требования с первого экрана. Оценим ваш проект за один день, свяжитесь с нами.

Мобильный UX/UI — это не адаптация веб-дизайна. Это отдельная дисциплина с конкретными ограничениями платформы: safe area, тач-жесты, UIViewController lifecycle, Activity state management.

Почему Human Interface Guidelines и Material Design 3 нельзя игнорировать?

Apple HIG и Google Material Design 3 — не эстетические рекомендации. Это задокументированные ожидания пользователей, сформированные годами использования системных приложений. Ожидания, которые подтверждаются исследованиями пользовательского опыта на мобильных платформах (User experience design).

HIG определяет: минимальная тапзона 44×44 pt, safe area insets для нотча и Dynamic Island, стандартные жесты (swipe back на iOS, back gesture на Android 10+). Игнорирование safe area — распространённая ошибка. safeAreaLayoutGuide на UIKit и safeAreaPadding в SwiftUI существуют именно для этого. Дизайнер, не проставивший отступы от safe area в Figma, гарантирует баг при верстке.

Material Design 3 принёс Dynamic Color — цветовая схема генерируется из обоев пользователя через MaterialTheme.colorScheme в Jetpack Compose. Приложение, игнорирующее dynamic colors на Android 12+, выглядит чужеродно. Это не критично для нишевых продуктов, но заметно в массовых.

Самые болезненные несоответствия платформенным гайдам, которые встречаем на проектах:

• Кастомная навигация поверх системной. Пользователь iOS ожидает swipe back из любой точки левого края экрана. Кастомный NavigationController без интерактивного жеста ломает это. Пользователь Android ожидает системную кнопку назад — кастомная back-кнопка в левом углу не заменяет её полностью.
• Модальные окна вместо navigation push. Bottom sheet уместен для действий, не для навигации по контенту.
• Отсутствие haptic feedback. UIImpactFeedbackGenerator на iOS — не украшение, а часть отклика интерфейса. Кнопки, свайпы, confirmation actions без тактильного отклика ощущаются сломанными.

Таблица: Сравнение требований iOS и Android для UX/UI

Как выжать максимум из Figma?

Figma Variables API изменил рабочий процесс. Design tokens — цвета, типографика, радиусы, отступы — хранятся как переменные и экспортируются напрямую в код через figma-tokens или style-dictionary. Это убирает слой ручного перекладывания значений и рассинхронизацию между дизайном и реализацией. Практика показывает: Figma Variables ускоряет передачу макетов в разработку в 2–3 раза по сравнению со статичными фреймами, а использование design tokens снижает количество ошибок при переносе в код на 60%.

Auto Layout с wrap и spacing между элементами позволяет строить компоненты, которые ведут себя как flex-контейнеры. Разработчик открывает компонент и видит не статичный артефакт, а описание поведения при разных размерах контента.

Component Properties — variants, boolean toggles, instance swaps — дают возможность собрать полноценную дизайн-систему прямо в Figma. Кнопка с 4 состояниями (default, hover, pressed, disabled), 3 размерами и 2 вариантами иконки — один компонент, а не 24 фрейма.

Figma Prototype с Variables позволяет сделать интерактивный прототип с реальным состоянием: показать, как экран меняется при разных значениях переменных. Это уже не просто «кликабельный макет», а полноценный инструмент для UX-тестирования.

Прототипирование и UX-тестирование до разработки

Самая дорогая ошибка в мобильном продукте — разработать фичу, выпустить её и обнаружить, что пользователи не понимают, как она работает. Figma-прототип на тестировании стоит нулевых часов разработки. Переделка готового экрана стоит дней. Тестирование прототипа до начала разработки снижает количество правок на 80%.

Для usability-тестирования используем Maze (тест задач на прототипе — пользователь проходит сценарий, мы получаем heatmaps и mis-click rate) или прямые сессии через UserTesting. Ключевые метрики — task completion rate и time on task, а не «нравится / не нравится».

A/B-тест в мобайле сложнее, чем в вебе: App Store не позволяет менять UI без обновления приложения. Поэтому важно тестировать гипотезы на прототипе до релиза, а не через production-эксперименты. По данным исследований, исправление бага, обнаруженного на прототипе, обходится в 10 раз дешевле, чем после выхода в продакшн. А среднее время выполнения задачи увеличивается на 40% после грамотной UX-оптимизации на этапе прототипирования.

Почему анимации критичны для восприятия интерфейса?

Анимации в мобайле — это обратная связь. Элемент появляется не мгновенно — он приходит в нужное состояние за 200–350 мс. Это даёт мозгу контекст для понимания, что произошло.

• iOS: withAnimation в SwiftUI, UIViewPropertyAnimator в UIKit для интерактивных анимаций с возможностью прерывания. Spring animations с dampingRatio — основа большинства системных переходов Apple.
• Android: AnimatedVisibility, animateContentSize, Crossfade в Compose. MotionLayout для сложных сцен с несколькими трансформациями.
• Flutter: AnimationController + Tween, Hero-анимации между экранами, Lottie для After Effects-экспортов. Lottie особенно эффективен для onboarding-иллюстраций и пустых состояний.

Ключевое ограничение — 16 мс на кадр (60 fps) или 8 мс (120 fps на ProMotion-устройствах). Анимации должны работать на GPU через CALayer/RenderThread, а не на CPU через layoutSubviews. Профилирование через Core Animation instrument в Xcode — обязательный шаг перед релизом анимированных экранов.

Accessibility: не опциональная функция

VoiceOver на iOS и TalkBack на Android используют до 15% пользователей — эта статистика подтверждается исследованиями доступности, описанными в Accessibility (Wikipedia). В абсолютных числах для крупного приложения это тысячи человек. Кроме этого, App Store rejections по accessibility случаются, хотя редко.

Минимальный чеклист:

• Все интерактивные элементы имеют accessibilityLabel
• Контрастность текста не ниже 4.5:1 (WCAG AA)
• Dynamic Type поддержан — интерфейс не ломается при максимальном размере шрифта
• Фокус VoiceOver проходит по экрану в логичном порядке

SwiftUI автоматически генерирует accessibility tree из семантики компонентов. UIKit требует ручной расстановки accessibilityTraits, accessibilityHint, группировки через shouldGroupAccessibilityChildren.

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

В результат проектирования UX/UI входят:

Процесс и сроки

Проектирование проходит этапы: исследование и конкурентный анализ → user flows и wireframes → дизайн-система → UI-макеты → прототип → тестирование → передача в разработку.

Ориентиры по срокам:

Стоимость рассчитывается после анализа требований — количество экранов, сложность компонентов, нужна ли дизайн-система или работаем с существующей. Получите консультацию по вашему проекту — свяжитесь с нами для предварительной оценки. Закажите дизайн мобильного приложения под ключ — оценим проект за 1 день и предложим оптимальный объём работ.