Я зробив це для комерційної гоночної гри PSP, яка працювала як через спеціальну мережу, так і через бездротову точку доступу. (Або на статичний сервер в Інтернеті, за бажанням)
Через пункт 2 система не повинна бути складною щодо оптимізації
На мій досвід, це неправда. Бездротові пристрої (особливо маленькі портативні) не схожі на комп’ютери з дротовим мережевим підключенням - для ігор смартфони та бездротові ігрові консолі, як правило, мають повільний мережевий інтерфейс.
Не зрозумійте мене неправильно - їх пропускна здатність зазвичай хороша (тобто кількість даних в секунду; відмінно підходить для потокового перегляду фільмів тощо), але затримка на доставку певного пакету може бути дуже поганою, і може бути такою дуже мінлива, що важко навіть оцінити, скільки часу потребуватиме доставку кожного окремого пакета. Ця різниця стає ще гіршою, оскільки більше бездротових пристроїв збираються в одну загальну зону, оскільки їх сигнали починають перешкоджати один одному. В результаті цього досить багато мого часу було витрачено на зменшення кількості пакетів, які потрібно було відправити, тож у нас було б менше зіткнень пакетів. (Зауважте, що це дещо менша проблема у тому випадку, коли задіяна точкова мережа, а не пристрої спілкуються один з одним через спеціальну мережу)
Як приклад подібної оптимізації наша гоночна гра відбулася у світі, у якому були світлофори. Тисячі їх. І нам потрібно було переконатися, що їхні сигнали синхронізовані між усіма програвачами в мережевому сеансі. Замість того, щоб намагатися надсилати пакети, щоб розповісти всім, які вогні знаходились у якому стані, ми визначили статичний графік для всіх світлофорів, а потім просто переконалися, що всі клієнти домовились про поточний "час гри". Оскільки всі вони знали час гри, і всі стани світлофорів можна було визначити з ігрового часу, ми синхронізували всі ці дані про стан, фактично не надсилаючи жодних спеціальних даних. Ця зміна зробила величезну зміну для нашої роботи в мережі.
Тим не менш, встановлення надійної синхронізації годин між декількома бездротовими пристроями (із сильно різними часами пінгу через велику втрату пакету) було величезною проблемою. Радий поговорити більше про це, якщо у вас є інтерес.
Кожен клієнт може бути авторитетним джерелом даних про себе та своє безпосереднє оточення (наприклад, куль.)
Це ми зробили, і це добре спрацювало в нашій ситуації (машини). Проблемна частина, звичайно, полягає в тому, коли об'єкт перестає бути ближчим до гравця 'а', ніж до гравця 'b', і тому його право власності переходить від одного гравця до іншого.
Це насправді напрочуд складні переговори між гравцями, де гра 'a' пропонує грати 'b': "Я думаю, цей об’єкт вам ближче. Ви повинні взяти під нього контроль". І тоді гра 'b' може або приймати, або може відмовитися, виходячи з власного погляду на ситуацію. Різниця в сприйнятому ігровому стані між 'a' і 'b', і зміна часу, коли запит і відповідь надсилаються і отримуються, робить це особливо неприємним переговором, щоб отримати надійність, і він може легко перерости в гру "гаряча картопля", причому право власності на об'єкти постійно підстрибує між кількома гравцями. І навіть коли вона працює належним чином, якщо дивитися з точки зору гри "c", там "
Моя інтуїція полягає в тому, що такий підхід "власності на об'єкти", ймовірно, буде занадто громіздким для невеликих, короткотривалих об'єктів, як кулі. Ми використовували його для легкових автомобілів та гонщиків AI, які, як правило, живуть в симуляції порівняно довго. Здається, що більш підходящим підходом, якщо ви готові довіряти клієнтам, було б мати гру кожного гравця власну позицію та свої снаряди та заявити, коли цього гравця вдарив чужий снаряд. (Отже, як "гра А", я відповідаю за те, де знаходяться снаряди гравця A та гравця A, але гравець B відповідає за те, чи я потрапив у гравця B). Маючи добрі рахунки з мертвими, ви повинні мати можливість отримати досить розумну поведінку із такої системи.