हमने नेटवर्क विलंबता क्षतिपूर्ति एल्गोरिदम के साथ मोबाइल शूटर के लिए बैलिस्टिक गणना के यांत्रिकी को कैसे बढ़ाया

नमस्ते, मैं निकिता ब्रिजाक हूं, पिक्सोनिक से एक सर्वर डेवलपर। आज मैं मोबाइल मल्टीप्लेयर में अंतराल की भरपाई के बारे में बात करना चाहूंगा।

सर्वर लैग मुआवजे के बारे में रूसी सहित कई लेख लिखे गए हैं। यह आश्चर्य की बात नहीं है, क्योंकि इस तकनीक का उपयोग 90 के दशक के उत्तरार्ध से मल्टीप्लेयर एफपीएस के निर्माण में सक्रिय रूप से किया गया है। उदाहरण के लिए, आप क्वेकवर्ल्ड मॉड को याद कर सकते हैं, जो इसका उपयोग करने वाले पहले लोगों में से एक था।

हम इसे अपने मोबाइल मल्टीप्लेयर शूटर डिनो स्क्वाड में भी उपयोग करते हैं।

इस लेख में, मेरा लक्ष्य उस बात को दोहराना नहीं है जो पहले ही हजारों बार लिखी जा चुकी है, बल्कि यह बताना है कि हमने अपनी तकनीक स्टैक और कोर गेमप्ले सुविधाओं को ध्यान में रखते हुए अपने गेम में लैग मुआवजे को कैसे लागू किया।

हमारे कॉर्टेक्स और प्रौद्योगिकी के बारे में कुछ शब्द।

डिनो स्क्वाड एक नेटवर्क मोबाइल PvP शूटर है। खिलाड़ी विभिन्न प्रकार के हथियारों से लैस डायनासोर को नियंत्रित करते हैं और 6v6 टीमों में एक दूसरे से लड़ते हैं।

क्लाइंट और सर्वर दोनों यूनिटी पर आधारित हैं। निशानेबाजों के लिए आर्किटेक्चर काफी क्लासिक है: सर्वर सत्तावादी है, और क्लाइंट भविष्यवाणी ग्राहकों पर काम करती है। गेम सिमुलेशन इन-हाउस ईसीएस का उपयोग करके लिखा गया है और इसका उपयोग सर्वर और क्लाइंट दोनों पर किया जाता है।

यदि आपने पहली बार अंतराल मुआवजे के बारे में सुना है, तो यहां इस मुद्दे पर एक संक्षिप्त भ्रमण दिया गया है।

मल्टीप्लेयर एफपीएस गेम में, मैच आमतौर पर रिमोट सर्वर पर सिम्युलेटेड होता है। खिलाड़ी अपना इनपुट (दबाई गई कुंजियों के बारे में जानकारी) सर्वर को भेजते हैं, और जवाब में सर्वर उन्हें प्राप्त डेटा को ध्यान में रखते हुए एक अद्यतन गेम स्थिति भेजता है। इस इंटरेक्शन योजना के साथ, फॉरवर्ड कुंजी दबाने और स्क्रीन पर खिलाड़ी के चरित्र के हिलने के बीच का विलंब हमेशा पिंग से अधिक होगा।

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

इस समस्या का समाधान क्लाइंट-साइड सिमुलेशन भविष्यवाणी है। यहां क्लाइंट स्वयं सर्वर से प्रतिक्रिया की प्रतीक्षा किए बिना, प्लेयर कैरेक्टर पर इनपुट लागू करता है। और जब उत्तर प्राप्त होता है, तो यह केवल परिणामों की तुलना करता है और विरोधियों की स्थिति को अद्यतन करता है। इस मामले में कुंजी दबाने और स्क्रीन पर परिणाम प्रदर्शित करने के बीच का विलंब न्यूनतम है।

यहां बारीकियों को समझना महत्वपूर्ण है: क्लाइंट हमेशा अपने अंतिम इनपुट के अनुसार खुद को खींचता है, और दुश्मन - नेटवर्क विलंब के साथ, सर्वर से डेटा की पिछली स्थिति के अनुसार। यानी किसी दुश्मन पर गोली चलाते समय खिलाड़ी उसे अपने सापेक्ष अतीत में देखता है। ग्राहक पूर्वानुमान के बारे में अधिक जानकारी हमने पहले लिखा था.

