Продуктивність на мультиплеєрному сервері FPS

Це пов’язано з продуктивністю MMO, за винятком того, що питання стосується пропускної здатності. Йдеться про навантаження на процесор.

Я зібрав простий FPS за допомогою node.js та webGL. Це надзвичайно просто, дуже схоже на клон BuddyMaze MIDI Maze. Там відбувається дуже мало, кожен рухається в двох вимірах (немає висоти), вистрілює прості снаряди і біжить у стіни.

Зараз, якщо я здійснюю кілька підключень до сервера, де кожен гравець швидко стріляє, крутячись по колах, я можу отримати приблизно 15 - 20 гравців у грі, перш ніж сервер витягне ядро ​​та сповільнить шлях. І це при запуску на сервері на 30 кадрів в секунду. При 10 кадрів в секунду я отримую близько 25 - 30 підключень. Це дуже погано, оскільки незабаром у грі буде набагато більше, і мені потрібно підготувати більше гравців, щоб це було здійсненним.

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

Як це можливо? Які існують хитрощі, щоб збільшити продуктивність сервера до такої величини? Деякі речі, які я знаю, включають:

• Зниження частоти кадрів на сервері та інтерполяція позицій на клієнті. Я отримав певну вигоду, але явно сервер TF2 цим навіть не турбує.
• Робити дорогі речі, такі як виявлення зіткнень на клієнті, і нечасто перевіряти це на сервері. Я ще не переніс це, я вже сьогодні ввечері. Навіть тому я не очікую такого величезного виграшу.
• Розбийте ігрове поле на регіони (квадратичні дерева), щоб мінімізувати обчислення. Ще не було можливості для цього.
• Я вважав прикрою можливістю, що node.js просто повільніше, ніж будь-який TF2 використовує, і може не підходити для такого роду завдань високої інтенсивності.
• Чи все в магії конфігурації сервера?

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

Оновлення

Профілювання справді - єдина мантра, яку я коли-небудь виявляв, що абсолютно непогрішна. Я швидко обернув деякі функції синхронізації навколо свого коду (спасибі, FP!) І виявив те, чого я ніколи не очікував: акт передачі даних клієнтам припадає майже на весь час виконання. Зокрема, близько 90%. Подальше тестування показало, що цей час залежить як від кількості клієнтів, так і від розміру даних, але тим більше останніх. Під час завантаження 20 користувачів я скоротив час мовлення на 90%, з 24 мс до трохи більше 2 мс, надсилаючи лише "{}" замість повних даних. Але лише для 5 користувачів мовлення займає близько 0,5 мс. Тому мені явно потрібно провести певну оптимізацію.

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

Ваш сервер не повинен надсилати штати всіх гравців всім гравцям при кожному галочку. Натомість він повинен надсилати спеціально створене повідомлення кожному клієнту, кожні 500 мс, кажучи, що "ці x гравці у вашому порту перегляду повинні знаходитись за цими координатами в 500 мс". Більшу частину часу це буде добре працювати, але якщо сервер зрозуміє, що він дав неправильну інформацію, він просто надсилає додаткове повідомлення.

Це різко зменшить мережевий трафік.

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

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

Це, мабуть, це. Сервер TF2 записується за допомогою C / C ++, і, таким чином, буде швидше, ніж node.js (який, якщо я добре пам’ятаю, використовує інтерпретацію Javascript на Java)

Google Quake на базі WebGL використовує Java для сервера, а вихідний код можна знайти тут: http://code.google.com/p/quake2-gwt-port/ . Можливо, варто переглянути це, щоб побачити, як це робиться. Мені також цікаво, що ви маєте на увазі, коли ви говорите про наявність частоти кадрів на сервері. Немає жодних причин рендерувати на сервері, він повинен просто бути там для обробки команд, що надсилаються клієнтом.

Нарешті, правило "не довіряйте клієнту" важливіше, ніж перевантажувати на клієнта дорогі розрахунки в надії на підвищення продуктивності. Особливо щось таке важливе, як виявлення зіткнення. Удвічі так, коли ваша гра базується на Javascript, і, таким чином, досить легко зламати (порівняно з чимось на зразок TF2, який компілюється).

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