গেমের ডেটা / লজিককে উপস্থাপনা থেকে আলাদা করা

Question

আমি সি ++ এবং ওপেনজিএল ২.১ ব্যবহার করে একটি গেম লিখছি। আমি ভাবছিলাম কীভাবে আমি ডেটা / লজিককে রেন্ডারিং থেকে আলাদা করতে পারি। এই মুহুর্তে আমি একটি বেস ক্লাস 'রেন্ডারেবল' ব্যবহার করি যা অঙ্কন বাস্তবায়নের জন্য খাঁটি ভার্চুয়াল পদ্ধতি দেয়। তবে প্রতিটি বস্তুর এতই বিশেষায়িত কোড রয়েছে, কীভাবে সঠিকভাবে শেডার ইউনিফর্ম সেট করতে হবে এবং ভার্টেক্স অ্যারে বাফার ডেটা সংগঠিত করতে হবে তা কেবলমাত্র অবজেক্টই জানে। আমি আমার কোডে সমস্ত গ্লো * ফাংশন কল দিয়ে শেষ করি। বস্তু আঁকার কোনও জেনেরিক উপায় আছে?

Comments

প্রকৃতপক্ষে আপনার অবজেক্টটিতে একটি উপস্থাপনযোগ্য সংযুক্ত করার জন্য রচনাটি ব্যবহার করুন এবং আপনার অবজেক্টটি সেই m_renderableসদস্যের সাথে ইন্টারঅ্যাক্ট করুন । এইভাবে, আপনি আপনার যুক্তি আরও ভাল পৃথক করতে পারেন। পদার্থবিজ্ঞান, আইআই এবং হোয়াট নোট এমন সাধারণ বস্তুগুলিতে রেন্ডারযোগ্য "ইন্টারফেস" প্রয়োগ করবেন না .. এর পরে, আপনি আলাদাভাবে উপস্থাপনা পরিচালনা করতে পারেন। জিনিসগুলিকে আরও বেশি ডিকোপল করার জন্য আপনার ওপেনজিএল ফাংশন কলগুলির উপর বিমূর্তিটির একটি স্তর প্রয়োজন। সুতরাং, কোনও ভাল ইঞ্জিনের বিভিন্ন রেন্ডারযোগ্য বাস্তবায়নের মধ্যে কোনও জিএল এপিআই কল আসবে বলে আশা করবেন না। এটি একটি মাইক্রো সংক্ষেপে।

— teodron

@ টিওড্রন: আপনি কেন এটি উত্তর হিসাবে রাখেননি?

— তাপিও

@ টেপিও: কারণ এটি কোনও উত্তরের মতো নয়; পরিবর্তে এটি আরও পরামর্শ।

— teodron

Answer 1

একটি ধারণা ভিজিটর ডিজাইনের প্যাটার্নটি ব্যবহার করা। আপনার কোনও রেন্ডারার বাস্তবায়ন দরকার যা প্রপসগুলি কীভাবে রেন্ডার করতে জানে। প্রতিটি অবজেক্ট রেন্ডার কাজটি পরিচালনা করতে রেন্ডার্সের উদাহরণটি কল করতে পারে।

সিউডোকোডের কয়েকটি লাইনে:

class Renderer {
public:
    void render( const ObjectA & obj );
    void render( const ObjectB & obj );
};


class ObjectA{
public:
    void draw( Renderer & r ){ r.render( *this ) };
}

class ObjectB{
public:
    void draw( Renderer & r ){ r.render( *this ) };
}

গ্লো * স্টাফগুলি রেন্ডারারের পদ্ধতি দ্বারা প্রয়োগ করা হয় এবং অবজেক্টগুলি কেবল রেন্ডার করার জন্য প্রয়োজনীয় ডেটা, অবস্থান, জমিনের ধরণ, আকার ... ইত্যাদি সঞ্চয় করে।

এছাড়াও, আপনি বিভিন্ন রেন্ডারার সেট করতে পারেন (ডিবাগরেেন্ডার, এইচকিউেন্ডারার, ... ইত্যাদি) এবং অবজেক্টগুলি পরিবর্তন না করে এগুলি গতিশীলভাবে ব্যবহার করতে পারেন।

এটি সহজেই সত্তা / উপাদান উপাদানগুলির সাথে একত্রিত হতে পারে।

Comments

এটি বরং একটি ভাল উত্তর! আপনি Entity/Componentবিকল্পটিকে আরও কিছুটা জোর দিতে পারতেন কারণ এটি অন্যান্য ইঞ্জিনের অংশগুলি (এআই, পদার্থবিজ্ঞান, নেটওয়ার্কিং বা সাধারণ গেমপ্লে) থেকে জ্যামিতি সরবরাহকারীদের পৃথক করতে সহায়তা করতে পারে can +1 টি!

— teodron

@ টিওড্রন, আমি ই / সি বিকল্প ব্যাখ্যা করব না কারণ এটি জিনিসগুলির প্রশংসা করবে। তবে, আমি মনে করি যে আপনার পরিবর্তন করা উচিত ObjectAএবং ObjectBপ্রতি DrawableComponentAএবং DrawableComponentBএবং রেন্ডার পদ্ধতিগুলির অভ্যন্তরে, আপনার প্রয়োজন হলে অন্যান্য উপাদানগুলি ব্যবহার করুন, যেমন: position = component->getComponent("Position");এবং প্রধান লুপে, আপনার সাথে ড্র কল করার জন্য আঁকতে সক্ষম উপাদানগুলির একটি তালিকা রয়েছে।

— ঝেন

কেন কেবল একটি ইন্টারফেস নেই (যেমন Renderable) যার একটি draw(Renderer&)ফাংশন রয়েছে এবং সমস্ত বস্তু যা তাদের প্রয়োগ করা যেতে পারে? কোন ক্ষেত্রে Rendererকেবল একটি ফাংশন প্রয়োজন যা সাধারণ ইন্টারফেস এবং কল প্রয়োগ করে এমন কোনও বস্তু গ্রহণ করে renderable.draw(*this);?

— ভ্যাল্ট ফ্যালকন

@ ভাইটফ্যালকন, দুঃখিত যদি আমি আমাকে পরিষ্কার না করি তবে বিস্তারিত ব্যাখ্যা করার জন্য আমার আরও স্থান এবং কোডের প্রয়োজন। মূলত, আমার সমাধানগুলি gl_*ফাংশনগুলি উপস্থাপককে স্থানান্তরিত করে (যুক্তিটিকে রেন্ডারিং থেকে পৃথক করে) তবে আপনার সমাধানটি gl_*কলগুলিকে বস্তুর মধ্যে সরিয়ে দেয় ।

— ঝেন

এইভাবে গ্লো * ফাংশনগুলি বস্তু কোডের বাইরে চলে গেছে তবে আমি এখনও হ্যান্ডেল ভেরিয়েবলগুলি রেন্ডারিংয়ে ব্যবহার করি যেমন বাফার / টেক্সচার আইডি, ইউনিফর্ম / বৈশিষ্ট্যগুলির অবস্থানগুলি।

— 8:48

Answer 2

আমি জানি আপনি ইতিমধ্যে ঝেনের উত্তরটি গ্রহণ করেছেন তবে আমি অন্য কাউকে সাহায্য করতে পারার ক্ষেত্রে সেখানে অন্য একটি রেখে দিতে চাই।

সমস্যার পুনরাবৃত্তি করতে, ওপি রেন্ডারিং কোডটিকে যুক্তি এবং ডেটা থেকে আলাদা রাখার ক্ষমতা চায়।

আমার সমাধানটি হ'ল উপাদানটি রেন্ডার করার জন্য একটি আলাদা ক্লাসকে একসাথে ব্যবহার করা, যা Rendererলজিক ক্লাস থেকে পৃথক । প্রথমে একটি Renderableইন্টারফেস থাকতে হবে যার একটি ফাংশন রয়েছে bool render(Renderer& renderer);এবং Rendererশ্রেণীর সমস্ত Renderableতালিকা পুনরুদ্ধার করতে দর্শনার্থীর প্যাটার্নটি ব্যবহার করে , তালিকা সরবরাহ GameObjectকরে এবং সেই বস্তুগুলির Renderableউদাহরণ দেয় যা রেন্ডার করে । এইভাবে, রেন্ডারারের সেখানে প্রতিটি প্রতিটি বস্তুর ধরণ সম্পর্কে জানতে হবে না এবং এটি এখনও ফাংশনটির Renderableমাধ্যমে প্রতিটি অবজেক্ট-টাইপকে অবহিত করার getRenderable()দায়িত্ব। অথবা বিকল্পভাবে, আপনি এমন একটি RenderableVisitorশ্রেণি তৈরি করতে পারেন যা সমস্ত গেমওবজেক্টগুলিতে পরিদর্শন করে এবং পৃথক GameObjectঅবস্থার উপর ভিত্তি করে তারা দর্শকদের কাছে তার প্রেরণীয় যোগ / যোগ না করার জন্য বেছে নিতে পারে। যেভাবেই হোক, মূল বক্তব্যটি হ'লgl_*কলগুলি সমস্ত বস্তুর বাইরেই থাকে এবং এমন একটি শ্রেণিতে থাকে যা অংশটির পরিবর্তে অবজেক্টের অন্তরঙ্গ বিবরণ জানে Renderer।

