🤦 🤷🏼 💂 अगर आप कभी कलाकार नहीं हैं तो गेम कैसे बनाएं 👨🏽‍🎓 🧗🏻 😣

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

और नहीं ...

छोटा सा परिचय

मैं तुरंत आरक्षण करूंगा: हमारा लक्ष्य पैसा कमाना नहीं है - हैबे पर इस विषय पर बहुत सारे लेख हैं। नहीं, हम एक सपने का खेल बनाएंगे।

सपनों के खेल के बारे में गेय विषयांतर

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

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

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

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

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

“आह !!! आतंक! एक बुरा सपना! ऐसे बकवास पर आप कैसे समय बिता सकते हैं! यहाँ से चले जाओ, मैं कुछ और दिलचस्प पढ़ने जाऊँगा! "

ऐसा क्यों? मेरा मतलब है, पहिया को सुदृढ़ करें? रेडीमेड गेम इंजन का उपयोग क्यों नहीं किया जाता है? इसका उत्तर सरल है: हम उसके बारे में कुछ भी नहीं जानते हैं, लेकिन हम अब खेल चाहते हैं। औसत प्रोग्रामर की मानसिकता की कल्पना करें: “मैं एक खेल बनाना चाहता हूँ! मांस, और विस्फोट, और पंपिंग होंगे, ~~और आप एक कोरोवन लूट सकते हैं~~ , और साजिश बमबारी कर रही है, और यह कहीं और कभी नहीं हुआ है! मैं अभी लिखना शुरू करूँगा! .. और किस पर? आइए देखें कि अब हमारे साथ क्या लोकप्रिय है ... हाँ, एक्स, वाई और जेड। चलो जेड लेते हैं, अब हर कोई इस पर लिखता है ... "। और इंजन का अध्ययन करना शुरू कर देता है। और वह विचार फेंकता है, क्योंकि इसके लिए पहले से ही पर्याप्त समय नहीं है। फिन। या, ठीक है, यह हार नहीं मानता, लेकिन वास्तव में इंजन को सीखे बिना, यह खेलना शुरू कर देता है। ठीक है, अगर तब वह किसी को अपना पहला "शिल्प" नहीं दिखाने का विवेक रखता है। आमतौर पर नहीं (किसी भी एप्लिकेशन स्टोर पर जाएं, अपने लिए देखें) - ठीक है, ठीक है, मुझे मुनाफा चाहिए, सहन करने की ताकत नहीं। एक बार खेलों के निर्माण में उत्साही रचनात्मक लोगों की बहुत कमी थी। काश, इस समय को पूरी तरह से पारित कर दिया गया है - अब खेल में मुख्य चीज आत्मा नहीं है, लेकिन व्यवसाय मॉडल (कम से कम इसके बारे में बहुत अधिक बात कर रहे हैं)। हमारा लक्ष्य सरल है: हम आत्मा के साथ खेल बनाएंगे। इसलिए, हम उपकरण से सार करते हैं (कोई भी करेगा) और कार्य पर ध्यान केंद्रित करता है।

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

विकल्प हैं:

1. एक सरल चित्रमय संपादक में अपने आप को सब कुछ ड्रा करें

खेल का स्क्रीनशॉट "उसे मार डालो", 2003

2. एक वेक्टर में अपने आप को सब कुछ ड्रा करें

खेल "रेवेन", 2001 के स्क्रीनशॉट

खेल का स्क्रीनशॉट "इन्फर्नो", 2002

3. एक ऐसे भाई से पूछिए जो यह भी नहीं जानता कि कैसे आकर्षित किया जाए (लेकिन यह थोड़ा बेहतर है)

खेल का स्क्रीनशॉट "कमबख्त", 2004

4. 3D-मॉडलिंग के लिए कुछ प्रोग्राम डाउनलोड करें और वहां से संपत्ति खींचें

खेल का स्क्रीनशॉट "कमबख्त 2. डेमो", 2006

5. हताशा में, सिर पर बाल फाड़कर

खेल का स्क्रीनशॉट "कमबख्त", 2004

6. छद्म विज्ञान (ASCII) में अपने आप को सब कुछ ड्रा करें

खेल का स्क्रीनशॉट "फीफा", 2000

खेल "सूमो", 1998 का स्क्रीनशॉट

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

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

उपरोक्त लंबे परिचय का उद्देश्य नौसिखिया इग्रोडेलोव को आशंकाओं और पूर्वाग्रहों को दूर करने में मदद करना था, चिंता करना बंद करो और फिर भी ऐसा कुछ करने की कोशिश करो। क्या आप तैयार हैं? तो चलिए शुरू करते हैं।

पहला कदम। विचार

कैसे? अभी भी कोई पता नहीं है?

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

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

लेकिन हम सरल तरीके से जाएंगे - मान लें कि हमारे पास पहले से ही एक विचार है, और हमने लंबे समय तक इसके बारे में नहीं सोचा है। हमारी पहली भव्य परियोजना के रूप में, हम ओब्सीडियन - पाथफाइंडर एडवेंचर्स से एक अच्छे खेल का एक क्लोन बनाएंगे।

“यह क्या मुसीबत है! कोई टेबल? ”

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

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

नियमों से परिचित नहीं लोगों के लिए, एक संक्षिप्त परिचय:

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

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

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

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

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

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

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

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

चरण दो डिज़ाइन

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

सबसे पहले, आपका डिज़ाइन दस्तावेज़ कुछ इस तरह दिखाई देगा

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

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

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

“लेखक, खुद को दीवार के खिलाफ मार लो। बहुत सारे पत्र। ”

चरण तीन मोडलिंग

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

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

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

मामलों का उपयोग करें

"उह ... यह सब क्या है?"

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

इस बिंदु को निम्नलिखित घटकों के आरेख में विस्तृत किया जा सकता है:

सिस्टम घटक

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

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

अगर आप खड़े हैं, तो बैठ जाइए

और अंत में, एक इनपुट-आउटपुट सिस्टम के माध्यम से सामान्य शब्दों में गेम इंजन के साथ अंतिम उपयोगकर्ता की बातचीत के अनुक्रम को प्रस्तुत करना अच्छा होगा।

सॉस

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

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

चरण चार उपकरण चयन

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

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

दरअसल, हमें किसी और चीज की जरूरत नहीं है। आप विकास शुरू कर सकते हैं।

चरण पाँच प्रोजेक्ट बनाना और स्थापित करना

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

 <modelVersion>4.0.0</modelVersion> <groupId>my.company</groupId> <artifactId>dice</artifactId> <version>1.0</version> <packaging>jar</packaging>

कोटलिन समर्थन भी जोड़ें, जो डिफ़ॉल्ट रूप से गायब है:

 <dependency> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-stdlib</artifactId> <version>${kotlin.version}</version> </dependency>

और कुछ सेटिंग्स जो हम विस्तार से नहीं बताएंगे:

 <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <kotlin.version>1.3.20</kotlin.version> <kotlin.compiler.incremental>true</kotlin.compiler.incremental> </properties>

हाइब्रिड परियोजनाओं के संबंध में थोड़ी जानकारी

यदि आप अपने प्रोजेक्ट में जावा और कोटलिन दोनों का उपयोग करने की योजना बनाते हैं, तो src/main/kotlin , आपके पास src/main/java फ़ोल्डर भी होगा। कोटलिन डेवलपर्स का दावा है कि पहले फ़ोल्डर ( *.kt ) से स्रोत फ़ाइलों को दूसरे फ़ोल्डर ( *.java ) से स्रोत फ़ाइलों की तुलना में पहले संकलित किया जाना चाहिए और इसलिए दृढ़ता से अनुशंसा करते हैं कि आप मानक मावेन लक्ष्यों के लिए सेटिंग्स बदल दें:

 <build> <plugins> <plugin> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-maven-plugin</artifactId> <version>${kotlin.version}</version> <executions> <execution> <id>compile</id> <phase>process-sources</phase> <goals> <goal>compile</goal> </goals> <configuration> <sourceDirs> <sourceDir>${project.basedir}/src/main/kotlin</sourceDir> <sourceDir>${project.basedir}/src/main/java</sourceDir> </sourceDirs> </configuration> </execution> <execution> <id>test-compile</id> <goals> <goal>test-compile</goal> </goals> <configuration> <sourceDirs> <sourceDir>${project.basedir}/src/test/kotlin</sourceDir> <sourceDir>${project.basedir}/src/test/java</sourceDir> </sourceDirs> </configuration> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.5.1</version> <executions> <!-- Replacing default-compile --> <execution> <id>default-compile</id> <phase>none</phase> </execution> <!-- Replacing default-testCompile --> <execution> <id>default-testCompile</id> <phase>none</phase> </execution> <execution> <id>java-compile</id> <phase>compile</phase> <goals> <goal>compile</goal> </goals> </execution> <execution> <id>java-test-compile</id> <phase>test-compile</phase> <goals> <goal>testCompile</goal> </goals> </execution> </executions> </plugin> </plugins> </build>

मैं यह नहीं कह सकता कि यह कितना महत्वपूर्ण है - परियोजनाएं इस शीट के बिना काफी अच्छी तरह से चल रही हैं। लेकिन सिर्फ मामले में, आपको चेतावनी दी जाती है।

आइए एक ही बार में तीन पैकेज बनाएं (क्यों कुछ को रौंदें?):

model - उन वर्गों के लिए जो खेल की दुनिया की वस्तुओं का वर्णन करते हैं;
game - गेमप्ले को लागू करने वाली कक्षाओं के लिए;
ui - उपयोगकर्ता बातचीत के लिए जिम्मेदार वर्गों के लिए।

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

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

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

mvn package ऑपरेशन पूरा होने के बाद, हमें सभी संकलित कक्षाओं के साथ JAR आर्काइव का आउटपुट मिलता है। सबसे पहले, डिफ़ॉल्ट रूप से, इस संग्रह में परियोजना के काम करने के लिए आवश्यक निर्भरता शामिल नहीं है (अब तक हमारे पास उनके पास नहीं है, लेकिन वे निश्चित रूप से भविष्य में दिखाई देंगे)। दूसरे, main विधि से युक्त मुख्य वर्ग के लिए पथ संग्रह मेनिफ़ेस्ट फ़ाइल में निर्दिष्ट नहीं है, इसलिए हम java -jar dice-1.0.jar साथ परियोजना शुरू java -jar dice-1.0.jar नहीं होंगे। pom.xml अतिरिक्त सेटिंग्स जोड़कर इसे ठीक करें:

 <build> <plugins> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.6</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifest> <mainClass>my.company.dice.MainKt</mainClass> </manifest> </archive> </configuration> </plugin> </plugins> </build>

मुख्य वर्ग के नाम पर ध्यान दें। कोटलिन कार्यों के लिए कक्षाओं के बाहर निहित (जैसे main कार्य), कक्षाएं वैसे भी संकलन के दौरान बनाई जाती हैं (क्योंकि जेवीएम कुछ भी नहीं जानता है और जानना नहीं चाहता है)। इस वर्ग का नाम Kt साथ फाइल का नाम है। यही है, अगर आपने मुख्य वर्ग का नाम मेन रखा है, तो इसे MainKt.class फ़ाइल में संकलित किया जाएगा। यह पिछले एक है जिसे हमें जार फ़ाइल के प्रकट होने में इंगित करना चाहिए।

अब, प्रोजेक्ट बनाते समय, हमें आउटपुट पर दो जार फाइलें dice-1.0.jar : dice-1.0.jar और dice-1.0-jar-with-dependencies.jar । हम दूसरे में रुचि रखते हैं। हम इसके लिए एक लॉन्च स्क्रिप्ट लिखेंगे।

dice.bat (विंडोज के लिए)

 @ECHO OFF rem Compiling call "path_to_maven\mvn.bat" -f "path_to_project\Dice\pom.xml" package if errorlevel 1 echo Project compilation failed! & pause & goto :EOF rem Running java -jar path_to_project\Dice\target\dice-1.0-jar-with-dependencies.jar pause

dice.sh (UNIX के लिए)

 #!/bin/sh # Compiling mvn -f "path_to_project/Dice/pom.xml" package if [[ "$?" -ne 0 ]] ; then echo 'Project compilation failed!'; exit $rc fi # Running java -jar path_to_project/Dice/target/dice-1.0-jar-with-dependencies.jar

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

तो, परियोजना ठीक शुरू होती है, लेकिन अभी तक कुछ भी नहीं करता है। चिंता न करें, हम इसे जल्द ही ठीक कर लेंगे।

चरण छह मुख्य वस्तुएं

धीरे-धीरे, हम गेमप्ले के लिए आवश्यक कक्षाओं के साथ model पैकेज भरना शुरू कर देंगे।

वर्ग आरेख

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

