У двигуні Source (а це попередник, goldsrc, quake's) ігрові об'єкти поділяються на два типи, світ та сутність. Світ - це геометрія карти, а сутності - це гравці, частинки, звуки, партитури тощо (для Двигуна джерела).

Кожна сутність має мисленнєву функцію, яка виконує всю логіку для цієї сутності.

Отже, якщо все, що потрібно обробити, походить з базового класу з функцією think, ігровий движок може зберігати все у списку і, на кожному кадрі, пробирати його та викликати цю функцію.

З першого погляду ця ідея є розумною, але вона може зайняти занадто багато ресурсів, якщо в грі багато сутностей.

Отже, як двигун типу Source дбає (обробляє, оновлює, малює тощо) об’єктів гри?

Добре, що іншого способу зробити це майже не потрібно - вам доведеться прокручувати та закликати think()кожну сутність хоча б раз на кілька кадрів.

Ви можете покласти об'єкти на власну нитку, але тоді у вас є цілий кошмар синхронізації стану, що, безумовно, не варто.

З першого погляду ця ідея є розумною, але вона може зайняти занадто багато ресурсів, якщо в грі багато сутностей.

Ось чому двигун Source встановлює жорсткий ліміт кількості сутностей, які можуть існувати одночасно : 4096 об'єктів, з яких лише половина (2048) може бути мережевою. Перейдіть будь-який з цих лімітів, і гра завершиться.

Ось чому, створюючи карту, вони рекомендують не використовувати більше ніж 800 об'єктів.

Ці кроки, які ви згадуєте, найімовірніше, здійснюються в окремих двигунах. Просто у простих ігрових двигунів їх зазвичай за один прохід. Ваша послідовність

for each object
    do physics
    do game logic
    draw

стає

call physics subsystem
call game logic subsystem
call drawing subsystem

Фізичний двигун піклується про положення та розміри.

Game Logic Engine піклується про інтерпретацію того, що Physics Engine змінив (він міг перешкоджати деяким шляховим точкам ...), які цілі мають персонажі та яку поведінку вони повинні робити , він виконує заплановані сценарії (ця функція думки ).

Drawing Engine малює, які об’єкти видно, і він знає, які об’єкти видно, тому що двигуни Quake тут накручують (див. Розділ Малюнок).

Моя рада вам - скоріше вивчити, як проводяться моделювання, а не ігрові двигуни. Існує величезна поп-культура, що стосується розробки ігор, ігрові двигуни робляться на необхідних мовах (через традиції та швидкість); тож мені було більш просвітлено отримати хороші підручники (скоріше теорію), а потім дивитись на двигуни (практика), а не дивитися на двигуни та головоломки годинами, як вони це робили.

Фізика

Ціле поняття про повторення всіх сутностей і, напевно, подумайте, малюйте}, можливо, призведе до проблем. Будуть конфлікти тощо. Я вірю, що Valve має Havok, і я думаю, що Havok піклується про достатньо правильну фізику.

Подумайте

Подумайте функція запускається , коли час в грі дорівнює часу в nextthink . Це працює таким чином у двигуні Quake, а двигун Quake є основою для двигунів Half Life. Він НЕ запускається кожного разу.

Внутрішньо це повинно бути простою ітерацією за допомогою списку сутностей і перевірки, чи минув час для виклику функції думки. Часова складність буде O (N), де N - кількість сутностей.

Якщо існує дуже велика кількість сутностей, слід виміряти, наскільки це покращить кадр в секунду. Зауважте, що через закон Амдала це потенційно невидима швидкість. Я маю на увазі, ви просто повторіть усі предмети і зменшіть & перевірити одне число.

Я б пришвидшив його шляхом сортування сутностей по nextthink (створити список покажчиків на сутності та сортувати його кожен раз; не масив сутностей, тому що сутності можуть змінити наступне мислення в будь-який час, тому їх перестановка в масиві приймає O (N) замість O ( 1) у списку).

Слід також переглянути планувальник O (1) в Linux .

Малюємо

Двигун малює те, що приблизно видно з області, на якій знаходиться камера. Рівень гри - це розділення на дерево, а область - лист цього дерева. Я не заважатиму вам про деталі про нього ... Тож якщо сутність видима, її кладуть у набір видимих ​​сутностей і вони малюються.

Вони зберігають, які зони є потенційно видимими. Його називають "потенційно видимим набором", PVS - коротким. Існує візуалізація PVS , зелена капсула грає і навколо нього виводиться те, що містить його PVS.

Отже, якщо все, що потрібно обробити, походить з базового класу з функцією think, ігровий движок може зберігати все у списку і, на кожному кадрі, пробирати його та викликати цю функцію.

З першого погляду ця ідея є розумною, але вона може зайняти занадто багато ресурсів, якщо в грі багато сутностей.

Власне, все, що міститься в одному великому списку, як правило, менш бажане; якби ви згрупували об'єкти у списки на основі, наприклад, їх типу, ви могли б краще розподілити обробку по декількох потоках. Наприклад, якщо ви знаєте, що всі об'єкти типу Foo ніколи не взаємодіють з будь-якими іншими сутностями під час фази моделювання, ви можете їх повністю вивантажити. Якби вони були розкидані вольово-неволею по якомусь великому переліку однини, зробити це було б набагато складніше.

Вам не обов’язково навіть виводити все із загального базового класу на той момент; Джерело надмірно перекривається зловживанням спадщиною за те, що в іншому випадку може бути реалізовано як дані в цьому відношенні.

Звичайно, у вас завжди буде верхня межа кількості об'єктів, які ви можете обробити на кадр, навіть якщо ви почнете перевантажувати роботу на інші ядра. Нічого не обійтися, просто потрібно мати уявлення про те, що таке обмеження у вашій реалізації, і вживає заходів для їх зменшення (правильне вибивання фаз обробки об’єктів, які їм не знадобляться, уникаючи надмірної деталізації в об'єктах тощо кетера).

Що ви повинні врахувати, і це, слідуючи за рухом думки попередніх відповідей, - це те, що ваша ефективність також буде залежати від того, коли і як ви називатимете ці функції мислення.

Переглядаючи посилання, яке ви розмістили у вихідному двигуні, ви також можете прочитати, що ви можете налаштувати час роздумів та різні контексти мислення для кожної вашої особи, окрім очевидного жорсткого обмеження, на яке хтось уже вказував, це стане ключем до досягнення більшої продуктивності з більшою кількістю сутностей, або шляхом створення покрокових оновлень, які поширюють обробку голодної продуктивності через кілька кадрів виконання, або шляхом викреслення непотрібної обробки в залежності від поточного контексту (тобто об'єкти, які знаходяться занадто далеко або поза сприйняттям гравця, не потребують той самий рівень "детальної думки", що й персонажі, близькі гравцю, просто не бачать, як персонаж за 2 милі відбирає собі ніс).

Є й інші більш конкретні рівні оптимізації залежно від вашої конкретної логіки гри та ситуації.