👨🏻 ✍🏼 🤱 एक साथ चाल के साथ एक मोड़ आधारित PvP क्षेत्र लेखन ☯️ 🧑🏾 🔠

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

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

2019 की गर्मियों में, सर्वर बंद हो गए थे, क्योंकि खेल की कम लोकप्रियता के कारण, प्रकाशक के लिए उनका समर्थन लाभहीन था। गेम को गेम-ए-ए-सर्विस के मॉडल पर बनाया गया था , इसलिए सर्वरों को बंद करने से ग्राहकों को कोड के टूटे हुए टुकड़ों में बदल दिया गया।

इसी तरह के खेलों के शैलियों के अद्वितीय संयोजन के कारण, बाजार पर बस कोई खेल नहीं था, लेकिन मैं वास्तव में इसके साथ कुछ खेलना चाहता था।

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

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

गेमप्ले

सामान्य तौर पर, कार्रवाई मल्टीप्लेयर XCOM की याद ताजा करती है, लेकिन हिटिंग और नायकों की 100% संभावना (जैसा कि MOBA शैली में है)।

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

आमतौर पर एक मैच में 8 लोग भाग लेते हैं। वे 4 लोगों की 2 टीमों में विभाजित हैं, और प्रत्येक एक चरित्र को नियंत्रित करता है। हालांकि, कदम दर कदम के कारण, कुछ भी ऐसा मोड बनाने से रोकता है जिसमें केवल 2 लोग भाग लेते हैं, और प्रत्येक अपनी टीम के सभी चार पात्रों को नियंत्रित करता है।

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

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

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

संकल्प को चरणों में विभाजित किया गया है। चरण क्रमिक रूप से चलते हैं, और प्रत्येक क्षमता के लिए खिलाड़ी पहले से जानते हैं कि यह किस चरण में काम करेगा। इस मामले में, एक चरण के भीतर क्षमताओं के संचालन का क्रम मायने नहीं रखता है।

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

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

कार्यान्वयन

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

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

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

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

अब मैं सबसे दिलचस्प (या कठिनाइयों का कारण) क्षणों पर अधिक विस्तार से ध्यान केंद्रित करूंगा, जो हमने खेल को विकसित करते समय सामना किया था।

क्षमताओं का उपयोग करने की प्रक्रिया

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

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

सरल खेल तर्क

खेल का बहुत विचार यह है कि खिलाड़ी अपने सिर की गणना पाठ्यक्रम के भीतर की घटनाओं के विकास में कर सकते हैं, और इसलिए सभी खेल तत्वों का तर्क सरल और सहज होना चाहिए। लेकिन योजना के कार्यान्वयन के साथ बहुत सी कठिनाइयाँ उत्पन्न हुईं।

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

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

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

क्या करें?

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

ईमानदार ज्यामिति

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

पेंट समय

— , — . ( ) — . , 90 .

न केवल केंद्रों के बीच, बल्कि कुछ विशिष्ट बिंदुओं के बीच दृश्यता सीमा की जांच करने का निर्णय लिया गया।

पेंट दो

तो, नायक के किनारों के साथ एक अतिरिक्त चार बिंदुओं के उपयोग ने "मृत क्षेत्र" को 60 डिग्री तक कम कर दिया (जो पहले से ही काफी चंचल हो गया है)।

नतीजतन, दीवारें वास्तव में उपयोगी हो गईं।

पेंट तीन

, 50% ( , ).

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

यहां gif (20Mb) की एक लिंक दी गई है , जहां आप देख सकते हैं कि शॉट प्वाइंट की ऑटोमैटिक शिफ्ट कैसे काम करती है।

स्थानीयकरण

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

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

जेली

अब मज़ेदार हिस्से के लिए। कुछ स्पष्ट सुझाव जो नौसिखिए प्रोग्रामर की मदद कर सकते हैं जो समान विचारधारा वाले लोगों की टीम में अपने पालतू प्रोजेक्ट को काटने का निर्णय लेते हैं।

यदि संभव हो, तो पहिया को सुदृढ़ न करें।
यदि समस्या व्यापक है, तो इसके लिए कई तैयार समाधान होने चाहिए। एक उपयुक्त तैयार किए गए समाधान को खोजने से खरोंच से खुद को लिखने में कम समय लग सकता है (विशेषकर यदि समस्या जटिल है)।
. , . , , . NetworkStream-, TcpClient- Json. , , . 30 ( MagicOnion, )
— , . — . . — . — .
— , . - summary readme. .
,
. . — , — , , .
Git — ,
, . .
,
. .
,
. , , , , . , , , .

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

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

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

विचार में रुचि रखने वालों के लिए लिंक

— Discord-. .

, , - — , Atlas Reactor

एक साथ चाल के साथ एक मोड़ आधारित PvP क्षेत्र लेखन