অস্বীকৃতি : আমি এই ক্লাসগুলিকে সম্পাদকটিতে হাত দিয়ে লিখেছি যাতে কোডের মধ্যে কিছু মিস হয়ে যাওয়ার ভাল সুযোগ রয়েছে তবে আশা করি, আপনি ধারণাটি পেয়ে যাবেন।

একটি (আংশিক) উদাহরণ প্রদর্শন করতে:

Renderable ইন্টারফেস

class Renderable {
public:
    Renderable(){}
    virtual ~Renderable(){}
    virtual void render(Renderer& renderer) const = 0;
};

GameObject শ্রেণী:

class GameObject {
public:
    GameObject()
        : mVisible(true)
        , mMarkedForDelete(false) {}

    virtual ~GameObject(){}

    virtual Renderable* getRenderable() {
        // By default, all GameObjects are missing their Renderable
        return NULL;
    }

    void setVisible(bool visible) {
        mVisible = visible;
    }

    bool isVisible() const {
        return getRenderable() != null && !isMarkedForDeletion() && mVisible;
    }

    void markForDeletion() {
        mMarkedForDelete = true;
    }

    bool isMarkedForDeletion() const {
        return mMarkedForDelete;
    }

    // More GameObject functions

private:
    bool mVisible;
    bool mMarkedForDelete;
};

(আংশিক) Rendererশ্রেণি।

class Renderer {
public:
    void renderObjects(std::vector<GameObject>& gameObjects) {
        // If you want to do something fancy with the renderable GameObjects,
        // create a visitor class to return the list of GameObjects that
        // are visible instead of rendering them straight-away
        std::list<GameObject>::iterator itr = gameObjects.begin(), end = gameObjects.end();
        while (itr != end) {
            GameObject* gameObject = *itr++;
            if (gameObject == null || !gameObject->isVisible()) {
                continue;
            }
            gameObject->getRenderable()->render(*this);
        }
    }

};

RenderableObject শ্রেণী:

template <typename T>
class RenderableObject : public Renderable {
public:
    RenderableObject(T& object)
        :mObject(object) {}
    virtual ~RenderableObject(){}

    virtual void render(Renderer& renderer) {
        return render(renderer, mObject);
    }

protected:
    virtual void render(Renderer& renderer, T& object) = 0;
};

ObjectA শ্রেণী:

// Forward delcare ObjectARenderable and make sure the constructor
// definition in the CPP file where ObjectARenderable gets included
class ObjectARenderable;

class ObjectA : public GameObject {
public:
    ObjectA()
        : mRenderable(new ObjectARenderable(*this)) {}

    // All data/logic

    Renderable* getRenderable() {
        return mRenderable.get();
    }

protected:
    // boost or std shared_ptr to make sure that the renderable instance is
    // cleaned up with the destruction of this object.
    shared_ptr<Renderable> mRenderable;
};

ObjectARenderable শ্রেণী:

#include "ObjectA.h"

