През последните две седмици работих върху мрежов двигател за моята игра. Преди това не знаех абсолютно нищо за мрежовите технологии в игрите, затова прочетох множество статии и направих безброй експерименти, за да разбера всички концепции и да мога да напиша собствен мрежов двигател.

В това ръководство бих искал да споделя с вас различни концепции, които трябва да проучите преди да напишете собствен игрови двигател, както и най-добрите ресурси и статии за изучаването им.

Накратко, съществуват два основни типа мрежови архитектури: peer-to-peer и клиент-серверна. В peer-to-peer архитектурата (p2p) данните се предават между всяка двойка свързани играчи, докато в клиент-серверната архитектура данните се предават само между играчите и сървъра.

Въпреки че архитектурата peer-to-peer все още се използва в някои игри, стандартът е клиент-серверна: тя е по-лесна за реализиране, изисква по-малко пропускна способност и улеснява защитата от измами. Затова в това ръководство ще се фокусираме върху клиент-серверната архитектура.

По-специално, най-много ни интересуват авторитарните сървъри: в такива системи сървърът винаги е прав. Например, ако играчът смята, че е на координати (10, 5), а сървърът му казва, че е на (5, 3), клиентът трябва да промени позицията си на тази, която сървърът предава, а не обратното. Използването на авторитарни сървъри опростява откритията на измамници.

В игровите мрежови системи съществуват три основни компонента:

• Транспортен протокол: как се предават данни между клиентите и сървъра.
• Протокол на приложението: какво се предава от клиентите на сървъра и от сървъра на клиентите и в какъв формат.
• Логика на приложението: как предаваните данни се използват за актуализиране на състоянието на клиентите и сървъра.

Много е важно да разберете ролята на всяка част и свързаните с тях трудности.

Транспортен протокол

Първата стъпка е да изберете протокол за транспортиране на данни между сървъра и клиентите. За това съществуват два интернет протокола: TCP и UDP. Но можете да създадете и собствен транспортен протокол въз основа на един от тях или да използвате библиотека, в която те се използват.

Сравнение на TCP и UDP

И TCP, и UDP се основават на IP. IP позволява да се предава пакет от източник на получател, но не дава гаранции, че изпратеният пакет рано или късно ще достигне до получателя, че ще му стигне поне веднъж и че последователността на пакетите ще пристигне в правилния ред. Освен това, пакетът може да съдържа само ограничен размер на данни, зададен от величината MTU.

UDP е просто тънък слой над IP. Следователно, той има същите ограничения. За разлика от него, TCP притежава множество особености. Той осигурява надеждно подредено свързване между два възела с проверка за грешки. Следователно, TCP е изключително удобен и се използва в множество други протоколи, например в HTTP, FTP и SMTP. Но всички тези функции имат своята цена: закъснение.

За да разберем защо тези функции могат да предизвикат закъснение, трябва да разберем как работи TCP. Когато възел-изпращач предава пакет на възел-получател, той очаква да получи потвърждение (ACK). Ако след определено време не го получи (защото пакетът или потвърждението са били изгубени или по някакви други причини), той изпраща пакета отново. Освен това, TCP гарантира получаването на пакетите в правилния ред, затова, докато изгубеният пакет не бъде получен, всички останали пакети не могат да бъдат обработени, дори ако вече са получени от възела-получател.

Но както вероятно разбирате, закъснението в многопотребителските игри е много важно, особено в активни жанрове като FPS. Именно затова много игри използват UDP с собствен протокол.

Собственият протокол на основата на UDP може да е по-ефективен от TCP по различни причини. Например, той може да маркира някои пакети като надеждни, а други – като ненадеждни. Затова не го интересува дали ненадеждният пакет е достигнал до получателя. Или може да обработва няколко потока данни, така че загубеният пакет в един поток да не забавя останалите потоци. Например, може да съществува поток за въвеждане от играча и още един поток за съобщения в чата. Ако съобщение в чата, което не е спешно, е загубено, то няма да забави активирането на входа, който е неотложен. Или собствените протоколи могат да реализират надеждност по друг начин в сравнение с TCP, за да бъдат по-ефективни в условията на видеоигри.

Така че, ако TCP е толкова лош, ще създаваме ли свой транспортен протокол на базата на UDP?

Всичко е малко по-сложно. Въпреки че TCP е почти субоптимален за игровите мрежови системи, той може да работи много добре конкретно във вашата игра и да спести вашето драгоценно време. Например, забавянето може и да не бъде проблем за игра с ходове или игра, която може да се играе само в LAN мрежи, където забавянията и загубата на пакети са много по-малко, отколкото в интернет.

