Архитектура не мешает геймдизайну?

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

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

DOD — сделай процессору приятно

Где-то после года разработки на UE4 мы поняли, что предоставляемый Epic Games функционал нас во многом не устраивает. И тогда, в поисках ускорения работы сервера, мы наткнулись на такую штуку как Data-oriented Design.(дизайн ориентированный на данные или просто DoD)

В чем же его особенность? Как я уже писал в прошлой заметке, тут важна история развития самих ЭВМ. Если быть точнее, в основном речь идет о росте производительности процессоров и памяти, которые не очень соотносятся.


Как видите, на графике прослеживается сильное отставание скорости доступа процессоров к оперативной памяти, а это значит, что каким бы классным и быстрым не был процессор (CPU), ваша оперативная память (RAM) будет ограничивать его.

Но не расстраивайтесь! Для того, чтобы снизить влияние этого разрыва, производители добавляют немного магии… Ой, нет, немного очень дорогой и быстрой памяти прямо на кристалл CPU. Эта память называется кешем и на сегодняшней день часто имеет аж целых 3 уровня. В характеристиках процессоров обычно пишут что-то вроде: «Объем кеша L1 64 КБ». Да, кеш измеряется в килобайтах, чем выше уровень кеша, тем он более медленный, но имеет немного больший объем.


Казалось бы, этой памяти довольно мало, но основная идея такой архитектуры в том, что небольшие блоки данных и программной логики в течение довольно короткого промежутка времени (миллионные доли секунды) могут снова понадобиться. А значит, разумнее держать их как можно «ближе», чтобы не приходилось долго (в сравнении с кешем) ждать их из оперативной памяти.

Таким образом, задача DoD состоит в том, чтобы структурировать данные программы в соответствии с тем, в каком порядке они будут обрабатываться. Это называется «принципом локальности». И в наиболее распространенной на сегодняшний день парадигме программирования, о которой я говорил в прошлой заметке, этот принцип повсеместно нарушается.


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

Проще говоря, процессоры плохо переваривают любые сложноустроенные объекты и иерархии, вне зависимости от того, насколько структурированными и понятными они выглядят для человека. И это свойство заложено глубоко в архитектуре современных CPU, а значит буквально диктует нам как должен быть написан наш код

ECS — данные + воображение

Ну, хорошо — у нас есть DoD, мы имеем четко структурированные данные. А что, собственно, с ними делать? Конечно обрабатывать. И тут нам понадобятся какие-то абстракции, которые будут объединять наши данные для создания всего многообразия игрового мира. Такими абстракциями в нашем случае выступают сущности, компоненты и системы:

Entity-Component-System (ECS)

Итак, наши данные из DoD мы теперь просто называем компонентами. Они представляют из себя просто свойства сущностей игрового мира: существ, игроков, предметов, явлений и так далее.

Сущности, в отличии от объектов в ООП, не содержат в себе буквально ничего. В каком-то смысле это просто ID (идентификатор), при помощи которого мы можем отличить одну сущность от другой и понять какие она имеет свойства.

Ну и наконец системы. Системы — это сама логика нашего мира. Системы занимаются тем, что последовательно обрабатывают данные, что буквально вдыхает жизнь в наш мир.

Это может показаться не менее сложным, чем та же ООП. Но вот более простое описание того, что делает ECS.
Данные теперь можно представить как огромную таблицу Excel, где сущности — это номера строк, а компоненты — столбцы. В итоге системы занимаются тем, что последовательно обрабатывают изменения данных в столбцах. Согласитесь — звучит очень просто.


Еще проще дело обстоит с тем, чтобы ускорить работу этой обработки. Все, что вам нужно сделать, это обрабатывать не все данные в столбце по очереди, а разделить их на группы, соответствующие числу потоков\ядер вашего процессора, и обрабатывать все параллельно. Обработка будет во столько раз быстрее, сколько у вас будет доступных потоков\ядер процессора. И это имеет свои плоды: вы можете полноценно утилизировать производительность даже таких монстров как 64-ядерные процессоры. Я говорю не о каких-то странных синтетических тестах, а о полноценной полезной нагрузке. Это большая редкость для софта вообще, чего уж говорить про игры.

