RTS तुल्यकालिक इंजन और Desync इतिहास

क्या आपने कभी StarCraft या सुप्रीम कमांडर जैसे गेम खेले हैं और "आउट ऑफ सिंक" का पता लगाने के बाद एक त्रुटि संदेश मिला, जिसके बाद गेम को बंद कर दिया गया? जानना चाहते हैं कि ऐसा क्यों हो रहा है? यह वास्तविक समय की रणनीतियों द्वारा अक्सर उपयोग किए जाने वाले खेल इंजन वास्तुकला की विरासत है। ¹

इस क्षेत्र में मेरा अनुभव गैस पावर्ड गेम्स में सुप्रीम कमांडर इंजन के साथ काम करने से आता है। बीटा परीक्षण के दौरान, Starcraft और Warcraft 3 को भी सिंक्रनाइज़ेशन के साथ समस्या थी, इसलिए हम कह सकते हैं कि सामान्य तौर पर वे उसी तरह काम करते हैं। सादगी के लिए, मैं सुप्रीम कमांडर इंजन के बारे में बात करूंगा। अन्य खेलों के साथ समानताएं ढूंढना पाठक के लिए एक अभ्यास के रूप में छोड़ देगा :)

आवश्यकताओं

सबसे पहले, हमारे खेल के लिए क्या आवश्यकताएं हैं? आपको यह बताने के लिए, यहां सुप्रीम कमांडर (2006) के पहले भाग के लिए एक वीडियो है।



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

तो कोई कार्य कैसे कर सकता है?

सिंक्रोनस इंजन आर्किटेक्चर

... एक एकल चरण के साथ पूरी तरह से तुल्यकालिक वास्तुकला के साथ! समकालिक इंजन में
प्रत्येक ग्राहक समान गति से समान कोड निष्पादित करता है। इसे थोड़ा सोचें। सुप्रीम कमांडर 8-प्लेयर गेम में, प्रत्येक खिलाड़ी गेम की समान स्थिति को संग्रहीत करता है और समान कोड निष्पादित करता है। नेटवर्क पर इकाइयों (स्थिति, स्वास्थ्य, आदि) की स्थिति के बारे में जानकारी संचारित करने के बजाय, केवल ² खिलाड़ियों द्वारा दर्ज की गई टीमों को प्रेषित किया जा सकता है। यदि सभी खिलाड़ियों का खेल राज्य समान है और समान इनपुट संसाधित है, तो परिणामी स्थिति भी समान होनी चाहिए।

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

स्तरों

शुरुआत में वीडियो देखें, अगर आप नहीं करेंगे। आपको क्या लगता है, प्रति सेकंड कितने फ्रेम के साथ खेल चल रहा है? सही उत्तर 10 एफपीएस है। “रुको क्या? वह बहुत चिकनी लग रही है! ”आप कहते हैं! हाँ - और एक ही समय में नहीं। आमतौर पर, एक खेल में दो आवृत्तियों का एक साथ उपयोग किया जाता है।

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

उपयोगकर्ता स्तर पूर्ण फ्रेम दर पर चलता है। इस स्तर को विशेष रूप से ग्राफिक माना जा सकता है। यूजर इंटरफेस, रेंडरिंग, एनीमेशन और यहां तक ​​कि यूनिट पोजिशन की गणना 60 एफपीएस पर की जा सकती है। प्रत्येक UserTick डेल्टा के दौरान अद्यतन किया जाता है, जिसका उपयोग खेल राज्य को एक मध्यवर्ती मूल्य (उदाहरण के लिए, मध्यवर्ती इकाई पदों) के लिए प्रक्षेपित करने के लिए किया जाता है। यही कारण है कि खेल आसानी से देख और खेल सकता है, हालांकि मुख्य इंजन कोर काफी कम आवृत्ति पर चलता है।

यह सिद्धांत कि मनुष्य के कार्य स्वतंत्र नहीं होते

"एक मिनट रुको!" "यदि प्रत्येक खिलाड़ी स्वतंत्र रूप से खेल की स्थिति को अपडेट करता है, तो क्या इसका मतलब यह है कि खेल का अनुकरण पूरी तरह से निर्धारक है?" क्या इसे हासिल करना मुश्किल है? हां। खासतौर पर आज की बहु-सूत्रीय दुनिया में।

इंजन के डेवलपर्स को बहुत सारी परेशानियाँ फ़्लोटिंग पॉइंट नंबर देती हैं। इस विषय का विस्तार से वर्णन करने के बजाय, मैं ग्लेन फील्डर - फ्लोटिंग पॉइंट निर्धारणवाद द्वारा एक शानदार पोस्ट का लिंक दूंगा।

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

आंतरिक देरी

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

