आम्ही नेटवर्क लेटन्सी कॉम्पेन्सेशन अल्गोरिदमसह मोबाइल शूटरसाठी बॅलिस्टिक गणनेचे मेकॅनिक्स कसे वर्धित केले

हाय, मी निकिता ब्रिजाक आहे, पिक्सोनिकची सर्व्हर डेव्हलपर. आज मी मोबाईल मल्टीप्लेअरमधील अंतराची भरपाई करण्याबद्दल बोलू इच्छितो.

रशियनसह सर्व्हर लॅग भरपाईबद्दल बरेच लेख लिहिले गेले आहेत. हे आश्चर्यकारक नाही, कारण हे तंत्रज्ञान 90 च्या दशकाच्या उत्तरार्धापासून मल्टीप्लेअर एफपीएसच्या निर्मितीमध्ये सक्रियपणे वापरले जात आहे. उदाहरणार्थ, तुम्ही QuakeWorld मॉड लक्षात ठेवू शकता, जो ते वापरणाऱ्यांपैकी एक होता.

आम्ही ते आमच्या मोबाइल मल्टीप्लेअर शूटर डिनो स्क्वॉडमध्ये देखील वापरतो.

या लेखात, माझे उद्दिष्ट जे आधीच हजार वेळा लिहिले गेले आहे त्याची पुनरावृत्ती करणे नाही, तर आमचे तंत्रज्ञान स्टॅक आणि मुख्य गेमप्ले वैशिष्ट्ये लक्षात घेऊन आम्ही आमच्या गेममध्ये लॅग भरपाई कशी लागू केली हे सांगणे आहे.

आमच्या कॉर्टेक्स आणि तंत्रज्ञानाबद्दल काही शब्द.

डिनो स्क्वॉड एक नेटवर्क मोबाइल PvP शूटर आहे. खेळाडू विविध प्रकारच्या शस्त्रांनी सुसज्ज डायनासोर नियंत्रित करतात आणि 6v6 संघांमध्ये एकमेकांशी लढतात.

क्लायंट आणि सर्व्हर दोन्ही युनिटीवर आधारित आहेत. नेमबाजांसाठी आर्किटेक्चर अगदी क्लासिक आहे: सर्व्हर हुकूमशाही आहे आणि क्लायंटचा अंदाज क्लायंटवर कार्य करतो. गेम सिम्युलेशन इन-हाउस ईसीएस वापरून लिहिलेले आहे आणि सर्व्हर आणि क्लायंट दोन्हीवर वापरले जाते.

जर तुम्ही लॅग कंपेन्सेशनबद्दल पहिल्यांदाच ऐकले असेल, तर येथे या समस्येचे थोडक्यात भ्रमण आहे.

मल्टीप्लेअर FPS गेममध्ये, सामना सहसा रिमोट सर्व्हरवर नक्कल केला जातो. खेळाडू त्यांचे इनपुट (की दाबलेल्या की बद्दल माहिती) सर्व्हरला पाठवतात आणि प्रतिसादात सर्व्हर त्यांना प्राप्त डेटा लक्षात घेऊन अद्ययावत गेम स्थिती पाठवतो. या परस्परसंवाद योजनेसह, फॉरवर्ड की दाबणे आणि प्लेअरचे पात्र स्क्रीनवर हलवण्याच्या क्षणादरम्यानचा विलंब नेहमीच पिंगपेक्षा जास्त असेल.

स्थानिक नेटवर्कवर असताना हा विलंब (लोकप्रियपणे इनपुट लॅग म्हणतात) कदाचित लक्षात येण्याजोगा असू शकतो, इंटरनेटद्वारे खेळत असताना ते वर्ण नियंत्रित करताना "बर्फावर सरकत आहे" अशी भावना निर्माण करते. ही समस्या मोबाइल नेटवर्कसाठी दुप्पट संबंधित आहे, जेथे खेळाडूचा पिंग 200 ms असेल तरीही एक उत्कृष्ट कनेक्शन मानले जाते. अनेकदा पिंग 350, 500 किंवा 1000 ms असू शकते. मग इनपुट लॅगसह वेगवान शूटर खेळणे जवळजवळ अशक्य होते.

