एंटिटी सिस्टम फ्रेमवर्क क्या है और गेम देव में इसकी आवश्यकता क्यों है?

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



पिछले हफ्ते मैंने एक्शनस्क्रिप्ट गेम विकसित करने के लिए ऐश -एंटिटी सिस्टम फ्रेमवर्क जारी किया और कई लोगों ने मुझसे सवाल पूछा कि "एंटिटी सिस्टम फ्रेमवर्क क्या है?"। यहाँ मेरा लंबा जवाब है।

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

इस पोस्ट में, मैं लगातार दिखाऊंगा कि पुराने जमाने के गेम लूप से एंटिटी आधारित वास्तुकला कैसे उभरती है। इसमें थोड़ा समय लगेगा। उपरोक्त उदाहरण Actionscript पर होंगे, क्योंकि यह वही है जो मैं इस समय उपयोग कर रहा हूं, लेकिन वास्तुकला स्वयं किसी भी प्रोग्रामिंग भाषा के लिए उपयुक्त है।

उदाहरण

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

खेल चक्र

वास्तव में यह समझने के लिए कि हम इकाई प्रणालियों का उपयोग क्यों करते हैं, आपको यह स्पष्ट रूप से समझना चाहिए कि अच्छा पुराना गेम चक्र कैसे काम करता है। क्षुद्रग्रहों के लिए, यह कुछ इस तरह दिख सकता है:

function update( time:Number ):void { game.update( time ); spaceship.updateInputs( time ); for each( var flyingSaucer:FlyingSaucer in flyingSaucers ) { flyingSaucer.updateAI( time ); } spaceship.update( time ); for each( var flyingSaucer:FlyingSaucer in flyingSaucers ) { flyingSaucer.update( time ); } for each( var asteroid:Asteroid in asteroids ) { asteroid.update( time ); } for each( var bullet:Bullet in bullets ) { bullet.update( time ); } collisionManager.update( time ); spaceship.render(); for each( var flyingSaucer:FlyingSaucer in flyingSaucers ) { flyingSaucer.render(); } for each( var asteroid:Asteroid in asteroids ) { asteroid.render(); } for each( var bullet:Bullet in bullets ) { bullet.render(); } } 

इस गेम लूप को नियमित अंतराल पर कहा जाता है, आमतौर पर खेल को अपडेट करने के लिए प्रति सेकंड 60 या 30 बार। लूप में संचालन का क्रम महत्वपूर्ण है क्योंकि हम विभिन्न गेम ऑब्जेक्ट्स को अपडेट करते हैं, उनके बीच टकराव की जांच करते हैं, और फिर उन सभी को आकर्षित करते हैं। हर फ्रेम।
यह एक बहुत ही सरल गेम लूप है क्योंकि:
1. खेल अपने आप में सरल है।
2. खेल में केवल एक राज्य है।
अतीत में, मैंने कंसोल गेम पर काम किया, जहां गेम लूप, एकमात्र फ़ंक्शन, जिसमें 3,000 से अधिक लाइनें शामिल थीं। यह सुंदर नहीं था और यह बेवकूफी थी। लेकिन यह उसी तरह था जैसे खेल बनाए गए और हमें इसके साथ रहना था।
एंटिटी सिस्टम आर्किटेक्चर गेम लूप की समस्याओं को हल करने की कोशिश से आया था। यह गेम लूप को गेम का मुख्य हिस्सा बनाता है और सुझाव देता है कि गेम लूप को सुव्यवस्थित करना आधुनिक गेम की वास्तुकला में किसी भी चीज की तुलना में अधिक महत्वपूर्ण है। उदाहरण के लिए, नियंत्रक से दृश्य को अलग करने की तुलना में यह अधिक महत्वपूर्ण है।

प्रक्रियाओं

इस विकास में पहला कदम वस्तुओं को कहा जाता है जिन्हें प्रक्रिया कहा जाता है। ये ऐसी वस्तुएँ हैं जिन्हें आरंभीकृत, अद्यतन और नष्ट किया जा सकता है। प्रक्रिया इंटरफ़ेस कुछ इस तरह दिखता है:

 interface IProcess { function start():Boolean; function update( time:Number ):void; function end():void; } 