class ObjectARenderable : public RenderableObject<ObjectA> {
public:
    ObjectARenderable(ObjectA& instance) {
        : RenderableObject<ObjectA>(instance) {}

protected:
    virtual void render(Renderer& renderer, T& object) {
        // gl_* class to render ObjectA
    }
};

Answer 3

একটি রেন্ডারিং-কমান্ড সিস্টেম তৈরি করুন। একটি উচ্চ-স্তরের অবজেক্ট, যার OpenGLRendererদৃশ্যপট এবং গেমোবজেক্ট উভয়ই অ্যাক্সেস রয়েছে , দৃশ্যের গ্রাফ বা গেমোবজেক্টগুলি পুনরাবৃত্তি করবে এবং একটি ব্যাচ তৈরি RenderCmdsকরবে, যার পরবর্তীতে OpenGLRendererপ্রতিটি অঙ্কিত হবে এবং তারপরে সমস্ত ওপেনগেল থাকবে সম্পর্কিত কোড।

এটি কেবল অ্যাবস্ট্রাকশন ছাড়াও আরও অনেক সুবিধা রয়েছে; অবশেষে আপনার রেন্ডারিং জটিলতা বাড়ার সাথে সাথে আপনি টেক্সচার বা শেডার দ্বারা প্রতিটি রেন্ডার কমান্ডকে বাছাই এবং গ্রুপ করতে পারেন উদাহরণস্বরূপ Render()ড্র কলগুলিতে অনেকগুলি বাধা নির্মূল করতে যা পারফরম্যান্সে একটি বিশাল পার্থক্য তৈরি করতে পারে।

class OpenGLRenderer
{
public:
    typedef GLuint GeometryBuffer;
    typedef GLuint TextureID;
    typedef std::vector<RenderCmd> RenderBatch; 

    void Render(const RenderBatch& renderBatch);   // set shaders, set active textures, draw geometry, ...

    MeshID CreateGeometryBuffer(...);
    TextureID CreateTexture(...);

    // ....
}

struct RenderCmd
{
    GeometryBuffer mGeometryBuffer;
    TextureID mTexture;
    Mat4& mWorldMatrix;
    bool mLightingEnabled;
    // .....
}

std::vector<GameObject> gYourGameObjects;
RenderBatch BuildRenderBatch()
{
    RenderBatch ret;

    for (GameObject& object : gYourGameObjects)
    { 
        // ....
    }

    return ret;
}

Answer 4

এটি সমস্ত রেন্ডারযোগ্য সত্তাগুলির জন্য সাধারণ কী কী তা নিয়ে আপনি অনুমানগুলি তৈরি করতে পারেন কিনা তা সম্পূর্ণভাবে নির্ভর করে। আমার ইঞ্জিনে, সমস্ত বস্তু একইভাবে উপস্থাপিত হয়, সুতরাং কেবলমাত্র vbos, টেক্সচার এবং রূপান্তর সরবরাহ করা প্রয়োজন। তারপরে রেন্ডারার তাদের সকলকে নিয়ে আসে, সুতরাং বিভিন্ন অবজেক্টে কোনও ওপেনজিএল ফাংশন কলের প্রয়োজন হয় না।

Comments

আবহাওয়া = বৃষ্টি, রৌদ্র, গরম, ঠান্ডা: P ->

— ওয়েস্টার

@ তোবিয়াস কিইনজলার আপনি যদি তার বানানটি সংশোধন করতে চলেছেন তবে সঠিকভাবে বানান চেষ্টা করুন :-)

— টাসাজেন্ট

@ টাসেজেন্ট কী এবং মফ্রির আইনকে ভেঙেছে ?

— মি-

— টাইপোটি

Answer 5

অবশ্যই বিভিন্ন ক্লাসে রেন্ডারিং কোড এবং গেম লজিক রাখুন। রচনা (যেমন টিওড্রন প্রস্তাবিত) সম্ভবত এটি করার সর্বোত্তম উপায়; গেম জগতের প্রতিটি সত্তার নিজস্ব রেন্ডারেবল - বা সম্ভবত সেগুলির একটি সেট থাকবে।

আপনার কাছে এখনও রেন্ডারেবলের একাধিক সাবক্লাস থাকতে পারে, উদাহরণস্বরূপ কঙ্কাল অ্যানিমেশন, কণা নির্গমনকারী এবং জটিল শেডারগুলি পরিচালনা করার জন্য আপনার বেসিক টেক্সচারযুক্ত এবং লিটার শেডার ছাড়াও। রেন্ডারেবল ক্লাস এবং এর সাবক্লাসগুলিতে কেবল রেন্ডারিংয়ের জন্য প্রয়োজনীয় তথ্য থাকতে হবে: জ্যামিতি, টেক্সচার এবং শেডার।

আরও, আপনি জাল থেকে নিজের দেওয়া জালের একটি উদাহরণ পৃথক করা উচিত। বলুন যে আপনি পর্দায় একশত গাছ পেয়েছেন, প্রতিটি একই জাল ব্যবহার করছে। আপনি কেবল জ্যামিতি একবারে সঞ্চয় করতে চান তবে প্রতিটি গাছের জন্য আপনার পৃথক অবস্থান এবং ঘূর্ণন ম্যাট্রিক প্রয়োজন। অ্যানিমেটেড হিউম্যানয়েডের মতো আরও জটিল অবজেক্টগুলিতে অতিরিক্ত রাষ্ট্রীয় তথ্য (যেমন একটি কঙ্কাল, বর্তমানে প্রয়োগকৃত অ্যানিমেশনের সেট ইত্যাদি) থাকবে।