या समस्येचे निराकरण क्लायंट-साइड सिम्युलेशन अंदाज आहे. येथे क्लायंट स्वतःच सर्व्हरच्या प्रतिसादाची वाट न पाहता प्लेअर कॅरेक्टरला इनपुट लागू करतो. आणि जेव्हा उत्तर प्राप्त होते, तेव्हा ते फक्त परिणामांची तुलना करते आणि विरोधकांची स्थिती अद्यतनित करते. या प्रकरणात की दाबणे आणि स्क्रीनवर निकाल प्रदर्शित करणे यामधील विलंब कमी आहे.

येथे सूक्ष्मता समजून घेणे महत्वाचे आहे: क्लायंट नेहमी त्याच्या शेवटच्या इनपुटनुसार स्वतःला आकर्षित करतो आणि शत्रू - नेटवर्क विलंबाने, सर्व्हरवरील डेटाच्या मागील स्थितीनुसार. म्हणजेच, शत्रूवर गोळीबार करताना, खेळाडू त्याला स्वतःच्या सापेक्ष भूतकाळात पाहतो. क्लायंटच्या अंदाजाबद्दल अधिक आम्ही आधी लिहिले.

अशाप्रकारे, क्लायंटचा अंदाज एक समस्या सोडवतो, परंतु दुसरी तयार करतो: जर एखाद्या खेळाडूने भूतकाळात शत्रू असलेल्या ठिकाणी शूट केले, त्याच बिंदूवर शूट करताना सर्व्हरवर, शत्रू यापुढे त्या ठिकाणी नसू शकतो. सर्व्हर लॅग भरपाई ही समस्या सोडवण्याचा प्रयत्न करते. जेव्हा एखादे शस्त्र गोळीबार केले जाते, तेव्हा सर्व्हर गेम स्थिती पुनर्संचयित करतो जे खेळाडूने शॉटच्या वेळी स्थानिकपणे पाहिले होते आणि तो खरोखर शत्रूला मारला असता का ते तपासतो. जर उत्तर "होय" असेल, तर हिट मोजला जातो, जरी त्या वेळी शत्रू सर्व्हरवर नसला तरीही.

या ज्ञानासह सशस्त्र, आम्ही डिनो स्क्वॉडमध्ये सर्व्हर लॅग भरपाई लागू करण्यास सुरुवात केली. सर्व प्रथम, क्लायंटने काय पाहिले ते सर्व्हरवर कसे पुनर्संचयित करावे हे आम्हाला समजले पाहिजे? आणि नक्की काय पुनर्संचयित करणे आवश्यक आहे? आमच्या गेममध्ये, शस्त्रे आणि क्षमतांवरील हिट्सची गणना रेकास्ट आणि आच्छादनांद्वारे केली जाते - म्हणजेच शत्रूच्या भौतिक कोलायडर्ससह परस्परसंवादाद्वारे. त्यानुसार, आम्हाला या कोलायडर्सची स्थिती पुनरुत्पादित करणे आवश्यक आहे, जे प्लेअरने सर्व्हरवर स्थानिकरित्या "पाहिले". त्यावेळी आम्ही युनिटी आवृत्ती 2018.x वापरत होतो. तेथील भौतिकशास्त्र API स्थिर आहे, भौतिक जग एकाच प्रतीमध्ये अस्तित्वात आहे. त्याचे राज्य जतन करण्याचा आणि नंतर बॉक्समधून पुनर्संचयित करण्याचा कोणताही मार्ग नाही. मग काय करायचं?

समाधान पृष्ठभागावर होते; त्यातील सर्व घटक आमच्याद्वारे इतर समस्यांचे निराकरण करण्यासाठी आधीच वापरले गेले होते:

