केवल एक्सेल का उपयोग करके विश्वसनीय गेम मैकेनिक्स कैसे बनाएं: मॉडलिंग और समाधान का अनुकूलन

हम खोज में हैं, पुनरावृत्ति नहीं

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

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

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

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

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



इस अंधेरे कमरे के अस्तित्व के कारण, हम "पुनरावृत्तियों" का प्रदर्शन करते हैं - हम यह नहीं जानते हैं कि जब तक हम उनकी जाँच नहीं करेंगे तब तक निर्णयों के परिणाम क्या होंगे। दूसरे शब्दों में, हम खोज में हैं ( जीडीसी 2004 में उनकी बात में राइट ने इसे "समाधान स्थान में खोज" कहा)।

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

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

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

लेखों की यह श्रृंखला

यह आलेख मॉडलिंग समाधानों पर पोस्ट की एक श्रृंखला में पहला होगा - औपचारिक मॉडल में समाधानों को विघटित करने के लिए उपकरणों का एक सेट, जो तब सबसे वांछनीय परिणाम खोजने के लिए खोज करने के लिए उपयोग किया जा सकता है।

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

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


जब सही तरीके से उपयोग किया जाता है, तो मॉडलिंग समाधान डिजाइन प्रक्रिया के कई पहलुओं में काफी सुधार कर सकते हैं:

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

लेखों की इस श्रृंखला में मैं उपयोग की सभी तीन श्रेणियों के उदाहरणों के बारे में बात करूंगा।

परिभाषा

"निर्णय मॉडलिंग" क्या है?

सीधे शब्दों में कहें, तो:

निर्णय मॉडलिंग इसकी गणना के लिए खोज के बाद के स्वचालन के साथ एक समाधान का अनुकरण करने की प्रक्रिया है।

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

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

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

क्यों बना मॉडल?

यदि आपने सिड मीयर की सभ्यता को निभाया, तो आप शायद सोचेंगे: “एक मिनट रुको, शहर के विकास को शुरू करने का सबसे अच्छा तरीका कैसे है? क्या मुझे पहले एक स्मारक और फिर एक गोदाम बनाने की आवश्यकता है? या पहले गोदाम की जरूरत है? या शायद पहले एक मंदिर, और फिर एक गोदाम? कौन सा निर्णय लेना बेहतर है? क्या कोई इस सवाल का जवाब दे सकता है? "

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

वास्तव में, ऐसी प्रणाली बनाई जा सकती है!

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

यहां एक समान समस्या का एक उदाहरण है - एक उदाहरण जिसे हम श्रृंखला में एक भविष्य के लेख में हल करेंगे।

मान लीजिए कि हमारे पास सुपरटैंक नामक एक गेम है। सुपरटैंक में, हम युद्ध के मैदान पर अन्य सुपर टैंक के साथ लड़ते हुए एक विशाल शानदार टैंक चलाते हैं। प्रत्येक लड़ाई से पहले, हम अपने टैंक के लिए हथियारों का एक विशिष्ट संयोजन चुन सकते हैं।


हमारे पास 100 क्रेडिट हैं जो आप उपकरणों पर खर्च कर सकते हैं। खिलाड़ी का सुपरटैंक 50 टन हथियार ले जा सकता है, और विशेष उच्च-शक्ति वाले हथियारों के लिए 3 "महत्वपूर्ण" स्लॉट भी हैं।

खेल में निम्नलिखित पांच प्रकार के हथियार होते हैं, और खिलाड़ी प्रत्येक प्रकार की किसी भी मात्रा का उपयोग कर सकता है, या पूरी तरह से इसे छोड़ सकता है:


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

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

मैन्युअल रूप से या कैलकुलेटर का उपयोग करके समस्या को हल करने का प्रयास करें।

क्या यह किया जा सकता है?

यदि आप कोशिश करते हैं, तो जल्दी से सुनिश्चित करें कि यह आश्चर्यजनक रूप से कठिन है।

शायद जटिल गणितीय समीकरणों का उपयोग करके इसे हल करने का एक तरीका है, लेकिन हम डिजाइनर हैं, और गणित हमारी चीज नहीं है।

यह भी सोचें कि उत्तर अन्य मापदंडों के साथ कैसे बदलेगा। 50 टन के बजाय सुपर टैंक 60 को समायोजित कर सकता है, तो क्या उत्तर बदल जाएगा? या अगर 100 ऋणों के बजाय हमारे पास 110 या 90 हैं? इष्टतम गियर कैसे बदलेगा? और अगर हमारे पास 2 या 4 महत्वपूर्ण स्लॉट हैं?

अब कल्पना करें कि हमारे पास एक ऐसी प्रणाली है जो किसी भी पैरामीटर (वेट, प्राइस, क्रिटिकल स्लॉट्स) के लिए सबसे बड़ी क्षति के साथ हथियारों के लेआउट की तुरंत गणना करती है। यह तालिका से हथियारों के मापदंडों को दर्ज करने के लिए पर्याप्त है, फिर सुपरटैंक (50 टन, 100 क्रेडिट, 3 महत्वपूर्ण स्लॉट) के मापदंडों को दर्ज करें - और बूम! - हमें सबसे अच्छा उपकरण मिला।

यह अद्भुत नहीं होगा?

हम सभी प्रकार के उपयोगी प्रश्नों के उत्तर तुरंत प्राप्त करने के लिए इस प्रणाली का उपयोग कर सकते हैं:

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

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

केवल कुछ पैराग्राफों में, हमने एक ऐसे कार्य का वर्णन किया है जो हमारे लिए मैन्युअल रूप से हल करना बहुत मुश्किल है, लेकिन जो Microsoft Excel में निर्मित टूल का उपयोग करके तुच्छ रूप से हल किया गया है।

भविष्य के लेख में, हम इस उदाहरण के लिए समाधानों का एक वास्तविक मॉडल बनाएंगे, जो उपरोक्त सभी प्रश्नों के उत्तर देगा।

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

रोड मैप

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

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

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

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

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

निर्णय मॉडल का उपयोग क्यों करें?

कुछ पाठकों को अब संदेह हो सकता है। ऐसा लगता है कि निर्णय मॉडल का निर्माण बहुत काम है। अगर हम फोकस ग्रुप टेस्टिंग और बीटा टेस्टिंग के रूप में कस्टम टेस्टिंग कर सकते हैं तो यह सब प्रयास क्यों आवश्यक है?

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

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

किसी भी अन्य उपकरण की तरह, इसके उपयोगकर्ता को इसकी प्रयोज्यता पर निर्णय लेना चाहिए।

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

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

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

यह डिजाइन को अविश्वसनीय रूप से जोखिम भरा, लंबा और महंगा बनाता है।

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

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

मॉडलिंग समाधान हमें इस तरह के समर्थन के लिए कुछ और कदम उठाने में मदद करेंगे और स्वचालित उपकरणों की मदद से हमारे डिजाइनरों की अपनी बुद्धि को पूरक और विस्तारित करने की शुरुआत करेंगे। और अगर हमारे पास एक विकल्प है: उपकरण के लिए या नहीं, तो "नहीं है" क्यों चुनें?

मुख्य चीज स्प्रेडशीट नहीं है, मुख्य चीज मॉडल है

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

• . Microsoft Excel Solver (« »). , Excel, . , , ( ) .

• (, , ). , : , , , . .

• कोई चार आयामी स्प्रेडशीट नहीं ; हम केवल दो-आयामी का उपयोग करेंगे।

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

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

स्पष्टीकरण

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

यहां कुछ सीमाओं के बारे में बताया गया है:

• . , , . , , . , , , , , .

• (). , . « », , Excel. ( / ), ( ), .

• . , - , , «» . . , , /, .

• . , Excel Solver, , , , . Solver , . , , « » . Solver ( Frontline ) , , Solver .

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

अंतिम और सबसे महत्वपूर्ण:

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

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

ऐसे मामलों में जहां व्यक्तिपरक पहलू होते हैं जिन्हें इस मॉडल में एम्बेड नहीं किया जा सकता है, उदाहरण के लिए, सौंदर्य संबंधी पहलू या प्रयोज्यता / playability पहलुओं, हमें या तो स्पष्ट रूप से उन्हें निर्णय मॉडल से अलग करने की आवश्यकता होगी, या पहले पास के रूप में निर्णय मॉडलिंग का उपयोग करें, या बस पूरी तरह से मॉडलिंग छोड़ दें ।

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

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

और यहां तक ​​कि जब समाधान मॉडल समस्या का इष्टतम समाधान नहीं ढूंढ सकता है, या तो क्योंकि कार्य बहुत जटिल है, या क्योंकि इसे सौंदर्य दृष्टिकोण और अन्य व्यक्तिपरक मानवीय कारकों की आवश्यकता है, यह अभी भी समाधान की सीमाओं को संकीर्ण करने में मदद कर सकता है, गतिरोध को समाप्त कर सकता है और अन्यथा समस्या की जटिलता को कम कर सकता है। ।

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

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

निष्कर्ष

अंत में, हम डिजाइन को सही ढंग से बनाना चाहते हैं ।

कई डिजाइन प्रश्न व्यक्तिपरक होते हैं, उनके पास "सही" या "गलत" उत्तर नहीं होते हैं। लेकिन कुछ मामलों में वे निश्चित रूप से हैं । और ऐसे मामलों में, हमें यह जानना होगा कि सही उत्तर कैसे प्राप्त करें, या कम से कम समझें कि "सही" उत्तर की परिभाषा से कैसे निपटा जाए और इसके समाधान की तलाश करें।

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

भाग 2. अनुकूलन की मूल बातें और सिमुलेशन की तैनाती

इस लेख के लिए स्प्रेडशीट यहां से डाउनलोड की जा सकती है ।

समाधान मॉडल तैयारी

अब जब हमने समाधान मॉडल के बारे में बात की है, तो बताया कि वे कैसे उपयोगी हैं और उनकी कुछ सीमाओं को सूचीबद्ध किया गया है, हम एक सरल उदाहरण के साथ बुनियादी अवधारणाओं को चित्रित करना चाहते हैं।

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

सरल शब्दों में, हमारे स्प्रेडशीट में चार प्रकार की कोशिकाएँ होंगी:

• — , — , . 0 - , . , , . .
• « » — . , , Tootsie Pop 17 0,25 , « ». .
• «» — , . .
• एक "लक्ष्य" (या "निकास") एक सेल है जिसका मूल्य हम ऑप्टिमाइज़र चलने पर कम से कम (या अधिकतम) करने का प्रयास करते हैं। हमारे उदाहरणों में, हमेशा केवल एक लक्ष्य सेल होगा, इसमें हमेशा एक नारंगी रंग और एक काली रूपरेखा होती है। ( नोट: अधिक शक्तिशाली सॉल्वर हैं जो कई लक्ष्यों के साथ काम करने का समर्थन करते हैं, लेकिन हमारे लेखों के लिए यह बहुत जटिल होगा।)

जब हम Microsoft Excel में निर्मित ऑप्टिमाइज़र (सॉल्वर टूल ("सॉल्यूशन फाइंडर") चलाते हैं, तो यह केवल हमारे द्वारा निर्दिष्ट लक्ष्य सेल को देखेगा और फिर निर्णय चर को बदलने की कोशिश करेगा, लेकिन यह (हमारे द्वारा निर्धारित सीमा के भीतर) या कम कर सकता है, या कर सकता है। इस लक्ष्य सेल (जो भी हम निर्दिष्ट करते हैं) के मूल्य को अधिकतम करें।

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

उदाहरण के लिए, यदि हम जानना चाहते थे कि टुटी पॉप के मध्य में जाने के लिए आपको कितनी बार चाटना चाहिए, तो हम एक समान स्प्रेडशीट का उपयोग कर सकते हैं:


हम एक्सेल सॉल्वर से टारगेट सेल को कम करने का आदेश देकर इस समस्या को हल करने के लिए कह सकते हैं "टोसी पॉप पर शेष द्रव्यमान", और वह जल्दी से प्रयोगों का उपयोग करके निर्धारित करेगा कि पीले समाधान सेल का मूल्य इस तरह का परिणाम देता है ( "Tootsie पॉप के बीच में जाने के लिए कितनी बार चाटना है") 68 है।

बेशक, ऐसा करना थोड़ा मूर्खतापूर्ण है, क्योंकि समस्या के बयान से यह स्पष्ट है कि उत्तर 17 / 0.25 = 68 होगा। यह एक समस्या को हल करने के लिए ऑप्टिमाइज़र को चलाने का कोई मतलब नहीं है जिसे सरल अंकगणित से हल किया जा सकता है।

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

हम कार्यों के विवरण पर ध्यान केंद्रित करेंगे, और सॉल्वर को सारी मेहनत छोड़ देंगे।

उदाहरण 1: कर

हमारे पहले वास्तविक निर्णय मॉडल में, हम इष्टतम कर दर निर्धारित करने का एक उदाहरण दिखाएंगे। कोई भी करों को पसंद नहीं करता है, लेकिन इस मामले में हम भुगतान नहीं करेंगे, लेकिन करों को प्राप्त करेंगे; मुझे उम्मीद है कि यह आपकी पीड़ा को कम करेगा।

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

मान लीजिए कि हम मानों की सीमा में 10% की वृद्धि के साथ कर दर को 0% से 50% तक इंगित कर सकते हैं। यहां एक स्क्रीनशॉट है जो मास्टर ऑफ ओरियन 2 की क्लासिक 4 एक्स रणनीति से एक समान प्रणाली दिखाता है:


डिजाइनरों के रूप में, हम एक साधारण सवाल पूछना चाहते हैं: सामान्य मामले में इष्टतम कर की दर क्या होगी?

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

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

चलिए कार्य का वर्णन इस प्रकार करते हैं:

• हमारे पास आकार 12 (जिसका अर्थ 12 मिलियन लोग हैं) का एक शहर है। इन लोगों को 12 अलग-अलग "नागरिकों" के रूप में दर्शाया गया है।
• किसी भी समय प्रत्येक नागरिक संतुष्ट या असंतुष्ट हो सकता है।
• संतुष्ट नागरिक करों के रूप में भुगतान करते हैं (कर की दर x 10) (उदाहरण के लिए, 20% की कर दर हमें प्रत्येक संतुष्ट नागरिक के लिए कर राजस्व में 2 इकाइयों की मुद्रा प्रदान करती है)।
• असंतुष्ट नागरिक कर का भुगतान नहीं करते हैं।
• शहर में 3 असंतुष्ट नागरिक हैं जो कर दर की परवाह किए बिना असंतुष्ट रहते हैं।
• निम्न सूत्र के आधार पर नागरिकों की एक अतिरिक्त संख्या अप्रसन्न हो जाती है: (जनसंख्या) x ((कर की दर) x (कर की दर) x 3.5, मान को निकटतम पूर्ण संख्या में गोल किया जाता है। आकार 12 के हमारे शहर के लिए, यह हमें 0% और 10% की दर से 0 अतिरिक्त असंतुष्ट नागरिकों, 20% की दर पर 1 अतिरिक्त असंतुष्ट नागरिक, 30% की दर से 3 अतिरिक्त असंतुष्ट नागरिकों, 40% की दर से 6 और 10 पर 10 अतिरिक्त नागरिक देगा। 50% की दर।

यह सरल है, है ना?

हम इस लेख के साथ संलग्न स्प्रेडशीट में इसका वर्णन करेंगे:


आप देख सकते हैं कि हमने टैक्स रेट को इंगित करने के अप्रत्यक्ष तरीके के रूप में पीले निर्णय बॉक्स (कर स्तर (0-5)) को निर्धारित किया है। सीधे कर दर को सेल में निर्दिष्ट करने के बजाय, कर दर गणना सेल निर्णय स्तर से कर स्तर संख्या लेता है और इसे 10% से गुणा करता है। अप्रत्यक्ष रूप से ऐसा करने का एक तार्किक कारण है, और हम इसे जल्द ही देखेंगे।

अब हम कर स्तर के सभी संभावित मूल्यों को प्रयोग और स्थानापन्न कर सकते हैं। आप कर स्तर सेल में 0 से 5 तक की संख्याओं में से प्रत्येक को दर्ज कर सकते हैं, और निम्नलिखित प्राप्त कर सकते हैं:


जैसा कि आप देख सकते हैं, एक इष्टतम कर की दर है: 30%, जो कर राजस्व को अधिकतम करता है, 18 इकाइयों को मुद्रा देता है।

चलो सिस्टम को स्वचालित करें!

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

जैसा कि हम देखेंगे, यह वही है जो सॉल्वर के लिए उपयोग किया जाता है।

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


यदि आप इसे नहीं देखते हैं, तो Excel विकल्प पर जाएँ, ऐड-इन्स श्रेणी का चयन करें, सुनिश्चित करें कि एक्सेल ऐड-इन्स को प्रबंधित करें ड्रॉप-डाउन सूची में चुना गया है। ), गो पर क्लिक करें और सुनिश्चित करें कि सॉल्वर ऐड-इन चेक किया गया है।

सॉल्वर बटन पर क्लिक करने के बाद, आपको एक समान संवाद बॉक्स देखना चाहिए।


आइए अब सॉल्वर संवाद बॉक्स की स्थापना में शामिल सभी चरणों पर एक नज़र डालें।

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

"परिवर्तनशील कोशिकाओं को बदलकर" खंड में, उन कोशिकाओं का चयन करें जिन्हें "समाधान खोजक" की गणना करनी चाहिए। हमें इष्टतम कर दर निर्धारित करने की आवश्यकता है, इसलिए पीले समाधान बॉक्स (टैक्स स्तर (0-5)) का चयन करें। यदि सब कुछ सही काम करता है, तो परिणामस्वरूप इस सेल को 30% की कर दर के अनुरूप 3 का मान सौंपा जाएगा, जिसकी इष्टतमता हम पहले से ही मैन्युअल गणना में निर्धारित कर चुके हैं।

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

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


हम दो बाधाओं को जोड़ देंगे, एक तो यह है कि कर स्तर निर्णय सेल की स्थिति को संतुष्ट करता है> = 0, और एक और ताकि निर्णय सेल <= 5. फिर, समाधान विधि सूची में, विकासवादी ("विकासवादी") का चयन करें एक समाधान के लिए खोज ") और हल पर क्लिक करें (" एक समाधान खोजें ")।

लगभग 30 सेकंड तक काम करने के बाद, सॉल्वर हमें एक समान जवाब देगा:


ओह, एक समस्या थी। सॉल्वर को आय की सही मात्रा प्राप्त हुई, लेकिन कर की दर गलत है। खिलाड़ी केवल 10% की वृद्धि के साथ कर निर्धारित कर सकता है, लेकिन सॉल्वर स्पष्ट रूप से आंशिक कर दरों को निर्धारित करता है, जो खिलाड़ी नहीं कर सकता।

आप कर की दर को पूरे संख्या तक सीमित करके समस्या का समाधान कर सकते हैं। यह केवल 0, 1, 2, 3, 4 या 5 के बराबर हो सकता है, लेकिन मध्यवर्ती मूल्यों के बिना।

सौभाग्य से, सॉल्वर में यह हासिल करना बहुत आसान हो सकता है। सॉल्वर खोलें, ऐड बटन पर क्लिक करें, टैक्स स्तर के समाधान सेल का चयन करें, और फिर बीच में ड्रॉप-डाउन सूची में आंतरिक प्रतिबंध का चयन करें:


अब सॉल्वर को फिर से चलाएं और निम्नलिखित प्राप्त करें:


आदर्श! थोड़े प्रयास से हमें सॉल्वर का सही उत्तर मिल गया। जैसा कि हम जल्द ही देखेंगे, कार्यों के पैमाने में वृद्धि के साथ, हमारे द्वारा उपकरण द्वारा किए गए कार्य की मात्रा, इसे स्थापित करने में लगने वाले समय से काफी अधिक है।

बढ़ता शहर

शहर मॉडल को थोड़ा जटिल करके अब कार्य का विस्तार करें।

किसी भी 4X रणनीति में, शहर (या ग्रह, या उपनिवेश, या अन्य आबाद इकाइयाँ) समय के साथ बढ़ते हैं। हम मानेंगे कि शहर में प्रति मोड़ 8% की निरंतर वृद्धि हुई है, 1,500 हजार (1.5 मिलियन) नागरिकों से शुरू होकर, 12 मिलियन निवासियों के आकार तक बढ़ रही है। अब हमारी स्प्रेडशीट इस तरह दिखाई देगी:


तालिका की प्रत्येक नई बाद की पंक्ति खेल के एक पाठ्यक्रम का वर्णन करती है।

हमने असंतोष के आधार स्तर की गणना को भी बदल दिया। अब इसकी गणना मूल जनसंख्या स्तर (लाखों में) के एक सेकंड के रूप में की जाती है, जिसे गोल किया जाता है। इसके कारण, मूल असंतोष 0 होगा जब तक कि शहर आकार 4 में नहीं बढ़ता है, जिसके बाद यह शहर के आकार के साथ रैखिक रूप से बढ़ेगा।

पहले की तरह, हम कर स्तर मानों को बदलकर कर स्तरों के साथ प्रयोग कर सकते हैं। हमें कर राजस्व में 0, 102, 190, 222, 144 और 65 इकाइयों की मुद्रा प्राप्त होगी, जिसमें प्रत्येक कर स्तर 0% से 50% है।

और फिर से हम इस समस्या को हल करने के लिए सॉल्वर प्राप्त कर सकते हैं; वह जल्दी से निर्धारित करेगा कि पहले की तरह इष्टतम कर की दर 30% है, जो हमें 222 मुद्रा इकाइयों की आय देती है। यहाँ सॉल्वर संवाद कैसा दिखता है:

परिवर्तनीय कर की दरें

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

क्या यह बहुत अच्छा नहीं होगा यदि हम न केवल एक एकल इष्टतम कर की दर निर्धारित कर सकते हैं, बल्कि प्रत्येक चाल में इष्टतम मूल्य की गणना भी कर सकते हैं?

वह तुरंत हमें बताएगी कि खिलाड़ी करों को कैसे समायोजित कर सकता है।

और यह पता चला कि यह किया जा सकता है! पहले से ही सही तरीके से समाधान मॉडल स्थापित करने के बाद, हम इसे अविश्वसनीय रूप से बस लागू कर सकते हैं।

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


अब एकल सॉल्वर को ऑप्टिमाइज़ करने के लिए सॉल्वर को मजबूर करने के बजाय, हम उसे पूरे टैक्स लेवल कॉलम को ऑप्टिमाइज़ करने की आज्ञा देते हैं। यह सॉल्वर डायलॉग जैसा दिखेगा - आप देख सकते हैं कि यह लगभग पहले जैसा ही है, केवल एक सेल के बजाय वैरिएबल और प्रतिबंध अब टैक्स लेवल कॉलम में सेल की एक पूरी श्रृंखला का प्रतिनिधित्व करते हैं।


सॉल्वर वास्तव में यह साबित करता है कि कर की दर में बदलाव के परिणाम बदल जाते हैं - संचयी आय अब 232 मुद्रा इकाइयों पर खड़ी है। समान कर दर की तुलना में, विकास केवल 5% (232 इकाइयों के खिलाफ 222) है, लेकिन यह अभी भी महत्वपूर्ण है क्योंकि हम जानते हैं कि कुछ खिलाड़ी इसे प्राप्त करने में सक्षम होंगे।

सॉल्वर प्राप्त समाधान पर करीब से नज़र डालें, तो आप देख सकते हैं कि यह 50% की कर दर से शुरू होता है, क्योंकि आकार 1 के शहर में असंतोष पैदा करने के लिए पर्याप्त लोग नहीं हैं। शहर के विकास की प्रक्रिया में, उपकरण 20% से 30% तक सीमा में प्रत्येक मोड़ में कर की दर को बदल देता है, जिसके आधार पर व्यक्ति अधिक आय लाएगा।

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

निष्कर्ष

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

यह स्थिति एक दिलचस्प प्रश्न की ओर ले जाती है: क्या यही हम चाहते हैं? क्या खिलाड़ियों के यांत्रिकी उनके लिए प्रत्येक स्तर पर कर के स्तर के micromanagement में संलग्न करना आवश्यक बनाते हैं? और क्या हम सत्ता-उन्मुख गेमर्स को सिस्टम को इस तरह से हरा देने की अनुमति देना चाहते हैं; क्या ऐसी चाल 5% के उनके लाभ से मेल खाती है?

मैं इन सवालों का जवाब नहीं दे सकता। अंत में, आप एक डिज़ाइनर हैं, जो डिज़ाइन लक्ष्य निर्धारित करते हैं, इसलिए यह तय करना है कि सिस्टम ऑपरेशन का यह स्तर आपके द्वारा गेम के लिए निर्धारित लक्ष्यों को पूरा करता है या नहीं।

बेशक, यह मॉडल सिर्फ एक नंगे फ्रेम है। वास्तविक 4X रणनीति में, खिलाड़ी शहर को विकसित करने, इमारतों के निर्माण और शहर के विकास, संतोष, कर राजस्व और उत्पादकता को प्रभावित करने वाले अन्य परिवर्तन करने के बारे में सभी प्रकार के निर्णय ले सकते हैं।

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

अगले लेख में, हम अपने वादे को पूरा करेंगे और परिचयात्मक लेख से उदाहरण में सुपरटैंक के लिए हथियारों की खरीद का अनुकूलन करेंगे।