В много успешни игри, включително World of Warcraft, Minecraft и Terraria, се използва TCP. Въпреки това, в повечето FPS се прилагат собствени протоколи на базата на UDP, така че по-долу ще говорим за тях по-подробно.

Ако решите да използвате TCP, уверете се, че е изключен алгоритъмът на Нейгъл, тъй като той буферира пакетите преди изпращане, което увеличава забавянето.

За да научите повече за разликите между UDP и TCP в контекста на многопользователски игри, можете да прочетете статията на Глен Фидлър UDP vs. TCP.

Собствен протокол

Така че искате да създадете собствен транспортен протокол, но не знаете откъде да започнете? Имате късмет, защото Глен Фидлър е написал две невероятни статии по този въпрос. В тях ще намерите много умни идеи.

Първата статия, Networking for Game Programmers от 2008 г., е по-лесна от втората, Building A Game Network Protocol от 2016 г. Препоръчвам да започнете с по-стария текст.

Имайте предвид, че Глен Фидлър е голям привърженик на използването на собствен протокол на базата на UDP. След като прочетете неговите статии, вероятно ще приемете неговото мнение, че TCP има сериозни недостатъци в видеоигрите и ще искате да реализирате собствен протокол.

Но ако сте новак в работата с мрежи, направете си услуга и използвайте TCP или библиотека. За успешната реализация на собствен транспортен протокол, предварително трябва да научите много.

Мрежови библиотеки

Ако ви е необходимо нещо по-ефективно от TCP, но не искате да се затруднявате с реализирането на собствен протокол и да се задълбочавате в детайлите, можете да се възползвате от мрежова библиотека. Има много от тях:

• yojimbo на Глен Фидлър
• RakNet, която вече не се поддържа, но нейният форк SLikeNet изглежда все още е активен.
• ENet — библиотека, създадена за многопользователски FPS Cube
• GameNetworkingSockets на компанията Valve

Не съм опитвал всички от тях, но предпочитам ENet, защото е лесна за използване и надеждна. Освен това разполага с ясна документация и уроци за начинаещи.

Транспортен протокол: заключение

В обобщение: съществуват два основни транспортни протоколи: TCP и UDP. TCP предлага множество полезни функции: надеждност, запазване на реда на пакетите, откритие на грешки. UDP няма нито едно от тези предимства, но TCP, по своята същност, има по-високи закъснения, които не са допустими за някои игри. Тоест, за да се осигурят ниски закъснения, може да се създаде собствен протокол на базата на UDP или да се използва библиотека, която реализира транспортен протокол на UDP и е адаптирана за многопотребителски видеоигри.

Изборът между TCP, UDP и библиотеката зависи от няколко фактора. Първо, от нуждите на играта: нуждае ли се от ниски закъснения? На второ място, от изискванията на приложния протокол: нужен ли е надежден протокол? Както ще видим в следващата част, може да се създаде приложен протокол, за който ненадеждният протокол напълно отговаря. Накрая, трябва също да се отчете опитността на разработчика на мрежовия двигател.

Имам два съвета:

• Максимално абстрахирайте транспортния протокол от останалата част на приложението, за да може лесно да бъде заменен, без да е нужно да презаписвате целия код.
• Не се занимавайте с преждевременна оптимизация. Ако не сте специалист по мрежи и не сте сигурни, дали ви е необходим собствен транспортен протокол на базата на UDP, можете да започнете с TCP или библиотека, осигуряваща надеждност, а след това да тествате и измервате производителността. Ако възникнат проблеми и сте сигурни, че причината е в транспортния протокол, може да е време да създадете свой собствен транспортен протокол.

В заключение на тази част ви препоръчвам да прочетете Introduction to Multiplayer Game Programming на Брайън Хук, в която се разглеждат множество от темите, обсъждани тук.

Приложен протокол

Сега, когато можем да обменяме данни между клиентите и сървъра, трябва да решим какви данни именно да предаваме и в какъв формат.

Класическата схема е, че клиентите изпращат на сървъра вход или действия, а сървърът изпраща на клиентите текущото игрално състояние.

Сървърът изпраща не пълно, а филтрирано състояние с обекти, които се намират близо до играча. Той го прави по три причини. Първо, пълното състояние може да бъде твърде голямо за предаване с висока честота. Второ, клиентите обикновено се интересуват от визуални и аудио данни, тъй като по-голямата част от игровата логика се симулира на сървъра на играта. Трето, в някои игри играчът не трябва да знае определени данни, като позицията на противника от другата страна на картата, тъй като в противен случай той може да подслушва пакети и точно да знае накъде да се движи, за да го убие.

Сериализация

