इकाई घटक प्रणाली टेम्पलेट का उपयोग कर LibGDX पर गेम विकसित करना

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

पहली बार हमेशा दर्द होता है

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

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

खेल इस तरह दिखता है:



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

ऊपर वर्णित सभी कारक और प्रिय, आग्रह करने वाले प्रबंधकों ने हमें बिना किसी वास्तुकला के एक गेम मैकेनिक लिखने के लिए प्रेरित किया।

परिणामी खेल का वर्णन

अधिकांश कोड कक्षाओं में संकलित किए गए थे: MyGdxGame: गेम , गेमस्क्रीन: स्क्रीन और ट्रैफिकगैम: अभिनेता ।

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

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

ट्रैफिकगैम - दृश्य का मुख्य अभिनेता जिसमें खेल की सभी गति होती है: कार्य का प्रतिपादन और तर्क।

यद्यपि दृश्य 2 डी का उपयोग अभिनेता घोंसले के पेड़ का निर्माण करना संभव बनाता है, यह सबसे अच्छा वास्तु समाधान नहीं है। हालांकि, UI / UX गेम (LibGDX पर) लागू करने के लिए, दृश्य 2 डी एक बेहतरीन विकल्प है।

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

var isGameActive: Boolean = true set(value) { backgroundActor?.isGameActive = value boostersMap.values.filterNotNull().forEach { it.isGameActive = value } obstaclesMap.values.filterNotNull().forEach { it.isGameActive = value } finishActor.isGameActive = value field = value } private var backgroundActoolbarActor private val pauseButtonActor: PauseButtonActor private val finishActor: FinishActor private var isQuizWon = falser: BackgroundActor? = null private var playerCarActor: PlayerCarActor private var toolbarActor: To private var pointsTime = 0f private var totalTimeElapsed = 0 private val timeToFinishTheGame = 50 private var lastQuizBoosterTime = 0.0f private var lastBoosterTime = 0.0f private val boostersMap = hashMapOf<Long?, BoosterActor?>() private var boosterSpawnedCount = 0 private var totalBoostersEatenCount = 0 private val boosterLimit = 20 private var lastBoosterYPos = 0.0f private var toGenerateBooster = false private var lastObstacleTime = 0.0f private var obstaclesMap = hashMapOf<Long?, ObstacleActor?>() 

स्वाभाविक रूप से, आपको ऐसा नहीं लिखना चाहिए। लेकिन बचाव में मैं कहूंगा कि ऐसा इसलिए हुआ क्योंकि:

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

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



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

ईसीएस हमारा सब कुछ है

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




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

मुझे मोबाइल उपकरणों के लिए और बंद घंटे के दौरान गेम का विकास पसंद है, प्रयोग के लिए, मैं गेम पैटर्न और खेल के विकास से संबंधित बाकी सभी चीजों का पता लगाऊंगा। मैंने गेम डिज़ाइन पैटर्न पर एक किताब पढ़ी, लेकिन समझ में नहीं आया कि गेमप्ले लॉजिक का बहुत सच्चा आर्किटेक्चर क्या होना चाहिए, जब तक कि मैं ईसीएस में नहीं आया।

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

पैटर्न के घटकों पर विचार करें:

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

   class VelocityComponent: Component { val velocity = Vector2() } 

• इकाई - खेल वस्तुएं: बाधाएं / बूस्टर / नियंत्रित नायक और यहां तक ​​कि पृष्ठभूमि। उनके पास विशेष प्रकार के वर्ग नहीं हैं: UltraMegaSuperman: GameUnit, लेकिन बस घटक सेट के लिए कंटेनर हैं । तथ्य यह है कि एक निश्चित इकाई जिससे UltraMegaSuperman अपने घटकों और उनके मापदंडों के सेट को परिभाषित करता है।
  उदाहरण के लिए, हमारे मामले में, मुख्य पात्र में निम्नलिखित घटक थे:
  
  
  • TextureComponent - स्क्रीन पर क्या आकर्षित करता है, इसे परिभाषित करता है
  • ट्रांसफॉर्मकंपोनेंट - गेम स्पेस में ऑब्जेक्ट की स्थिति
  • वेलोसोकोम्पोनेंट - गेम स्पेस में ऑब्जेक्ट की गति
  • HeroControllerComponent - इसमें ऐसे मान होते हैं जो नायक की गति को प्रभावित करते हैं
  • ImmortalityTimeComponent - में अमरता का शेष समय होता है
  • डायनामिककंपोनेंट - इंगित करता है कि ऑब्जेक्ट स्थिर नहीं है और गुरुत्वाकर्षण के अधीन है
  • BodyComponent - टकरावों की गणना करने के लिए आवश्यक भौतिक 2d नायक शरीर को परिभाषित करता है
