मेरे पास एक ऑनलाइन गेम है जहां खिलाड़ी किसी तरह से दुनिया को आकार देते हैं - जैसे। अल्टिमा ऑनलाइन का आवास, जहां आपको दुनिया के नक्शे के कुछ हिस्सों पर सीधे अपने घर बनाने के लिए मिलता है। ये ऐसे परिवर्तन हैं जो समय के साथ लगातार दुनिया में बने रहने चाहिए।
इसी समय, डिजाइन टीम नई सामग्री जोड़ रही है और नए खिलाड़ियों के लिए खेल को बेहतर बनाने और विस्तारित करने के लिए पुरानी सामग्री में संशोधन कर रही है। वे परीक्षण के दौरान पहले एक विकास सर्वर पर ऐसा करेंगे और फिर बाद में लाइव सर्वर पर खिलाड़ियों के "काम" के साथ अपने काम को मर्ज करना होगा।
यह मानते हुए कि हम गेम डिज़ाइन के मुद्दों को ठीक करते हैं - उदाहरण के लिए। खिलाड़ी केवल निर्दिष्ट क्षेत्रों में निर्माण कर सकते हैं, इसलिए वे कभी भी भौगोलिक रूप से डिजाइनर संपादन से नहीं टकराते - हैं डेटा को संभालने या डेटा संरचनाओं को व्यवस्थित करने के लिए अच्छे तरीके क्या हैं ताकि टकराव से बचने के लिए जब नए डिजाइनर डेटा को नए खिलाड़ी डेटा के साथ विलय कर दिया जाए?
उदाहरण 1: एक खिलाड़ी एक नए प्रकार के आइटम को शिल्प करता है, और खेल इसे आईडी 123456 प्रदान करता है। उस आइटम के उदाहरण सभी वापस 123456 को संदर्भित करते हैं। अब कल्पना कीजिए कि गेम डिजाइनरों के पास एक समान प्रणाली है, और एक डिजाइनर एक नई वस्तु भी बनाता है जिसे 123456 भी गिना जाता है। इससे कैसे बचा जा सकता है?
उदाहरण 2: कोई एक लोकप्रिय मॉड बनाता है जो आपके सभी ड्रेगन को एक फ्रांसीसी उच्चारण देता है। इसमें एक नई वस्तु के साथ एक स्क्रिप्ट शामिल है, assignFrenchAccentजिसे वे प्रत्येक ड्रैगन ऑब्जेक्ट को नई आवाज परिसंपत्तियों को आवंटित करने के लिए उपयोग करते हैं। लेकिन आप अपने "नेपोलियन बनाम स्मॉग" डीएलसी को तैनात करने वाले हैं जिसमें एक ही नाम की एक वस्तु है - आप ग्राहक सेवा की बहुत सारी समस्याओं के बिना ऐसा कैसे कर सकते हैं?
मैंने निम्नलिखित रणनीतियों के बारे में सोचा है:
- आप 2 अलग-अलग फ़ाइलों / निर्देशिकाओं / डेटाबेस का उपयोग कर सकते हैं, लेकिन तब आपके रीड ऑपरेशन काफी जटिल होते हैं। "सभी आइटम दिखाएं" को डिजाइनर DB पर पढ़ा हुआ एक प्रदर्शन करना होगा और एक खिलाड़ी DB पर पढ़ना होगा (और अभी भी 2 के बीच अंतर करना है, किसी तरह)।
- आप एक स्टोर में 2 अलग नामस्थान का उपयोग कर सकते हैं, जैसे। प्राथमिक कुंजी के रूप में स्ट्रिंग्स का उपयोग करना और उन्हें "डिज़ाइन:" या "PLAYER:" के साथ उपसर्ग करना, लेकिन उन नामस्थानों को बनाना गैर-तुच्छ हो सकता है और निर्भरताएं स्पष्ट नहीं हैं। (उदा। आरडीबीएमएस में आप कुशलता से प्राथमिक कुंजी के रूप में तार का उपयोग करने में सक्षम नहीं हो सकते हैं। आप पूर्णांक का उपयोग कर सकते हैं और एक निश्चित संख्या के नीचे सभी प्राथमिक कुंजी आवंटित कर सकते हैं, जैसे 1 मिलियन, डिजाइनर डेटा, और उस बिंदु से ऊपर सब कुछ। खिलाड़ी डेटा। लेकिन वह जानकारी RDBMS के लिए अदृश्य है और विदेशी कुंजी लिंक 'डिवाइड' को पार कर जाएंगे, जिसका अर्थ है कि सभी टूलिंग और स्क्रिप्ट को इसके आसपास स्पष्ट रूप से काम करने की आवश्यकता है।)
- आप हमेशा वास्तविक समय में एक ही साझा डेटाबेस पर काम कर सकते हैं, लेकिन प्रदर्शन खराब हो सकता है और खिलाड़ी डेटा को नुकसान का खतरा बढ़ सकता है। यह उन गेमों तक भी नहीं है जो विभिन्न विश्व डेटा के साथ 1 से अधिक सर्वर पर चलते हैं।
- ... कोई अन्य विचार?
यह मेरे लिए होता है कि हालांकि यह मुख्य रूप से ऑनलाइन गेम के लिए एक मुद्दा है, अवधारणाएं मोडिंग पर भी लागू हो सकती हैं, जहां समुदाय एक ही समय में मॉड बनाता है जो डेवलपर्स अपने गेम को पैच करते हैं। नए पैच आने पर मॉड ब्रेकिंग की संभावना को कम करने के लिए क्या कोई रणनीति यहां उपयोग की जाती है?
मैंने इसे "संस्करण नियंत्रण" के रूप में भी टैग किया है क्योंकि एक स्तर पर यह है - डेटा विकास की 2 शाखाएं जिन्हें विलय की आवश्यकता है। शायद कुछ अंतर्दृष्टि उस दिशा से आ सकती है।
EDIT - समस्या को स्पष्ट करने में मदद करने के लिए ऊपर दिए गए कुछ उदाहरण। मुझे लगता है कि इस मुद्दे को वास्तव में नामस्थान में से एक है, जो समग्र कुंजी के माध्यम से एक स्टोर में लागू किया जा सकता है। यह मर्ज की रणनीति को सरल करता है, कम से कम। लेकिन ऐसे विकल्प हो सकते हैं जिन्हें मैं नहीं देख रहा हूं।