Първата стъпка ще бъде преобразуването на данните, които искаме да изпратим (вход данни или игрово състояние), в подходящ формат за предаване. Този процес се нарича сериализация.

Веднага идва наум идеята да се използва човекочитаем формат, като JSON или XML. Но това ще бъде напълно неефективно и ще заеме голяма част от канала безполезно.

Вместо това се препоръчва да се използва двоичен формат, който е много по-компактен. Тоест, пакетите ще съдържат само няколко байта. Тук трябва да се вземе предвид проблемът с порядъка на байтовете, който може да се различава на различни компютри.

За сереализиране на данни може да се използва библиотека, например:

• FlatBuffers на компанията Google
• Cap’n Proto на компанията Sandstorm
• cereal на Шейн Грант и Рандолф Вурхис

Просто се уверете, че библиотеката създава преносими архиви и се грижи за реда на байтовете.

Алтернативно решение може да бъде самостоятелна реализация, която не е особено сложна, особено ако в кода използвате подход, ориентиран към данни. Освен това, тя ще ви позволи да извършвате оптимизации, които не винаги са възможни при използване на библиотека.

Глен Фидлър е написал две статии за сериализация: Четене и писане на пакети и Стратегии за сериализация.

Сжатие

Количество данни, предавани между клиентите и сървъра, е ограничено от пропускателната способност на канала. Компресирането на данни ще позволи за предаване на повече данни в всеки момент, да увеличи честотата на обновленията или просто да намали изискванията за канала.

Битова опаковка

Първата техника е битово опаковане. Тя се състои в използването на точното количество битове, необходимо за описание на нужната величина. Например, ако имате изброяване, което може да има 16 различни стойности, вместо цял байт (8 бита) можете да използвате само 4 бита.

Глен Фидлър обяснява как да реализирате това във втората част на статията Четене и писане на пакети.

Битовото опаковане работи особено добре с дискретизацията, която ще бъде темата на следващия раздел.

Дискретизация

Дискретизация е техника за компресия с загуби, която се състои в използването на подмножество от възможните стойности за кодиране на величината. Най-лесно може да се реализира дискретизация, като се закръглят числа с плаваща запетая.

Глен Фидлър (отново!) показва как да прилагате дискретизация на практика в своята статия Сжатие на моментни снимки.

Алгоритми за компресия

Следващата техника ще бъдат алгоритмите за компресия без загуби.

Ето, според мен, три най-интересни алгоритма, които трябва да знаете:

• Кодиране на Хафман с предварително изчислен код, който е изключително бърз и може да дава добри резултати. Той е използван за компресия на пакети в мрежовия двигател Quake3.
• zlib е алгоритъм за общо предназначение, който никога не увеличава обема на данните. Както можете да видите, туктой е приложен в множество области на приложение. За обновяване на състояния той може да се окаже излишен. Но може и да бъде полезен, ако трябва да изпращате на клиентите от сървъра активи, дълги текстове или релеф.
• Копиране на дълги серии е вероятно най-простият алгоритъм за компресия, но е много ефективен за определени типове данни и може да се използва като етап на предварителна обработка преди zlib. Особено е подходящ за компресия на релеф, съставен от тайлове или воксели, в които множество съседи се повтарят.

Делта-компресия

Последната методика за компресия е делта-компресия. Тя се състои в това, че се предават само разликите между текущото игрово състояние и последното състояние, получено от клиента.

Впервые она была применена в сетевом движке Quake3. Вот две статьи, объясняющих способ её использования:

• Модел на мрежата Quake3 На Брайан Хук
• Преглед на изходния код на Quake 3: мрежов модел На Фабиен Санглар [превод статии на Хабре, вижте раздел 'Мрежов модел']

Глен Фидлер също използваше това във втората част на своето изследване Сжатие на моментни снимки.

Шифроване

Освен това, може да се наложи да шифровате предаването на информация между клиентите и сървъра. Има няколко причини за това:

• приватност/конфиденциалност: съобщенията могат да бъдат прочетени само от получателя и никое друго лице, което извършва мрежово подслушване, не може да ги прочете.
• аутентикация: човек, който желае да играе ролята на играч, трябва да знае неговия ключ.
• предотвратяване на измами: злонамерените играчи ще имат много по-големи трудности да създават собствени пакети за измама, тъй като ще трябва да възпроизведат схемата на шифроване и да намерят ключа (който се сменя при всяко свързване).

Настоятелно препоръчвам да използвате библиотека за това. Предлагам да се ползва libsodium, тъй като е особено лесна и има отлични указания. Особено интересен е указанието за размяна на ключове, което позволява генерирането на нови ключове при всяко ново свързване.

