Як боротися з більш швидкими комп'ютерами у відеоіграх у режимі реального часу клієнт / сервер

Я створюю свою першу онлайн-гру за допомогою socket.io, і хотілося б, щоб це була багатокористувацька гра в реальному часі, як agar.io або diep.io.

Але я зіткнувся з проблемою спроб з'ясувати, як змусити всі комп'ютери працювати з однаковою швидкістю.

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

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

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

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

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

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

Як програмісти зазвичай справляються з цим?

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

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

Тик, ймовірно, буде у формі 1 / N секунд, N - кількість кліщів в секунду, або Tickrate. Цей тиккрат може бути дуже часто або дуже рідко, в залежності від Вашого випадку використання. Моя особиста пропозиція полягає в тому, щоб уникнути тиккрату вище 60 тиків на секунду, якщо ви впевнені, що вам потрібно більше. Ви, мабуть, не так :)

Дії повинні бути атомними. Наприклад, в slither.io такі дії, як переміщення, не повинні негайно обробляти щось на зразок розриву ланцюга, якщо тільки той гравець, якого ви вдали, вже не здійснив свій хід. Це може здатися тривіальним для чогось на рівні пікселів, але якщо ви маєте справу з рухом на основі плитки, це стає набагато більш очевидним і забезпечує справедливість. Якщо гравець A переходить на плитку X, Y та програвач B, зараз знаходиться на цій плитці, ви повинні переконатися, що до кінця галочки гравець B все ще буде на цій плитці для будь-яких дій, що відбудуться між ними.

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

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

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

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

Майте стан гри як на клієнті, так і на сервері.

Коли клієнт намагається використовувати команду (миша, клавіатура та інше введення), перегляньте його стан гри, якщо вона дійсна.

Якщо це так, відправте команду на сервер, не виконуючи її на клієнті, що відправляє.

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

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

Коли клієнт отримує команду від сервера, подивіться на його стан гри, якщо вона дійсна, негайно виконайте дії, прохані командою, а потім подивіться на поточну дату та порівняйте її з отриманим прогнозом на дату. Якщо це не вірно, клієнт не синхронізований. (Усі клієнти з подібним з’єднанням отримують одночасно)

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

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

На клієнтах візуалізуйте речі на екрані ТІЛЬКИ, коли не залишається нічого іншого. У простих сценаріях функція візуалізації приймає в якості входу лише поточний стан гри.

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

Перевірка повинна відрізнятися, наприклад, сервер повинен обмежувати запити команд / одиницю часу.

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

У масовій більшості багатокористувацьких ігор справжні розрахунки робить лише сервер. Клієнти - це лише тупі IO-машини, на яких лише реальною проблемою є малювання 3D-графіки. І в цьому випадку не має значення, чи може клієнт працювати з 20 або 200 FPS, оскільки це впливає лише на візуальні зображення. Це означає, що "оновлення клієнта" абсолютно не має значення. Клієнт може спробувати "передбачити", що може розраховувати сервер, але це лише для того, щоб згладити відчуття геймплея і не має фактичного впливу на сам геймплей.

більша швидкість клавіатури

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

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