Мені цікаво, як багатокористувацькі мережі з фізикою реалізуються в гоночних іграх. У нас є фізичний світ з кількома швидкохідними транспортними засобами, якими керують різні люди. Скажімо, транспортні засоби мають зброю і можуть стріляти один з одного (Twisted Metal, Vigilante v8)
Мене хвилює удари та зіткнення. Авторитетний сервер чи краща альтернатива?
Відповіді:
Зазвичай використовується Сервер, який зберігає стан "правди", який періодично ділиться з Клієнтами. Зіткнення відбуваються незалежно в Клієнтах і Серверах, при цьому стан Клієнтів оцінюється з попередніх станів, використовуючи процес, аналогічний тому, що його зазвичай називають Dead Reckoning . Коли стан Сервера досягає Клієнта, якщо існують відмінності, Клієнт здійснює перехід від його поточного стану до стану, щойно отриманого в основному за допомогою інтерполяції.
Однак зіткнення з багатьма об'єктами може бути справжньою проблемою, тому зазвичай робиться - це тримати модельований час Клієнтів трохи відставши від імітованого часу Сервера, щоб забезпечити різні додаткові ступені гнучкості. Ця стаття про мережевий код Valve's Source Engine є досить пояснювальною. Крім того, якщо ви все ще не визначилися з тим, яким мережним проміжним програмним забезпеченням / бібліотекою користуватися, я пропоную вам переглянути RakNet та його компонент "ReplicaManager3" .
Можна зробити кілька речей.
Ви можете централізувати всі об’єкти фізики на сервері та синхронізувати координати з об’єктами гравців усіх клієнтів. Це найпростіше і працює без багатьох недоліків, однак він використовує багато ресурсів і вимагає великої пропускної здатності. Ви можете оптимізувати використання пропускної здатності, лише надсилаючи значення гравцеві інших гравців, які знаходяться в певному радіусі.
Ви можете зробити так, як згадував Neenster, і змусити сервер і клієнтів імітувати фізику, і так часто сервер виправлятиме клієнтів. Це означає, що всі клієнти обчислюють там власну фізику для кожного гравця, і ви б синхронізували події клавіші через сервер, даючи траєкторію кожного гравця для кожного клієнта. Кожен, скажімо, 5 секунд сервер транслює його фізичне моделювання, і всі клієнти приймають зміни. Це може створити невеликі компенсації, які не помітні більшість разів, але під час затримки мережі та втрати пакетів (неминуче з високим рівнем трафіку UDP) ви помітите, що ваш плеєр та / або інші гравці мерехтять по екрану і швидко та швидко змінюють позицію (це слово?).
Ви можете змусити кожного клієнта обчислити власну фізику та синхронізувати її координати. Це ускладнює моделювання фізики на об'єктах, які діляться між клієнтами. Це досить складна концепція, яку можна реалізувати, якщо ви хочете зробити щось неприємне, оскільки певний об'єкт не обов'язково належить жодному клієнту.
Перший, мабуть, найпростіший і повинен дозволяти вам мати близько 4-5 гравців з невеликим відставанням. Для кожного матчу потрібно мати власний сервер. Якщо ви робите матчі з локальною мережею, це шлях вниз.
Друге, мабуть, є найбільш практичним, однак це може бути важко здійснити. Це також досить винахідливий для фізичного моделювання на сервері. Якщо у вас є централізовані сервери, можливо, вам доведеться завантажити баланс на декілька машин, можливо, дозвольте 10 збігів на сервер, завантажте нові сервери на найменше збігів.
Третій, безумовно, найменш напружений на сервері, і, мабуть, найкраще рішення, якщо ви робите мережеву схему однорангових. Як я вже згадував, синхронізувати інші об'єкти, крім об’єкта програвача, може бути важко, оскільки ці об'єкти також можуть змінюватися іншими клієнтами.
Я не можу сказати, який з них використовувати, бо не знаю, як працює ваша гра. Все, що я можу зробити, це навести вам факти. Якщо у вас є додаткові питання, сміливо коментуйте.