नेटवर्किंग पोंग क्लोन

Question

मेरे पास टीसीपी सॉकेट्स, यूडीपी संचार आदि की बुनियादी बातें हैं, लेकिन वास्तविक समय के खेल के वातावरण में इन्हें लागू करने के तरीके के बारे में अधिक जानकारी नहीं मिल सकती है।

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

क्या यह यूडीपी ट्रैफ़िक की बड़ी मात्रा को स्पैम करने वाला एक बुरा है? क्या मुझे अपनी भीड़ सुविधाओं के लिए DCCP जैसी किसी चीज़ पर ध्यान देना चाहिए? या यह वास्तव में इस तरह के एक छोटे पैमाने की परियोजना के साथ एक समस्या नहीं है?

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

क्या यह बेहतर होगा कि ग्राहक अपने पैडल पोज़िशन्स को एक-दूसरे के साथ सहकर्मी से संवाद करें?

मैं ये प्रश्न पोंग के संदर्भ में पूछ रहा हूं, लेकिन यह भी दिलचस्पी है कि अन्य खेलों, या सामान्यीकृत समाधानों में इन समस्याओं को कैसे दूर किया जाएगा।

Comments

परेशान, पोस्ट करने के ठीक बाद मैंने यह देखा: gamedev.stackexchange.com/questions/249/…

— elwyn

एक और अस्पष्ट से संबंधित प्रश्न: gamedev.stackexchange.com/questions/552/…

— 1

Answer 1

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

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

गेंद की स्थिति के अपडेट को सभी ग्राहकों के बीच एक युग्मक के रूप में देखें ताकि आप ऑर्डर पैकेट से बाहर निकल सकें और यहां तक ​​कि गेंदों की स्थिति के अंतर को अधिक सटीक बना सकें (आप अतीत में एक विशिष्ट समय में स्थिति और वेग को जानते हैं ताकि आप नए को प्रक्षेपित कर सकें स्थान)।

एक पागल खेल के साथ इस मॉडल के साथ आप कई बार गेंद को पीछे की ओर ले जाते हुए देख सकते हैं या थोड़ा इधर-उधर कूद सकते हैं। लेकिन एक सभ्य कनेक्शन के साथ यह बहुत चिकनी होना चाहिए।

Answer 2

ट्रैफ़िक चिंताओं के बारे में - आप प्रति सेकंड 20-30 पैकेट प्रति से अधिक भेजने से बचना चाहते हैं। सामान्य स्थिति में, यदि आप छोटे, कम पैकेट भेजते हैं, तो आप कम विलंबता (कम) और कम पैकेट का कम मौका अनुभव करेंगे।

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

Answer 3

यह एक बहुत व्यापक प्रश्न है, लेकिन मैं महत्वपूर्ण पहलुओं को संक्षेप में बताने की कोशिश करूंगा।

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

UDP आमतौर पर किसी भी क्लाइंट / सर्वर मॉडल के लिए सही विकल्प होता है। एक सहकर्मी से सहकर्मी के खेल के लिए टीसीपी व्यावहारिक हो सकती है, लेकिन फिर भी यूडीपी एक बेहतर विकल्प हो सकता है। मूल रूप से, यूडीपी आपके लिए कम संभालती है, जिसका अर्थ है अधिक प्रयास लेकिन यह भी कि आप दोषों से कैसे निपटते हैं, इस पर अधिक नियंत्रण।

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

आप निश्चित रूप से किसी भी दिशा में "स्पैमिंग" अपडेट नहीं करना चाहते हैं। प्रति फ्रेम सर्वर से एक अद्यतन सभी की जरूरत है, और आपके सर्वर को एक निश्चित फ्रेम दर पर चलना चाहिए। जो आपके ऊपर है, लेकिन उसमें पानी में जाने की जरूरत नहीं है। एक 50ms फ्रेम (20 एफपीएस) अच्छा चिकनी खेल खेलने के लिए बहुत है। क्लाइंट पर चीजों को सुचारू रखने के लिए, आप प्रक्षेप का उपयोग करना चाहते हैं। क्लाइंट को सर्वर फ्रेम स्नैपशॉट के बीच लगातार संक्रमण होना चाहिए, यह आसानी से एक अलग प्रश्न का विषय हो सकता है।

ग्राहक अपडेट सीमित होना चाहिए, हालांकि एक फ्रेम प्रति संभवतया बहुत अधिक होगा यदि आपका ग्राहक एक सभ्य फ्रेम दर पर चल रहा है।