उदाहरण के लिए, तीन खिलाड़ी - ए, बी और सी - लॉन्च सिमिकिक [1]। इस समय, खिलाड़ी A इकाई को आक्रमण करने की आज्ञा देता है। यूआई तुरंत प्रतिक्रिया दिखाता है, क्योंकि UserTick प्रति सेकंड 60 बार चलती है। एकल-खिलाड़ी गेम में, इस कमांड को SimTick [2] (0-100 एमएस में देरी) में संसाधित किया जाएगा। हालांकि, सभी तीन खिलाड़ियों को समान परिणाम प्राप्त करने के लिए एक ही SimTick रन में टीम को संसाधित करना होगा। SimTick [2] में कमांड को संसाधित करने की कोशिश करने के बजाय, खिलाड़ी A, SimTick [4] (विलंब 200-300 ms) में निष्पादित करने के लिए डेटा B के साथ खिलाड़ियों को B और C को नेटवर्क पैकेट भेजता है। इससे सभी खिलाड़ियों को टीम बनाने का समय मिल जाता है। यदि इनपुट जानकारी प्राप्त नहीं हुई है या समय पर पुष्टि नहीं की गई है तो गेम क्रैश हो सकता है। मुझे नहीं पता है कि सुपकॉम में इसके लिए कौन से तंत्र का उपयोग किया गया था, लेकिन मुझे पता चलने पर मैं इस पोस्ट को अपडेट कर दूंगा। SimTick निष्पादन की विशिष्ट संख्या जिसके माध्यम से इनपुट को संसाधित किया जाना चाहिए गतिशील रूप से P2p ⁵ टोपोलॉजी का उपयोग करके निर्धारित किया जाता है।

यूनिट की प्रतिक्रिया के लिए उपयोगकर्ता की क्लिक से देरी हमेशा कम से कम 0-100 एमएस (अगली सिमटेक) होगी। इसे कई तरीकों से मुखौटा बनाया जा सकता है। इंटरफ़ेस आमतौर पर तुरंत प्रतिक्रिया देता है - कुछ चमकता है, एक उपयुक्त ध्वनि सुनाई देती है: "अयूर के लिए जीवन!" या "ज़ग ज़ग"।

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

Desync - नरक से कीड़े

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

SupCom में, खेल का पूरा राज्य प्रति सेकंड एक बार हैशेड है। यदि कुछ क्लाइंट के लिए हैश मेल नहीं खाता है, तो कॉन्सर्ट खत्म हो गया है। खेल खत्म अंत। संदेश "सिंक त्रुटि" के साथ एक विंडो पॉप अप होती है और आपको गेम से बाहर निकलना होगा। SimTick के परिणामों में कुछ मेल नहीं खाता था और अब खेल की स्थिति अलग है। सिमुलेशन के मार्ग बदल गए और आगे यह केवल बदतर हो जाएगा। यहां एक पुनर्प्राप्ति तंत्र प्रदान नहीं किया गया है।

आउट ऑफ सिंक आमतौर पर प्रोग्रामर त्रुटि का परिणाम होता है। डेसिंक को 60% से अधिक समय तक चलने वाले 5% खेलों में खेला जा सकता है। ऐसी त्रुटि को ढूंढना और ठीक करना आमतौर पर गेम के दौरान कंसोल में मुद्रित मेमोरी स्टेटस के हैश में एक द्विआधारी खोज शामिल है। प्लेबैक के कम अवसर के साथ desync के साथ, यह कंसोल में संदेशों की एक बड़ी संख्या की ओर जाता है जबकि आधा दर्जन मशीनें जितनी जल्दी हो सके सिमुलेशन की गणना करती हैं, इसके टूटने का इंतजार कर रही हैं। यदि यह आपके लिए पर्याप्त नहीं है, तो मैं जोड़ूंगा कि सिंक से बाहर होने के सबसे सामान्य कारणों में से एक अघोषित चर है।

डिमिगॉड का इतिहास

SupCom इंजन पर मेरा अधिकांश काम डेमिगोड पर काम करते समय किया गया था, जिसमें इंजन के एक संशोधित संस्करण का उपयोग किया गया था।



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

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

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

अंतिम विचार

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

1. हेलो अभियान सह-ऑप और अग्निशमन मोड में एक साथ एक तुल्यकालिक मॉडल का उपयोग करता है
2. SupCom में, इनपुट को यूनिट समूहों के कमांड के रूप में संसाधित किया जाता है। आंदोलन, हमले, रक्षा, क्षमताओं का उपयोग, आदि।
3. यदि पुरानी कोड को पुराने डेटा के साथ चलाना संभव हो तो पुरानी रिट्री फ़ाइलों का समर्थन किया जा सकता है
4. हेलो में रिवाइंडिंग "सेवप्वाइंट" का उपयोग करके की गई थी जो एक विशिष्ट बिंदु पर गेम की स्थिति को संग्रहीत करता है। सुचारू रूप से रिवाइंड करना असंभव था, लेकिन पिछले सहेज बिंदु पर जाना और वहां से आगे बढ़ना संभव था। EMNIP।
5. SupCom सहकर्मी से सहकर्मी नेटवर्क आर्किटेक्चर का पूरा उपयोग करता है
6. लाइटनिंग फोर्स, दुर्भाग्य से, संलग्न नहीं है