मल्टीप्लेयर रीयलटाइम Android खेल के लिए सबसे अच्छा समाधान [बंद]


11

मैं एंड्रॉइड (2-8 खिलाड़ियों) के लिए मल्टीप्लेयर रियलटाइम गेम बनाने की योजना बना रहा हूं, और मुझे लगता है कि मल्टीप्लेयर संगठन के लिए कौन सा समाधान सबसे अच्छा है:

  1. पीसी पर सर्वर बनाएं, और मोबाइल पर क्लाइंट, सभी कम्युनिकेशन सर्वर से गुजरें (क्लाइंटए -> पीसी सर्वर -> सभी ग्राहक)

  2. ब्लूटूथ का उपयोग करें, मैंने अभी तक उपयोग नहीं किया है, और मुझे नहीं पता कि ब्लूटूथ पर मल्टीप्लेयर बनाना मुश्किल है

  3. उपकरणों में से एक पर सर्वर बनाएं, और अन्य डिवाइस कनेक्ट होते हैं (नेटवर्क के माध्यम से, लेकिन मुझे नहीं पता कि NAT पर उपकरणों के साथ समस्या को हल करना मुश्किल है?)

  4. अन्य समाधान?


3
क्या आप इस पर केवल-स्थानीय खेल की योजना बना रहे हैं या क्या आप चाहते हैं कि लोग इंटरनेट पर लोगों के साथ खेल सकें? क्या आप खेलों के लिए मशीनों की मेजबानी कर रहे हैं?
तेतराड

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

जवाबों:


2

अस्वीकरण; मैंने जावा और एंड्रॉइड प्लेटफॉर्म के साथ बहुत कुछ नहीं किया है।

हालाँकि, विंडोज़ प्लेटफ़ॉर्म के साथ-साथ विंडोज़ मोबाइल प्लेटफ़ॉर्म पर '.net' भाषाओं के साथ मेरा अधिक व्यापक अनुभव यह है कि ब्लूटूथ या नेटवर्क डेटा कनेक्शन बनाने और बनाए रखने के लिए आवश्यक सभी कोड का 75-90% एक अच्छा / बनाए रखा जाता है। ओएस या पुस्तकालयों के साथ समर्थित है जिन्हें हार्डवेयर तक पहुंचने की आवश्यकता होगी।

अब तक यह भी Android के साथ सच लगता है, ओएस में ब्लूटूथ या इंटरनेट पर डेटा कनेक्शन बनाने के तरीकों के साथ-साथ संबंधित हार्डवेयर को सक्षम / अक्षम करने के साथ।

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

अन्य सही हैं कि ब्लूटूथ v2.0 / v2.1 वर्तमान में बड़े डेटा लोड का समर्थन करने में सक्षम नहीं है। यह v3.0 और उच्चतर के अंतिम प्रसार के साथ बदल जाएगा। और इस सीमा के आसपास होने के रास्ते हैं।

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

कांग्रेस: प्रत्येक खिलाड़ी वास्तव में खेल के अपने कुछ अनूठे उदाहरण खेल रहे होंगे, जो कि अन्य खिलाड़ियों के साथ जुड़े रहेंगे ताकि खेल को एक-दूसरे के साथ सिंक से बहुत दूर रखा जा सके।

CON: सहायक कोड व्यापक / जटिल हो सकता है और आप जो हासिल करना चाहते हैं उसके आधार पर अपने सिर को चारों ओर लपेटना मुश्किल हो सकता है।

प्रो: कोई केंद्रीय सर्वर या डिवाइस की आवश्यकता है! कोई $ $ $ आवश्यक नहीं।

PRO: डेटा का एक भारी आदान-प्रदान केवल तब होता है जब कोई खिलाड़ी (पुनः) शामिल होता है, या एक गेम को इनिशियलाइज़ किया जाता है। - यहां तक ​​कि यह सुनिश्चित करके भी कम किया जा सकता है कि सभी गेम उत्पन्न होने जा रहे हैं, और सभी खिलाड़ियों द्वारा उसी तरह प्रगति की जाए। संभावित रूप से ऊर्जा की खपत को कम करना जो भारी नेटवर्क उपयोग के कारण होता है।

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