Answer 4

क्या आपको धोखा देने की परवाह है?

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

एक पोंग क्लोन वास्तव में थोड़ा मुश्किल है, क्योंकि अधिकांश खेलों के विपरीत आप (एक डेवलपर के रूप में) एक तरफ से हिट और दूसरे को नहीं देख कर धोखा खा सकते हैं।

सामान्यीकृत कुछ के लिए, एक तकनीक जिसके बारे में मैंने सुना है, लेकिन आवश्यक नहीं पाया है (हालांकि एक्शन गेम्स के लिए हो सकता है) अपने वास्तविक टाइमस्टैम्प के साथ कार्रवाई करना है (समय प्राप्त करें - पिंग / 2), और सर्वर रोल बैक ( स्नैप) यदि कोई पूर्व-समय की घटना आती है, और फिर बाद में कार्रवाई की जाती है। इस तरह, हर कोई स्थानीय रूप से संगत है जब तक कि अलग-अलग खिलाड़ियों की बातचीत के कारण कुछ संघर्ष न हो। एकमात्र खतरा यह है कि 'लैग बैक टाइम' की क्षमता है अगर वे एक लैगी कनेक्शन को नकली करते हैं।

Answer 5

Google मृत गणना। 4 खिलाड़ियों के लिए अपडेट भेजना महत्वपूर्ण नहीं होगा। भेजे गए डेटा की मात्रा बाइट्स के आदेश पर होने वाली है। तो, इसका मतलब है कि लगातार अपडेट ठीक होना चाहिए। मृत रेकिंग के साथ, आप खिलाड़ी को क्लाइंट और सर्वर पर ले जाते हैं। सर्वर अथॉरिटी है। जब क्लाइंट की स्थिति सर्वर से सिंक से बहुत दूर हो जाती है, तो इसे वापस संरेखण में बहाव करना पड़ता है। http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking यूडीपी का उपयोग करने का तरीका है। Bupdates को अक्सर भेजा जाएगा कि खोए हुए डेटा को जल्द ही आने वाले डेटा से बदल दिया जाएगा। टीसीपी का पैकेट रीट्रांसमीटर खिलाड़ी की स्थिति के लिए इसके लायक नहीं है। क्लाइंट और सर्वर को सिंक्रोन पर कैसे रखें के बारे में अधिक जानकारी के लिए इस लेख को देखें।

Comments

-1, कम सामग्री और यह [वर्तमान में] गलत वर्तनी है। यह मृत गणना है ।

— टेट्राद

मेरे डाउनवोट को हटा दिया।

— टेट्राद

Answer 6

मैंने कुछ हफ़्ते पहले एक 2-खिलाड़ी-स्थानीय-नेटवर्क-पोंग गेम को प्रोग्राम किया है, यहाँ मैंने यह कैसे किया:

-एक पक्ष एक सर्वर खोलता है, दूसरा एक स्वचालित रूप से जोड़ता है-वे दोनों अपने पैडल एक्स स्थिति को एक दूसरे के @ 60fps या उससे कम [UDP] की ओर स्पैमिंग कर रहे हैं-एक पक्ष गेंद को नए वेग और स्थिति के बारे में तय करने वाली गेंद को हिट करता है और उसे भेजता है दूसरे एक [टीसीपी] के लिए गेंद पैडल के ऊपर से उड़ती है, जो खिलाड़ी चूक गया, वह एक दूसरे को वृद्धि स्कोर संदेश के साथ संपर्क करता है और गेंद को रीसेट किया जाता है [टीसीपी] - गेंद हर समय स्वतंत्र रूप से सिम्युलेटेड हो रही है, जो पोंग की सरल गेंद भौतिकी के अनुरूप है

यह 60fps पर लगभग 0.3 से 0.5 केबीटी / ट्रैफ़िक बनाता है और खिलाड़ियों को उनकी धारणा में कोई अंतराल नहीं है, लेकिन केवल अगर पिंग एक निश्चित सीमा से नीचे है, क्योंकि गेंदों को नए स्थान पर स्थानांतरित करने की आवश्यकता है।

इस प्रणाली के साथ धोखा करना आसान है और बहुत ही हानिपूर्ण कनेक्शन के साथ सिंक से बाहर जाने की उच्च संभावना है, लेकिन कौन पांग में धोखा देने की परवाह करता है ?!