রেন্ডার করার জন্য, নিষ্পাপ পদ্ধতিটি প্রতিটি গেম সত্তার উপর পুনরাবৃত্তি হয় এবং এটি নিজেকে রেন্ডার করতে বলে। পর্যায়ক্রমে, প্রতিটি সত্তা (যখন এটি প্রসারিত হয়) তার উপস্থাপনযোগ্য বস্তু (গুলি) একটি দৃশ্যের বস্তুর মধ্যে সন্নিবেশ করতে পারে। তারপরে, আপনার রেন্ডার ফাংশনটি দৃশ্যকে রেন্ডার করতে বলে। এটি সেই দৃশ্যটি কোনও কোড গেম সত্তা বা নির্দিষ্ট রেন্ডারেবল সাবক্লাসে এম্বেড না করেই জটিল রেন্ডার-সম্পর্কিত জিনিসগুলি করতে সক্ষম করে।

Answer 6

এই পরামর্শটি রেন্ডারিংয়ের জন্য সত্যই সুনির্দিষ্ট নয় তবে এমন একটি সিস্টেম নিয়ে আসা উচিত যা জিনিসগুলি অনেকাংশে পৃথক করে রাখে। প্রথমে চেষ্টা করুন এবং 'গেমওজেক্ট' ডেটা অবস্থানের তথ্য থেকে আলাদা রাখুন।

এটি লক্ষণীয় যে সাধারণ XYZ অবস্থানিক তথ্য এত সহজ নাও হতে পারে। আপনি যদি পদার্থবিজ্ঞানের ইঞ্জিন ব্যবহার করছেন তবে আপনার অবস্থানের তথ্য 3 য় পক্ষের ইঞ্জিনের মধ্যে সংরক্ষণ করা যেতে পারে। আপনাকে হয় তাদের মধ্যে সিঙ্ক্রোনাইজ করতে হবে (এতে প্রচুর অর্থহীন মেমরি অনুলিপি করা হতে পারে) বা ইঞ্জিন থেকে সরাসরি তথ্যটি জিজ্ঞাসা করতে হবে। তবে সমস্ত বস্তুর পদার্থবিজ্ঞানের প্রয়োজন হয় না, কিছু স্থানে স্থির করা হবে তাই ভাসমানগুলির একটি সহজ সেট সেখানে সূক্ষ্মভাবে কাজ করে। কিছু এমনকি অন্য বস্তুর সাথে সংযুক্ত থাকতে পারে, তাই তাদের অবস্থানটি আসলে অন্য একটি অবস্থানের অফসেট। একটি উন্নত সেটআপে আপনার অবস্থানটি কেবলমাত্র জিপিইউতে সঞ্চিত থাকতে পারে কেবলমাত্র কম্পিউটার সাইডের প্রয়োজন হবে স্ক্রিপ্টিং, স্টোরেজ এবং নেটওয়ার্কের প্রতিরূপের জন্য। সুতরাং আপনার অবস্থানগত ডেটার জন্য আপনার বেশ কয়েকটি সম্ভাব্য পছন্দ থাকতে পারে। এখানে উত্তরাধিকার ব্যবহার করা বোধগম্য।

তার অবস্থানের মালিকানাধীন কোনও বস্তুর পরিবর্তে object বস্তুটি নিজেই একটি সূচকযুক্ত ডেটা কাঠামোর মালিকানাধীন উচিত। উদাহরণস্বরূপ, কোনও 'স্তর' এর একটি অক্ট্রি থাকতে পারে, বা কোনও পদার্থবিজ্ঞানের ইঞ্জিনের 'দৃশ্য' থাকতে পারে। আপনি যখন রেন্ডার করতে চান (বা কোনও রেন্ডারিং দৃশ্য সেটআপ করতে পারেন), আপনি ক্যামেরাতে দৃশ্যমান অবজেক্টগুলির জন্য আপনার বিশেষ কাঠামোটি জিজ্ঞাসা করুন।

