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

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

Генерално, постоје два главна типа мрежних архитектура: равноправни и клијент-сервер. У пеер-то-пеер (п2п) архитектури, подаци се преносе између било ког пара повезаних играча, док се у архитектури клијент-сервер подаци преносе само између играча и сервера.

Иако се пеер-то-пеер архитектура и даље користи у неким играма, клијент-сервер је стандард: лакша је за имплементацију, захтева мању ширину канала и олакшава заштиту од варања. Стога ћемо се у овом туторијалу фокусирати на архитектуру клијент-сервер.

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

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

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

Веома је важно разумети улогу сваког дела и изазове који су са њима повезани.

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

Први корак је одабир протокола за транспорт података између сервера и клијената. За ово постоје два Интернет протокола: ТЦП и УДП. Али можете креирати сопствени транспортни протокол на основу једног од њих или користити библиотеку која их користи.

Поређење ТЦП-а и УДП-а

И ТЦП и УДП су засновани на IP. ИП омогућава да се пакет пренесе од извора до примаоца, али не гарантује да ће послати пакет пре или касније стићи до примаоца, да ће бар једном стићи до њега и да ће редослед пакета стићи у исправном ред. Штавише, пакет може да садржи само ограничену количину података, дату вредношћу МТУ.

УДП је само танак слој на врху ИП-а. Дакле, има иста ограничења. Насупрот томе, ТЦП има много функција. Обезбеђује поуздану, уредну везу између два чвора са провером грешака. Отуда је ТЦП веома згодан и користи се у многим другим протоколима, нпр. ХТТП, ФТП и СМТП. Али све ове карактеристике имају своју цену: одлагање.

Да бисмо разумели зашто ове функције могу да изазову кашњење, морамо разумети како ТЦП функционише. Када чвор који шаље пакет преноси пакет на пријемни чвор, очекује да ће примити потврду (АЦК). Ако га после одређеног времена не прими (јер је изгубљен пакет или потврда, или из неког другог разлога), онда поново шаље пакет. Штавише, ТЦП гарантује да су пакети примљени у исправном редоследу, тако да све док се изгубљени пакет не прими, сви остали пакети не могу да се обрађују, чак и ако их је домаћин који их је већ примио.

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

Изворни протокол заснован на УДП-у може бити ефикаснији од ТЦП-а из различитих разлога. На пример, може да означи неке пакете као поуздане, а друге као непоуздане. Стога, није важно да ли непоуздани пакет стигне до примаоца. Или може да обради више токова података тако да изгубљени пакет у једном току не успори преостале токове. На пример, може постојати нит за унос играча и друга нит за поруке ћаскања. Ако се порука ћаскања која није хитна изгуби, неће успорити унос који је хитан. Или би власнички протокол могао да имплементира поузданост другачије од ТЦП-а да би био ефикаснији у окружењу видео игрица.

Дакле, ако је ТЦП толико лош, онда ћемо креирати сопствени транспортни протокол заснован на УДП-у?

Мало је компликованије. Иако је ТЦП скоро неоптималан за мрежне системе за игре, он може прилично добро да функционише за вашу специфичну игру и уштеди вам драгоцено време. На пример, кашњење можда није проблем за игру засновану на потезу или игру која се може играти само на ЛАН мрежама, где су кашњење и губитак пакета много мањи него на Интернету.

Многе успешне игре, укључујући Ворлд оф Варцрафт, Минецрафт и Террариа, користе ТЦП. Међутим, већина ФПС-ова користи сопствене протоколе засноване на УДП-у, тако да ћемо о њима више говорити у наставку.

Ако одлучите да користите ТЦП, уверите се да је онемогућен Наглеов алгоритам, јер баферује пакете пре слања, што значи да повећава кашњење.

Да бисте сазнали више о разликама између УДП и ТЦП у контексту игара за више играча, можете прочитати чланак Глена Фиедлера УДП вс. ТЦП.

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

Дакле, желите да креирате сопствени транспортни протокол, али не знате одакле да почнете? Имате среће јер је Гленн Фиедлер написао два невероватна чланка о томе. У њима ћете наћи много паметних мисли.

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