इस प्रकार, क्लाइंट भविष्यवाणी एक समस्या को हल करती है, लेकिन दूसरी समस्या पैदा करती है: यदि कोई खिलाड़ी उस बिंदु पर गोली चलाता है जहां दुश्मन अतीत में था, उसी बिंदु पर शूटिंग करते समय सर्वर पर, दुश्मन अब उस स्थान पर नहीं हो सकता है। सर्वर लैग क्षतिपूर्ति इस समस्या को हल करने का प्रयास करती है। जब कोई हथियार चलाया जाता है, तो सर्वर गेम की उस स्थिति को पुनर्स्थापित करता है जिसे खिलाड़ी ने शॉट के समय स्थानीय रूप से देखा था, और जांच करता है कि क्या वह वास्तव में दुश्मन को मार सकता था। यदि उत्तर "हाँ" है, तो हिट को गिना जाता है, भले ही दुश्मन उस समय सर्वर पर न हो।

इस ज्ञान से लैस होकर, हमने डिनो स्क्वाड में सर्वर लैग मुआवजे को लागू करना शुरू किया। सबसे पहले, हमें यह समझना था कि क्लाइंट ने जो देखा उसे सर्वर पर कैसे पुनर्स्थापित किया जाए? और वास्तव में किस चीज़ को पुनर्स्थापित करने की आवश्यकता है? हमारे खेल में, हथियारों और क्षमताओं से होने वाले हिट की गणना रेकास्ट और ओवरले के माध्यम से की जाती है - अर्थात, दुश्मन के भौतिक कोलाइडरों के साथ बातचीत के माध्यम से। तदनुसार, हमें इन कोलाइडरों की स्थिति को पुन: उत्पन्न करने की आवश्यकता थी, जिसे खिलाड़ी ने सर्वर पर स्थानीय रूप से "देखा"। उस समय हम यूनिटी संस्करण 2018.x का उपयोग कर रहे थे। वहां भौतिकी एपीआई स्थिर है, भौतिक दुनिया एक ही प्रति में मौजूद है। इसकी स्थिति को सहेजने और फिर इसे बॉक्स से पुनर्स्थापित करने का कोई तरीका नहीं है। इसलिए क्या करना है?

समाधान सतह पर था; इसके सभी तत्वों का उपयोग हम पहले ही अन्य समस्याओं को हल करने के लिए कर चुके थे:

1. प्रत्येक ग्राहक के लिए, हमें यह जानना होगा कि उसने चाबियाँ दबाने पर किस समय विरोधियों को देखा। हमने इस जानकारी को पहले ही इनपुट पैकेज में लिख लिया है और क्लाइंट भविष्यवाणी को समायोजित करने के लिए इसका उपयोग किया है।
2. हमें खेल राज्यों के इतिहास को संग्रहीत करने में सक्षम होने की आवश्यकता है। इसमें यह है कि हम अपने विरोधियों (और इसलिए उनके सहयोगियों) की स्थिति पर कब्जा कर लेंगे। हमारे पास सर्वर पर पहले से ही एक राज्य इतिहास था, हमने इसे बनाने के लिए इसका उपयोग किया डेल्टा. सही समय को जानकर हम इतिहास में सही स्थिति का आसानी से पता लगा सकते हैं।
3. अब जब हमारे हाथ में इतिहास से खेल की स्थिति है, तो हमें भौतिक दुनिया की स्थिति के साथ खिलाड़ी डेटा को सिंक्रनाइज़ करने में सक्षम होने की आवश्यकता है। मौजूदा कोलाइडर - हटते हैं, गायब कोलाइडर - बनाते हैं, अनावश्यक कोलाइडर - नष्ट करते हैं। यह तर्क भी पहले ही लिखा जा चुका था और इसमें कई ईसीएस सिस्टम शामिल थे। हमने इसका उपयोग एक यूनिटी प्रक्रिया में कई गेम रूम रखने के लिए किया। और चूंकि भौतिक दुनिया एक प्रक्रिया है, इसलिए इसे कमरों के बीच पुन: उपयोग करना पड़ता है। सिमुलेशन के प्रत्येक टिक से पहले, हम भौतिक दुनिया की स्थिति को "रीसेट" करते हैं और इसे वर्तमान कमरे के डेटा के साथ पुन: प्रारंभ करते हैं, एक चतुर पूलिंग सिस्टम के माध्यम से यूनिटी गेम ऑब्जेक्ट्स को यथासंभव पुन: उपयोग करने का प्रयास करते हैं। जो कुछ बचा था वह अतीत से खेल की स्थिति के लिए उसी तर्क को लागू करना था।

