Як впоратися з великою кількістю підйомів у грі MMO

Як обробляють такі ігри, як Minecraft або насправді будь-яка гра MMO, яка має пікапи?

Скажіть, місцевість породжує 3 краплі "бруду" щоразу, коли ви копаєте місцевість. Скажімо, кожен елемент має анімацію обертання, обчислену кожен кадр. Якщо кількість підйомів у світі буде дуже великою, це буде марною масовою накладними витратами в обчисленні кадрів для клієнта на даному сервері, оскільки цілком ймовірно, що багато цих пунктів підбирання знаходяться в світлих роках від вас.

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

Моє актуальне питання: як інші ММО вирішили це питання?

Просто завантажуючи в пам’ять ті частини світу, які знаходяться поруч із програвачем. Все інше призупинено на жорсткому диску. Коли на відстані двох кілометрів лежить крихітний предмет, гравець не може його бачити і не може з ним взаємодіяти. Тому немає ніяких причин її оновлювати чи надсилати до GPU для надання. Чим менше об'єкт і його діапазон взаємодії, тим менший діапазон навколо плеєра, куди потрібно його завантажити.

Щодо з'ясування того, що є близьким до гравця: Це зводиться до того, щоб зберігати світ у структурі даних, оптимізованій для просторового пошуку. Хорошими кандидатами для цього є просторове хешування і багатовимірні дерева .

У вас є дві дуже різні речі для управління:

1. Сервер повинен керувати усім світом в авторському порядку. Для цього необхідне спілкування з N клієнтами (де N - "масовий").

2. Клієнт , в принципі, міг знати про весь світ, але цього не потрібно . Для клієнта достатньо знати про те, що знаходиться поблизу гравця. Припустимо, наприклад, досить грубу сітку поділу, потрібно знати лише клітинку гравця та 26 комірок навколо програвача (або 8 комірок, якщо у вас є двовимірна сітка). Дещо тонша сітка краще, але ви отримуєте ідею.

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

Серверу не потрібно ні знати, ні дбати про обертання підбирачів або подібні деталі. Навіщо це?

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

Що потрібно з точки зору сервера - це знати, що ви копали (30, 40, 50) у вузлі, в якому ви перебуваєте, і він вирішує, що це породжує, наприклад, три об’єкти типу 5 або один об'єкт типу 7 з кількість 3. Це все, що це хвилює, і це все, що вам скаже. Вона також буде включати цю інформацію в дані, що надсилаються тому, хто пізніше переміщає область, що цікавить, через сітку комірки (якщо припустити, що вона все ще є до цього часу).

Клієнт отримує інформацію про три породжені об'єкти, бла-бла. Тепер, незалежно від того, чи відображає клієнт ASCII-арт-карту, де зараз є D, чи він показує обертову купу бруду, все одно. Незалежно від того, чи є палі різними обертаннями, чи обертаються лише ті, що наближаються до вашого програвача. Це просто речі, які відображаються на моніторі, вони не впливають ні на кого більше.

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

Ви можете (і повинні) залежно від вашого розміру перегородки тривіально обрізати осередки сітки, які занадто далеко.

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

Перевірка відстані (дійсно відстань у квадраті, але для вас це однаково) - це лише два множення та доповнення (оптимізовано до MUL, MADD, так що насправді лише дві операції), після чого слід гілка або умовний хід. Це майже так само швидко, як і будь-яка інша операція, яка не обрізає цілі комірки сітки одночасно. Насправді це щось, що ви могли навіть зробити на GPU ...

Бачачи, як у вас буде кілька сотень, або щонайбільше декілька тисяч перевірок відстані на ту саму позицію (відстань у квадраті працює добре), у вас справді не виникає особливих проблем, просто роблячи цей розрахунок, тим більше, що це досить кеш- дружня ітерація над суміжною пам’яттю, а при умовних рухах - бруд дешевий. Щось на кшталт (псевдокод) rot = r[i] + 1; r[i] = ((dx*dx+dy*dy) < DIST_SQ) ? rot : r[i];. Це одна ітерація над масивом у кілька сотень значень на кадр. Комп'ютер не міг менше дбати про це, це суміжні навантаження та магазини, простий АЛУ, відсутність філій та лише кілька тисяч ітерацій.

Це (багато-до-одного) - це не той самий клас проблем (багато-до-багатьох), як на сервері. Дійсно, клієнт не проблема.

@ T.Sar пише в коментарі, що вам слід дізнатися про концепцію "завантаженої частини" Minecrafts для отримання додаткової інформації. Якщо ви це робите, майте на увазі, що це в Minecraft досить складно через людей, що будують машини в грі.

Далі йде дуже спрощена версія:

Світ розділений на квадратні регіони (шматки). У Minecraft також є розподіл по висоті, але більшості MMS цього не потрібно.

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

У Minecraft регіони складають 16x16 блоків, і клієнт знає про 9x9 регіонів, по 4 регіони у кожному напрямку. (4 регіони схід + гравець регіону знаходиться в + 4 регіонах захід = 9 регіонів. Усього північ / південь)

У цих цифрах немає нічого магічного, використовуйте все, що має сенс у вашій грі.

Клієнт лише анімує речі всередині цієї області. Сервер обчислює лише такі речі, як мандрівні монстри в регіонах, близьких до якогось гравця.

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

Немає нічого поганого в тому, щоб мати кілька вкладених меж анімації. Наприклад, анімаційний предмет падає в зону 3x3, мандруючи монстрами в зоні 5x5 і просто показуючи пейзаж у зоні 9x9.

Сервер зберігає "заморожену версію" регіонів, яких не бачить жоден гравець. Якщо для цього потрібно багато пам’яті, можливо, ви захочете вивантажити їх через деякий час. Коли наступний гравець прибуває, регіон перезавантажується без падіння предмета. Наступного разу вам потрібно бути швидшим, програвач 1.