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

नमस्ते, म Pixonic बाट सर्भर विकासकर्ता Nikita Brizhak हुँ। आज म मोबाइल मल्टिप्लेयरमा ढिलाइको लागि क्षतिपूर्तिको बारेमा कुरा गर्न चाहन्छु।

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

हामी यसलाई हाम्रो मोबाइल मल्टिप्लेयर शूटर डिनो स्क्वाडमा पनि प्रयोग गर्छौं।

यस लेखमा, मेरो लक्ष्य पहिले नै हजार पटक लेखिएको कुरा दोहोर्याउने होइन, तर हाम्रो टेक्नोलोजी स्ट्याक र मुख्य गेमप्ले सुविधाहरूलाई ध्यानमा राख्दै हामीले हाम्रो खेलमा ढिलो क्षतिपूर्ति कसरी लागू गर्यौं भनेर बताउन।

हाम्रो कोर्टेक्स र प्रविधि बारे केही शब्दहरू।

डिनो स्क्वाड एक नेटवर्क मोबाइल PvP शूटर हो। खेलाडीहरूले विभिन्न प्रकारका हतियारहरूले सुसज्जित डायनासोरहरू नियन्त्रण गर्छन् र 6v6 टोलीहरूमा एक अर्कासँग लड्छन्।

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

यदि तपाईंले ढिलो क्षतिपूर्तिको बारेमा सुन्नुभएको यो पहिलो पटक हो भने, यहाँ यस मुद्दामा संक्षिप्त भ्रमण छ।

मल्टिप्लेयर FPS खेलहरूमा, खेल सामान्यतया रिमोट सर्भरमा सिमुलेटेड हुन्छ। खेलाडीहरूले सर्भरमा आफ्नो इनपुट (कुञ्जीहरू थिचिएको जानकारी) पठाउँछन्, र प्रतिक्रियामा सर्भरले प्राप्त डाटालाई खातामा लिई अद्यावधिक खेल स्थिति पठाउँदछ। यस अन्तरक्रिया योजनाको साथ, फर्वार्ड कुञ्जी थिच्ने र स्क्रिनमा प्लेयर क्यारेक्टर सर्ने क्षण बीचको ढिलाइ सधैं पिंग भन्दा ठूलो हुनेछ।

स्थानीय नेटवर्कहरूमा हुँदा यो ढिलाइ (लोकप्रिय रूपमा इनपुट ल्याग भनिन्छ) अप्रत्याशित हुन सक्छ, इन्टरनेट मार्फत खेल्दा यसले क्यारेक्टरलाई नियन्त्रण गर्दा "बरफमा स्लाइडिङ" को भावना सिर्जना गर्दछ। यो समस्या मोबाइल सञ्जालहरूको लागि दोब्बर सान्दर्भिक छ, जहाँ खेलाडीको पिङ 200 एमएस भएको अवस्थामा अझै पनि उत्कृष्ट जडान मानिन्छ। अक्सर पिंग 350, 500, वा 1000 ms हुन सक्छ। त्यसपछि इनपुट ल्यागको साथ द्रुत शूटर खेल्न लगभग असम्भव हुन्छ।

यस समस्याको समाधान ग्राहक-साइड सिमुलेशन भविष्यवाणी हो। यहाँ क्लाइन्ट आफैले सर्भरबाट प्रतिक्रियाको प्रतीक्षा नगरी, प्लेयर क्यारेक्टरमा इनपुट लागू गर्दछ। र जब जवाफ प्राप्त हुन्छ, यसले केवल परिणामहरू तुलना गर्दछ र विपक्षीको स्थिति अपडेट गर्दछ। यस अवस्थामा कुञ्जी थिच्ने र स्क्रिनमा नतिजा प्रदर्शन गर्ने बीचको ढिलाइ न्यूनतम छ।

यहाँ सूक्ष्मता बुझ्न महत्त्वपूर्ण छ: क्लाइन्टले सधैं यसको अन्तिम इनपुट अनुसार आफैलाई आकर्षित गर्दछ, र शत्रुहरू - नेटवर्क ढिलाइको साथ, सर्भरबाट डेटाको अघिल्लो अवस्था अनुसार। त्यो हो, जब एक शत्रु मा गोली हान्दा, खेलाडीले उसलाई विगतमा आफैलाई सापेक्ष देख्छ। ग्राहक भविष्यवाणी बारे थप हामीले पहिले लेख्यौं.

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

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

