इंजन भागों के बीच बातचीत को कैसे लागू किया जाए?


10

मैं एक सवाल पूछना चाहता हूं कि गेम इंजन भागों के बीच सूचना का आदान-प्रदान कैसे किया जाना चाहिए।

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

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

मैंने कुछ इवेंट सिस्टम का उपयोग करने के बारे में सोचा, लेकिन मुझे यह जानने के लिए पर्याप्त अनुभव नहीं है कि क्या यह सही समाधान होगा।

क्या ईवेंट सिस्टम एकमात्र उपयुक्त दृष्टिकोण है, या मुझे कुछ और उपयोग करना चाहिए?

मैं ग्राफिक्स इंजन के रूप में Ogre का उपयोग कर रहा हूं, अगर यह मायने रखता है।


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

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

जवाबों:


20

मेरा पसंदीदा खेल इंजन संरचना लगभग सभी भागों के बीच संचार के लिए संदेश का उपयोग करके इंटरफ़ेस और ऑब्जेक्ट <-> घटक मॉडल है।

आपके मुख्य प्रबंधक भागों जैसे आपके दृश्य प्रबंधक, संसाधन लोडर, ऑडियो, रेंडरर, भौतिकी, आदि के लिए कई इंटरफेस हैं।

मेरे पास 3D दृश्य / दुनिया में सभी वस्तुओं के प्रभारी प्रबंधक हैं।

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

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

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

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

यहाँ दृश्य प्रबंधक, ऑब्जेक्ट और घटक और संदेश प्रवाह का एक बहुत ही सरल लेआउट है, जिसे मैंने C ++ में लिखा है, लगभग एक घंटे में मार पड़ी है। जब इसे चलाया जाता है तो यह ऑब्जेक्ट पर स्थिति सेट करता है, और संदेश रेंडर घटक से गुजरता है, फिर ऑब्जेक्ट से स्थिति को पुनः प्राप्त करता है। का आनंद लें!

साथ ही, मैंने किसी भी व्यक्ति के लिए नीचे दिए गए कोड का C # संस्करण और स्काला संस्करण लिखा है जो C ++ के बजाय उन में धाराप्रवाह हो सकता है।

#include <iostream>
#include <stdio.h>

#include <list>
#include <map>

using namespace std;

struct Vector3
{
public:
    Vector3() : x(0.0f), y(0.0f), z(0.0f)
    {}

    float x, y, z;
};

enum eMessageType
{
    SetPosition,
    GetPosition,    
};

class BaseMessage
{
protected: // Abstract class, constructor is protected
    BaseMessage(int destinationObjectID, eMessageType messageTypeID) 
        : m_destObjectID(destinationObjectID)
        , m_messageTypeID(messageTypeID)
    {}

public: // Normally this isn't public, just doing it to keep code small
    int m_destObjectID;
    eMessageType m_messageTypeID;
};

class PositionMessage : public BaseMessage
{
protected: // Abstract class, constructor is protected
    PositionMessage(int destinationObjectID, eMessageType messageTypeID, 
                    float X = 0.0f, float Y = 0.0f, float Z = 0.0f)
        : BaseMessage(destinationObjectID, messageTypeID)
        , x(X)
        , y(Y)
        , z(Z)
    {

    }

public:
    float x, y, z;
};

class MsgSetPosition : public PositionMessage
{
public:
    MsgSetPosition(int destinationObjectID, float X, float Y, float Z)
        : PositionMessage(destinationObjectID, SetPosition, X, Y, Z)
    {}
};

class MsgGetPosition : public PositionMessage
{
public:
    MsgGetPosition(int destinationObjectID)
        : PositionMessage(destinationObjectID, GetPosition)
    {}
};

class BaseComponent
{
public:
    virtual bool SendMessage(BaseMessage* msg) { return false; }
};

class RenderComponent : public BaseComponent
{
public:
    /*override*/ bool SendMessage(BaseMessage* msg)
    {
        // Object has a switch for any messages it cares about
        switch(msg->m_messageTypeID)
        {
        case SetPosition:
            {                   
                // Update render mesh position/translation

                cout << "RenderComponent handling SetPosition\n";
            }
            break;
        default:
            return BaseComponent::SendMessage(msg);
        }

        return true;
    }
};

class Object
{
public:
    Object(int uniqueID)
        : m_UniqueID(uniqueID)
    {
    }

    int GetObjectID() const { return m_UniqueID; }

    void AddComponent(BaseComponent* comp)
    {
        m_Components.push_back(comp);
    }

    bool SendMessage(BaseMessage* msg)
    {
        bool messageHandled = false;

        // Object has a switch for any messages it cares about
        switch(msg->m_messageTypeID)
        {
        case SetPosition:
            {               
                MsgSetPosition* msgSetPos = static_cast<MsgSetPosition*>(msg);
                m_Position.x = msgSetPos->x;
                m_Position.y = msgSetPos->y;
                m_Position.z = msgSetPos->z;

                messageHandled = true;
                cout << "Object handled SetPosition\n";
            }
            break;
        case GetPosition:
            {
                MsgGetPosition* msgSetPos = static_cast<MsgGetPosition*>(msg);
                msgSetPos->x = m_Position.x;
                msgSetPos->y = m_Position.y;
                msgSetPos->z = m_Position.z;

                messageHandled = true;
                cout << "Object handling GetPosition\n";
            }
            break;
        default:
            return PassMessageToComponents(msg);
        }

        // If the object didn't handle the message but the component
        // did, we return true to signify it was handled by something.
        messageHandled |= PassMessageToComponents(msg);

        return messageHandled;
    }

private: // Methods
    bool PassMessageToComponents(BaseMessage* msg)
    {
        bool messageHandled = false;

        auto compIt = m_Components.begin();
        for ( compIt; compIt != m_Components.end(); ++compIt )
        {
            messageHandled |= (*compIt)->SendMessage(msg);
        }

        return messageHandled;
    }

private: // Members
    int m_UniqueID;
    std::list<BaseComponent*> m_Components;
    Vector3 m_Position;
};

class SceneManager
{
public: 
    // Returns true if the object or any components handled the message
    bool SendMessage(BaseMessage* msg)
    {
        // We look for the object in the scene by its ID
        std::map<int, Object*>::iterator objIt = m_Objects.find(msg->m_destObjectID);       
        if ( objIt != m_Objects.end() )
        {           
            // Object was found, so send it the message
            return objIt->second->SendMessage(msg);
        }

        // Object with the specified ID wasn't found
        return false;
    }

    Object* CreateObject()
    {
        Object* newObj = new Object(nextObjectID++);
        m_Objects[newObj->GetObjectID()] = newObj;

        return newObj;
    }

private:
    std::map<int, Object*> m_Objects;
    static int nextObjectID;
};

// Initialize our static unique objectID generator
int SceneManager::nextObjectID = 0;

int main()
{
    // Create a scene manager
    SceneManager sceneMgr;

    // Have scene manager create an object for us, which
    // automatically puts the object into the scene as well
    Object* myObj = sceneMgr.CreateObject();

    // Create a render component
    RenderComponent* renderComp = new RenderComponent();

    // Attach render component to the object we made
    myObj->AddComponent(renderComp);

    // Set 'myObj' position to (1, 2, 3)
    MsgSetPosition msgSetPos(myObj->GetObjectID(), 1.0f, 2.0f, 3.0f);
    sceneMgr.SendMessage(&msgSetPos);
    cout << "Position set to (1, 2, 3) on object with ID: " << myObj->GetObjectID() << '\n';

    cout << "Retreiving position from object with ID: " << myObj->GetObjectID() << '\n';

    // Get 'myObj' position to verify it was set properly
    MsgGetPosition msgGetPos(myObj->GetObjectID());
    sceneMgr.SendMessage(&msgGetPos);
    cout << "X: " << msgGetPos.x << '\n';
    cout << "Y: " << msgGetPos.y << '\n';
    cout << "Z: " << msgGetPos.z << '\n';
}

1
यह कोड वास्तव में अच्छा लग रहा है। मुझे एकता की याद दिलाता है।
टिली

मुझे पता है कि यह एक पुराना उत्तर है, लेकिन मेरे कुछ सवाल हैं। एक 'वास्तविक' गेम में सैकड़ों प्रकार के संदेश नहीं होंगे, जिससे कोडिंग दुःस्वप्न बन जाएगा? साथ ही, यदि आपको मुख्य चरित्र को सही ढंग से खींचने के लिए सामना करना पड़ रहा है, तो आपको क्या करना चाहिए (उदाहरण के लिए)। क्या आपको एक नया GetSpriteMessage बनाने और आपके द्वारा प्रस्तुत हर एक समय में भेजने की आवश्यकता नहीं होगी? क्या यह बहुत महंगा नहीं है? बस सोच रहा! धन्यवाद।
you786

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

2

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

मुझे ओग्रे के बारे में ज्यादा जानकारी नहीं है, इसलिए मैं आम तौर पर बोल रहा हूं।

कोर में, आपके पास मुख्य गेम लूप है। यह इनपुट सिग्नल प्राप्त करता है, एआई की गणना करता है (सरल गति से जटिल एआई और गेम लॉजिक तक), संसाधनों को लोड करता है [, आदि] और वर्तमान स्थिति का प्रतिपादन करता है। यह मूल उदाहरण है, इसलिए आप इंजन को इन भागों में अलग कर सकते हैं (InputManager, AIManager, ResourceManager, RenderManager)। और आपके पास SceneManager होना चाहिए जो खेल में मौजूद सभी वस्तुओं को रखता है।

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

ps यदि आप C ++ का उपयोग कर रहे हैं तो उपयोग करने पर विचार करें RAII पैटर्न


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