Ну а что же насчет механик? Самым значимым плюсом для ММО, которая написана на базе ECS, является простота сопровождения, что включает и добавление новых механик.

Сопровождение — это процесс улучшения, оптимизации и устранения дефектов программного обеспечения.

Любая оптимизация, поиск багов и исправления в уже существующих системах очень сильно упрощается за счет полной изоляции. Можно сказать, что в некотором смысле системы в ECS работают практически как отдельные программы.

Создание новых систем и свойств никак не ограничено, за исключением ограничений производительности машины, на которой это все запущено. На самом деле это огромные цифры: миллионы сущностей с десятками разнообразных свойств\компонентов.

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

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

Кончено, существует во многом похожий простой компонентный принцип на базе ООП, который стал популярным в играх. Он используется и в UE4, и до 2018 версии активно использовался в Unity. Скорее всего, и многие самописные движки тоже используют его. Но у него все еще есть минусы, ограничивающие пластичность, если можно так выразиться. Объекты, которые вы захотите создать в игре, все еще будут шаблонными, они не смогут иметь любые свойства, какие вам захочется, так как компоненты добавляются в процессе написания самого кода. Справедливости ради можно добавить, что существуют способы обойти эти ограничения и в ООП, но подобная архитектура требует еще больших затрат времени и имеет еще большую сложность, не говоря о том, что она нарушает все тот же принцип локальности данных.

В ECS же вы вольны создавать просто немыслимые гибриды сущностей, абсолютно не заботясь об изменениях в архитектуре проекта. Так мы можем создать книгу-NPC, которая может ходить или летать, выдавать квесты, а затем, изменив несколько параметров, превратить ее в предмет, который будет контейнером, содержать в себе какую-то информацию и даст игрокам возможность положить эту сущность в инвентарь. И, конечно, «книга», выполнив все возложенные на нее обязательства, может стать просто книгой, которая имеет только 2-3 свойства в виде простых численных значений. И все это в процессе выполнения программы. Возможность создавать сущности, которые имеют любые свойства прямо в игре абсолютно без ограничений и без необходимости что-то дописывать — это очень удобно, поверьте.

На мой взгляд, не менее воодушевляющим примером может служить компонентный AI. Часто в играх используются так называемые древа поведения, которые, если упрощать, определяют: что делает NPC в данный момент времени, что он может сделать после этого, что будет, если произойдут такие-то события. Тут мы столкнемся с тем, что необходимо заранее определить все возможные варианты развития событий, чтобы наш NPC не тупил на ровном месте. Да, с простым компонентным подходом мы можем написать планировщик, который будет оценивать свойства этого NPC (или его состояния, как вам больше нравится), свойства мира вокруг и планировать свои действия для достижения какой-то цели. Однако, эта система и все ее состояния для конкретного NPC все еще будут жестко определены программным кодом, и после компиляции вы уже ничего не сможете изменить.


Что предлагает нам ECS? Нам дается сущность, которую в процессе самой игры мы можем наделить свойствами: сделать NPC торговцем, бандитом, бродягой, а после смерти оставить лишь компонент модели тела и пару других свойств. Но представьте, что тело NPC никуда не денется, на это место придет некромант, который «заменит» компонент одной модели на другую и сделает из нашего трупа NPC-нежить. Так каждое новое добавленное свойство меняет поведение этого NPC, делая его умнее или глупее, изменяя его цели и методы их достижения.

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

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

P.S. Для тех, кто хочет и имеет возможность погрузиться глубже и разобраться в деталях, я могу посоветовать вот эту статью. И для расширения тематики огромный список разнообразных полезных материалов по DoD.