Как движок, подобный объектам Process?

В движке Source (и это antecessor, goldsrc, quake) игровые объекты делятся на два типа: мир и сущности. Мир - это геометрия карты, а сущности - игроки, частицы, звуки, оценки и т. Д. (Для исходного движка).

Каждый объект имеет think , которые выполняют всю логику для этого объекта.

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

При первом взгляде эта идея разумна, но она может занять слишком много ресурсов, если в игре много сущностей.

Итак, как движок вроде Source заботится (процесс, обновление, рисование и т. д.) игровых объектов?

9 голосов | спросил JulioC 23 J0000006Europe/Moscow 2011, 07:55:03

4 ответа


5

Ну, нет другого способа сделать это - вы собираетесь иметь , чтобы прокрутить и вызвать think() для каждого объекта не реже одного раза в несколько кадров.

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

  

При первом взгляде эта идея разумна, но она может занять слишком много ресурсов, если в игре много сущностей.

Вот почему движок Source помещает жесткий предел количества объектов, которые могут существовать за один раз : 4096 объектов, из которых только половина (2048) может быть подключена к сети. Перейдите по любому из этих пределов, и игра выйдет из строя.

Именно поэтому при создании карты они рекомендуют не использовать более 800 объектов.

ответил BlueRaja - Danny Pflughoeft 23 J0000006Europe/Moscow 2011, 10:06:22
3

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

for each object
    do physics
    do game logic
    draw

становится

call physics subsystem
call game logic subsystem
call drawing subsystem

Физический движок заботится о позициях и размерах.

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

Drawing Engine рисует, какие объекты видны, и он знает, какие объекты видны, потому что здесь работают читы Quake (см. раздел «Draw»).

Мой совет для вас - это скорее изучить, как симуляции выполняются, а не для игровых движков. Существует огромная поп-культура, связанная с развитием игры, а игровые движки сделаны на императивных языках (из-за традиции и скорости); так что для меня было лучше просвещать хорошие учебники (скорее теория), а THEN смотреть на двигатели (практику), а не смотреть на двигатели и головоломки часами, как они это делали.

Физика

Общее понятие итерации всех объектов и {think, draw}, вероятно, приведет к проблемам. Будут конфликты и так далее. Я считаю, что у Valve есть Havok, и я думаю, что Havok заботится о достаточно правильной физике.

Подумайте

Функция

Думать запускается, когда время в игре равно времени nextthink . Он работает таким образом в Quake engine, а двигатель Quake является основой для двигателей Half Life. Он НЕ запускается каждый раз.

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

Если существует очень большое количество объектов, вы должны измерить, насколько это улучшит fps. Обратите внимание, что из-за закона Amdahl это потенциально невидимое ускорение. Я имею в виду, вы просто перебираете все предметы и уменьшаете и проверяете один номер.

Я бы ускорил его, сортируя объекты nextthink (создайте список указателей на сущности и сортируйте их каждый раз, а не массив сущностей, потому что сущности могут изменить их nextthink в любое время, поэтому их перестроение в массиве принимает O (N) вместо из O (1) в списке).

Вы также можете посмотреть планировщик O (1) в Linux .

Draw

Двигатель рисует то, что приблизительно видно из области, на которой находится камера. Уровень игры - это разделение на дерево, а область - лист этого дерева. Я не буду беспокоить вас сведения об этом ... Итак, если сущность видима, она помещается в набор видимых объектов и рисуется.

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

ответил user712092 30 J000000Saturday11 2011, 09:19:02
2
  

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

     

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

На самом деле помещение всего в один большой список обычно меньше, чем желательно; если вы должны были группировать сущности в списках на основе, например, их типа, вы могли бы лучше распределить обработку по нескольким потокам. Например, если вы знаете, что все объекты типа Foo никогда не взаимодействуют с другими объектами во время фазы моделирования, вы можете полностью их выгрузить. Если бы они были разбросаны волей-неволей в каком-то большом единственном списке, это было бы намного сложнее сделать.

Вам не обязательно даже нужно выводить все из общего базового класса в этот момент; Источник идет довольно за бортом с злоупотреблениями наследования для того, что в противном случае могло бы быть реализовано как данные в этом отношении.

У вас, конечно, всегда будет верхний предел количества объектов, которые вы можете обрабатывать за кадр, даже если вы начнете разгружать работу на другие ядра. Нет никакого способа обойти это, вам просто нужно иметь представление о том, что этот предел находится в вашей реализации, и предпринимает шаги по его устранению (правильное отбраковка фаз обработки объектов, которые им не понадобятся, избегая чрезмерной детализации в объектах, et так далее).

ответил Josh 23 J0000006Europe/Moscow 2011, 19:06:03
1

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

Посмотрев на ссылку, которую вы разместили на исходном движке, вы также можете прочитать, что вы можете настроить время мысли и различные контексты мышления для каждого из ваших сущностей, помимо очевидного жесткого ограничения, которое кто-то уже указал, это будет ключом к достигая большей производительности с большим количеством объектов, либо путем создания ступенчатых обновлений, которые распространяют голографическую обработку производительности с помощью нескольких кадров исполнения, либо путем отбрасывания ненужной обработки в зависимости от текущего контекста (т.е. объекты, которые находятся слишком далеко или за пределами игрока восприятие не нуждается в том же уровне «думаю, что детали», поскольку персонажи, близкие к игроку, просто не видят, что персонаж в 2 милях отбирает нос).

И есть другие более конкретные уровни оптимизации в зависимости от вашей конкретной логики игры и ситуации.

ответил Sergio Franco 23 J0000006Europe/Moscow 2011, 16:38:41

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132