1. प्रत्येक क्लायंटसाठी, जेव्हा त्याने कळा दाबल्या तेव्हा त्याने विरोधकांना कोणत्या वेळी पाहिले हे आपल्याला माहित असणे आवश्यक आहे. आम्ही ही माहिती आधीच इनपुट पॅकेजमध्ये लिहिली आहे आणि क्लायंट अंदाज समायोजित करण्यासाठी वापरली आहे.
2. आम्ही खेळ राज्यांचा इतिहास संग्रहित करण्यास सक्षम असणे आवश्यक आहे. त्यातच आम्ही आमच्या विरोधकांची (आणि म्हणून त्यांचे टक्कर देणारे) स्थान धारण करू. आमच्याकडे आधीच सर्व्हरवर राज्य इतिहास आहे, आम्ही ते तयार करण्यासाठी वापरले डेल्टास. योग्य वेळ जाणून घेतल्यास, आपल्याला इतिहासात योग्य राज्य सहज सापडते.
3. आता आपल्याकडे इतिहासातील गेम स्थिती आहे, आम्हाला भौतिक जगाच्या स्थितीसह खेळाडू डेटा समक्रमित करण्यास सक्षम असणे आवश्यक आहे. विद्यमान टक्कर - हलवा, गहाळ - तयार करा, अनावश्यक - नष्ट करा. हे तर्कशास्त्र आधीच लिहिले गेले होते आणि त्यात अनेक ECS प्रणालींचा समावेश होता. आम्ही एका युनिटी प्रक्रियेत अनेक गेम रूम ठेवण्यासाठी याचा वापर केला. आणि भौतिक जग प्रत्येक प्रक्रियेत एक असल्याने, ते खोल्यांमध्ये पुन्हा वापरावे लागले. सिम्युलेशनच्या प्रत्येक टिकापूर्वी, आम्ही भौतिक जगाची स्थिती "रीसेट" केली आणि वर्तमान खोलीसाठी डेटासह ते पुन्हा सुरू केले, चतुर पूलिंग सिस्टमद्वारे युनिटी गेम ऑब्जेक्ट्सचा शक्य तितका पुन्हा वापर करण्याचा प्रयत्न केला. भूतकाळातील खेळाच्या स्थितीसाठी समान तर्क लागू करणे बाकी होते.

हे सर्व घटक एकत्र करून, आम्हाला एक "टाइम मशीन" मिळाले जे भौतिक जगाची स्थिती योग्य क्षणी परत आणू शकते. कोड सोपे असल्याचे दिसून आले:

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;
     }
}

फक्त शॉट्स आणि क्षमतांची सहज भरपाई करण्यासाठी या मशीनचा वापर कसा करायचा हे शोधणे बाकी होते.

सर्वात सोप्या प्रकरणात, जेव्हा यांत्रिकी एकाच हिटस्कॅनवर आधारित असते, तेव्हा सर्वकाही स्पष्ट दिसते: खेळाडूने शूट करण्यापूर्वी, त्याला भौतिक जगाला इच्छित स्थितीत परत आणणे आवश्यक आहे, रेकास्ट करणे, हिट किंवा चुकणे मोजणे आणि जगाला प्रारंभिक स्थितीकडे परत करा.

पण डिनो पथकात असे मेकॅनिक फार कमी आहेत! गेममधील बहुतेक शस्त्रे प्रोजेक्टाइल तयार करतात - दीर्घकालीन बुलेट जे अनेक सिम्युलेशन टिक्ससाठी उडतात (काही प्रकरणांमध्ये, डझनभर टिक). त्यांचं काय करायचं, किती वाजता उडायचं?

В प्राचीन लेख हाफ-लाइफ नेटवर्क स्टॅकबद्दल, वाल्वच्या मुलांनी तोच प्रश्न विचारला आणि त्यांचे उत्तर हे होते: प्रक्षेपण अंतर भरपाई समस्याप्रधान आहे आणि ते टाळणे चांगले आहे.

आमच्याकडे हा पर्याय नव्हता: प्रक्षेपण-आधारित शस्त्रे हे गेम डिझाइनचे प्रमुख वैशिष्ट्य होते. त्यामुळे आम्हाला काहीतरी शोधून काढावे लागले. काही विचारमंथनानंतर, आम्ही दोन पर्याय तयार केले जे कार्य करत आहेत:

1. आम्ही प्रक्षेपणाला तयार केलेल्या खेळाडूच्या वेळेस बांधतो. सर्व्हर सिम्युलेशनची प्रत्येक टिक, प्रत्येक खेळाडूच्या प्रत्येक बुलेटसाठी, आम्ही भौतिक जगाला क्लायंट स्थितीत परत आणतो आणि आवश्यक गणना करतो. या दृष्टिकोनामुळे सर्व्हरवर वितरित लोड आणि प्रोजेक्टाइलच्या उड्डाण वेळेचा अंदाज लावणे शक्य झाले. प्रेडिक्टेबिलिटी आमच्यासाठी विशेषतः महत्वाची होती, कारण आमच्याकडे क्लायंटवर अंदाज लावलेल्या शत्रूच्या प्रोजेक्टाइल्ससह सर्व प्रोजेक्टाइल आहेत.

चित्रात, टिक 30 वर असलेला खेळाडू अपेक्षेने क्षेपणास्त्र उडवत आहे: तो शत्रू कोणत्या दिशेने धावत आहे हे पाहतो आणि त्याला क्षेपणास्त्राचा अंदाजे वेग माहित आहे. स्थानिक पातळीवर तो पाहतो की त्याने 33 व्या टिकला लक्ष्य केले. विलंब भरपाईबद्दल धन्यवाद, ते सर्व्हरवर देखील दिसून येईल

2. आम्ही पहिल्या पर्यायाप्रमाणेच सर्वकाही करतो, परंतु, बुलेट सिम्युलेशनची एक टिक मोजल्यानंतर, आम्ही थांबत नाही, परंतु त्याच सर्व्हर टिकमध्ये त्याचे फ्लाइट अनुकरण करणे सुरू ठेवतो, प्रत्येक वेळी त्याचा वेळ सर्व्हरच्या जवळ आणतो. एकामागून एक टिक आणि कोलायडर पोझिशन अपडेट करत आहे. दोनपैकी एक गोष्ट होईपर्यंत आम्ही हे करतो:

• बुलेटची मुदत संपली आहे. याचा अर्थ असा की गणना संपली आहे, आपण चुकू किंवा हिट मोजू शकतो. आणि हे त्याच टिकवर आहे ज्यामध्ये गोळी झाडली गेली होती! आमच्यासाठी हे प्लस आणि मायनस दोन्ही होते. एक प्लस - कारण शूटिंग प्लेयरसाठी यामुळे हिट आणि शत्रूच्या आरोग्यामध्ये होणारा विलंब लक्षणीयरीत्या कमी झाला. नकारात्मक बाजू अशी आहे की जेव्हा विरोधकांनी खेळाडूवर गोळीबार केला तेव्हा तोच परिणाम दिसून आला: शत्रूने असे दिसते की फक्त एक मंद रॉकेट सोडला आणि नुकसान आधीच मोजले गेले.
• बुलेट सर्व्हर वेळेवर पोहोचला आहे. या प्रकरणात, त्याचे अनुकरण पुढील सर्व्हर टिकमध्ये कोणत्याही अंतराची भरपाई न करता सुरू राहील. मंद प्रक्षेपणासाठी, हे सैद्धांतिकदृष्ट्या पहिल्या पर्यायाच्या तुलनेत भौतिकशास्त्राच्या रोलबॅकची संख्या कमी करू शकते. त्याच वेळी, सिम्युलेशनवरील असमान भार वाढला: सर्व्हर एकतर निष्क्रिय होता, किंवा एका सर्व्हर टिकमध्ये ते अनेक बुलेटसाठी डझनभर सिम्युलेशन टिक्स मोजत होते.

मागील चित्राप्रमाणेच परिस्थिती, परंतु दुसऱ्या योजनेनुसार गणना केली. क्षेपणास्त्र सर्व्हरच्या वेळेसह शॉट झाला त्याच टिकच्या वेळी “कॅच अप” झाले आणि हिट पुढील टिक म्हणून लवकर मोजले जाऊ शकते. 31 व्या टिकवर, या प्रकरणात, अंतराची भरपाई यापुढे लागू केली जाणार नाही

