पोकर, ब्लैकजैक, बेलोट और प्रेफरेंस का डेटाबेस से क्या लेना-देना है?

कई अलग-अलग कार्ड गेम को समायोजित करने के लिए पर्याप्त लचीला डेटाबेस कैसे डिज़ाइन करें।

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

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

चार कार्ड गेम जिनका हम अपने डेटाबेस में उपयोग करेंगे

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

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

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

ब्लैकजैक:

डेक: प्रत्येक 52 पत्तों के एक से आठ डेक; कोई जोकर कार्ड नहीं
खिलाड़ी: डीलर और 1 या अधिक विरोधी
प्रयुक्त इकाई: आम तौर पर पैसा
बुनियादी नियम: खिलाड़ियों को 2 कार्ड मिलते हैं जो केवल वे ही देख सकते हैं; डीलर को दो कार्ड मिलते हैं, एक फेस-अप और दूसरा फेस-डाउन; प्रत्येक खिलाड़ी अधिक कार्ड बनाने का निर्णय लेता है (या नहीं); डीलर अंतिम ड्रा करता है। कार्ड में 1 से 11 के बीच के बिंदु मान निर्दिष्ट किए गए हैं।
संभावित खिलाड़ी कार्रवाइयां: हिट, स्टैंड, स्प्लिट, सरेंडर
लक्ष्य और जीत की स्थिति: खिलाड़ी के कार्ड का योग डीलर के कार्ड से अधिक होता है; अगर कोई खिलाड़ी 21 से ऊपर जाता है, तो वह खिलाड़ी हार जाता है।

पोकर (टेक्सास होल्डम):

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

बेलोट (बेलोट का क्रोएशियाई संस्करण):

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

प्राथमिकता:

डेक: अक्सर एक पारंपरिक जर्मन या हंगेरियन 32-कार्ड डेक; कोई जोकर कार्ड नहीं
खिलाड़ी: तीन
इकाइयां: अंक
बुनियादी नियम: सभी खिलाड़ियों को 10 कार्ड बांटे जाते हैं; टेबल के बीच में दो "किट्टी" या "टैलन" कार्ड रखे गए हैं; खिलाड़ी निर्धारित करते हैं कि क्या वे एक सूट पर बोली लगाना चाहते हैं; खिलाड़ी खेलने या न खेलने का फैसला करते हैं।
संभावित खिलाड़ी कार्रवाइयां: पास, बोली सूट, खेलो, मत खेलो, कार्ड फेंको
लक्ष्य: खेले जा रहे प्रेफरेंस के प्रकार पर निर्भर करता है; मानक संस्करण में, बोली लगाने वाले को कुल छह तरकीबें जीतनी होंगी।
विजय शर्त: जब तीनों खिलाड़ियों के स्कोर का योग 0 होता है, तो सबसे कम अंकों वाला खिलाड़ी जीत जाता है।

डेटाबेस और कार्ड गेम को क्यों मिलाएं?

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

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

मॉडल का एक त्वरित परिचय

यह मॉडल हमें सभी प्रासंगिक गेम डेटा को स्टोर करने में सक्षम बनाता है, जिसमें शामिल हैं:

खेल गुण
खेल और मैचों की सूची
प्रतिभागियों
इन-गेम कार्रवाइयां

चूंकि खेल कई तरह से भिन्न होते हैं, इसलिए हम अक्सर varchar(256) . का उपयोग करेंगे गुण, चाल और परिणामों का वर्णन करने के लिए डेटा प्रकार।

खिलाड़ी, मैच और प्रतिभागी

मॉडल के इस खंड में तीन टेबल होते हैं और इसका उपयोग पंजीकृत खिलाड़ियों, खेले गए मैचों और भाग लेने वाले खिलाड़ियों के बारे में डेटा संग्रहीत करने के लिए किया जाता है।

player तालिका पंजीकृत खिलाड़ियों के बारे में डेटा संग्रहीत करती है। username और email गुण अद्वितीय मूल्य हैं। nick_name विशेषता खिलाड़ियों के स्क्रीन नामों को संग्रहीत करती है।

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