এটি ভাল মেমরি পরিচালনা দিতে সহায়তা করে। এইভাবে এমন কোনও বস্তু যা আসলে কোনও অঞ্চলে নেই এমনকি এমন একটি অবস্থানও রাখে না যা কোনও অঞ্চলে সর্বশেষ ছিল যখন এটি ছিল 0.0 কোর্ড বা কর্ডগুলি ফিরে আসার চেয়ে বোঝায়।

যদি আপনি আর অবজেক্টে স্থানাঙ্ক না রাখেন, অবজেক্ট.জেটএক্সএক্স () এর পরিবর্তে আপনার স্তরের.জেএক্সএক্স (অবজেক্ট) থাকবে। স্তরটিতে অবজেক্টটির সন্ধান করা সমস্যাটি সম্ভবত একটি ধীর গতি সম্পন্ন হবে কারণ এটি এর সমস্ত বস্তুগুলির মধ্যে নজর রাখতে হবে এবং আপনার অনুসন্ধানের সাথে মিলে যেতে হবে।

এড়াতে আমি সম্ভবত একটি বিশেষ 'লিঙ্ক' ক্লাস তৈরি করব। একটি যা একটি স্তর এবং একটি অবজেক্টের মধ্যে আবদ্ধ হয়। আমি এটিকে একটি "অবস্থান" বলি। এটিতে xyz স্থানাঙ্কের পাশাপাশি স্তরে হাতল এবং বস্তুর একটি হ্যান্ডেল থাকবে। এই লিঙ্ক শ্রেণিটি স্পেসিয়াল কাঠামো / স্তরে সংরক্ষণ করা হবে এবং বস্তুর সাথে এর দুর্বল উল্লেখ থাকবে (যদি স্তর / অবস্থানটি ধ্বংস হয়ে যায় তবে অবজেক্টের রেফারেন্সটি বাতিল করতে হবে। এটি সম্ভবত অবস্থান শ্রেণিটি মূল্যবান হতে পারে) অবজেক্টটির 'নিজস্ব', যদি কোনও স্তর মুছে ফেলা হয়, তেমনি বিশেষ সূচক কাঠামো, এতে থাকা অবস্থানগুলি এবং এর অবজেক্টগুলিও।

typedef std::tuple<Level, Object, PositionXYZ> Location;

এখন অবস্থানের তথ্য কেবলমাত্র এক জায়গায় সংরক্ষণ করা হয়েছে। অবজেক্ট, স্পেসিয়াল ইনডেক্সিং স্ট্রাকচার, রেন্ডারার ইত্যাদির মধ্যে নকল নয়।

অক্ট্রিগুলির মতো স্পেসিয়াল ডেটা স্ট্রাকচারগুলিতে প্রায়শই তারা যে জিনিসগুলি সঞ্চয় করে থাকে তার স্থানাঙ্কের প্রয়োজন হয় না। কাঠামোতে নোডগুলির আপেক্ষিক অবস্থানের মধ্যে অবস্থানটি সংরক্ষণ করা হয় (এটি এক ধরণের ক্ষতিকারক সংকোচনের মতো ভাবা যেতে পারে, দ্রুত অনুসন্ধানের সময়গুলির জন্য নির্ভুলতা ত্যাগ করা)। অক্টোবরে লোকেশন অবজেক্টের সাথে তারপরে কোয়েরি শেষ হয়ে গেলে এর ভিতরে প্রকৃত স্থানাঙ্কগুলি পাওয়া যায়।

অথবা আপনি যদি নিজের পদার্থের অবস্থানগুলি বা দুজনের মধ্যে একটি মিশ্রণ পরিচালনা করতে পদার্থবিজ্ঞানের ইঞ্জিন ব্যবহার করছেন তবে আপনার সমস্ত কোডকে এক জায়গায় রাখার সময় লোকেশন ক্লাসটি সেই স্বচ্ছভাবে পরিচালনা করতে হবে।

আরেকটি সুবিধা হ'ল অবস্থান এবং রেফারেন্স একই স্তরে সংরক্ষণ করা হয়। আপনি অবজেক্টটি কার্যকর করতে পারবেন e টেলপোর্টটো (অন্যান্য_বজেক্ট) এবং এটি স্তর স্তরে কাজ করতে পারেন। একইভাবে এআই-এর পাথ-সন্ধান কোনও আলাদা অঞ্চলে কিছু অনুসরণ করতে পারে।

