एमएमओआरपीजी क्लाइंट/सर्वर कोडिंग

Question

एमएमओआरपीजी क्लाइंट/सर्वर संचार में यूडीपी और टीसीपी प्रोटोकॉल का उपयोग कैसे किया जाता है?

उदाहरण के लिए:

करता है ग्राहक प्रसारण (प्लेयर की स्थिति, आदि) यूडीपी के माध्यम से सर्वर के लिए? या ठीक इसके विपरीत?

या यह टीसीपी का उपयोग करने की तरह है जहां ग्राहक अनुरोध करता है कि सर्वर प्लेयर को स्थानांतरित करे। सर्वर अनुरोध प्राप्त करता है, खिलाड़ी को ले जाता है और क्लाइंट को वापस भेजता है कि खिलाड़ी अब xyz स्थिति पर है?

चैट चैनलों को टीसीपी का उपयोग करके लागू किया जाना चाहिए?

क्या इस पर कोई अच्छा लेख/पुस्तकें हैं? मुझे बिट्स और टुकड़े मिल गए हैं लेकिन ऐसा लगता है कि असली मांस और आलू अनुभव से जीते हैं।

Answer 1

वायरसहार्क स्थापित करके और यातायात को देखकर आपके आधे प्रश्न (परिवहन परत प्रोटोकॉल का उपयोग) का जवाब दिया जा सकता है।

Answer 2

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

Answer 3

आपकी सर्वश्रेष्ठ शर्त शायद प्लेशेशिफ्ट के नेटवर्किंग कोड पर नज़र डालने के लिए है, यह एक ओपन सोर्स एमएमओ है। मेरा मानना ​​है कि यह दृश्य पर सबसे विकसित है (आखिरी बार मैंने देखा)।

Answer 4

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

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

वैसे भी, यूडीपी और टीसीपी का संयोजन उचित होगा - आपको बस खुद से पूछना होगा, "क्या मुझे विश्वसनीयता या गति चाहिए?"

Answer 5

कई अलग-अलग संभावित कार्यान्वयन हैं, लेकिन अधिकांश भाग के लिए, वे इस तरह दिखेगा। इस पैटर्न को गेम दुनिया में लगभग किसी भी कार्रवाई के साथ दोहराया जाता है।

1. क्लाइंट उस सर्वर से संचार करता है जिसे खिलाड़ी स्थानांतरित करना चाहता है।
2. क्लाइंट उस खिलाड़ी के अनुसार आगे बढ़ता है जो यह सोचता है कि क्या होना चाहिए।
3. सर्वर मान्य करता है कि चाल कुछ ऐसा हो सकता है जो खिलाड़ी के स्थान को दिया जा सके।
4. सर्वर क्लाइंट को अद्यतन करता है कि प्लेयर कहां से संबंधित है जहां तक ​​खिलाड़ी संबंधित है।
5. क्लाइंट सर्वर की विश्वस्तरी को प्रतिबिंबित करने के लिए खिलाड़ियों की स्थिति अपडेट करता है।

Answer 6

आपको Project Darkstar में रुचि हो सकती है। यह एक ओपन सोर्स एमएमओ ढांचा है।

Answer 7

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

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

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

Answer 8

मुझे नहीं लगता कि इस प्रश्न का एक संक्षिप्त उत्तर है, यह अपने दायरे में काफी व्यापक है। फिर भी, कुछ बिंदु:

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

Gamasutra में नेटवर्किंग के बारे में लेख हैं, लेकिन मेरे पास अभी कोई लिंक आसान नहीं है। निश्चित नहीं है कि वे अभी भी खुले तौर पर उपलब्ध हैं, क्षमा करें।

Answer 9

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

1. Unrea Networking Architecture
2. The Croquet Project

टिम स्वीनी के दस्तावेजों को जिस तरह से मैं प्रोग्रामिंग के बारे में सोचा बदल दिया। मैं उन्हें पर्याप्त सिफारिश नहीं कर सकता।