game_id - खेल की सूची वाली तालिका का संदर्भ देता है (इस मामले में पोकर, लाठी, बेलोट, और वरीयता)।
start_time और end_time वास्तविक समय जब एक मैच शुरू होता है और समाप्त होता है। ध्यान दें कि end_time शून्य हो सकता है; खेल समाप्त होने तक हमारे पास इसका मूल्य नहीं होगा। साथ ही, यदि कोई मैच समाप्त होने से पहले छोड़ दिया जाता है, तो end_time मान शून्य रह सकता है।
number_of_players - खेल शुरू करने के लिए आवश्यक प्रतिभागियों की संख्या है
deck_id - खेल में प्रयुक्त डेक का संदर्भ देता है।
decks_used - खेल खेलने के लिए उपयोग किए जाने वाले डेक की संख्या है। आमतौर पर यह मान 1 होगा, लेकिन कुछ गेम एकाधिक डेक का उपयोग करते हैं।
unit_id - खेल को स्कोर करने के लिए उपयोग की जाने वाली इकाई (अंक, चिप्स, पैसा, आदि) है।
entrance_fee - खेल में शामिल होने के लिए आवश्यक इकाइयों की संख्या है; यह शून्य हो सकता है यदि खेल के लिए प्रत्येक खिलाड़ी को इकाइयों की एक निर्धारित संख्या के साथ शुरू करने की आवश्यकता नहीं है।
victory_conditions - निर्धारित करता है कि किस खिलाड़ी ने मैच जीता। हम varchar . का उपयोग करेंगे प्रत्येक गेम की जीत की स्थिति का वर्णन करने के लिए डेटा प्रकार (यानी 100 अंक तक पहुंचने वाली पहली टीम) और इसकी व्याख्या करने के लिए एप्लिकेशन को छोड़ दें। यह लचीलापन बहुत सारे खेलों को जोड़ने के लिए जगह छोड़ता है।
match_result - मैच के परिणाम को टेक्स्ट फॉर्मेट में स्टोर करता है। जैसा कि victory_conditions के साथ है , हम एप्लिकेशन को मूल्य की व्याख्या करने देंगे। यह विशेषता NULL हो सकती है क्योंकि हम उस मान को उसी समय भर देंगे जब हम end_time डालेंगे मूल्य।

participant तालिका एक मैच में सभी प्रतिभागियों के बारे में डेटा संग्रहीत करती है। match_id और player_id विशेषताएँ match और player टेबल। साथ में, ये मान तालिका की वैकल्पिक कुंजी बनाते हैं।

अधिकांश गेम घुमाते हैं कि कौन सा खिलाड़ी पहले बोली लगाता है या खेलता है। आमतौर पर पहले दौर में, जो खिलाड़ी पहले (शुरुआती खिलाड़ी) खेलता है, वह खेल के नियमों से निर्धारित होता है। अगले दौर में, मूल ओपनिंग खिलाड़ी के बाएं (या कभी-कभी दाएं) खिलाड़ी पहले जाएगा। हम initial_player_order . का उपयोग करेंगे पहले राउंड के ओपनिंग प्लेयर के ऑर्डिनल नंबर को स्टोर करने की विशेषता। match_id और initial_player_order विशेषताएँ एक और वैकल्पिक कुंजी बनाती हैं क्योंकि दो खिलाड़ी एक ही समय में नहीं खेल सकते हैं।

score जब कोई खिलाड़ी मैच खत्म करता है तो विशेषता अपडेट हो जाती है। कभी-कभी यह सभी खिलाड़ियों के लिए एक ही क्षण में होगा (जैसे बेलोट या वरीयता में) और कभी-कभी जब मैच अभी भी चल रहा हो (जैसे पोकर या लाठी)।

कार्रवाइयां और कार्य प्रकार

जब हम उन कार्यों के बारे में सोचते हैं जो खिलाड़ी कार्ड गेम में कर सकते हैं, तो हमें एहसास होता है कि हमें स्टोर करना चाहिए:

कार्रवाई क्या थी
वह कार्रवाई किसने की
कब (किस सौदे में) कार्रवाई हुई
उस कार्रवाई में किस कार्ड का उपयोग किया गया था

action_type तालिका एक साधारण शब्दकोश है जिसमें खिलाड़ी क्रियाओं के नाम होते हैं। कुछ संभावित मूल्यों में ड्रा कार्ड, प्ले कार्ड, किसी अन्य खिलाड़ी को कार्ड पास करना, चेक करना और बढ़ाना शामिल है।

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

action_order विशेषता इन-गेम कार्रवाई की क्रमिक संख्या संग्रहीत करती है। उदाहरण के लिए, एक प्रारंभिक बोली को 1 मान प्राप्त होगा; अगली बोली में 2 मान होंगे, आदि। एक ही समय में एक से अधिक कार्य नहीं हो सकते हैं। इसलिए, deal_id और action_order विशेषताएँ मिलकर वैकल्पिक कुंजी बनाती हैं।

action_notation विशेषता में एक क्रिया का विस्तृत विवरण होता है। पोकर में, उदाहरण के लिए, हम एक उठाएं . स्टोर कर सकते हैं कार्रवाई और मनमानी राशि। कुछ क्रियाएं अधिक जटिल हो सकती हैं, इसलिए इन मानों को टेक्स्ट के रूप में संग्रहीत करना और एप्लिकेशन को इसकी व्याख्या करने के लिए छोड़ देना बुद्धिमानी है।

डील और डील ऑर्डर

एक मैच एक या अधिक कार्ड सौदों से बना होता है। हम पहले ही participant और match टेबल, लेकिन हमने उन्हें deal और deal_order टेबल.

deal तालिका एक मैच इंस्टेंस के बारे में हमारे लिए आवश्यक सभी डेटा संग्रहीत करती है।

match_id विशेषता उस उदाहरण को उपयुक्त मिलान से संबंधित करती है, जबकि start_time और end_time सटीक समय को इंगित करें जब वह उदाहरण शुरू हुआ और कब समाप्त हुआ।

move_time_limit और deal_result विशेषताएँ दोनों टेक्स्ट फ़ील्ड हैं जिनका उपयोग समय सीमा (यदि लागू हो) और उस सौदे के परिणाम का विवरण संग्रहीत करने के लिए किया जाता है।

participant तालिका, initial_player_order शुरुआती मैच इंस्टेंस के लिए एट्रिब्यूट स्टोर प्लेयर ऑर्डर। बाद के मोड़ों के लिए आदेशों को संग्रहीत करने के लिए एक पूरी तरह से नई तालिका की आवश्यकता होती है - deal_order टेबल।

जाहिर है, deal_id और participant_id एक मैच इंस्टेंस और एक प्रतिभागी के संदर्भ हैं। साथ में, वे deal_order टेबल। player_order विशेषता में उस मैच के उदाहरण में भाग लेने वाले खिलाड़ियों के ऑर्डर को दर्शाने वाले मान होते हैं। साथ में deal_id , यह इस तालिका में दूसरी वैकल्पिक कुंजी बनाता है। deal_result विशेषता एक टेक्स्ट फ़ील्ड है जो एक व्यक्तिगत खिलाड़ी के लिए मैच के परिणाम का वर्णन करती है। score विशेषता डील परिणाम से संबंधित एक संख्यात्मक मान संग्रहीत करती है।

सूट, रैंक और कार्ड

मॉडल का यह भाग उन कार्डों का वर्णन करता है जिनका उपयोग हम सभी समर्थित खेलों में करेंगे। प्रत्येक कार्ड का एक सूट और रैंक होता है।

suit_type तालिका एक शब्दकोश है जिसमें हमारे द्वारा उपयोग किए जाने वाले सभी प्रकार के सूट शामिल हैं। suit_type_name . के लिए , हम "फ़्रेंच सूट", "जर्मन सूट", "स्विस-जर्मन सूट" और "लैटिन सूट" जैसे मानों का उपयोग करेंगे।

suit तालिका विशिष्ट डेक प्रकारों द्वारा निहित सभी सूटों के नाम रखती है। उदाहरण के लिए, फ्रांसीसी डेक में "हुकुम", "हार्ट्स", "डायमंड्स" और "क्लब" नामक सूट हैं।

rank शब्दकोश में, हमें "ऐस", "किंग", "क्वीन" और "जैक" जैसे प्रसिद्ध कार्ड मान मिलेंगे।

card तालिका में हर संभव कार्ड की एक सूची है। प्रत्येक कार्ड इस तालिका में केवल एक बार दिखाई देगा। यही कारण है कि suit_id और rank_id विशेषताएँ इस तालिका की वैकल्पिक कुंजी बनाती हैं। दोनों विशेषताओं का मान NULL हो सकता है क्योंकि कुछ कार्डों में सूट या रैंक नहीं होता है (जैसे जोकर कार्ड)। is_joker_card एक स्व-व्याख्यात्मक बूलियन मान है। card_name विशेषता टेक्स्ट द्वारा एक कार्ड का वर्णन करती है:"ऐस ऑफ स्पेड्स"।

