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



    Содержание:


    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-папок. Но на билд это никак не влияет, а структура кода становится яснее.

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


    • +12
    • 4,8k
    • 2
    Plarium 74,42
    Разработчик мобильных и браузерных игр
    Поделиться публикацией
    Комментарии 2
    • 0
      Забыли добавить ссылку в тексте статьи: Подробно о влиянии размера приложения на конверсию читайте в предыдущей статье (ссылка).

      Ну а в целом, спасибо, было познавательно почитать будучи инди-разработчиком.
      • 0
        Спасибо! Исправили :)

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое