როგორ გავაუმჯობესეთ ბალისტიკური გამოთვლების მექანიზმი მობილური მსროლელისთვის ქსელის შეყოვნების კომპენსაციის ალგორითმით

გამარჯობა, მე ვარ ნიკიტა ბრიჟაკი, სერვერის დეველოპერი Pixonic-ისგან. დღეს მსურს ვისაუბრო მობილურ მულტიპლეერში ჩამორჩენის კომპენსირებაზე.

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

ჩვენ ასევე ვიყენებთ მას ჩვენს მობილურ მრავალმოთამაშიან მსროლელ Dino Squad-ში.

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

ორიოდე სიტყვა ჩვენი ქერქისა და ტექნოლოგიების შესახებ.

Dino Squad არის ქსელური მობილური PvP მსროლელი. მოთამაშეები აკონტროლებენ დინოზავრებს, რომლებიც აღჭურვილია სხვადასხვა იარაღით და ებრძვიან ერთმანეთს 6v6 გუნდებში.

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

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

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

ლოკალურ ქსელებში ეს შეფერხება (პოპულარულად უწოდებენ შეყვანის ჩამორჩენას) შეიძლება შეუმჩნეველი იყოს, ინტერნეტით თამაშისას ის ქმნის "ყინულზე სრიალის" განცდას პერსონაჟის მართვისას. ეს პრობლემა ორმაგად აქტუალურია მობილური ქსელებისთვის, სადაც ის შემთხვევა, როდესაც მოთამაშის პინგი 200 ms-ია, მაინც შესანიშნავ კავშირად ითვლება. ხშირად პინგი შეიძლება იყოს 350, 500 ან 1000 ms. მაშინ თითქმის შეუძლებელი ხდება სწრაფი მსროლელის თამაში შეყვანის ჩამორჩენით.

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

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

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

ამ ცოდნით შეიარაღებული, ჩვენ დავიწყეთ სერვერის ჩამორჩენის კომპენსაციის დანერგვა Dino Squad-ში. უპირველეს ყოვლისა, უნდა გვესმოდეს, როგორ აღვადგინოთ სერვერზე ის, რაც ნახა კლიენტმა? და კონკრეტულად რისი აღდგენაა საჭირო? ჩვენს თამაშში იარაღიდან და უნარებიდან დარტყმები გამოითვლება სხივების და გადაფარვის საშუალებით - ანუ მტრის ფიზიკურ კოლაიდერებთან ურთიერთქმედების გზით. შესაბამისად, დაგვჭირდა ამ კოლაიდერების პოზიციის რეპროდუცირება, რომელიც მოთამაშემ ლოკალურად „ნახა“ სერვერზე. იმ დროს ჩვენ ვიყენებდით Unity ვერსია 2018.x. ფიზიკის API იქ სტატიკურია, ფიზიკური სამყარო არსებობს ერთ ეგზემპლარად. მისი მდგომარეობის შენახვა და შემდეგ მისი ყუთიდან აღდგენა არ არსებობს. ასე რომ, რა უნდა გააკეთოს?

გამოსავალი ზედაპირზე იყო; მისი ყველა ელემენტი უკვე გამოყენებული იყო სხვა პრობლემების გადასაჭრელად:

1. თითოეული კლიენტისთვის, ჩვენ უნდა ვიცოდეთ, რა დროს ხედავდა ოპონენტებს კლავიშების დაჭერისას. ჩვენ უკვე ჩავწერეთ ეს ინფორმაცია შეყვანის პაკეტში და გამოვიყენეთ კლიენტის პროგნოზის დასარეგულირებლად.
2. ჩვენ უნდა შეგვეძლოს თამაშის სახელმწიფოების ისტორიის შენახვა. სწორედ მასში დავიკავებთ ჩვენი ოპონენტების (და შესაბამისად მათი კოლაიდერების) პოზიციებს. ჩვენ უკვე გვქონდა სერვერზე სახელმწიფო ისტორია, ვიყენებდით მის შესაქმნელად დელტები. ვიცოდეთ შესაფერისი დრო, ჩვენ ადვილად ვიპოვით ისტორიაში სწორ მდგომარეობას.
3. ახლა, როდესაც ჩვენ გვაქვს თამაშის მდგომარეობა ისტორიიდან, ჩვენ უნდა შევძლოთ მოთამაშის მონაცემების სინქრონიზაცია ფიზიკური სამყაროს მდგომარეობასთან. არსებული კოლაიდერები - გადაადგილება, დაკარგული - შექმნა, არასაჭირო - განადგურება. ეს ლოგიკა ასევე უკვე დაწერილი იყო და შედგებოდა რამდენიმე ECS სისტემისგან. ჩვენ გამოვიყენეთ რამდენიმე სათამაშო ოთახის გასამართად ერთი Unity პროცესში. და რადგან ფიზიკური სამყარო ერთი პროცესია, ის ხელახლა უნდა იქნას გამოყენებული ოთახებს შორის. სიმულაციის ყოველი ნიშნის წინ, ჩვენ „გადავაყენებთ“ ფიზიკური სამყაროს მდგომარეობას და ხელახლა ვაყენებთ მას მიმდინარე ოთახის მონაცემებით, ვცდილობთ მაქსიმალურად გამოვიყენოთ Unity თამაშის ობიექტები ჭკვიანური გაერთიანების სისტემის მეშვეობით. დარჩა მხოლოდ იგივე ლოგიკის გამოძახება თამაშის მდგომარეობისთვის წარსულიდან.

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

public class TimeMachine : ITimeMachine
{
     //История игровых состояний
     private readonly IGameStateHistory _history;

     //Текущее игровое состояние на сервере
     private readonly ExecutableSystem[] _systems;

     //Набор систем, расставляющих коллайдеры в физическом мире 
     //по данным из игрового состояния
     private readonly GameState _presentState;

     public TimeMachine(IGameStateHistory history, GameState presentState, ExecutableSystem[] timeInitSystems)
     {
         _history = history; 
         _presentState = presentState;
         _systems = timeInitSystems;  
     }

     public GameState TravelToTime(int tick)
     {
         var pastState = tick == _presentState.Time ? _presentState : _history.Get(tick);
         foreach (var system in _systems)
         {
             system.Execute(pastState);
         }
         return pastState;
     }
}

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

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

მაგრამ ასეთი მექანიკა ძალიან ცოტაა Dino Squad-ში! თამაშში იარაღის უმეტესობა ქმნის ჭურვებს - ხანგრძლივ ტყვიებს, რომლებიც დაფრინავენ რამდენიმე სიმულაციური ტკიპისთვის (ზოგიერთ შემთხვევაში, ათობით ტკიპზე). რა ვუყოთ მათ, რომელ საათზე უნდა იფრინონ?

В უძველესი სტატია Half-Life ქსელის სტეკის შესახებ, იგივე კითხვა დაუსვეს ბიჭებმა Valve-დან და მათი პასუხი ასეთი იყო: ჭურვის ჩამორჩენის კომპენსაცია პრობლემურია და ჯობია თავიდან აიცილოთ იგი.

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

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

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

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

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

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

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

ცალკე, ღირს შესრულების საკითხის დაყენება. თუ გეგონათ, რომ ეს ყველაფერი შეანელებდა საქმეს, მე ვპასუხობ: ასეა. ერთიანობა საკმაოდ ნელია კოლაიდერების გადაადგილებაში და მათ ჩართვა-გამორთვაში. Dino Squad-ში, "უარეს შემთხვევაში" სცენარში, შეიძლება იყოს რამდენიმე ასეული ჭურვი ერთდროულად ბრძოლაში. კოლაიდერების გადაადგილება თითოეული ჭურვის ცალკე დასათვლელად მიუწვდომელი ფუფუნებაა. აქედან გამომდინარე, ჩვენთვის აბსოლუტურად აუცილებელი იყო მინიმუმამდე დავყვანილიყავით ფიზიკის „დაბრუნებების“ რაოდენობა. ამისთვის ECS-ში შევქმენით ცალკე კომპონენტი, რომელშიც ჩავწერთ მოთამაშის დროს. ჩვენ დავამატეთ ის ყველა ერთეულს, რომელიც მოითხოვს ჩამორჩენის კომპენსაციას (ჭურვები, შესაძლებლობები და ა.შ.). სანამ ჩვენ დავიწყებთ ასეთი ერთეულების დამუშავებას, ამ დროისთვის ვაგროვებთ მათ და ვამუშავებთ მათ ერთად, თითო კლასტერზე ერთხელ ვაბრუნებთ ფიზიკურ სამყაროს.

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

public sealed class LagCompensationSystemGroup : ExecutableSystem
{
     //Машина времени
     private readonly ITimeMachine _timeMachine;

     //Набор систем лагкомпенсации
     private readonly LagCompensationSystem[] _systems;
     
     //Наша реализация кластеризатора
     private readonly TimeTravelMap _travelMap = new TimeTravelMap();

    public LagCompensationSystemGroup(ITimeMachine timeMachine, 
        LagCompensationSystem[] lagCompensationSystems)
     {
         _timeMachine = timeMachine;
         _systems = lagCompensationSystems;
     }

     public override void Execute(GameState gs)
     {
         //На вход кластеризатор принимает текущее игровое состояние,
         //а на выход выдает набор «корзин». В каждой корзине лежат энтити,
         //которым для лагкомпенсации нужно одно и то же время из истории.
         var buckets = _travelMap.RefillBuckets(gs);

         for (int bucketIndex = 0; bucketIndex < buckets.Count; bucketIndex++)
         {
             ProcessBucket(gs, buckets[bucketIndex]);
         }

         //В конце лагкомпенсации мы восстанавливаем физический мир 
         //в исходное состояние
         _timeMachine.TravelToTime(gs.Time);
     }

     private void ProcessBucket(GameState presentState, TimeTravelMap.Bucket bucket)
     {
         //Откатываем время один раз для каждой корзины
         var pastState = _timeMachine.TravelToTime(bucket.Time);

         foreach (var system in _systems)
         {
               system.PastState = pastState;
               system.PresentState = presentState;

               foreach (var entity in bucket)
               {
                   system.Execute(entity);
               }
          }
     }
}

დარჩენილი იყო მხოლოდ დეტალების კონფიგურაცია:

1. გაიგეთ რამდენად შეზღუდოთ მოძრაობის მაქსიმალური მანძილი დროში.

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

2. დაადგინეთ რომელი საგნების გადატანა შეიძლება დროში და რომელი არა.

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

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

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

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

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

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

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

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

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

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

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

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

წყარო: www.habr.com