कार्ड और डेक

कार्ड डेक के हैं। क्योंकि एक कार्ड कई डेक में प्रदर्शित हो सकता है, हमें एक n:n . की आवश्यकता होगी card और deck टेबल.

deck तालिका में, हम उन सभी कार्ड डेक के नाम संग्रहीत करेंगे जिनका हम उपयोग करना चाहते हैं। deck_name में संग्रहीत मानों का एक उदाहरण विशेषताएं हैं:"मानक 52-कार्ड डेक (फ्रेंच)" या "32-कार्ड डेक (जर्मन)"।

card_in_deck संबंध का उपयोग उपयुक्त डेक को कार्ड आवंटित करने के लिए किया जाता है। card_id - deck_id जोड़ी deck टेबल।

प्रयुक्त गुण, डेक और इकाइयों का मिलान करें

मॉडल के इस भाग में एक नया गेम शुरू करने के लिए कुछ बुनियादी पैरामीटर शामिल हैं।

इस खंड का मुख्य भाग game टेबल। यह तालिका एप्लिकेशन-समर्थित गेम के बारे में डेटा संग्रहीत करती है। game_name विशेषता में "पोकर", "ब्लैकजैक", "बेलोट" और "प्रेफरेंस" जैसे मान शामिल हैं।

min_number_of_players और max_number_of_players एक मैच में प्रतिभागियों की न्यूनतम और अधिकतम संख्या है। ये विशेषताएँ खेल के लिए सीमाओं के रूप में काम करती हैं, और इन्हें एक मैच की शुरुआत में स्क्रीन पर दिखाया जाता है। मैच शुरू करने वाले व्यक्ति को इस श्रेणी से एक मान का चयन करना होगा।

min_entrance_fee और max_entrance_fee विशेषताएँ प्रवेश शुल्क सीमा को दर्शाती हैं। फिर से, यह खेले जा रहे खेल पर आधारित है।

possible_victory_condition में , हम उन सभी जीत की शर्तों को संग्रहीत करेंगे जो एक मैच को सौंपी जा सकती हैं। मान एक सीमांकक द्वारा अलग किए जाते हैं।

unit हमारे सभी खेलों में उपयोग की जाने वाली प्रत्येक इकाई को संग्रहीत करने के लिए डिक्शनरी का उपयोग किया जाता है। unit_name विशेषता में "बिंदु", "डॉलर", "यूरो" और "चिप" जैसे मान होंगे।

game_deck और game_unit टेबल एक ही तर्क का उपयोग करते हैं। उनमें उन सभी डेक और इकाइयों की सूचियाँ होती हैं जिनका उपयोग एक मैच में किया जा सकता है। इसलिए, game_id - deck_id जोड़ी और game_id - unit_id जोड़ी अपने संबंधित तालिकाओं में वैकल्पिक कुंजी बनाती है।

स्कोर

हमारे आवेदन में, हम उन सभी खिलाड़ियों के स्कोर को स्टोर करना चाहते हैं जिन्होंने हमारे कार्ड गेम में भाग लिया था। प्रत्येक खेल के लिए, एक एकल संख्यात्मक मान की गणना और भंडारण किया जाता है। (गणना एक ही प्रकार के सभी खेलों में खिलाड़ी के परिणामों पर आधारित है।) यह खिलाड़ी स्कोर एक रैंक के समान है; यह उपयोगकर्ताओं को मोटे तौर पर यह जानने देता है कि एक खिलाड़ी कितना अच्छा है।

गणना प्रक्रिया को लौटें। हम एक n:n . बनाएंगे player . के बीच संबंध और game टेबल। वह है player_score हमारे मॉडल में तालिका। player_id और score_id “एक साथ तालिका की वैकल्पिक कुंजी बनाते हैं। “score विशेषता का उपयोग पहले बताए गए संख्यात्मक मान को संग्रहीत करने के लिए किया जाता है।

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

जैसा कि इस लेख में दिखाया गया है, आप कई खेलों के लिए एक डेटाबेस का उपयोग कर सकते हैं। आप ऐसा क्यों करेंगे? तीन कारण:1) आप उसी डेटाबेस का पुन:उपयोग कर सकते हैं; 2) यह विश्लेषण को सरल करेगा; और इससे 3) बेहतर AI विरोधियों का निर्माण होगा।