वर्ग Comparable इंटरफ़ेस को लागू करता है Comparable क्यूब्स की एक दूसरे के साथ तुलना की जा सके (उपयोगी बाद में जब हम एक आदेशित पंक्ति में कई क्यूब्स प्रदर्शित करेंगे)। बड़े क्यूब्स को पहले रखा जाएगा।

 class Die(val type: Type, val size: Int) : Comparable<Die> { enum class Type { PHYSICAL, //Blue SOMATIC, //Green MENTAL, //Purple VERBAL, //Yellow DIVINE, //Cyan WOUND, //Gray ENEMY, //Red VILLAIN, //Orange OBSTACLE, //Brown ALLY //White } fun roll() = (1.. size).random() override fun toString() = "d$size" override fun compareTo(other: Die): Int { return compareValuesBy(this, other, Die::type, { -it.size }) } }

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

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

 open class Bag { protected val dice = LinkedList<Die>() val size get() = dice.size fun put(vararg dice: Die) { dice.forEach(this.dice::addLast) this.dice.shuffle() } fun draw(): Die = dice.pollFirst() fun clear() = dice.clear() fun examine() = dice.sorted().toList() }

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

 class Pile : Bag() { fun removeDie(die: Die) = dice.remove(die) }

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

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

 data class Hero(val type: Type) { enum class Type { BRAWLER HUNTER } var name = "" var isAlive = true var favoredDieType: Die.Type = Die.Type.ALLY val hand = Hand(0) val bag: Bag = Bag() val discardPile: Pile = Pile() private val diceLimits = mutableListOf<DiceLimit>() private val skills = mutableListOf<Skill>() private val dormantSkills = mutableListOf<Skill>() fun addDiceLimit(limit: DiceLimit) = diceLimits.add(limit) fun getDiceLimits(): List<DiceLimit> = Collections.unmodifiableList(diceLimits) fun addSkill(skill: Skill) = skills.add(skill) fun getSkills(): List<Skill> = Collections.unmodifiableList(skills) fun addDormantSkill(skill: Skill) = dormantSkills.add(skill) fun getDormantSkills(): List<Skill> = Collections.unmodifiableList(dormantSkills) fun increaseDiceLimit(type: Die.Type) { diceLimits.find { it.type == type }?.let { when { it.current < it.maximal -> it.current++ else -> throw IllegalArgumentException("Already at maximum") } } ?: throw IllegalArgumentException("Incorrect type specified") } fun hideDieFromHand(die: Die) { bag.put(die) hand.removeDie(die) } fun discardDieFromHand(die: Die) { discardPile.put(die) hand.removeDie(die) } fun hasSkill(type: Skill.Type) = skills.any { it.type == type } fun improveSkill(type: Skill.Type) { dormantSkills .find { it.type == type } ?.let { skills.add(it) dormantSkills.remove(it) } skills .find { it.type == type } ?.let { when { it.level < it.maxLevel -> it.level += 1 else -> throw IllegalStateException("Skill already maxed out") } } ?: throw IllegalArgumentException("Skill not found") } }

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

 class Hand(var capacity: Int) { private val dice = LinkedList<Die>() private val allies = LinkedList<Die>() val dieCount get() = dice.size val allyDieCount get() = allies.size fun dieAt(index: Int) = when { (index in 0 until dieCount) -> dice[index] else -> null } fun allyDieAt(index: Int) = when { (index in 0 until allyDieCount) -> allies[index] else -> null } fun addDie(die: Die) = when { die.type == Die.Type.ALLY -> allies.addLast(die) else -> dice.addLast(die) } fun removeDie(die: Die) = when { die.type == Die.Type.ALLY -> allies.remove(die) else -> dice.remove(die) } fun findDieOfType(type: Die.Type): Die? = when (type) { Die.Type.ALLY -> if (allies.isNotEmpty()) allies.first else null else -> dice.firstOrNull { it.type == type } } fun examine(): List<Die> = (dice + allies).sorted() }

DiceLimit वर्ग की वस्तुओं का संग्रह प्रत्येक प्रकार के क्यूब्स की संख्या पर सीमा DiceLimit है जो स्क्रिप्ट की शुरुआत में नायक के पास हो सकता है। कहने के लिए कुछ विशेष नहीं है, हम शुरू में निर्धारित करते हैं, प्रत्येक प्रकार के लिए अधिकतम और वर्तमान मान।

 class DiceLimit(val type: Die.Type, val initial: Int, val maximal: Int, var current: Int)

लेकिन कौशल के साथ यह अधिक दिलचस्प है। उनमें से प्रत्येक को व्यक्तिगत रूप से (जिसके बारे में बाद में) लागू किया जाएगा, लेकिन हम केवल दो पर विचार करेंगे: हिट और शूट (क्रमशः प्रत्येक वर्ग के लिए एक)। प्रारंभिक से अधिकतम स्तर तक कौशल विकसित किया जा सकता है ("पंप"), जो अक्सर पासा के रोल में जोड़े जाने वाले संशोधक को प्रभावित करता है। यह गुण level , maxLevel level , modifier1 और modifier2 में maxLevel है।

 class Skill(val type: Type) { enum class Type { //Brawler HIT, //Hunter SHOOT, } var level = 1 var maxLevel = 3 var isActive = true var modifier1 = 0 var modifier2 = 0 }

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

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

“मुझे कुछ बीमार हो गया। मुझे धूम्रपान करना होगा या कुछ और ... "

और हम जारी रखेंगे।
महान और भयानक गेम मैकेनिक्स - नायकों और उनकी क्षमताओं का वर्णन किया गया है, यह विरोधी ताकतों के लिए आगे बढ़ने का समय है। या यों कहें, जिन वस्तुओं के साथ हमारे नायकों को बातचीत करनी होती है।

एक और वर्ग आरेख

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

 sealed class Threat { var name: String = "" var description: String = "" private val traits = mutableListOf<Trait>() fun addTrait(trait: Trait) = traits.add(trait) fun getTraits(): List<Trait> = traits } class Obstacle(val tier: Int, vararg val dieTypes: Die.Type) : Threat() class Villain : Threat() class Enemy : Threat() enum class Trait { MODIFIER_PLUS_ONE, //Add +1 modifier MODIFIER_PLUS_TWO, //Add +2 modifier }

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

 fun getTraits(): List<Trait> = Collections.unmodifiableList(traits)

लेकिन हम इस मुद्दे पर संपर्क करने में इतने लापरवाह नहीं होंगे (आप, हालांकि, चेतावनी दी गई है)।

खेल यांत्रिकी की ख़ासियत के कारण, Obstacle क्षेत्र अतिरिक्त क्षेत्रों की उपस्थिति में अपने समकक्षों से भिन्न होता है, लेकिन हम उन पर ध्यान केंद्रित नहीं करेंगे।

धमकी कार्ड (और यदि आप ध्यान से डिजाइन दस्तावेज़ पढ़ते हैं, तो याद रखें कि ये कार्ड हैं) Deck वर्ग द्वारा दर्शाए गए डेक में संयुक्त हैं:

 class Deck<E: Threat> { private val cards = LinkedList<E>() val size get() = cards.size fun addToTop(card: E) = cards.addFirst(card) fun addToBottom(card: E) = cards.addLast(card) fun revealTop(): E = cards.first fun drawFromTop(): E = cards.removeFirst() fun shuffle() = cards.shuffle() fun clear() = cards.clear() fun examine() = cards.toList() }

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

... Location वर्ग में, जिसका प्रत्येक उदाहरण एक अद्वितीय इलाके का वर्णन करता है जिसे हमारे नायकों को स्क्रिप्ट के भाग के रूप में देखना होगा।

 class Location { var name: String = "" var description: String = "" var isOpen = true var closingDifficulty = 0 lateinit var bag: Bag var villain: Villain? = null lateinit var enemies: Deck<Enemy> lateinit var obstacles: Deck<Obstacle> private val specialRules = mutableListOf<SpecialRule>() fun addSpecialRule(rule: SpecialRule) = specialRules.add(rule) fun getSpecialRules() = specialRules }

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

अंत में, यह स्क्रिप्ट को लागू करने के लिए बनी हुई है ( Scenario वर्ग):

 class Scenario { var name = "" var description = "" var level = 0 var initialTimer = 0 private val allySkills = mutableListOf<AllySkill>() private val specialRules = mutableListOf<SpecialRule>() fun addAllySkill(skill: AllySkill) = allySkills.add(skill) fun getAllySkills(): List<AllySkill> = Collections.unmodifiableList(allySkills) fun addSpecialRule(rule: SpecialRule) = specialRules.add(rule) fun getSpecialRules(): List<SpecialRule> = Collections.unmodifiableList(specialRules) }

प्रत्येक परिदृश्य को टाइमर के स्तर और प्रारंभिक मूल्य की विशेषता है। जैसा पहले देखा गया था, specialRules (विशेष नियम) और सहयोगियों के कौशल निर्धारित किए जाते हैं (हम विचार से चूक जाएंगे)। आप सोच सकते हैं कि स्क्रिप्ट में स्थानों ( Location वर्ग की वस्तुओं) की एक सूची भी होनी चाहिए और, तार्किक रूप से, यह वास्तव में ऐसा है। लेकिन जैसा कि बाद में देखा जाएगा, हम कहीं भी इस तरह के कनेक्शन का उपयोग नहीं करेंगे और यह कोई तकनीकी लाभ नहीं देता है।

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

"अच्छी तरह से ..."

सातवाँ चरण। पैटर्न और जेनरेटर

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

 val location = Location().apply { name = "Some location" description = "Some description" isOpen = true closingDifficulty = 4 bag = Bag().apply { put(Die(Die.Type.PHYSICAL, 4)) put(Die(Die.Type.SOMATIC, 4)) put(Die(Die.Type.MENTAL, 4)) put(Die(Die.Type.ENEMY, 6)) put(Die(Die.Type.OBSTACLE, 6)) put(Die(Die.Type.VILLAIN, 6)) } villain = Villain().apply { name = "Some villain" description = "Some description" addTrait(Trait.MODIFIER_PLUS_ONE) } enemies = Deck<Enemy>().apply { addToTop(Enemy().apply { name = "Some enemy" description = "Some description" }) addToTop(Enemy().apply { name = "Other enemy" description = "Some description" }) shuffle() } obstacles = Deck<Obstacle>().apply { addToTop(Obstacle(1, Die.Type.PHYSICAL, Die.Type.VERBAL).apply { name = "Some obstacle" description = "Some Description" }) } }

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

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

किसी टेम्प्लेट से ऑब्जेक्ट जेनरेट करने की प्रक्रिया

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

वर्ग आरेख

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

आइए कुछ सरल - उत्पादक क्यूब्स के साथ शुरू करें। "कैसे? - आप कहते हैं। - क्या हम पर्याप्त निर्माता नहीं हैं? हाँ, यह एक प्रकार और आकार के साथ है। ” नहीं, मैं जवाब नहीं दूंगा, पर्याप्त नहीं है। वास्तव में, कई मामलों में (नियमों को पढ़ें), क्यूब्स को मनमाने ढंग से राशि में उत्पन्न किया जाना चाहिए (उदाहरण के लिए: "या तो नीले या हरे रंग के एक से तीन क्यूब्स से")। इसके अलावा, आकार को स्क्रिप्ट की जटिलता के स्तर के आधार पर चुना जाना चाहिए। इसलिए, हम एक विशेष इंटरफ़ेस पेश करते हैं DieTypeFilter।

 interface DieTypeFilter { fun test(type: Die.Type): Boolean }

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

 class SingleDieTypeFilter(val type: Die.Type): DieTypeFilter { override fun test(type: Die.Type) = (this.type == type) } class InvertedSingleDieTypeFilter(val type: Die.Type): DieTypeFilter { override fun test(type: Die.Type) = (this.type != type) } class MultipleDieTypeFilter(vararg val types: Die.Type): DieTypeFilter { override fun test(type: Die.Type) = (type in types) } class InvertedMultipleDieTypeFilter(vararg val types: Die.Type): DieTypeFilter { override fun test(type: Die.Type) = (type !in types) }

क्यूब का आकार भी मनमाने ढंग से निर्धारित किया जाएगा, लेकिन बाद में उस पर और अधिक। इस बीच, हम एक क्यूब्स जनरेटर ( DieGenerator) लिखेंगे , जो कि क्लास कंस्ट्रक्टर के विपरीत Die, क्यूब के स्पष्ट प्रकार और आकार को स्वीकार नहीं करेगा, लेकिन फ़िल्टर और जटिलता का स्तर।

 private val DISTRIBUTION_LEVEL1 = intArrayOf(4, 4, 4, 4, 6, 6, 6, 6, 8) private val DISTRIBUTION_LEVEL2 = intArrayOf(4, 6, 6, 6, 6, 8, 8, 8, 8, 10) private val DISTRIBUTION_LEVEL3 = intArrayOf(6, 8, 8, 8, 10, 10, 10, 10, 12, 12, 12) private val DISTRIBUTIONS = arrayOf( intArrayOf(4), DISTRIBUTION_LEVEL1, DISTRIBUTION_LEVEL2, DISTRIBUTION_LEVEL3 ) fun getMaxLevel() = DISTRIBUTIONS.size - 1 fun generateDie(filter: DieTypeFilter, level: Int) = Die(generateDieType(filter), generateDieSize(level)) private fun generateDieType(filter: DieTypeFilter): Die.Type { var type: Die.Type do { type = Die.Type.values().random() } while (!filter.test(type)) return type } private fun generateDieSize(level: Int) = DISTRIBUTIONS[if (level < 1 || level > getMaxLevel()) 0 else level].random()

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

दो निजी तरीके अलग से क्यूब के प्रकार और आकार उत्पन्न करते हैं - प्रत्येक के बारे में कुछ दिलचस्प कहा जा सकता है। विधि generateDieType()को एक इनपुट फ़िल्टर के साथ पास करके अनंत लूप में संचालित किया जा सकता है

 override fun test(filter: DieTypeFilter) = false

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

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

 class BagTemplate { class Plan(val minQuantity: Int, val maxQuantity: Int, val filter: DieTypeFilter) val plans = mutableListOf<Plan>() fun addPlan(minQuantity: Int, maxQuantity: Int, filter: DieTypeFilter) { plans.add(Plan(minQuantity, maxQuantity, filter)) } }

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

 private fun realizePlan(plan: BagTemplate.Plan, level: Int): Array<Die> { val count = (plan.minQuantity..plan.maxQuantity).shuffled().last() return (1..count).map { generateDie(plan.filter, level) }.toTypedArray() } fun generateBag(template: BagTemplate, level: Int): Bag { return template.plans.asSequence() .map { realizePlan(it, level) } .fold(Bag()) { b, d -> b.put(*d); b } } }

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

अपने आप से, बैग मैदान पर झूठ नहीं बोलेंगे - आपको उन्हें नायकों और स्थानों को देने की आवश्यकता है। उत्तरार्द्ध से शुरू करते हैं।

 interface LocationTemplate { val name: String val description: String val bagTemplate: BagTemplate val basicClosingDifficulty: Int val enemyCardsCount: Int val obstacleCardsCount: Int val enemyCardPool: Collection<EnemyTemplate> val obstacleCardPool: Collection<ObstacleTemplate> val specialRules: List<SpecialRule> }

कोटलिन भाषा में, विधियों के बजाय, get()आप इंटरफ़ेस गुणों का उपयोग कर सकते हैं - यह बहुत अधिक संक्षिप्त है। हम पहले से ही बैग टेम्पलेट से परिचित हैं, शेष विधियों पर विचार करें। संपत्ति basicClosingDifficultyइलाके को बंद करने के लिए चेक की मूल जटिलता निर्धारित करेगी। यहां "मूल" शब्द का अर्थ केवल यह है कि अंतिम जटिलता परिदृश्य के स्तर पर निर्भर करेगी और इस स्तर पर अस्पष्ट है। इसके अलावा, हमें दुश्मनों और बाधाओं (और एक ही समय में खलनायक) के लिए पैटर्न को परिभाषित करने की आवश्यकता है। इसके अलावा, टेम्पलेट में वर्णित दुश्मनों और बाधाओं की विविधता से, सभी का उपयोग नहीं किया जाएगा, लेकिन केवल एक सीमित संख्या (पुनरावृत्ति मूल्य बढ़ाने के लिए)। कृपया ध्यान दें कि क्षेत्र के विशेष नियम ( SpecialRule) एक सरल गणना ( enum class) द्वारा कार्यान्वित किए जाते हैं , और इसलिए उन्हें अलग टेम्पलेट की आवश्यकता नहीं होती है।

 interface EnemyTemplate { val name: String val description: String val traits: List<Trait> } interface ObstacleTemplate { val name: String val description: String val tier: Int val dieTypes: Array<Die.Type> val traits: List<Trait> } interface VillainTemplate { val name: String val description: String val traits: List<Trait> }

और जनरेटर को न केवल व्यक्तिगत वस्तुओं को बनाने दें, बल्कि उनके साथ पूरे डेक भी।

 fun generateVillain(template: VillainTemplate) = Villain().apply { name = template.name description = template.description template.traits.forEach { addTrait(it) } } fun generateEnemy(template: EnemyTemplate) = Enemy().apply { name = template.name description = template.description template.traits.forEach { addTrait(it) } } fun generateObstacle(template: ObstacleTemplate) = Obstacle(template.tier, *template.dieTypes).apply { name = template.name description = template.description template.traits.forEach { addTrait(it) } } fun generateEnemyDeck(types: Collection<EnemyTemplate>, limit: Int?): Deck<Enemy> { val deck = types .map { generateEnemy(it) } .shuffled() .fold(Deck<Enemy>()) { d, c -> d.addToTop(c); d } limit?.let { while (deck.size > it) deck.drawFromTop() } return deck } fun generateObstacleDeck(templates: Collection<ObstacleTemplate>, limit: Int?): Deck<Obstacle> { val deck = templates .map { generateObstacle(it) } .shuffled() .fold(Deck<Obstacle>()) { d, c -> d.addToTop(c); d } limit?.let { while (deck.size > it) deck.drawFromTop() } return deck }

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

 fun generateLocation(template: LocationTemplate, level: Int) = Location().apply { name = template.name description = template.description bag = generateBag(template.bagTemplate, level) closingDifficulty = template.basicClosingDifficulty + level * 2 enemies = generateEnemyDeck(template.enemyCardPool, template.enemyCardsCount) obstacles = generateObstacleDeck(template.obstacleCardPool, template.obstacleCardsCount) template.specialRules.forEach { addSpecialRule(it) } }

अध्याय की शुरुआत में हम जिस इलाके को स्पष्ट रूप से कोड में सेट करते हैं, वह अब पूरी तरह से अलग रूप लेगा:

 class SomeLocationTemplate: LocationTemplate { override val name = "Some location" override val description = "Some description" override val bagTemplate = BagTemplate().apply { addPlan(1, 1, SingleDieTypeFilter(Die.Type.PHYSICAL)) addPlan(1, 1, SingleDieTypeFilter(Die.Type.SOMATIC)) addPlan(1, 2, SingleDieTypeFilter(Die.Type.MENTAL)) addPlan(2, 2, MultipleDieTypeFilter(Die.Type.ENEMY, Die.Type.OBSTACLE)) } override val basicClosingDifficulty = 2 override val enemyCardsCount = 2 override val obstacleCardsCount = 1 override val enemyCardPool = listOf( SomeEnemyTemplate(), OtherEnemyTemplate() ) override val obstacleCardPool = listOf( SomeObstacleTemplate() ) override val specialRules = emptyList<SpecialRule>() } class SomeEnemyTemplate: EnemyTemplate { override val name = "Some enemy" override val description = "Some description" override val traits = emptyList<Trait>() } class OtherEnemyTemplate: EnemyTemplate { override val name = "Other enemy" override val description = "Some description" override val traits = emptyList<Trait>() } class SomeObstacleTemplate: ObstacleTemplate { override val name = "Some obstacle" override val description = "Some description" override val traits = emptyList<Trait>() override val tier = 1 override val dieTypes = arrayOf( Die.Type.PHYSICAL, Die.Type.VERBAL ) } val location = generateLocation(SomeLocationTemplate(), 1)

परिदृश्य पीढ़ी एक समान तरीके से घटित होगी।

 interface ScenarioTemplate { val name: String val description: String val initialTimer: Int val staticLocations: List<LocationTemplate> val dynamicLocationsPool: List<LocationTemplate> val villains: List<VillainTemplate> val specialRules: List<SpecialRule> fun calculateDynamicLocationsCount(numberOfHeroes: Int) = numberOfHeroes + 2 }

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

 fun generateScenario(template: ScenarioTemplate, level: Int) = Scenario().apply { name =template.name description = template.description this.level = level initialTimer = template.initialTimer template.specialRules.forEach { addSpecialRule(it) } } fun generateLocations(template: ScenarioTemplate, level: Int, numberOfHeroes: Int): List<Location> { val locations = template.staticLocations.map { generateLocation(it, level) } + template.dynamicLocationsPool .map { generateLocation(it, level) } .shuffled() .take(template.calculateDynamicLocationsCount(numberOfHeroes)) val villains = template.villains .map(::generateVillain) .shuffled() locations.forEachIndexed { index, location -> if (index < villains.size) { location.villain = villains[index] location.bag.put(generateDie(SingleDieTypeFilter(Die.Type.VILLAIN), level)) } } return locations }

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

खैर, ऐसा लगता है कि वे कुछ भी भूल नहीं गए हैं ... ओह हाँ, नायकों - उन्हें भी उत्पन्न करने की आवश्यकता है, जिसका अर्थ है कि उन्हें अपने स्वयं के टेम्पलेट की भी आवश्यकता है। यहाँ कुछ हैं, उदाहरण के लिए:

 interface HeroTemplate { val type: Hero.Type val initialHandCapacity: Int val favoredDieType: Die.Type val initialDice: Collection<Die> val initialSkills: List<SkillTemplate> val dormantSkills: List<SkillTemplate> fun getDiceCount(type: Die.Type): Pair<Int, Int>? }

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

 class BrawlerHeroTemplate : HeroTemplate { override val type = Hero.Type.BRAWLER override val favoredDieType = PHYSICAL override val initialHandCapacity = 4 override val initialDice = listOf( Die(PHYSICAL, 6), Die(PHYSICAL, 6), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(SOMATIC, 6), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(MENTAL, 4), Die(VERBAL, 4), Die(VERBAL, 4) ) override fun getDiceCount(type: Die.Type) = when (type) { PHYSICAL -> 8 to 12 SOMATIC -> 4 to 7 MENTAL -> 1 to 2 VERBAL -> 2 to 4 else -> null } override val initialSkills = listOf( HitSkillTemplate() ) override val dormantSkills = listOf<SkillTemplate>() } class HunterHeroTemplate : HeroTemplate { override val type = Hero.Type.HUNTER override val favoredDieType = SOMATIC override val initialHandCapacity = 5 override val initialDice = listOf( Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(PHYSICAL, 4), Die(SOMATIC, 6), Die(SOMATIC, 6), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(SOMATIC, 4), Die(MENTAL, 6), Die(MENTAL, 4), Die(MENTAL, 4), Die(MENTAL, 4), Die(VERBAL, 4) ) override fun getDiceCount(type: Die.Type) = when (type) { PHYSICAL -> 3 to 5 SOMATIC -> 7 to 11 MENTAL -> 4 to 7 VERBAL -> 1 to 2 else -> null } override val initialSkills = listOf( ShootSkillTemplate() ) override val dormantSkills = listOf<SkillTemplate>() }

लेकिन एक जनरेटर लिखने से पहले, हम कौशल के लिए एक टेम्पलेट को परिभाषित करते हैं।

 interface SkillTemplate { val type: Skill.Type val maxLevel: Int val modifier1: Int val modifier2: Int val isActive get() = true } class HitSkillTemplate : SkillTemplate { override val type = Skill.Type.HIT override val maxLevel = 3 override val modifier1 = +1 override val modifier2 = +3 } class ShootSkillTemplate : SkillTemplate { override val type = Skill.Type.SHOOT override val maxLevel = 3 override val modifier1 = +0 override val modifier2 = +2 }

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

 fun generateSkill(template: SkillTemplate, initialLevel: Int = 1): Skill { val skill = Skill(template.type) skill.isActive = template.isActive skill.level = initialLevel skill.maxLevel = template.maxLevel skill.modifier1 = template.modifier1 skill.modifier2 = template.modifier2 return skill } fun generateHero(type: Hero.Type, name: String = ""): Hero { val template = when (type) { BRAWLER -> BrawlerHeroTemplate() HUNTER -> HunterHeroTemplate() } val hero = Hero(type) hero.name = name hero.isAlive = true hero.favoredDieType = template.favoredDieType hero.hand.capacity = template.initialHandCapacity template.initialDice.forEach { hero.bag.put(it) } for ((t, l) in Die.Type.values().map { it to template.getDiceCount(it) }) { l?.let { hero.addDiceLimit(DiceLimit(t, it.first, it.second, it.first)) } } template.initialSkills .map { generateSkill(it) } .forEach { hero.addSkill(it) } template.dormantSkills .map { generateSkill(it, 0) } .forEach { hero.addDormantSkill(it) } return hero }

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

आठवां चरण। खेल चक्र

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

गतिविधि चार्ट

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

तो, पहली बात यह तय करना है कि हमें किन वस्तुओं की आवश्यकता है।

हीरोज। लिपि। स्थान।
हमने पहले ही उनके निर्माण की प्रक्रिया की समीक्षा की है - हम इसे दोहराएंगे नहीं। हम केवल उन इलाकों के पैटर्न पर ध्यान देते हैं, जिनका उपयोग हम अपने छोटे से उदाहरण में करेंगे।

 class TestLocationTemplate : LocationTemplate { override val name = "Test" override val description = "Some Description" override val basicClosingDifficulty = 0 override val enemyCardsCount = 0 override val obstacleCardsCount = 0 override val bagTemplate = BagTemplate().apply { addPlan(2, 2, SingleDieTypeFilter(Die.Type.PHYSICAL)) addPlan(2, 2, SingleDieTypeFilter(Die.Type.SOMATIC)) addPlan(2, 2, SingleDieTypeFilter(Die.Type.MENTAL)) addPlan(2, 2, SingleDieTypeFilter(Die.Type.VERBAL)) addPlan(2, 2, SingleDieTypeFilter(Die.Type.DIVINE)) } override val enemyCardPool = emptyList<EnemyTemplate>() override val obstacleCardPool = emptyList<ObstacleTemplate>() override val specialRules = emptyList<SpecialRule>() }

जैसा कि आप देख सकते हैं, बैग में केवल "सकारात्मक" क्यूब्स हैं - नीले, हरे, बैंगनी, पीले और नीले। क्षेत्र में कोई दुश्मन और बाधाएं नहीं हैं, खलनायक और घाव नहीं पाए जाते हैं। कोई विशेष नियम भी नहीं हैं - उनका कार्यान्वयन बहुत गौण है।

बरकरार क्यूब्स के लिए ढेर।
या एक निवारक ढेर। चूंकि हम इलाके के बैग में नीले क्यूब्स डालते हैं, उन्हें जांच में और उपयोग के बाद, एक विशेष ढेर में रखा जा सकता है। वर्ग का एक उदाहरण इसके लिए उपयोगी है Pile।

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

 class DiePair(val die: Die, var modifier: Int = 0)

क्षेत्र में वर्णों का स्थान।
एक अच्छे तरीके से, इस क्षण को एक विशेष संरचना का उपयोग करके ट्रैक करने की आवश्यकता है। उदाहरण के लिए, उस स्थान के नक्शे Map<Location, List<Hero>>जहां प्रत्येक इलाके में वर्तमान में नायकों की एक सूची होगी (साथ ही विपरीत के लिए एक विधि - उस इलाके का निर्धारण जिसमें एक विशेष नायक स्थित है)। यदि आप इस मार्ग का अनुसरण करने का निर्णय लेते हैं, तो Locationकार्यान्वयन वर्ग में विधियों को जोड़ना न भूलें equals()और hashCode(), मुझे आशा है, यह समझाने की आवश्यकता नहीं है कि क्यों। हम इस पर समय बर्बाद नहीं करेंगे, क्योंकि क्षेत्र केवल एक है और नायक इसे कहीं भी नहीं छोड़ते हैं।

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

 interface HandFilter { fun test(hand: Hand): Boolean }

इंटरफ़ेस कार्यान्वयन इनपुट के रूप में नायक के हाथ (क्लास ऑब्जेक्ट Hand) को लेते हैं और चेक के परिणामों के आधार पर वापस लौटते trueहैं false। खेल के हमारे टुकड़े के लिए, हमें एक ही कार्यान्वयन की आवश्यकता है: यदि नीला, हरा, बैंगनी या पीला घन मिलता है, तो हमें यह निर्धारित करने की आवश्यकता है कि नायक के हाथ में एक ही रंग का घन है या नहीं।

 class SingleDieHandFilter(private vararg val types: Die.Type) : HandFilter { override fun test(hand: Hand) = (0 until hand.dieCount).mapNotNull { hand.dieAt(it) }.any { it.type in types } || (Die.Type.ALLY in types && hand.allyDieCount > 0) }

हाँ, फिर से कार्यात्मकता।

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

 class HandMask { private val positions = mutableSetOf<Int>() private val allyPositions = mutableSetOf<Int>() val positionCount get() = positions.size val allyPositionCount get() = allyPositions.size fun addPosition(position: Int) = positions.add(position) fun removePosition(position: Int) = positions.remove(position) fun addAllyPosition(position: Int) = allyPositions.add(position) fun removeAllyPosition(position: Int) = allyPositions.remove(position) fun checkPosition(position: Int) = position in positions fun checkAllyPosition(position: Int) = position in allyPositions fun switchPosition(position: Int) { if (!removePosition(position)) { addPosition(position) } } fun switchAllyPosition(position: Int) { if (!removeAllyPosition(position)) { addAllyPosition(position) } } fun clear() { positions.clear() allyPositions.clear() } }

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

वैसे, ढेर ( PileMask) से क्यूब्स का चयन करने के लिए एक समान वर्ग को लागू करने की आवश्यकता है , लेकिन यह कार्यक्षमता इस उदाहरण के दायरे से बाहर है।

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

 abstract class HandMaskRule(val hand: Hand) { abstract fun checkMask(mask: HandMask): Boolean abstract fun isPositionActive(mask: HandMask, position: Int): Boolean abstract fun isAllyPositionActive(mask: HandMask, position: Int): Boolean fun getCheckedDice(mask: HandMask): List<Die> { return ((0 until hand.dieCount).filter(mask::checkPosition).map(hand::dieAt)) .plus((0 until hand.allyDieCount).filter(mask::checkAllyPosition).map(hand::allyDieAt)) .filterNotNull() } }

काफी जटिल तर्क, मैं समझूंगा और माफ कर दूंगा अगर यह वर्ग आपके लिए समझ से बाहर है। और फिर भी समझाने की कोशिश करते हैं। इस वर्ग के कार्यान्वयन हमेशा हाथ (वस्तु Hand) के संदर्भ को संग्रहीत करते हैं जिसके साथ वे निपटेंगे। प्रत्येक विधि एक मुखौटा ( HandMask) प्राप्त करती है , जो चयन की वर्तमान स्थिति को दर्शाती है (कौन से पद खिलाड़ी द्वारा चुने गए हैं और जो नहीं हैं)। विधि checkMask()रिपोर्ट करती है कि चयनित क्यूब्स परीक्षण पास करने के लिए पर्याप्त हैं या नहीं। विधि isPositionActive()कहती है कि क्या किसी विशिष्ट स्थिति को उजागर करना आवश्यक है - क्या परीक्षण के लिए इस स्थिति में घन जोड़ना संभव है (या पहले से चयनित एक घन को हटा दें)। isAllyPositionActive()सफेद पासा के लिए विधि समान है (हां, मुझे पता है, मैं एक बेवकूफ हूं)। अच्छी तरह से और सहायक विधिgetCheckedDice()यह बस मास्क के अनुरूप हाथ से सभी क्यूब्स की एक सूची देता है - यह उन सभी को एक बार में लेने के लिए आवश्यक है, उन्हें मेज पर फेंक दें और मज़ेदार दस्तक का आनंद लें, जिसके साथ वे अलग-अलग दिशाओं में बिखेरते हैं।

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

 class StatDieAcquireHandMaskRule(hand: Hand, private val requiredType: Die.Type) : HandMaskRule(hand) { /** * Define how many dice of specified type are currently checked */ private fun checkedDieCount(mask: HandMask) = (0 until hand.dieCount) .filter(mask::checkPosition) .mapNotNull(hand::dieAt) .count { it.type === requiredType } override fun checkMask(mask: HandMask) = (mask.allyPositionCount == 0 && checkedDieCount(mask) == 1) override fun isPositionActive(mask: HandMask, position: Int) = with(hand.dieAt(position)) { when { mask.checkPosition(position) -> true this == null -> false this.type === Die.Type.DIVINE -> true this.type === requiredType && checkedDieCount(mask) < 1 -> true else -> false } } override fun isAllyPositionActive(mask: HandMask, position: Int) = false }

. . . (capacity), ( ). , ( , ). .

 class DiscardExtraDiceHandMaskRule(hand: Hand) : HandMaskRule(hand) { private val minDiceToDiscard = if (hand.dieCount > hand.capacity) min(hand.dieCount - hand.woundCount, hand.dieCount - hand.capacity) else 0 private val maxDiceToDiscard = hand.dieCount - hand.woundCount override fun checkMask(mask: HandMask) = (mask.positionCount in minDiceToDiscard..maxDiceToDiscard) && (mask.allyPositionCount in 0..hand.allyDieCount) override fun isPositionActive(mask: HandMask, position: Int) = when { mask.checkPosition(position) -> true hand.dieAt(position) == null -> false hand.dieAt(position)!!.type == Die.Type.WOUND -> false mask.positionCount < maxDiceToDiscard -> true else -> false } override fun isAllyPositionActive(mask: HandMask, position: Int) = hand.allyDieAt(position) != null }

Nezhdanchik: Handएक संपत्ति अचानक उस वर्ग में दिखाई दी जो woundCountपहले मौजूद नहीं थी। आप इसका कार्यान्वयन स्वयं लिख सकते हैं, यह आसान है। उसी समय अभ्यास करें।

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

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

 class DieBattleCheck(val method: Method, opponent: DiePair? = null) { enum class Method { SUM, AVG_UP, AVG_DOWN, MAX, MIN } private inner class Wrap(val pair: DiePair, var roll: Int) private infix fun DiePair.with(roll: Int) = Wrap(this, roll) private val opponent: Wrap? = opponent?.with(0) private val heroics = ArrayList<Wrap>() var isRolled = false var result: Int? = null val heroPairCount get() = heroics.size fun getOpponentPair() = opponent?.pair fun getOpponentResult() = when { isRolled -> opponent?.roll ?: 0 else -> throw IllegalStateException("Not rolled yet") } fun addHeroPair(pair: DiePair) { if (method == Method.SUM && heroics.size > 0) { pair.modifier = 0 } heroics.add(pair with 0) } fun addHeroPair(die: Die, modifier: Int) = addHeroPair(DiePair(die, modifier)) fun clearHeroPairs() = heroics.clear() fun getHeroPairAt(index: Int) = heroics[index].pair fun getHeroResultAt(index: Int) = when { isRolled -> when { (index in 0 until heroics.size) -> heroics[index].roll else -> 0 } else -> throw IllegalStateException("Not rolled yet") } fun roll() { fun roll(wrap: Wrap) { wrap.roll = wrap.pair.die.roll() } isRolled = true opponent?.let { roll(it) } heroics.forEach { roll(it) } } fun calculateResult() { if (!isRolled) { throw IllegalStateException("Not rolled yet") } val opponentResult = opponent?.let { it.roll + it.pair.modifier } ?: 0 val stats = heroics.map { it.roll + it.pair.modifier } val heroResult = when (method) { DieBattleCheck.Method.SUM -> stats.sum() DieBattleCheck.Method.AVG_UP -> ceil(stats.average()).toInt() DieBattleCheck.Method.AVG_DOWN -> floor(stats.average()).toInt() DieBattleCheck.Method.MAX -> stats.max() ?: 0 DieBattleCheck.Method.MIN -> stats.min() ?: 0 } result = heroResult - opponentResult } }

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

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

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

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

 enum class GamePhase { SCENARIO_START, HERO_TURN_START, HERO_TURN_END, LOCATION_BEFORE_EXPLORATION, LOCATION_ENCOUNTER_STAT, LOCATION_ENCOUNTER_DIVINE, LOCATION_AFTER_EXPLORATION, GAME_LOSS }

वास्तव में, और भी चरण हैं, लेकिन हमने केवल उन्हीं का चयन किया है जो हमारे उदाहरण में उपयोग किए जाते हैं। गेम इंजन के चरण को बदलने के लिए, हम विधियों का उपयोग करेंगे changePhaseX(), जहां Xउपरोक्त सूची से मूल्य है। इन विधियों में, इंजन के सभी आंतरिक चर संबंधित चरण की शुरुआत के लिए पर्याप्त मानों तक कम हो जाएंगे, लेकिन बाद में उस पर अधिक।

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

 enum class StatusMessage { EMPTY, CHOOSE_DICE_PERFORM_CHECK, END_OF_TURN_DISCARD_EXTRA, END_OF_TURN_DISCARD_OPTIONAL, CHOOSE_ACTION_BEFORE_EXPLORATION, CHOOSE_ACTION_AFTER_EXPLORATION, ENCOUNTER_PHYSICAL, ENCOUNTER_SOMATIC, ENCOUNTER_MENTAL, ENCOUNTER_VERBAL, ENCOUNTER_DIVINE, DIE_ACQUIRE_SUCCESS, DIE_ACQUIRE_FAILURE, GAME_LOSS_OUT_OF_TIME }

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

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

 class Action( val type: Type, var isEnabled: Boolean = true, val data: Int = 0 ) { enum class Type { NONE, //Blank type CONFIRM, //Confirm some action CANCEL, //Cancel action HAND_POSITION, //Some position in hand HAND_ALLY_POSITION, //Some ally position in hand EXPLORE_LOCATION, //Explore current location FINISH_TURN, //Finish current turn ACQUIRE, //Acquire (DIVINE) die FORFEIT, //Remove die from game HIDE, //Put die into bag DISCARD, //Put die to discard pile } }

एक आंतरिक गणन Typeक्रिया के प्रकार का वर्णन करता है। isEnabledनिष्क्रिय अवस्था में क्रियाओं को प्रदर्शित करने के लिए क्षेत्र आवश्यक है। यही है, यह रिपोर्ट करने के लिए कि यह कार्रवाई आमतौर पर उपलब्ध है, लेकिन किसी कारण के लिए फिलहाल प्रदर्शन नहीं किया जा सकता है (जब कार्रवाई बिल्कुल भी प्रदर्शित नहीं होती है तो ऐसा प्रदर्शन बहुत अधिक जानकारीपूर्ण होता है)। संपत्ति data(कुछ प्रकार की क्रियाओं के लिए आवश्यक) एक विशेष मूल्य संग्रहीत करती है जो कुछ अतिरिक्त विवरण (उदाहरण के लिए, उपयोगकर्ता द्वारा चयनित स्थिति का सूचकांक या सूची से चयनित आइटम की संख्या) को संग्रहीत करती है।

KlasActionखेल इंजन और इनपुट-आउटपुट सिस्टम (जिसके बारे में नीचे) के बीच मुख्य "इंटरफ़ेस" है। चूंकि अक्सर कई क्रियाएं होती हैं (अन्यथा, फिर क्यों चुनें?), उन्हें समूहों (सूचियों) में जोड़ा जाएगा। मानक संग्रह का उपयोग करने के बजाय, हम अपने स्वयं के विस्तारित को लिखेंगे।

 class ActionList : Iterable<Action> { private val actions = mutableListOf<Action>() val size get() = actions.size fun add(action: Action): ActionList { actions.add(action) return this } fun add(type: Action.Type, enabled: Boolean = true): ActionList { add(Action(type, enabled)) return this } fun addAll(actions: ActionList): ActionList { actions.forEach { add(it) } return this } fun remove(type: Action.Type): ActionList { actions.removeIf { it.type == type } return this } operator fun get(index: Int) = actions[index] operator fun get(type: Action.Type) = actions.find { it.type == type } override fun iterator(): Iterator<Action> = ActionListIterator() private inner class ActionListIterator : Iterator<Action> { private var position = -1 override fun hasNext() = (actions.size > position + 1) override fun next() = actions[++position] } companion object { val EMPTY get() = ActionList() } }

वर्ग में सूची से क्रियाओं को जोड़ने और हटाने के लिए कई अलग-अलग विधियाँ शामिल हैं (जिन्हें एक साथ जंजीर में डाला जा सकता है), साथ ही सूचकांक और प्रकार दोनों से प्राप्त करें (ध्यान दें "अधिभार" get()- वर्ग ब्रैकेट ऑपरेटर हमारी सूची पर लागू होता है)। इंटरफ़ेस का कार्यान्वयन Iteratorहमें अपने ~~सभी प्रकार के पागल गंदगी~~ वर्ग के साथ विभिन्न धारा जोड़तोड़ (कार्यक्षमता, एएचए) करने की अनुमति देता है । खाली सूची जल्दी बनाने के लिए एक ईएमपीटीवाई मूल्य भी प्रदान किया जाता है।

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

 enum class GameScreen { HERO_TURN_START, LOCATION_INTERIOR, GAME_LOSS }

, . … .

«» «».
— (). , , . - . , .

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

 interface GameRenderer { fun drawHeroTurnStart(hero: Hero) fun drawLocationInteriorScreen( location: Location, heroesAtLocation: List<Hero>, timer: Int, currentHero: Hero, battleCheck: DieBattleCheck?, encounteredDie: DiePair?, pickedDice: HandMask, activePositions: HandMask, statusMessage: StatusMessage, actions: ActionList ) fun drawGameLoss(message: StatusMessage) }

मुझे लगता है कि यहां अतिरिक्त स्पष्टीकरण की आवश्यकता नहीं है - सभी स्थानांतरित वस्तुओं के उद्देश्य पर ऊपर विस्तार से चर्चा की गई है।

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

 interface GameInteractor{ fun anyInput() fun pickAction(list: ActionList): Action fun pickDiceFromHand(activePositions: HandMask, actions: ActionList): Action }

अंतिम विधि के बारे में थोड़ा और। जैसा कि नाम का अर्थ है, उपयोगकर्ता को हाथ से क्यूब्स का चयन करने के लिए आमंत्रित करता है, एक वस्तु प्रदान करता है HandMask- सक्रिय पदों की संख्या। विधि का निष्पादन तब तक जारी रहेगा जब तक कि उनमें से कुछ का चयन नहीं किया जाता है - इस मामले में, विधि क्षेत्र में चयनित स्थिति की संख्या के साथ प्रकार HAND_POSITION(या HAND_ALLY_POSITION, एमडीए) की कार्रवाई लौटाएगी data। इसके अलावा, ऑब्जेक्ट से एक और कार्रवाई (उदाहरण के लिए, CONFIRMया CANCEL) का चयन करना संभव है ActionList। इनपुट विधियों के कार्यान्वयन को उन परिस्थितियों के बीच अंतर करना चाहिए जब क्षेत्र ऐसी कार्रवाइयों के उपयोगकर्ता इनपुट isEnabledको सेट falseऔर अनदेखा करता है।

खेल इंजन वर्ग।
हमने काम के लिए आवश्यक सभी चीजों की जांच की, समय आ गया है और लागू करने के लिए इंजन। एक वर्ग बनाएँGame निम्नलिखित सामग्री के साथ:

क्षमा करें, यह प्रभावशाली लोगों को नहीं दिखाया जाना चाहिए।

 class Game( private val renderer: GameRenderer, private val interactor: GameInteractor, private val scenario: Scenario, private val locations: List<Location>, private val heroes: List<Hero>) { private var timer = 0 private var currentHeroIndex = -1 private lateinit var currentHero: Hero private lateinit var currentLocation: Location private val deterrentPile = Pile() private var encounteredDie: DiePair? = null private var battleCheck: DieBattleCheck? = null private val activeHandPositions = HandMask() private val pickedHandPositions = HandMask() private var phase: GamePhase = GamePhase.SCENARIO_START private var screen = GameScreen.SCENARIO_INTRO private var statusMessage = StatusMessage.EMPTY private var actions: ActionList = ActionList.EMPTY fun start() { if (heroes.isEmpty()) throw IllegalStateException("Heroes list is empty!") if (locations.isEmpty()) throw IllegalStateException("Location list is empty!") heroes.forEach { it.isAlive = true } timer = scenario.initialTimer //Draw initial hand for each hero heroes.forEach(::drawInitialHand) //First hero turn currentHeroIndex = -1 changePhaseHeroTurnStart() processCycle() } private fun drawInitialHand(hero: Hero) { val hand = hero.hand val favoredDie = hero.bag.drawOfType(hero.favoredDieType) hand.addDie(favoredDie!!) refillHeroHand(hero, false) } private fun refillHeroHand(hero: Hero, redrawScreen: Boolean = true) { val hand = hero.hand while (hand.dieCount < hand.capacity && hero.bag.size > 0) { val die = hero.bag.draw() hand.addDie(die) if (redrawScreen) { Audio.playSound(Sound.DIE_DRAW) drawScreen() Thread.sleep(500) } } } private fun changePhaseHeroTurnEnd() { battleCheck = null encounteredDie = null phase = GamePhase.HERO_TURN_END //Discard extra dice (or optional dice) val hand = currentHero.hand pickedHandPositions.clear() activeHandPositions.clear() val allowCancel = if (hand.dieCount > hand.capacity) { statusMessage = StatusMessage.END_OF_TURN_DISCARD_EXTRA false } else { statusMessage = StatusMessage.END_OF_TURN_DISCARD_OPTIONAL true } val result = pickDiceFromHand(DiscardExtraDiceHandMaskRule(hand), allowCancel) statusMessage = StatusMessage.EMPTY actions = ActionList.EMPTY if (result) { val discardDice = collectPickedDice(hand) val discardAllyDice = collectPickedAllyDice(hand) pickedHandPositions.clear() (discardDice + discardAllyDice).forEach { die -> Audio.playSound(Sound.DIE_DISCARD) currentHero.discardDieFromHand(die) drawScreen() Thread.sleep(500) } } pickedHandPositions.clear() //Replenish hand refillHeroHand(currentHero) changePhaseHeroTurnStart() } private fun changePhaseHeroTurnStart() { phase = GamePhase.HERO_TURN_START screen = GameScreen.HERO_TURN_START //Tick timer timer-- if (timer < 0) { changePhaseGameLost(StatusMessage.GAME_LOSS_OUT_OF_TIME) return } //Pick next hero do { currentHeroIndex = ++currentHeroIndex % heroes.size currentHero = heroes[currentHeroIndex] } while (!currentHero.isAlive) currentLocation = locations[0] //Setup Audio.playMusic(Music.SCENARIO_MUSIC_1) Audio.playSound(Sound.TURN_START) } private fun changePhaseLocationBeforeExploration() { phase = GamePhase.LOCATION_BEFORE_EXPLORATION screen = GameScreen.LOCATION_INTERIOR encounteredDie = null battleCheck = null pickedHandPositions.clear() activeHandPositions.clear() statusMessage = StatusMessage.CHOOSE_ACTION_BEFORE_EXPLORATION actions = ActionList() actions.add(Action.Type.EXPLORE_LOCATION, checkLocationCanBeExplored(currentLocation)) actions.add(Action.Type.FINISH_TURN) } private fun changePhaseLocationEncounterStatDie() { Audio.playSound(Sound.ENCOUNTER_STAT) phase = GamePhase.LOCATION_ENCOUNTER_STAT screen = GameScreen.LOCATION_INTERIOR battleCheck = null pickedHandPositions.clear() activeHandPositions.clear() statusMessage = when (encounteredDie!!.die.type) { Die.Type.PHYSICAL -> StatusMessage.ENCOUNTER_PHYSICAL Die.Type.SOMATIC -> StatusMessage.ENCOUNTER_SOMATIC Die.Type.MENTAL -> StatusMessage.ENCOUNTER_MENTAL Die.Type.VERBAL -> StatusMessage.ENCOUNTER_VERBAL else -> throw AssertionError("Should not happen") } val canAttemptCheck = checkHeroCanAttemptStatCheck(currentHero, encounteredDie!!.die.type) actions = ActionList() actions.add(Action.Type.HIDE, canAttemptCheck) actions.add(Action.Type.DISCARD, canAttemptCheck) actions.add(Action.Type.FORFEIT) } private fun changePhaseLocationEncounterDivineDie() { Audio.playSound(Sound.ENCOUNTER_DIVINE) phase = GamePhase.LOCATION_ENCOUNTER_DIVINE screen = GameScreen.LOCATION_INTERIOR battleCheck = null pickedHandPositions.clear() activeHandPositions.clear() statusMessage = StatusMessage.ENCOUNTER_DIVINE actions = ActionList() actions.add(Action.Type.ACQUIRE, checkHeroCanAcquireDie(currentHero, Die.Type.DIVINE)) actions.add(Action.Type.FORFEIT) } private fun changePhaseLocationAfterExploration() { phase = GamePhase.LOCATION_AFTER_EXPLORATION screen = GameScreen.LOCATION_INTERIOR encounteredDie = null battleCheck = null pickedHandPositions.clear() activeHandPositions.clear() statusMessage = StatusMessage.CHOOSE_ACTION_AFTER_EXPLORATION actions = ActionList() actions.add(Action.Type.FINISH_TURN) } private fun changePhaseGameLost(message: StatusMessage) { Audio.stopMusic() Audio.playSound(Sound.GAME_LOSS) phase = GamePhase.GAME_LOSS screen = GameScreen.GAME_LOSS statusMessage = message } private fun pickDiceFromHand(rule: HandMaskRule, allowCancel: Boolean = true, onEachLoop: (() -> Unit)? = null): Boolean { //Preparations pickedHandPositions.clear() actions = ActionList().add(Action.Type.CONFIRM, false) if (allowCancel) { actions.add(Action.Type.CANCEL) } val hand = rule.hand while (true) { //Recurring action onEachLoop?.invoke() //Define success condition val canProceed = rule.checkMask(pickedHandPositions) actions[Action.Type.CONFIRM]?.isEnabled = canProceed //Prepare active hand commands activeHandPositions.clear() (0 until hand.dieCount) .filter { rule.isPositionActive(pickedHandPositions, it) } .forEach { activeHandPositions.addPosition(it) } (0 until hand.allyDieCount) .filter { rule.isAllyPositionActive(pickedHandPositions, it) } .forEach { activeHandPositions.addAllyPosition(it) } //Draw current phase drawScreen() //Process interaction result val result = interactor.pickDiceFromHand(activeHandPositions, actions) when (result.type) { Action.Type.CONFIRM -> if (canProceed) { activeHandPositions.clear() return true } Action.Type.CANCEL -> if (allowCancel) { activeHandPositions.clear() pickedHandPositions.clear() return false } Action.Type.HAND_POSITION -> { Audio.playSound(Sound.DIE_PICK) pickedHandPositions.switchPosition(result.data) } Action.Type.HAND_ALLY_POSITION -> { Audio.playSound(Sound.DIE_PICK) pickedHandPositions.switchAllyPosition(result.data) } else -> throw AssertionError("Should not happen") } } } private fun collectPickedDice(hand: Hand) = (0 until hand.dieCount) .filter(pickedHandPositions::checkPosition) .mapNotNull(hand::dieAt) private fun collectPickedAllyDice(hand: Hand) = (0 until hand.allyDieCount) .filter(pickedHandPositions::checkAllyPosition) .mapNotNull(hand::allyDieAt) private fun performStatDieAcquireCheck(shouldDiscard: Boolean): Boolean { //Prepare check battleCheck = DieBattleCheck(DieBattleCheck.Method.SUM, encounteredDie) pickedHandPositions.clear() statusMessage = StatusMessage.CHOOSE_DICE_PERFORM_CHECK val hand = currentHero.hand //Try to pick dice from performer's hand if (!pickDiceFromHand(StatDieAcquireHandMaskRule(currentHero.hand, encounteredDie!!.die.type), true) { battleCheck!!.clearHeroPairs() (collectPickedDice(hand) + collectPickedAllyDice(hand)) .map { DiePair(it, if (shouldDiscard) 1 else 0) } .forEach(battleCheck!!::addHeroPair) }) { battleCheck = null pickedHandPositions.clear() return false } //Remove dice from hand collectPickedDice(hand).forEach { hand.removeDie(it) } collectPickedAllyDice(hand).forEach { hand.removeDie(it) } pickedHandPositions.clear() //Perform check Audio.playSound(Sound.BATTLE_CHECK_ROLL) for (i in 0..7) { battleCheck!!.roll() drawScreen() Thread.sleep(100) } battleCheck!!.calculateResult() val result = battleCheck?.result ?: -1 val success = result >= 0 //Process dice which participated in the check (0 until battleCheck!!.heroPairCount) .map(battleCheck!!::getHeroPairAt) .map(DiePair::die) .forEach { d -> if (d.type === Die.Type.DIVINE) { currentHero.hand.removeDie(d) deterrentPile.put(d) } else { if (shouldDiscard) { currentHero.discardDieFromHand(d) } else { currentHero.hideDieFromHand(d) } } } //Show message to user Audio.playSound(if (success) Sound.BATTLE_CHECK_SUCCESS else Sound.BATTLE_CHECK_FAILURE) statusMessage = if (success) StatusMessage.DIE_ACQUIRE_SUCCESS else StatusMessage.DIE_ACQUIRE_FAILURE actions = ActionList.EMPTY drawScreen() interactor.anyInput() //Clean up battleCheck = null //Resolve consequences of the check if (success) { Audio.playSound(Sound.DIE_DRAW) currentHero.hand.addDie(encounteredDie!!.die) } return true } private fun processCycle() { while (true) { drawScreen() when (phase) { GamePhase.HERO_TURN_START -> { interactor.anyInput() changePhaseLocationBeforeExploration() } GamePhase.GAME_LOSS -> { interactor.anyInput() return } GamePhase.LOCATION_BEFORE_EXPLORATION -> when (interactor.pickAction(actions).type) { Action.Type.EXPLORE_LOCATION -> { val die = currentLocation.bag.draw() encounteredDie = DiePair(die, 0) when (die.type) { Die.Type.PHYSICAL, Die.Type.SOMATIC, Die.Type.MENTAL, Die.Type.VERBAL -> changePhaseLocationEncounterStatDie() Die.Type.DIVINE -> changePhaseLocationEncounterDivineDie() else -> TODO("Others") } } Action.Type.FINISH_TURN -> changePhaseHeroTurnEnd() else -> throw AssertionError("Should not happen") } GamePhase.LOCATION_ENCOUNTER_STAT -> { val type = interactor.pickAction(actions).type when (type) { Action.Type.DISCARD, Action.Type.HIDE -> { performStatDieAcquireCheck(type === Action.Type.DISCARD) changePhaseLocationAfterExploration() } Action.Type.FORFEIT -> { Audio.playSound(Sound.DIE_REMOVE) changePhaseLocationAfterExploration() } else -> throw AssertionError("Should not happen") } } GamePhase.LOCATION_ENCOUNTER_DIVINE -> when (interactor.pickAction(actions).type) { Action.Type.ACQUIRE -> { Audio.playSound(Sound.DIE_DRAW) currentHero.hand.addDie(encounteredDie!!.die) changePhaseLocationAfterExploration() } Action.Type.FORFEIT -> { Audio.playSound(Sound.DIE_REMOVE) changePhaseLocationAfterExploration() } else -> throw AssertionError("Should not happen") } GamePhase.LOCATION_AFTER_EXPLORATION -> when (interactor.pickAction(actions).type) { Action.Type.FINISH_TURN -> changePhaseHeroTurnEnd() else -> throw AssertionError("Should not happen") } else -> throw AssertionError("Should not happen") } } } private fun drawScreen() { when (screen) { GameScreen.HERO_TURN_START -> renderer.drawHeroTurnStart(currentHero) GameScreen.LOCATION_INTERIOR -> renderer.drawLocationInteriorScreen(currentLocation, heroes, timer, currentHero, battleCheck, encounteredDie, null, pickedHandPositions, activeHandPositions, statusMessage, actions) GameScreen.GAME_LOSS -> renderer.drawGameLoss(statusMessage) } } private fun checkLocationCanBeExplored(location: Location) = location.isOpen && location.bag.size > 0 private fun checkHeroCanAttemptStatCheck(hero: Hero, type: Die.Type): Boolean { return hero.isAlive && SingleDieHandFilter(type).test(hero.hand) } private fun checkHeroCanAcquireDie(hero: Hero, type: Die.Type): Boolean { if (!hero.isAlive) { return false } return when (type) { Die.Type.ALLY -> hero.hand.allyDieCount < MAX_HAND_ALLY_SIZE else -> hero.hand.dieCount < MAX_HAND_SIZE } } }

विधि start()- खेल के लिए प्रवेश बिंदु। यहाँ चरों को आरंभीकृत किया जाता है, नायकों को तौला जाता है, हाथों को क्यूब्स से भरा जाता है, और सभी तरफ से कैमरों से रिपोर्टर चमकते हैं। मुख्य चक्र किसी भी मिनट लॉन्च किया जाएगा, जिसके बाद इसे रोका नहीं जा सकता है। विधि drawInitialHand()खुद के लिए बोलती है (हम drawOfType()वर्ग विधि के कोड पर विचार नहीं करते थे Bag, लेकिन एक साथ इतने लंबे समय तक जाने के बाद, आप इस कोड को खुद लिख सकते हैं)। विधि के refillHeroHand()पास दो विकल्प हैं (तर्क के मूल्य के आधार पर redrawScreen): तेज और शांत (जब आपको खेल की शुरुआत में सभी नायकों के हाथों को भरने की आवश्यकता होती है), और जोर से पैथोस का एक गुच्छा, जब इस कदम के अंत में आपको बैग से क्यूब्स को हटाने की आवश्यकता होती है, तो हाथ को सही आकार में लाते हैं।

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

उपयोगिता विधि pickDiceFromHand()हाथ से क्यूब्स के चयन में लगी हुई है। HandMaskRuleचयन नियमों को परिभाषित करने वाले एक परिचित वर्ग की एक वस्तु यहां पारित की जाती है । यह चयन को अस्वीकार करने की क्षमता को भी इंगित करता है ( allowCancel), साथ ही एक फ़ंक्शन onEachLoopजिसका कोड हर बार चयनित क्यूब्स की सूची को कॉल किया जाना चाहिए (आमतौर पर एक स्क्रीन redraw)। इस विधि द्वारा चयनित क्यूब्स को हाथ से collectPickedDice()और विधियों का उपयोग करके इकट्ठा किया जा सकता है collectPickedAllyDice()।

एक और उपयोगिता विधिperformStatDieAcquireCheck()पूरी तरह से एक नए घन के अधिग्रहण के लिए परीक्षण पास करने वाले नायक को लागू करता है। इस विधि में केंद्रीय भूमिका ऑब्जेक्ट द्वारा निभाई जाती है DieBattleCheck। प्रक्रिया विधि द्वारा क्यूब्स के चयन के साथ शुरू होती है pickDiceFromHand()(प्रत्येक चरण में "प्रतिभागियों" की सूची अपडेट की जाती है DieBattleCheck)। चयनित क्यूब्स को हाथ से हटा दिया जाता है, जिसके बाद एक "रोल" होता है - प्रत्येक डाई अपने मूल्य को अपडेट करता है (एक पंक्ति में आठ बार), जिसके बाद परिणाम की गणना और प्रदर्शित की जाती है। एक सफल रोल पर, एक नया नायक नायक के हाथ में आ जाता है। परीक्षण में भाग लेने वाले क्यूब्स या तो आयोजित किए जाते हैं (यदि वे नीले हैं), या त्याग दिए गए हैं (यदि shouldDiscard = true), या बैग में छिपे हुए हैं (यदि shouldDiscard = false)।

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

इसके अलावा, वर्ग कई सहायक तरीकों में शामिल हैं: checkLocationCanBeExplored(), checkHeroCanAttemptStatCheck()और checkHeroCanAcquireDie()। उनके नाम अपने लिए बोलते हैं, इसलिए हम उन पर विस्तार से ध्यान नहीं देंगे। और एक वर्ग विधि कॉल भी हैं Audio, जो एक लाल लहरदार रेखा द्वारा रेखांकित हैं। समय के लिए उन्हें टिप्पणी करें - हम बाद में उनके उद्देश्य पर विचार करेंगे।

किसे कुछ भी समझ में नहीं आता है, यहाँ एक आरेख है (स्पष्टता के लिए, इसलिए बोलने के लिए):

बस इतना ही, खेल तैयार है (हेहे)। वास्तविक छोटी चीजें थीं, उनके बारे में नीचे।

चरण नौ। प्रदर्शन छवि

तो हम आज की बातचीत के मुख्य विषय पर आते हैं - एप्लिकेशन का ग्राफिक घटक। जैसा कि आपको याद है, हमारा काम इंटरफ़ेस GameRendererऔर उसके तीन तरीकों को लागू करना है , और चूंकि हमारी टीम में अभी भी कोई प्रतिभाशाली कलाकार नहीं है, इसलिए हम छद्म विज्ञान का उपयोग करते हुए खुद ऐसा करेंगे। लेकिन शुरू करने के लिए, यह समझना अच्छा होगा कि हम आम तौर पर बाहर निकलने पर क्या देखने की उम्मीद करते हैं। और हम निम्नलिखित सामग्री के तीन स्क्रीन देखना चाहते हैं:

स्क्रीन 1. प्लेयर टर्न आईडी

स्क्रीन 2. क्षेत्र और वर्तमान नायक के बारे में जानकारी

स्क्रीन 3. स्क्रिप्ट हानि संदेश

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

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

 <dependency> <groupId>org.fusesource.jansi</groupId> <artifactId>jansi</artifactId> <version>1.17.1</version> <scope>compile</scope> </dependency>

और आप बनाना शुरू कर सकते हैं। यह पुस्तकालय हमें सुविधाजनक तरीकों के एक समूह के साथ एक क्लास ऑब्जेक्ट Ansi(स्थिर कॉल के परिणामस्वरूप प्राप्त Ansi.ansi()) प्रदान करता है जिसे जंजीर किया जा सकता है। यह StringBuilder'a' के सिद्धांत पर काम करता है, पहले हम ऑब्जेक्ट बनाते हैं, फिर इसे प्रिंट करने के लिए भेजते हैं। उपयोगी तरीकों में से हम उपयोगी पाएंगे:

a() - वर्ण प्रदर्शित करने के लिए;
cursor() - स्क्रीन पर कर्सर को स्थानांतरित करने के लिए;
eraseLine() - जैसे कि खुद के लिए बोलता है;
eraseScreen() - इसी तरह;
fg(), bg(), fgBright(), bgBright() - पाठ और पृष्ठभूमि के रंगों के साथ काम करने के लिए बहुत असुविधाजनक तरीके - हम अपने खुद के, अधिक सुखद बना देंगे;
reset() - सेट रंग सेटिंग्स, झिलमिलाहट, आदि को रीसेट करने के लिए।

आइए ConsoleRendererउपयोगिता के तरीकों के साथ एक वर्ग बनाएं जो हमारे काम में हमारे लिए उपयोगी हो सकता है। पहला संस्करण कुछ इस तरह दिखेगा:

 abstract class ConsoleRenderer() { protected lateinit var ansi: Ansi init { AnsiConsole.systemInstall() clearScreen() resetAnsi() } private fun resetAnsi() { ansi = Ansi.ansi() } fun clearScreen() { print(Ansi.ansi().eraseScreen(Ansi.Erase.ALL).cursor(1, 1)) } protected fun render() { print(ansi.toString()) resetAnsi() } }

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

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

 protected fun drawHorizontalLine(offsetY: Int, filler: Char) { ansi.cursor(offsetY, 1) (1..CONSOLE_WIDTH).forEach { ansi.a(filler) } //for (i in 1..CONSOLE_WIDTH) { ansi.a(filler) } }

एक बार फिर, मैं आपको याद दिलाता हूं कि कमांड को लागू करना a()या cursor()किसी तात्कालिक प्रभाव के लिए नेतृत्व नहीं करता है, लेकिन केवल Ansiकमांड के संबंधित अनुक्रम को ऑब्जेक्ट में जोड़ता है । जब इन दृश्यों को प्रिंट करने के लिए भेजा जाएगा, तभी हम उन्हें स्क्रीन पर देखेंगे।

शास्त्रीय चक्र का उपयोग करने forऔर इसके साथ कार्यात्मक दृष्टिकोण के बीच कोई बुनियादी अंतर नहीं है - ClosedRangeऔर forEach{}प्रत्येक डेवलपर अपने लिए निर्णय लेता है कि उसके लिए क्या अधिक सुविधाजनक है। हालांकि, मैं आपके सिर को कार्यात्मकता के साथ मूर्ख बनाना जारी रखूंगा, बस इसलिए कि ~~मैं एक बंदर हूं जो सब कुछ नया प्यार करता है और चमकदार~~ कोष्ठक एक नई रेखा से लिपटा नहीं है और कोड अधिक कॉम्पैक्ट दिखता है।

हम एक और उपयोगिता विधि लागू करते हैं drawBlankLine()जो कि जैसा काम करती हैdrawHorizontalLine(offsetY, ' '), केवल विस्तार के साथ। कभी-कभी हमें लाइन को पूरी तरह से खाली नहीं करने की आवश्यकता होती है, लेकिन शुरुआत और अंत (फ्रेम, हाँ) पर एक ऊर्ध्वाधर रेखा छोड़ दें। कोड कुछ इस तरह दिखेगा:

 protected fun drawBlankLine(offsetY: Int, drawBorders: Boolean = true) { ansi.cursor(offsetY, 1) if (drawBorders) { ansi.a('│') (2 until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } else { ansi.eraseLine(Ansi.Erase.ALL) } }

कैसे, आपने छद्म विज्ञान से फ़्रेम को कभी नहीं खींचा? प्रतीकों को सीधे स्रोत कोड में डाला जा सकता है। Alt कुंजी दबाए रखें और संख्यात्मक कीपैड पर वर्ण कोड टाइप करें। तो जाने दो। किसी भी एन्कोडिंग में हमें आवश्यक ASCII कोड समान हैं, यहाँ न्यूनतम सज्जन सेट है:

और फिर, Minecraft की तरह, संभावनाएं केवल आपकी कल्पना की सीमाओं तक सीमित हैं। और स्क्रीन का आकार।

 protected fun drawCenteredCaption(offsetY: Int, text: String, color: Color, drawBorders: Boolean = true) { val center = (CONSOLE_WIDTH - text.length) / 2 ansi.cursor(offsetY, 1) ansi.a(if (drawBorders) '│' else ' ') (2 until center).forEach { ansi.a(' ') } ansi.color(color).a(text).reset() (text.length + center until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a(if (drawBorders) '│' else ' ') }

चलो फूलों के बारे में थोड़ी बात करते हैं। कक्षा Ansiमें Colorआठ प्राथमिक रंगों (काला, नीला, हरा, सियान, लाल, बैंगनी, पीला, ग्रे) के लिए स्थिरांक होते हैं , जिन्हें fg()/bg()अंधेरे संस्करण के लिए या fgBright()/bgBright()प्रकाश के लिए तरीकों के इनपुट के लिए पारित किया जाना चाहिए, जो करने के लिए बहुत असुविधाजनक है, क्योंकि रंग की पहचान करना वैसे, हमारे लिए एक मूल्य पर्याप्त नहीं है - हमें कम से कम दो (रंग और चमक) की आवश्यकता है। इसलिए, हम स्थिरांक और हमारे विस्तार के तरीकों (साथ ही साथ क्यूब्स और नायकों के वर्गों के लिए मैप-बाइंडिंग रंग) की सूची बनाएंगे:

 protected enum class Color { BLACK, DARK_BLUE, DARK_GREEN, DARK_CYAN, DARK_RED, DARK_MAGENTA, DARK_YELLOW, LIGHT_GRAY, DARK_GRAY, LIGHT_BLUE, LIGHT_GREEN, LIGHT_CYAN, LIGHT_RED, LIGHT_MAGENTA, LIGHT_YELLOW, WHITE } protected fun Ansi.color(color: Color?): Ansi = when (color) { Color.BLACK -> fgBlack() Color.DARK_BLUE -> fgBlue() Color.DARK_GREEN -> fgGreen() Color.DARK_CYAN -> fgCyan() Color.DARK_RED -> fgRed() Color.DARK_MAGENTA -> fgMagenta() Color.DARK_YELLOW -> fgYellow() Color.LIGHT_GRAY -> fg(Ansi.Color.WHITE) Color.DARK_GRAY -> fgBrightBlack() Color.LIGHT_BLUE -> fgBrightBlue() Color.LIGHT_GREEN -> fgBrightGreen() Color.LIGHT_CYAN -> fgBrightCyan() Color.LIGHT_RED -> fgBrightRed() Color.LIGHT_MAGENTA -> fgBrightMagenta() Color.LIGHT_YELLOW -> fgBrightYellow() Color.WHITE -> fgBright(Ansi.Color.WHITE) else -> this } protected fun Ansi.background(color: Color?): Ansi = when (color) { Color.BLACK -> ansi.bg(Ansi.Color.BLACK) Color.DARK_BLUE -> ansi.bg(Ansi.Color.BLUE) Color.DARK_GREEN -> ansi.bgGreen() Color.DARK_CYAN -> ansi.bg(Ansi.Color.CYAN) Color.DARK_RED -> ansi.bgRed() Color.DARK_MAGENTA -> ansi.bgMagenta() Color.DARK_YELLOW -> ansi.bgYellow() Color.LIGHT_GRAY -> ansi.bg(Ansi.Color.WHITE) Color.DARK_GRAY -> ansi.bgBright(Ansi.Color.BLACK) Color.LIGHT_BLUE -> ansi.bgBright(Ansi.Color.BLUE) Color.LIGHT_GREEN -> ansi.bgBrightGreen() Color.LIGHT_CYAN -> ansi.bgBright(Ansi.Color.CYAN) Color.LIGHT_RED -> ansi.bgBrightRed() Color.LIGHT_MAGENTA -> ansi.bgBright(Ansi.Color.MAGENTA) Color.LIGHT_YELLOW -> ansi.bgBrightYellow() Color.WHITE -> ansi.bgBright(Ansi.Color.WHITE) else -> this } protected val dieColors = mapOf( Die.Type.PHYSICAL to Color.LIGHT_BLUE, Die.Type.SOMATIC to Color.LIGHT_GREEN, Die.Type.MENTAL to Color.LIGHT_MAGENTA, Die.Type.VERBAL to Color.LIGHT_YELLOW, Die.Type.DIVINE to Color.LIGHT_CYAN, Die.Type.WOUND to Color.DARK_GRAY, Die.Type.ENEMY to Color.DARK_RED, Die.Type.VILLAIN to Color.LIGHT_RED, Die.Type.OBSTACLE to Color.DARK_YELLOW, Die.Type.ALLY to Color.WHITE ) protected val heroColors = mapOf( Hero.Type.BRAWLER to Color.LIGHT_BLUE, Hero.Type.HUNTER to Color.LIGHT_GREEN )

अब, 16 में से प्रत्येक उपलब्ध रंग विशिष्ट रूप से एक एकल स्थिरांक द्वारा पहचाना जाता है। हम कुछ और उपयोगी तरीके लिखेंगे, लेकिन इससे पहले कि हम एक और बात का पता लगाएँ:

पाठ स्ट्रिंग्स के लिए स्थिरांक कहाँ संग्रहीत करें?

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

स्ट्रिंग स्थिरांक को अलग-अलग फ़ाइलों में स्थानांतरित करने की आवश्यकता है ... ठीक है, हाँ। हम सहेंगे। इस तरह के संसाधनों के साथ काम करने के लिए मानक जावा तंत्र ऑब्जेक्ट है java.util.ResourceBundleजो फाइलों के साथ काम करता है .properties। यहाँ हम ऐसी फाइल से शुरू करते हैं:

 # Game status messages choose_dice_perform_check=Choose dice to perform check: end_of_turn_discard_extra=END OF TURN: Discard extra dice: end_of_turn_discard_optional=END OF TURN: Discard any dice, if needed: choose_action_before_exploration=Choose your action: choose_action_after_exploration=Already explored this turn. Choose what to do now: encounter_physical=Encountered PHYSICAL die. Need to pass respective check or lose this die. encounter_somatic=Encountered SOMATIC die. Need to pass respective check or lose this die. encounter_mental=Encountered MENTAL die. Need to pass respective check or lose this die. encounter_verbal=Encountered VERBAL die. Need to pass respective check or lose this die. encounter_divine=Encountered DIVINE die. Can be acquired automatically (no checks needed): die_acquire_success=You have acquired the die! die_acquire_failure=You have failed to acquire the die. game_loss_out_of_time=You ran out of time # Die types physical=PHYSICAL somatic=SOMATIC mental=MENTAL verbal=VERBAL divine=DIVINE ally=ALLY wound=WOUND enemy=ENEMY villain=VILLAIN obstacle=OBSTACLE # Hero types and descriptions brawler=Brawler hunter=Hunter # Various labels avg=avg bag=Bag bag_size=Bag size class=Class closed=Closed discard=Discard empty=Empty encountered=Encountered fail=Fail hand=Hand heros_turn=%s's turn max=max min=min perform_check=Perform check: pile=Pile received_new_die=Received new die result=Result success=Success sum=sum time=Time total=Total # Action names and descriptions action_confirm_key=ENTER action_confirm_name=Confirm action_cancel_key=ESC action_cancel_name=Cancel action_explore_location_key=E action_explore_location_name=xplore action_finish_turn_key=F action_finish_turn_name=inish action_hide_key=H action_hide_name=ide action_discard_key=D action_discard_name=iscard action_acquire_key=A action_acquire_name=cquire action_leave_key=L action_leave_name=eave action_forfeit_key=F action_forfeit_name=orfeit

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

हम अमूर्त हैं, हालांकि, एक विशिष्ट प्रारूप से (एंड्रॉइड में, उदाहरण के लिए, तार अलग तरीके से संग्रहीत किए जाते हैं) और स्ट्रिंग स्ट्रिंग को लोड करने के लिए इंटरफ़ेस का वर्णन करते हैं।

 interface StringLoader { fun loadString(key: String): String }

कुंजी इनपुट में प्रेषित होती है, आउटपुट एक विशिष्ट रेखा है। कार्यान्वयन इंटरफ़ेस के समान सरल है (मान लीजिए कि फ़ाइल पथ के साथ स्थित है src/main/resources/text/strings.properties)।

 class PropertiesStringLoader() : StringLoader { private val properties = ResourceBundle.getBundle("text.strings") override fun loadString(key: String) = properties.getString(key) ?: "" }

अब drawStatusMessage()स्क्रीन पर खेल इंजन की वर्तमान स्थिति ( StatusMessage) को प्रदर्शित करने के लिए एक विधि को लागू करना और drawActionList()उपलब्ध कार्यों की सूची प्रदर्शित करने के लिए एक विधि ( ) को लागू करना मुश्किल नहीं होगा ActionList। साथ ही अन्य आधिकारिक विधियां जो केवल आत्मा की इच्छा है।

बहुत सारे कोड हैं, इसका एक हिस्सा हम पहले ही देख चुके हैं ... इसलिए यहां आपके लिए एक स्पॉइलर है

 abstract class ConsoleRenderer(private val strings: StringLoader) { protected lateinit var ansi: Ansi init { AnsiConsole.systemInstall() clearScreen() resetAnsi() } protected fun loadString(key: String) = strings.loadString(key) private fun resetAnsi() { ansi = Ansi.ansi() } fun clearScreen() { print(Ansi.ansi().eraseScreen(Ansi.Erase.ALL).cursor(1, 1)) } protected fun render() { ansi.cursor(CONSOLE_HEIGHT, CONSOLE_WIDTH) System.out.print(ansi.toString()) resetAnsi() } protected fun drawBigNumber(offsetX: Int, offsetY: Int, number: Int): Unit = with(ansi) { var currentX = offsetX cursor(offsetY, currentX) val text = number.toString() text.forEach { when (it) { '0' -> { cursor(offsetY, currentX) a(" ███ ") cursor(offsetY + 1, currentX) a("█ █ ") cursor(offsetY + 2, currentX) a("█ █ ") cursor(offsetY + 3, currentX) a("█ █ ") cursor(offsetY + 4, currentX) a(" ███ ") } '1' -> { cursor(offsetY, currentX) a(" █ ") cursor(offsetY + 1, currentX) a(" ██ ") cursor(offsetY + 2, currentX) a("█ █ ") cursor(offsetY + 3, currentX) a(" █ ") cursor(offsetY + 4, currentX) a("█████ ") } '2' -> { cursor(offsetY, currentX) a(" ███ ") cursor(offsetY + 1, currentX) a("█ █ ") cursor(offsetY + 2, currentX) a(" █ ") cursor(offsetY + 3, currentX) a(" █ ") cursor(offsetY + 4, currentX) a("█████ ") } '3' -> { cursor(offsetY, currentX) a("████ ") cursor(offsetY + 1, currentX) a(" █ ") cursor(offsetY + 2, currentX) a(" ██ ") cursor(offsetY + 3, currentX) a(" █ ") cursor(offsetY + 4, currentX) a("████ ") } '4' -> { cursor(offsetY, currentX) a(" █ ") cursor(offsetY + 1, currentX) a(" ██ ") cursor(offsetY + 2, currentX) a(" █ █ ") cursor(offsetY + 3, currentX) a("█████ ") cursor(offsetY + 4, currentX) a(" █ ") } '5' -> { cursor(offsetY, currentX) a("█████ ") cursor(offsetY + 1, currentX) a("█ ") cursor(offsetY + 2, currentX) a("████ ") cursor(offsetY + 3, currentX) a(" █ ") cursor(offsetY + 4, currentX) a("████ ") } '6' -> { cursor(offsetY, currentX) a(" ███ ") cursor(offsetY + 1, currentX) a("█ ") cursor(offsetY + 2, currentX) a("████ ") cursor(offsetY + 3, currentX) a("█ █ ") cursor(offsetY + 4, currentX) a(" ███ ") } '7' -> { cursor(offsetY, currentX) a("█████ ") cursor(offsetY + 1, currentX) a(" █ ") cursor(offsetY + 2, currentX) a(" █ ") cursor(offsetY + 3, currentX) a(" █ ") cursor(offsetY + 4, currentX) a(" █ ") } '8' -> { cursor(offsetY, currentX) a(" ███ ") cursor(offsetY + 1, currentX) a("█ █ ") cursor(offsetY + 2, currentX) a(" ███ ") cursor(offsetY + 3, currentX) a("█ █ ") cursor(offsetY + 4, currentX) a(" ███ ") } '9' -> { cursor(offsetY, currentX) a(" ███ ") cursor(offsetY + 1, currentX) a("█ █ ") cursor(offsetY + 2, currentX) a(" ████ ") cursor(offsetY + 3, currentX) a(" █ ") cursor(offsetY + 4, currentX) a(" ███ ") } } currentX += 6 } } protected fun drawHorizontalLine(offsetY: Int, filler: Char) { ansi.cursor(offsetY, 1) (1..CONSOLE_WIDTH).forEach { ansi.a(filler) } } protected fun drawBlankLine(offsetY: Int, drawBorders: Boolean = true) { ansi.cursor(offsetY, 1) if (drawBorders) { ansi.a('│') (2 until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } else { ansi.eraseLine(Ansi.Erase.ALL) } } protected fun drawCenteredCaption(offsetY: Int, text: String, color: Color, drawBorders: Boolean = true) { val center = (CONSOLE_WIDTH - text.length) / 2 ansi.cursor(offsetY, 1) ansi.a(if (drawBorders) '│' else ' ') (2 until center).forEach { ansi.a(' ') } ansi.color(color).a(text).reset() (text.length + center until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a(if (drawBorders) '│' else ' ') } protected fun drawStatusMessage(offsetY: Int, message: StatusMessage, drawBorders: Boolean = true) { //Setup val messageText = loadString(message.toString().toLowerCase()) var currentX = 1 val rightBorder = CONSOLE_WIDTH - if (drawBorders) 1 else 0 //Left border ansi.cursor(offsetY, 1) if (drawBorders) { ansi.a('│') currentX++ } ansi.a(' ') currentX++ //Text ansi.a(messageText) currentX += messageText.length //Right border (currentX..rightBorder).forEach { ansi.a(' ') } if (drawBorders) { ansi.a('│') } } protected fun drawActionList(offsetY: Int, actions: ActionList, drawBorders: Boolean = true) { val rightBorder = CONSOLE_WIDTH - if (drawBorders) 1 else 0 var currentX = 1 //Left border ansi.cursor(offsetY, 1) if (drawBorders) { ansi.a('│') currentX++ } ansi.a(' ') currentX++ //List of actions actions.forEach { action -> val key = loadString("action_${action.toString().toLowerCase()}_key") val name = loadString("action_${action.toString().toLowerCase()}_name") val length = key.length + 2 + name.length if (currentX + length >= rightBorder) { (currentX..rightBorder).forEach { ansi.a(' ') } if (drawBorders) { ansi.a('│') } ansi.cursor(offsetY + 1, 1) currentX = 1 if (drawBorders) { ansi.a('│') currentX++ } ansi.a(' ') currentX++ } if (action.isEnabled) { ansi.color(Color.LIGHT_YELLOW) } ansi.a('(').a(key).a(')').reset() ansi.a(name) ansi.a(" ") currentX += length + 2 } //Right border (currentX..rightBorder).forEach { ansi.a(' ') } if (drawBorders) { ansi.a('│') } } protected enum class Color { BLACK, DARK_BLUE, DARK_GREEN, DARK_CYAN, DARK_RED, DARK_MAGENTA, DARK_YELLOW, LIGHT_GRAY, DARK_GRAY, LIGHT_BLUE, LIGHT_GREEN, LIGHT_CYAN, LIGHT_RED, LIGHT_MAGENTA, LIGHT_YELLOW, WHITE } protected fun Ansi.color(color: Color?): Ansi = when (color) { Color.BLACK -> fgBlack() Color.DARK_BLUE -> fgBlue() Color.DARK_GREEN -> fgGreen() Color.DARK_CYAN -> fgCyan() Color.DARK_RED -> fgRed() Color.DARK_MAGENTA -> fgMagenta() Color.DARK_YELLOW -> fgYellow() Color.LIGHT_GRAY -> fg(Ansi.Color.WHITE) Color.DARK_GRAY -> fgBrightBlack() Color.LIGHT_BLUE -> fgBrightBlue() Color.LIGHT_GREEN -> fgBrightGreen() Color.LIGHT_CYAN -> fgBrightCyan() Color.LIGHT_RED -> fgBrightRed() Color.LIGHT_MAGENTA -> fgBrightMagenta() Color.LIGHT_YELLOW -> fgBrightYellow() Color.WHITE -> fgBright(Ansi.Color.WHITE) else -> this } protected fun Ansi.background(color: Color?): Ansi = when (color) { Color.BLACK -> ansi.bg(Ansi.Color.BLACK) Color.DARK_BLUE -> ansi.bg(Ansi.Color.BLUE) Color.DARK_GREEN -> ansi.bgGreen() Color.DARK_CYAN -> ansi.bg(Ansi.Color.CYAN) Color.DARK_RED -> ansi.bgRed() Color.DARK_MAGENTA -> ansi.bgMagenta() Color.DARK_YELLOW -> ansi.bgYellow() Color.LIGHT_GRAY -> ansi.bg(Ansi.Color.WHITE) Color.DARK_GRAY -> ansi.bgBright(Ansi.Color.BLACK) Color.LIGHT_BLUE -> ansi.bgBright(Ansi.Color.BLUE) Color.LIGHT_GREEN -> ansi.bgBrightGreen() Color.LIGHT_CYAN -> ansi.bgBright(Ansi.Color.CYAN) Color.LIGHT_RED -> ansi.bgBrightRed() Color.LIGHT_MAGENTA -> ansi.bgBright(Ansi.Color.MAGENTA) Color.LIGHT_YELLOW -> ansi.bgBrightYellow() Color.WHITE -> ansi.bgBright(Ansi.Color.WHITE) else -> this } protected val dieColors = mapOf( Die.Type.PHYSICAL to Color.LIGHT_BLUE, Die.Type.SOMATIC to Color.LIGHT_GREEN, Die.Type.MENTAL to Color.LIGHT_MAGENTA, Die.Type.VERBAL to Color.LIGHT_YELLOW, Die.Type.DIVINE to Color.LIGHT_CYAN, Die.Type.WOUND to Color.DARK_GRAY, Die.Type.ENEMY to Color.DARK_RED, Die.Type.VILLAIN to Color.LIGHT_RED, Die.Type.OBSTACLE to Color.DARK_YELLOW, Die.Type.ALLY to Color.WHITE ) protected val heroColors = mapOf( Hero.Type.BRAWLER to Color.LIGHT_BLUE, Hero.Type.HUNTER to Color.LIGHT_GREEN ) protected open fun shortcut(index: Int) = "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ"[index] }

हमने यह सब क्यों किया, आप पूछें? हां, इस अद्भुत वर्ग से हमारे इंटरफ़ेस कार्यान्वयन को विरासत में देने के लिए GameRenderer।

वर्ग आरेख

यह इस प्रकार है कि पहले, सबसे सरल विधि का कार्यान्वयन इस प्रकार होगा:

 override fun drawGameLoss(message: StatusMessage) { val centerY = CONSOLE_HEIGHT / 2 (1 until centerY).forEach { drawBlankLine(it, false) } val data = loadString(message.toString().toLowerCase()).toUpperCase() drawCenteredCaption(centerY, data, LIGHT_RED, false) (centerY + 1..CONSOLE_HEIGHT).forEach { drawBlankLine(it, false) } render() }

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

निम्न विधि इस सिद्धांत का अनुसरण करती है:

 override fun drawHeroTurnStart(hero: Hero) { val centerY = (CONSOLE_HEIGHT - 5) / 2 (1 until centerY).forEach { drawBlankLine(it, false) } ansi.color(heroColors[hero.type]) drawHorizontalLine(centerY, '─') drawHorizontalLine(centerY + 4, '─') ansi.reset() ansi.cursor(centerY + 1, 1).eraseLine() ansi.cursor(centerY + 3, 1).eraseLine() ansi.cursor(centerY + 2, 1) val text = String.format(loadString("heros_turn"), hero.name.toUpperCase()) val index = text.indexOf(hero.name.toUpperCase()) val center = (CONSOLE_WIDTH - text.length) / 2 ansi.cursor(centerY + 2, center) ansi.eraseLine(Ansi.Erase.BACKWARD) ansi.a(text.substring(0, index)) ansi.color(heroColors[hero.type]).a(hero.name.toUpperCase()).reset() ansi.a(text.substring(index + hero.name.length)) ansi.eraseLine(Ansi.Erase.FORWARD) (centerY + 5..CONSOLE_HEIGHT).forEach { drawBlankLine(it, false) } render() }

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

खैर, हमने सबसे सरल तरीकों पर ध्यान दिया और कार्यान्वयन को जानने का समय आ गया है drawLocationInteriorScreen()। जैसा कि आप स्वयं समझते हैं, यहाँ अधिक परिमाण का क्रम होगा। इसके अलावा, उपयोगकर्ता की क्रियाओं के जवाब में स्क्रीन की सामग्री गतिशील रूप से बदल जाएगी और इसे लगातार पुन: तैयार करना होगा (कभी-कभी एनीमेशन के साथ)। खैर, अंत में आपको खत्म करने के लिए: कल्पना करें कि ऊपर दी गई स्क्रीन के अलावा, इस पद्धति के ढांचे में, तीन और के प्रदर्शन को लागू करना आवश्यक है:

1. बैग से हटाए गए क्यूब के साथ बैठक

2. परीक्षण पास करने के लिए पासा का चयन करना

3. परीक्षण के परिणाम प्रदर्शित करना

इसलिए, आपके लिए मेरी बहुत अच्छी सलाह है: सभी कोड को एक विधि से अलग न करें। कार्यान्वयन को कई तरीकों से तोड़ें (भले ही उनमें से प्रत्येक को केवल एक बार कहा जाएगा)। खैर, "रबर" के बारे में मत भूलना।

अगर यह आपकी आंखों में झुनझुनी शुरू कर देता है, तो कुछ सेकंड के लिए झपकी लें - यह मदद करनी चाहिए

 class ConsoleGameRenderer(loader: StringLoader) : ConsoleRenderer(loader), GameRenderer { private fun drawLocationTopPanel(location: Location, heroesAtLocation: List<Hero>, currentHero: Hero, timer: Int) { val closedString = loadString("closed").toLowerCase() val timeString = loadString("time") val locationName = location.name.toString().toUpperCase() val separatorX1 = locationName.length + if (location.isOpen) { 6 + if (location.bag.size >= 10) 2 else 1 } else { closedString.length + 7 } val separatorX2 = CONSOLE_WIDTH - timeString.length - 6 - if (timer >= 10) 1 else 0 //Top border ansi.cursor(1, 1) ansi.a('┌') (2 until CONSOLE_WIDTH).forEach { ansi.a(if (it == separatorX1 || it == separatorX2) '┬' else '─') } ansi.a('┐') //Center row ansi.cursor(2, 1) ansi.a("│ ") if (location.isOpen) { ansi.color(WHITE).a(locationName).reset() ansi.a(": ").a(location.bag.size) } else { ansi.a(locationName).reset() ansi.color(DARK_GRAY).a(" (").a(closedString).a(')').reset() } ansi.a(" │") var currentX = separatorX1 + 2 heroesAtLocation.forEach { hero -> ansi.a(' ') ansi.color(heroColors[hero.type]) ansi.a(if (hero === currentHero) '☻' else '').reset() currentX += 2 } (currentX..separatorX2).forEach { ansi.a(' ') } ansi.a("│ ").a(timeString).a(": ") when { timer <= 5 -> ansi.color(LIGHT_RED) timer <= 15 -> ansi.color(LIGHT_YELLOW) else -> ansi.color(LIGHT_GREEN) } ansi.bold().a(timer).reset().a(" │") //Bottom border ansi.cursor(3, 1) ansi.a('├') (2 until CONSOLE_WIDTH).forEach { ansi.a(if (it == separatorX1 || it == separatorX2) '┴' else '─') } ansi.a('┤') } private fun drawLocationHeroPanel(offsetY: Int, hero: Hero) { val bagString = loadString("bag").toUpperCase() val discardString = loadString("discard").toUpperCase() val separatorX1 = hero.name.length + 4 val separatorX3 = CONSOLE_WIDTH - discardString.length - 6 - if (hero.discardPile.size >= 10) 1 else 0 val separatorX2 = separatorX3 - bagString.length - 6 - if (hero.bag.size >= 10) 1 else 0 //Top border ansi.cursor(offsetY, 1) ansi.a('├') (2 until CONSOLE_WIDTH).forEach { ansi.a(if (it == separatorX1 || it == separatorX2 || it == separatorX3) '┬' else '─') } ansi.a('┤') //Center row ansi.cursor(offsetY + 1, 1) ansi.a("│ ") ansi.color(heroColors[hero.type]).a(hero.name.toUpperCase()).reset() ansi.a(" │") val currentX = separatorX1 + 1 (currentX until separatorX2).forEach { ansi.a(' ') } ansi.a("│ ").a(bagString).a(": ") when { hero.bag.size <= hero.hand.capacity -> ansi.color(LIGHT_RED) else -> ansi.color(LIGHT_YELLOW) } ansi.a(hero.bag.size).reset() ansi.a(" │ ").a(discardString).a(": ") ansi.a(hero.discardPile.size) ansi.a(" │") //Bottom border ansi.cursor(offsetY + 2, 1) ansi.a('├') (2 until CONSOLE_WIDTH).forEach { ansi.a(if (it == separatorX1 || it == separatorX2 || it == separatorX3) '┴' else '─') } ansi.a('┤') } private fun drawDieSize(die: Die, checked: Boolean = false) { when { checked -> ansi.background(dieColors[die.type]).color(BLACK) else -> ansi.color(dieColors[die.type]) } ansi.a(die.toString()).reset() } private fun drawDieFrameSmall(offsetX: Int, offsetY: Int, longDieSize: Boolean) { //Top border ansi.cursor(offsetY, offsetX) ansi.a('╔') (0 until if (longDieSize) 5 else 4).forEach { ansi.a('═') } ansi.a('╗') //Left border ansi.cursor(offsetY + 1, offsetX) ansi.a("║ ") //Bottom border ansi.cursor(offsetY + 2, offsetX) ansi.a("╚") (0 until if (longDieSize) 5 else 4).forEach { ansi.a('═') } ansi.a('╝') //Right border ansi.cursor(offsetY + 1, offsetX + if (longDieSize) 6 else 5) ansi.a('║') } private fun drawDieSmall(offsetX: Int, offsetY: Int, pair: DiePair, rollResult: Int? = null) { ansi.color(dieColors[pair.die.type]) val longDieSize = pair.die.size >= 10 drawDieFrameSmall(offsetX, offsetY, longDieSize) //Roll result or die size ansi.cursor(offsetY + 1, offsetX + 1) if (rollResult != null) { ansi.a(String.format(" %2d %s", rollResult, if (longDieSize) " " else "")) } else { ansi.a(' ').a(pair.die.toString()).a(' ') } //Draw modifier ansi.cursor(offsetY + 3, offsetX) val modString = if (pair.modifier == 0) "" else String.format("%+d", pair.modifier) val frameLength = 4 + if (longDieSize) 3 else 2 var spaces = (frameLength - modString.length) / 2 (0 until spaces).forEach { ansi.a(' ') } ansi.a(modString) spaces = frameLength - spaces - modString.length (0 until spaces).forEach { ansi.a(' ') } ansi.reset() } private fun drawDieFrameBig(offsetX: Int, offsetY: Int, longDieSize: Boolean) { //Top border ansi.cursor(offsetY, offsetX) ansi.a('╔') (0 until if (longDieSize) 3 else 2).forEach { ansi.a("══════") } ansi.a("═╗") //Left border (1..5).forEach { ansi.cursor(offsetY + it, offsetX) ansi.a('║') } //Bottom border ansi.cursor(offsetY + 6, offsetX) ansi.a('╚') (0 until if (longDieSize) 3 else 2).forEach { ansi.a("══════") } ansi.a("═╝") //Right border val currentX = offsetX + if (longDieSize) 20 else 14 (1..5).forEach { ansi.cursor(offsetY + it, currentX) ansi.a('║') } } private fun drawDieSizeBig(offsetX: Int, offsetY: Int, pair: DiePair) { ansi.color(dieColors[pair.die.type]) val longDieSize = pair.die.size >= 10 drawDieFrameBig(offsetX, offsetY, longDieSize) //Die size ansi.cursor(offsetY + 1, offsetX + 1) ansi.a(" ████ ") ansi.cursor(offsetY + 2, offsetX + 1) ansi.a(" █ █ ") ansi.cursor(offsetY + 3, offsetX + 1) ansi.a(" █ █ ") ansi.cursor(offsetY + 4, offsetX + 1) ansi.a(" █ █ ") ansi.cursor(offsetY + 5, offsetX + 1) ansi.a(" ████ ") drawBigNumber(offsetX + 8, offsetY + 1, pair.die.size) //Draw modifier ansi.cursor(offsetY + 7, offsetX) val modString = if (pair.modifier == 0) "" else String.format("%+d", pair.modifier) val frameLength = 4 + 6 * if (longDieSize) 3 else 2 var spaces = (frameLength - modString.length) / 2 (0 until spaces).forEach { ansi.a(' ') } ansi.a(modString) spaces = frameLength - spaces - modString.length - 1 (0 until spaces).forEach { ansi.a(' ') } ansi.reset() } private fun drawBattleCheck(offsetY: Int, battleCheck: DieBattleCheck) { val performCheck = loadString("perform_check") var currentX = 4 var currentY = offsetY //Top message ansi.cursor(offsetY, 1) ansi.a("│ ").a(performCheck) (performCheck.length + 4 until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') //Left border (1..4).forEach { ansi.cursor(offsetY + it, 1) ansi.a("│ ") } //Opponent var opponentWidth = 0 var vsWidth = 0 (battleCheck.getOpponentPair())?.let { //Die if (battleCheck.isRolled) { drawDieSmall(4, offsetY + 1, it, battleCheck.getOpponentResult()) } else { drawDieSmall(4, offsetY + 1, it) } opponentWidth = 4 + if (it.die.size >= 10) 3 else 2 currentX += opponentWidth //VS ansi.cursor(currentY + 1, currentX) ansi.a(" ") ansi.cursor(currentY + 2, currentX) ansi.color(LIGHT_YELLOW).a(" VS ").reset() ansi.cursor(currentY + 3, currentX) ansi.a(" ") ansi.cursor(currentY + 4, currentX) ansi.a(" ") vsWidth = 4 currentX += vsWidth } //Clear below for (row in currentY + 5..currentY + 8) { ansi.cursor(row, 1) ansi.a('│') (2 until currentX).forEach { ansi.a(' ') } } //Dice for (index in 0 until battleCheck.heroPairCount) { if (index > 0) { ansi.cursor(currentY + 1, currentX) ansi.a(" ") ansi.cursor(currentY + 2, currentX) ansi.a(if (battleCheck.method == DieBattleCheck.Method.SUM) " + " else " / ").reset() ansi.cursor(currentY + 3, currentX) ansi.a(" ") ansi.cursor(currentY + 4, currentX) ansi.a(" ") currentX += 3 } val pair = battleCheck.getHeroPairAt(index) val width = 4 + if (pair.die.size >= 10) 3 else 2 if (currentX + width + 3 > CONSOLE_WIDTH) { //Out of space for (row in currentY + 1..currentY + 4) { ansi.cursor(row, currentX) (currentX until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } currentY += 4 currentX = 4 + vsWidth + opponentWidth } if (battleCheck.isRolled) { drawDieSmall(currentX, currentY + 1, pair, battleCheck.getHeroResultAt(index)) } else { drawDieSmall(currentX, currentY + 1, pair) } currentX += width } //Clear the rest (currentY + 1..currentY + 4).forEach { row -> ansi.cursor(row, currentX) (currentX until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } if (currentY == offsetY) { //Still on the first line currentX = 4 + vsWidth + opponentWidth (currentY + 5..currentY + 8).forEach { row -> ansi.cursor(row, currentX) (currentX until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } } //Draw result (battleCheck.result)?.let { r -> val frameTopY = offsetY + 5 val result = String.format("%+d", r) val message = loadString(if (r >= 0) "success" else "fail").toUpperCase() val color = if (r >= 0) DARK_GREEN else DARK_RED //Frame ansi.color(color) drawHorizontalLine(frameTopY, '▒') drawHorizontalLine(frameTopY + 3, '▒') ansi.cursor(frameTopY + 1, 1).a("▒▒") ansi.cursor(frameTopY + 1, CONSOLE_WIDTH - 1).a("▒▒") ansi.cursor(frameTopY + 2, 1).a("▒▒") ansi.cursor(frameTopY + 2, CONSOLE_WIDTH - 1).a("▒▒") ansi.reset() //Top message val resultString = loadString("result") var center = (CONSOLE_WIDTH - result.length - resultString.length - 2) / 2 ansi.cursor(frameTopY + 1, 3) (3 until center).forEach { ansi.a(' ') } ansi.a(resultString).a(": ") ansi.color(color).a(result).reset() (center + result.length + resultString.length + 2 until CONSOLE_WIDTH - 1).forEach { ansi.a(' ') } //Bottom message center = (CONSOLE_WIDTH - message.length) / 2 ansi.cursor(frameTopY + 2, 3) (3 until center).forEach { ansi.a(' ') } ansi.color(color).a(message).reset() (center + message.length until CONSOLE_WIDTH - 1).forEach { ansi.a(' ') } } } private fun drawExplorationResult(offsetY: Int, pair: DiePair) { val encountered = loadString("encountered") ansi.cursor(offsetY, 1) ansi.a("│ ").a(encountered).a(':') (encountered.length + 5 until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') val dieFrameWidth = 3 + 6 * if (pair.die.size >= 10) 3 else 2 for (row in 1..8) { ansi.cursor(offsetY + row, 1) ansi.a("│ ") ansi.cursor(offsetY + row, dieFrameWidth + 4) (dieFrameWidth + 4 until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } drawDieSizeBig(4, offsetY + 1, pair) } private fun drawHand(offsetY: Int, hand: Hand, checkedDice: HandMask, activePositions: HandMask) { val handString = loadString("hand").toUpperCase() val alliesString = loadString("allies").toUpperCase() val capacity = hand.capacity val size = hand.dieCount val slots = max(size, capacity) val alliesSize = hand.allyDieCount var currentY = offsetY var currentX = 1 //Hand title ansi.cursor(currentY, currentX) ansi.a("│ ").a(handString) //Left border currentY += 1 currentX = 1 ansi.cursor(currentY, currentX) ansi.a("│ ╔") ansi.cursor(currentY + 1, currentX) ansi.a("│ ║") ansi.cursor(currentY + 2, currentX) ansi.a("│ ╚") ansi.cursor(currentY + 3, currentX) ansi.a("│ ") currentX += 3 //Main hand for (i in 0 until min(slots, MAX_HAND_SIZE)) { val die = hand.dieAt(i) val longDieName = die != null && die.size >= 10 //Top border ansi.cursor(currentY, currentX) if (i < capacity) { ansi.a("════").a(if (longDieName) "═" else "") } else { ansi.a("────").a(if (longDieName) "─" else "") } ansi.a(if (i < capacity - 1) '╤' else if (i == capacity - 1) '╗' else if (i < size - 1) '┬' else '┐') //Center row ansi.cursor(currentY + 1, currentX) ansi.a(' ') if (die != null) { drawDieSize(die, checkedDice.checkPosition(i)) } else { ansi.a(" ") } ansi.a(' ') ansi.a(if (i < capacity - 1) '│' else if (i == capacity - 1) '║' else '│') //Bottom border ansi.cursor(currentY + 2, currentX) if (i < capacity) { ansi.a("════").a(if (longDieName) '═' else "") } else { ansi.a("────").a(if (longDieName) '─' else "") } ansi.a(if (i < capacity - 1) '╧' else if (i == capacity - 1) '╝' else if (i < size - 1) '┴' else '┘') //Die number ansi.cursor(currentY + 3, currentX) if (activePositions.checkPosition(i)) { ansi.color(LIGHT_YELLOW) } ansi.a(String.format(" (%s) %s", shortcut(i), if (longDieName) " " else "")) ansi.reset() currentX += 5 + if (longDieName) 1 else 0 } //Ally subhand if (alliesSize > 0) { currentY = offsetY //Ally title ansi.cursor(currentY, handString.length + 5) (handString.length + 5 until currentX).forEach { ansi.a(' ') } ansi.a(" ").a(alliesString) (currentX + alliesString.length + 5 until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') //Left border currentY += 1 ansi.cursor(currentY, currentX) ansi.a(" ┌") ansi.cursor(currentY + 1, currentX) ansi.a(" │") ansi.cursor(currentY + 2, currentX) ansi.a(" └") ansi.cursor(currentY + 3, currentX) ansi.a(" ") currentX += 4 //Ally slots for (i in 0 until min(alliesSize, MAX_HAND_ALLY_SIZE)) { val allyDie = hand.allyDieAt(i)!! val longDieName = allyDie.size >= 10 //Top border ansi.cursor(currentY, currentX) ansi.a("────").a(if (longDieName) "─" else "") ansi.a(if (i < alliesSize - 1) '┬' else '┐') //Center row ansi.cursor(currentY + 1, currentX) ansi.a(' ') drawDieSize(allyDie, checkedDice.checkAllyPosition(i)) ansi.a(" │") //Bottom border ansi.cursor(currentY + 2, currentX) ansi.a("────").a(if (longDieName) "─" else "") ansi.a(if (i < alliesSize - 1) '┴' else '┘') //Die number ansi.cursor(currentY + 3, currentX) if (activePositions.checkAllyPosition(i)) { ansi.color(LIGHT_YELLOW) } ansi.a(String.format(" (%s) %s", shortcut(i + 10), if (longDieName) " " else "")).reset() currentX += 5 + if (longDieName) 1 else 0 } } else { ansi.cursor(offsetY, 9) (9 until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') ansi.cursor(offsetY + 4, currentX) (currentX until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } //Clear the end of the line (0..3).forEach { row -> ansi.cursor(currentY + row, currentX) (currentX until CONSOLE_WIDTH).forEach { ansi.a(' ') } ansi.a('│') } } override fun drawHeroTurnStart(hero: Hero) { val centerY = (CONSOLE_HEIGHT - 5) / 2 (1 until centerY).forEach { drawBlankLine(it, false) } ansi.color(heroColors[hero.type]) drawHorizontalLine(centerY, '─') drawHorizontalLine(centerY + 4, '─') ansi.reset() ansi.cursor(centerY + 1, 1).eraseLine() ansi.cursor(centerY + 3, 1).eraseLine() ansi.cursor(centerY + 2, 1) val text = String.format(loadString("heros_turn"), hero.name.toUpperCase()) val index = text.indexOf(hero.name.toUpperCase()) val center = (CONSOLE_WIDTH - text.length) / 2 ansi.cursor(centerY + 2, center) ansi.eraseLine(Ansi.Erase.BACKWARD) ansi.a(text.substring(0, index)) ansi.color(heroColors[hero.type]).a(hero.name.toUpperCase()).reset() ansi.a(text.substring(index + hero.name.length)) ansi.eraseLine(Ansi.Erase.FORWARD) (centerY + 5..CONSOLE_HEIGHT).forEach { drawBlankLine(it, false) } render() } override fun drawLocationInteriorScreen( location: Location, heroesAtLocation: List<Hero>, timer: Int, currentHero: Hero, battleCheck: DieBattleCheck?, encounteredDie: DiePair?, pickedDice: HandMask, activePositions: HandMask, statusMessage: StatusMessage, actions: ActionList) { //Top panel drawLocationTopPanel(location, heroesAtLocation, currentHero, timer) //Encounter info when { battleCheck != null -> drawBattleCheck(4, battleCheck) encounteredDie != null -> drawExplorationResult(4, encounteredDie) else -> (4..12).forEach { drawBlankLine(it) } } //Fill blank space val bottomHalfTop = CONSOLE_HEIGHT - 11 (13 until bottomHalfTop).forEach { drawBlankLine(it) } //Hero-specific info drawLocationHeroPanel(bottomHalfTop, currentHero) drawHand(bottomHalfTop + 3, currentHero.hand, pickedDice, activePositions) //Separator ansi.cursor(bottomHalfTop + 8, 1) ansi.a('├') (2 until CONSOLE_WIDTH).forEach { ansi.a('─') } ansi.a('┤') //Status and actions drawStatusMessage(bottomHalfTop + 9, statusMessage) drawActionList(bottomHalfTop + 10, actions) //Bottom border ansi.cursor(CONSOLE_HEIGHT, 1) ansi.a('└') (2 until CONSOLE_WIDTH).forEach { ansi.a('─') } ansi.a('┘') //Finalize render() } override fun drawGameLoss(message: StatusMessage) { val centerY = CONSOLE_HEIGHT / 2 (1 until centerY).forEach { drawBlankLine(it, false) } val data = loadString(message.toString().toLowerCase()).toUpperCase() drawCenteredCaption(centerY, data, LIGHT_RED, false) (centerY + 1..CONSOLE_HEIGHT).forEach { drawBlankLine(it, false) } render() } }

इस सभी कोड के संचालन की जांच से जुड़ी एक छोटी समस्या है। चूंकि अंतर्निहित आईडीई कंसोल एएनएसआई से बचने के क्रम का समर्थन नहीं करता है, इसलिए आपको बाहरी टर्मिनल में आवेदन शुरू करना होगा (हमने पहले ही इसे लॉन्च करने के लिए एक स्क्रिप्ट लिखी थी)। इसके अलावा, एएनएसआई समर्थन के साथ, विंडोज में सब कुछ ठीक नहीं है - जहां तक मुझे पता है, केवल 10 वें संस्करण के साथ मानक cmd.exe हमें उच्च-गुणवत्ता वाले प्रदर्शन (और कुछ समस्याओं के साथ, जो हम पर ध्यान केंद्रित नहीं करेंगे) के साथ खुश कर सकते हैं। और PowerShell ने तुरंत दृश्यों को पहचानना नहीं सीखा (वर्तमान मांग के बावजूद)। यदि आप अशुभ हैं, तो निराश मत हो - हमेशा वैकल्पिक समाधान होते हैं ( यह, उदाहरण के लिए )। और हम आगे बढ़ते हैं।

चरण दस उपयोगकर्ता इनपुट

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

जैसा कि आप याद करते हैं, हमें वर्ग विधियों को लागू करने की आवश्यकता का सामना करना पड़ता है GameInteractor। उनमें से केवल तीन हैं, लेकिन उन्हें विशेष ध्यान देने की आवश्यकता है। सबसे पहले, सिंक्रनाइज़ेशन। खेल इंजन को तब तक निलंबित रखा जाना चाहिए जब तक खिलाड़ी एक कुंजी दबाता है। दूसरे, प्रसंस्करण पर क्लिक करें। दुर्भाग्य से, मानक कक्षाओं की क्षमता Reader, Scanner, Consoleनहीं पर्याप्त इन सबसे अहम पहचान करने के लिए है: हम प्रेस करने के लिए उपयोगकर्ता की आवश्यकता नहीं है प्रत्येक आदेश के बाद ENTER। हमें कुछ ऐसा चाहिएKeyListenerलेकिन, लेकिन यह कसकर स्विंगिंग ढांचे से बंधा हुआ है, और हमारा कंसोल एप्लिकेशन इस सभी ग्राफिक टिनसेल के बिना है।

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

 <dependency> <groupId>jline</groupId> <artifactId>jline</artifactId> <version>2.14.6</version> <scope>compile</scope> </dependency>

कृपया ध्यान दें कि हमें तीसरे, नवीनतम संस्करण की आवश्यकता नहीं है, लेकिन दूसरा, जहां ConsoleReaderएक विधि के साथ एक वर्ग है readCharacter()। जैसा कि नाम का अर्थ है, यह विधि कीबोर्ड पर दबाए गए वर्ण का कोड लौटाता है (जबकि सिंक्रोनाइज़ करते हुए, जो हमें चाहिए)। बाकी एक तकनीकी मामला है: प्रतीकों और कार्यों के प्रकार ( Action.Type) के बीच पत्राचार की एक तालिका संकलित करें और, एक पर क्लिक करके, दूसरे को लौटाएं।

"क्या आप जानते हैं कि कीबोर्ड की सभी कुंजियों को एक वर्ण के साथ प्रदर्शित नहीं किया जा सकता है? कई चाबियाँ दो, तीन, चार अलग-अलग पात्रों के भागने के अनुक्रम का उपयोग करती हैं। उनके साथ कैसे रहें? ”

यह ध्यान दिया जाना चाहिए कि इनपुट कार्य जटिल है यदि हम "गैर-चरित्र कुंजियों" को पहचानना चाहते हैं: तीर, एफ-की, होम, इंसर्ट, PgUp / Dn, एंड, डिलीट, संख्या-पैड और अन्य। लेकिन हम नहीं चाहते हैं, इसलिए हम जारी रखेंगे। आइए ConsoleInteractorआवश्यक सेवा विधियों के साथ एक वर्ग बनाएं ।

 abstract class ConsoleInteractor { private val reader = ConsoleReader() private val mapper = mapOf( CONFIRM to 13.toChar(), CANCEL to 27.toChar(), EXPLORE_LOCATION to 'e', FINISH_TURN to 'f', ACQUIRE to 'a', LEAVE to 'l', FORFEIT to 'f', HIDE to 'h', DISCARD to 'd', ) protected fun read() = reader.readCharacter().toChar() protected open fun getIndexForKey(key: Char) = "1234567890abcdefghijklmnopqrstuvw".indexOf(key) }

नक्शा mapperऔर विधि निर्धारित करें read()। इसके अलावा, हम उन getIndexForKey()स्थितियों में उपयोग की जाने वाली एक विधि प्रदान करेंगे, जहाँ हमें किसी सूची या क्यूब्स से किसी वस्तु का चयन करने की आवश्यकता है। यह इस वर्ग से हमारे इंटरफ़ेस कार्यान्वयन को विरासत में मिला है GameInteractor।

वर्ग आरेख

और, वास्तव में, कोड:

 class ConsoleGameInteractor : ConsoleInteractor(), GameInteractor { override fun anyInput() { read() } override fun pickAction(list: ActionList): Action { while (true) { val key = read() list .filter(Action::isEnabled) .find { mapper[it.type] == key } ?.let { return it } } } override fun pickDiceFromHand(activePositions: HandMask, actions: ActionList) : Action { while (true) { val key = read() actions.forEach { if (mapper[it.type] == key && it.isEnabled) return it } when (key) { in '1'..'9' -> { val index = key - '1' if (activePositions.checkPosition(index)) { return Action(HAND_POSITION, data = index) } } '0' -> { if (activePositions.checkPosition(9)) { return Action(HAND_POSITION, data = 9) } } in 'a'..'f' -> { val allyIndex = key - 'a' if (activePositions.checkAllyPosition(allyIndex)) { return Action(HAND_ALLY_POSITION, data = allyIndex) } } } } } }

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

ग्यारह कदम। लगता है और संगीत

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

, — , . , . , . , . , , — , — , . , : , , — , . , — , — . ? , . , ( , , ).

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

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

 enum class Sound { TURN_START, //Hero starts the turn BATTLE_CHECK_ROLL, //Perform check, type BATTLE_CHECK_SUCCESS, //Check was successful BATTLE_CHECK_FAILURE, //Check failed DIE_DRAW, //Draw die from bag DIE_HIDE, //Remove die to bag DIE_DISCARD, //Remove die to pile DIE_REMOVE, //Remove die entirely DIE_PICK, //Check/uncheck the die TRAVEL, //Move hero to another location ENCOUNTER_STAT, //Hero encounters STAT die ENCOUNTER_DIVINE, //Hero encounters DIVINE die ENCOUNTER_ALLY, //Hero encounters ALLY die ENCOUNTER_WOUND, //Hero encounters WOUND die ENCOUNTER_OBSTACLE, //Hero encounters OBSTACLE die ENCOUNTER_ENEMY, //Hero encounters ENEMY die ENCOUNTER_VILLAIN, //Hero encounters VILLAIN die DEFEAT_OBSTACLE, //Hero defeats OBSTACLE die DEFEAT_ENEMY, //Hero defeats ENEMY die DEFEAT_VILLAIN, //Hero defeats VILLAIN die TAKE_DAMAGE, //Hero takes damage HERO_DEATH, //Hero death CLOSE_LOCATION, //Location closed GAME_VICTORY, //Scenario completed GAME_LOSS, //Scenario failed ERROR, //When something unexpected happens }

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

 interface SoundPlayer { fun play(sound: Sound) }

पहले चर्चा किए गए इंटरफेस की तरह GameRendererऔर GameInteractor, इसके कार्यान्वयन को भी इनपुट के लिए कक्षा उदाहरण के लिए पारित करने की आवश्यकता है Game। शुरुआत के लिए, एक कार्यान्वयन इस तरह हो सकता है:

 class MuteSoundPlayer : SoundPlayer { override fun play(sound: Sound) { //Do nothing } }

बाद में, हम और अधिक दिलचस्प कार्यान्वयन पर विचार करेंगे, लेकिन अब हम संगीत के बारे में बात करते हैं।
ध्वनि प्रभावों की तरह, यह खेल के वातावरण को बनाने में बहुत बड़ी भूमिका निभाता है, और उसी तरह, एक उत्कृष्ट खेल को अनुपयुक्त संगीत के साथ बर्बाद किया जा सकता है। ध्वनियों की तरह, संगीत विनीत होना चाहिए, सामने नहीं आना (सिवाय इसके कि जब कोई कलात्मक प्रभाव के लिए आवश्यक हो) और पर्याप्त रूप से स्क्रीन पर कार्रवाई के अनुरूप हो (आशा न करें कि किसी ने गंभीरता से घात लगाए और निर्दयता से मार डाला मुख्य रूप से नायक, अगर उसकी त्रासद मृत्यु का दृश्य बच्चों के गीत के मज़ेदार संगीत के साथ होगा)। यह हासिल करना बहुत मुश्किल है, विशेष रूप से प्रशिक्षित लोग ऐसे मुद्दों से निपटते हैं (हम उनके साथ अपरिचित हैं), लेकिन हम, गेमबिलिंग जीनियस के शुरुआती के रूप में, कुछ भी कर सकते हैं। उदाहरण के लिए, कहीं पर जाएंfreemusicarchive.org या soundcloud.com (या यहां तक कि YouTube) और अपनी पसंद के हिसाब से कुछ ढूंढें। डेस्कटॉप के लिए, परिवेश एक अच्छा विकल्प है - एक स्पष्ट राग के बिना शांत, चिकना संगीत, एक पृष्ठभूमि बनाने के लिए अच्छी तरह से अनुकूल है। लाइसेंस पर डबल ध्यान दें: यहां तक कि नि: शुल्क संगीत कभी-कभी प्रतिभाशाली संगीतकारों द्वारा लिखा जाता है जो लायक हैं, यदि मौद्रिक इनाम नहीं है, तो कम से कम सार्वभौमिक मान्यता।

आइए एक और गणना बनाएं:

 enum class Music { SCENARIO_MUSIC_1, SCENARIO_MUSIC_2, SCENARIO_MUSIC_3, }

इसी तरह, हम इंटरफ़ेस और इसके डिफ़ॉल्ट कार्यान्वयन को परिभाषित करते हैं।

 interface MusicPlayer { fun play(music: Music) fun stop() } class MuteMusicPlayer : MusicPlayer { override fun play(music: Music) { //Do nothing } override fun stop() { //Do nothing } }

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

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

ऑडियो प्लेबैक सिस्टम क्लास आरेख

क्लास Audioहमारा सिंगलटन है। यह सबसिस्टम को एक नया मुखौटा प्रदान करता है ... वैसे, यहाँ मुखौटा (मुखौटा) है - एक और डिजाइन पैटर्न, अच्छी तरह से काम किया और इन इंटरनेट पर बार-बार वर्णित (उदाहरणों के साथ)। इसलिए, पहले से ही पीछे की पंक्तियों से असंतुष्ट चीखें सुनते हुए, मैं लंबे समय से ज्ञात चीजों को समझाना बंद कर देता हूं और आगे बढ़ता हूं। कोड है:

 object Audio { private var soundPlayer: SoundPlayer = MuteSoundPlayer() private var musicPlayer: MusicPlayer = MuteMusicPlayer() fun init(soundPlayer: SoundPlayer, musicPlayer: MusicPlayer) { this.soundPlayer = soundPlayer this.musicPlayer = musicPlayer } fun playSound(sound: Sound) = this.soundPlayer.play(sound) fun playMusic(music: Music) = this.musicPlayer.play(music) fun stopMusic() = this.musicPlayer.stop() }

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

वह सब है।यह वास्तविक प्लेबैक से निपटने के लिए बनी हुई है। लगता है कि खेलने के लिए (या, जैसा कि स्मार्ट लोग कहते हैं, नमूने हैं ), जावा में एक सुविधाजनक वर्ग AudioSystemऔर इंटरफ़ेस है Clip। हमें केवल ऑडियो फ़ाइल (जो हमारे क्लासपैथ में है, याद है?) को सही तरीके से सेट करने की आवश्यकता है?

 import javax.sound.sampled.AudioSystem class BasicSoundPlayer : SoundPlayer { private fun pathToFile(sound: Sound) = "/sound/${sound.toString().toLowerCase()}.wav" override fun play(sound: Sound) { val url = javaClass.getResource(pathToFile(sound)) val audioIn = AudioSystem.getAudioInputStream(url) val clip = AudioSystem.getClip() clip.open(audioIn) clip.start() } }

open() IOException ( - — - ), try-catch , , .

« , ...»

. , (, mp3) Java , ( ). , JLayer . :

 <dependencies> <dependency> <groupId>com.googlecode.soundlibs</groupId> <artifactId>jlayer</artifactId> <version>1.0.1.4</version> <scope>compile</scope> </dependency> </dependencies>

 class BasicMusicPlayer : MusicPlayer { private var currentMusic: Music? = null private var thread: PlayerThread? = null private fun pathToFile(music: Music) = "/music/${music.toString().toLowerCase()}.mp3" override fun play(music: Music) { if (currentMusic == music) { return } currentMusic = music thread?.finish() Thread.yield() thread = PlayerThread(pathToFile(music)) thread?.start() } override fun stop() { currentMusic = null thread?.finish() } // Thread responsible for playback private inner class PlayerThread(private val musicPath: String) : Thread() { private lateinit var player: Player private var isLoaded = false private var isFinished = false init { isDaemon = true } override fun run() { loop@ while (!isFinished) { try { player = Player(javaClass.getResource(musicPath).openConnection().apply { useCaches = false }.getInputStream()) isLoaded = true player.play() } catch (ex: Exception) { finish() break@loop } player.close() } } fun finish() { isFinished = true this.interrupt() if (isLoaded) { player.close() } } } }

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

चरण बारह। स्थानीयकरण

हमारा खेल लगभग तैयार है, लेकिन कोई भी इसे नहीं खेलेगा। क्यों?

"कोई रूसी नहीं है! .. कोई रूसी नहीं है! .. रूसी भाषा जोड़ें! .. कुत्तों द्वारा विकसित!"

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

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

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

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

 class TestEnemyTemplate : EnemyTemplate { override val name = "Test enemy" override val description = "Some enemy standing in your way." override val nameLocalizations = mapOf( "ru" to " -", "ar" to "بعض العدو", "iw" to "איזה אויב", "zh" to "一些敵人", "ua" to "і " ) override val descriptionLocalizations = mapOf( "ru" to " - .", "ar" to "وصف العدو", "iw" to "תיאור האויב", "zh" to "一些敵人的描述", "ua" to " ї і   ." ) override val traits = listOf<Trait>() }

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

 class LocalizedString(defaultValue: String, localizations: Map<String, String>) { private val default: String = defaultValue private val values: Map<String, String> = localizations.toMap() operator fun get(lang: String) = values.getOrDefault(lang, default) override fun equals(other: Any?) = when { this === other -> true other !is LocalizedString -> false else -> default == other.default } override fun hashCode(): Int { return default.hashCode() } }

और उसके अनुसार जनरेटर कोड को सही करें।

 fun generateEnemy(template: EnemyTemplate) = Enemy().apply { name = LocalizedString(template.name, template.nameLocalizations) description = LocalizedString(template.description, template.descriptionLocalizations) template.traits.forEach { addTrait(it) } }

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

 val language = Locale.getDefault().language val enemyName = enemy.name[language]

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

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

 # Game status messages choose_dice_perform_check=    : end_of_turn_discard_extra= :   : end_of_turn_discard_optional= :    : choose_action_before_exploration=,  : choose_action_after_exploration= .   ? encounter_physical=  .   . encounter_somatic=  .   . encounter_mental=  .   . encounter_verbal=  .   . encounter_divine=  .    : die_acquire_success=   ! die_acquire_failure=    . game_loss_out_of_time=    # Die types physical= somatic= mental= verbal= divine= ally= wound= enemy= villain= obstacle= # Hero types and descriptions brawler= hunter= # Various labels avg= bag= bag_size=  class= closed= discard= empty= encountered=  fail= hand= heros_turn= %s max= min= perform_check= : pile= received_new_die=   result= success= sum= time= total= # Action names and descriptions action_confirm_key=ENTER action_confirm_name= action_cancel_key=ESC action_cancel_name= action_explore_location_key=E action_explore_location_name= action_finish_turn_key=F action_finish_turn_name=  action_hide_key=H action_bag_name= action_discard_key=D action_discard_name= action_acquire_key=A action_acquire_name= action_leave_key=L action_leave_name= action_forfeit_key=F action_forfeit_name=

: , . ( ), , -, , -, , . , — - , (, , , — ).

 class PropertiesStringLoader(locale: Locale) : StringLoader { private val properties = ResourceBundle.getBundle("text.strings", locale) override fun loadString(key: String) = properties.getString(key) ?: "" }

।
जैसा कि पहले ही उल्लेख किया गया है, ResourceBundleवह खुद स्थानीयकरण फाइलों में से एक को खोजने की जिम्मेदारी लेगा जो वर्तमान लोकेल से सबसे अधिक निकटता से मेल खाता है। और अगर वह नहीं मिला, तो वह डिफ़ॉल्ट फ़ाइल ( string.properties) लेगा । और सब ठीक हो जाएगा ...

अहा! वहाँ यह था!

, Unicode .properties Java 9. ISO-8859-1 — ResourceBundle . , , — . Unicode- — , , : '\uXXXX' . , , Java native2ascii , . :

 # Game status messages choose_dice_perform_check=\u0412\u044b\u0431\u0435\u0440\u0438\u0442\u0435 \u043a\u0443\u0431\u0438\u043a\u0438 \u0434\u043b\u044f \u043f\u0440\u043e\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438: end_of_turn_discard_extra=\u041a\u041e\u041d\u0415\u0426 \u0425\u041e\u0414\u0410: \u0421\u0431\u0440\u043e\u0441\u044c\u0442\u0435 \u043b\u0438\u0448\u043d\u0438\u0435 \u043a\u0443\u0431\u0438\u043a\u0438: end_of_turn_discard_optional=\u041a\u041e\u041d\u0415\u0426 \u0425\u041e\u0414\u0410: \u0421\u0431\u0440\u043e\u0441\u044c\u0442\u0435 \u043a\u0443\u0431\u0438\u043a\u0438 \u043f\u043e \u0436\u0435\u043b\u0430\u043d\u0438\u044e: choose_action_before_exploration=\u0412\u044b\u0431\u0435\u0440\u0438\u0442\u0435, \u0447\u0442\u043e \u0434\u0435\u043b\u0430\u0442\u044c: choose_action_after_exploration=\u0418\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0435 \u0437\u0430\u0432\u0435\u0440\u0448\u0435\u043d\u043e. \u0427\u0442\u043e \u0434\u0435\u043b\u0430\u0442\u044c \u0434\u0430\u043b\u044c\u0448\u0435? encounter_physical=\u0412\u0441\u0442\u0440\u0435\u0447\u0435\u043d \u0424\u0418\u0417\u0418\u0427\u0415\u0421\u041a\u0418\u0419 \u043a\u0443\u0431\u0438\u043a. \u041d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0443. encounter_somatic=\u0412\u0441\u0442\u0440\u0435\u0447\u0435\u043d \u0421\u041e\u041c\u0410\u0422\u0418\u0427\u0415\u0421\u041a\u0418\u0419 \u043a\u0443\u0431\u0438\u043a. \u041d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0443. encounter_mental=\u0412\u0441\u0442\u0440\u0435\u0447\u0435\u043d \u041c\u0415\u041d\u0422\u0410\u041b\u042c\u041d\u042b\u0419 \u043a\u0443\u0431\u0438\u043a. \u041d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0443. encounter_verbal=\u0412\u0441\u0442\u0440\u0435\u0447\u0435\u043d \u0412\u0415\u0420\u0411\u0410\u041b\u042c\u041d\u042b\u0419 \u043a\u0443\u0431\u0438\u043a. \u041d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0443. encounter_divine=\u0412\u0441\u0442\u0440\u0435\u0447\u0435\u043d \u0411\u041e\u0416\u0415\u0421\u0422\u0412\u0415\u041d\u041d\u042b\u0419 \u043a\u0443\u0431\u0438\u043a. \u041c\u043e\u0436\u043d\u043e \u0432\u0437\u044f\u0442\u044c \u0431\u0435\u0437 \u043f\u0440\u043e\u0432\u0435\u0440\u043a\u0438: die_acquire_success=\u0412\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u0438 \u043d\u043e\u0432\u044b\u0439 \u043a\u0443\u0431\u0438\u043a! die_acquire_failure=\u0412\u0430\u043c \u043d\u0435 \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043a\u0443\u0431\u0438\u043a. game_loss_out_of_time=\u0423 \u0432\u0430\u0441 \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u043e\u0441\u044c \u0432\u0440\u0435\u043c\u044f

. — . — . , IDE ( ) « », — - ( ), IDE, .

, . getBundle() , , , ResourceBundle.Control — - .

 class PropertiesStringLoader(locale: Locale) : StringLoader { private val properties = ResourceBundle.getBundle( "text.strings", locale, Utf8ResourceBundleControl()) override fun loadString(key: String) = properties.getString(key) ?: "" }

, , :

 class Utf8ResourceBundleControl : ResourceBundle.Control() { @Throws(IllegalAccessException::class, InstantiationException::class, IOException::class) override fun newBundle(baseName: String, locale: Locale, format: String, loader: ClassLoader, reload: Boolean): ResourceBundle? { val bundleName = toBundleName(baseName, locale) return when (format) { "java.class" -> super.newBundle(baseName, locale, format, loader, reload) "java.properties" -> with((if ("://" in bundleName) null else toResourceName(bundleName, "properties")) ?: return null) { when { reload -> reload(this, loader) else -> loader.getResourceAsStream(this) }?.let { stream -> InputStreamReader(stream, "UTF-8").use { r -> PropertyResourceBundle(r) } } } else -> throw IllegalArgumentException("Unknown format: $format") } } @Throws(IOException::class) private fun reload(resourceName: String, classLoader: ClassLoader): InputStream { classLoader.getResource(resourceName)?.let { url -> url.openConnection().let { connection -> connection.useCaches = false return connection.getInputStream() } } throw IOException("Unable to load data!") } }

, … , ( ) — ( Kotlin ). — , .properties UTF-8 - .

विभिन्न भाषाओं में एप्लिकेशन के संचालन का परीक्षण करने के लिए, ऑपरेटिंग सिस्टम की सेटिंग्स को बदलना आवश्यक नहीं है - केवल JRE शुरू करते समय आवश्यक भाषा निर्दिष्ट करें:

 java -Duser.language=ru -jar path_to_project\Dice\target\dice-1.0-jar-with-dependencies.jar

यदि आप अभी भी विंडोज पर काम कर रहे हैं, तो समस्याओं की अपेक्षा करें

, Windows (cmd.exe) 437 ( DOSLatinUS), — . , UTF-8 , :

 chcp 65001

Java , , . :

 java -Dfile.encoding=UTF-8 -Duser.language=ru -jar path_to_project\Dice\target\dice-1.0-jar-with-dependencies.jar

, , Unicode- (, Lucida Console)

हमारे सभी रोमांचक कारनामों के बाद, परिणाम को गर्व से आम जनता के सामने प्रदर्शित किया जा सकता है और जोर से घोषित किया जाएगा: "हम कुत्ते नहीं हैं!"

नस्लीय आस्था विकल्प

और वह अच्छा है।

चरण तेरह यह सब एक साथ रखना

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

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

स्क्रिप्ट और इलाके;
नायकों;
इंटरफ़ेस कार्यान्वयन GameInteractor;
इंटरफेस का कार्यान्वयन GameRendererऔर StringLoader;
इंटरफेस का कार्यान्वयन SoundPlayerऔर MusicPlayer;
वर्ग वस्तु Game;
शैम्पेन की एक बोतल।

चलो चलते हैं!

 fun main(args: Array<String>) { Audio.init(BasicSoundPlayer(), BasicMusicPlayer()) val loader = PropertiesStringLoader(Locale.getDefault()) val renderer = ConsoleGameRenderer(loader) val interactor = ConsoleGameInteractor() val template = TestScenarioTemplate() val scenario = generateScenario(template, 1) val locations = generateLocations(template, 1, heroes.size) val heroes = listOf( generateHero(Hero.Type.BRAWLER, "Brawler"), generateHero(Hero.Type.HUNTER, "Hunter") ) val game = Game(renderer, interactor, scenario, locations, heroes) game.start() }

हम पहले कार्यशील प्रोटोटाइप को लॉन्च करते हैं और उसका आनंद लेते हैं। वहां तुम जाओ।

चरण चौदह। खेल संतुलन

उम्म्म्म…

चरण पंद्रह। परीक्षण

अब जब पहले कार्यशील प्रोटोटाइप के लिए कोड का थोक लिखा गया है, तो इकाई परीक्षणों के एक जोड़े को जोड़ना अच्छा होगा ...

"कैसे? अभी अभी? हाँ, परीक्षण बहुत शुरुआत में लिखे जाने थे, और फिर कोड! "

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

: ( ) . , . , ( ), , . , Renderer — . , .

, . . : , . , . , :

 public class DieGeneratorTest { @Test public void testGetMaxLevel() { assertEquals("Max level should be 3", 3, DieGeneratorKt.getMaxLevel()); } @Test public void testDieGenerationSize() { DieTypeFilter filter = new SingleDieTypeFilter(Die.Type.ALLY); List<? extends List<Integer>> allowedSizes = Arrays.asList( null, Arrays.asList(4, 6, 8), Arrays.asList(4, 6, 8, 10), Arrays.asList(6, 8, 10, 12) ); IntStream.rangeClosed(1, 3).forEach(level -> { for (int i = 0; i < 10; i++) { int size = DieGeneratorKt.generateDie(filter, level).getSize(); assertTrue("Incorrect level of die generated: " + size, allowedSizes.get(level).contains(size)); assertTrue("Incorrect die size: " + size, size >= 4); assertTrue("Incorrect die size: " + size, size <= 12); assertTrue("Incorrect die size: " + size, size % 2 == 0); } }); } @Test public void testDieGenerationType() { List<Die.Type> allowedTypes1 = Arrays.asList(Die.Type.PHYSICAL); List<Die.Type> allowedTypes2 = Arrays.asList(Die.Type.PHYSICAL, Die.Type.SOMATIC, Die.Type.MENTAL, Die.Type.VERBAL); List<Die.Type> allowedTypes3 = Arrays.asList(Die.Type.ALLY, Die.Type.VILLAIN, Die.Type.ENEMY); for (int i = 0; i < 10; i++) { Die.Type type1 = DieGeneratorKt.generateDie(new SingleDieTypeFilter(Die.Type.PHYSICAL), 1).getType(); assertTrue("Incorrect die type: " + type1, allowedTypes1.contains(type1)); Die.Type type2 = DieGeneratorKt.generateDie(new StatsDieTypeFilter(), 1).getType(); assertTrue("Incorrect die type: " + type2, allowedTypes2.contains(type2)); Die.Type type3 = DieGeneratorKt.generateDie(new MultipleDieTypeFilter(Die.Type.ALLY, Die.Type.VILLAIN, Die.Type.ENEMY), 1).getType(); assertTrue("Incorrect die type: " + type3, allowedTypes3.contains(type3)); } } }

या तो:

 public class BagGeneratorTest { @Test public void testGenerateBag() { BagTemplate template1 = new BagTemplate(); template1.addPlan(0, 10, new SingleDieTypeFilter(Die.Type.PHYSICAL)); template1.addPlan(5, 5, new SingleDieTypeFilter(Die.Type.SOMATIC)); template1.setFixedDieCount(null); BagTemplate template2 = new BagTemplate(); template2.addPlan(10, 10, new SingleDieTypeFilter(Die.Type.DIVINE)); template2.setFixedDieCount(5); BagTemplate template3 = new BagTemplate(); template3.addPlan(10, 10, new SingleDieTypeFilter(Die.Type.ALLY)); template3.setFixedDieCount(50); for (int i = 0; i < 10; i++) { Bag bag1 = BagGeneratorKt.generateBag(template1, 1); assertTrue("Incorrect bag size: " + bag1.getSize(), bag1.getSize() >= 5 && bag1.getSize() <= 15); assertEquals("Incorrect number of SOMATIC dice", 5, bag1.examine().stream().filter(d -> d.getType() == Die.Type.SOMATIC).count()); Bag bag2 = BagGeneratorKt.generateBag(template2, 1); assertEquals("Incorrect bag size", 5, bag2.getSize()); Bag bag3 = BagGeneratorKt.generateBag(template3, 1); assertEquals("Incorrect bag size", 50, bag3.getSize()); List<Die.Type> dieTypes3 = bag3.examine().stream().map(Die::getType).distinct().collect(Collectors.toList()); assertEquals("Incorrect die types", 1, dieTypes3.size()); assertEquals("Incorrect die types", Die.Type.ALLY, dieTypes3.get(0)); } } }

या इस तरह भी:

 public class LocationGeneratorTest { private void testLocationGeneration(String name, LocationTemplate template) { System.out.println("Template: " + template.getName()); assertEquals("Incorrect template type", name, template.getName()); IntStream.rangeClosed(1, 3).forEach(level -> { Location location = LocationGeneratorKt.generateLocation(template, level); assertEquals("Incorrect location type", name, location.getName().get("")); assertTrue("Location not open by default", location.isOpen()); int closingDifficulty = location.getClosingDifficulty(); assertTrue("Closing difficulty too small", closingDifficulty > 0); assertEquals("Incorrect closing difficulty", closingDifficulty, template.getBasicClosingDifficulty() + level * 2); Bag bag = location.getBag(); assertNotNull("Bag is null", bag); assertTrue("Bag is empty", location.getBag().getSize() > 0); Deck<Enemy> enemies = location.getEnemies(); assertNotNull("Enemies are null", enemies); assertEquals("Incorrect enemy threat count", enemies.getSize(), template.getEnemyCardsCount()); if (bag.drawOfType(Die.Type.ENEMY) != null) { assertTrue("Enemy cards not specified", enemies.getSize() > 0); } Deck<Obstacle> obstacles = location.getObstacles(); assertNotNull("Obstacles are null", obstacles); assertEquals("Incorrect obstacle threat count", obstacles.getSize(), template.getObstacleCardsCount()); List<SpecialRule> specialRules = location.getSpecialRules(); assertNotNull("SpecialRules are null", specialRules); }); } @Test public void testGenerateLocation() { testLocationGeneration("Test Location", new TestLocationTemplate()); testLocationGeneration("Test Location 2", new TestLocationTemplate2()); } }

"रोको, रोको, रोको!" यह क्या है? जावा ??? "

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

और एक बात। क्लास याद हैHandMaskRule ? , - , (, « , , — , , — » — ?). ? … . , , ( ), , , , . ? ? ? - ? . — , . … , :

 public class TripleDieHandMaskRuleTest { private Hand hand; @Before public void init() { hand = new Hand(10); hand.addDie(new Die(Die.Type.PHYSICAL, 4)); //0 hand.addDie(new Die(Die.Type.PHYSICAL, 4)); //1 hand.addDie(new Die(Die.Type.SOMATIC, 4)); //2 hand.addDie(new Die(Die.Type.SOMATIC, 4)); //3 hand.addDie(new Die(Die.Type.MENTAL, 4)); //4 hand.addDie(new Die(Die.Type.MENTAL, 4)); //5 hand.addDie(new Die(Die.Type.VERBAL, 4)); //6 hand.addDie(new Die(Die.Type.VERBAL, 4)); //7 hand.addDie(new Die(Die.Type.DIVINE, 4)); //8 hand.addDie(new Die(Die.Type.DIVINE, 4)); //9 hand.addDie(new Die(Die.Type.ALLY, 4)); //A (0) hand.addDie(new Die(Die.Type.ALLY, 4)); //B (1) } @Test public void testRule1() { HandMaskRule rule = new TripleDieHandMaskRule( hand, new Die.Type[]{Die.Type.PHYSICAL, Die.Type.SOMATIC}, new Die.Type[]{Die.Type.MENTAL, Die.Type.VERBAL}, new Die.Type[]{Die.Type.PHYSICAL, Die.Type.ALLY} ); HandMask mask = new HandMask(); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertTrue("Should be on", rule.isPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 2)); assertTrue("Should be on", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertTrue("Should be on", rule.isPositionActive(mask, 5)); assertTrue("Should be on", rule.isPositionActive(mask, 6)); assertTrue("Should be on", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertFalse("Rule should not be met yet", rule.checkMask(mask)); mask.addPosition(0); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertTrue("Should be on", rule.isPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 2)); assertTrue("Should be on", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertTrue("Should be on", rule.isPositionActive(mask, 5)); assertTrue("Should be on", rule.isPositionActive(mask, 6)); assertTrue("Should be on", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertFalse("Rule should not be met yet", rule.checkMask(mask)); mask.addPosition(4); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertTrue("Should be on", rule.isPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 2)); assertTrue("Should be on", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertFalse("Should be off", rule.isPositionActive(mask, 5)); assertFalse("Should be off", rule.isPositionActive(mask, 6)); assertFalse("Should be off", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertFalse("Rule should not be met yet", rule.checkMask(mask)); mask.addAllyPosition(0); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertFalse("Ally should be off", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertFalse("Should be off", rule.isPositionActive(mask, 1)); assertFalse("Should be off", rule.isPositionActive(mask, 2)); assertFalse("Should be off", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertFalse("Should be off", rule.isPositionActive(mask, 5)); assertFalse("Should be off", rule.isPositionActive(mask, 6)); assertFalse("Should be off", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertTrue("Rule should be met", rule.checkMask(mask)); mask.removePosition(0); assertTrue("Ally should be on", rule.isAllyPositionActive(mask, 0)); assertFalse("Ally should be off", rule.isAllyPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 0)); assertTrue("Should be on", rule.isPositionActive(mask, 1)); assertTrue("Should be on", rule.isPositionActive(mask, 2)); assertTrue("Should be on", rule.isPositionActive(mask, 3)); assertTrue("Should be on", rule.isPositionActive(mask, 4)); assertFalse("Should be off", rule.isPositionActive(mask, 5)); assertFalse("Should be off", rule.isPositionActive(mask, 6)); assertFalse("Should be off", rule.isPositionActive(mask, 7)); assertFalse("Should be off", rule.isPositionActive(mask, 8)); assertFalse("Should be off", rule.isPositionActive(mask, 9)); assertFalse("Rule should not be met again", rule.checkMask(mask)); } }

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

 class TripleDieHandMaskRule( hand: Hand, types1: Array<Die.Type>, types2: Array<Die.Type>, types3: Array<Die.Type>) : HandMaskRule(hand) { private val types1 = types1.toSet() private val types2 = types2.toSet() private val types3 = types3.toSet() override fun checkMask(mask: HandMask): Boolean { if (mask.positionCount + mask.allyPositionCount != 3) { return false } return getCheckedDice(mask).asSequence() .filter { it.type in types1 } .any { d1 -> getCheckedDice(mask) .filter { d2 -> d2 !== d1 } .filter { it.type in types2 } .any { d2 -> getCheckedDice(mask) .filter { d3 -> d3 !== d1 } .filter { d3 -> d3 !== d2 } .any { it.type in types3 } } } } override fun isPositionActive(mask: HandMask, position: Int): Boolean { if (mask.checkPosition(position)) { return true } val die = hand.dieAt(position) ?: return false return when (mask.positionCount + mask.allyPositionCount) { 0 -> die.type in types1 || die.type in types2 || die.type in types3 1 -> with(getCheckedDice(mask).first()) { (this.type in types1 && (die.type in types2 || die.type in types3)) || (this.type in types2 && (die.type in types1 || die.type in types3)) || (this.type in types3 && (die.type in types1 || die.type in types2)) } 2-> with(getCheckedDice(mask)) { val d1 = this[0] val d2 = this[1] (d1.type in types1 && d2.type in types2 && die.type in types3) || (d2.type in types1 && d1.type in types2 && die.type in types3) || (d1.type in types1 && d2.type in types3 && die.type in types2) || (d2.type in types1 && d1.type in types3 && die.type in types2) || (d1.type in types2 && d2.type in types3 && die.type in types1) || (d2.type in types2 && d1.type in types3 && die.type in types1) } 3 -> false else -> false } } override fun isAllyPositionActive(mask: HandMask, position: Int): Boolean { if (mask.checkAllyPosition(position)) { return true } if (hand.allyDieAt(position) == null) { return false } return when (mask.positionCount + mask.allyPositionCount) { 0 -> ALLY in types1 || ALLY in types2 || ALLY in types3 1 -> with(getCheckedDice(mask).first()) { (this.type in types1 && (ALLY in types2 || ALLY in types3)) || (this.type in types2 && (ALLY in types1 || ALLY in types3)) || (this.type in types3 && (ALLY in types1 || ALLY in types2)) } 2-> with(getCheckedDice(mask)) { val d1 = this[0] val d2 = this[1] (d1.type in types1 && d2.type in types2 && ALLY in types3) || (d2.type in types1 && d1.type in types2 && ALLY in types3) || (d1.type in types1 && d2.type in types3 && ALLY in types2) || (d2.type in types1 && d1.type in types3 && ALLY in types2) || (d1.type in types2 && d2.type in types3 && ALLY in types1) || (d2.type in types2 && d1.type in types3 && ALLY in types1) } 3 -> false else -> false } } }

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

"और मैं <...> भी <...> बहुत <...> खुशी <...> हूं। अंदर जाओ! <...> वापस! <...> अंतर में! "

चरण सोलह। प्रतिरूपकता

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

हम एक नहीं बल्कि तुच्छ कार्य के साथ सामना कर रहे हैं। तीन समूहों में अब तक बनाई गई सभी कक्षाओं को तोड़ना आवश्यक है:

बुनियादी कार्यक्षमता: मॉड्यूल, खेल इंजन, कनेक्टर इंटरफेस और प्लेटफ़ॉर्म-स्वतंत्र कार्यान्वयन ( कोर );
परिदृश्य, इलाके, दुश्मनों और बाधाओं के टेम्पलेट्स - तथाकथित "साहसिक" ( साहसिक ) के घटक ;
किसी विशेष प्लेटफ़ॉर्म के लिए विशिष्ट इंटरफ़ेस का विशिष्ट कार्यान्वयन: हमारे मामले में, एक कंसोल एप्लिकेशन ( cli )।

इस पृथक्करण का परिणाम अंततः निम्नलिखित आरेख की तरह दिखाई देगा:

शो के अंत में अभिनेताओं की तरह, हमारे आज के नायक पूरी ताकत से दृश्य में फिर से प्रवेश करते हैं

अतिरिक्त प्रोजेक्ट बनाएं और संबंधित वर्ग को स्थानांतरित करें। और हमें बस आपस में प्रोजेक्ट्स की बातचीत को सही ढंग से कॉन्फ़िगर करने की आवश्यकता है।

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

फ़ाइल pom.xmlइस प्रकार है:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>my.company</groupId> <artifactId>dice-core</artifactId> <version>1.0</version> <packaging>jar</packaging> <dependencies> <dependency> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-stdlib</artifactId> <version>${kotlin.version}</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit-dep</artifactId> <version>4.8.2</version> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.jetbrains.kotlin</groupId> <!-- other Kotlin setup --> </plugin> </plugins> </build> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <kotlin.version>1.3.20</kotlin.version> <kotlin.compiler.incremental>true</kotlin.compiler.incremental> </properties> </project>

अब से हम इसे इस तरह एकत्रित करेंगे:

 mvn -f "path_to_project/DiceCore/pom.xml" install

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

फ़ाइल में pom.xmlस्थानांतरित की जाएगी:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>my.company</groupId> <artifactId>dice-cli</artifactId> <version>1.0</version> <packaging>jar</packaging> <dependencies> <dependency> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-stdlib</artifactId> <version>${kotlin.version}</version> </dependency> <dependency> <groupId>my.company</groupId> <artifactId>dice-core</artifactId> <version>1.0</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.fusesource.jansi</groupId> <artifactId>jansi</artifactId> <version>1.17.1</version> <scope>compile</scope> </dependency> <dependency> <groupId>jline</groupId> <artifactId>jline</artifactId> <version>2.14.6</version> <scope>compile</scope> </dependency> <dependency> <groupId>com.googlecode.soundlibs</groupId> <artifactId>jlayer</artifactId> <version>1.0.1.4</version> <scope>compile</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.jetbrains.kotlin</groupId> <!-- other Kotlin setup --> </plugin> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>2.6</version> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifest> <mainClass>my.company.dice.MainKt</mainClass> </manifest> </archive> </configuration> </plugin> </plugins> </build> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <kotlin.version>1.3.20</kotlin.version> <kotlin.compiler.incremental>true</kotlin.compiler.incremental> </properties> </project>

हमने इस प्रोजेक्ट को बनाने और चलाने के लिए पहले ही स्क्रिप्ट देख ली है - हमने इसे दोहराना शुरू नहीं किया है।

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

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

 java -classpath "path_to_project/DiceCli/target/adventures/*" -jar path_to_project/DiceCli/target/dice-1.0-jar-with-dependencies.jar

“मूर्ख, या क्या? -Jar स्विच का उपयोग करते समय, -classpath स्विच को अनदेखा कर दिया जाता है! "

हालांकि, यह काम नहीं करेगा। निष्पादन योग्य जार अभिलेखागार के लिए क्लासपाथ को स्पष्ट रूप से आंतरिक फ़ाइल में लिखा जाना चाहिए META-INF/MANIFEST.MF(अनुभाग कहा जाता है - Claspath:)। यह ठीक है, इसके लिए विशेष प्लगइन्स भी हैं ( मावेन-कंपाइलर-प्लगइन या, सबसे खराब, मावेन-असेंबली-प्लगइन )। लेकिन मैनिफ़ेस्ट, एलास में वाइल्डकार्ड काम नहीं करते हैं - आपको स्पष्ट रूप से निर्भर जार-फ़ाइलों के नाम निर्दिष्ट करने होंगे। यही है, उन्हें पहले से जानना, जो हमारे मामले में समस्याग्रस्त है।

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

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

विंडोज में:

 @ECHO OFF call "path_to_maven\mvn.bat" -f "path_to_project\DiceCore\pom.xml" install call "path_to_maven\mvn.bat" -f "path_to_project\DiceCli\pom.xml" package call "path_to_maven\mvn.bat" -f "path_to_project\TestAdventure\pom.xml" package mkdir path_to_project\DiceCli\target\adventures copy "path_to_project\TestAdventure\target\test-adventure-1.0.jar" path_to_project\DiceCli\target\adventures\ chcp 65001 cd path_to_project\DiceCli\target\ java -Dfile.encoding=UTF-8 -cp "dice-cli-1.0-jar-with-dependencies.jar;adventures\*" my.company.dice.MainKt pause

और यूनिक्स पर:

 #!/bin/sh mvn -f "path_to_project/DiceCore/pom.xml" install mvn -f "path_to_project/DiceCli/pom.xml" package mvn -f "path_to_project/TestAdventure/pom.xml" package mkdir path_to_project/DiceCli/target/adventures cp path_to_project/TestAdventure/target/test-adventure-1.0.jar path_to_project/DiceCli/target/adventures/ cd path_to_project/DiceCli/target/ java -cp "dice-cli-1.0-jar-with-dependencies.jar:adventures/*" my.company.dice.MainKt

और यहाँ चाल है। कुंजी का उपयोग करने के बजाय, -jarहम क्ली प्रोजेक्ट को क्लासपाथ में जोड़ते हैं और स्पष्ट रूप से प्रवेश बिंदु के रूप में उसके भीतर निहित वर्ग को निर्दिष्ट करते हैं MainKt। साथ ही यहाँ हम फोल्डर से सभी आर्काइव को कनेक्ट करते हैं adventures/।

एक बार फिर से यह बताने की जरूरत नहीं है कि यह कितना टेढ़ा फैसला है - मैं खुद जानता हूं, धन्यवाद। टिप्पणियों में अपने विचारों को बेहतर ढंग से सुझाएं। कृपया । (ಥ﹏ಥ)

चरण सत्रह। कहानी

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

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

ठीक है, चलो हमारी कहानी दूसरों को पढ़ते हैं - पक्ष से एक निष्पक्ष देखो बहुत बार किए गए दोषों को समझने और उन्हें समय पर ठीक करने में मदद करता है।

खेल की साजिश

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

— , . , , .

, , - . , , , , . .

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

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

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

आगे क्या है?

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

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

"लेकिन फिर भी, आप खेल संतुलन के बारे में बात नहीं करना चाहते हैं?"

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

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

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

इस आशावादी नोट पर, मुझे आपकी छुट्टी लेनी चाहिए। ध्यान देने के लिए आप सभी का धन्यवाद। जल्द मिलते हैं!

"ई! जो आप देखते हैं? अब यह सब मोबाइल फोन पर कैसे लॉन्च किया जाए? क्या मैंने व्यर्थ प्रतीक्षा की, या क्या? "

उपसंहार। एंड्रॉयड

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

कंसोल इंटरफ़ेस में, यह ऐसा दिखता है

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

मुख्य मेनू के लिए गतिविधि चार्ट

आसान है, है ना? उस और भाषण के बारे में। कोड भी परिमाण सरल का एक आदेश है।

 class MainMenu( private val renderer: MenuRenderer, private val interactor: MenuInteractor ) { private var actions = ActionList.EMPTY fun start() { Audio.playMusic(Music.MENU_MAIN) actions = ActionList() actions.add(Action.Type.NEW_ADVENTURE) actions.add(Action.Type.CONTINUE_ADVENTURE, false) actions.add(Action.Type.MANUAL, false) actions.add(Action.Type.EXIT) processCycle() } private fun processCycle() { while (true) { renderer.drawMainMenu(actions) when (interactor.pickAction(actions).type) { Action.Type.NEW_ADVENTURE -> TODO() Action.Type.CONTINUE_ADVENTURE -> TODO() Action.Type.MANUAL -> TODO() Action.Type.EXIT -> { Audio.stopMusic() Audio.playSound(Sound.LEAVE) renderer.clearScreen() Thread.sleep(500) return } else -> throw AssertionError("Should not happen") } } } }

उपयोगकर्ता के साथ इंटरैक्शन इंटरफेस का उपयोग करके कार्यान्वित किया जाता है MenuRendererऔर MenuInteractorजो पहले देखा गया था, उसी तरह काम कर रहा है।

 interface MenuRenderer: Renderer { fun drawMainMenu(actions: ActionList) } interface Interactor { fun anyInput() fun pickAction(list: ActionList): Action }

जैसा कि आप पहले ही समझ चुके हैं, हमने जानबूझकर विशिष्ट कार्यान्वयन से इंटरफेस को अलग कर दिया है। अब हमें बस जरूरत है कि हम Cli प्रोजेक्ट को एक नए प्रोजेक्ट के साथ बदलें (इसे Droid कहते हैं ), Core Project पर निर्भरता को जोड़ते हुए । चलो करते हैं।

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

 apply plugin: 'com.android.application' apply plugin: 'kotlin-android' apply plugin: 'kotlin-android-extensions' android { compileSdkVersion 28 defaultConfig { applicationId "my.company.dice" minSdkVersion 14 targetSdkVersion 28 versionCode 1 versionName "1.0" } } dependencies { implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" implementation "my.company:dice-core:1.0" }

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

 buildscript { ext.kotlin_version = '1.3.20' repositories { google() jcenter() mavenLocal() } dependencies { classpath 'com.android.tools.build:gradle:3.3.0' classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" } } allprojects { repositories { google() jcenter() mavenLocal() } }

, , — . , , : SoundPlayer , MusicPlayer , MenuInteractor ( GameInteractor ), MenuRenderer ( GameRenderer ) StringLoader , , . , .

(, , ) Android — Canvas . - View- यह हमारा "कैनवास" होगा। इनपुट के साथ, यह थोड़ा अधिक जटिल है, क्योंकि अब हमारे पास कीबोर्ड नहीं है, और इंटरफ़ेस को इस तरह से डिज़ाइन करने की आवश्यकता है कि स्क्रीन के कुछ हिस्सों पर उपयोगकर्ता इनपुट को कमांड का इनपुट माना जाता है। ऐसा करने के लिए, हम एक ही वारिस का उपयोग करेंगे View- इस तरह, वह उपयोगकर्ता और गेम इंजन के बीच मध्यस्थ के रूप में कार्य करेगा (सिस्टम कंसोल इस तरह के मध्यस्थ के रूप में कैसे काम करता है) के समान।

आइए हमारे दृश्य के लिए मुख्य गतिविधि बनाएं और इसे घोषणापत्र में लिखें।

 <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="my.company.dice"> <application android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:theme="@style/AppTheme"> <activity android:name=".ui.MainActivity" android:screenOrientation="sensorLandscape" android:configChanges="orientation|keyboardHidden|screenSize"> <intent-filter> <category android:name="android.intent.category.LAUNCHER"/> <action android:name="android.intent.action.MAIN"/> </intent-filter> </activity> </application> </manifest>

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

 <resources> <style name="AppTheme" parent="android:Theme.Black.NoTitleBar.Fullscreen"/> </resources>

और जब से हम संसाधनों में शामिल हुए हैं, हम क्ली प्रोजेक्ट से स्थानीय स्ट्रिंग्स को स्थानांतरित करते हैं , उन्हें वांछित प्रारूप में लाते हैं:

 <resources> <string name="action_new_adventure_key">N</string> <string name="action_new_adventure_name">ew adventure</string> <string name="action_continue_adventure_key">C</string> <string name="action_continue_adventure_name">ontinue adventure</string> <string name="action_manual_key">M</string> <string name="action_manual_name">anual</string> <string name="action_exit_key">X</string> <string name="action_exit_name">Exit</string> </resources>

साथ ही मुख्य मेनू में प्रयुक्त ध्वनियों और संगीत की फाइलें (प्रत्येक प्रकार की) /assets/sound/leave.wav, /assets/music/menu_main.mp3क्रमशः उन्हें अंदर रखकर ।

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

कक्षा और इंटरफ़ेस आरेख

रुको, बेहोश मत करो, अब मैं सब कुछ विस्तार से बताऊंगा।

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

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

आइए कार्यात्मक इंटरफेस की मदद से इस समस्या को हल करने का प्रयास करें। कक्षा DiceSurfaceमें एक विशेष पैरामीटर होगा instructions- वास्तव में, कोड का एक ब्लॉक जिसे हर बार विधि को निष्पादित किया जाना चाहिए onDraw()। रेंडरर, एक सार्वजनिक पद्धति का उपयोग करके, यह इंगित करेगा कि किन विशिष्ट निर्देशों का पालन किया जाना चाहिए। यदि किसी को दिलचस्पी है, तो उपयोग किए जाने वाले पैटर्न को एक रणनीति कहा जाता है । यह इस तरह दिखता है:

 typealias RenderInstructions = (Canvas, Paint) -> Unit class DiceSurface(context: Context) : View(context) { private var instructions: RenderInstructions = { _, _ -> } private val paint = Paint().apply { color = Color.YELLOW style = Paint.Style.STROKE isAntiAlias = true } fun updateInstructions(instructions: RenderInstructions) { this.instructions = instructions this.postInvalidate() } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) canvas.drawColor(Color.BLACK) //Fill background with black color instructions.invoke(canvas, paint) //Execute current render instructions } } class DroidMenuRenderer(private val surface: DiceSurface): MenuRenderer { override fun clearScreen() { surface.updateInstructions { _, _ -> } } override fun drawMainMenu(actions: ActionList) { surface.updateInstructions { c, p -> val canvasWidth = c.width val canvasHeight = c.height //Draw title text p.textSize = canvasHeight / 3f p.strokeWidth = 0f p.color = Color.parseColor("#ff808000") c.drawText( "DICE", (canvasWidth - p.measureText("DICE")) / 2f, (buttonTop - p.ascent() - p.descent()) / 2f, p ) //Other instructions... } } }

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

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

एक मानक इंटरफ़ेस का उपयोग करके लागू करने के लिए यह दृष्टिकोण काफी सरल है BlockingQueue। कक्षा DroidMenuInteractorविधि कहेगाtake(), जो खेल की धारा के निष्पादन को निलंबित कर देगा जब तक कि कतार (परिचित वर्ग के उदाहरण Action) कतार में दिखाई न दें । DiceSurface, बदले में, उपयोगकर्ता क्लिक (मानक onTouchEvent()वर्ग विधि View) को समायोजित करेगा , वस्तुओं को उत्पन्न करेगा और उन्हें विधि द्वारा कतार में जोड़ देगा offer()। यह इस तरह दिखेगा:

 class DiceSurface(context: Context) : View(context) { private val actionQueue: BlockingQueue<Action> = LinkedBlockingQueue<Action>() fun awaitAction(): Action = actionQueue.take() override fun onTouchEvent(event: MotionEvent): Boolean { if (event.action == MotionEvent.ACTION_UP) { actionQueue.offer(Action(Action.Type.NONE), 200, TimeUnit.MILLISECONDS) } return true } } class DroidMenuInteractor(private val surface: DiceSurface) : Interactor { override fun anyInput() { surface.awaitAction() } override fun pickAction(list: ActionList): Action { while (true) { val type = surface.awaitAction().type list .filter(Action::isEnabled) .find { it.type == type } ?.let { return it } } } }

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

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

 private class ActiveRect(val action: Action, left: Float, top: Float, right: Float, bottom: Float) { val rect = RectF(left, top, right, bottom) fun check(x: Float, y: Float, w: Float, h: Float) = rect.contains(x / w, y / h) }

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

हम कक्षा में DiceSurfaceएक अतिरिक्त फ़ील्ड लागू करेंगे , इसे बाहर से (रेंडरर की तरफ से) नियंत्रित करने के लिए दो विधियाँ ( addRectangle()और clearRectangles()) जोड़ेंगे , और onTouchEvent()आयतों के निर्देशांक को ध्यान में रखकर इसका विस्तार करेंगे।

 class DiceSurface(context: Context) : View(context) { private val actionQueue: BlockingQueue<Action> = LinkedBlockingQueue<Action>() private val rectangles: MutableSet<ActiveRect> = Collections.newSetFromMap(ConcurrentHashMap<ActiveRect, Boolean>()) private var instructions: RenderInstructions = { _, _ -> } private val paint = Paint().apply { color = Color.YELLOW style = Paint.Style.STROKE isAntiAlias = true } fun updateInstructions(instructions: RenderInstructions) { this.instructions = instructions this.postInvalidate() } fun clearRectangles() { rectangles.clear() } fun addRectangle(action: Action, left: Float, top: Float, right: Float, bottom: Float) { rectangles.add(ActiveRect(action, left, top, right, bottom)) } fun awaitAction(): Action = actionQueue.take() override fun onTouchEvent(event: MotionEvent): Boolean { if (event.action == MotionEvent.ACTION_UP) { with(rectangles.firstOrNull { it.check(event.x, event.y, width.toFloat(), height.toFloat()) }) { if (this != null) { actionQueue.put(action) } else { actionQueue.offer(Action(Action.Type.NONE), 200, TimeUnit.MILLISECONDS) } } } return true } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) canvas.drawColor(Color.BLACK) instructions(canvas, paint) } }

आयतों को संग्रहीत करने के लिए एक प्रतिस्पर्धी संग्रह का उपयोग किया जाता है - यह घटना से बचने की अनुमति देगा ConcurrentModificationExceptionयदि सेट को एक साथ अद्यतन किया जाता है और विभिन्न प्रवाह द्वारा सॉर्ट किया जाता है (जो हमारे मामले में होगा)।

वर्ग कोड DroidMenuInteractorअपरिवर्तित रहेगा, लेकिन यह DroidMenuRendererबदल जाएगा। प्रत्येक आइटम के लिए प्रदर्शन में चार बटन जोड़ें ActionList। उन्हें शीर्षक DICE के नीचे रखें, समान रूप से स्क्रीन की चौड़ाई में वितरित करें। खैर, चलो सक्रिय आयतों के बारे में मत भूलना।

 class DroidMenuRenderer ( private val surface: DiceSurface, private val loader: StringLoader ) : MenuRenderer { protected val helper = StringLoadHelper(loader) override fun clearScreen() { surface.clearRectangles() surface.updateInstructions { _, _ -> } } override fun drawMainMenu(actions: ActionList) { //Prepare rectangles surface.clearRectangles() val percentage = 1.0f / actions.size actions.forEachIndexed { i, a -> surface.addRectangle(a, i * percentage, 0.45f, i * percentage + percentage, 1f) } //Prepare instructions surface.updateInstructions { c, p -> val canvasWidth = c.width val canvasHeight = c.height val buttonTop = canvasHeight * 0.45f val buttonWidth = canvasWidth / actions.size val padding = canvasHeight / 144f //Draw title text p.textSize = canvasHeight / 3f p.strokeWidth = 0f p.color = Color.parseColor("#ff808000") p.isFakeBoldText = true c.drawText( "DICE", (canvasWidth - p.measureText("DICE")) / 2f, (buttonTop - p.ascent() - p.descent()) / 2f, p ) p.isFakeBoldText = false //Draw action buttons p.textSize = canvasHeight / 24f actions.forEachIndexed { i, a -> p.color = if (a.isEnabled) Color.YELLOW else Color.LTGRAY p.strokeWidth = canvasHeight / 240f c.drawRect( i * buttonWidth + padding, buttonTop + padding, i * buttonWidth + buttonWidth - padding, canvasHeight - padding, p ) val name = mergeActionData(helper.loadActionData(a)) p.strokeWidth = 0f c.drawText( name, i * buttonWidth + (buttonWidth - p.measureText(name)) / 2f, (canvasHeight + buttonTop - p.ascent() - p.descent()) / 2f, p ) } } } private fun mergeActionData(data: Array<String>) = if (data.size > 1) { if (data[1].first().isLowerCase()) data[0] + data[1] else data[1] } else data.getOrNull(0) ?: "" }

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

 class ResourceStringLoader(context: Context) : StringLoader { private val packageName = context.packageName private val resources = context.resources override fun loadString(key: String): String = resources.getString(resources.getIdentifier(key, "string", packageName)) }

यह ध्वनियों और संगीत के बारे में बात करने के लिए बनी हुई है। Android में एक अद्भुत वर्ग है MediaPlayerजो इन चीजों से संबंधित है। संगीत बजाने के लिए बेहतर कुछ नहीं है:

 class DroidMusicPlayer(private val context: Context): MusicPlayer { private var currentMusic: Music? = null private val player = MediaPlayer() override fun play(music: Music) { if (currentMusic == music) { return } currentMusic = music player.setAudioStreamType(AudioManager.STREAM_MUSIC) val afd = context.assets.openFd("music/${music.toString().toLowerCase()}.mp3") player.setDataSource(afd.fileDescriptor, afd.startOffset, afd.length) player.setOnCompletionListener { it.seekTo(0) it.start() } player.prepare() player.start() } override fun stop() { currentMusic = null player.release() } }

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

यह ध्वनियों MediaPlayerके लिए भी उपयुक्त है , लेकिन अगर वे कुछ और सरल हैं (जैसा कि हमारे मामले में), यह करेगा SoundPool। इसका लाभ यह है कि जब ध्वनि फ़ाइलों को पहले से ही मेमोरी में लोड किया जाता है, तो उनका प्लेबैक तुरंत शुरू होता है। नुकसान स्पष्ट है - पर्याप्त स्मृति नहीं हो सकती है (लेकिन हमारे लिए पर्याप्त है, हम मामूली हैं)।

 class DroidSoundPlayer(context: Context) : SoundPlayer { private val soundPool: SoundPool = SoundPool(2, AudioManager.STREAM_MUSIC, 100) private val sounds = mutableMapOf<Sound, Int>() private val rate = 1f private val lock = ReentrantReadWriteLock() init { Thread(SoundLoader(context)).start() } override fun play(sound: Sound) { if (lock.readLock().tryLock()) { try { sounds[sound]?.let { s -> soundPool.play(s, 1f, 1f, 1, 0, rate) } } finally { lock.readLock().unlock() } } } private inner class SoundLoader(private val context: Context) : Runnable { override fun run() { val assets = context.assets lock.writeLock().lock() try { Sound.values().forEach { s -> sounds[s] = soundPool.load( assets.openFd("sound/${s.toString().toLowerCase()}.wav"), 1 ) } } finally { lock.writeLock().unlock() } } } }

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

अब, आखिरकार, हम अपने अंदर के सभी घटकों को एक साथ अंधा कर देते हैं MainActivity- इस बारे में नहीं भूल गए? कृपया ध्यान दें कि MainMenu(और Gameबाद में) एक अलग थ्रेड में लॉन्च किया जाना चाहिए।

 class MainActivity : Activity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) Audio.init(DroidSoundPlayer(this), DroidMusicPlayer(this)) val surface = DiceSurface(this) val renderer = DroidMenuRenderer(surface) val interactor = DroidMenuInteractor(surface, ResourceStringLoader(this)) setContentView(surface) Thread { MainMenu(renderer, interactor).start() finish() }.start() } override fun onBackPressed() { } }

वह, वास्तव में, सब है। सभी पीड़ा के बाद, हमारे आवेदन की मुख्य स्क्रीन बस आश्चर्यजनक लगती है:

मोबाइल स्क्रीन की पूरी चौड़ाई में मुख्य मेनू

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

उपयोगी लिंक

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

खैर, अचानक, किसी को इस परियोजना को शुरू करने और देखने की इच्छा होगी, और अपने आप पर आलस्य इकट्ठा करेंगे, यहां काम कर रहे संस्करण के लिए एक लिंक है: लिंक!

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

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

ऑल द बेस्ट।

अगर आप कभी कलाकार नहीं हैं तो गेम कैसे बनाएं

छोटा सा परिचय

पहला कदम। विचार

चरण दो डिज़ाइन

चरण तीन मोडलिंग

चरण चार उपकरण चयन

चरण पाँच प्रोजेक्ट बनाना और स्थापित करना

चरण छह मुख्य वस्तुएं

सातवाँ चरण। पैटर्न और जेनरेटर

आठवां चरण। खेल चक्र

चरण नौ। प्रदर्शन छवि

चरण दस उपयोगकर्ता इनपुट

ग्यारह कदम। लगता है और संगीत

चरण बारह। स्थानीयकरण

चरण तेरह यह सब एक साथ रखना

चरण चौदह। खेल संतुलन

चरण पंद्रह। परीक्षण

चरण सोलह। प्रतिरूपकता

चरण सत्रह। कहानी

आगे क्या है?

उपसंहार। एंड्रॉयड

उपयोगी लिंक

More articles: