Mmorpg डेटा कैसे स्टोर करता है?

Question

मैं अपने server.exe में sql डेटाबेस का उपयोग करना चाहता हूं।

1000 उपयोगकर्ताओं को ऑनलाइन कहने देता है। और जब वे खेलते हैं तो खिलाड़ी अपना डेटा बदल देंगे। और सर्वर को इन अपडेट को सहेजने की आवश्यकता है।

पर कैसे ?

मुझे लगता है कि दो तरीके हैं:

1) सर्वर रन टाइम पर रैम में सेव करेगा और कभी-कभी या प्रति घंटा सर्वर रैम से एसक्यूएल डेटाबेस में डेटा (अपडेट) लिखेगा। लेकिन अगर बिजली चली जाए या किसी तरह सर्वर बंद हो जाए, तो अपडेट नहीं होंगे। बेशक मैं अद्यतन खोना नहीं चाहता।

2) सर्वर रन टाइम में डेटाबेस में अपडेट सेव करेगा। लेकिन गति का क्या होगा? मैंने एक तरीका सोचा। मैं आपको छवि के साथ नीचे दिखाऊंगा। क्या मैं इस विधि से 1000 ऑनलाइन खिलाड़ियों के लिए पर्याप्त गति प्राप्त कर सकता हूं?

Comments

क्या आपने कोई बेंचमार्क किया है? आपको क्या लगता है कि डेटाबेस संचालन आपके खेल के लिए एक मुद्दा होगा?

— कॉंगसबोंगस

यदि आपका खेल राज्य वास्तव में संबंधपरक है? क्या आप वाकई SQL डेटाबेस चाहते हैं?

— मोनिका

कृपया यह भी पढ़ें कि हैश का उपयोग करके पासवर्ड कैसे संभालें। या कम से कम उपयोगकर्ता को सूचित करें कि उनके पासवर्ड को सादे पाठ के रूप में सहेजा जा रहा है, इसलिए वे दूसरे सुरक्षित पासवर्ड का उपयोग नहीं करने के बारे में जानते हैं।

— टॉमटैगक

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

— निधि मोनिका का मुकदमा

आप एक सामान्य API लिख सकते हैं जो स्टोरेज एग्नॉस्टिक है। फिर एक एडेप्टर लिखिए जो देरी से स्टोरेज के लिए रैम में डेटा को कैश करता है। या आप एडाप्टर को लिख सकते हैं जो डेटा को अस्थायी फ़ाइल में SQL DB में फ्लश करने से पहले लिखता है। इस तरह से आप यह पता लगाने के लिए कैशिंग चालू और बंद कर सकते हैं कि कौन सबसे अच्छा है। यदि आपको अपना आर्किटेक्चर सही बनाया गया है, तो आपको बहुत अधिक अतिरिक्त कोड लिखने की आवश्यकता नहीं है।

— 0xC0DEGURU

Answer 1

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

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

आमतौर पर, मुख्य मेमोरी के रूप में SQL सर्वर का उपयोग करना अप्रिय रूप से धीमा (और बोझिल) होने वाला है। मुझे आपके प्रस्ताव में पर्याप्त विस्तार नहीं दिखाई दे रहा है, यह सुनिश्चित करने में सक्षम होने के लिए कि यह केवल लगभग 1000 खिलाड़ियों के लिए काम करेगा - यह शायद ठीक होगा। लेकिन मुझे विश्वास नहीं होता कि आप इसे आक्रामक रूप से ढाल सकते हैं।

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

मैं आपको पहले दृष्टिकोण के साथ जाने की सलाह दूंगा।

Comments

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

— मतलब

"रीस्टार्टेबल सेव क्वे" ध्वनियों को एक जर्नल की तरह, कई फाइल सिस्टम और डेटाबेस इंजन द्वारा कार्यान्वित किया जाता है?

— विशाल

इन मुद्दों पर MMOs, या यहाँ तक कि वीडियो गेम, लिए अद्वितीय नहीं हैं सब पर । लगभग हर ओआरएम अस्तित्व में किसी न किसी तरह के कैशिंग / बैचिंग तंत्र प्रदान करता है। अपने स्वयं के समाधान को रोल करने की कोई आवश्यकता नहीं है।

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

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

— जॉन

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

— मार्क

Answer 2

1000 खिलाड़ी एक समस्या हो सकती है या नहीं। यह इस बात पर निर्भर करता है कि आपको डेटाबेस को कितनी बार अद्यतन करने की आवश्यकता है। हालाँकि एक सरल उपाय है: डेटाबेस को अपने सर्वर पर रखें।

---

मेरे पास एक झलक थी कि डेटाबेस सिस्टम एक गेम कैसे काम करता है जिसे लोग एक MMO- लाइट कहते हैं - जिसे मैं खुलासा नहीं करूंगा - फिर भी मैं यह बता सकता हूं कि इसमें लगातार 1000 से अधिक खिलाड़ी हैं, यह सार है:

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

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

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