इन सभी तत्वों को एक साथ रखकर, हमें एक "टाइम मशीन" मिली जो भौतिक दुनिया की स्थिति को सही समय पर वापस ला सकती है। कोड सरल निकला:

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वें टिक पर, इस मामले में, अंतराल मुआवजा अब लागू नहीं होता है

हमारे कार्यान्वयन में, ये दोनों दृष्टिकोण कोड की केवल कुछ पंक्तियों में भिन्न थे, इसलिए हमने दोनों बनाए, और लंबे समय तक वे समानांतर में मौजूद रहे। हथियार की यांत्रिकी और गोली की गति के आधार पर, हमने प्रत्येक डायनासोर के लिए एक या दूसरा विकल्प चुना। यहाँ निर्णायक मोड़ यांत्रिकी के खेल में उपस्थिति थी जैसे "यदि आप इतने समय में दुश्मन को कई बार मारते हैं, तो इतना बोनस प्राप्त करें।" कोई भी मैकेनिक जहां खिलाड़ी द्वारा दुश्मन पर हमला करने के समय ने महत्वपूर्ण भूमिका निभाई हो, उसने दूसरे दृष्टिकोण के साथ काम करने से इनकार कर दिया। इसलिए हमने पहले विकल्प को चुना और अब यह खेल में सभी हथियारों और सभी सक्रिय क्षमताओं पर लागू होता है।

अलग से, यह प्रदर्शन के मुद्दे को उठाने लायक है। यदि आपने सोचा है कि यह सब चीजें धीमी कर देगा, तो मैं उत्तर देता हूं: यह है। कोलाइडर को हिलाने और उन्हें चालू और बंद करने में यूनिटी काफी धीमी है। डिनो स्क्वाड में, "सबसे खराब" स्थिति में, युद्ध में एक साथ कई सौ प्रोजेक्टाइल मौजूद हो सकते हैं। प्रत्येक प्रक्षेप्य को अलग-अलग गिनने के लिए कोलाइडर को ले जाना एक अप्राप्य विलासिता है। इसलिए, हमारे लिए भौतिकी "रोलबैक" की संख्या को कम करना नितांत आवश्यक था। ऐसा करने के लिए, हमने ईसीएस में एक अलग घटक बनाया जिसमें हम खिलाड़ी का समय रिकॉर्ड करते हैं। हमने इसे उन सभी संस्थाओं में जोड़ा है जिन्हें अंतराल क्षतिपूर्ति (प्रोजेक्टाइल, क्षमताएं, आदि) की आवश्यकता होती है। इससे पहले कि हम ऐसी संस्थाओं को संसाधित करना शुरू करें, हम उन्हें इस समय तक क्लस्टर करते हैं और उन्हें एक साथ संसाधित करते हैं, प्रत्येक क्लस्टर के लिए भौतिक दुनिया को एक बार वापस लाते हैं।

इस स्तर पर हमारे पास आम तौर पर कार्य प्रणाली है। इसका कोड कुछ हद तक सरलीकृत रूप में:

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. निर्धारित करें कि उस खिलाड़ी के कोलाइडर के साथ क्या करना है जिसके लिए अंतराल क्षतिपूर्ति की जा रही है। अच्छे तरीके से, उनकी स्थिति अतीत में नहीं बदलनी चाहिए: खिलाड़ी को खुद को उसी समय में देखना चाहिए जिसमें वह अब सर्वर पर है। हालाँकि, हम शूटिंग प्लेयर के कोलाइडर को भी वापस रोल करते हैं और इसके कई कारण हैं।

सबसे पहले, यह क्लस्टरिंग में सुधार करता है: हम करीबी पिंग वाले सभी खिलाड़ियों के लिए समान भौतिक स्थिति का उपयोग कर सकते हैं।