Имајте на уму да је Гленн Фиедлер велики заговорник коришћења прилагођеног протокола заснованог на УДП-у. А након што прочитате његове чланке, вероватно ћете усвојити његово мишљење да ТЦП има озбиљне недостатке у видео игрицама и пожелећете да имплементирате сопствени протокол.

Али ако сте нови у умрежавању, учините себи услугу и користите ТЦП или библиотеку. Да бисте успешно применили сопствени транспортни протокол, морате много да научите унапред.

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

Ако вам треба нешто ефикасније од ТЦП-а, али не желите да пролазите кроз гњаважу око имплементације сопственог протокола и улажења у много детаља, можете користити мрежну библиотеку. Има их много:

• иојимбо Гленн Фиедлер
• РакНет, који више није подржан, већ је његов форк СЛикеНет Изгледа да је још увек активан.
• ЕНет је библиотека креирана за ФПС за више играча Коцка
• ГамеНетворкингСоцкетс Вентил

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

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

Да резимирамо: постоје два главна транспортна протокола: ТЦП и УДП. ТЦП има много корисних карактеристика: поузданост, очување редоследа пакета, откривање грешака. УДП нема све ово, али ТЦП по својој природи има повећано кашњење, што је за неке игре неприхватљиво. То јест, да бисте осигурали мало кашњење, можете креирати сопствени протокол заснован на УДП-у или користити библиотеку која имплементира транспортни протокол на УДП и прилагођена је за видео игре за више играча.

Избор између ТЦП, УДП и библиотеке зависи од неколико фактора. Прво, из потреба игре: да ли јој је потребна мала латенција? Друго, од захтева протокола апликације: да ли му је потребан поуздан протокол? Као што ћемо видети у следећем делу, могуће је креирати апликациони протокол за који је непоуздани протокол сасвим прикладан. Коначно, такође морате узети у обзир искуство програмера мрежног механизма.

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

• Апстрахујте транспортни протокол од остатка апликације што је више могуће тако да се може лако заменити без поновног писања целог кода.
• Немојте претерано оптимизовати. Ако нисте стручњак за умрежавање и нисте сигурни да ли вам је потребан прилагођени транспортни протокол заснован на УДП-у, можете почети са ТЦП-ом или библиотеком која обезбеђује поузданост, а затим тестирати и мерити перформансе. Ако се појаве проблеми и ако сте сигурни да је узрок транспортни протокол, можда је време да креирате сопствени транспортни протокол.

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

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

Сада када можемо да размењујемо податке између клијената и сервера, морамо да одлучимо које податке ћемо пренети и у ком формату.

Класична шема је да клијенти шаљу улаз или акције серверу, а сервер клијентима шаље тренутно стање игре.

Сервер шаље не пуно стање, већ филтрирано стање са ентитетима који се налазе у близини играча. Он то ради из три разлога. Прво, комплетно стање може бити превелико да би се преносило на високој фреквенцији. Друго, клијенти су углавном заинтересовани за визуелне и аудио податке, јер се већина логике игре симулира на серверу игре. Треће, у неким играма играч не мора да зна одређене податке, на пример, позицију непријатеља на другој страни мапе, иначе може да нањуши пакете и тачно зна где да се креће да би га убио.

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

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

Помисао која вам одмах пада на памет је коришћење формата читљивог за људе, као што су ЈСОН или КСМЛ. Али ово ће бити потпуно неефикасно и потрошиће већину канала.

Препоручује се да се уместо тога користи бинарни формат, који је много компактнији. То јест, пакети ће садржати само неколико бајтова. Овде постоји проблем који треба размотрити ред бајтова, који се могу разликовати на различитим рачунарима.

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

• ФлатБуфферс Гоогле
• Цап'н Прото Компанија Пешчана олуја
• житарице Схане Грант и Рандолпх Воорхеес

Само се побрините да библиотека креира преносиве архиве и брине о ендианнессу.

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

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

Компресија

Количина података пренетих између клијената и сервера ограничена је пропусним опсегом канала. Компресија података ће вам омогућити да пренесете више података у сваком снимку, повећате учесталост ажурирања или једноставно смањите захтеве канала.

