हास्केल में गेम इंजन और नेटवर्क सर्वर को सिंक्रनाइज़ करने के लिए कैसे करें?

Question

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

हर 20ms या तो के लिए

याम्पा/Reactimate क्लाइंट-सर्वर संचार के लिए

• Happstack उपयोग करना चाहते हैं, ग्राहक कीबोर्ड और माउस भेजना चाहिए HTTP GET के माध्यम से सर्वर पर ईवेंट, वर्तमान गेम स्थिति (JSON-encoded गेंद और प्लेयर स्थिति) प्राप्त करें और इसे प्रस्तुत करें। मैं खेल लूप, इनपुट हैंडलिंग और प्रतिपादन के लिए एसडीएल आधारभूत संरचना का उपयोग करने के बारे में सोच रहा हूं।

  सर्वर मूल रूप से दो धागे चलाता है: एक happstack सर्वर HTTP GET प्राप्त करता है, कुंजीपटल/माउस कमांड को कतार में रखता है, दूसरी पंक्ति से वर्तमान गेम स्थिति पढ़ता है और HTTP GET अनुरोध का उत्तर देता है।

  दूसरा धागा Yampa Arcade paper में वर्णित एक यम्पा गेम इंजन चलाता है: गेम इंजन जितनी जल्दी हो सके नए दौर की गणना करता है (कोई टिक नहीं) और परिणाम को रेंडर कतार में डाल देता है।

  

  जनरल प्रश्न: यह एक व्यवहार्य वास्तुकला की तरह लग रही है?

  विशिष्ट प्रश्न: कैसे एक सर्वर पक्ष प्रतिपादन कतार डिजाइन करेगा: क्या कोई इस के लिए चैन का उपयोग करेगा? यदि गेम इंजन क्लाइंट साइड पर "टिकिंग" की तुलना में औसत पर तेज है, तो कतार लंबी और लंबी हो जाएगी। चैन के साथ इसे कैसे संभाला जा सकता है?

  आपकी टिप्पणियां बहुत स्वागत है!

Answer 1

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

मुझे यह भी समझ में नहीं आता कि आप इस तरह के गेम (उस मामले के लिए कोई भी गेम) के लिए HTTP का उपयोग क्यों करना चाहते हैं, लगभग सभी गेम यूडीपी का उपयोग करते हैं और मैं शायद इस प्रकार के गेम के लिए इस मार्ग से नीचे जाऊंगा। This tutorial उस तरह की चीजों के बारे में सीखने के लिए बहुत अच्छा लग रहा है।

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

याम्पा & सर्वर साइड प्रतिपादन के बारे में, तो मैं सबसे नेटवर्क खेल लगता है कि हम खेल तर्क & संस्थाओं को लागू करने के साधन के रूप में खेल के संदर्भ में एफ आर पी के बारे में सोच सर्वर & ग्राहक संस्थाओं की है।आम तौर पर प्रस्तुत करने योग्य ऑब्जेक्ट्स क्लाइंट इकाइयां हैं और गैर-प्रस्तुत करने योग्य सर्वर इकाइयां हैं, और मुझे लगता है कि कुछ इकाइयों का प्रतिनिधित्व दोनों पर होता है। तो उस स्थिति में आप संभवतः क्लाइंट पक्ष दोनों सर्वर & पर चल रहे Yampa चाहते हैं और मैं सर्वर-साइड पर प्रतिपादन से संबंधित किसी भी चीज़ से बचने का प्रयास करूंगा। प्रस्तुत करने योग्य वस्तुओं को मुख्य रूप से उस ग्राहक पक्ष से चिपकना चाहिए जो मेरा मानना ​​है। क्या कोई विशिष्ट कारण है कि आप सर्वर से आने वाले आदेश प्रस्तुत करना चाहते हैं?

Answer 2

आप ही कभी नवीनतम खेल राज्य देने के लिए चाहते हैं, एक चान या एक कतार का उपयोग नहीं करते, एक samplevar का उपयोग करें: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent-SampleVar.html

Answer 3

मामले में आप रुचि रखते हैं, मैं भी एक ऐसी ही सर्वर-ग्राहक लिखा रहे हैं एक बार हास्केल में आधारित सॉकर गेम। आप github (server, client) पर स्रोत कोड पा सकते हैं। चूंकि मैं काफी हस्सेल शुरुआत करने वाला था, फिर भी, मैंने थ्रेडिंग (और blogged about them) के बारे में कुछ समस्याओं में भाग लिया और वास्तव में परियोजना को कभी भी समाप्त नहीं किया, लेकिन आप कम से कम कोड से यह देख सकते हैं कि इसे कैसे नहीं किया जाए। (अंत में मैंने सर्वर-क्लाइंट आर्किटेक्चर को हटा दिया और freekick2 लिखा।) मुझे लगता है कि आर्किटेक्चर स्वयं व्यवहार्य है।

हालांकि, जैसे snk_kid लिखते हैं, मुझे नहीं पता कि आप HTTP का उपयोग क्यों करना चाहते हैं। बिना किसी (ध्यान देने योग्य) विलंबता के नेटवर्क पर चलने के लिए, आपको शायद यूडीपी के साथ-साथ क्लाइंट साइड भविष्यवाणी (here's कुछ सूचनात्मक सामग्री) का उपयोग करना होगा।