Мы в компании давно работаем с Unity и не могли не пригласить их ребят на Pixonic DevGAMM Talks, который состоялся в сентябре.
Полевой инженер Валентин Симонов объяснил, как спланировать игровую архитектуру с учетом преимуществ новых технологий.
Unity работала над ними несколько лет, чтобы достичь недостижимого ранее уровня производительности.
Выступление можно послушать на YouTube, а транскрипт со слайдами прочитать прямо под катом.
Что, если я скажу вам, что вы можете увеличить производительность игры в 10 раз? На самом деле это не совсем так, но в каждой шутке есть доля правды.
Я хочу поговорить о том, над чем мы сейчас работаем, каким будет будущее Unity и что вы можете использовать уже сейчас.
На Unity делаются совершенно разные игры.
Вот примеры, которые я играю сам.
Они используют разные функции, требуют разной производительности и разного подхода к разработке.
И мы работаем над проектом, который называем «Производительность по умолчанию».
Это несколько специальных возможностей, которые при правильном использовании позволят вам добиться значительного увеличения производительности.
В некоторых задачах мы измеряли х10 и даже х11. Особенно в задачах моделирования большого количества объектов, взаимодействующих друг с другом.
Но когда мы говорим о производительности по умолчанию, мы имеем в виду, что вам придется изменить свой подход к разработке, сильно изменить свой подход к игровой архитектуре.
И, на самом деле, это нужно не всем.
Популярный вопрос: «Что вы делаете в своем ECS? Будете ли вы удалять все GameObjects, удалять все Transform, иерархию и компоненты? Нет, мы оставим все это позади.
Вы сможете работать с Unity точно так же, как и сейчас, но если вы хотите большей производительности, то вам необходимо знать о технологиях, о которых я хочу рассказать вкратце.
И я хочу упомянуть еще одну технологию под названием Scriptable Render Pipelines (SRP) — она позволяет более эффективно писать конвейер рендеринга для вашей игры.
Вы, наверное, видели демо, которое мы показали на одном из Unite. Здесь на ПК в реальном времени моделируется гигантское количество юнитов, что-то около 60 тысяч (доходит до 100 тысяч и начинает немного тормозить): И новые функции, о которых я хочу поговорить, это: система Entity Component System (ECS), система заданий C#, наш новый суперкомпилятор Burst и Scriptable Render Pipelines (SRP).
Повторяю: вам решать, хотите ли вы идти вперед вместе с нами, изучать новые технологии или вам нормально разрабатывать игры, которые уже хорошо зарабатывают и которые легко сделать.
Чтобы понять, что мы пытаемся решить, важно понять состояние аппаратного обеспечения в 2018 году.
Обратите внимание, как увеличивается производительность и количество ядер процессора.
В какой-то момент однопоточная производительность даже снизилась.
То есть теперь ядер у нас много, но их производительность растёт не так быстро.
Поэтому нам хотелось бы использовать мощность всех ядер.
У моего телефона 8 ядер: 4 сильных и 4 слабых.
А современный телефон может работать так же быстро, как современный компьютер (но не очень долго из-за перегрева).
Также необходимо понимать, что повышение производительности — это не только использование всех ядер, но и оптимизация производительности одного ядра.
И последняя картинка, которую мы всегда приводим в пример того, как производительность процессов увеличивается, но скорость доступа к памяти увеличивается не так сильно: 
Видно, что доступ к памяти сейчас очень медленный.
Производители процессоров делают многое, чтобы нивелировать эту разницу — добавляют кэши, процессоры занимаются спекулятивными вычислениями, пытаясь предсказать, какой код будет выполнен следующим.
И если мы не подумаем об этом, когда вы делаете свою игру (или когда мы делаем для вас движок), то мы не сможем в полной мере воспользоваться преимуществами современных процессоров.
Наверное, многие из вас часами рассматривают подобную картинку в Unity: 
Здесь видно, что многопоточность есть, но остальные ядра и потоки по большей части незаняты.
Что-то делается, но мне бы хотелось, чтобы они были заняты.
Теперь у нас есть рендеринг, это как черный ящик.
У вас есть выбор: вперед или отсрочка, а также различные настройки материалов, шейдеров, буферов команд и так далее.
Сделать красивую картинку можно, но многие алгоритмы крайне сложны в реализации.
И мы все знаем об архитектуре Unity: компоненты, GameObjects, иерархия Transform, весь код, все данные в MonoBehaviour и каждый компонент обрабатывает свои данные.
Но есть проблемы с нынешним положением дел.
Рано или поздно вы с этим сталкиваетесь и понимаете, что вам следует и чего не следует делать.
Иерархия объектов сама по себе имеет определенные накладные расходы, и некоторые объекты не обязательно должны быть GameObjects. А если у вас большое количество компонентов и обновлений к ним, то все становится гораздо медленнее.
я однажды написал Эта статья , что по-прежнему актуально, если вы хотите знать, чего не следует делать.
И самое главное в контексте процессоров — все компоненты, все данные разбросаны по памяти, что нарушает использование кэша процессора.
Теперь я хочу быстро пройтись по новым функциям.
Я не буду слишком подробно останавливаться на том, что такое ECS и как он работает. Дело в том, что у нас есть Entities, которые являются просто идентификаторами определенных сущностей в игре — они хранят данные в виде компонентов, т.е.
только данные, никакого кода.
И системы обрабатывают Сущность определенными компонентами и каким-то образом изменяют эти данные.
Почему мы делаем свою ECS и чем она будет лучше конкурентов? Есть несколько моментов.
Во-первых, это не совсем официально, но мы думаем, что именно так мы сейчас сделали бы движок.
Понятно, что мы не хотим избавляться от GameObjects, текущих компонентов Unity, полностью всё выкидывать и устанавливать ECS. Но мы хотим двигаться в сторону лучшего двигателя.
Мы делаем ставку на высокую производительность.
Недавно к нам присоединился Майк Эктон (если вы занимаетесь разработкой на C++, то знаете, что он один из евангелистов дата-ориентированного программирования).
И мы хотим, чтобы вся система работала как можно быстрее — быстрее, чем C++.
Мы также думаем о том, как нативно интегрировать разные вещи в ECS. Некоторое время назад мы объявили, что делаем новую сеть и она тоже основана на ECS — можно будет делать многопользовательскую игру на ECS и обмениваться кодом между клиентом и сервером.
Мы работаем над инструментами отладки в Unity. Те.
Пока что ECS существует как бы отдельно от GameObjects и компонентов, и это очень неудобно.
Мы хотим все упростить.
В настоящее время существует DebugView, который выглядит примерно так: 
Здесь вы можете увидеть, какие у вас есть Сущности, какие системы сколько времени обрабатывают, какие системы с какими компонентами работают, а также для каждого компонента вы можете увидеть в инспекторе, какие данные каждая Сущность имеет в компонентах (обратите внимание, что API часто меняется и многие руководства уже могут быть устаревшими).
Также, если вы слышали о нашей новой разработке Unity for Small Things (это очень маленький рантайм, позволяющий делать игры для мессенджеров) — там тоже все построено на ECS. В последнее время наблюдается бум разработки и перехода на ECS — это очень популярная технология и ее нужно знать каждому.
У нас проходит конференция для программистов, поэтому без слайда с кодом сложно обойтись.
Кода там очень много, поэтому сложно вытащить какой-то внятный кусок, чтобы что-то было понятно.
По сути, я взял из примера одну систему, которая работает с C# Job System (подробнее об этом позже), и мы многое делаем для уменьшения количества кода, добавляем синтаксический сахар.
Здесь есть система, которая работает с компонентами RotationData и ей также нужны преобразования GameObject, которые представлены специальной штукой под названием TransformAccessArray. И для каждого обновления системы мы создаем Job, запускаем этот Job, он где-то обновляется, может быть разделен на несколько групп и выполняться в разных потоках.
Как использовать его в проекте? Так же, как и в других реализациях ECS, нужно понимать, что думать придётся совершенно иначе (в отличие от GameObjects и Transforms).
И они привыкнут к этой мысли.
Понятно, что начинать нужно с самого начала проекта, потому что мне очень часто приходят вопросы типа «мы сделали игру и хотим перейти на ECS — какЭ» Это очень сложно сделать в готовой игре.
Необходимо продумать взаимодействие с Unity, поскольку ECS живет отдельно, в своем маленьком мире.
Мы предоставляем некоторые возможности для взаимодействия с GameObjects и Transforms, но физика, рендеринг и т. д. здесь становятся все более сложными.
А пока нам нужно смириться с тем, что большая часть привычного интерфейса будет недоступна, но мы над этим тоже работаем.
И сразу нужно задуматься о том, что вы будете писать системы в Job System, что гораздо эффективнее.
Несколько слов о системе заданий.
Мы хотим сделать это очень простым способом написания многопоточного кода.
При этом писать на C#, проверять все за вас, а не давать возможности допускать ошибки или показывать почему, где и как вы их допустили.
Мы ограничиваем возможности языка, которые вы можете использовать в Джобсе, и называем это подмножество C# High Performance C#.
У вас в Job-коде нет ссылок, нет строк, все данные нужно копировать — вы не можете использовать большое количество возможностей языка, тем самым значительно сложнее выстрелить себе в ногу многопоточностью.
Мы также представляем очень быстрые коллекции и интеграцию ECS. Такая структура ECS и системы заданий обеспечивает очень быстрое выполнение кода.
При этом мы не просто даем вам возможность использовать эти технологии — мы сами работаем с этими системами и создаем новые API, чтобы их можно было использовать в Джобсе.
Мы сделали асинхронные рейкасты для физики, с помощью которых вы можете сказать: «Я хочу 600 рейкастов, сделайте это для меня когда-нибудь, пожалуйста».
Мы работаем над использованием этих технологий для расширения существующих систем, таких как анимация через Playbles API. И мы думаем сделать на Unity новые системы, которые не будут закрыты на C++, но код которых будет на C# и доступен вам.
Если мы возьмем код Джоба, то он довольно прост. Job — это структура, имеющая метод Execute, в котором мы выполняем некоторую работу, запуская это задание.
Соответственно, наш внутренний Планировщик когда-нибудь поймет, где его лучше запускать, и разрешит все зависимости.
Здесь мы получаем JobHandle, который можно использовать в качестве зависимости для некоторых других заданий.
Как использовать его в проекте? Хорошо, если вы с самого начала используете Джобса, но здесь это не обязательно.
Если у вас есть какая-то система, критичная к производительности, например, моделирование, поиск пути, сеть или что-то еще, вы можете выяснить, как оптимизировать ее с помощью этого инструмента.
Но для этого нужно сделать несколько больших шагов и понять, как правильно хранить данные.
ECS позволяет правильно хранить данные, потому что мы отделяем данные от кода и наша реализация ECS хранит данные компонентов линейно в памяти, и при прогоне этих компонентов с какой-то системой вы используете все возможности процессора, все сохраняется в кеше и т. д. Мы стараемся делать это очень быстро.
Потом вы разбиваете эту работу на параллельные задачи, пишете код Job и запускаете его.
И (вероятно) у вас все работает. Конечно, нужно тестировать и, самое главное, тестировать на целевой платформе, в зависимости от количества ядер и т. д. Но использование Job System и ECS также, как я уже сказал, очень сильно влияет на то, как вы планируете архитектуру своей системы.
игра.
Дальше все гораздо проще.
Burst Compiler — наша уникальная технология, специальный компилятор этого подмножества C# (High Performance C#) в машинный код текущей платформы, на которой вы публикуете свой проект. 
Ребята сотворили какую-то магию, которую наверное кроме них никто не понимает, но эта штука ускоряет код Job в 10 раз, что супер круто.
И самое крутое, что это не требует от вас никаких действий — если у вас есть код Job, вы просто добавляете атрибут [BurstCompile], Burst компилирует ваш код, и вы получаете «бесплатную» производительность.
Это наша новая технология, и вы можете попробовать ее прямо сейчас.
Последнее, о чем я хочу вкратце упомянуть, — это Scriptable Render Pipeline (SRP), над которым мы работаем очень долгое время и который предназначен для того, чтобы дать вам возможность писать настраиваемый рендеринг для вашей конкретной игры.
Render Pipeline — это некий алгоритм, который выполняет отбор (какие объекты будут отрисовываться), рендеринг и постобработку.
Теперь у нас есть blackbox, который Forward или Deferred — они уже хороши, мы получаем очень крутую графику на мобильных телефонах, на ПК, на консолях.
Но у них есть много ограничений, поскольку их невозможно расширить.
Используя эту новую функцию SRP, вы можете написать свой Pipeline, можете что-то удалять оттуда, что-то добавлять, делать все, что захотите.
В настоящее время мы работаем над двумя примерами конвейеров.
Один LWRP, который мы ориентируем на мобильные телефоны и слабые устройства, и HDRP, который мы ориентируем на ПК, консоли и над которым работают очень известные люди в отрасли.
До этого они делали ААА-игры.
Вы, наверное, видели нашу демо-версию «Книги мертвых».
Здесь мы использовали HDRP, чтобы показать мощь этой технологии.
Чтобы этим воспользоваться, вам также придется совершить немало героических шагов, ведь почти ничего из того, что у нас сейчас есть, не совместимо с новым Pipeline. Те.
если вы обновитесь с Legacy, то мы предоставляем утилиту, которая обновит за вас большинство материалов, но вам нужно будет переписать шейдеры, т. е.
текстуры, скорее всего, будут выглядеть по-другому.
Очень здорово, если вы можете начать с нуля и поэкспериментировать со своим конвейером.
Если вы хотите что-то сделать в своем конвейере, свяжитесь с нами.
Опять же, поймите, что вам нужно, потому что теперь у вас больше возможностей что-то делать, но вам понадобятся люди, которые смогут это сделать, или вам придется научиться это делать.
Я думаю, это здорово, потому что те, кто будет двигаться вперед вместе с нами с этими новыми технологиями, будут более востребованы на рынке.
Вот и все, я надеюсь, что кто-то пойдет и посмотрит на эти технологии и сделает красивые, крутые игры.
Вопросы из зала
— Когда можно будет взять ECS и развивать его? — Можно использовать ECS, проблема в том, что в нынешнем виде он больше ориентирован на людей, ориентированных на производительность, т. е.какой-то ААА-проект. А задача Unity — сделать производительность по умолчанию доступной каждому.
Поэтому нам нужна какая-то система, надстройка к ECS, которая бы позволила нам использовать ECS с той же легкостью, с какой мы сейчас используем MonoBehaviour. Пока такого дополнения нет, не думаю, что ECS выйдет в полноценный релиз.
Иначе получается, что мы сделали функцию, которой будет пользоваться 1% наших пользователей.
И это не задача Unity. Я знаю людей, которые уже используют ECS в продакшене, просто имейте в виду, что эта функция еще находится в глубокой разработке и сейчас мы решаем, как сделать интерфейс максимально удобным для пользователя.
И следующая задача (не менее сложная) — как сделать какой-то API, который будет жить поверх этой ECS и позволит использовать его с той же легкостью, что и MonoBehaviour. Те.
На вопрос «когда именно» ответа нет. — ECS и другие пункты ориентированы на то, чтобы взять какой-то базовый GameObject и сделать 150 тысяч его клонов и управлять ими.
Что делать, если у меня мало объектов, но они имеют разные сущности? — Можно в принципе ничего не делать; данная технология не обязывает вас ее использовать.
Если вы можете повысить производительность с помощью этих технологий, вам следует их использовать.
Если для вас это не актуально, то вы продолжаете использовать Unity как есть.
Поэтому, пожалуйста, не паникуйте.
— У нас есть клиент на Unity, сервер на .
NET, мы пробовали сервер на Unity, ничего не получилось.
Но при этом я хочу использовать и на сервере технологии, которые есть в Unity. — Мы работаем над этим и понимаем, что сейчас не можем предоставить эффективное серверное решение.
Мы купили компанию Multiplay некоторое время назад, чтобы делать качественный хостинг для Unity-игр.
Мы занимаемся сетью отдельно, а также работаем над оптимизацией движка, чтобы можно было использовать больше возможностей.
Соответственно, когда все это соберется воедино, мы получим отличное многопользовательское решение.
Больше выступлений от Pixonic DevGAMM Talks
- Использование Consul для масштабирования сервисов с отслеживанием состояния (Иван Бубнов, DevOps в BIT.GAMES);
- CICD: плавное развертывание в распределенных кластерных системах без простоев (Егор Панов, системный администратор Pixonic);
- Попрактикуйтесь в использовании модели актера на серверной платформе игры Quake Champions. (Роман Рогозин, бэкенд-разработчик Sabre Interactive);
- Мета-серверная архитектура мобильного онлайн-шутера Tacticool (Павел Платто, ведущий инженер-программист PanzerDog);
- Принцип KISS в разработке (Константин Гладышев, ведущий игровой программист 1С Game Studios);
- Общая логика игры на клиенте и сервере (Антон Григорьев, заместитель технического директора Pixonic).
- Cucumber в облаке: использование BDD-скриптов для нагрузочного тестирования продукта (Антон Косякин, технический менеджер по продукту ALICE Platform).
-
Иконки Многих Платежных Систем
19 Oct, 24 -
Новогодний Подарок От Devexpress
19 Oct, 24 -
Ie9 Будет Поддерживать Непрозрачность
19 Oct, 24 -
Logjam — Новая Уязвимость В Tls
19 Oct, 24
