विरासत में क्या गलत है? पुशबटन इंजन ढांचे का उपयोग करते हुए फ़्लैश खेल विकास

कई विशेष रूपरेखाएं नहीं हैं जो फ़्लैश गेम्स के विकास में तेजी लाती हैं। जो सुना जाता है, उनमें से निम्नलिखित पर ध्यान दिया जा सकता है:

Flixel
FlashPunk
साइट्रस इंजन
पुशबटन इंजन

इस पोस्ट के साथ, मैं पुशबटन इंजन नामक एक होनहार ओपन सोर्स इंजन के लिए साथी फ्लैशर्स का ध्यान आकर्षित करना चाहता हूं। PBEs पहले ही Adobe Max 2010 में पेश करने में कामयाब रहे हैं और इस पर #facebook.com के अनुसार # 2 टॉप फेसबुक गेम 2010 विकसित कर चुके हैं । इसका उपयोग Zynga, Playdom, Hive7 जैसी कंपनियों द्वारा खेल विकास के लिए किया जाता है।

इंजन के डेवलपर्स गेम डेवलपमेंट सर्किल में जाने-माने लोग हैं जिन्होंने द इनक्रेडिबल मशीन, ट्राइब्स, टॉर्क और अन्य जैसे गेम बनाए।

विकास के लिए एक जिज्ञासु घटक दृष्टिकोण प्रस्तावित है, जो लेखकों के अनुसार, पारंपरिक वस्तु-उन्मुख की तुलना में खेल के विकास में बहुत अधिक सुविधाजनक और उत्पादक है।

इंजन की कुछ विशेषताएं:

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

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

पाठ १
पाठ २
पाठ ३
पाठ ४

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

विरासत में क्या गलत है?

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



इसके बाद, हम सब्जेक्ट क्लास को जोड़ते हैं और पैरेंट क्लास गेम एंटिटी में सामान्य कार्यक्षमता को रखते हैं:



खेल बढ़ रहा है, वर्ग पदानुक्रम की जटिलता इसके साथ बढ़ रही है, लेकिन अभी तक सब कुछ अच्छा लग रहा है।



लेकिन जल्द या बाद में, अप्रिय प्रश्न उठने लगते हैं। उदाहरण के लिए, ऑब्जेक्ट क्लास से मूविंग आइटम क्लास को किससे, या कैन मूव क्लास से ले सकते हैं?



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



कोड को डीबग करना, संशोधित करना और बनाए रखना मुश्किल हो जाता है।

क्या समाधान प्रस्तावित किया जा रहा है?

इस स्थिति में बाहर का रास्ता एक रचना हो सकता है - खेल को तार्किक संस्थाओं में विभाजित करना जो आवश्यक घटकों से भरे हुए हैं। उदाहरण के लिए, हमारे पास 3 इकाइयाँ हैं: प्लेयर, शत्रु और आइटम।



घटकों के रूप में, हम, एक निर्माता के रूप में, संस्थाओं का निर्माण करते हैं:



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

पुशबटन इंजन में घटक दृष्टिकोण कैसे लागू किया जाता है?

घटक बनाने का कोड पैकेज में है

com.pblabs.engine.entity.*

एक इकाई प्रकार इकाई का एक हल्का कंटेनर है जो IEntity इंटरफ़ेस को लागू करता है। बनाने के लिए, कारखाना विधि का उपयोग करें allocateEntity :

var myEntity:IEntity = PBE.allocateEntity();

हम निर्मित इकाई को इनिशियलाइज़ करते हैं, इसे एक ऐसा नाम देते हैं जिसके द्वारा हम बाद में इसे अपने कोड में कहीं भी पा सकते हैं:

myEntity.initialize("MyEntity");

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



घटक आवृत्ति बनाने और कॉन्फ़िगर करने के बाद, इसे addComponent विधि का उपयोग करके इकाई में जोड़ें:

myEntity.addComponent(myComponent, "MyComponent");

जैसा कि आपने शायद देखा है, प्रत्येक इकाई या घटक को एक स्ट्रिंग नाम सौंपा गया है। यह आवश्यक है ताकि हम कोड में कहीं भी विशेष देखने के तरीकों का उपयोग करके उन्हें प्राप्त कर सकें:

PBE.lookupEntity
PBE.lookupComponentByName

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