• सिस्टम - प्रत्येक इकाई के घटकों से डेटा को संसाधित करने के लिए कोड होता है। उन्हें इकाई और / या घटक वस्तुओं को संग्रहीत नहीं करना चाहिए, क्योंकि यह पैटर्न के विपरीत होगा। आदर्श रूप से, उन्हें बिल्कुल साफ होना चाहिए।
  
  सिस्टम सभी गंदे काम करते हैं: खेल में सभी वस्तुओं को आकर्षित करें, ऑब्जेक्ट को अपनी गति से आगे बढ़ाएं, टकरावों की जांच करें, आने वाले नियंत्रण से गति को बदलें, और इसी तरह। उदाहरण के लिए, गुरुत्वाकर्षण का प्रभाव इस तरह दिखता है:
  
  

   override fun processEntity(entity: Entity, deltaTime: Float) { entity.getComponent(VelocityComponent::class.java) .velocity .add(0f, -GRAVITY * deltaTime) } 

  
  प्रत्येक प्रणाली का विशेषज्ञता उन संस्थाओं के लिए आवश्यकताओं को निर्धारित करता है जिन्हें इसे संसाधित करना होगा। यही है, ऊपर दिए गए उदाहरण में, इकाई में वेलोसोमकंपोनेंट और डायनेमिककंपोनेंट वेग घटक होने चाहिए ताकि इस इकाई को संसाधित किया जा सके, अन्यथा इकाई सिस्टम के लिए दिलचस्प नहीं है, और इसलिए दूसरों के साथ। एक बनावट को आकर्षित करने के लिए, उदाहरण के लिए, आपको यह जानना होगा कि TextureComponent बनावट क्या है और TransformComponent को कहाँ आकर्षित करना है। प्रत्येक प्रणाली में आवश्यकताओं को निर्धारित करने के लिए, परिवार को कंस्ट्रक्टर में लिखा जाता है जिसमें घटकों की कक्षाएं इंगित की जाती हैं।
  
  

   Family.all(TransformComponent::class.java, TextureComponent::class.java).get() 

  
  इसके अलावा, सिस्टम के भीतर प्रसंस्करण संस्थाओं का क्रम एक तुलनित्र द्वारा समायोजित किया जा सकता है। इसके अलावा, इंजन में सिस्टम के निष्पादन का क्रम भी प्राथमिकता मूल्य द्वारा नियंत्रित होता है।
  

इंजन तीन घटकों को जोड़ता है। इसमें गेम में सभी सिस्टम और सभी इकाइयां शामिल हैं। खेल की शुरुआत में, खेल में सभी आवश्यक सिस्टम

 engine.apply { addSystem(ControlSystem()) addSystem(GravitySystem()) addSystem(renderingSystem) addSystem(MovementSystem()) addSystem(EnemyGeneratorSystem()) } 

इंजन के साथ-साथ शुरुआती इकाइयाँ जोड़ी जाती हैं,

 val hero: Entity = engine.createEntity() engine.addEntity(hero) 

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

पैटर्न के मुख्य भागों के बीच संबंध नीचे प्रस्तुत किया गया है:



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

खेल चक्र इस प्रकार संरचित है:

1. LibGDX से "गेम साइकिल" पैटर्न के कार्यान्वयन का उपयोग करते हुए, अपडेट विधि में हम प्रत्येक समय कदम पर इसकी वृद्धि प्राप्त करते हैं - डेल्टा टाइम।
2. अगला, हम इंजन को समय देते हैं। और वह बदले में, एक चक्र में सिस्टम के माध्यम से पुनरावृत्ति करता है, उन्हें डेल्टा टाइम वितरित करता है।

    for (i in 0 until systems.size()) { val system = systems[i] if (system.checkProcessing()) { system.update(deltaTime) } } 

3. अपने सिस्टम के माध्यम से डेल्टा टाईप प्राप्त करने वाले सिस्टम और उन्हें डील्टा टाइम में लेते हुए परिवर्तन लागू करते हैं।

    for (i in 0 until entities.size()) { processEntity(entities[i], deltaTime) } 

यह खेल के हर उपाय के साथ होता है।

ईसीएस के लाभ

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

Gamedev की बड़ी दुनिया में ECS

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

बेहतर समझ के लिए, मैंने जीथब पर एक छोटा सा उदाहरण दिया ।
आपका ध्यान के लिए धन्यवाद!

विषय पर भी:

• खेल का कार्यान्वयन और उदाहरण
• ईसीएस और ऑल-ऑल-ऑल
• ईसीएस मूल बातें
• घटक और इकाई प्रणाली