Последните две недели работев на онлајн моторот за мојата игра. Пред ова, воопшто не знаев ништо за вмрежување во игрите, па прочитав многу написи и направив многу експерименти за да ги разберам сите концепти и да можам да напишам свој мрежен мотор.

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

Општо земено, постојат два главни типа на мрежни архитектури: peer-to-peer и клиент-сервер. Во архитектурата peer-to-peer (p2p), податоците се пренесуваат помеѓу кои било парови поврзани играчи, додека во архитектурата клиент-сервер, податоците се пренесуваат само помеѓу играчите и серверот.

Иако архитектурата peer-to-peer сè уште се користи во некои игри, клиент-серверот е стандардот: полесно е да се имплементира, бара помала ширина на каналот и ја олеснува заштитата од мамење. Затоа, во ова упатство ќе се фокусираме на архитектурата клиент-сервер.

Конкретно, најмногу сме заинтересирани за авторитарни сервери: во такви системи, серверот е секогаш во право. На пример, ако играчот мисли дека е на координатите (10, 5), а серверот му каже дека е на (5, 3), тогаш клиентот треба да ја замени својата позиција со онаа што ја пријавил серверот, а не порок обратно. Користењето на авторитетни сервери го олеснува идентификувањето на измамниците.

Системите за мрежни игри имаат три главни компоненти:

• Транспортен протокол: како податоците се пренесуваат помеѓу клиентите и серверот.
• Протокол за апликација: што се пренесува од клиенти на сервер и од сервер до клиенти и во кој формат.
• Логика на апликацијата: како се користат пренесените податоци за ажурирање на состојбата на клиентите и серверот.

Многу е важно да се разбере улогата на секој дел и предизвиците поврзани со нив.

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

Првиот чекор е да изберете протокол за транспорт на податоци помеѓу серверот и клиентите. Постојат два Интернет протоколи за ова: TCP и UDP. Но, можете да креирате сопствен транспортен протокол врз основа на еден од нив или да користите библиотека што ги користи.

Споредба на TCP и UDP

И TCP и UDP се базираат на IP. ИП дозволува пакетот да се пренесе од извор до примач, но не гарантира дека испратениот пакет порано или подоцна ќе стигне до примачот, дека ќе го достигне барем еднаш и дека секвенцата на пакети ќе пристигне во правилна со цел. Покрај тоа, пакетот може да содржи само ограничена количина на податоци, дадена од вредноста МТУ.

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.

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

Значи, сакате да креирате сопствен транспортен протокол, но не знаете од каде да започнете? Имате среќа затоа што Глен Фидлер напиша две неверојатни написи за ова. Во нив ќе најдете многу паметни мисли.

Првата статија Вмрежување за програмери за игри 2008 година, полесна од втората, Изградба на протокол за мрежа за игри 2016 година. Ви препорачувам да започнете со постарата.

Забележете дека Глен Фидлер е голем поборник за користење на прилагоден протокол базиран на UDP. И откако ќе ги прочитате неговите написи, веројатно ќе го усвоите неговото мислење дека TCP има сериозни недостатоци во видео игрите и ќе сакате да имплементирате свој протокол.

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

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

Ако ви треба нешто поефикасно од TCP, но не сакате да поминете низ мака со имплементирање на сопствен протокол и да навлегувате во многу детали, можете да користите мрежна библиотека. Има многу од нив:

• јоџимбо Глен Фидлер
• РакНет, кој повеќе не е поддржан, туку вилушка од него SLikeNet Изгледа дека сè уште е активен.
• ENet е библиотека создадена за мултиплеер FPS Коцка
• Играмрежни приклучоци Вентил

Не сум ги пробал сите, но претпочитам ENet бидејќи е лесен за употреба и сигурен. Покрај тоа, има јасна документација и упатство за почетници.

Транспортен протокол: Заклучок