রেন্ডারিং এর সাথে শ্রদ্ধা সহ। আপনার রেন্ডারে লোকেশনটির সাথে একই রকম বাঁধাই থাকতে পারে। এটির মধ্যে রেন্ডারিং নির্দিষ্ট জিনিসগুলি বাদে। আপনার সম্ভবত সম্ভবত এই কাঠামোটিতে 'অবজেক্ট' বা 'স্তর' সংরক্ষণ করার প্রয়োজন নেই। আপনি যদি রঙ বাছাইয়ের মতো কিছু করার চেষ্টা করছেন বা তার উপরে ভাসমান একটি হিটবার উপস্থাপন করছেন তবে অন্যথায় রেন্ডারার কেবল জাল এবং এ জাতীয় বিষয়ে যত্নশীল হন তবে অবজেক্টটি কার্যকর হতে পারে। রেন্ডারেবল স্টাফ একটি জাল হবে, এছাড়াও বাউন্ডিং বাক্স ইত্যাদি থাকতে পারে।

typedef std::pair<RenderableStuff, PositionXYZ> RenderThing;

renderer.render(level, camera);
renderer: object = level.getVisibleObjects(camera);
level: physics.getObjectsInArea(physics.getCameraFrustrum(camera));
for(object in objects) {
    //This could be depth sorted, meshes could be broken up and sorted by material for batch rendering or whatever
    rendering_que.addObjectToRender(object);
}

আপনার প্রতিটি ফ্রেমে এটি করার দরকার নেই, আপনি নিশ্চিত করতে পারেন যে আপনি বর্তমানে ক্যামেরা দেখানোর চেয়ে একটি বড় অঞ্চল নিয়েছেন। এটি ক্যাশে করুন, কোনও বাউন্ডিং বাক্সটি সীমার মধ্যে চলে আসে কিনা তা দেখতে ট্র্যাক অবজেক্টের গতিপথ, ক্যামেরার গতিবিধি ট্র্যাক করে ইত্যাদি on তবে আপনি এটিকে বেঞ্চমার্ক না করা পর্যন্ত এই ধরণের স্টাফ দিয়ে গণ্ডগোল শুরু করবেন না।

আপনার পদার্থবিজ্ঞানের ইঞ্জিনে নিজেও একই রকম বিমূর্ততা থাকতে পারে, কারণ এতেও অবজেক্ট ডেটার দরকার নেই, কেবল সংঘর্ষের জাল এবং পদার্থবিজ্ঞানের বৈশিষ্ট্য।

আপনার সমস্ত মূল অবজেক্টের ডেটা এতে থাকা জালটির নাম হবে। গেম ইঞ্জিনটি এরপরে এগিয়ে যেতে পারে এবং নির্দিষ্ট বস্তুর রেন্ডার (যা আপনার রেন্ডারিং এপিআই, অর্থাৎ ডাইরেক্টএক্স বনাম ওপেনগ্লের সাথে সুনির্দিষ্ট হতে পারে) এর সাথে আপনার বস্তু শ্রেণীর উপর চাপ না দিয়ে পছন্দসই বিন্যাসে এটি লোড করতে পারে।

এটি বিভিন্ন উপাদান পৃথক রাখে। এটি আপনার পদার্থবিজ্ঞানের ইঞ্জিন প্রতিস্থাপনের মতো কাজগুলি করা সহজ করে তোলে কারণ যে জিনিসগুলি বেশিরভাগ ক্ষেত্রে এক জায়গায় থাকে। এটি ইউনিটেস্টিংকে আরও সহজ করে তোলে। আপনার প্রয়োজনীয় সমস্ত লোকেশন ক্লাস হওয়ায় আপনি কোনও আসল নকল বস্তু সেটআপ না করে পদার্থবিজ্ঞানের অনুসন্ধানগুলির মতো বিষয়গুলি পরীক্ষা করতে পারেন। আপনি জিনিস সহজেই অনুকূলিত করতে পারেন। এটি আরও সুস্পষ্ট করে তোলে যে আপনার কোন্ ক্লাসগুলি এবং একক অবস্থানগুলিতে অনুকূলকরণের জন্য আপনার কী কোয়েরিগুলি করা উচিত (উদাহরণস্বরূপ উপরের স্তর level বিটভিজিবলঅবজেক্টটি যেখানে ক্যামেরাটি খুব বেশি না সরে আপনি জিনিসগুলি ক্যাশে করতে পারবেন)।