रचना बनाम विरासत, टीम पैटर्न और सामान्य रूप से खेल विकास

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

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

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

वह अपने खेल डिजाइन व्यवसाय पर भाग गया, और मैंने आईडीई खोला।

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

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

class Character { x = 0; y = 0; moveTo (x, y) { this.x = x; this.y = y; } } class Mage extends Character { mana = 100; castSpell () { this.mana--; } } class Warrior extends Character { stamina = 100; meleeHit () { this.stamina--; } } 

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

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

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

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

 class Character { abilities = []; addAbility (...abilities) { for (const a of abilities) { this.abilities.push(a); } return this; } getAbility (AbilityClass) { for (const a of this.abilities) { if (a instanceof AbilityClass) { return a; } } return null; } } /////////////////////////////////////// // //    ,      //       // /////////////////////////////////////// class Ability {} class HealthAbility extends Ability { health = 100; maxHealth = 100; } class MovementAbility extends Ability { x = 0; y = 0; moveTo(x, y) { this.x = x; this.y = y; } } class SpellCastAbility extends Ability { mana = 100; maxMana = 100; cast () { this.mana--; } } class MeleeFightAbility extends Ability { stamina = 100; maxStamina = 100; constructor (power) { this.power = power; } hit () { this.stamina--; } } /////////////////////////////////////// // //        // /////////////////////////////////////// class CharactersFactory { createMage () { return new Character().addAbility( new MovementAbility(), new HealthAbility(), new SpellCastAbility() ); } createWarrior () { return new Character().addAbility( new MovementAbility(), new HealthAbility(), new MeleeFightAbility(3) ); } createPaladin () { return new Character().addAbility( new MovementAbility(), new HealthAbility(), new SpellCastAbility(), new MeleeFightAbility(2) ); } } 

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

 createMagicTree () { return new Character().addAbility( new SpellCastAbility() ); } 

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

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

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

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

मैंने अपने आप को शाप दिया, क्योंकि मैं पूरी तरह से भूल गया था कि हमें अभी भी दृश्य को खराब करना है। अरे, यह वास्तुकला को फिर से लिखना है।

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

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

 class DealDamageCommand extends Command { constructor (target, damage) { this.target = target; this.damage = damage; } execute () { const healthAbility = this.target.getAbility(HealthAbility); if (healthAbility == null) { throw new Error('NoHealthAbility'); } const resultHealth = healthAbility.health - this.damage; healthAbility.health = Math.max( 0, resultHealth ); } } 

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

 class MeleeHitCommand extends Command { constructor (source, target, damage) { this.source = source; this.target = target; this.damage = damage; } execute () { const fightAbility = this.source.getAbility(MeleeFightAbility); if (fightAbility == null) { throw new Error('NoFightAbility'); } this.addChildren([ new DealDamageCommand(this.target, fightAbility.power); ]); } } 

इन दो टीमों में वह सब कुछ है जो आपको हमारे एनिमेशन के लिए चाहिए। एक रेंडरर घटनाओं की सदस्यता ले सकता है और वह सब कुछ प्रदर्शित कर सकता है जो कलाकार निम्नलिखित कोड के साथ चाहते हैं:

 async onMeleeHit (meleeHitCommand) { await view.drawMeleeHit( meleeHitCommand.source, meleeHitCommand.target ); } async onDealDamage (dealDamageCommand) { await view.showDamageNumbers( dealDamageCommand.target, dealDamageCommand.damage ); } 

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

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

हमारी वास्तुकला मंत्र के जटिल संयोजनों को बनाना आसान बनाती है। बस यह है कि प्रत्येक वर्तनी उन आदेशों की सूची लौटा सकती है जिन्हें कलाकारों के दौरान किए जाने की आवश्यकता होती है

 class CastSpellCommand extends Command { constructor (source, target, spell) { this.source = source; this.target = target; this.spell = spell; } execute () { const spellAbility = this.source.getAbility(SpellCastAbility); if (spellAbility == null) { throw new Error('NoSpellCastAbility'); } this.addChildren(new PayManaCommand(this.source, this.spell.manaCost)); this.addChildren(this.spell.getCommands(this.source, this.target)); } } class Spell { manaCost = 0; getCommands (source, target) { return []; } } class DamageSpell extends Spell { manaCost = 3; constructor (damageValue) { this.damageValue = damageValue; } getCommands (source, target) { return [ new DealDamageCommand(target, this.damageValue) ]; } } class HealSpell extends Spell { manaCost = 2; constructor (healValue) { this.healValue = healValue; } getCommands (source, target) { return [ new HealDamageCommand(target, this.healValue) ]; } } class VampireSpell extends Spell { manaCost = 5; constructor (value) { this.value = value; } getCommands (source, target) { return [ new DealDamageCommand(target, this.value), new HealDamageCommand(source, this.value) ]; } } 

डेढ़ साल बाद

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

- सुनो - खेल डिजाइनर ने लिखा - मेरे पास एक महान विचार है ...