- 'क्लाइंट सर्वर' या 'पीयर टू पीयर' या बीच में कुछ: किस कंप्यूटर के पास कौन सी गेम क्रियाएं हैं।
बारी आधारित गेम के साथ, आमतौर पर यह कहना बहुत आसान होता है कि 'सर्वर का अंतिम अधिकार है और हम कर चुके हैं'। वास्तविक समय के खेल के साथ, अक्सर यह डिज़ाइन शुरू करने के लिए एक बेहतरीन जगह है, लेकिन जैसे ही आप विलंबता जोड़ते हैं, क्लाइंट आंदोलन/क्रियाएं उत्तरदायी नहीं होती हैं। तो आप क्लाइंट इनपुट को उस समस्या को हल करने के लिए तुरंत अपने चरित्र या इकाइयों को प्रभावित करने की इजाजत देकर 'विलंबता छिपाने' की कुछ प्रकार जोड़ते हैं, और अब जब आप क्लाइंट और सर्वर गैमेस्टेट को अलग करना शुरू करते हैं तो आपको समस्याओं को सुलझाने के साथ निपटना होगा। 9 गुना 10 बार ठीक है, आप ऑब्जेक्ट्स को आधिकारिक स्थिति पर प्रभावित करने वाले ऑब्जेक्ट्स को पॉप या लेप करते हैं, लेकिन 10 बार में से 1 तब होता है जब ऑब्जेक्ट प्लेयर अवतार या कुछ होता है, तो समाधान अस्वीकार्य है, इसलिए आप शुरू करते हैं कुछ कार्यों पर ग्राहक प्राधिकरण दें। अब आपको सर्वर पर एकाधिक गैमेस्टेट्स को मेल करना होगा, और यदि आप उस तरह की चीज़ों की परवाह करते हैं, तो किसी दुर्भावनापूर्ण क्लाइंट के माध्यम से संभावित रूप से 'धोखाधड़ी' तक स्वयं को खोलें। यह मूल रूप से है जहां हर टेलीपोर्ट/डुप्ली/जो भी बग/धोखा आता है।
बेशक आप एक मॉडल से शुरू कर सकते हैं जहां 'प्रत्येक ग्राहक के पास' ऑब्जेक्ट्स 'पर अधिकार होता है और धोखाधड़ी की समस्या को अनदेखा करता है (कुछ मामलों में ठीक है)। लेकिन अब आप गेम सिमुलेशन पर बड़े पैमाने पर असर के लिए कमजोर हैं यदि वह ग्राहक बाहर निकलता है, या यहां तक कि 'सिमुलेशन को बनाए रखने में थोड़ा पीछे आता है' - प्रभावी रूप से प्रत्येक खिलाड़ी गेम एक के प्रभाव को महसूस/महसूस कर देगा लापरवाही या अन्यथा कम प्रदर्शन करने वाले क्लाइंट के रूप में, या तो ग्राहक को पकड़ने के लिए प्रतीक्षा करने के लिए, या गैमेस्टेट को सिंक से नियंत्रित करने के रूप में।
- 'सिंक्रनाइज़' या 'asynchronus'
एक आम रणनीति सभी खिलाड़ियों को सुनिश्चित करने के लिए एक ही gamestate पर काम कर रहे हैं बस प्लेयर आदानों (की सूची पर सहमत करने में ऊपर वर्णित मॉडलों में से एक के माध्यम से है) और फिर गेमप्ले सिमुलेशन सभी मशीनों पर सिंक्रनाइज़ रूप से खेलें। इसका मतलब है कि अनुकरण तर्क को बिल्कुल मेल खाना है, या गेम सिंक से बाहर हो जाएंगे। यह वास्तव में यह लगता है की तुलना में आसान और कठिन दोनों है। यह आसान है क्योंकि एक गेम सिर्फ कोड है, और कोड एक ही इनपुट (यहां तक कि यादृच्छिक संख्या जेनरेटर) देने पर बिल्कुल वही निष्पादित करता है। यह कठिन है क्योंकि दो मामले हैं जहां यह मामला नहीं है: (1) जब आप गलती से अपने गेम सिमुलेशन के बाहर यादृच्छिक रूप से उपयोग करते हैं और (2) जब आप फ्लोट का उपयोग करते हैं। पूर्व में किस गेम सिस्टम द्वारा आरएनजी का उपयोग किया जाता है, इस पर सख्त नियम/दावा करके पूर्व को सुधार दिया जाता है। उत्तरार्द्ध फ्लोट्स का उपयोग न करके हल किया जाता है। (फ्लोट्स में वास्तव में 2 समस्याएं होती हैं, एक वे आपके प्रोजेक्ट की ऑप्टिमाइज़ेशन कॉन्फ़िगरेशन के आधार पर बहुत अलग तरीके से काम करते हैं, लेकिन अगर यह काम किया जाता है, तो वे विभिन्न प्रोसेसर आर्किटेक्चर एटीएम, एलओएल में असंगत रूप से काम करते हैं)। स्टारक्राफ्ट/वॉरक्राफ्ट और कोई भी गेम जो 'रीप्ले' प्रदान करता है, इस मॉडल का सबसे अधिक उपयोग करता है। वास्तव में, एक रीप्ले सिस्टम होने का परीक्षण करने का एक शानदार तरीका है कि आपके आरएनजी सिंक में रह रहे हैं।
एसिंक्रोनस समाधान के साथ गेम स्टेट अथॉरिटी बस कुछ सारी आवृत्ति पर सभी अन्य ग्राहकों को पूरे राज्य को प्रसारित करते हैं। ग्राहक उस डेटा को लेते हैं और स्लैम को अपने गैमेस्टेट में लेते हैं (और मानक तब तक कुछ सरल एक्सट्रापोलेशन करते हैं जब तक उन्हें अगला अपडेट नहीं मिलता)। यहां वह जगह है जहां 'udp' एक व्यवहार्य विकल्प बन जाता है, क्योंकि आप हर ~ 1sec या तो पूरे गैमेस्टेट को स्पैमिंग कर रहे हैं, तो उन अद्यतनों का कुछ अंश छोड़ना अप्रासंगिक है। उन खेलों के लिए जिनके पास अपेक्षाकृत कम गेम स्टेटस (भूकंप, वॉरक्राफ्ट की दुनिया) है, यह अक्सर सबसे आसान समाधान होता है।