मैं एक इकाई प्रणाली में सुविधाओं को कैसे लागू करूं?

31

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

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

अब मेरे पास जो समस्या है, वह मेरे पुराने इंजन कॉन्सेप्ट को इस नए प्रोग्रामिंग प्रतिमान में फिट कर रही है। ये पिछले प्रश्नों में से कुछ परिभाषाएँ हैं, जिन्हें अद्यतन किया गया है:

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

कैमरा

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

मैं एक इकाई प्रणाली में इस तरह की वस्तु का प्रतिनिधित्व कैसे कर सकता हूं? क्या कैमरा एक इकाई, एक घटक या संयोजन (मेरे उत्तर के अनुसार ) होगा?

कण एमिटर

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

मैं एक इकाई प्रणाली में इस तरह की वस्तु का प्रतिनिधित्व कैसे कर सकता हूं?

इनपुट मैनेजर

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

यह एक इकाई प्रणाली में कैसे परिवर्तित होता है?

javascript entity-system component-based

— jcora
स्रोत

26

कैमरा: इसे कंपोनेंट बनाना काफी साफ-सुथरा होगा। यह सिर्फ एक होगाisRenderingशॉन की तरह ध्वज और गहराई सीमा। "देखने के क्षेत्र" के अलावा (मुझे लगता है कि आप इसे 2 डी में स्केल कह सकते हैं?) और एक आउटपुट ज़ोन। आउटपुट ज़ोन गेम विंडो के उस हिस्से को परिभाषित कर सकता है जिसे यह कैमरा प्रदान करता है। यह एक अलग स्थिति / रोटेशन नहीं होगा जैसा कि आप उल्लेख करते हैं। आपके द्वारा बनाया गया इकाई जिसमें कैमरा घटक है, उस इकाई की स्थिति और रोटेशन घटकों का उपयोग करेगा। फिर आपके पास एक कैमरा सिस्टम होगा जो उन संस्थाओं के लिए दिखता है जिनके पास कैमरा, स्थिति और रोटेशन घटक हैं। सिस्टम उस इकाई को लेता है और स्क्रीन के निर्दिष्ट हिस्से तक स्थिति, रोटेशन, देखने की गहराई और देखने के क्षेत्र से इसे "देख" सकता है। आपको मल्टीपल व्यू पोर्ट, "कैरेक्टर व्यू" विंडो, लोकल मल्टीप्लेयर,
कण एमिटर: यह भी केवल एक घटक होना चाहिए। कण प्रणाली एक स्थिति, रोटेशन और कण उत्सर्जक वाली संस्थाओं की तलाश करेगी। Emitter में आपके वर्तमान emitter को पुन: पेश करने के लिए आवश्यक सभी गुण हैं, मुझे यकीन नहीं है कि वे सभी क्या हैं, जैसे सामान: दर, प्रारंभिक वेग, क्षय समय और इसी तरह। आपको कई पास नहीं बनाने होंगे। कण प्रणाली को पता है कि किन अवयवों में वह घटक है। मुझे लगता है कि आप अपने मौजूदा कोड का एक अच्छा सौदा फिर से उपयोग कर सकते हैं।
इनपुट्स: मेरा कहना है कि इसे एक घटक में बनाना सबसे अधिक समझदारी है जो मैं ऊपर दिए गए सुझाव देता हूं। तुंहारेinput systemवर्तमान इनपुट घटनाओं के साथ हर फ्रेम को अपडेट किया जाएगा। फिर जब यह उन सभी संस्थाओं से गुजर रहा है जिनके पास इनपुट घटक है, तो यह उन घटनाओं को लागू करेगा। इनपुट घटक में सभी संबंधित विधि कॉलबैक कीबोर्ड और माउस घटनाओं की एक सूची होगी। मुझे वास्तव में यकीन नहीं है कि विधि कॉलबैक कहां रहेगी। शायद कुछ इनपुट नियंत्रक वर्ग? जो कुछ भी आपके इंजन के उपयोगकर्ताओं द्वारा बाद में संशोधन के लिए सबसे अधिक समझ में आता है। लेकिन यह आपको कैमरा एंटिटीज, प्लेयर एंटिटीज या जो भी आपको चाहिए, आसानी से इनपुट कंट्रोल लागू करने की शक्ति देगा। कीबोर्ड के साथ संस्थाओं के एक समूह के आंदोलन को सिंक्रनाइज़ करना चाहते हैं? बस उन सभी इनपुट घटकों को दें जो एक ही इनपुट पर प्रतिक्रिया देते हैं और इनपुट सिस्टम उन सभी घटकों पर उन घटनाओं को लागू करता है जो उनके लिए पूछ रहे हैं।

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