---

चरित्र का डेटा क्लाइंट और सर्वर दोनों पर मौजूद है, और सिस्टम को सिंक में रखने के लिए डिज़ाइन किया गया है, दोनों तरफ एक ही ऑपरेशन कर रहा है।

अब, जब कोई खिलाड़ी सिस्टम के साथ लेन-देन करता है - कहते हैं कि NPC या समान के माध्यम से दूसरे के लिए एक आइटम का आदान-प्रदान करें - इसके ये चरण हैं:

• क्लाइंट जाँचता है कि क्या ऑपरेशन वैध है
• क्लाइंट सर्वर को ऑपरेशन भेजता है (async ऑपरेशन)
• क्लाइंट अपने मॉडल को रैम में अपडेट करता है
• यदि ऑपरेशन मान्य है, तो सर्वर जाँच करता है
• सर्वर रैम में अपने मॉडल को अपडेट करता है
• सर्वर डेटाबेस (async ऑपरेशन) को अपडेट करता है
• सर्वर क्लाइंट को बताता है कि परिवर्तन हुआ

नोट :

• डेटाबेस अद्यतन, हालांकि async, तुरंत किया जाता है। यदि किसी कारण से गेम सर्वर नीचे चला जाता है, तो बहुत कुछ खो नहीं जाता है।
• डेटाबेस को अपने सर्वर पर रखने के लिए प्रदर्शन में गिरावट कोई बड़ी बात नहीं है।

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

---

कभी-कभी कुछ गलत हो जाता है, इसके दो संभावित परिणाम हैं:

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

किसी भी स्थिति में, क्लाइंट को त्रुटि के बारे में पता है, और वह उस सभी के साथ लॉग करेगा जो खिलाड़ी कर रहा था। क्लाइंट साइड लॉगिंग हर समय हो रहा है। फिर, लॉगआउट पर, यदि कोई त्रुटि थी, तो क्लाइंट लॉग को सर्वर पर भेजता है।

---

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

Comments

धन्यवाद, लेकिन क्या खिलाड़ियों के बारे में उदाहरण के लिए आंदोलनों, अगर एक खिलाड़ी अपने वर्तमान स्थिति से चलता है: x:10,y:10,z:10करने के लिए x:11,y:11,z:11, यह डेटाबेस में तुरंत बचाया जाना चाहिए? क्या होगा अगर खिलाड़ी चलता रहता है, इसका मतलब है कि हम उसकी वर्तमान स्थिति को हर 1sec या उससे कम पर सहेजते हैं, और यदि हजारों खिलाड़ी हैं, तो हर सेकंड DB को लाखों प्रश्न मिलते हैं। यह कैसे काम करता है?

— dwix

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

— निको

@dwix खेल के मामले में मैं बात करता हूं, खिलाड़ी की स्थिति भी नहीं बची है। यदि आप लॉग आउट करते हैं और लॉग इन करते हैं, या यदि सर्वर नीचे चला जाता है, तो खिलाड़ी को सुरक्षित ज्ञात स्थिति में वापस रखा जाएगा (संपादित करें: यदि आप चाहें तो यह एक निजी उदाहरण है, "घर" है, लेकिन यह सभी के लिए समान है)। हालांकि, कुछ खेल खिलाड़ी की सटीक स्थिति को बनाए रखते हैं, यहां तक ​​कि आकस्मिक वियोग के दौरान भी। ऐसा करने के लिए, सामान्य aproach उस जानकारी को कम अक्सर स्टोर करता है। भले ही, आप वह नहीं करते जो सर्वर डेटाबेस पर प्रतीक्षा कर रहा है।

— थरोट

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

— थरोट

@dwix मतलब की टिप्पणी

— थरोट

Answer 3

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

ईवीई ऑनलाइन एक MMO का उदाहरण है जहां सब कुछ एक SQL डेटाबेस में संग्रहीत किया जाता है। मुझे लगता है कि यह लगभग 60,000 एक साथ उपयोगकर्ताओं के साथ चरम पर था, और लोड के साथ बनाए रखने के लिए पिछले कुछ वर्षों में डेटाबेस सर्वरों के लिए कुछ महंगे हार्डवेयर समर्पित करना पड़ा। हालांकि ईवीई प्रति MMORPGs की तुलना में प्रति उपयोगकर्ता बहुत अधिक डेटा संग्रहीत करता है और इसमें बहुत अधिक लगातार और विविध लेनदेन होते हैं। डेटाबेस के एसीआईडी ​​गुण पूरे विशाल और जटिल डेटाबेस को हमेशा एक सुसंगत स्थिति में रखने की अनुमति देता है।

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

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

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

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