दूसरे, सभी रेकास्ट और ओवरलैप्स में हम हमेशा उस खिलाड़ी के कोलाइडर को बाहर कर देते हैं जिसके पास क्षमताएं या प्रोजेक्टाइल होते हैं। डिनो स्क्वाड में, खिलाड़ी डायनासोर को नियंत्रित करते हैं, जिनकी शूटर मानकों के अनुसार गैर-मानक ज्यामिति होती है। भले ही खिलाड़ी एक असामान्य कोण पर गोली चलाता है और गोली का प्रक्षेप पथ खिलाड़ी के डायनासोर कोलाइडर से होकर गुजरता है, गोली इसे अनदेखा कर देगी।

तीसरा, हम अंतराल मुआवजे की शुरुआत से पहले ही ईसीएस से डेटा का उपयोग करके डायनासोर के हथियार की स्थिति या क्षमता के अनुप्रयोग बिंदु की गणना करते हैं।

परिणामस्वरूप, लैग-मुआवज़ा वाले प्लेयर के कोलाइडर की वास्तविक स्थिति हमारे लिए महत्वहीन है, इसलिए हमने अधिक उत्पादक और साथ ही सरल रास्ता अपनाया।

नेटवर्क विलंबता को आसानी से हटाया नहीं जा सकता, इसे केवल छिपाया जा सकता है। छिपाने के किसी भी अन्य तरीके की तरह, सर्वर लैग मुआवजे के अपने फायदे हैं। यह उस खिलाड़ी के गेमिंग अनुभव को बेहतर बनाता है जो गोली चलाने वाले खिलाड़ी की कीमत पर शूटिंग कर रहा है। हालाँकि, डिनो स्क्वाड के लिए, यहाँ विकल्प स्पष्ट था।

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

2019 संस्करण में (और शायद थोड़ा पहले), यूनिटी ने स्वतंत्र भौतिक दृश्यों के लिए पूर्ण समर्थन जोड़ा। हमने अपडेट के लगभग तुरंत बाद उन्हें सर्वर पर लागू कर दिया, क्योंकि हम सभी कमरों के लिए सामान्य भौतिक दुनिया से जल्दी छुटकारा पाना चाहते थे।

हमने प्रत्येक गेम रूम को अपना स्वयं का भौतिक दृश्य दिया और इस प्रकार सिमुलेशन की गणना करने से पहले पड़ोसी कमरे के डेटा से दृश्य को "साफ़" करने की आवश्यकता को समाप्त कर दिया। सबसे पहले, इससे उत्पादकता में उल्लेखनीय वृद्धि हुई। दूसरे, इससे बग की एक पूरी श्रेणी से छुटकारा पाना संभव हो गया जो तब उत्पन्न होता था जब प्रोग्रामर नए गेम तत्वों को जोड़ते समय दृश्य सफाई कोड में कोई त्रुटि करता था। ऐसी त्रुटियों को डीबग करना कठिन था, और उनके परिणामस्वरूप अक्सर एक कमरे के दृश्य में भौतिक वस्तुओं की स्थिति दूसरे कमरे में "प्रवाहित" हो जाती थी।

इसके अलावा, हमने इस पर कुछ शोध किया कि क्या भौतिक दृश्यों का उपयोग भौतिक दुनिया के इतिहास को संग्रहीत करने के लिए किया जा सकता है। अर्थात्, सशर्त रूप से, प्रत्येक कमरे में एक दृश्य नहीं, बल्कि 30 दृश्य आवंटित करें, और उनमें से एक चक्रीय बफर बनाएं, जिसमें कहानी को संग्रहीत किया जाए। सामान्य तौर पर, विकल्प काम कर रहा था, लेकिन हमने इसे लागू नहीं किया: इसने उत्पादकता में कोई भारी वृद्धि नहीं दिखाई, बल्कि जोखिम भरे बदलावों की आवश्यकता थी। यह अनुमान लगाना मुश्किल था कि इतने सारे दृश्यों के साथ लंबे समय तक काम करने पर सर्वर कैसा व्यवहार करेगा। इसलिए, हमने नियम का पालन किया: "यदि यह तोड़ नहीं है, तो इसे ठीक न करें'.

स्रोत: www.habr.com