आमच्या अंमलबजावणीमध्ये, कोडच्या फक्त दोन ओळींमध्ये हे दोन दृष्टिकोन भिन्न होते, म्हणून आम्ही दोन्ही तयार केले आणि बर्याच काळापासून ते समांतर अस्तित्वात होते. शस्त्राच्या यांत्रिकी आणि बुलेटच्या वेगावर अवलंबून, आम्ही प्रत्येक डायनासोरसाठी एक किंवा दुसरा पर्याय निवडला. इथे टर्निंग पॉइंट म्हणजे मेकॅनिक्सच्या खेळात "जर तुम्ही अशा वेळी शत्रूला इतक्या वेळा मारले तर असा बोनस मिळवा." कोणत्याही मेकॅनिकने जेथे खेळाडूने शत्रूला मारल्याच्या वेळी महत्त्वाची भूमिका बजावली, त्याने दुसऱ्या दृष्टिकोनासह काम करण्यास नकार दिला. म्हणून आम्ही पहिल्या पर्यायासह समाप्त केले आणि ते आता सर्व शस्त्रे आणि गेममधील सर्व सक्रिय क्षमतांना लागू होते.

स्वतंत्रपणे, कार्यप्रदर्शनाचा मुद्दा उपस्थित करणे योग्य आहे. जर तुम्हाला असे वाटले की या सर्व गोष्टी कमी होतील, तर मी उत्तर देतो: ते आहे. कोलायडर्स हलविण्यात आणि त्यांना चालू आणि बंद करण्यात युनिटी खूपच मंद आहे. डिनो स्क्वॉडमध्ये, "सर्वात वाईट" प्रकरणात, लढाईत एकाच वेळी अनेक शंभर प्रोजेक्टाइल असू शकतात. प्रत्येक प्रक्षेपणाला स्वतंत्रपणे मोजण्यासाठी कोलायडर्स हलवणे ही परवडणारी लक्झरी आहे. म्हणून, भौतिकशास्त्रातील "रोलबॅक" ची संख्या कमी करणे आमच्यासाठी पूर्णपणे आवश्यक होते. हे करण्यासाठी, आम्ही 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. ज्या खेळाडूसाठी अंतराची भरपाई केली जात आहे त्यांच्या कोलायडर्सचे काय करायचे ते ठरवा. चांगल्या प्रकारे, त्यांची स्थिती भूतकाळात बदलू नये: खेळाडूने स्वतःला त्याच वेळी पाहिले पाहिजे ज्यामध्ये तो आता सर्व्हरवर आहे. तथापि, आम्ही शूटिंग प्लेयरचे टक्कर देखील परत करतो आणि याची अनेक कारणे आहेत.

प्रथम, ते क्लस्टरिंग सुधारते: आम्ही जवळच्या पिंग्ससह सर्व खेळाडूंसाठी समान भौतिक स्थिती वापरू शकतो.

दुसरे म्हणजे, सर्व रेकास्ट आणि ओव्हरलॅप्समध्ये आम्ही नेहमी क्षमता किंवा प्रोजेक्टाइल्सच्या मालकीच्या खेळाडूचे कोलायडर्स वगळतो. डिनो स्क्वॉडमध्ये, खेळाडू डायनासोर नियंत्रित करतात, ज्यात नेमबाज मानकांनुसार मानक नसलेली भूमिती असते. जरी खेळाडूने असामान्य कोनात गोळी मारली आणि गोळीचा मार्ग खेळाडूच्या डायनासोरच्या टक्करातून गेला तरीही बुलेट त्याकडे दुर्लक्ष करेल.

तिसरे म्हणजे, आम्ही डायनासोरच्या शस्त्राची स्थिती किंवा ECS कडील डेटा वापरून क्षमतेच्या अनुप्रयोगाच्या बिंदूची गणना अंतराची भरपाई सुरू होण्यापूर्वीच करतो.