Приложен протокол: заключение

С това приключваме с приложния протокол. Смятам, че компресията е напълно ненужна и решението за нейното използване зависи единствено от играта и необходимата пропускателна способност на канала. Според мен, шифроването е задължително, но в първия прототип може да се обходи без него.

Логика на приложението

Сега можем да обновяваме състоянието при клиента, но можем да се сблъскаме с проблеми със забавяне. Играчът, който подава вход, трябва да чака обновяване на състоянието на играта от сървъра, за да види какво влияние е оказал на света.

Освен това, между двете обновявания на състоянието, светът е напълно статичен. Ако честотата на обновленията е ниска, движенията ще бъдат много тромави.

Съществуват няколко техники, които могат да намалят влиянието на този проблем, и в следващия раздел ще ги обсъдим.

Техники за изглаждане на забавянията

Всички описани в този раздел техники са подробно разгледани в серията Fast-Paced Multiplayer на Габриел Гамбетта. Настоятелно препоръчвам да прочетете тази прекрасна серия статии. В нея има и интерактивна демонстрация, която показва как тези техники работят на практика.

Първата техника е да се приложи резултатът от входа директно, без да се чака отговор от сървъра. Това се нарича предсказване от страна на клиента. Въпреки това, когато клиентът получи актуализация от сървъра, той трябва да се увери, че прогнозата му е била правилна. Ако не е така, той просто трябва да промени състоянието си в съответствие с полученото от сървъра, тъй като сървърът е авторитарен. Техниката е използвана за първи път в Quake. Повече за нея може да се прочете в статия Преглед на кода на Quake Engine На Фабиен Санглар [превод на Хабра].

Вторият набор техники се използва за изглаждане на движението на други същности между две актуализации на състоянието. Има два начина да се реши тази задача: интерполация и екстраполация. При интерполацията се вземат последните две състояния и се показва преход от едно до друго. Недостатъкът ѝ е, че предизвиква малка доза закъснение, тъй като клиентът винаги вижда това, което се е случвало в миналото. Екстраполацията включва предсказването на това, къде в момента трябва да се намират съществата на базата на последното състояние, получено от клиента. Недостатъкът ѝ е, че ако съществото напълно промени посоката на движение, ще се получи голяма грешка между прогнозата и реалната позиция.

Последната, най-напреднала техника, полезна само за FPS — това е компенсация на латентността. При използване на компенсация на латентността, сървърът взема предвид закъсненията на клиента, когато той стреля в целта. Например, ако играчът е извършил хедшот на екрана си, но в действителност целта му поради закъснението се е намирала на друго място, би било несправедливо да се откаже на играча правото на убийство заради закъснението. Затова сървърът връща времето назад, в момента, когато играчът е стрелял, за да симулира какво е видял играчът на екрана си, и да провери колизията между изстрела му и целта.

Глен Фидлър (както винаги!) написа през 2004 година статия Network Physics (2004), в която заложи основите на синхронизацията на симулацията на физиката между сървъра и клиента. През 2014 година той написа нова серия статии Networking Physics, в която описва други техники за синхронизация на симулацията на физиката.

Също така в уики на компания Valve има две статии, Source Multiplayer Networking и Методи за компенсиране на латентността в проектиране и оптимизация на протоколи в играта , в които се разглежда компенсацията на закъсненията.

Предотвратяване на измами

Съществуват две основни техники за предотвратяване на измами.

Първо: усложняването на изпращането на злонамерени пакети от играчи. Както вече беше споменато, добър начин за реализиране е шифрирането.

Второ: авторитарният сървър трябва да получава само команди/вход/действия. Клиентът не трябва да има възможност да променя състоянието на сървъра, освен чрез изпращане на вход. Тогава сървърът всеки път при получаване на вход трябва да проверява допустимостта му преди да го приложи.

Логика на приложението: заключение

Препоръчвам ви да реализирате начин за симулиране на големи закъснения и ниски честоти на обновление, за да можете да тествате поведението на играта си в лоши условия, дори когато клиентът и сървърът работят на един и същи компютър. Това значително ще опрости реализирането на методи за изглаждане на закъсненията.

Други полезни ресурси

Ако искате да проучите други ресурси, посветени на мрежовите модели, можете да ги намерите тук:

• Блог на Глен Фидлър — струва си да прочетете целия му блог, в него има много отлични статии. Тук събрани са всички статии по мрежовите технологии.
• Awesome Game Networking на автора М. Фатих МАР — това е подробен списък със статии и видеа за мрежови игрови движки.
• В wiki на сабреддита r/gamedev също има много полезни връзки.

Източник: habr.com