Վերջին երկու շաբաթվա ընթացքում ես աշխատում էի իմ խաղի ցանցային շարժիչի վրա: Մինչ այդ ես ընդհանրապես ոչինչ չգիտեի խաղերում ցանցային կապի մասին, այնպես որ ես կարդացի շատ հոդվածներ և շատ փորձեր արեցի, որպեսզի հասկանամ բոլոր հասկացությունները և կարողանամ գրել իմ սեփական ցանցային շարժիչը:

Այս ուղեցույցում ես կցանկանայի ձեզ հետ կիսվել տարբեր հասկացություններով, որոնք դուք պետք է սովորեք նախքան ձեր սեփական խաղային շարժիչը գրելը, ինչպես նաև դրանք սովորելու լավագույն ռեսուրսներն ու հոդվածները:

Ընդհանուր առմամբ, գոյություն ունի ցանցային ճարտարապետության երկու հիմնական տեսակ՝ հավասարազոր և հաճախորդ-սերվեր: Peer-to-peer (p2p) ճարտարապետության մեջ տվյալները փոխանցվում են ցանկացած զույգ միացված խաղացողների միջև, մինչդեռ հաճախորդ-սերվեր ճարտարապետության մեջ տվյալները փոխանցվում են միայն խաղացողների և սերվերի միջև:

Թեև որոշ խաղերում դեռևս օգտագործվում է գործընկեր-սերվեր ճարտարապետությունը, հաճախորդ-սերվեր ճարտարապետությունը ստանդարտ է. այն ավելի հեշտ է իրականացնել, պահանջում է ավելի փոքր ալիքի լայնություն և հեշտացնում է պաշտպանությունը խաբեությունից: Հետևաբար, այս ուղեցույցում մենք կկենտրոնանանք հաճախորդ-սերվեր ճարտարապետության վրա:

Մասնավորապես, մեզ ամենաշատը հետաքրքրում են ավտորիտար սերվերները. նման համակարգերում սերվերը միշտ ճիշտ է: Օրինակ, եթե խաղացողը կարծում է, որ գտնվում է (10, 5), իսկ սերվերը նրան ասում է, որ գտնվում է (5, 3), ապա հաճախորդը պետք է փոխարինի իր դիրքը այն դիրքով, որը սերվերը հայտնում է, այլ ոչ թե հակառակը: Հեղինակավոր սերվերների օգտագործումը հեշտացնում է խաբեբաներին ճանաչելը:

Խաղային ցանցային համակարգերում կան երեք հիմնական բաղադրիչ.

• Տրանսպորտային արձանագրություն. ինչպես են տվյալները փոխանցվում հաճախորդների և սերվերի միջև:
• Կիրառման արձանագրություն. ինչ է փոխանցվում հաճախորդներից սերվեր և սերվերից հաճախորդներին և ինչ ձևաչափով:
• Կիրառական տրամաբանություն. ինչպես են փոխանցված տվյալները օգտագործվում հաճախորդների և սերվերի վիճակը թարմացնելու համար:

Շատ կարևոր է հասկանալ յուրաքանչյուր մասի դերը և դրանց հետ կապված դժվարությունները:

Տրանսպորտային արձանագրություն

Առաջին քայլը սերվերի և հաճախորդների միջև տվյալների փոխադրման արձանագրություն ընտրելն է: Դրա համար կան երկու ինտերնետային արձանագրություններ. TCP и UDP. Բայց դուք կարող եք ստեղծել ձեր սեփական տրանսպորտային արձանագրությունը դրանցից մեկի հիման վրա կամ օգտագործել գրադարան, որն օգտագործում է դրանք:

TCP-ի և UDP-ի համեմատություն

Ե՛վ TCP, և՛ UDP հիմնված են IP. IP-ն թույլ է տալիս փաթեթը փոխանցել աղբյուրից ստացողին, սակայն դա չի երաշխավորում, որ ուղարկված փաթեթը վաղ թե ուշ կհասնի ստացողին, որ այն կհասնի նրան գոնե մեկ անգամ, և որ փաթեթների հաջորդականությունը կհասնի: ճիշտ կարգը. Ավելին, փաթեթը կարող է պարունակել միայն սահմանափակ տվյալների չափ՝ տրված արժեքով MTU.

UDP-ն ընդամենը բարակ շերտ է IP-ի վերևում: Հետևաբար, այն ունի նույն սահմանափակումները. Ի հակադրություն, TCP-ն ունի բազմաթիվ առանձնահատկություններ: Այն ապահովում է հուսալի պատվիրված կապ երկու հանգույցների միջև սխալների ստուգմամբ: Հետևաբար, TCP-ն շատ հարմար է և օգտագործվում է շատ այլ արձանագրություններում, օրինակ՝ in 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 ընդդեմ. TCP.

Սեփականության արձանագրություն

Այսպիսով, դուք ցանկանում եք ստեղծել ձեր սեփական տրանսպորտային արձանագրությունը, բայց չգիտեք, թե որտեղից սկսել: Դուք հաջողակ եք, քանի որ Գլեն Ֆիդլերը դրա մասին երկու զարմանալի հոդված է գրել: Դրանցում շատ խելացի գաղափարներ կգտնեք։

Առաջին հոդված Ցանցային ցանց խաղերի ծրագրավորողների համար 2008, ավելի հեշտ, քան երկրորդը Խաղային ցանցի արձանագրության ստեղծում 2016թ. Խորհուրդ եմ տալիս սկսել ավելի հինից:

Տեղյակ եղեք, որ Գլեն Ֆիդլերը UDP-ի վրա հիմնված ձեր սեփական արձանագրությունն օգտագործելու մեծ կողմնակից է: Իսկ նրա հոդվածները կարդալուց հետո, հավանաբար, կընդունեք նրա կարծիքը, որ TCP-ն տեսախաղերում լուրջ թերություններ ունի, և դուք կցանկանաք ձեր սեփական արձանագրությունն իրականացնել։

Բայց եթե դուք նոր եք ցանցային, ապա ձեզ լավություն արեք և օգտագործեք TCP կամ գրադարան: Ձեր սեփական տրանսպորտային արձանագրությունը հաջողությամբ իրականացնելու համար նախապես պետք է շատ բան սովորել:

Ցանցային գրադարաններ

Եթե ​​Ձեզ անհրաժեշտ է ինչ-որ բան ավելի արդյունավետ, քան TCP-ն, բայց չեք ցանկանում անհանգստացնել ձեր սեփական արձանագրությունն իրականացնելու և շատ մանրամասների մեջ մտնելու համար, կարող եք օգտագործել ցանցային գրադարանը: Դրանք շատ են.

• յոջիմբո Գլեն Ֆիդլեր
• Ռաքնեթ, որն այլևս չի աջակցվում, այլ դրա պատառաքաղը SLikeNet կարծես ակտիվ է.
• ENet Multiplayer FPS-ի համար ստեղծված գրադարան է Խորանարդ
• GameNetworkingSockets Valve-ի կողմից

Ես բոլորը չեմ փորձել, բայց ես նախընտրում եմ ENet-ը, քանի որ այն հեշտ է օգտագործել և հուսալի: Բացի այդ, այն ունի հստակ փաստաթղթեր և ձեռնարկ սկսնակների համար:

Տրանսպորտային արձանագրության եզրակացություն

Ամփոփելու համար, կան երկու հիմնական տրանսպորտային արձանագրություններ՝ TCP և UDP: TCP-ն ունի բազմաթիվ օգտակար հատկություններ՝ հուսալիություն, փաթեթների պատվերի պահպանում, սխալի հայտնաբերում: UDP-ն չունի այդ ամենը, բայց TCP-ն, իր բնույթով, ունի բարձր ուշացում, որն անընդունելի է որոշ խաղերի համար: Այսինքն՝ ցածր ուշացում ապահովելու համար դուք կարող եք ստեղծել ձեր սեփական արձանագրությունը՝ հիմնված UDP-ի վրա կամ օգտագործել գրադարան, որն իրականացնում է տրանսպորտային արձանագրությունը UDP-ի վրա և հարմարեցված է բազմախաղացող տեսախաղերի համար:

TCP-ի, UDP-ի և գրադարանի միջև ընտրությունը կախված է մի քանի գործոններից: Նախ, խաղի կարիքներից. Արդյո՞ք դրա կարիքը ցածր է: Երկրորդ՝ կիրառական արձանագրության պահանջներից՝ վստահելի արձանագրության կարիք կա՞։ Ինչպես կտեսնենք հաջորդ մասում, հնարավոր է ստեղծել հավելվածի արձանագրություն, որի համար անվստահելի արձանագրությունը բավականին հարմար է։ Ի վերջո, դուք նույնպես պետք է հաշվի առնեք ցանցային շարժիչի մշակողի փորձը:

Ես ունեմ երկու խորհուրդ.

• Տրանսպորտային արձանագրությունը որքան հնարավոր է վերացեք մնացած հավելվածից, որպեսզի այն հեշտությամբ փոխարինվի՝ առանց ամբողջ ծածկագիրը վերաշարադրելու:
• Չափից դուրս օպտիմիզացնել: Եթե ​​դուք ցանցի փորձագետ չեք և վստահ չեք, թե արդյոք ձեզ անհրաժեշտ է ձեր սեփական UDP-ի վրա հիմնված տրանսպորտային արձանագրությունը, կարող եք սկսել TCP-ից կամ հուսալիություն ապահովող գրադարանից, այնուհետև փորձարկել և չափել կատարողականությունը: Եթե ​​դուք խնդիրներ ունեք և վստահ եք, որ դա տրանսպորտային արձանագրություն է, ապա կարող է ժամանակն է ստեղծել ձեր սեփական տրանսպորտային արձանագրությունը:

Այս մասի վերջում խորհուրդ եմ տալիս կարդալ Ներածություն Multiplayer Game Programming-ին Բրայան Հուկը, որն ընդգրկում է այստեղ քննարկված շատ թեմաներ:

Դիմումի արձանագրություն

Այժմ, երբ մենք կարող ենք տվյալների փոխանակում կատարել հաճախորդների և սերվերի միջև, մենք պետք է որոշենք, թե ինչ տվյալներ փոխանցել և ինչ ձևաչափով:

Դասական սխեման այն է, որ հաճախորդները մուտքագրում կամ գործողություններ են ուղարկում սերվերին, իսկ սերվերն ուղարկում է խաղի ընթացիկ վիճակը հաճախորդներին:

Սերվերը ուղարկում է ոչ թե ամբողջական, այլ զտված վիճակը նվագարկչի մոտ գտնվող անձանց հետ: Նա դա անում է երեք պատճառով. Նախ, ընդհանուր վիճակը կարող է չափազանց մեծ լինել բարձր հաճախականությամբ փոխանցելու համար: Երկրորդ, հաճախորդները հիմնականում հետաքրքրված են տեսողական և աուդիո տվյալների վրա, քանի որ խաղի տրամաբանության մեծ մասը մոդելավորվում է խաղի սերվերի վրա: Երրորդ, որոշ խաղերում խաղացողը կարիք չունի իմանալու որոշակի տվյալներ, ինչպես, օրինակ, թշնամու դիրքը քարտեզի մյուս կողմում, քանի որ հակառակ դեպքում նա կարող է հոտ քաշել փաթեթներից և հստակ իմանալ, թե որտեղ պետք է շարժվի իրեն սպանելու համար:

Սերիալացում

Առաջին քայլը այն տվյալները, որոնք մենք ցանկանում ենք ուղարկել (մուտքային կամ խաղի վիճակ) փոխակերպելն է փոխանցման համար հարմար ձևաչափի: Այս գործընթացը կոչվում է սերիականացում.

Միանգամից միտք է ծագում օգտագործել մարդու համար ընթեռնելի ձևաչափ, օրինակ՝ JSON կամ XML: Բայց սա լիովին անարդյունավետ կլինի և իզուր կզբաղեցնի ալիքի մեծ մասը:

Փոխարենը խորհուրդ է տրվում օգտագործել երկուական ձևաչափը, որը շատ ավելի կոմպակտ է։ Այսինքն, փաթեթները կպարունակեն ընդամենը մի քանի բայթ: Այստեղ պետք է հաշվի առնել խնդիրը բայթերի կարգը, որը կարող է տարբերվել տարբեր համակարգիչների վրա:

Տվյալների սերիականացման համար կարող եք օգտագործել գրադարան, օրինակ՝

• FlatBuffers Google
• Cap'n Proto Ավազային փոթորիկ
• շիլա Շեյն Գրանտ և Ռանդոլֆ Վուրհիս

Պարզապես համոզվեք, որ գրադարանը ստեղծում է շարժական արխիվներ և հոգ է տանում էնդիանության մասին:

Այլընտրանքային լուծում կլինի այն ինքներդ իրականացնելը, դա այնքան էլ դժվար չէ, հատկապես, եթե դուք օգտագործում եք տվյալների կենտրոնացված մոտեցում ձեր կոդում: Բացի այդ, այն թույլ կտա կատարել օպտիմալացումներ, որոնք միշտ չէ, որ հնարավոր են գրադարանից օգտվելիս:

Գլեն Ֆիդլերը երկու հոդված է գրել սերիալիզացիայի վերաբերյալ. Ընթերցանության և գրելու փաթեթներ и Սերիալացման ռազմավարություններ.

Սեղմում

Հաճախորդների և սերվերի միջև փոխանցվող տվյալների քանակը սահմանափակվում է ալիքի թողունակությամբ: Տվյալների սեղմումը թույլ կտա ձեզ փոխանցել ավելի շատ տվյալներ յուրաքանչյուր լուսանկարում, բարձրացնել թարմացման արագությունը կամ պարզապես նվազեցնել թողունակության պահանջները:

Bit փաթեթավորում

Առաջին տեխնիկան բիտ փաթեթավորումն է: Այն բաղկացած է հենց այն բիթերի քանակից, որոնք անհրաժեշտ են ցանկալի արժեքը նկարագրելու համար: Օրինակ, եթե դուք ունեք enum, որը կարող է ունենալ 16 տարբեր արժեք, ապա ամբողջ բայթի փոխարեն (8 բիթ), կարող եք օգտագործել ընդամենը 4 բիթ:

Գլեն Ֆիդլերը բացատրում է, թե ինչպես դա իրականացնել հոդվածի երկրորդ մասում: Ընթերցանության և գրելու փաթեթներ.

Բիթերի փաթեթավորումը հատկապես լավ է աշխատում դիսկրետացման դեպքում, որը կլինի հաջորդ բաժնի թեման:

Նմուշառում

Նմուշառում Կորուստային սեղմման տեխնիկա է, որն օգտագործում է հնարավոր արժեքների միայն ենթաբազմություն՝ արժեքը կոդավորելու համար: Դիսկրետացում իրականացնելու ամենահեշտ ձևը լողացող կետով թվերի կլորացումն է:

Գլեն Ֆիդլերը (կրկին) իր հոդվածում ցույց է տալիս, թե ինչպես կարելի է գործնականում կիրառել դիսկրետիզացիա Snapshot սեղմում.

Սեղմման ալգորիթմներ

Հաջորդ տեխնիկան կլինի անկորուստ սեղմման ալգորիթմները:

Ահա, իմ կարծիքով, երեք ամենահետաքրքիր ալգորիթմները, որոնք դուք պետք է իմանաք.

• Հաֆմանի կոդավորում նախապես հաշվարկված կոդով, որը չափազանց արագ է և կարող է լավ արդյունքներ տալ: Այն օգտագործվում էր Quake3 ցանցային շարժիչում փաթեթները սեղմելու համար:
• ZLIB ընդհանուր նշանակության սեղմման ալգորիթմ է, որը երբեք չի ավելացնում տվյալների քանակը: Ինչպես կարող եք տեսնել այստեղ, այն օգտագործվել է մի շարք ծրագրերում: Նահանգների թարմացման համար դա կարող է ավելորդ լինել: Բայց դա կարող է օգտակար լինել, եթե Ձեզ անհրաժեշտ է սերվերից հաճախորդներին ուղարկել ակտիվներ, երկար տեքստեր կամ տեղանք:
• Պատճենման վազքի երկարությունները Հավանաբար սեղմման ամենապարզ ալգորիթմն է, բայց այն շատ արդյունավետ է տվյալների որոշակի տեսակների համար և կարող է օգտագործվել որպես նախամշակման քայլ նախքան zlib-ը: Այն հատկապես հարմար է սալիկներից կամ վոքսելներից բաղկացած տեղանքը սեղմելու համար, որոնցում կրկնվում են բազմաթիվ հարևան տարրեր:

դելտայի սեղմում

Վերջնական սեղմման տեխնիկան դելտա սեղմումն է: Դա կայանում է նրանում, որ փոխանցվում են միայն խաղի ընթացիկ վիճակի և հաճախորդի կողմից ստացված վերջին վիճակի միջև եղած տարբերությունները:

Այն առաջին անգամ օգտագործվել է Quake3 ցանցային շարժիչում: Ահա երկու հոդված, որոնք բացատրում են, թե ինչպես օգտագործել այն.

• Quake3 ցանցային մոդելը Բրայան Հուկ
• Quake 3 Source Code Review. Network Model Ֆաբիեն Սանգլարս [թարգմանություն Հաբրեի հոդվածները, տես «Ցանցային մոդել» բաժինը]

Գլեն Ֆիդլերն այն օգտագործել է նաև իր հոդվածի երկրորդ մասում։ Snapshot սեղմում.

Կոդավորումը

Բացի այդ, ձեզ կարող է անհրաժեշտ լինել գաղտնագրել հաճախորդների և սերվերի միջև տեղեկատվության փոխանցումը: Դրա մի քանի պատճառ կա.

• Գաղտնիություն/Գաղտնիություն. Հաղորդագրությունները կարող են կարդալ միայն ստացողը, և ցանցի ոչ մի այլ աչքառող չի կարողանա կարդալ դրանք:
• Նույնականացում. անձը, ով ցանկանում է խաղալ խաղացողի դերը, պետք է իմանա իր բանալին:
• խաբեության կանխարգելում. վնասակար խաղացողների համար շատ ավելի դժվար կլինի ստեղծել իրենց խաբեության փաթեթները, նրանք ստիպված կլինեն կրկնօրինակել գաղտնագրման սխեման և գտնել բանալին (որը փոխվում է յուրաքանչյուր կապի վրա):

Ես խստորեն խորհուրդ եմ տալիս դրա համար օգտագործել գրադարան: Առաջարկում եմ օգտագործել լիբսոդիում, քանի որ այն հատկապես պարզ է և ունի հիանալի ձեռնարկներ: Առանձնահատուկ հետաքրքրություն է ներկայացնում ձեռնարկը բանալիների փոխանակում, որը թույլ է տալիս ստեղծել նոր բանալիներ յուրաքանչյուր նոր կապի վրա:

Դիմումի արձանագրություն. Եզրակացություն

Սա եզրափակում է դիմումի արձանագրությունը: Կարծում եմ, որ սեղմումը լիովին ընտրովի է, և այն օգտագործելու որոշումը կախված է միայն խաղից և պահանջվող թողունակությունից: Կոդավորումը, իմ կարծիքով, պարտադիր է, բայց առաջին նախատիպում կարելի է առանց դրա։

Կիրառական տրամաբանություն

Այժմ մենք կարող ենք թարմացնել հաճախորդի վիճակը, սակայն կարող ենք բախվել հետաձգման հետ կապված խնդիրների հետ: Խաղացողը, մուտքագրում կատարելուց հետո, պետք է սպասի սերվերից խաղի վիճակի թարմացմանը՝ տեսնելու, թե դա ինչ ազդեցություն է թողել աշխարհի վրա:

Ավելին, երկու պետական ​​թարմացումների միջև աշխարհը լիովին ստատիկ է: Եթե ​​նահանգի թարմացման արագությունը ցածր է, ապա շարժումները շատ կտրուկ կլինեն:

Այս խնդրի ազդեցությունը մեղմելու մի քանի տեխնիկա կան, և ես դրանք կանդրադառնամ հաջորդ բաժնում:

Հետաձգման հարթեցման տեխնիկա

Այս բաժնում նկարագրված բոլոր տեխնիկաները մանրամասն քննարկվում են շարքում: Արագ տեմպերով Multiplayer Գաբրիել Գամբետա. Ես բարձր խորհուրդ եմ տալիս կարդալ այս հիանալի հոդվածների շարքը: Այն նաև ներառում է ինտերակտիվ ցուցադրություն՝ տեսնելու, թե ինչպես են այս տեխնիկան աշխատում գործնականում:

Առաջին տեխնիկան մուտքագրման արդյունքն ուղղակիորեն կիրառելն է՝ չսպասելով սերվերի պատասխանին: Այն կոչվում է հաճախորդի կողմից կանխատեսում. Այնուամենայնիվ, երբ հաճախորդը սերվերից թարմացում է ստանում, նա պետք է ստուգի, որ դրա կանխատեսումը ճիշտ էր: Եթե ​​դա այդպես չէ, ապա նա պարզապես պետք է փոխի իր վիճակը սերվերից ստացածի համաձայն, քանի որ սերվերը ավտորիտար է։ Այս տեխնիկան առաջին անգամ օգտագործվել է Quake-ում: Այդ մասին ավելին կարող եք կարդալ հոդվածում: Quake Engine կոդի վերանայում Ֆաբիեն Սանգլարս [թարգմանություն Habré-ի վրա]:

Տեխնիկաների երկրորդ խումբն օգտագործվում է երկու պետական ​​թարմացումների միջև այլ սուբյեկտների տեղաշարժը հարթելու համար: Այս խնդիրը լուծելու երկու եղանակ կա՝ ինտերպոլացիա և էքստրապոլացիա: Ինտերպոլացիայի դեպքում վերցվում են վերջին երկու վիճակները և ցուցադրվում է անցումը մեկից մյուսին։ Դրա թերությունն այն է, որ այն առաջացնում է ուշացման մի փոքր մասը, քանի որ հաճախորդը միշտ տեսնում է, թե ինչ է տեղի ունեցել անցյալում: Էքստրապոլացիան նշանակում է կանխատեսել, թե որտեղ պետք է գտնվեն կազմակերպությունները՝ հիմնվելով հաճախորդի կողմից ստացված վերջին վիճակի վրա: Դրա թերությունն այն է, որ եթե կազմակերպությունն ամբողջությամբ փոխի շարժման ուղղությունը, ապա կանխատեսման և իրական դիրքի միջև մեծ սխալ կլինի:

Վերջին, ամենաառաջադեմ տեխնիկան, որն օգտակար է միայն FPS-ում հետաձգման փոխհատուցում. Լագի փոխհատուցում օգտագործելիս սերվերը հաշվի է առնում հաճախորդի ուշացումները, երբ նա կրակում է թիրախի վրա: Օրինակ, եթե խաղացողը գլխով հարված կատարեց իր էկրանին, բայց իրականում նրա թիրախը ուշացման պատճառով այլ վայրում էր, ապա անարդար կլինի խաղացողին մերժել ուշացման պատճառով սպանելու իրավունքը: Այսպիսով, սերվերը վերադարձնում է ժամանակը դեպի այն պահը, երբ խաղացողը կրակել է, որպեսզի մոդելավորի այն, ինչ խաղացողը տեսել է իր էկրանին և ստուգել, ​​թե արդյոք բախվել է իր կրակոցի և թիրախի միջև:

Գլեն Ֆիդլերը (ինչպես միշտ) հոդված է գրել 2004թ Ցանցային ֆիզիկա (2004), որում նա հիմք դրեց սերվերի և հաճախորդի միջև ֆիզիկայի սիմուլյացիաների համաժամացմանը։ 2014 թվականին նա գրել է նոր հոդվածաշար ցանցային ֆիզիկա, որտեղ նա նկարագրել է ֆիզիկայի սիմուլյացիաների համաժամացման այլ տեխնիկա։

Valve-ի վիքիում կա նաև երկու հոդված. Աղբյուր Multiplayer Networking и Հապաղման փոխհատուցման մեթոդներ հաճախորդի/սերվերի ներխաղային արձանագրության նախագծման և օպտիմիզացման մեջ հետաձգման փոխհատուցման հետ կապված.

Խաբեության կանխարգելում

Գոյություն ունեն խաբեության կանխարգելման երկու հիմնական տեխնիկա.

Նախ՝ դժվարացնելով խաբեբաների համար վնասակար փաթեթներ ուղարկելը: Ինչպես նշվեց վերևում, դրա իրականացման լավ միջոցը գաղտնագրումն է:

Երկրորդ, հեղինակավոր սերվերը պետք է ստանա միայն հրամաններ/ներածում/գործողություններ: Հաճախորդը չպետք է կարողանա փոխել վիճակը սերվերի վրա, բացառությամբ մուտքագրման միջոցով: Այնուհետև սերվերը, ամեն անգամ, երբ մուտք է ստանում, պետք է ստուգի դրա վավերականությունը՝ նախքան այն կիրառելը:

Կիրառման տրամաբանություն. Եզրակացություն

Ես խորհուրդ եմ տալիս կիրառել բարձր հետաձգման և թարմացման ցածր արագության մոդելավորման միջոց, որպեսզի կարողանաք ստուգել ձեր խաղի վարքը վատ պայմաններում, նույնիսկ երբ հաճախորդը և սերվերը աշխատում են նույն մեքենայի վրա: Սա մեծապես հեշտացնում է հետաձգման հարթեցման տեխնիկայի իրականացումը:

Այլ օգտակար ռեսուրսներ

Եթե ​​ցանկանում եք ուսումնասիրել ցանցի մոդելի այլ ռեսուրսներ, կարող եք գտնել դրանք այստեղ՝

• Գլեն Ֆիդլերի բլոգը — արժե կարդալ նրա ամբողջ բլոգը, նրանում շատ հիանալի հոդվածներ կան։ Այստեղ հավաքված են ցանցային տեխնոլոգիաների վերաբերյալ բոլոր հոդվածները:
• Զարմանալի խաղ ցանցեր M. Fatih MAR-ը տեսախաղերի ցանցային շարժիչների վերաբերյալ հոդվածների և տեսանյութերի համապարփակ ցանկ է:
• В wiki subreddit r/gamedev Կան նաև շատ օգտակար հղումներ։

Source: www.habr.com