नेटवर्क 2 डी गेम के साथ अंतराल मुआवजा


31

मैं एक 2 डी गेम बनाना चाहता हूं जो मूल रूप से एक भौतिकी संचालित सैंडबॉक्स / गतिविधि गेम है। हालांकि ऐसा कुछ है जो मुझे वास्तव में समझ में नहीं आता है। अनुसंधान से, ऐसा लगता है कि सर्वर से अपडेट केवल प्रत्येक 100ms के बारे में होना चाहिए। मैं देख सकता हूं कि एक खिलाड़ी के लिए यह कैसे काम करता है क्योंकि वे सिर्फ समवर्ती भौतिकी का अनुकरण कर सकते हैं और प्रक्षेप के माध्यम से क्षतिपूर्ति कर सकते हैं।

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

मूल रूप से यह शूटिंग और उस तरह के सामान के लिए कैसे काम करता है?

धन्यवाद

जवाबों:


58

उन लोगों के लिए सारांश जो लंबे उत्तर पसंद नहीं करते ...

यह किया जा सकता है, लेकिन अगर कोई विलंबता हो तो सही मल्टीप्लेयर भौतिकी करना असंभव है । क्यों विलंबता प्रभाव भौतिकी को समझाया जाता है, और फिर आपके भौतिकी सिमुलेशन पर विलंबता के प्रभाव को कम करने के लिए सुझाव दिए जाते हैं।


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

समस्या यह है कि भौतिक विज्ञान को यथार्थवादी होने के लिए तेज और उत्तरदायी होना चाहिए, लेकिन साथ ही साथ सभी कारकों के संयुक्त कार्यों के आधार पर गणना करना होगा - जिसका अर्थ है सभी खिलाड़ियों की संयुक्त कार्रवाई। और अगर वहाँ विलंबता है, यह वास्तविक समय में नहीं किया जा सकता है।

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

यह दिखाने के लिए कि कैसे चीजें गड़बड़ हो सकती हैं

एक ऐसे खेल की कल्पना करें जहां दो खिलाड़ी (क्लाइंट) एक सर्वर से जुड़े हों। क्लाइंट से सर्वर तक इंटरनेट पर जाने के लिए एक संदेश के लिए 100 मिलीसेकंड (1/10 वां सेकंड) लगता है। जब कोई खिलाड़ी कुछ करता है, तो सर्वर को संदेश भेजा जाता है कि उन्होंने क्या किया है। सर्वर तब संदेश को अन्य खिलाड़ियों के लिए प्रसारित करता है ताकि वे सभी जान सकें कि अभिनय खिलाड़ी ने क्या किया।

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

आइए इसे संभालने के विभिन्न तरीकों पर गौर करें और इसके क्या परिणाम होंगे ...

क्या होगा यदि भौतिकी की गणना सिर्फ सर्वर पर की जाए?

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

लेकिन समस्या यह है कि खिलाड़ी के क्रेट प्रतिक्रिया को देखने से पहले यह एक सेकंड का 2/10 वां होगा। दोनों खिलाड़ियों के संदेश सर्वर तक पहुंचने के लिए सेकंड का 1/10 वां हिस्सा लेते हैं, फिर सर्वर गणना के परिणाम के लिए एक सेकंड का 1/10 वां भाग दोनों खिलाड़ियों के लिए भेजा जाता है।

निचला रेखा, लम्बी गेमप्ले।

क्या होगा अगर भौतिक विज्ञान की गणना सिर्फ ग्राहक पर की जाए?

मान लीजिए कि हमारे पास केवल क्लाइंट पर गणना की गई भौतिकी है। आइए इसे प्लेयर ए के दृष्टिकोण से देखें। प्लेयर ए हिट करता है और यह तुरंत उनकी दिशा में जाने लगता है। सर्वर को एक संदेश भी भेजा जाता है कि प्लेयर A ने क्या किया है।

हालांकि उसी समय, बी ने अपना हिट किया और क्रेट को अपनी दिशा में जाते हुए देखा और सर्वर को एक संदेश भेजा कि उन्होंने क्या किया है।

