लगातार ऑनलाइन गेम में खिलाड़ी की स्थिति को बचाने के लिए कितनी बार?

9

ऑनलाइन गेम में, लोग जब चाहें तब लॉग ऑन और ऑफ करना पसंद करते हैं। आमतौर पर, सर्वर पर उनकी गेम उपलब्धियों को मूल रूप से सहेजा जाता है। यह हासिल करना उतना मुश्किल नहीं है, लेकिन मैं सोच रहा हूं कि कैसे एक कुशल तरीके से किया जा सकता है जो समझ में आता है और पैमाने होगा।

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

performance browser-based-games node.js

— Lanbo
स्रोत

मैं खेल राज्य को हर 10 सेकंड में बचाता हूं। मुझे लगता है कि यह पर्याप्त है, यह किसी का ध्यान नहीं जाता (और मैं अपने नेटबुक पर अपने MMORPG सर्वर को चला रहा हूं जिसमें 512 एमबी की रैम है)।

— 23

10

मेरे मन में वर्ल्ड ऑफ़ Warcraft जैसे एक पारंपरिक MMORPG हैं।

प्रत्येक खिलाड़ी और स्वायत्त चीज़ से प्रत्येक कमांड के बाद सहेजें (जैसे एनपीसी)

लगातार बैकअप। सर्वर किसी भी समय नीचे जा सकता है, और खेल की स्थिति उस क्षण (या हाल ही में, वैसे भी) तक बच जाती है।
सर्वर के प्रदर्शन पर प्रभाव; भले ही यह नॉन-ब्लॉकिंग (यानी दूसरे धागे पर) हो, भले ही डेटाबेस दूसरे सर्वर पर हो, यह प्रोसेसिंग है कि आप अन्यथा नहीं करेंगे। यदि आप कहते हैं कि यह गैर-अवरुद्ध है, तो दूसरे धागे को इसे संभालना होगा, और यह एक ऐसा धागा है जिसे किसी और चीज़ के साथ रखा जा सकता है।
बढ़ी हुई डिस्क I / O, इस प्रकार बढ़ते जोखिम / विफलता की दर। यह विशेष रूप से एक चिंता का विषय है यदि आप भंडारण के लिए एसएसडी का उपयोग कर रहे हैं, तो उनके निचले जीवन को देखते हुए।
यदि आप डेटाबेस को दूसरे सर्वर पर लोड करते हैं, तो बैंडविड्थ में वृद्धि हुई है; यदि आप बैंडविड्थ के लिए भुगतान कर रहे हैं, तो यह एक चिंता का विषय हो सकता है, और यदि यह एक अलग नेटवर्क कार्ड पर नहीं है, तो यह उन संसाधनों को ले रहा है जिन्हें बेहतर तरीके से खिलाड़ी ट्रैफिक का उपयोग करने के लिए रखा जा सकता है।
यदि सर्वर इन कमांड की स्थिति को बचाने के लिए आगे और पीछे हो जाता है तो क्या होता है? यानी अगर अधिक कमांडों को बचाया जा सकता है, तो वे एक कतार में ढेर हो जाते हैं? क्या यह कतार अतिप्रवाह करती है और त्रुटि का कारण बनती है? क्या आप सब कुछ रोकते हैं ताकि कतार पकड़ सके?
यह मुझे लगता है कि यह दृष्टिकोण, जबकि यह सरल लगता है, सावधानीपूर्वक योजना बनाने की आवश्यकता होगी। उदाहरण के लिए, एक-दूसरे पर भरोसा करने वाले लगातार आदेशों को एक साथ सहेजने की आवश्यकता होगी; अन्यथा कमांड के बीच में एक विफलता हो सकती है, और केवल एक को बचाया जाएगा, लेकिन दूसरे को नहीं। विचार करें कि क्या दो खिलाड़ी किसी व्यापार को अंजाम देते हैं और दो कमांड डिस्क में सहेजे जाते हैं: "प्राप्तकर्ता में आइटम का 1 जोड़ें" और "प्रेषक से आइटम का 1 घटाएं"। यदि पहली कमांड के बाद विफलता होती है, लेकिन दूसरी कमांड सेव होने से पहले, आपके पास एक आइटम दोहराव है। (यदि आदेश उलटा है, तो आपके पास एक खोई हुई वस्तु है)

समय-समय पर सब कुछ बचाओ

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

लॉगआउट पर एक चरित्र सहेजें (कुछ और न सहेजें)

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