मेरे पास एक पूर्ण-इन-गेम गेम इंजन को लागू करने के लिए समय का अभाव है जो इसका उपयोग करता है। मैंने जो गेम बनाए हैं, वे मोनोपॉली और यूनो जैसे गेम्स को फिर से बनाने के लिए सीमित कर दिए गए हैं, जो बहुत अच्छी तरह से काम करता है।

सबसे आसान था जिसने ऊनो का अनुकरण किया। मैं अनिवार्य रूप से एक खिलाड़ी के जीतने के बाद हारने वालों के डेक को स्टैक करता था ताकि यह सुनिश्चित हो सके कि खिलाड़ी सभी गेम जीते। उस समय का 95% + मैं यह नहीं बता सकता था कि मैं सभी के समान सटीक खेल नहीं खेल रहा था।

मैंने मास्टर ऑफ ओरियन II के समान एक गेम का निर्माण शुरू किया, लेकिन खेल खुद मेरे लिए थोड़ा बहुत था।


9

यह बहुत हद तक खेल पर निर्भर करता है, लेकिन कुछ दोस्त और मैं एक ही महीने पहले एक ही मुद्दे के बारे में सोच रहे थे, और यहाँ हमने जो निर्धारित किया है। मैं फिर से पेशेवरों और विपक्ष के मूड में हूं।

कंप्यूटर आधारित सर्वर

पेशेवरों

  • कोशिस किया है और सत्य है
  • मापनीय

विपक्ष

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

पीयर टू पीयर उनमें से एक के साथ नियंत्रण में है

पेशेवरों

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

विपक्ष

  • एक साधारण केंद्रीकृत सहकर्मी-शोधक लिखने की आवश्यकता है। (मैं एक सौ आसान लाइनों में php + mysql में मेरा किया था)
  • सर्वर फोन पर चल रहे हैं। फोन स्लो हो सकते हैं। क्या सभी टार्गेट फोन एक गेम होस्ट कर पाएंगे?
  • यदि सर्वर फोन काट दिया जाए तो क्या होगा?
  • हैकर्स के लिए क्लाइंट-सर्वर की तुलना में आसान है

ब्लूटूथ के लिए के रूप में, मैं ऊपर सहकर्मी विधि के लिए सहकर्मी के समान होने की उम्मीद करेंगे। मुझे भी नहीं लगता कि आपको NAT के साथ कोई समस्या होनी चाहिए।

EDIT : यह आपके अनुभव पर भी काफी निर्भर करता है। मैं कुछ अपेक्षाकृत छोटे क्लाइंट / सर्वर गेम लिखना शुरू करूँगा ताकि पहले नेटवर्किंग को लटका दिया जा सके। यह एक कठिन विषय है जिसे पहली बार गलत करना आसान है। तीसरी कोशिश में मुझे मेरा अधिकार मिल गया। ज्ञात पैटर्न का पालन करें, और अपने आप को कुछ बनाने की कोशिश न करें।


मुझे नहीं लगता कि यह ब्लूटूथ के माध्यम से किया जा सकता है, मुझे संदेह है कि यह प्रसारण का समर्थन करता है: AFAIK यह केवल एक एकल होस्ट को दूसरे से जोड़ता है, बहुत कम अधिकतम कनेक्शन राशि है, और धीमा है।
ओ ० '।

4

सबसे बड़ी बातों में से एक जो आपको बनाने की आवश्यकता है वह है विश्वसनीयता। फ़ोन बहुत विश्वसनीय नहीं हैं; वास्तव में, आपको शायद यह मान लेना चाहिए कि 8 खिलाड़ी के खेल में किसी के डिस्कनेक्ट होने की संभावना है (आने वाली कॉल, खराब रिसेप्शन, प्लेयर क्विट्स ...)

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

जॉन ने पारंपरिक क्लाइंट <-> सर्वर आर्किटेक्चर के पेशेवरों और विपक्षों को कवर किया। यह शायद सभी के लिए एक विश्वसनीय मल्टीप्लेयर अनुभव प्रदान करने का सबसे लचीला तरीका है।

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

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

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

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