टर्न-आधारित बोर्ड गेम सर्वर संदर्भ? [बन्द है]

Question

टर्न-बेस गेम सर्वर बनाने के बारे में सिफारिश करने के लिए क्या कोई अच्छा संदर्भ / किताबें हैं? यह शतरंज के खिलाड़ियों की जोड़ी बनाने और गेम स्टेट्स रखने के लिए शतरंज सर्वर जैसा कुछ है। अतीत में, उदाहरण के लिए IGS (गो, वीकी) एक सॉकेट आधारित कार्यान्वयन है। उपलब्ध समकालीन प्रौद्योगिकियां किससे सीखने के लिए हैं? धन्यवाद!

Comments

gdev फोरम पर एक संबंधित धागा है gamedev.net/topic/565319-turn-based-game-design-help

— zinking

आप निम्नलिखित गेम सर्वर डिज़ाइन से सीख सकते हैं: Developers.google.com/games/services/android/…

— tomash

Answer 1

मुझे नहीं लगता कि इस विषय में कोई विशेष पुस्तक है, क्योंकि विषय थोथा तुच्छ है।

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

युग्मन पीपीएल एलो के माध्यम से किया जा सकता है ... लेकिन मुझे लगता है कि आपको पता था कि यू

Comments

शायद तुम थोड़ा और समझा सकते हो, अंडा। मैं 'एलो' नहीं जानता

— 9

मैंने एलो प्रणाली की एक कड़ी को शामिल करने के लिए पोस्ट को संपादित किया।

— काइलोटन

Answer 2

अगर यह मैं था, मैं इसे जमीन से सॉकेट के साथ बनाऊंगा। भेजने के लिए डेटा की मात्रा बहुत कम है, और टर्न-आधारित प्रकृति थोड़ा विलंबता को अस्वीकार्य बनाती है।

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

क्या आपको किसी भी प्रकार के बीच-बीच में रिपोर्टिंग की आवश्यकता है, जैसे "प्लेयर 2 एक इकाई को स्थानांतरित कर रहा है" या "आपका प्रतिद्वंद्वी AFK हो सकता है"? यदि ऐसा है तो आप सॉकेट कनेक्शन को खुला रखना चाहते हैं।

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

संपादित करें: यदि खेल केवल 1-ऑन -1 गेम का समर्थन करता है, तो सहकर्मी से सहकर्मी कनेक्शन देखने लायक हो सकते हैं।

Answer 3

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

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