आइए ईमानदार रहें:हम सभी को गेम खेलना पसंद है, खासकर हमारे कंप्यूटर पर। जब तक इंटरनेट व्यापक नहीं हो गया, हम में से अधिकांश ने स्वयं कंप्यूटर गेम खेला, आमतौर पर एआई विरोधियों के खिलाफ। यह मजेदार था, लेकिन जैसे ही आपने महसूस किया कि गेमप्ले मैकेनिक्स कैसे काम करता है, गेम ने अपना अधिकांश जादू खो दिया।
इंटरनेट के विकास ने खेलों को ऑनलाइन स्थानांतरित कर दिया। अब, हम मानव विरोधियों के खिलाफ खेल सकते हैं और उनके खिलाफ अपने कौशल का परीक्षण कर सकते हैं। कोई और रॉट गेमप्ले नहीं!
फिर बड़े पैमाने पर मल्टीप्लेयर ऑनलाइन (MMO) गेम सामने आए और सब कुछ बदल दिया। हजारों खिलाड़ियों ने खुद को एक ही खेल जगत में पाया, संसाधनों पर प्रतिस्पर्धा, बातचीत, व्यापार और लड़ाई। ऐसे खेलों को संभव बनाने के लिए, एक डेटाबेस संरचना की आवश्यकता थी जो सभी प्रासंगिक सूचनाओं को संग्रहीत कर सके।
इस लेख में, हम एक मॉडल तैयार करेंगे जिसमें MMO खेलों में पाए जाने वाले सबसे सामान्य तत्व शामिल होंगे। हम इसका उपयोग कैसे करें, इसकी सीमाओं और इसके संभावित सुधारों पर चर्चा करेंगे।
MMO खेलों के लिए डेटा मॉडल का परिचय
आज बहुत सारे लोकप्रिय MMO खेल हैं, और उनमें सभी प्रकार के परिदृश्य शामिल हैं। मैं यहां Ogame . जैसे रणनीति गेम पर ध्यान केंद्रित करूंगा , ट्रैवियन , स्पार्टा :साम्राज्यों का युद्ध और इंपीरिया ऑनलाइन . ये खेल योजना बनाने, निर्माण करने और रणनीति बनाने के बारे में अधिक हैं, और प्रत्यक्ष कार्रवाई के बारे में कम हैं।
MMO गेम अलग-अलग ब्रह्मांडों में सेट होते हैं, नेत्रहीन भिन्न होते हैं, और कमोबेश विभिन्न गेमप्ले विकल्पों का उपयोग करते हैं। फिर भी, कुछ विचार वही हैं। खिलाड़ी स्थानों के लिए प्रतिस्पर्धा करते हैं, उनके लिए लड़ते हैं, और अन्य खिलाड़ियों के साथ (और खिलाफ) गठबंधन करते हैं। वे संरचनाएं बनाते हैं, संसाधन एकत्र करते हैं, और अनुसंधान प्रौद्योगिकियां। वे इकाइयाँ (जैसे योद्धा, टैंक, व्यापारी, आदि) बनाते हैं और उनका उपयोग सहयोगियों के साथ व्यापार करने या विरोधियों से लड़ने के लिए करते हैं। यह सब हमारे डेटाबेस में समर्थित होना चाहिए।
हम इन खेलों को कई अनुक्रमित वर्गों के साथ ऑनलाइन बोर्ड गेम के रूप में सोच सकते हैं। प्रत्येक वर्ग के साथ कई अलग-अलग क्रियाएं जुड़ी हो सकती हैं; कुछ क्रियाओं में अनेक वर्ग शामिल होंगे - उदा. जब हम इकाइयों या संसाधनों को एक स्थान से दूसरे स्थान पर ले जाते हैं।
डेटाबेस को पांच मुख्य क्षेत्रों में बांटा गया है:
Players / UsersAlliancesLocations and StructuresResearch and ResourcesUnits
शेष सात अवर्गीकृत सारणियाँ इकाइयों से संबंधित हैं और इकाई की स्थिति और खेल के अंदर की गतिविधियों का वर्णन करती हैं। हम इनमें से प्रत्येक क्षेत्र को खिलाड़ियों . से शुरू करते हुए और अधिक विस्तार से देखेंगे और गठबंधन ।
खिलाड़ी और गठबंधन
निस्संदेह, खिलाड़ी किसी भी खेल का सबसे महत्वपूर्ण हिस्सा होते हैं।
player तालिका में एक गेम इंस्टेंस में भाग लेने वाले सभी पंजीकृत खिलाड़ियों की एक सूची है। हम खिलाड़ियों के उपयोगकर्ता नाम, पासवर्ड और स्क्रीन नाम संग्रहीत करेंगे। इन्हें user_name . में स्टोर किया जाएगा , password , और nickname क्रमशः गुण।
नए उपयोगकर्ताओं को पंजीकरण के दौरान एक ईमेल पता प्रदान करना होगा। एक पुष्टिकरण कोड जनरेट किया जाएगा और उन्हें भेजा जाएगा, जिसका वे जवाब देंगे। हम confirmation_date को अपडेट करेंगे विशेषता जब उपयोगकर्ता अपना ईमेल पता सत्यापित करता है। तो, इस तालिका में तीन अद्वितीय कुंजियाँ हैं:user_name , nickname और email ।
हर बार जब कोई उपयोगकर्ता लॉग इन करता है, तो login_history टेबल। इस तालिका की सभी विशेषताएँ स्व-व्याख्यात्मक हैं। logout_time विशिष्ट है। यह NULL हो सकता है जब उपयोगकर्ता का वर्तमान सत्र सक्रिय होता है या जब उपयोगकर्ता तकनीकी समस्याओं के कारण गेम (बिना लॉग आउट किए) छोड़ देते हैं। login_data . में विशेषता, हम खिलाड़ी के भौगोलिक स्थान, आईपी पते और उनके द्वारा उपयोग किए जाने वाले डिवाइस और ब्राउज़र जैसे लॉगिन विवरण संग्रहीत करेंगे।
अधिकांश MMO गेम हमें अन्य खिलाड़ियों के साथ सहयोग करने देते हैं। खिलाड़ी सहयोग के मानक रूपों में से एक गठबंधन है। खिलाड़ी अपने इन-गेम "निजी डेटा" (ऑनलाइन स्थिति, योजनाएं, उनके शहरों और कॉलोनियों का स्थान, आदि) को अन्य लोगों के साथ साझा करते हैं ताकि संबद्ध कार्यों का लाभ उठाया जा सके और इसका मज़ा लिया जा सके।
alliance तालिका खेल गठबंधनों के बारे में बुनियादी जानकारी संग्रहीत करती है। प्रत्येक का एक अद्वितीय alliance_name होता है जिसे हम स्टोर करेंगे। हमारे पास एक फ़ील्ड भी होगी, date_founded , वह भंडार जब गठबंधन की स्थापना हुई थी। अगर कोई गठबंधन टूट जाता है, तो हम उस जानकारी को date_disbanded . में स्टोर कर लेंगे विशेषता।
alliance_member तालिका गठबंधन वाले खिलाड़ियों से संबंधित है। खिलाड़ी एक ही गठबंधन में एक से अधिक बार शामिल हो सकते हैं और छोड़ सकते हैं। इस वजह से, player_id - alliance_id जोड़ी एक अद्वितीय कुंजी नहीं है। हम इस बारे में जानकारी रखेंगे कि कोई खिलाड़ी कब गठबंधन में शामिल होता है और कब (यदि) वे छोड़ते हैं date_from में और date_to खेत। membership_type_id विशेषता membership_type शब्दकोश; यह गठबंधन में खिलाड़ियों के अधिकारों के मौजूदा स्तर को संग्रहीत करता है।
गठबंधन में खिलाड़ियों के अधिकार समय के साथ बदल सकते हैं। membership_actions , membership_type और actions_allowed सारणियां मिलकर गठबंधन के सदस्यों के लिए सभी संभावित अधिकारों को परिभाषित करती हैं। यह मॉडल खिलाड़ियों को गठबंधन में अधिकारों के अपने स्तर को परिभाषित करने की अनुमति नहीं देता है, लेकिन इसे membership_type शब्दकोश और भंडारण की जानकारी के बारे में कि वे किस गठबंधन से संबंधित हैं।
संक्षेप में:इन तालिकाओं में संग्रहीत मान प्रारंभिक सेटअप के दौरान हमारे द्वारा परिभाषित किए गए हैं; वे तभी बदलेंगे जब हम नए विकल्प पेश करेंगे।
membership_history तालिका एक गठबंधन के भीतर खिलाड़ियों की भूमिकाओं या अधिकारों के बारे में सभी डेटा संग्रहीत करती है, जिसमें ये अधिकार मान्य होने की सीमा भी शामिल है। (उदाहरण के लिए, उसके पास एक महीने के लिए "नौसिखिया" अनुमतियां हो सकती हैं, और फिर उस बिंदु से "पूर्ण सदस्यता" हो सकती है।) date_to विशेषता NULLable है क्योंकि वर्तमान में सक्रिय अधिकार अभी समाप्त नहीं हुए हैं।
membership_actions डिक्शनरी में उन सभी एक्शन खिलाड़ियों की सूची है जो एक गठबंधन में कर सकते हैं। प्रत्येक क्रिया का अपना action_name होता है और गेम लॉजिक इन्हीं नामों के इर्द-गिर्द बना हुआ है। हम “सदस्यों की सूची देखें” . जैसे मूल्यों की अपेक्षा कर सकते हैं , “सदस्यों की स्थिति देखें” और “संदेश भेजें” यहाँ।
membership_type शब्दकोश में खेल में उपयोग किए जाने वाले क्रिया समूहों के अद्वितीय नाम हैं। actions_allowed तालिका सदस्यता प्रकारों के लिए कार्य निर्दिष्ट करती है। प्रत्येक क्रिया को केवल एक बार एक प्रकार को सौंपा जा सकता है। इसलिए, membership_action - membership_type जोड़ी इस तालिका के लिए अद्वितीय कुंजी बनाती है।
स्थान और संरचनाएं
खेल स्थान ऐसे क्षेत्र हैं जहां खिलाड़ी संसाधन एकत्र करते हैं और संरचनाओं और इकाइयों का निर्माण करते हैं। कुछ खेलों में संभावित स्थानों की एक पूर्वनिर्धारित सीमा होती है, जबकि अन्य उपयोगकर्ताओं को अपने स्वयं के स्थानों को परिभाषित करने की अनुमति दे सकते हैं।
3D स्पेस में, स्थानों को [x:y:z] निर्देशांकों से परिभाषित किया जा सकता है। यदि किसी गेम की एक पूर्वनिर्धारित सीमा है, तो हो सकता है कि यह खिलाड़ियों को तीनों अक्षों के लिए [0:1000] सीमा से बाहर किसी भी स्थान का उपयोग करने की अनुमति न दे, इसलिए हम 1000 * 1000 * 1000 स्थान तक सीमित हैं।
दूसरी ओर, शायद हम खिलाड़ियों को उनके नए स्थान के सटीक निर्देशांक दर्ज करने की अनुमति देना चाहते हैं - उदा। [1001:2073:4] - और हम चाहते हैं कि गेम उनके लिए इसे प्रोसेस करे।
हम location टेबल। प्रत्येक स्थान का अपना नाम होता है, लेकिन नाम अद्वितीय नहीं होते हैं। दूसरी ओर, coordinates विशेषता में केवल अद्वितीय मान होने चाहिए। स्थान निर्देशांक टेक्स्ट मानों के रूप में संग्रहीत किए जाते हैं, इसलिए हम 3D गेम के लिए निर्देशांकों को [112:72:235] के रूप में संग्रहीत कर सकते हैं। 2D गेम के लिए निर्देशांक <1102:98> के रूप में संग्रहीत किए जा सकते हैं।
कुछ खेलों में, स्थानों में कई वर्ग होंगे जिनका उपयोग घर की संरचनाओं या इकाइयों के लिए किया जाता है। हम उस जानकारी को dimension . में रखेंगे विशेषता, जो एक टेक्स्ट फ़ील्ड है। एक आयाम 2D या 3D ग्रिड में केवल वर्गों की संख्या हो सकता है। player_id विशेषता उस स्थान के वर्तमान स्वामी के बारे में जानकारी संग्रहीत करती है। जब स्थान पूर्वनिर्धारित होते हैं और खिलाड़ी उन पर कब्जा करने के लिए प्रतिस्पर्धा करते हैं तो यह NULL हो सकता है।
structure तालिका में सभी संरचनाओं की एक सूची है जिसे हम विभिन्न खेल स्थानों पर बना सकते हैं। संरचनाएं उन सुधारों का प्रतिनिधित्व करती हैं जो हमें बेहतर इकाइयों का उत्पादन करने, नए प्रकार के शोध करने, अधिक संसाधन उत्पन्न करने आदि की अनुमति देती हैं। खेल में उपयोग की जाने वाली प्रत्येक संरचना का अपना अनूठा structure_name होता है। . कुछ संभावित structure_name मान "खेत", "अयस्क खदान", "सौर संयंत्र" और "अनुसंधान केंद्र" हैं।
हम उम्मीद कर सकते हैं कि प्रत्येक संरचना को कई बार अपग्रेड किया जाएगा, इसलिए हम इसके वर्तमान स्तर के बारे में जानकारी भी संग्रहीत करेंगे। प्रत्येक अपग्रेड संरचनाओं के आउटपुट में सुधार करता है, इसलिए यह अधिक संसाधनों का उत्पादन करता है या हमें गेम में नई सुविधाओं का उपयोग करने की अनुमति देता है। हम अपग्रेड के अधिकतम स्तर को पहले से नहीं जान सकते हैं, इसलिए हम फ़ार्मुलों के साथ सभी स्तर से संबंधित सामग्री (लागत, अपग्रेड समय और उत्पादन) को परिभाषित करेंगे। डेटाबेस में संग्रहीत सभी सूत्र खेल के यांत्रिकी के मूल हैं, और उनका समायोजन सामान्य रूप से खेल संतुलन और गेमप्ले के लिए महत्वपूर्ण है।
upgrade_time_formula . के मामले में भी ऐसा ही है गुण। इस फ़ील्ड के लिए एक उदाहरण मान है “<स्तर> * 30 मिनट” , जहां <स्तर> उस स्तर का प्रतिनिधित्व करता है जिसे हम अपग्रेड करना चाहते हैं।
ज्यादातर मामलों में, ऐसी आवश्यकताएं होती हैं जिन्हें खिलाड़ियों द्वारा कुछ कार्रवाई करने से पहले पूरा किया जाना चाहिए। हो सकता है कि नई संरचनाओं का निर्माण करने से पहले या इसके विपरीत हमें एक निर्धारित मात्रा में शोध पूरा करने की आवश्यकता हो। हम संरचना बनाने के लिए आवश्यक अनुसंधान स्तर को prerequisite_research टेबल। विभिन्न शोध शुरू करने के लिए आवश्यक संबंध और संरचना स्तर prerequisite_structure टेबल। दोनों तालिकाओं में, विदेशी कुंजियाँ research_id और structure_id एक अद्वितीय कुंजी बनाने के लिए जोड़ा जाता है। level_required विशेषता ही मूल्य है।
ये दो टेबल, prerequisite_research और prerequisite_structure , खेल का मूल भी बनाते हैं।
प्रत्येक संरचना के लिए, हम पूर्वापेक्षाओं की एक सूची परिभाषित करेंगे:अन्य संरचनाएं और उनके न्यूनतम स्तर जिन्हें खिलाड़ियों को निर्माण शुरू करना होगा। हम इस डेटा को structure_required टेबल। यहां, structure_id उस संरचना का प्रतिनिधित्व करता है जिसे हम बनाना चाहते हैं; structure_required_id पूर्वापेक्षित संरचना (संरचनाओं) और level . का संदर्भ है आवश्यक स्तर है।
structure_built तालिका किसी दिए गए स्थान पर वर्तमान संरचना स्तरों के बारे में जानकारी संग्रहीत करती है। upgrade_ongoing विशेषता केवल तभी सेट की जाएगी जब कोई अपग्रेड वर्तमान में चल रहा हो, जबकि upgrade_end_time एक बार अपग्रेड पूरा हो जाने पर विशेषता में टाइमस्टैम्प होगा।
structure_formula तालिका संरचनाओं और संसाधनों से संबंधित है। इस तालिका में विदेशी कुंजी जोड़ी इसकी अनूठी कुंजी बनाती है। इस तालिका में दो टेक्स्ट विशेषताएँ भी हैं जिनमें पैरामीटर के रूप में <स्तर> वाले सूत्र शामिल हैं। हम इन फ़ार्मुलों को परिभाषित करेंगे, एक लागत के लिए और दूसरा संसाधन निर्माण के लिए, डेटाबेस में। वे upgrade_time_formula . के समान होंगे . हमें उनकी आवश्यकता है क्योंकि हमें प्रत्येक संरचना के निर्माण में खर्च किए गए संसाधनों को परिभाषित करना चाहिए। हमें उन्नयन के बाद संसाधन उत्पादन को परिभाषित करने की भी आवश्यकता है, यदि संरचना कोई संसाधन उत्पन्न करती है (अर्थात अयस्क खदान <स्तर> * 20 का उत्पादन करेगा) अयस्क प्रति दिन)।
अनुसंधान और संसाधन
खेलों में अनुसंधान (या प्रौद्योगिकियां) आमतौर पर अन्य सुविधाओं के निर्माण के लिए आवश्यक हैं। अनुसंधान के कुछ स्तरों के बिना, नई संरचना या इकाई प्रकार का निर्माण नहीं किया जा सकता है। अनुसंधान की अपनी आवश्यकताएं भी हो सकती हैं। सबसे आम में से एक दी गई संरचना का स्तर है, जिसे आमतौर पर "अनुसंधान प्रयोगशाला" कहा जाता है। या शायद खिलाड़ियों को नया शोध शुरू करने से पहले एक निश्चित स्तर का शोध पूरा करना होगा। इन सभी आवश्यकताओं को इस खंड में संभाला जाएगा। नीचे, हम अनुसंधान और संसाधनों के लिए डेटा मॉडल पा सकते हैं:
research तालिका में हमारे खेल में सभी संभावित शोध कार्यों की एक सूची है। यह structure टेबल। research_name विशेषता तालिका की अद्वितीय कुंजी है, जबकि upgrade_time_formula फ़ील्ड में इसके पैरामीटर के रूप में <स्तर> के साथ अनुसंधान समय आवश्यकता सूत्र का एक पाठ प्रतिनिधित्व शामिल है। अपग्रेड के लिए आवश्यक सभी संसाधन upgrade_formula . में परिभाषित हैं research_formula टेबल।
संरचनाओं के साथ के रूप में, हम अन्य सभी शोधों और उनके स्तरों की सूची को परिभाषित करेंगे, जिन्हें किसी अन्य प्रकार के शोध को शुरू करने से पहले पूरा किया जाना चाहिए। हम इस डेटा को research_required तालिका, जहां research_id वांछित अनुसंधान का प्रतिनिधित्व करता है; research_required_id पूर्वापेक्षित शोध का संदर्भ है, और level आवश्यक स्तर है।
अनुसंधान व्यक्तिगत खिलाड़ियों से संबंधित है, और प्रत्येक खिलाड़ी - अनुसंधान . के लिए ch जोड़ी हमें एक खिलाड़ी के वर्तमान शोध स्तर और किसी भी चल रहे उन्नयन की स्थिति को संग्रहीत करना चाहिए। हम इस जानकारी को research_level तालिका उसी तरह से है जैसे हमने structure_built टेबल।
लकड़ी, अयस्क, रत्न और ऊर्जा जैसे संसाधनों का खनन या संग्रह किया जाता है और बाद में संरचनाओं और अन्य सुधारों के निर्माण के लिए उपयोग किया जाता है। हम सभी इन-गेम संसाधनों की सूची resource शब्दकोश। यहां केवल एक ही विशेषता है resource_name फ़ील्ड, और यह तालिका की अद्वितीय कुंजी भी है।
प्रत्येक स्थान पर संसाधनों की वर्तमान मात्रा पर नज़र रखने के लिए, हम resources_on_location टेबल। फिर से, एक विदेशी कुंजी जोड़ी (resource_id और location_id ) तालिका की अद्वितीय कुंजी बनाता है, जबकि number विशेषता वर्तमान संसाधन मूल्यों को संग्रहीत करती है।
इकाइयां और आंदोलन
इकाइयों के उत्पादन के लिए संसाधनों का उपयोग किया जाता है। इकाइयों का उपयोग संसाधनों के परिवहन, अन्य खिलाड़ियों पर हमला, या सामान्य रूप से लूटपाट और जलाने के लिए किया जा सकता है।
हमारे खेल में प्रयुक्त इकाई प्रकारों की सूची unit केवल एक मान वाला शब्दकोश, unit_name; वह विशेषता इस तालिका की अनूठी कुंजी है। कुछ सामान्य खेल इकाइयां "स्वॉर्ड्समैन", "बैटलक्रूजर", "ग्रिफिन", "जेट फाइटर", "टैंक" आदि हैं।
हमें प्रत्येक इकाई को विशिष्ट विशेषताओं के साथ वर्णित करने की आवश्यकता है। सभी संभावित विशेषताओं की सूची characteristic शब्दकोश। characteristic_name फ़ील्ड में एक अद्वितीय मान होता है। इस क्षेत्र के मूल्यों में शामिल हो सकते हैं:"हमला", "रक्षा" और "हिट पॉइंट"। हम unit_characteristic संबंध। unit_id . की विदेशी कुंजी जोड़ी और characteristic_id तालिका की अनूठी कुंजी बनाएं। हम केवल एक विशेषता का उपयोग करेंगे, value , वांछित मान संग्रहीत करने के लिए।
research_unit तालिका में सभी शोध गतिविधियों की एक सूची है जो किसी दिए गए इकाई प्रकार का उत्पादन शुरू करने से पहले समाप्त होनी चाहिए। unit_cost तालिका एकल इकाई के उत्पादन के लिए आवश्यक संसाधनों को परिभाषित करती है। दोनों तालिकाओं में विदेशी कुंजी युग्म (research_id . से बनी अद्वितीय कुंजियाँ होती हैं या resources_id unit_id . के साथ संयुक्त ) और एक मान फ़ील्ड (cost और level_required )।
और अब, मजेदार हिस्सा। उत्पादन मजेदार है, लेकिन इकाइयों को इधर-उधर ले जाना और कार्रवाई करना और भी बेहतर है। हमने पहले ही unit तालिका, लेकिन हम इसे यहां रखेंगे क्योंकि यह अन्य तालिकाओं से कैसे संबंधित है।
या तो इकाइयाँ किसी स्थान पर तैनात हैं या वे स्थानों के बीच घूम रही हैं। player_idजोड़ना फ़ील्ड निर्धारित करती है कि या तो स्थान या समूहों के बीच घूमने वाले समूह का स्वामी कौन है।
यदि इकाइयाँ केवल दिए गए स्थान पर तैनात हैं, तो हम उस स्थान और वहाँ तैनात इकाइयों की संख्या को संग्रहीत करेंगे। ऐसा करने के लिए, हम units_on_location टेबल।
जब इकाइयां तैनात नहीं हैं, तो वे घूम रहे हैं। हमें उनके प्रस्थान बिंदु और उनके गंतव्य को संग्रहीत करने की आवश्यकता होगी। इसके अलावा, हमें आंदोलनों के दौरान संभावित क्रियाओं को परिभाषित करने की आवश्यकता है। ऐसी सभी कार्रवाइयां movement_type शब्दकोश। type_name विशेषता अद्वितीय है जबकि allows_wait विशेषता निर्धारित करती है कि क्या कोई क्रिया गंतव्य बिंदु पर प्रतीक्षा की अनुमति देती है।
हम एक एकल इकाई प्रकार को स्थानांतरित कर सकते हैं, लेकिन लगभग हर मामले में हम कई अलग-अलग इकाई प्रकारों की कई इकाइयों को स्थानांतरित करेंगे। वह समूह सामान्य डेटा साझा करेगा और हम उन्हें group_movement टेबल। इस तालिका में, हम निम्नलिखित मदों को परिभाषित करेंगे:
- वह खिलाड़ी जिसने कार्रवाई शुरू की
- कार्रवाई का प्रकार
- शुरुआती बिंदु
- गंतव्य बिंदु
arrival_timeगंतव्य परreturn_timeशुरुआती बिंदु तकwait_timeगंतव्य पर
return_time यदि यह एकतरफा यात्रा है, तो विशेषता NULL हो सकती है, और wait_time खिलाड़ी द्वारा परिभाषित किया गया है। किसी समूह से संबंधित इकाइयों को units_in_group टेबल। units_id . की विदेशी कुंजी जोड़ी और group_moving_id तालिका की अनूठी कुंजी बनाता है। समूह के भीतर एक ही प्रकार की इकाइयों की संख्या number . में परिभाषित की गई है विशेषता।
प्रत्येक आंदोलन संसाधनों को एक स्थान से दूसरे स्थान तक ले जा सकता है। इसलिए, हम group_movement और resources टेबल। प्राथमिक और विदेशी कुंजियों के अलावा, resources_in_group तालिका में केवल number शामिल है गुण। यह फ़ील्ड उन संसाधनों की मात्रा को संग्रहीत करती है जो खिलाड़ी शुरुआती बिंदु से अपने गंतव्य तक ले जाते हैं।
ज्यादातर मामलों में, खिलाड़ी दूसरों को अपने साहसिक कार्य में शामिल होने के लिए बुला सकते हैं। इसका समर्थन करने के लिए हम दो तालिकाओं का उपयोग करेंगे:allied_movement और allied_groups . एक खिलाड़ी संयुक्त कार्रवाई शुरू करेगा, और वह allied_movement टेबल। किसी संबद्ध कार्रवाई में भाग लेने वाली इकाइयों के सभी समूहों को allied_groups टेबल। प्रत्येक समूह को केवल एक बार संबद्ध कार्रवाई के लिए असाइन किया जा सकता है, इसलिए विदेशी कुंजियाँ इस तालिका की अद्वितीय कुंजी बनाती हैं।
यह मॉडल हमें एक MMO रणनीति गेम बनाने के लिए आवश्यक बुनियादी संरचना प्रदान करता है। इसमें सबसे महत्वपूर्ण खेल विशेषताएं शामिल हैं:स्थान, संरचनाएं, संसाधन, अनुसंधान और इकाइयाँ। यह उनसे संबंधित भी है, हमें डेटाबेस में पूर्वापेक्षाएँ परिभाषित करने देता है, और अधिकांश गेम लॉजिक को डेटाबेस में भी संग्रहीत करता है।
इन तालिकाओं के भर जाने के बाद, अधिकांश खेल तर्क परिभाषित हो जाते हैं और हम नए मूल्यों के जोड़े जाने की अपेक्षा नहीं करेंगे। लगभग हर तालिका में एक अद्वितीय कुंजी मान होता है, या तो एक विशेषता नाम या विदेशी कुंजी जोड़ी। इकाइयों की विशेषताओं और उत्पादन/लागत फ़ार्मुलों को बदलने से हम डेटाबेस परत में खेल संतुलन को बदल सकेंगे।
आप इस मॉडल को कैसे बदलेंगे? आपको क्या पसंद है, और आप अलग तरीके से क्या करेंगे? हमें कमेंट सेक्शन में बताएं!