परिणामी, लॅग-कम्पेन्सेटेड प्लेअरच्या कोलायडर्सची वास्तविक स्थिती आमच्यासाठी महत्वाची नाही, म्हणून आम्ही अधिक उत्पादनक्षम आणि त्याच वेळी सोपा मार्ग स्वीकारला.

नेटवर्क लेटन्सी फक्त काढून टाकली जाऊ शकत नाही, ती फक्त मास्क केली जाऊ शकते. वेशातील इतर कोणत्याही पद्धतीप्रमाणे, सर्व्हर लॅग भरपाईचे त्याचे ट्रेडऑफ आहेत. हे ज्या खेळाडूवर गोळी मारली जात आहे त्याच्या खर्चावर शूटिंग करणार्‍या खेळाडूचा गेमिंग अनुभव सुधारतो. डिनो स्क्वॉडसाठी, तथापि, येथे निवड स्पष्ट होती.

अर्थात, या सर्वांसाठी संपूर्णपणे सर्व्हर कोडच्या वाढीव जटिलतेसाठी पैसे द्यावे लागले - प्रोग्रामर आणि गेम डिझाइनर दोन्हीसाठी. जर पूर्वी सिम्युलेशन सिस्टमचा एक साधा अनुक्रमिक कॉल असेल, तर लॅग भरपाईसह, नेस्टेड लूप आणि शाखा त्यात दिसू लागल्या. सोबत काम करणे सोयीचे व्हावे यासाठी आम्ही खूप प्रयत्न केले.

2019 च्या आवृत्तीमध्ये (आणि कदाचित थोडे आधी), युनिटीने स्वतंत्र भौतिक दृश्यांसाठी पूर्ण समर्थन जोडले. आम्ही ते अद्यतनानंतर लगेचच सर्व्हरवर लागू केले, कारण आम्हाला सर्व खोल्यांमध्ये सामान्य असलेल्या भौतिक जगापासून त्वरित सुटका हवी होती.

आम्ही प्रत्येक गेम रूमला त्याचे स्वतःचे भौतिक दृश्य दिले आणि अशा प्रकारे सिम्युलेशनची गणना करण्यापूर्वी शेजारच्या खोलीच्या डेटामधून दृश्य "साफ" करण्याची आवश्यकता दूर केली. सर्वप्रथम, यामुळे उत्पादकतेत लक्षणीय वाढ झाली. दुसरे म्हणजे, नवीन गेम घटक जोडताना प्रोग्रामरने सीन क्लीनअप कोडमध्ये त्रुटी केल्यास उद्भवलेल्या बग्सच्या संपूर्ण वर्गापासून मुक्त होणे शक्य झाले. अशा त्रुटी डीबग करणे कठीण होते आणि त्यामुळे अनेकदा एका खोलीच्या दृश्यातील भौतिक वस्तूंची स्थिती दुसऱ्या खोलीत "वाहते" होते.

याव्यतिरिक्त, आम्ही भौतिक जगाचा इतिहास संग्रहित करण्यासाठी भौतिक दृश्यांचा वापर केला जाऊ शकतो का यावर काही संशोधन केले. म्हणजेच, सशर्त, प्रत्येक खोलीत एक दृश्य नाही तर 30 दृश्ये द्या आणि त्यांच्यामधून एक चक्रीय बफर बनवा, ज्यामध्ये कथा संग्रहित करा. सर्वसाधारणपणे, पर्याय कार्यरत असल्याचे दिसून आले, परंतु आम्ही ते अंमलात आणले नाही: त्याने उत्पादकतेत कोणतीही विलक्षण वाढ दर्शविली नाही, परंतु त्याऐवजी धोकादायक बदल आवश्यक आहेत. एवढ्या दृश्यांसह बराच वेळ काम करत असताना सर्व्हर कसा वागेल हे सांगणे कठीण होते. म्हणून, आम्ही नियम पाळला: "जर तो तुटलेला नसेल तर त्याचे निराकरण करू नका».

स्त्रोत: www.habr.com