2/10 सेकंड के बाद, सर्वर से क्लाइंट के लिए एक संदेश आता है। A को B ने क्या किया, और B को A ने क्या किया है, बताया जाता है। समस्या यह है कि दोनों ग्राहकों का कहना है, "वैसे खिलाड़ी X ने इस मौके पर हिट किया हो सकता है, लेकिन उस स्थान पर अब कोई टोकरा नहीं है, इसलिए उनके हिट ने कुछ नहीं किया।"

लब्बोलुआब यह है कि, सिंक से बाहर दो गेम और खिलाड़ियों को साझा अनुभव नहीं है। यदि वे दोनों अलग-अलग चीजें देखते हैं तो मल्टीप्लेयर की बात क्या है?

क्या होगा अगर भौतिक विज्ञान की गणना क्लाइंट और सर्वर दोनों पर की जाए?

इस मामले में, भौतिकी की गणना क्लाइंट पर की जाती है, इसलिए खिलाड़ियों को तत्काल नो-लैग प्रतिक्रिया दिखाई देती है, लेकिन यह सर्वर पर भी गणना की जाती है, इसलिए यह सभी खिलाड़ियों के लिए "सही" है।

दोनों खिलाड़ियों ने अपने-अपने निर्देशन में टोकरा मारा और प्रत्येक ने केवल अपने हिट के आधार पर टोकरा चाल को देखा। लेकिन फिर 2/10 सेकंड के बाद, सर्वर वापस आता है और कहता है, "वास्तव में, आप दोनों गलत हैं। टोकरा इस तरह से चला गया।" अचानक दोनों खिलाड़ियों को टोकरा काफी हद तक दिशाओं को बदलता है और एक नए स्थान पर गड़बड़ करता है।

निचला रेखा एक गड़बड़ खेल है।

निष्कर्ष

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

मल्टीप्लेयर गेम को अच्छी तरह से चलाने के लिए आप जो चीजें कर सकते हैं

साधारण टकराव की मात्रा का उपयोग करें। जब एक सरल घन आकार कर देगा, तो भौतिकी के साथ आकृति के हर विवरण को परेशान न करें। एक स्पाइकी बॉल को भौतिकी के लिए स्पाइकी बॉल के रूप में तैयार नहीं किया जाता है। इसके बजाय इसे एक क्षेत्र के रूप में मॉडल करें।

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

सक्रिय भौतिकी वस्तुओं की संख्या कम रखने के लिए केवल भौतिक विज्ञान वस्तु होने की आवश्यकता होने पर ही वस्तुओं को भौतिक वस्तुएं बनाएं।

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

खिलाड़ियों को किसी तरह की स्थिति को एक साथ स्थापित करने की अनुमति दें, और फिर कुछ क्यू पर, भौतिकी दोनों खिलाड़ियों के लिए सिम्युलेटेड है और दोनों अपने संयुक्त कार्यों का परिणाम देखते हैं। जब तक यह पूरा न हो जाए, खिलाड़ी अनुक्रम में हस्तक्षेप नहीं कर सकते।

अलग-अलग खिलाड़ियों के फिशिक्स ताकि वे एक-दूसरे के साथ हस्तक्षेप न कर सकें। यह गेंदबाजी या पूल जैसे खेल के लिए बहुत अच्छा होगा, जहां एक समय में केवल एक खिलाड़ी का नियंत्रण होता है, या प्रत्येक खिलाड़ी का अपना "सैंडबॉक्स" होता है (जैसे बॉलिंग लेन)।

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

परिशिष्ट: शूटिंग के खेल इसके साथ कैसे निपटते हैं

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

एक ऐसे परिदृश्य की कल्पना करें जहां खिलाड़ी ए शूट खिलाड़ी बी। आपका विशिष्ट शूटर गेम कुछ ऐसा करेगा ...

  1. ए स्थानीय रूप से गणना करेगा यदि वे बी को मारते हैं, और अगर ऐसा लगता है कि कोई हिट है, तो यह रक्त पफ की तरह "हिट" प्रभाव निभाता है। यह क्लाइंट की ओर से किया जाता है ताकि खिलाड़ी तुरंत उनकी कार्रवाई पर प्रतिक्रिया देखे। यदि आप ऐसा नहीं करते हैं, तो खेल में कमी महसूस होती है।
  2. एक सर्वर को एक संदेश भी कहता है, "मैंने इस वेक्टर के साथ शूटिंग की है"
  3. जब सर्वर को संदेश मिलता है, तो यह दिखता है कि आईटी को लगता है कि खिलाड़ी कहां हैं, और फैसला करता है कि क्या ए का शॉट वेक्टर बी से टकराता है।
  4. यदि सर्वर ए हिट बी तय करता है, तो यह तय करता है कि बी हिट है, और बीओटीएच ग्राहकों को संदेश भेजता है कि क्या हुआ।
  5. यदि सर्वर तय करता है कि A ने B को नहीं मारा, तो B ठीक है, और A "मिस" है। यह ए की तरह लग सकता है जैसे उन्होंने मारा ("मैंने रक्त कश देखा!") लेकिन यह सर्वर कॉल है कि वे चूक गए।