Да резимираме: постојат два главни транспортни протоколи: TCP и UDP. TCP има многу корисни карактеристики: доверливост, зачувување на нарачката на пакети, откривање грешки. UDP го нема сето ова, но TCP по својата природа има зголемена латентност, што е неприфатливо за некои игри. Односно, за да се обезбеди мала латентност, можете да креирате сопствен протокол базиран на UDP или да користите библиотека што имплементира транспортен протокол на UDP и е прилагодена за видео игри со повеќе играчи.

Изборот помеѓу TCP, UDP и библиотеката зависи од неколку фактори. Прво, од потребите на играта: дали и треба мала латентност? Второ, од барањата на протоколот за апликација: дали му треба сигурен протокол? Како што ќе видиме во следниот дел, можно е да се создаде протокол за апликација за кој недоверлив протокол е сосема соодветен. Конечно, треба да го земете предвид и искуството на развивачот на мрежниот мотор.

Имам два совети:

• Апстрактирајте го транспортниот протокол од остатокот од апликацијата колку што е можно повеќе за да може лесно да се замени без да се препише целиот код.
• Не преоптимизирајте. Ако не сте експерт за вмрежување и не сте сигурни дали ви треба прилагоден транспортен протокол базиран на UDP, можете да започнете со TCP или библиотека што обезбедува доверливост, а потоа да ги тестирате и измерите перформансите. Ако се појават проблеми и сте уверени дека причината е транспортниот протокол, тогаш можеби е време да креирате сопствен транспортен протокол.

На крајот од овој дел ви препорачувам да прочитате Вовед во програмирање на игри со повеќе играчи од Брајан Хук, кој опфаќа многу од темите што се дискутираат овде.

Протокол за апликација

Сега кога можеме да разменуваме податоци помеѓу клиентите и серверот, треба да одлучиме кои податоци да ги пренесеме и во кој формат.

Класичната шема е дека клиентите испраќаат влез или дејства до серверот, а серверот ја испраќа моменталната состојба на играта до клиентите.

Серверот не ја испраќа целосната состојба, туку филтрираната состојба со ентитети кои се наоѓаат во близина на плеерот. Тој го прави ова од три причини. Прво, целосната состојба може да биде преголема за да се пренесе на висока фреквенција. Второ, клиентите се главно заинтересирани за визуелни и аудио податоци, бидејќи поголемиот дел од логиката на играта е симулирана на серверот на играта. Трето, во некои игри играчот не треба да знае одредени податоци, на пример, позицијата на непријателот од другата страна на мапата, во спротивно може да шмрка пакети и да знае точно каде да се движи за да го убие.

Сериизација

Првиот чекор е да ги претвориме податоците што сакаме да ги испратиме (влез или состојба на игра) во формат погоден за пренос. Овој процес се нарекува серијализација.

Мислата што веднаш ми паѓа на ум е да се користи формат читлив за луѓе, како што се JSON или XML. Но, ова ќе биде целосно неефикасно и ќе го потроши поголемиот дел од каналот.

Наместо тоа, се препорачува да се користи бинарен формат, кој е многу покомпактен. Односно, пакетите ќе содржат само неколку бајти. Има проблем што треба да се разгледа овде редослед на бајти, што може да се разликува на различни компјутери.

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

• Рамни бафери Google
• Кап'н Прото Компанија за песочна бура
• житни култури Шејн Грант и Рендолф Ворхис

Само погрижете се библиотеката да создава преносливи архиви и да се грижи за ендјанноста.

Алтернативно решение е да го имплементирате сами, тоа не е особено тешко, особено ако користите пристап заснован на податоци кон вашиот код. Дополнително, ќе ви овозможи да извршите оптимизации кои не се секогаш можни при користење на библиотеката.

Глен Фидлер напиша две статии за серијализацијата: Пакети за читање и пишување и Стратегии за серијализација.

Компресија

Количината на податоци пренесени помеѓу клиентите и серверот е ограничена од пропусниот опсег на каналот. Компресирањето на податоците ќе ви овозможи да пренесувате повеќе податоци во секоја слика, да ја зголемите фреквенцијата на ажурирање или едноставно да ги намалите барањата за каналот.