यदि हम इसे कई प्रक्रियाओं में विभाजित करते हैं, तो हम खेल चक्र को सरल बना सकते हैं, जो जिम्मेदार होगा, उदाहरण के लिए, वस्तुओं को प्रस्तुत करने, या संचालन करने के लिए। इन प्रक्रियाओं का प्रबंधन करने के लिए, हम एक प्रक्रिया प्रबंधक बनाएंगे।

 class ProcessManager { private var processes:PrioritisedList; public function addProcess( process:IProcess, priority:int ):Boolean { if( process.start() ) { processes.add( process, priority ); return true; } return false; } public function update( time:Number ):void { for each( var process:IProcess in processes ) { process.update( time ); } } public function removeProcess( process:IProcess ):void { process.end(); processes.remove( process ); } } 

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

रेंडर प्रक्रिया

उदाहरण के लिए, प्रतिपादन प्रक्रिया को देखें। हम गेम लूप से रेंडर कोड को खींच सकते हैं और इसे इस प्रक्रिया में रख सकते हैं, कुछ इस तरह से:

 class RenderProcess implements IProcess { public function start() : Boolean { //    return true; } public function update( time:Number ):void { spaceship.render(); for each( var flyingSaucer:FlyingSaucer in flyingSaucers ) { flyingSaucer.render(); } for each( var asteroid:Asteroid in asteroids ) { asteroid.render(); } for each( var bullet:Bullet in bullets ) { bullet.render(); } } public function end() : void { //    } } 

हम इंटरफेस का उपयोग करते हैं

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

 interface IRenderable { function render(); } class RenderProcess implements IProcess { private var targets:Vector.<IRenderable>; public function start() : Boolean { //    return true; } public function update( time:Number ):void { for each( var target:IRenderable in targets ) { target.render(); } } public function end() : void { //    } } 

तब हमारे अंतरिक्ष यान के वर्ग में एक समान कोड होगा:

 class Spaceship implements IRenderable { public var view:DisplayObject; public var position:Point; public var rotation:Number; public function render():void { view.x = position.x; view.y = position.y; view.rotation = rotation; } } 

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

हम बेस क्लास और इनहेरिटेंस का उपयोग करते हैं

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

 class Renderable implements IRenderable { public var view:DisplayObject; public var position:Point; public var rotation:Number; public function render():void { view.x = position.x; view.y = position.y; view.rotation = rotation; } } class Spaceship extends Renderable { } 

निस्संदेह, आरेखित की जाने वाली सभी वस्तुएँ बेस क्लास का विस्तार करेंगी और हमें इस तरह एक पदानुक्रम मिलेगा:

आंदोलन की प्रक्रिया

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

 interface IMoveable { function move( time:Number ); } class MoveProcess implements IProcess { private var targets:Vector.<IMoveable>; public function start():Boolean { return true; } public function update( time:Number ):void { for each( var target:IMoveable in targets ) { target.move( time ); } } public function end():void { } } class Moveable implements IMoveable { public var position:Point; public var rotation:Number; public var velocity:Point; public var angularVelocity:Number; public function move( time:Number ):void { position.x += velocity.x * time; position.y += velocity.y * time; rotation += angularVelocity * time; } } class Spaceship extends Moveable { } 

एकाधिक वंशानुक्रम

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

 class Moveable extends Renderable implements IMoveable { public var velocity:Point; public var angularVelocity:Number; public function move( time:Number ):void { position.x += velocity.x * time; position.y += velocity.y * time; rotation += angularVelocity * time; } } class Spaceship extends Moveable { } 

अब हमारा स्पेसशिप मूविंग और रेंडरिंग दोनों में सक्षम है। हम अन्य गेम ऑब्जेक्ट्स पर समान सिद्धांत लागू कर सकते हैं और इस वर्ग को पदानुक्रम प्राप्त कर सकते हैं।


हम स्थैतिक वस्तुओं को भी प्राप्त कर सकते हैं जो केवल रेंडर करने योग्य है।

जंगम लेकिन भरोसेमंद नहीं

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

 class InvisibleMoveable implements IMoveable { public var position:Point; public var rotation:Number; public var velocity:Point; public var angularVelocity:Number; public function move( time:Number ):void { position.x += velocity.x * time; position.y += velocity.y * time; rotation += angularVelocity * time; } } 

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

वंशानुक्रम पर रचना को प्राथमिकता दें।

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

 class Renderable implements IRenderable { public var view:DisplayObject; public var position:Point; public var rotation:Number; public function render():void { view.x = position.x; view.y = position.y; view.rotation = rotation; } } class Moveable implements IMoveable { public var position:Point; public var rotation:Number; public var velocity:Point; public var angularVelocity:Number; public function move( time:Number ):void { position.x += velocity.x * time; position.y += velocity.y * time; rotation += angularVelocity * time; } } class Spaceship { public var renderData:IRenderable; public var moveData:IMoveable; } 

इस प्रकार, हम विभिन्न व्यवहारों को किसी भी तरह से विरासत में मिला सकते हैं बिना किसी विरासत के मुद्दों के।

इस संरचना का उपयोग करके बनाई गई ये वस्तुएं: स्टेटिक ऑब्जेक्ट, स्पेसशिप, फ्लाइंग सॉसर, एस्टेरॉयड और फोर्स फील्ड - सामूहिक रूप से एंटिटीज कहलाती हैं।
हमारी प्रक्रियाएँ नहीं बदलतीं।

 interface IRenderable { function render(); } class RenderProcess implements IProcess { private var targets:Vector.<IRenderable>; public function update(time:Number):void { for each(var target:IRenderable in targets) { target.render(); } } } interface IMoveable { function move(); } class MoveProcess implements IProcess { private var targets:Vector.<IMoveable>; public function update(time:Number):void { for each(var target:IMoveable in targets) { target.move( time ); } } } 

लेकिन हम प्रत्येक प्रक्रिया में एक जहाज वस्तु नहीं जोड़ेंगे, इसके बजाय हम इसके घटकों को जोड़ देंगे। और इसलिए हमें कुछ ऐसा मिलता है:

 public function createSpaceship():Spaceship { var spaceship:Spaceship = new Spaceship(); ... renderProcess.addItem( spaceship.renderData ); moveProcess.addItem( spaceship.moveData ); ... return spaceship; } 

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

सामान्य जानकारी के साथ क्या करना है?

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

 class Renderable implements IRenderable { public var view:DisplayObject; public var position:Point; public var rotation:Number; public function render():void { view.x = position.x; view.y = position.y; view.rotation = rotation; } } class Moveable implements IMoveable { public var position:Point; public var rotation:Number; public var velocity:Point; public var angularVelocity:Number; public function move( time:Number ):void { position.x += velocity.x * time; position.y += velocity.y * time; rotation += angularVelocity * time; } } class Spaceship { public var renderData:IRenderable; public var moveData:IMoveable; } 

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

 class PositionComponent { public var x:Number; public var y:Number; public var rotation:Number; } class VelocityComponent { public var velocityX:Number; public var velocityY:Number; public var angularVelocity:Number; } class DisplayComponent { public var view:DisplayObject; } class Renderable implements IRenderable { public var display:DisplayComponent; public var position:PositionComponent; public function render():void { display.view.x = position.x; display.view.y = position.y; display.view.rotation = position.rotation; } } class Moveable implements IMoveable { public var position:PositionComponent; public var velocity:VelocityComponent; public function move( time:Number ):void { position.x += velocity.velocityX * time; position.y += velocity.velocityY * time; position.rotation += velocity.angularVelocity * time; } } 

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

 class Spaceship { public function Spaceship() { moveData = new Moveable(); renderData = new Renderable(); moveData.position = new PositionComponent(); moveData.velocity = new VelocityComponent(); renderData.position = moveData.position; renderData.display = new DisplayComponent(); } } 

यह परिवर्तन अभी भी प्रक्रियाओं को प्रभावित नहीं करता है।

और यह आराम करने के लिए एक अच्छी जगह है।

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

गुड ऑब्जेक्ट ओरिएंटेड प्रैक्टिस से बचना

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

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

तो यह है:

 interface IRenderable { function render(); } class Renderable implements IRenderable { public var display:DisplayComponent; public var position:PositionComponent; public function render():void { display.view.x = position.x; display.view.y = position.y; display.view.rotation = position.rotation; } } class RenderProcess implements IProcess { private var targets:Vector.<IRenderable>; public function update( time:Number ):void { for each( var target:IRenderable in targets ) { target.render(); } } } 

यह बन जाएगा:

 class RenderData { public var display:DisplayComponent; public var position:PositionComponent; } class RenderProcess implements IProcess { private var targets:Vector.<RenderData>; public function update( time:Number ):void { for each( var target:RenderData in targets ) { target.display.view.x = target.position.x; target.display.view.y = target.position.y; target.display.view.rotation = target.position.rotation; } } } 

और यह:

 interface IMoveable { function move( time:Number ); } class Moveable implements IMoveable { public var position:PositionComponent; public var velocity:VelocityComponent; public function move( time:Number ):void { position.x += velocity.velocityX * time; position.y += velocity.velocityY * time; position.rotation += velocity.angularVelocity * time; } } class MoveProcess implements IProcess { private var targets:Vector.<IMoveable>; public function move( time:Number ):void { for each( var target:Moveable in targets ) { target.move( time ); } } } 

यह बन जाएगा:

 class MoveData { public var position:PositionComponent; public var velocity:VelocityComponent; } class MoveProcess implements IProcess { private var targets:Vector.<MoveData>; public function move( time:Number ):void { for each( var target:MoveData in targets ) { target.position.x += target.velocity.velocityX * time; target.position.y += target.velocity.velocityY * time; target.position.rotation += target.velocity.angularVelocity * time; } } } 

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

पहला स्पष्ट निष्कर्ष यह है कि रेंडरप्रोसेस में अब रेंडर कोड के बाद से सभी संस्थाओं के पास एक ही रेंडरिंग विधि होनी चाहिए। लेकिन केवल इतना ही नहीं। उदाहरण के लिए, हम दो प्रक्रियाएँ बना सकते हैं, RenderMovieClip और RenderBitmap, और वे संस्थाओं के विभिन्न सेटों पर काम कर सकते हैं। इस प्रकार, हम कोड के लचीलेपन में नहीं खोएंगे।

हमें जो मिलता है, वह एक अधिक समझने योग्य पृथक्करण और सरल विन्यास के साथ एक वास्तुकला प्राप्त करने के लिए हमारी संस्थाओं को काफी हद तक परिष्कृत करने की क्षमता है। रिफैक्टरिंग एक सवाल के साथ शुरू होगी।

क्या हमें मूल्य वर्गों की आवश्यकता है?

फिलहाल, हमारा सार

 class Spaceship { public var moveData:MoveData; public var renderData:RenderData; } 

दो वर्ग शामिल हैं

 class MoveData { public var position:PositionComponent; public var velocity:VelocityComponent; } class RenderData { public var display:DisplayComponent; public var position:PositionComponent; } 

इन डेटा वर्गों में तीन घटक होते हैं:

 class PositionComponent { public var x:Number; public var y:Number; public var rotation:Number; } class VelocityComponent { public var velocityX:Number; public var velocityY:Number; public var angularVelocity:Number; } class DisplayComponent { public var view:DisplayObject; } 

और ये मूल्य वर्ग दो प्रक्रियाओं में उपयोग किए जाते हैं:

 class MoveProcess implements IProcess { private var targets:Vector.<MoveData>; public function move( time:Number ):void { for each( var target:MoveData in targets ) { target.position.x += target.velocity.velocityX * time; target.position.y += target.velocity.velocityY * time; target.position.rotation += target.velocity.angularVelocity * time; } } } class RenderProcess implements IProcess { private var targets:Vector.<RenderData>; public function update( time:Number ):void { for each( var target:RenderData in targets ) { target.display.view.x = target.position.x; target.display.view.y = target.position.y; target.display.view.rotation = target.position.rotation; } } } 

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

 class Spaceship { public var position:PositionComponent; public var velocity:VelocityComponent; public var display:DisplayComponent; } class PositionComponent { public var x:Number; public var y:Number; public var rotation:Number; } class VelocityComponent { public var velocityX:Number; public var velocityY:Number; public var angularVelocity:Number; } class DisplayComponent { public var view:DisplayObject; } 

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

सिस्टम और नोड्स।

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

 class MoveNode { public var position:PositionComponent; public var velocity:VelocityComponent; } class RenderNode { public var display:DisplayComponent; public var position:PositionComponent; } 

प्रक्रियाएँ स्वयं नहीं बदलेंगी, लेकिन, अधिक सामान्य नामकरण नियमों को बनाए रखते हुए, हम उन्हें सिस्टम में बदल देंगे।

 class MoveSystem implements ISystem { private var targets:Vector.<MoveNode>; public function update( time:Number ):void { for each( var target:MoveNode in targets ) { target.position.x += target.velocity.velocityX * time; target.position.y += target.velocity.velocityY * time; target.position.rotation += target.velocity.angularVelocity * time; } } } class RenderSystem implements ISystem { private var targets:Vector.<RenderNode>; public function update( time:Number ):void { for each( var target:RenderNode in targets ) { target.display.view.x = target.position.x; target.display.view.y = target.position.y; target.display.view.rotation = target.position.rotation; } } } interface ISystem { function update( time:Number ):void; } 

और सार क्या है?

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

 class Entity { private var components : Dictionary; public function add( component:Object ):void { var componentClass : Class = component.constructor; components[ componentClass ] = component' } public function remove( componentClass:Class ):void { delete components[ componentClass ]; } public function get( componentClass:Class ):Object { return components[ componentClass ]; } } 

और इसलिए हम अपना स्पेसशिप बनाएंगे:

 public function createSpaceship():void { var spaceship:Entity = new Entity(); var position:PositionComponent = new PositionComponent(); position.x = Stage.stageWidth / 2; position.y = Stage.stageHeight / 2; position.rotation = 0; spaceship.add( position ); var display:DisplayComponent = new DisplayComponent(); display.view = new SpaceshipImage(); spaceship.add( display ); engine.add( spaceship ); } 

इंजन कोर क्लास

हमें सिस्टम मैनेजर के बारे में नहीं भूलना चाहिए, जिसे पहले प्रोसेस मैनेजर के रूप में जाना जाता था:

 class SystemManager { private var systems:PrioritisedList; public function addSystem( system:ISystem, priority:int ):void { systems.add( system, priority ); system.start(); } public function update( time:Number ):void { for each( var system:ISystem in systemes ) { system.update( time ); } } public function removeSystem( system:ISystem ):void { system.end(); systems.remove( system ); } } 

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

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

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

 public class Engine { private var entities:EntityList; private var systems:SystemList; private var nodeLists:Dictionary; public function addEntity( entity:Entity ):void { entities.add( entity ); //            //         //        } public function removeEntity( entity:Entity ):void { //  ,    //       entities.remove( entity ); } public function addSystem( system:System, priority:int ):void { systems.add( system, priority ); system.start(); } public function removeSystem( system:System ):void { system.end(); systems.remove( system ); } public function getNodeList( nodeClass:Class ):NodeList { var nodes:NodeList = new NodeList(); nodeLists[ nodeClass ] = nodes; // create the nodes from the current set of entities // and populate the node list return nodes; } public function update( time:Number ):void { for each( var system:ISystem in systemes ) { system.update( time ); } } } 

यह देखने के लिए कि यह व्यवहार में कैसा दिखता है, मेरा ऐश एंटिटी सिस्टम फ्रेमवर्क डाउनलोड करें और गेम एस्टरॉयड का कार्यान्वयन देखें ।

निष्कर्ष

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

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

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



मूल