— माइकलहाउस
स्रोत

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

— जकोरा

यह वास्तुशिल्प रूप से शुद्ध लगता है, लेकिन प्रतिपादन प्रणाली सभी संस्थाओं के माध्यम से पुनरावृत्ति के सक्रिय कैमरे का निर्धारण कैसे करती है?

— पेस

@Pace के बाद से मैं चाहता हूं कि सक्रिय कैमरा बहुत जल्दी मिल जाए, मैं संभवतः कैमरा सिस्टम को उन संस्थाओं के लिए एक संदर्भ रखने की अनुमति दूंगा जिनके पास एक सक्रिय कैमरा है।

— MichaelHouse

आप कई कैमरों को नियंत्रित करने के लिए तर्क कहां देते हैं (देखें, घुमाएं, घुमाएं, आदि)। आप कई कैमरों को कैसे नियंत्रित करते हैं?

— प्लाजमासेल 19

@plasmacel यदि आपके पास नियंत्रण साझा करने वाली कई वस्तुएँ हैं, तो यह निर्धारित करना आपके नियंत्रण प्रणाली की ज़िम्मेदारी होगी कि कौन सी वस्तु इनपुट प्राप्त करती है।

— MichaelHouse

13

यहाँ बताया गया है कि मैंने यह कैसे किया:

कैमरा

मेरा कैमरा किसी अन्य की तरह एक इकाई है, जिसमें संलग्न घटक हैं:

Transformहै Translation, Rotationऔर Scaleगुण, वेग के लिए दूसरों के अलावा, आदि।
Pov(देखने के प्वाइंट) है FieldOfView, AspectRatio, Near, Far, और कुछ और एक प्रक्षेपण मैट्रिक्स उत्पादन करने के लिए, एक के अलावा आवश्यक IsOrthoपरिप्रेक्ष्य और ओर्थोग्रफिक अनुमानों के बीच स्विच करने के लिए इस्तेमाल झंडा। रेंडरिंग सिस्टम द्वारा उपयोग की जाने वाली Povएक आलसी-लोड ProjectionMatrixसंपत्ति भी प्रदान करता है जिसे आंतरिक रूप से पढ़ने पर गणना की जाती है, और जब तक कि किसी अन्य गुण को संशोधित नहीं किया जाता है।

कोई समर्पित कैमरा सिस्टम नहीं है। रेंडर सिस्टम एक सूची रखता है Povऔर इसमें यह निर्धारित करने के लिए तर्क होता है कि रेंडर करते समय किसका उपयोग करना है।

इनपुट

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

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

