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

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

Като цяло има два основни типа мрежови архитектури: 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, уверете се, че е деактивиран Алгоритъмът на Nagle, защото буферира пакетите преди изпращане, което означава, че увеличава забавянето.

За да научите повече за разликите между UDP и TCP в контекста на мултиплейър игри, вижте статията на Glenn Fiedler UDP срещу. TCP.

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

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

Първа статия Работа в мрежа за програмисти на игри 2008, по-лесен от втория Изграждане на мрежов протокол за игра 2016 г. Препоръчвам ви да започнете с по-стария.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• FlatBuffers Google
• Cap'n Proto Пясъчна буря
• зърнени култури Шейн Грант и Рандолф Вурхийс

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

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

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

компресия

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

Опаковка на битове

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

Glenn Fiedler обяснява как да приложите това във втората част на статията. Четене и писане на пакети.

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

Вземане на проби

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

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

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

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

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

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

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

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

За първи път е използван в мрежовия двигател на Quake3. Ето две статии, обясняващи как да го използвате:

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

Глен Фидлър също го използва във втората част на статията си. Компресиране на моментна снимка.

Шифрование

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

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

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

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

Това завършва протокола за приложение. Вярвам, че компресията е напълно незадължителна и решението да се използва зависи само от играта и необходимата честотна лента. Шифроването според мен е задължително, но в първия прототип можете и без него.

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

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

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

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

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

Всички техники, описани в този раздел, се обсъждат подробно в поредицата. Бърз мултиплейър Габриел Гамбета. Силно препоръчвам да прочетете тази страхотна поредица от статии. Той също така включва интерактивна демонстрация, за да видите как тези техники работят на практика.

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

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

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

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

Има и две статии в уикито на Valve, Изходна мрежа за мултиплейър и Методи за компенсиране на латентността в дизайна и оптимизацията на протокола клиент/сървър в играта занимаващи се с обезщетение за забавяне.

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

Има две основни техники за предотвратяване на измама.

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

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

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

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

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

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

• Блогът на Глен Фидлър — струва си да прочетете целия му блог, в него има много отлични статии. Тук всички статии за мрежовите технологии са събрани.
• Страхотна игра в мрежа от M. Fatih MAR е изчерпателен списък от статии и видеоклипове за мрежови двигатели за видеоигри.
• В wiki subreddit r/gamedev Има и много полезни връзки.

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