अपनी परियोजना के लिए आप शायद किसी भी तरह से जा सकते हैं। एक साथ 1000 उपयोगकर्ता होने से शायद इन दिनों एक SQL सर्वर एक कमोडिटी पीसी पर क्या काम कर सकता है, इसकी सीमा को आगे नहीं बढ़ाएगा, लेकिन बहुत कुछ लेनदेन की प्रकृति पर निर्भर करेगा। यदि आप SQL और रिलेशनल डेटाबेस डिज़ाइन से परिचित हैं तो यह आपके लिए काम कर सकता है। आप जितना संभव हो सके लेन-देन को कम से कम करना चाहते हैं, खिलाड़ी वर्तमान हिटपॉइंट जैसी कुछ चीज़ों के लिए आप केवल समय-समय पर उन्हें डेटाबेस में सहेजना चाहते हैं क्योंकि इन जैसे आँकड़ों के लिए संगत होना आवश्यक नहीं है। (PvP खेल में वे हालांकि हो सकता है ...) डेटाबेस में राक्षस एचपी जैसी चीजों को बिल्कुल भी संग्रहीत न करें, अधिकांश खेलों में केवल खिलाड़ी से संबंधित डेटा लगातार है।

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

Answer 4

विभिन्न खेल विभिन्न तरीकों से चीजों को संग्रहीत करते हैं। अक्सर, गेम कंपनियां ऐसा करने के लिए कोई रास्ता बनाती हैं, और उनके अधिकांश गेम उसी तरह का उपयोग करते हैं। बेशक, विभिन्न स्टूडियो अक्सर अलग-अलग तरीकों का उपयोग करते हैं। SQL का उपयोग निश्चित रूप से गेम के लिए किया जाता है, जैसे कि CCP (EVE) में SQL सर्वर का नेटवर्क होता है (या कम से कम), मुझे यकीन नहीं है कि अब वे इसे कैसे करते हैं। अन्य, बस बहुत सारी फ़ाइलों का उपयोग करें।

शायद विभिन्न गेम डेटा लेनदेन को संभालने के लिए अज्ञेय "डेटा ब्रोकर तंत्र" बनाने से शुरू करें? चूंकि आप किसी भी तरह से परीक्षण कर रहे हैं, इसलिए एक ऐसा तंत्र बनाएं जो आपको खेल के दृष्टिकोण से भंडारण के बारे में बहुत अधिक देखभाल करने की आवश्यकता नहीं है। मतलब, होस्ट एप्लिकेशन से कैसे, इस पर ध्यान केंद्रित करें।

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

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

डेटा को जहाज करने का एक प्रारूप, XML हो सकता है। इस तरह आप अधिक आसानी से गतिशील हो सकते हैं कि आप इसे कैसे चुन सकते हैं। एक वर्ण बनाम एकाधिक वर्ण, या एक आइटम बनाम आइटम का एक संग्रह, आदि। तब आप XML के रूप में XML (SQL) में "स्टोर" कर सकते हैं, और / या SQL ने XML से अधिक ट्रांजेक्शनल फैशन में वितरित किया है, कैसे आप वास्तव में संग्रहीत डेटा चाहते हैं।

एक और तरीका द्विआधारी है, जो शिपिंग के संदर्भ में अधिक कुशल है, लेकिन अन्य स्थितियों में अधिक लागत को लागू कर सकता है।

1,000 ग्राहकों के साथ, आप शुरू कर सकते हैं, और आसानी से प्रति ग्राहक 10 एमबी स्टोर कर सकते हैं और केवल 10 जीबी प्रभावी रैम का उपयोग कर सकते हैं + उस डेटा के प्रबंधन के लिए कुछ सिस्टम प्रशासनिक रैम जोड़ें, एक और जीबी या दो कहें। आप उपयोग के लिए तैयार डेटा संरचना में पहले से ही मेजबान पर रैम में रख सकते हैं। और गतिशील रूप से लोड / सहेजें, जो ऑनलाइन पर निर्भर करता है, गतिविधि के आधार पर विभिन्न आवृत्तियों में, आदि।

आप प्रत्येक ग्राहक की जानकारी को एक अलग फ़ाइल में भी संग्रहीत कर सकते हैं, और इसी तरह।

Answer 5

* ऑनलाइन * खिलाड़ियों को RAM में रखें, और जब वे लॉग आउट करते हैं, तो उन्हें डेटाबेस (SQLite? MySQL?) पर भेजें। यदि आप लॉगआउट के दौरान IO के रुकने के बारे में चिंतित हैं, तो प्रत्येक लॉगआउट को अपना धागा दें, इसे मुख्य / गेम थ्रेड में न करें (वास्तव में मैं हर ऑनलाइन खिलाड़ी के लिए एक समर्पित खिलाड़ी धागा रखता हूं, इसने नेटवर्किंग कोड को इतना आसान बना दिया है एस्किनेट नेटवर्क io अप्रोच करने से)