Інформація про безшовну архітектуру сервера MMO

Я шукаю будь-який матеріал на безшовних серверах MMO! У мене є декілька статей у книгах "Масово багатокористувацький розвиток ігор" та "Ігри з програмуванням ігор 5". Хтось має досвід цієї теми чи знає статті про це?

Мене цікавлять "погляди високого рівня", а також реалізація. Це може стати темою моєї магістерської дисертації, і я хотів би дізнатися, як важко написати таку систему, перш ніж я розпочну дипломну роботу. Зараз я не вирішив, якою мовою користуватися, я думаю про Яву чи Скалу. Ерланг міг бути вибором, але я ніколи з цим не працював.

Примітка. Основною вимогою буде рух. Будь-які інші ігрові системи необов’язкові і дають "бонусний кредит".

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

Основна складність управління такою системою випливає з того, наскільки безпроблемною вона вам потрібна. Як сказав Джош, вирішення проблеми передачі сутності з одного сервера на інший є ключовою частиною пакету.

Це не єдина проблема - якщо суб'єктам на декількох серверах потрібно взаємодіяти як частина однієї операції, тепер у вас є проблема синхронізації, коли кожній системі потрібні дані з іншої сторони, щоб продовжити, але до моменту надходження даних вони можуть вже недійсні. Ви можете спробувати вирішити це, розбивши операцію на кілька повідомлень з можливістю відкату, якщо одна сторона відступає, але, як ви бачили з розділу 3.1 в розділі "Масивно багатокористувацькі ігри", це суттєво ускладнює будь-яку логіку гри, яку вам потрібно зробіть це за допомогою. Скала та Ерланг допомагають вам правильно надіслати систему обміну повідомленнями - вони не допомагають вам розкласти те, що раніше було функцією 10 рядків, на безліч різних повідомлень і станів, які вам зараз потрібно відстежувати.

Очевидно, що ця проблема не є абсолютно новою, і реляційні бази даних підтримують подібну проблему, зберігаючи всі дані в центрі і дозволяючи декільком клієнтам запитувати і змінювати їх, як потрібно, відкочуючи транзакції, де це необхідно. Це дає вам більшість ваших вимог щодо правильності, але, на жаль, створює непрактичні проблеми щодо продуктивності, а також робить незрозумілою реалізацію логіки гри (оскільки значна частина вашої логіки зараз записана в процедурах, що зберігаються в базі даних). Тут може бути хорошим рішенням різний вид БД, особливо якщо ви готові торгувати вимогами надійності, які надає більшість RDBMS.

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

Мене цікавлять "погляди високого рівня", а також реалізація.

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

Я хотів би з’ясувати, як важко написати таку систему

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

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

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

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

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