तो ए बी को कैसे याद कर सकता है जब ऐसा लगता है कि वे उन्हें मारते हैं? क्योंकि B स्थानांतरित हो सकता है, लेकिन A ने इसे अभी तक नहीं देखा है क्योंकि सर्वर ने क्लाइंट को अभी तक "B यहाँ ले जाया गया" संदेश नहीं भेजा है।

इस बारे में उनकी साइट पर वाल्व का एक अच्छा राइटअप है। Http://developer.valvesoftware.com/wiki/Source_Multeps_Networking देखें


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

1
आप वापस जाना चाहते हैं और मेरी पोस्ट को फिर से पढ़ना चाहते हैं। मेरे हिस्से के सामने के छोर पर कुछ राय देते हुए, मैं ठीक उसी तरह का वर्णन कर रहा हूं जैसे कई खिलाड़ियों के साथ भौतिकी सिमुलेशन में होता है - जिसमें आपके गैरी के मॉड गेम सत्र शामिल हैं। आप तथ्यों के आसपास नहीं पहुंच सकते।
टिम होल्ट

2
ठीक है, मैंने अपने चढ़ाव को एक अपवोट में बदल दिया। लेकिन आप भौतिकी के साथ मल्टीप्लेयर गेम के लिए एक बहुत ही नकारात्मक तस्वीर पेंट करते हैं, जब यह वास्तव में पहले और अपेक्षाकृत गड़बड़ मुक्त किया गया है।
अटैकिंगहोबो

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

1
+1 के लिए "टूटी भौतिकी कानूनों या कुछ के साथ एक गड़बड़ ब्रह्मांड में होने के बारे में एक कहानी की कल्पना करें"।
पेट्रीक कज़ाचर्सकी

13

मैंने यहां इस विषय के बारे में लेखों की एक श्रृंखला लिखी है: http://www.gabrielgambetta.com/fpm1.html

पहले तीन लेख विषय, ग्राहक पक्ष की भविष्यवाणी, सर्वर सामंजस्य, और इकाई प्रक्षेप से परिचय के साथ सौदा करते हैं (यह वह हिस्सा है जो आपके विशिष्ट प्रश्न का उत्तर देता है)। 4 वें लेख (जल्द ही आ रहा है) "शूटिंग सामान" से निपटेंगे :)

टिम होल्ट का जवाब बहुत ज्यादा है। मेरे लेखों में कुछ ऐसे चित्र हैं जो आपको यह समझने में मदद कर सकते हैं कि क्या चल रहा है, लेकिन टिम और मैं मूल रूप से एक ही बात कह रहे हैं।


अच्छी चीजें ggambett!
टिम होल्ट

2
इतने सारे खिलाड़ी यह नहीं समझते हैं कि यह सामान कैसे काम करता है, लेकिन शाश्वत को समझने के लिए यह बहुत महत्वपूर्ण है, "डब्ल्यूटीएफ मुझे क्यों याद आया?" सवाल।
टिम होल्ट

या "मेरे चरित्र को एक विशाल रबर बैंड के साथ उस कॉलम से क्यों जोड़ा गया है?" एक गिरा कनेक्शन पर :)
ggambett

वाल्व के विकी में एक राइटअप है जो इन मुद्दों में भी जाता है। डेवलपर
टिम होल्ट

1
मुझे लाइव डेमो बहुत पसंद है। क्या हो रहा है इसकी कल्पना करने का एक शानदार तरीका।
रिचर्ड मार्स्केल - Drackir

2

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


0

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

एक अच्छा पद और बेहतर उत्तर मिल सकता है:

नेटवर्क गेम कैसे लिखें?


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.