विचार बंद करना

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

अन्त में, इस सलाह को पूर्ण सत्य के रूप में न लें। मैंने मल्टीप्लेयर बैकअप सिस्टम नहीं लिखा है। मैं एक ऑनलाइन "गेम" पर काम कर रहा हूं , यही वजह है कि मैंने इस बारे में सोचा है और ऊपर अपने विचारों को लिखा है, लेकिन मैंने अभी तक इसे लागू करने के चरण में प्रवेश नहीं किया है। तो यह वास्तविक अनुभव के बिना लिखा जाता है, लेकिन बहुत सारे पढ़ने और विषय के बारे में ज्ञान एकत्र करने के बाद।

— Ricket
स्रोत

4

क्या मैं व्यक्तिगत रूप से देखा है वाणिज्यिक MMO इन तीनों का एक संयोजन का उपयोग करें। समय-समय पर महत्वपूर्ण घटनाओं और कार्यों जैसे बॉस को मारना / लूटना / व्यापार करना, गैर-महत्वपूर्ण कार्यों को याद करने से रोकने के लिए (और जो लोग लंबे समय तक लॉग इन नहीं होते हैं) को दंडित करने के बाद होते हैं, और हमेशा लॉग आउट करते हैं। एक एकल विधि आमतौर पर पर्याप्त नहीं है। इनमें से लगभग सभी विधियाँ एक अंतर्निहित SQL स्टाइल डेटाबेस पर निर्भर करती हैं, जो हार्डवेयर में खराबी होने पर पारदर्शी रूप से बैकअप और पुनर्स्थापित हो जाता है।

— NtscCobalt

@NtscCobalt - मैं "SQL स्टाइल डेटाबेस" तक आपके साथ था। क्या एसक्यूएल वास्तव में एक आवश्यकता है? NoSQL के बारे में क्या?

— बीटगैमिट

@tjameson वैसे मेरी टिप्पणी NoSQL को छूने से पहले लिखी गई थी। मैं केवल यह कहने की कोशिश कर रहा था कि आपको अपने स्वयं के प्रारूप को रोल नहीं करना चाहिए, लेकिन वैसे भी मैं एसक्यूएल की सिफारिश करूंगा क्योंकि आपको हाथ से पहले स्कीमा पता होना चाहिए (या आलसी होना चाहिए और एंटिटी-की-वैल्यू का उपयोग करना चाहिए) और संगतता की तुलना में अधिक महत्वपूर्ण है उस डेटा को विभाजन करने की क्षमता। अधिक जानकारी के लिए stackoverflow.com/questions/7339374/… देखें ।

— NtscCobalt 21

1

मुझे लगता है कि यह खेल के प्रकार पर निर्भर करता है कि खिलाड़ियों और सर्वर के बीच यातायात की मात्रा कितनी है।

एक MMORPG में, हर बार जब वे सर्वर को सूचना भेजते हैं, तो खिलाड़ियों की स्थिति को बचाने के लिए कोई मतलब नहीं होगा। जब खिलाड़ी का वर्तमान डेटा 'बासी' हो, तो उसे बोलने के लिए अद्यतन करने के लिए अधिक समझदारी होगी। नए क्षेत्र में पार करने, बॉस को हराने या स्टोर छोड़ने जैसी प्रमुख घटनाओं पर खिलाड़ी के राज्य को बचाने के लिए भी फायदेमंद हो सकता है।

टर्न-आधारित गेम में, निश्चित रूप से खिलाड़ी के राज्य को बचाने के लिए निश्चित रूप से हर बार वे अपनी बारी के साथ-साथ एक विरोधी खिलाड़ी की बारी (स्वास्थ्य हानि, जादू प्रभाव, आदि को बचाने के बाद) को समझेंगे।

फिर से, उत्तर पूरी तरह से पैमाने और आपके सर्वर की क्षमताओं पर निर्भर करता है। यह सबसे अच्छा संतुलन खोजने और गुणवत्ता का त्याग किए बिना यथासंभव अनुकूलन करने के बारे में है।

— JMellow
स्रोत

1

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

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

— Lunin
स्रोत

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

— इंजीनियर

यह बताने की समस्या कि वास्तव में एक लंबे समय तक चलने वाले ब्राउज़र गेम में खिलाड़ी कब लॉग इन करता है, वास्तव में एक तुच्छ नहीं है।

— लैंबो

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

— लूनिन नोव