Логіка гри на сервері! Добре чи погано?


25

Наразі я планую просту онлайн гру в багатокористувацькі ігри. І ось питання. Чи є сенс зробити всю логіку гри на сервері і просто надіслати вхід від клієнта на сервер? Які плюси і мінуси чи є причини, чому я не повинен цього робити?

Відповіді:


37

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

Крім того, вам не обов'язково хочеться повернути назад все, що потрібно зробити клієнту. Наприклад, ви можете надіслати якесь повідомлення із повідомленням "NPC X помер", і клієнт визначає, яку анімацію / звуки потрібно відтворити. Такі речі.

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

На цій темі є багато більш конкретних питань на цю тему. Наприклад:

Чи слід виявляти зіткнення на стороні сервера або спільно між клієнтом / сервером?

Хто обчислює AI в MMO?

Чи повинен бути власником гри влада чи інший німий клієнт?


4
+1 Побий мене до цього. Крім того, залежно від стилю гри, можливо, вам потрібно / потрібно зробити прогнозування на стороні клієнта.
Джон Макдональд

14

Ну, ви отримали відповіді, але ваша справжня відповідь - "спробувати себе". Речі відрізняються від гри до гри.

Я зробив пару багатокористувацьких ігор для деяких курсів дизайну мережевих ігор. Найскладніше було робити екшн-ігри в режимі реального часу, де багато гравців брали участь і надсилали матеріали, як пекло. Коли справа доходить до цього моменту, все стає проблемою. Як ви бачите перше надіслане Tetrat посилання, проблемою стає навіть визначення змови. І ви будете читати-чути такі терміни, як відставання, інтерполяція, екстраполяція, передбачення ... Але якщо ви ніколи не спробували себе кодувати з нуля, ви просто приймете ці слова і не знатимете, що вони насправді означають.

Моя рекомендація:

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

Крок 2
Почніть вирішити проблеми на стороні клієнта. Наприклад, проблеми з телепортацією. Ваш персонаж був у (0,0), а сервер сказав, що зараз ви на (100,100). Ваш персонаж просто телепортується до (100 100), що не приємно. Настає інтерполяція. У вас має бути код на стороні клієнта, який плавно пересуне символ із (0,0) до (100, 100). Так, ви переместите свого персонажа з (0,0) на (100,100), але наскільки швидко? Наразі ви можете просто використовувати різницю у часі між кожним оновленням сервера. Якщо ваш сервер надсилає 10 пакетів за секунду, це означає затримку 100 мс між кожним пакетом.

Крок 3
Тепер ваша гра вже хороша для швидких мереж, де є затримка (1-50) мс. Але це приречене, якщо є втрата пакету, висока затримка або обчислення забирає багато часу на сервері ... ECT. У тих ситуаціях, які ви помітите, натиснувши стрілку вліво, ви побачите, як ваш персонаж рухається вліво із затримкою 200 мс. Затримка між вашим пакетом йде на сервер, час обчислення і повертається до вас з останньою позицією. Це погано, найгірший недолік розробленої серверною дизайном. Гравець хоче, щоб його персонаж рухався ліворуч, як тільки він натискає ліворуч, ви не можете змусити його чекати. На щастя, клієнт також має той самий код, що і сервер, то чому б не виконати його на клієнті негайно і зафіксувати кінцевий результат за допомогою відповіді з сервера? Ось що є основним вхідним прогнозом. Клієнт натискає ліворуч, код на його стороні перемістить його вліво, через деякий час, скажімо, 200 мс, реальна позиція виходить із сервера, і клієнт виправляє свою позицію з ним. Якщо все пішло добре, клієнт нічого не помітить, "крок 2" також допоможе нам у цьому.

Ну, у мережі є багато навчальних посібників та речей з цього приводу. Але є 2, які мені дуже подобаються:

Дійсно добре, охоплює темні плями: багатокористувацька мережа Valve-Source Engine,
історія, цікаво читати і вартує цього: 1500 лучників 28,8 ,


3

Плюси:

  • такий підхід є більш (найбільш) піратським доказом
  • ви можете легше застосовувати оновлення
  • централізована громада

Мінуси:

  • величезні вимоги до пропускної здатності
  • деякі користувачі можуть ненавидіти такий підхід (конфіденційність та інше)
  • проблеми з локальним ігровим процесом (локальні партії), одиночним гравцем

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

2

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


Це смішно, коли я задавав подібні запитання тут у 2016 році, всі мені просто сказали "ніколи не довіряй клієнту".
newguy

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

2

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

Якщо ви хочете зробити шутер, ви можете використовувати як вхідні, так і абстрактні функції. Якщо взяти Unreal Tournament 3 як випадок, вони створили мультиплеєра переважно за допомогою повторних викликів функцій.
Для руху вони беруть вхід гравця (стискається в один біт для кожної дії) дельта обертання, прискорення та часової позначки і відправляють його на сервер.
Для інших цілей, як зброя, вони синхронізуються під час стрільби (AFAIK, ще не заглядав у цю частину глибоко).
Для більш статичних / рідше змінених значень, таких як здоров'я, вони надсилають змінну клієнту або серверу залежно від того, що вказав програміст.

А для ігор, які не належать до RTS, пам’ятайте прогнозування клієнтів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.