Чи є ресурси та документація про те, як поточні ММО обробляють дані про дії та рух від стиснення до обробки на клієнті? Будь-які ресурси для алгоритмів прогнозування руху?
Мене особливо цікавлять ті, хто має рух wsad і фокусується на підтримці низької затримки. Також, яка швидкість і розмір пакетів для різних типів MMO (мережева)?
Чи є спосіб змінити швидкість передачі пакетів або відключити прямо деякі пакети, якщо гравець не може їх досягти або в подальшому випадку їх побачити?
Відповіді:
Що ж, є ця книга - яка вже трохи стара, і я ніколи її не читав, але це від авторитетного видавця. Я також знайшов цей , який є новішим, але про нього я ніколи не чув. Обидва заявляють, що охоплюють проблеми розвитку MMO (або принаймні онлайн); зважаючи на це, прогнозування на стороні клієнта є більш-менш однаковим, незалежно від масштабу вашої супутньої бази гравців, і Google має багато інформації про це .
Важливо усвідомити, що з практичної точки зору розробнику інді / хобі досить важко скласти гру, яка буде досить популярною, щоб навіть набрати достатньо гравців, щоб досягти теоретичного піку одночасно високого рівня, щоб вважатись "масовим". Але методи все ж можуть бути навчальними для дослідження.
Є дві основні класифікації того, що ви можете зробити:
Другий - насправді проблема дизайну ігор та соціальних маніпуляцій - це особливо складно, оскільки багатокористувацькі ігри, природно, соціальні, це частина їх привабливості, тому ви не хочете занадто відлякувати скупчень гравців. З іншого боку, гра, в якій всі в світі нерестові - це той хлопець, який випадає з найкращого бабло в грі, важко буде масштабувати.
Для першого варіанту ви можете розглянути багатоярусні повідомлення - є деякі речі про інших гравців, які завжди важливо знати, наприклад, позиції. Але інші речі, такі як здоров'я, можуть бути не настільки важливими для об'єктів, яких поточний гравець ще не бачить, тому ви передаваєте, що ви надсилаєте цьому гравцеві, виходячи з відносної відстані всіх інших об'єктів, що знаходяться в його околицях - це, по суті, перешкоджає дані, які ви надсилаєте, як ви згадували в останньому фрагменті свого питання, а також фільтруючи їх.
Дуже масштабні багатокористувацькі архітектури також буферують звіти, які не потребують негайних дій над ними. Повідомлення збереження символів, що надсилаються на сервер, можна робити в дельтах, з повним оновленням лише у критичних точках, і ці оновлення можуть бути завантажені на сервер, що перебуває в режимі дроселювання, щоб вони надсилалися на сервер, який фактично постійно зберігає дані символів, періодична мода - у міру масштабу ваших плеєрів вам доведеться турбуватися про оптимізацію IO диска, а також про мережевий трафік. Ви не хочете, щоб ваша база персонажів була зірвана.
Швидкість і розмір пакетів сильно відрізняються від гри до гри, як і для ігор, що не мають MMO. Це дійсно дуже специфічна річ і немає узагальнених стандартів.
На додаток до вищевказаної відповіді, прочитайте на TCP_NODELAY і як працює масштабування вікон. Розуміння деталей TCP (і так, ви хочете використовувати TCP, а не UDP, якщо перспектива обробки диференціальних оновлень, що виходять з ладу, не здається вам цікавою) і повторна передача є критичною для контролю затримки.