ბოლო ორი კვირაა ვმუშაობ ონლაინ ძრავზე ჩემი თამაშისთვის. მანამდე, მე საერთოდ არაფერი ვიცოდი თამაშებში ქსელის შესახებ, ამიტომ წავიკითხე ბევრი სტატია და ჩავატარე ბევრი ექსპერიმენტი, რომ გამეგო ყველა კონცეფცია და შემეძლო დამეწერა ჩემი ქსელის ძრავა.

ამ სახელმძღვანელოში მსურს გაგიზიაროთ სხვადასხვა ცნებები, რომლებიც უნდა ისწავლოთ საკუთარი თამაშის ძრავის დაწერამდე, ასევე საუკეთესო რესურსები და სტატიები მათ შესასწავლად.

ზოგადად, არსებობს ორი ძირითადი ტიპის ქსელის არქიტექტურა: 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.

საკუთარი პროტოკოლი

ასე რომ, გსურთ შექმნათ თქვენი საკუთარი სატრანსპორტო პროტოკოლი, მაგრამ არ იცით საიდან დაიწყოთ? თქვენ იღბლიანი ხართ, რადგან გლენ ფიდლერმა დაწერა ორი საოცარი სტატია ამის შესახებ. მათში უამრავ ჭკვიან აზრს ნახავთ.

პირველი სტატია ქსელი თამაშის პროგრამისტებისთვის 2008 წელი, მეორეზე უფრო ადვილი, თამაშის ქსელის პროტოკოლის შექმნა 2016 წელი. გირჩევთ დაიწყოთ უფრო ძველით.

გაითვალისწინეთ, რომ გლენ ფიდლერი არის UDP-ზე დაფუძნებული საბაჟო პროტოკოლის გამოყენების დიდი მომხრე. და მისი სტატიების წაკითხვის შემდეგ, თქვენ ალბათ დაეთანხმებით მის აზრს, რომ TCP-ს აქვს სერიოზული ხარვეზები ვიდეო თამაშებში და მოგინდებათ საკუთარი პროტოკოლის დანერგვა.

მაგრამ თუ თქვენ ახალი ხართ ქსელში, გააკეთეთ სიკეთე საკუთარ თავს და გამოიყენეთ TCP ან ბიბლიოთეკა. საკუთარი სატრანსპორტო პროტოკოლის წარმატებით განსახორციელებლად, წინასწარ ბევრი რამ უნდა ისწავლოთ.

ქსელის ბიბლიოთეკები

თუ გჭირდებათ რაიმე უფრო ეფექტური ვიდრე TCP, მაგრამ არ გსურთ თქვენი პროტოკოლის დანერგვისა და ბევრი დეტალის შესწავლა, შეგიძლიათ გამოიყენოთ ქსელის ბიბლიოთეკა. ბევრი მათგანია:

• იოჯიმბო გლენ ფიდლერი
• რაქნეტი, რომელიც აღარ არის მხარდაჭერილი, მაგრამ მისი ჩანგალი SLikeNet როგორც ჩანს ისევ აქტიურია.
• ENet არის მრავალმოთამაშიანი FPS-ისთვის შექმნილი ბიბლიოთეკა Cube
• GameNetworkingSockets სარქველი

მე არ გამომიცდია ყველა, მაგრამ მირჩევნია ENet, რადგან ის მარტივი და საიმედოა. გარდა ამისა, მას აქვს მკაფიო დოკუმენტაცია და გაკვეთილი დამწყებთათვის.

ტრანსპორტის პროტოკოლი: დასკვნა

შეჯამება: არსებობს ორი ძირითადი სატრანსპორტო პროტოკოლი: TCP და UDP. TCP-ს აქვს მრავალი სასარგებლო ფუნქცია: საიმედოობა, პაკეტის შეკვეთის შენარჩუნება, შეცდომების გამოვლენა. UDP-ს არ აქვს ეს ყველაფერი, მაგრამ TCP-ს თავისი ბუნებით აქვს გაზრდილი შეყოვნება, რაც მიუღებელია ზოგიერთი თამაშისთვის. ანუ დაბალი შეყოვნების უზრუნველსაყოფად, შეგიძლიათ შექმნათ თქვენი საკუთარი პროტოკოლი UDP-ზე დაფუძნებული ან გამოიყენოთ ბიბლიოთეკა, რომელიც ახორციელებს სატრანსპორტო პროტოკოლს UDP-ზე და ადაპტირებულია მრავალმოთამაშიანი ვიდეო თამაშებისთვის.

არჩევანი TCP, UDP და ბიბლიოთეკას შორის დამოკიდებულია რამდენიმე ფაქტორზე. პირველი, თამაშის საჭიროებიდან გამომდინარე: სჭირდება თუ არა მას დაბალი შეყოვნება? მეორეც, განაცხადის პროტოკოლის მოთხოვნებიდან: სჭირდება მას სანდო პროტოკოლი? როგორც შემდეგ ნაწილში ვნახავთ, შესაძლებელია აპლიკაციის პროტოკოლის შექმნა, რომლისთვისაც არასანდო პროტოკოლი საკმაოდ შესაფერისია. და ბოლოს, თქვენ ასევე უნდა გაითვალისწინოთ ქსელის ძრავის შემქმნელის გამოცდილება.

ორი რჩევა მაქვს:

• შეძლებისდაგვარად ამოიღეთ სატრანსპორტო პროტოკოლი დანარჩენი აპლიკაციიდან, რათა ის ადვილად შეიცვალოს ყველა კოდის გადაწერის გარეშე.
• ნუ ზედმეტ ოპტიმიზაციას. თუ არ ხართ ქსელის ექსპერტი და არ ხართ დარწმუნებული, გჭირდებათ თუ არა მორგებული UDP-ზე დაფუძნებული სატრანსპორტო პროტოკოლი, შეგიძლიათ დაიწყოთ TCP-ით ან ბიბლიოთეკით, რომელიც უზრუნველყოფს საიმედოობას და შემდეგ შეამოწმოთ და გაზომოთ შესრულება. თუ პრობლემები წარმოიქმნება და დარწმუნებული ხართ, რომ მიზეზი სატრანსპორტო პროტოკოლია, მაშინ შეიძლება დროა შექმნათ თქვენი საკუთარი სატრანსპორტო პროტოკოლი.

ამ ნაწილის დასასრულს გირჩევთ წაიკითხოთ შესავალი Multiplayer თამაშის პროგრამირებაში ბრაიან ჰუკის მიერ, რომელიც მოიცავს აქ განხილულ ბევრ თემას.

განაცხადის პროტოკოლი

ახლა, როდესაც ჩვენ შეგვიძლია გავცვალოთ მონაცემები კლიენტებსა და სერვერებს შორის, უნდა გადავწყვიტოთ რა მონაცემები გადავიტანოთ და რა ფორმატში.

კლასიკური სქემა არის ის, რომ კლიენტები აგზავნიან შეყვანას ან მოქმედებებს სერვერზე, ხოლო სერვერი უგზავნის თამაშის მიმდინარე მდგომარეობას კლიენტებს.

სერვერი აგზავნის არა სრულ მდგომარეობას, არამედ გაფილტრულ მდგომარეობას ერთეულებით, რომლებიც მდებარეობს მოთამაშის მახლობლად. ის ამას სამი მიზეზის გამო აკეთებს. პირველი, სრული მდგომარეობა შეიძლება იყოს ძალიან დიდი, რომ გადაიცეს მაღალი სიხშირით. მეორეც, კლიენტებს ძირითადად აინტერესებთ ვიზუალური და აუდიო მონაცემები, რადგან თამაშის ლოგიკის უმეტესი ნაწილი სიმულირებულია თამაშის სერვერზე. მესამე, ზოგიერთ თამაშში მოთამაშეს არ სჭირდება გარკვეული მონაცემების ცოდნა, მაგალითად, მტრის პოზიცია რუკის მეორე მხარეს, წინააღმდეგ შემთხვევაში მას შეუძლია პაკეტების ამოსუნთქვა და ზუსტად იცოდეს სად გადავიდეს მის მოსაკლავად.

სერიალიზაცია

პირველი ნაბიჯი არის მონაცემების გადაყვანა, რომლის გაგზავნაც გვინდა (შეყვანის ან თამაშის მდგომარეობა) გადაცემისთვის შესაფერის ფორმატში. ამ პროცესს ე.წ სერიალიზაცია.

აზრი, რომელიც მაშინვე ჩნდება, არის ადამიანის მიერ წაკითხული ფორმატის გამოყენება, როგორიცაა JSON ან XML. მაგრამ ეს სრულიად არაეფექტური იქნება და არხის უმეტეს ნაწილს დაკარგავს.

ამის ნაცვლად რეკომენდებულია ორობითი ფორმატის გამოყენება, რომელიც ბევრად უფრო კომპაქტურია. ანუ, პაკეტები შეიცავს მხოლოდ რამდენიმე ბაიტს. აქ გასათვალისწინებელია პრობლემა ბაიტის შეკვეთა, რომელიც შეიძლება განსხვავდებოდეს სხვადასხვა კომპიუტერზე.

მონაცემთა სერიალიზაციისთვის შეგიძლიათ გამოიყენოთ ბიბლიოთეკა, მაგალითად:

• FlatBuffers Google
• კაპ'ნ პროტო Sandstorm კომპანია
• ხორბლის შეინ გრანტი და რენდოლფ ვურჰესი

უბრალოდ დარწმუნდით, რომ ბიბლიოთეკა ქმნის პორტატულ არქივებს და ზრუნავს ენდიანობაზე.

ალტერნატიული გამოსავალია მისი დამოუკიდებლად განხორციელება; ეს არ არის განსაკუთრებით რთული, განსაკუთრებით თუ იყენებთ მონაცემთა ორიენტირებულ მიდგომას თქვენი კოდის მიმართ. გარდა ამისა, ის საშუალებას მოგცემთ განახორციელოთ ოპტიმიზაცია, რომელიც ყოველთვის არ არის შესაძლებელი ბიბლიოთეკის გამოყენებისას.

გლენ ფიდლერმა დაწერა ორი სტატია სერიალიზაციის შესახებ: კითხვისა და წერის პაკეტები и სერიალიზაციის სტრატეგიები.

შეკუმშვა

კლიენტებსა და სერვერს შორის გადაცემული მონაცემების რაოდენობა შეზღუდულია არხის გამტარუნარიანობით. მონაცემთა შეკუმშვა საშუალებას მოგცემთ გადაიტანოთ მეტი მონაცემი თითოეულ სურათზე, გაზარდოთ განახლების სიხშირე ან უბრალოდ შეამციროთ არხის მოთხოვნები.

ბიტიანი შეფუთვა

პირველი ტექნიკა არის ცოტა შეფუთვა. იგი შედგება ზუსტად იმ ბიტების რაოდენობის გამოყენებით, რაც აუცილებელია სასურველი მნიშვნელობის აღსაწერად. მაგალითად, თუ თქვენ გაქვთ enum, რომელსაც შეიძლება ჰქონდეს 16 განსხვავებული მნიშვნელობა, მაშინ მთელი ბაიტის ნაცვლად (8 ბიტი), შეგიძლიათ გამოიყენოთ მხოლოდ 4 ბიტი.

გლენ ფიდლერი განმარტავს, თუ როგორ უნდა განხორციელდეს ეს სტატიის მეორე ნაწილში კითხვისა და წერის პაკეტები.

ბიტის შეფუთვა განსაკუთრებით კარგად მუშაობს შერჩევისას, რაც მომდევნო განყოფილების თემა იქნება.

სინჯის აღება

სინჯის აღება არის დაკარგვის შეკუმშვის ტექნიკა, რომელიც იყენებს შესაძლო მნიშვნელობების მხოლოდ ქვეჯგუფს მნიშვნელობის დაშიფვრისთვის. დისკრეტიზაციის განხორციელების უმარტივესი გზაა მცურავი წერტილის რიცხვების დამრგვალება.

გლენ ფიდლერი (კიდევ ერთხელ!) თავის სტატიაში გვიჩვენებს, თუ როგორ უნდა გამოიყენოს ნიმუშის აღება პრაქტიკაში Snapshot შეკუმშვა.

შეკუმშვის ალგორითმები

შემდეგი ტექნიკა იქნება უდანაკარგო შეკუმშვის ალგორითმები.

აქ, ჩემი აზრით, არის სამი ყველაზე საინტერესო ალგორითმი, რომელიც უნდა იცოდეთ:

• ჰაფმანის კოდირება წინასწარ გამოთვლილი კოდით, რომელიც ძალიან სწრაფია და შეუძლია კარგი შედეგის მიღება. იგი გამოიყენებოდა Quake3 ქსელის ძრავში პაკეტების შეკუმშვისთვის.
• zlib არის ზოგადი დანიშნულების შეკუმშვის ალგორითმი, რომელიც არასოდეს ზრდის მონაცემთა რაოდენობას. როგორ ხედავ აქ, ის გამოიყენებოდა სხვადასხვა აპლიკაციებში. ეს შეიძლება ზედმეტი იყოს შტატების განახლებისთვის. მაგრამ ეს შეიძლება იყოს სასარგებლო, თუ თქვენ გჭირდებათ სერვერიდან კლიენტებისთვის აქტივების, გრძელი ტექსტების ან რელიეფის გაგზავნა.
• სიგრძის კოპირება - ეს არის ალბათ უმარტივესი შეკუმშვის ალგორითმი, მაგრამ ის ძალიან ეფექტურია გარკვეული ტიპის მონაცემებისთვის და შეიძლება გამოყენებულ იქნას როგორც წინასწარი დამუშავების ნაბიჯი zlib-მდე. იგი განსაკუთრებით შესაფერისია ფილების ან ვოქსელებისგან შემდგარი რელიეფის შეკუმშვისთვის, რომელშიც მრავალი მიმდებარე ელემენტი მეორდება.

დელტა შეკუმშვა

შეკუმშვის ბოლო ტექნიკა არის დელტა შეკუმშვა. ის მდგომარეობს იმაში, რომ გადაიცემა მხოლოდ განსხვავებები თამაშის მიმდინარე მდგომარეობასა და კლიენტის მიერ მიღებულ ბოლო მდგომარეობას შორის.

ის პირველად გამოიყენეს Quake3 ქსელის ძრავში. აქ არის ორი სტატია, სადაც განმარტავენ, თუ როგორ გამოიყენოთ იგი:

• Quake3 ქსელის მოდელი ბრაიან ჰუკი
• Quake 3 Source Code მიმოხილვა: ქსელის მოდელი ფაბიენ სანგლარსი [თარგმანი სტატიები Habré-ზე, იხილეთ სექცია „ქსელის მოდელი“]

გლენ ფიდლერმაც გამოიყენა იგი თავისი სტატიის მეორე ნაწილში Snapshot შეკუმშვა.

დაშიფვრა

გარდა ამისა, შეიძლება დაგჭირდეთ კლიენტებსა და სერვერს შორის ინფორმაციის გადაცემის დაშიფვრა. ამის რამდენიმე მიზეზი არსებობს:

• კონფიდენციალურობა/კონფიდენციალურობა: შეტყობინებების წაკითხვა შეუძლია მხოლოდ მიმღებს და ვერც ერთი სხვა პირი, რომელიც სუნავს ქსელს, ვერ წაიკითხავს მათ.
• ავთენტიფიკაცია: ადამიანმა, რომელსაც სურს მოთამაშის როლის შესრულება, უნდა იცოდეს მისი გასაღები.
• თაღლითობის პრევენცია: მავნე მოთამაშეებისთვის გაცილებით რთული იქნება საკუთარი მოტყუების პაკეტების შექმნა, მათ მოუწევთ დაშიფვრის სქემის რეპროდუცირება და გასაღების პოვნა (რომელიც იცვლება ყოველი კავშირის დროს).

მე მკაცრად გირჩევთ გამოიყენოთ ბიბლიოთეკა ამისათვის. მე გირჩევთ გამოიყენოთ ლიბოდიუმი, რადგან ის განსაკუთრებით მარტივია და აქვს შესანიშნავი გაკვეთილები. განსაკუთრებით საინტერესოა გაკვეთილი გასაღების გაცვლა, რომელიც საშუალებას გაძლევთ შექმნათ ახალი გასაღებები ყოველი ახალი კავშირით.

განაცხადის პროტოკოლი: დასკვნა

ამით სრულდება ჩვენი განაცხადის პროტოკოლი. მე მჯერა, რომ შეკუმშვა სრულიად არჩევითია და მისი გამოყენების გადაწყვეტილება დამოკიდებულია მხოლოდ თამაშზე და საჭირო გამტარუნარიანობაზე. დაშიფვრა, ჩემი აზრით, სავალდებულოა, მაგრამ პირველ პროტოტიპში ამის გარეშე შეგიძლიათ.

განაცხადის ლოგიკა

ჩვენ ახლა შეგვიძლია განვაახლოთ მდგომარეობა კლიენტში, მაგრამ შესაძლოა შეფერხების პრობლემა შეგვხვდეს. მოთამაშეს, შეყვანის დასრულების შემდეგ, უნდა დაელოდოს თამაშის მდგომარეობის განახლებას სერვერიდან, რათა დაინახოს რა გავლენა იქონია მას მსოფლიოში.

უფრო მეტიც, ორ სახელმწიფო განახლებას შორის, სამყარო სრულიად სტატიკურია. თუ სახელმწიფო განახლების სიჩქარე დაბალია, მაშინ მოძრაობები იქნება ძალიან მკვეთრი.

ამ პრობლემის ზემოქმედების შესამცირებლად რამდენიმე ტექნიკა არსებობს და მათ შემდეგ ნაწილში განვიხილავ.

შეყოვნების დაგლუვების ტექნიკა

ამ ნაწილში აღწერილი ყველა ტექნიკა დეტალურად არის განხილული სერიაში სწრაფი ტემპით მულტიმოთამაშე გაბრიელ გამბეტა. მე გირჩევთ წაიკითხოთ ამ შესანიშნავი სტატიების სერია. ის ასევე მოიცავს ინტერაქტიულ დემო ვერსიას, რომელიც საშუალებას გაძლევთ ნახოთ, როგორ მუშაობს ეს ტექნიკა პრაქტიკაში.

პირველი ტექნიკა არის შეყვანის შედეგის პირდაპირ გამოყენება სერვერისგან პასუხის მოლოდინის გარეშე. მას ეძახიან კლიენტის მხრიდან პროგნოზირება. თუმცა, როდესაც კლიენტი მიიღებს განახლებას სერვერისგან, მან უნდა დაადასტუროს, რომ მისი პროგნოზი იყო სწორი. თუ ეს ასე არ არის, მაშინ მან უბრალოდ უნდა შეცვალოს თავისი მდგომარეობა იმის მიხედვით, რაც მიიღო სერვერისგან, რადგან სერვერი ავტორიტარულია. ეს ტექნიკა პირველად გამოიყენეს Quake-ში. ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ სტატიაში Quake Engine კოდის მიმოხილვა ფაბიენ სანგლარსი [თარგმანი ჰაბრეზე].

ტექნიკის მეორე ნაკრები გამოიყენება სხვა ერთეულების გადაადგილების გასამარტივებლად ორ სახელმწიფო განახლებას შორის. ამ პრობლემის გადაჭრის ორი გზა არსებობს: ინტერპოლაცია და ექსტრაპოლაცია. ინტერპოლაციის შემთხვევაში აღებულია ბოლო ორი მდგომარეობა და ნაჩვენებია ერთიდან მეორეზე გადასვლა. მისი მინუსი არის ის, რომ იწვევს მცირე შეფერხებას, რადგან კლიენტი ყოველთვის ხედავს იმას, რაც მოხდა წარსულში. ექსტრაპოლაცია არის იმის პროგნოზირება, თუ სად უნდა იყოს ახლა ერთეულები კლიენტის მიერ მიღებული ბოლო მდგომარეობის მიხედვით. მისი მინუსი ის არის, რომ თუ სუბიექტი მთლიანად ცვლის მოძრაობის მიმართულებას, მაშინ იქნება დიდი შეცდომა პროგნოზსა და რეალურ პოზიციას შორის.

უახლესი, ყველაზე მოწინავე ტექნიკა, რომელიც მხოლოდ FPS-შია გამოსაყენებელი ჩამორჩენის კომპენსაცია. დაგვიანების კომპენსაციის გამოყენებისას სერვერი ითვალისწინებს კლიენტის შეფერხებებს, როდესაც ის ისვრის სამიზნეს. მაგალითად, თუ მოთამაშემ შეასრულა თავდასხმა თავის ეკრანზე, მაგრამ რეალურად მათი სამიზნე სხვა ადგილას იყო დაყოვნების გამო, მაშინ უსამართლო იქნება მოთამაშეს უარი თქვან მკვლელობის უფლებაზე დაგვიანების გამო. ამრიგად, სერვერი აბრუნებს დროს უკან იმ მომენტამდე, როდესაც მოთამაშემ გაისროლა, რათა მოახდინოს მოთამაშის მიერ დანახული ეკრანის სიმულაცია და შეამოწმოს შეჯახება მათ დარტყმასა და მიზანს შორის.

გლენ ფიდლერმა (როგორც ყოველთვის!) დაწერა სტატია 2004 წელს ქსელის ფიზიკა (2004), რომელშიც მან საფუძველი ჩაუყარა სერვერსა და კლიენტს შორის ფიზიკის სიმულაციების სინქრონიზაციას. 2014 წელს მან დაწერა სტატიების ახალი სერია ქსელური ფიზიკა, რომელშიც აღწერილი იყო ფიზიკის სიმულაციების სინქრონიზაციის სხვა ტექნიკა.

ასევე არის ორი სტატია Valve ვიკიზე, წყარო Multiplayer Networking и შეყოვნების კომპენსაციის მეთოდები კლიენტის/სერვერის თამაშში პროტოკოლის დიზაინსა და ოპტიმიზაციაში რომლებიც ითვალისწინებენ კომპენსაციას დაგვიანებისთვის.

თაღლითობის პრევენცია

თაღლითობის თავიდან აცილების ორი ძირითადი მეთოდი არსებობს.

პირველი: ართულებს თაღლითებს მავნე პაკეტების გაგზავნას. როგორც ზემოთ აღინიშნა, ამის განხორციელების კარგი გზაა დაშიფვრა.

მეორე: ავტორიტარულმა სერვერმა უნდა მიიღოს მხოლოდ ბრძანებები/შეყვანა/მოქმედებები. კლიენტს არ უნდა შეეძლოს სერვერზე მდგომარეობის შეცვლა შეყვანის გაგზავნის გარდა. შემდეგ, ყოველ ჯერზე, როდესაც სერვერი იღებს შეყვანას, მან უნდა შეამოწმოს თუ არა ის მართებულია მის გამოყენებამდე.

განაცხადის ლოგიკა: დასკვნა

გირჩევთ, დანერგოთ გზა მაღალი შეყოვნებისა და განახლების დაბალი სიხშირის სიმულაციისთვის, ასე რომ თქვენ შეგიძლიათ შეამოწმოთ თქვენი თამაშის ქცევა ცუდ პირობებში, მაშინაც კი, როდესაც კლიენტი და სერვერი მუშაობენ ერთ კომპიუტერზე. ეს მნიშვნელოვნად გაამარტივებს დაგვიანებით დაგლუვების ტექნიკის განხორციელებას.

სხვა სასარგებლო რესურსები

თუ გსურთ შეისწავლოთ სხვა რესურსები ქსელის მოდელებზე, შეგიძლიათ იპოვოთ ისინი აქ:

• გლენ ფიდლერის ბლოგი – მისი მთელი ბლოგის წაკითხვა ღირს, იქ უამრავი შესანიშნავი სტატიაა. აქ ქსელური ტექნოლოგიების შესახებ ყველა სტატია შეგროვებულია.
• გასაოცარი თამაშის ქსელი by M. Fatih MAR არის სტატიებისა და ვიდეოების ყოვლისმომცველი სია ონლაინ ვიდეო თამაშების ძრავებზე.
• В r/gamedev subreddit-ის ვიკი ასევე ბევრი სასარგებლო ბმულია.

წყარო: www.habr.com