Бит пакување

Првата техника е малку пакување. Се состои од користење на точно бројот на битови кои се неопходни за да се опише саканата вредност. На пример, ако имате енум што може да има 16 различни вредности, тогаш наместо цел бајт (8 бита), можете да користите само 4 бита.

Глен Фидлер објаснува како да се имплементира ова во вториот дел од статијата Пакети за читање и пишување.

Пакувањето на битови работи особено добро со земање примероци, што ќе биде тема на следниот дел.

Земање мостри

Земање мостри е техника на компресија со загуби која користи само подмножество на можни вредности за кодирање на вредност. Најлесен начин да се спроведе дискретизација е со заокружување на броевите со подвижна запирка.

Глен Фидлер (повторно!) покажува како да се спроведе земање примероци во пракса во својата статија Компресија на слика.

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

Следната техника ќе биде алгоритми за компресија без загуби.

Еве, според мое мислење, трите најинтересни алгоритми што треба да ги знаете:

• Хафман кодирање со претходно пресметан код, кој е исклучително брз и може да даде добри резултати. Се користеше за компресија на пакети во мрежниот мотор Quake3.
• злиб е алгоритам за компресија за општа намена кој никогаш не ја зголемува количината на податоци. Како можеш да видиш тука, се користи во различни апликации. Може да биде излишно за ажурирање на состојбите. Но, може да биде корисно ако треба да испраќате средства, долги текстови или терен до клиентите од серверот.
• Должини на копирање - Ова е веројатно наједноставниот алгоритам за компресија, но е многу ефикасен за одредени типови на податоци и може да се користи како чекор за претходна обработка пред zlib. Тој е особено погоден за компресирање на терен составен од плочки или воксели во кои се повторуваат многу соседни елементи.

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

Последната техника на компресија е делта компресија. Се состои во тоа што се пренесуваат само разликите помеѓу моменталната состојба на играта и последната состојба добиена од клиентот.

За прв пат беше користен во мрежниот мотор Quake3. Еве две статии кои објаснуваат како да го користите:

• Моделот за вмрежување Quake3 Брајан Хук
• Преглед на изворниот код на Quake 3: Мрежен модел Фабиен Сангларс [превод статии за Хабре, видете го делот „Мрежен модел“]

Глен Фидлер го користел и во вториот дел од својата статија Компресија на слика.

Шифрирање

Дополнително, можеби ќе треба да го шифрирате преносот на информации помеѓу клиентите и серверот. Постојат неколку причини за ова:

• приватност/доверливост: пораките може да ги чита само примачот, а ниту едно друго лице кое ја душка мрежата нема да може да ги чита.
• автентикација: лицето кое сака да ја игра улогата на играч мора да го знае неговиот клуч.
• Превенција на измами: Ќе биде многу потешко за злонамерните играчи да создадат свои пакети за измами, тие ќе мора да ја репродуцираат шемата за шифрирање и да го најдат клучот (кој се менува со секоја врска).

Силно препорачувам да користите библиотека за ова. Предлагам користење либсодиум, бидејќи е особено едноставен и има одлични упатства. Особено интересен е туторијалот за размена на клучеви, што ви овозможува да генерирате нови клучеви со секоја нова врска.

Протокол за апликација: Заклучок

Ова го завршува нашиот протокол за апликација. Верувам дека компресирањето е целосно опционално и одлуката да се користи зависи само од играта и потребниот пропусен опсег. Шифрирањето, според мое мислење, е задолжително, но во првиот прототип можете без него.

Логика на апликацијата

Сега можеме да ја ажурираме состојбата на клиентот, но може да наиде на проблеми со латентност. Играчот, откако ќе го заврши внесувањето, треба да почека состојбата на играта да се ажурира од серверот за да види какво влијание имало врз светот.

Покрај тоа, помеѓу две ажурирања на државата, светот е целосно статичен. Ако стапката на ажурирање на државата е ниска, тогаш движењата ќе бидат многу непредвидливи.

Постојат неколку техники за да се намали влијанието на овој проблем, и ќе ги опфатам во следниот дел.

Техники за измазнување на латенцијата

Сите техники опишани во овој дел се детално разгледани во серијата Мултиплеер со брзо темпо Габриел Гамбета. Силно препорачувам да ја прочитате оваа одлична серија на статии. Вклучува и интерактивно демо кое ви овозможува да видите како функционираат овие техники во пракса.

Првата техника е директно да се примени влезниот резултат без да се чека одговор од серверот. Тоа се нарекува прогнозирање од страна на клиентот. Меѓутоа, кога клиентот ќе добие ажурирање од серверот, тој мора да потврди дека неговото предвидување било точно. Ако тоа не е случај, тогаш тој само треба да ја смени својата состојба според она што го добил од серверот, бидејќи серверот е авторитарен. Оваа техника за прв пат беше употребена во Quake. Можете да прочитате повеќе за тоа во статијата Преглед на кодот на Quake Engine Фабиен Сангларс [превод на Хабре].

Вториот сет на техники се користи за да се изедначи движењето на други ентитети помеѓу две ажурирања на состојби. Постојат два начини да се реши овој проблем: интерполација и екстраполација. Во случај на интерполација се земаат последните две состојби и се прикажува преминот од едната во другата. Неговиот недостаток е тоа што предизвикува мало доцнење бидејќи клиентот секогаш гледа што се случило во минатото. Екстраполацијата е за предвидување каде ентитетите треба да бидат сега врз основа на последната состојба добиена од клиентот. Неговиот недостаток е што ако субјектот целосно ја промени насоката на движење, тогаш ќе има голема грешка помеѓу прогнозата и вистинската позиција.

Најновата, најнапредната техника корисна само во FPS е компензација на заостанување. При користење на компензација на задоцнување, серверот ги зема предвид доцнењата на клиентот кога тој пука во целта. На пример, ако играчот изврши удар со глава на својот екран, но во реалноста неговата цел беше на друга локација поради доцнење, тогаш би било неправедно да му се ускрати правото на играчот да убие поради доцнење. Затоа, серверот го премотува времето назад до моментот кога играчот пукал за да симулира што играчот видел на својот екран и да провери дали има судир меѓу нивниот истрел и целта.

Глен Фидлер (како и секогаш!) напиша статија во 2004 година Мрежна физика (2004), во која тој ги постави темелите за синхронизирање на физичките симулации помеѓу серверот и клиентот. Во 2014 година напиша нова серија написи Физика за вмрежување, кој опиша други техники за синхронизирање на физички симулации.

Има и две статии на викито на Valve, Извор Мултиплеер вмрежување и Методи за компензација на латентност во дизајнот и оптимизацијата на протоколот во играта на клиент/сервер кои размислуваат за компензација за доцнење.

Спречување на мамење

Постојат две главни техники за спречување на изневерувањето.

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

Второ: авторитарен сервер треба да прима само команди/влез/дејства. Клиентот не треба да може да ја менува состојбата на серверот освен со испраќање влез. Потоа, секој пат кога серверот добива влез, мора да провери дали е валиден пред да го користи.

Логика на примена: заклучок

Ви препорачувам да имплементирате начин за симулирање на високи доцнења и ниски стапки на освежување за да можете да го тестирате однесувањето на вашата игра во лоши услови, дури и кога клиентот и серверот работат на ист компјутер. Ова во голема мера ќе ја поедностави имплементацијата на техниките за измазнување на одложување.

Други корисни ресурси

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

• Блог на Глен Фидлер – Вреди да се прочита целиот негов блог, таму има многу одлични статии. Тука Сите статии за мрежните технологии се собрани.
• Прекрасно вмрежување со игри од M. Fatih MAR е сеопфатна листа на статии и видеа за мотори за онлајн видео игри.
• В вики на подредит р/гамедев Има и многу корисни врски.

Извор: www.habr.com