क्या मौजूदा FOSS घटक-आधारित रूपरेखाएँ हैं? [बन्द है]


25

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

विशेष रूप से मेरा मतलब है कि ऐसी परियोजनाएं हैं जिनमें एक आधार Entityवर्ग, एक आधार Componentवर्ग और शायद कुछ मानक घटक शामिल हैं? यदि आप पहिया को फिर से संगठित नहीं करना चाहते हैं, तो यह एक गेम शुरू करना बहुत आसान होगा, या हो सकता है कि आप GraphicsComponentडायरेक्ट 3 डी के साथ स्प्राइट करते हैं, लेकिन आप यह पहले से ही एक दर्जन बार कर चुके हैं।

एक त्वरित Googling जाता Rusher । क्या किसी ने इसके बारे में सुना है / क्या कोई इसका उपयोग करता है? अगर कोई लोकप्रिय नहीं हैं, तो क्यों नहीं? क्या इस पुन: प्रयोज्य जैसा कुछ बनाना बहुत मुश्किल है, और उन्हें भारी अनुकूलन की आवश्यकता है? अपने स्वयं के कार्यान्वयन में मुझे बहुत सारे बॉयलरप्लेट मिले जो एक रूपरेखा में पिरोए जा सकते थे।


4
आपको पहला लिखना चाहिए! :)
Ricket

1
खैर, मैंने अपने प्रोजेक्ट के लिए C # में एक लिखा। शायद हम सब योगदान दे सकते हैं?
Tesserex

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

हो सकता है क्योंकि घटक आधारित डिजाइन परियोजना प्रबंधकों को प्रोग्रामर की तुलना में अधिक आकर्षित करता है
एम। यूटुक एटलिनिया

जवाबों:


45

अगर कोई लोकप्रिय नहीं हैं, तो क्यों नहीं?

क्योंकि इस तरह के ढांचे का संचालन कैसे होगा, इस पर आम सहमति जैसा कुछ नहीं है।

Gamedev.net पर एक थ्रेड पर मैंने यह निर्धारित किया कि जब लोग घटक-आधारित गेम सिस्टम के बारे में बात करते हैं, तो वास्तव में कम से कम 8 संभावित क्रमांकन होते हैं कि वे कैसे काम करने की उम्मीद करते हैं, 3 अलग-अलग कारकों के आधार पर:

इनबोर्ड बनाम आउटबोर्ड - घटकों को एक इकाई में एकत्रित किया जाना चाहिए, या उन्हें एक सबसिस्टम का हिस्सा होना चाहिए और केवल एक इकाई आईडी से जुड़ा होना चाहिए?

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

घटक पर डेटा बनाम इकाई पर डेटा - क्या डेटा को उस घटक द्वारा आयोजित किया जाना चाहिए जो मुख्य रूप से उस पर संचालित होता है? या सभी घटकों द्वारा सुलभ एक साझा स्थान में इकाई पर डेटा संग्रहीत किया जाना चाहिए?

इससे परे कि घटक कैसे साझा करें (साझा डेटा के माध्यम से संवाद करना चाहिए? इस पर आगे सवाल हैं? वाया फ़ंक्शन पॉइंटर्स? वाया सिग्नल / स्लॉट? या बिल्कुल नहीं?), उन्हें कैसे अपडेट करना चाहिए (घटक प्रकार के आधार पर एक निश्चित क्रम में? प्रति) -निर्माण के समय में परिभाषित-ऑर्डर ऑर्डर; घटक अंतरनिर्भरता के सामयिक प्रकार के आधार पर?), आदि।

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

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


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

1
@ एडम: मैं उस दृष्टिकोण के बारे में विवरण पर एक लिंक चाहूंगा जिसने डार्विन विकास मैच जीता। जब मैं विवरण कहता हूं, तो मैं इनबोर्ड और आउटबोर्ड के बारे में नहीं सुनना चाहता, मैं हैश मैप्स, वैक्टर, एलोकेटर्स, प्राइवेट, पब्लिक, लूप्स, कॉन्स्ट ... लो लेवल डिटेल्स के बारे में सुनना चाहता हूं।
v.oddou

@ v.oddou किसी ने पहले से ही उत्तर के रूप में विकी के लिए एक लिंक पोस्ट किया (नीचे देखें)। आप विवरण चाहते हैं? यह सोर्स कोड से भरा है ।
एडम

10

एक विकी है जो इन सभी के उदाहरणों को एकत्रित कर रहा है:

http://entity-systems.wikidot.com/

... विभिन्न दृष्टिकोणों के बीच अंतर के स्पष्टीकरण के साथ।


ऐश और आर्टेमिस (विकी पर दोनों) वास्तव में लोकप्रिय साबित हुए हैं, ये दोनों व्यावसायिक खेल के विकास के लिए उपयोग करते हैं, साथ ही शौक से काम करते हैं।
एडम

4

इन रूपरेखाओं की जाँच करें जो मुझे इस वास्तुकला से संबंधित मिलीं ...

www.burgerengine.com

PushButtonEngine

आर्टेमिस फ्रेमवर्क - https://github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis

एकता आपी पर एक नजर। आप घटक आधारित वास्तुकला के बारे में बहुत सारी सामग्री पा सकते हैं। (जैसे ही मुझे सोमेमोर मिलेगा सूची को अपडेट कर देंगे ...)

अद्यतन करें:

      https://code.google.com/p/spartanframework/

यह इकाई प्रणालियों के बारे में अच्छे तरीके से बताता है ... http://piemaster.net/2011/07/entity-component-primer/


2

फ्लैश के लिए पुश बटन इंजन है: http://pushbuttonengine.com/

और c ++ / python के लिए Panda3D है: panda3d डॉट कॉम (क्षमा करें, मुझे केवल n00b के रूप में प्रति पोस्ट 1 url की अनुमति है)

मुझे यकीन है कि वहाँ टन अधिक हैं :)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.