Битно паковање

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

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

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

Узимање узорка

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

Гленн Фиедлер (опет!) показује како да се узорковање примени у пракси у свом чланку Снапсхот Цомпрессион.

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

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

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

• Хуффман кодирање са унапред израчунатим кодом, који је изузетно брз и може дати добре резултате. Коришћен је за компримовање пакета у Куаке3 мрежном механизму.
• злиб је алгоритам компресије опште намене који никада не повећава количину података. Како видиш овде, коришћен је у разним апликацијама. Може бити сувишно за ажурирање стања. Али може бити корисно ако клијентима са сервера треба да пошаљете средства, дугачке текстове или терен.
• Копирање дужине серије - Ово је вероватно најједноставнији алгоритам компресије, али је веома ефикасан за одређене врсте података, и може се користити као корак пре обраде пре злиб-а. Посебно је погодан за сабијање терена састављеног од плочица или воксела у којима се понављају многи суседни елементи.

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

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

Први пут је коришћен у Куаке3 мрежном механизму. Ево два чланка која објашњавају како да га користите:

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

Глен Фидлер га је такође користио у другом делу свог чланка Снапсхот Цомпрессион.

Шифровање

Поред тога, можда ћете морати да шифрујете пренос информација између клијената и сервера. Постоји неколико разлога за то:

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

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

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

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

Логика апликације

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

Штавише, између два ажурирања стања, свет је потпуно статичан. Ако је стопа ажурирања стања ниска, онда ће покрети бити веома трзави.

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

Технике изглађивања кашњења

Све технике описане у овом одељку су детаљно размотрене у серији Брзи мултиплаиер Габриел Гамбетта. Топло препоручујем читање ове одличне серије чланака. Такође укључује интерактивни демо који вам омогућава да видите како ове технике функционишу у пракси.

Прва техника је да примените улазни резултат директно без чекања одговора од сервера. Зове се предвиђање на страни клијента. Међутим, када клијент добије ажурирање од сервера, мора да провери да ли је његово предвиђање било тачно. Ако то није случај, онда само треба да промени своје стање према ономе што је добио од сервера, јер је сервер ауторитаран. Ова техника је први пут коришћена у Куаке-у. Више о томе можете прочитати у чланку Преглед кода Куаке Енгине Фабиен Сангларс [превод на Хабре].

Други скуп техника се користи за изглађивање кретања других ентитета између два ажурирања стања. Постоје два начина за решавање овог проблема: интерполација и екстраполација. У случају интерполације, узимају се последња два стања и приказује се прелаз из једног у друго. Његова мана је што узрокује мало кашњење јер клијент увек види шта се десило у прошлости. Екстраполација се односи на предвиђање где би сада требало да буду ентитети на основу последњег стања које је клијент примио. Његов недостатак је што ако ентитет потпуно промени правац кретања, онда ће доћи до велике грешке између прогнозе и стварне позиције.

Најновија, најнапреднија техника корисна само у ФПС-у је компензација заостајања. Приликом коришћења компензације заостајања, сервер узима у обзир кашњења клијента када пуца у мету. На пример, ако је играч извео ударац главом на свом екрану, али је у стварности његова мета била на другој локацији због кашњења, онда би било неправедно ускратити играчу право да убије због кашњења. Стога, сервер премота време уназад до тренутка када је играч пуцао да би симулирао оно што је играч видео на свом екрану и проверио да ли постоји судар између њиховог ударца и мете.

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

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

Спречавање варања

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

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

Друго: ауторитарни сервер треба да прима само команде/улаз/акције. Клијент не би требало да буде у могућности да промени стање на серверу осим слањем уноса. Затим, сваки пут када сервер прими улаз, мора да провери да ли је валидан пре него што га употреби.

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

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

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

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

• Блог Глена Фиедлера – вреди прочитати цео његов блог, тамо има много сјајних чланака. Овде Прикупљени су сви чланци о мрежним технологијама.
• Одлично умрежавање игара би М. Фатих МАР је свеобухватна листа чланака и видео снимака о интернет машинама за видео игре.
• В вики подредита р/гамедев Такође има много корисних линкова.

Извор: ввв.хабр.цом