यहां उन ईवेंट हैंडलर को संभालना है जो फ्रेम के बीच लगे होते हैं जो जहाज के InputReceiverकंपोनेंट (C #) से जुड़े होते हैं:

  void ship_input_Hold(object sender, InputEventArgs args)
    {
        var k = args.Keys;
        var e = args.Entity;

        var dt = (float)args.GameTime.ElapsedGameTime.TotalSeconds;

        var verlet = e.As<VerletMotion>();
        var transform = e.As<Transform>();

        if (verlet != null)
        {

        /// calculate applied force 
            var force = Vector3.Zero;
            var forward = transform.RotationMatrix.Up * Settings.ShipSpeedMax;

            if (k.Contains(Keys.W))
                force += forward;

            if (k.Contains(Keys.S))
                force -= forward;

            verlet.Force += force * dt;
        }

        if (transform != null)
        {
            var theta = Vector3.Zero;

            if (k.Contains(Keys.A))
                theta.Z += Settings.TurnRate;

            if (k.Contains(Keys.D))
                theta.Z -= Settings.TurnRate;

            transform.Rotation += theta * dt;
        }

        if (k.Contains(Keys.Space))
        {
            var time = (float)args.GameTime.TotalGameTime.TotalSeconds - _rapidFireLast;

            if (time >= _rapidFireDelay)
            {
                Fire();
                _rapidFireLast = (float)args.GameTime.TotalGameTime.TotalSeconds;
            }
        }
    }

यदि आपका कैमरा मोबाइल है, तो उसे अपना InputReceiverऔर Transformकंपोनेंट दें, एक लैम्ब्डा या हैंडलर संलग्न करें, जो भी आप चाहते हैं, जिस तरह का नियंत्रण चाहते हैं उसे लागू करता है।

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

एक InputSystemवर्ग जो कीबोर्ड, माउस इत्यादि के लिए एक आंतरिक स्थिति को बनाए रखता है, InputSystemअपने आंतरिक इकाई संग्रह को एक InputReceiverघटक के लिए फ़िल्टर करता है । अपनी Update()पद्धति में, यह उस संग्रह के माध्यम से पुनरावृत्त करता है और प्रत्येक घटक से जुड़े इनपुट हैंडलर को उसी तरह से कॉल करता है, जिसमें रेंडरिंग सिस्टम प्रत्येक इकाई को एक Renderableघटक के साथ खींचता है ।

कण

यह वास्तव में इस बात पर निर्भर करता है कि आप कणों के साथ बातचीत करने की योजना कैसे बनाते हैं। यदि आपको बस एक कण प्रणाली की आवश्यकता है जो एक वस्तु की तरह व्यवहार करती है - कहो, एक आतिशबाजी दिखाती है कि खिलाड़ी स्पर्श या हिट नहीं कर सकता है - तो मैं एक एकल इकाई बनाऊंगा, और एक ParticleRenderGroupघटक जिसमें कुछ भी जानकारी होगी जो आपको कणों के लिए आवश्यक है - क्षय, आदि - जो आपके Renderableघटक द्वारा कवर नहीं किया गया है । प्रतिपादन करते समय, रेंडर प्रणाली यह देखती है कि क्या किसी संस्था ने RenderParticleGroupसंलग्न किया है और तदनुसार इसे संभाल सकता है।

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

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

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

निष्कर्ष

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

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

— 3Dave
स्रोत

आप कई कैमरों को नियंत्रित करने के लिए तर्क कहां देते हैं (देखें, घुमाएं, घुमाएं, आदि)।

— प्लाज़्मासेल 19

7

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

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

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

— शॉन मिडिल्डिच
स्रोत

4

क्या कैमरा एक इकाई या बस एक घटक होगा?

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

मुझे पूरा यकीन है कि कण खुद नहीं होने चाहिए

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

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

— Kylotan
स्रोत

1

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

कैमरा :

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

कणकमीक :

वहाँ एक ParticleSystemहोगा जो सभी संस्थाओं को अद्यतन करेगा जिसमें "एमिटर" घटक था। कण उस घटक के अंदर एक सापेक्ष समन्वय अंतरिक्ष में गूंगी वस्तुएं हैं। यहाँ प्रतिपादन की समस्या है: मुझे या तो एक ParticleRendererप्रणाली बनाने की आवश्यकता होगी , या मौजूदा एक की कार्यक्षमता का विस्तार करना होगा।

इनपुट सिस्टम :

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

— jcora
स्रोत

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

@ melak47, यह सच है, मैंने इसके बारे में भी सोचा था, लेकिन मैं इसे लागू करना चाहता था जिस तरह से Aremis करता है। लेकिन यह "सिस्टम प्रासंगिक संस्थाओं के संदर्भों को संग्रहीत करता है" अधिक से अधिक त्रुटिपूर्ण प्रतीत होता है ...

— jcora

क्या Artemis प्रत्येक घटक प्रकार को अपनी सूची में संग्रहीत नहीं करता है? तो क्या आपके पास वास्तव में ड्रा करने योग्य घटकों, कैमरा घटकों, रोशनी की सूची नहीं है और क्या नहीं है?