Окрім статті, що пов'язана з іншими відповідями, я можу трохи розповісти про досвід проекту « Аріанна» .
Як зберегти речі синхронізованими?
У нас є побудова рамки „ Marauroa “ навколо концепції дій та сприйняття: дії надсилаються від клієнта на сервер, на якому вводяться дані користувача (ходіть ліворуч, атакуйте монстрів №47, скажіть „привіт”). І сприйняття надсилаються з сервера до клієнтів, які розповідають про стан світу, що їх близько. Ці сприйняття надсилаються щоразу. Залежно від гри ми використовуємо час повороту від 30 мс до 300 мс.
У нас є два типи сприйняття : Повне сприйняття надсилається при вході в систему і коли гравець потрапляє в нову область (зону). Після цього надсилаються диференціальні сприйняття, включаючи лише модифіковані атрибути (наприклад, положення) модифікованих об'єктів, і звичайно нові та видалені об'єкти.
Як вирішити проблеми із затримкою?
Ми твердо віримо в те, що "сервер завжди правий". Клієнт робить деякі прогнози, такі як плавна ходьба, перевірки зіткнень тощо. Але якщо клієнт і сервер не згодні з чимось, сервер виграє. Підпроект Stendhal (2D RPG) використовує час повороту 300 мс за замовчуванням (з великою кількістю вирівнювання зроблено на стороні клієнта). Це робить Стендаля дуже стійким проти відставання.
Примітка. Деякі інші ігри довіряють клієнтові певні можливості, щоб мінімізувати вплив відставання в мережі. У WoW його часто експлуатували на одному з бойових полів під назвою «Warsong Gulch». Гравець із прапором може вибрати два способи: у середині через тунель та праворуч, піднімаючись на гору. Тож гравець, який обманює, біжить до тунелю, а потім викликає відставання для себе. Сервер та інші клієнти продовжуватимуть бачити, як він біжить до нього. Але через невеликий час цей клієнт може сказати серверу, що він пішов у гору. WoW перевірить, чи відстань між останніми переданими координатами та поточними координатами відповідає часовому відрізку, і прийме це.
Використання UDP проти TCP
У ранніх версіях ми використовували UDP, щоб зменшити накладні витрати TCP. Ми впоралися із втраченими пакетами самостійно. Це прекрасно спрацювало в перші дні проекту. Але коли сервер був перенесений з якогось домашнього підключення DSL до реального центру обробки даних кілька років тому, у нас виникли величезні проблеми. UDP є (або, принаймні, 5 років тому) надзвичайно вимогливим до енергозабезпечення брандмауера процесора: Набір правил повинен застосовуватися до кожного пакету UDP. Однак для TCP набір правил застосовується лише для перших 3 пакетів. Після цього зв’язок встановлюється. Усі наступні пакети будуть обходити звичайний набір правил, тому що вони знаходяться у сполучній таблиці відстеження або тому, що у них немає прапора SYN.
Як захистити зв'язок і клієнта від зворотного проектування?
Arianne є повністю відкритим кодом, сюди входять клієнт, сервер, графіка, музика. І звичайно, що включає нашу протокольну документацію і навіть аналізатор, який використовується для налагодження.
Легко захистити зв’язок від несанкціонованого нюху сторонніми особами за допомогою SSL.
Однак захистити його від зворотного проектування неможливо. Впевнені, що ви можете його притупити і використовувати методи налагодження. Зрештою, ви не можете запобігти зворотному проектуванню програмного забезпечення, яке ви даруєте користувачам. Існує дуже цікава презентація про те, як інженер Skype був розроблений, незважаючи на те, що розробники доклали багато зусиль до методів анти-налагодження: http://recon.cx/en/f/vskype-part1.pdf
Примітка. Є деякі країни, в яких зворотна інженерія є незаконною або дозволяють вводити абзац у ліцензію або ToS забороняє зворотну інженерію. Але є й інші країни (на зразок тієї, в якій я живу), які явно дозволяють зворотну інженерію в контексті розробки сумісних форматів зберігання даних або протоколів передачі, абзаців у ліцензії або ToS, які намагаються заборонити недійсні. (У цьому розділі все, наскільки я знаю, я не юрист)
Які речі слід обчислювати локально, а які - на сервері?
Ми обчислюємо все, що стосується логіки гри на сервері. Клієнт передбачить певні події для того, щоб гра була безперебійною. Але врешті-решт сервер завжди має рацію.
Прогнозовані події - це, наприклад, зупинка руху при зіткненні. Стендаль використовує сітку для позиціонування елементів. І з точки зору сервера, верхній лівий кут кожної сутності знаходиться рівно на одному квадраті. Але клієнт плавно перемістить їх між плитками. Це також намалюватиме псевдо 3d ефект. Таким чином, особа, яка має базу 1x1, може бути вище у клієнта.
Як збалансувати проблеми з навантаженням?
Постарайтеся зробити це максимально просто, щоб полегшити технічне обслуговування.
Балансування навантаження статичного контенту добре відоме в області кластерних серверів http та мереж розповсюдження контенту.
Досить проста концепція збалансування навантаження ігрових служб - це розділення серверів на регіони / зони. Тож зони змінного струму знаходяться на одному сервері, а зони DF - на іншому. Це особливо легко, якщо ви не можете шукати зони з одного набору до зон в іншому. Вам потрібно покласти кілька чеків, щоб клієнт міг підключитися лише до зонового сервера, відповідального за зону, в якій знаходиться плеєр.
Найпростіший спосіб перенести гравців з одного сервера на інший - записати їх у базу даних, сказати клієнту підключитися до іншого сервера зони та відключити їх від поточного. Потім клієнт підключиться до нового сервера зони, який завантажить його з бази даних. (Оскільки у будь-якому випадку вам потрібне завантаження з / зберігання до коду бази даних, прямий зв'язок між серверами для передачі даних може бути здійснено пізніше).
Деякі додаткові глобальні сервіси потрібні через: Під час входу клієнтам потрібно повідомити про підключення до правильного зонного сервера. І ви можете захотіти всесвітню систему чатів.
Я детально розглядав цю тему в розділі Як досягається балансування навантаження в ММО?