Pull to refresh
0
Plarium
Разработчик мобильных и браузерных игр

Особенности разработки мобильной MMO RTS. Часть 5

Reading time 4 min
Views 5.9K


Содержание:


  1. Кто такие Technical Artists и зачем они нужны
  2. Оптимизация ресурсов
  3. Организация структуры ресурсов в проекте

В прошлых статьях я рассказывал об архитектуре, многопоточности, профилировании, оптимизации, но не писал о людях. Сегодня поговорим о Technical Artists и о том, чем они занимаются.

Кто такие Technical Artists и зачем они нужны


Где-то год назад мы поняли, что разработчикам стало довольно тяжело. Им нужно было выполнять сразу несколько задач:

  1. интегрировать графические ресурсы;
  2. профилировать;
  3. организовывать ресурсы в проекте.

Всё это занимало достаточно много времени. Нужно было разбираться в тонкостях работы игрового движка с ресурсами и откладывать написание кода. Ситуация изменилась, когда в проект пришел человек на позицию Technical Artist, с опытом работы с 3D. У него было отличное понимание теории работы с ресурсами и педантичность. После того как он стал членом команды, разработчики начали уделять больше времени коду. Мы решили собрать команду Technical Artists. Они решают следующие задачи:

  1. Интегрируют 3D, 2D графику и анимацию в проект.
  2. Тестируют графику, в частности 3D модели и анимацию.
  3. Оптимизируют графику как со стороны дизайна, так и со стороны ее корректной интеграции в Unity.
  4. Создают анимацию – особенно когда нужны кастомные шейдеры для специфических задач или тесная интеграция анимации с игровой функциональностью.
  5. Помогают художникам, моделлерам и аниматорам найти оптимальное решение графических проблем, в основном связанных со спецификой отображения импортированных моделей и графики в Unity. Иногда даже пишут простой инструментарий для дизайна игровых сцен и работы с графикой.
  6. Профилируют проект, находит узкие места в производительности графики, связанные с неправильным или неоптимальным использованием ресурсов.
  7. Много работают с графическими ресурсами: организовывают их, помогают разработчикам определить соотношения ресурсов в билде и в бандлах. Также проверяют корректное расположение ресурсов перед релизами.
  8. Оптимизируют размер ресурсов в проекте.

После перераспределения задач команде разработке стало легче дышать. Появились люди, которые взяли на себя ответственность за ресурсы в проекте.

Оптимизация ресурсов


Оптимизация ассетов в проекте – важный аспект работы Technical Artist. Нам важно, чтобы размер приложения оставался небольшим. Поэтому мы часто занимаемся оптимизацией 3D графики, UI-спрайтов и других изображений. Подробно о влиянии размера приложения на конверсию читайте в предыдущей статье.

Оптимизация графики


Используйте текстурную компрессию. Разные устройства поддерживают различные типы сжатия. Например, все iOS устройства поддерживают PVRTC-сжатие. На Android кроме PVRTC есть несколько других форматов: ETC, DXT, ATC, ASTC. PVRTC часто приводит к появлению графических артефактов, и мы по возможности их исправляем. Например, при разработке UI для iOS лучше использовать процедурные градиенты, а не градиентные спрайты. Еще можно завести отдельный атлас для таких градиентов и не использовать для него сжатие.

Вернемся на секунду к Technical Artist. Они занимаются еще и организацией атласов в проекте. Атласы помогают снизить нагрузку на GPU, объединяя несколько материалов в один. Это уменьшает число вызовов отрисовки.

Атласы стоит организовывать по категориям. Нет смысла хранить в одном атласе 2 текстуры, которые используются в разных частях проекта.

Отдельный вызов – максимально плотная упаковка атласов при огромном разнообразии размеров, пропорций и типов спрайтов.

Оптимизация 3D моделей


В этом процессе почти нет мелочей. Важно оптимизировать геометрию, развертку, переиспользовать текстуры. Очень много места можно потратить, банально забыв удалить ненужные ключи из запеченных анимаций. Часто в задачах оптимизации графики помогают кастомные шейдеры, которые позволяют из одних и тех же ассетов получать разные визуальные эффекты.

Организация структуры ресурсов в проекте


Организация ресурсов в проекте – тоже работа Technical Artists. Несмотря на то, что есть определенные правила организации ресурсов, разработчики иногда игнорируют их. Не со зла, конечно. Тут Technical Artists – последняя линия обороны перед безжалостным натиском хаоса.

Все ресурсы в проекте лежат в двух папках: Resources и ResourcesStatic. В Resources лежат ресурсы, которые инстанциируются в рантайме через Resource.Load. Иначе они просто не попадут в билд, потому что у Unity нет прямых ссылок на эти ресурсы.

В ResourcesStatic находятся все остальные ресурсы, которые Unity включит в билд только в том случае, если они являются зависимостью какого-то из ресурсов, которые в билд уже включены. Если какой-то из ресурсов перестанет использоваться, но останется лежать в проекте, в этой папке, он перестанет попадать в билд и влиять на размер приложения.

Последнее, о чем я сегодня расскажу – организация Editor-скриптов для Unity-компонентов. Мы долго обсуждали, где должны храниться эти файлы. В результате пришли к выводу, что оптимальнее всего размещать Editor-файл ближе всего к его компоненту. Например, если namespace компонента View.Common.Binding.Text, то его Editor-файл будет находится по пути: View.Common.Binding.Text.Editor. Такой подход неудобен тем, что приходится создавать большое количество Editor-папок. Но на билд это никак не влияет, а структура кода становится яснее.

Другие статьи из серии:


Tags:
Hubs:
+12
Comments 2
Comments Comments 2

Articles

Information

Website
company.plarium.com
Registered
Founded
2009
Employees
1,001–5,000 employees
Location
Израиль