Немецкие составные слова вылезают за границу диалогового окна? Арабские тексты идут слева направо, ломая layout? Это не баги перевода — это проблемы технической локализации. Локализация — системная работа с текстом, шрифтами, форматированием, правилами склонения и размерами UI под каждый язык. Игра, которая «переведена», но не локализована, выглядит как машинный перевод: текст вылезает за кнопки, числа отображаются без учёта локали, а RTL-строки не зеркалятся.
Наш опыт — 10+ лет в геймдеве. Мы строили пайплайны для проектов с 15 языками, включая арабский, иврит, китайский. Мы используем Unity Localization — стандарт для Unity-проектов. Он работает через StringTable (текстовые строки с ключами) и AssetTable (локализованные ассеты). Таблицы экспортируются в XLIFF или CSV для передачи переводчикам.
Ключевой принцип: в коде и Prefab'ах — только ключи, никаких хардкоженных строк. Компонент LocalizedString на TextMeshProUGUI — обязательная архитектура. Нарушение этого правила означает ручной поиск всех текстовых строк по сцене — это сотни объектов при добавлении нового языка.
Как работает техническая локализация?
Техническая локализация начинается с аудита: проверяем код на хардкоженные строки, UI на негибкие layout-ы. Затем настраиваем StringTable/AssetTable, связываем ключи с элементами. Экспортируем в XLIFF для переводчиков, импортируем обратно с верификацией. После — псевдолокализация и тестирование. Для CJK-языков подключаем Dynamic Font Asset, для RTL — зеркалирование UI.
Почему псевдолокализация незаменима?
До получения реальных переводов мы запускаем псевдолокализацию: удлиняем все строки на 30–40% и добавляем случайные символы. Это выявляет переполнение контейнеров за 2–3 дня вместо обнаружения на этапе интеграции переводов. Без псевдолокализации вы рискуете получить баги за пару недель до релиза. Сравнение: псевдолокализация в 3 раза эффективнее обнаруживает проблемы с переполнением до передачи строк переводчикам, тогда как реальные переводы — только после импорта.
Что такое Dynamic Font Asset и зачем он нужен?
Для китайского, японского и корейского языков статический шрифтовой атлас весит 15–30 MB. Dynamic Font Asset загружает только встретившиеся в тексте глифы, сокращая память до нескольких сотен килобайт. Минус — микрофризы (0.5–2 мс) при первом рендере нового иероглифа, но для мобильных проектов это приемлемо.
| Характеристика |
Статический Font Asset |
Dynamic Font Asset |
| Память |
15–30 MB |
0.5–2 MB (зависит от текста) |
| Микрофризы |
Нет |
Да (0.5–2 мс при новых глифах) |
| Простота настройки |
Готовый атлас |
Требует указания диапазонов Unicode |
Для арабского и иврита обязательна поддержка RTL. В TextMeshPro есть встроенный RTL режим (TMP_Text.isRightToLeftText = true), но одного флага недостаточно. Элементы UI тоже должны зеркалиться: кнопка «Назад» перемещается с левого края на правый, список читается справа налево. Это требует специальной логики в Layout Manager или переключаемых Prefab'ов с зеркальным layout'ом для RTL-языков.
Из нашей практики: на проекте с поддержкой русского, английского и немецкого мы столкнулись с тем, что немецкие составные слова (например, Geschwindigkeitsbegrenzung) не переносятся в TextMeshPro по умолчанию. Решение — Hyphenation через TMP_Settings + подключение словаря переносов для немецкого. После настройки текст корректно переносится, контейнер диалога перестал переполняться.
Ориентировочные сроки
| Масштаб |
Сроки (без учёта времени перевода) |
| Добавление одного языка в готовый пайплайн |
3–7 дней |
| Построение пайплайна локализации с нуля (1–2 языка) |
1–3 недели |
| Полная локализация проекта (5–10 языков, RTL включая) |
4–10 недель |
| Интеграция с внешними CAT-инструментами + автоматизация |
1–3 недели |
Типичные ошибки при локализации
- Хардкоженные строки в коде и сценах — при добавлении языка приходится искать их вручную.
- Отсутствие RTL-зеркалирования UI — арабский текст идёт слева направо, ломая навигацию.
- Игнорирование множественных форм — в русском три числа, в английском два, в арабском шесть.
- Неиспользование псевдолокализации — баги с переполнением обнаруживаются только после интеграции переводов.
Что входит в нашу работу
Мы предоставляем полный цикл локализации под ключ:
- Аудит текущего кода и UI на готовность к локализации.
- Настройка пайплайна Unity Localization (или аналога для Unreal Engine).
- Создание StringTable/AssetTable, интеграция с CAT-инструментами.
- Разработка Dynamic Font Asset для CJK и RTL-языков.
- Псевдолокализация и тестирование переполнения UI.
- Автоматизация импорта/экспорта переводов.
- Документация по поддержке локализации для команды.
Свяжитесь с нами для аудита вашего проекта — мы подберём оптимальное решение. Получите консультацию инженера по локализации, чтобы избежать типичных ошибок и сократить время выхода на новые рынки.
Прототипирование и UX/UI для игр: архитектура, производительность, локализация
Открываете чужой Unity-проект — и видите: один Canvas на всю игру, сотня вложенных панелей, Layout Groups внутри Layout Groups, профайлер показывает 4 ms только на пересчёт UI в каждом кадре. Это не редкость. За 10+ лет работы мы разобрали сотни UI-систем — почти все страдали от отсутствия архитектуры с самого начала. В результате к середине разработки UI становится узким местом: каждый новый экран добавляет баги, производительность падает, правки занимают часы. Мы проектируем и реализуем игровой UI: от вайрфреймов до готовых компонентов в движке, с прицелом на производительность и поддерживаемость. Наш подход к прототипированию игрового интерфейса позволяет выявить 80% UX-проблем до написания кода. Свяжитесь с нами для консультации — оценим ваш проект.
Прототипирование и проектирование
Любой UI начинается с понимания информационных потоков: что игрок должен видеть в каждый момент, какие действия доступны, как переходить между экранами. Без этого разработка превращается в серию итераций «сделали — не то — переделали». Инструмент для прототипирования — Figma. Причина выбора не в моде, а в конкретных возможностях:
- Компонентная система с вариантами — позволяет проверить кнопку в состояниях Normal/Hover/Pressed/Disabled
- Auto Layout — честная симуляция поведения UI при разных размерах текста (критично для мультиязычных игр)
- Прототипы с переходами — тестируйте навигационный флоу до первой строки кода
На этапе прототипа выявляется большинство UX-проблем: неочевидные переходы, перегруженные экраны, неверная иерархия информации. Исправить это в Figma — 15 минут. Исправить в готовом проекте — полдня. Мы гарантируем, что каждый прототип сопровождается техническим заданием для разработчиков — это исключает двусмысленность при передаче в движок.
uGUI против UI Toolkit: что выбрать для нового проекта
В Unity сейчас два фреймворка для UI, и выбор между ними не очевиден. uGUI (Canvas-based) — зрелая система, существует с ранних версий Unity. Работает с RectTransform, богатая экосистема ассетов. Практически весь существующий игровой UI написан на uGUI.
UI Toolkit — система на основе XML (UXML) и CSS-подобных стилей (USS). Изначально создавалась для редакторных инструментов, с версии 2021 официально поддерживается для рантайм UI. Архитектурно ближе к веб-разработке.
UI Toolkit подходит для следующих сценариев:
- Новый проект, команда готова к обучению
- Нужна сложная система тем и скинов
- Активно разрабатываются кастомные редакторные инструменты
uGUI остаётся предпочтительным, если:
- Идёт поддержка существующего проекта
- Нужна максимальная совместимость с ассетами Asset Store
- Команда уже знает uGUI, сроки сжатые
Wikipedia: Unity (game engine) – UI подтверждает, что оба подхода активно используются в индустрии.
Как добиться производительного UI в Unity?
Это та область, где игровой UI кардинально отличается от UI в обычных приложениях. В игре UI обновляется каждый кадр, и неэффективная реализация может съедать 3–5 ms из бюджета кадра — напрямую влияя на FPS.
Как работает батчинг в Canvas
Unity объединяет элементы одного Canvas в единый draw call, если они используют одинаковый материал и текстурный атлас. Нарушение батча означает дополнительный draw call, что бьёт по производительности.
Батчинг ломают следующие факторы:
- Разные текстуры у соседних элементов (решение: спрайтовый атлас через Sprite Atlas)
- Mask компонент создаёт стенсил и разрывает батч (альтернатива: RectMask2D — работает дешевле)
- Canvas с разными Render Mode — батчинг работает только внутри одного Canvas
- Любой Graphic Raycaster добавляет overhead — ставьте его только на интерактивные Canvas
Разделение Canvas по типам контента
Главная рекомендация: разделяйте статичный и динамичный контент. Когда хоть один элемент в Canvas изменяется, Unity перестраивает геометрию всего Canvas. Если на одном Canvas живут статичная рамка HUD и анимированная шкала здоровья — каждую секунду Canvas перестраивается полностью. Это может снижать FPS на 15-20%.
Правильная структура:
Canvas (Screen Space - Overlay)
├── Canvas_Static — фоны, рамки, иконки без анимации
├── Canvas_Dynamic — HP-бары, таймеры, счётчик ресурсов
└── Canvas_Popup — модальные окна, уведомления
Каждый дочерний Canvas изолирует ребилд от родительского. Изменение в Canvas_Dynamic не трогает Canvas_Static.
Пошаговая настройка раздельного Canvas:
- Создайте корневой Canvas с Render Mode = Screen Space Overlay
- Внутри создайте пустые объекты GameObjects, каждому назначьте компонент Canvas
- Назовите их Static, Dynamic, Popup
- Перенесите существующие UI-элементы в соответствующие группы
- Убедитесь, что компонент Canvas Scaler настроен только на корневом Canvas (дочерние наследуют настройки)
Результат: сокращение времени перерисовки UI до 60% в сценах с динамическими HUD.
TextMeshPro и текстовые батчи
TextMeshPro — стандарт для текста в Unity. В отличие от старого Text, использует SDF-рендеринг: текст остаётся чётким при любом масштабе. Но у TMP есть нюанс: каждый уникальный шрифтовый атлас — отдельный материал, то есть отдельный draw call. Если в игре используется три варианта шрифта (основной, заголовочный, цифровой) плюс версии для каждого языка — батчинг текста разваливается. Решение: TMP Font Asset Creator с объединением глифов нужных языков в один атлас. Для кириллицы + латиницы + цифр обычно хватает одного атласа 2048×2048 — это сокращает draw calls на тексте до 1-2.
Как адаптировать UI под разные экраны?
Мобильные платформы добавляют задачу, которой нет на PC: UI должен корректно работать на 16:9, 18:9, 19.5:9, 4:3 и iPad-соотношениях одновременно. Ошибка в адаптации — одна из частых причин переделок, съедающих до 30% бюджета.
Инструменты:
- Canvas Scaler с режимом Scale With Screen Size — базовая настройка. Reference Resolution 1080×1920 для мобильных, Match параметр 0.5 (баланс между шириной и высотой)
- Anchor Presets — каждый элемент должен быть привязан к правильному краю или центру
- Safe Area — на устройствах с вырезом и скруглёнными углами кнопки не должны попадать в недоступную зону. Решение: Screen.safeArea в коде, корректирует RectTransform корневого элемента
Проверка делается не только в редакторе Game View — нужно физическое тестирование на устройствах или Device Simulator (встроен в Unity). Закажите аудит текущего UI — мы выявим узкие места за 2-3 дня.
Локализация UI
Это не отдельная задача, а требование к архитектуре с первого дня. Типичная проблема: UI спроектирован под русский текст, который занимает N символов. Немецкий перевод в полтора раза длиннее. Кнопки ломаются, текст вылезает за границы. На этапе проектирования мы выполняем:
- Все текстовые поля с Auto Size в TMP или явно заданными минимальным/максимальным размером
- Кнопки с Horizontal Layout Group + Content Size Fitter вместо фиксированной ширины
- Иконки и декоративные элементы не вставляем в строку с текстом через конкатенацию
Для реализации локализации используем Unity Localization Package (официальный) или I2 Localization (ассет, более гибкий для сложных случаев). Экономия времени на переделку при таком подходе — до 40%.
Что мы проверим в вашем UI за один день
- Анализ draw calls и батчинг (с помощью Frame Debugger)
- Перестройка Canvas (через Profiler, поиск лишних rebatch)
- Работа Raycaster (удаление лишних)
- Адаптивность (Safe Area, Anchor Presets)
- Локализация (тест на сверхдлинные строки)
- Качество шрифтов (атласы TMP, ошибки оверлапов)
Что входит в услугу
- Проектирование навигационной структуры и флоу экранов
- Прототипирование игрового интерфейса в Figma с передачей макетов в разработку
- Реализация UI-компонентов в Unity (uGUI или UI Toolkit)
- Аудит существующего UI по производительности: анализ draw calls, Canvas rebatch, лишних Raycaster
- Настройка системы локализации и проверка на длинных переводах
- Адаптация под мобильные соотношения сторон и Safe Area
Сроки: от 5 рабочих дней на аудит до 4 недель на полный цикл. Стоимость рассчитывается индивидуально — пишите, получите коммерческое предложение. 10+ лет в геймдеве, более 200 реализованных проектов гарантируют результат.