• गोलीको म्याद सकिएको छ। यसको मतलब गणना सकियो, हामी मिस वा हिट गणना गर्न सक्छौं। र यो त्यही टिकमा छ जसमा गोली चलाइएको थियो! हाम्रा लागि यो प्लस र माइनस दुवै थियो। एक प्लस - किनभने शूटिङ खेलाडीको लागि यसले हिट र शत्रुको स्वास्थ्यमा कमी बीचको ढिलाइलाई उल्लेखनीय रूपमा कम गर्यो। नकारात्मक पक्ष यो हो कि विपक्षीहरूले खेलाडीमा गोली हानेपछि उस्तै प्रभाव देखियो: दुश्मन, यो देखिन्छ, केवल एक ढिलो रकेट चलाएको छ, र क्षति पहिले नै गणना गरिएको थियो।
• बुलेट सर्भर समयमा पुग्यो। यस अवस्थामा, यसको सिमुलेशन कुनै पनि ढिलाइ क्षतिपूर्ति बिना अर्को सर्भर टिकमा जारी रहनेछ। ढिलो प्रोजेक्टाइलहरूको लागि, यसले सैद्धान्तिक रूपमा पहिलो विकल्पको तुलनामा भौतिकी रोलब्याकहरूको संख्या घटाउन सक्छ। एकै समयमा, सिमुलेशनमा असमान लोड बढ्यो: सर्भर या त निष्क्रिय थियो, वा एक सर्भर टिकमा यसले धेरै बुलेटहरूको लागि एक दर्जन सिमुलेशन टिकहरू गणना गरिरहेको थियो।

अघिल्लो तस्वीर मा जस्तै समान परिदृश्य, तर दोस्रो योजना अनुसार गणना। क्षेप्यास्त्रले सर्भर समयको साथ शट भएको एउटै टिकमा "क्याप अप" गर्यो, र हिट अर्को टिकको रूपमा गणना गर्न सकिन्छ। ३१ औं टिकमा, यस अवस्थामा, ढिलाइ क्षतिपूर्ति अब लागू हुँदैन

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

अलग, यो प्रदर्शन को मुद्दा उठाउन लायक छ। यदि तपाइँ सोच्नुहुन्छ कि यो सबै चीजहरू सुस्त हुनेछ, म जवाफ दिन्छु: यो हो। एकता कोलाइडरहरू सार्न र तिनीहरूलाई खोल्न र बन्द गर्नमा एकदम ढिलो छ। डिनो स्क्वाडमा, "सबैभन्दा खराब" अवस्थामा, त्यहाँ लडाईमा एकै साथ धेरै सय प्रोजेक्टाइलहरू अवस्थित हुन सक्छन्। प्रत्येक प्रोजेक्टाइललाई व्यक्तिगत रूपमा गणना गर्न कोलाइडरहरू सार्नु एक अप्ठ्यारो लक्जरी हो। तसर्थ, भौतिक विज्ञान "रोलब्याक" को संख्या कम गर्न को लागी यो बिल्कुल आवश्यक थियो। यो गर्नको लागि, हामीले 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 टिक्सको मार्जिन (२० हर्ट्जको टिक दरको साथ) सीमित गर्यौं। यसले खेलाडीहरूलाई धेरै उच्च पिंगहरूमा पनि विपक्षीहरूलाई हिट गर्न अनुमति दिन्छ।

2. कुन वस्तुहरू समयमा सार्न सकिन्छ र कुन सकिँदैन भनेर निर्धारण गर्नुहोस्।

हामी, पक्कै पनि, हाम्रा विरोधीहरूलाई सारिरहेका छौं। तर स्थापना योग्य ऊर्जा ढाल, उदाहरणका लागि, होइन। हामीले डिफेन्सिभ क्षमतालाई प्राथमिकता दिनु राम्रो हुन्छ भन्ने निर्णय गर्‍यौं, जसरी प्रायः अनलाइन शूटरहरूमा गरिन्छ। यदि खेलाडीले पहिले नै वर्तमानमा ढाल राखेको छ भने, विगतका ढिलाइ-क्षतिपूर्ति बुलेटहरू यसबाट उड्नु हुँदैन।

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

4. ढिलो क्षतिपूर्ति प्रदर्शन भइरहेको खेलाडी को कोलाइडर संग के गर्ने निर्धारण गर्नुहोस्। राम्रो तरिकाले, तिनीहरूको स्थिति विगतमा परिवर्तन हुनु हुँदैन: खेलाडीले आफूलाई अहिले सर्भरमा भएको समयमा देख्नुपर्छ। यद्यपि, हामी शूटिङ प्लेयरको कोलाइडरहरू पनि रोल ब्याक गर्छौं, र यसका धेरै कारणहरू छन्।

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

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

तेस्रो, हामी डायनासोरको हतियारको स्थिति वा ECS बाट डेटा प्रयोग गर्ने क्षमताको अनुप्रयोगको बिन्दुलाई ढिलो क्षतिपूर्ति सुरु हुनु अघि पनि गणना गर्छौं।

नतिजाको रूपमा, ढिलो-क्षतिपूर्ति प्लेयरको टक्करहरूको वास्तविक स्थिति हाम्रो लागि महत्वहीन छ, त्यसैले हामीले थप उत्पादक र एकै समयमा सरल मार्ग लियौं।

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

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

2019 संस्करणमा (र हुनसक्छ अलि पहिले), Unity ले स्वतन्त्र भौतिक दृश्यहरूको लागि पूर्ण समर्थन थप्यो। हामीले तिनीहरूलाई अद्यावधिक पछि लगभग तुरुन्तै सर्भरमा लागू गर्यौं, किनकि हामी सबै कोठाहरूमा सामान्य भौतिक संसारबाट छिट्टै छुटकारा पाउन चाहन्छौं।

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

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

स्रोत: www.habr.com