বাহ্যিক উপাদান পরিচালকদের সাথে একটি সত্তা সিস্টেম সংগঠিত?


13

আমি একটি শীর্ষ-ডাউন মাল্টিপ্লেয়ার 2 ডি শ্যুটার গেমের জন্য একটি গেম ইঞ্জিন ডিজাইন করছি, যা আমি অন্যান্য শীর্ষ-ডাউন শ্যুটার গেমগুলির জন্য যুক্তিসঙ্গতভাবে পুনরায় ব্যবহারযোগ্য হতে চাই। এই মুহূর্তে আমি এটি সম্পর্কে সত্তা সিস্টেমের মতো কিছু কীভাবে ডিজাইন করা উচিত তা নিয়ে ভাবছি। প্রথমে আমি এই সম্পর্কে ভেবেছিলাম:

আমার অ্যান্টিটি ম্যানেজার নামে একটি ক্লাস আছে। এটি আপডেট নামে একটি পদ্ধতি এবং ড্র নামে অন্য একটি প্রয়োগ করতে হবে। আমার লজিক এবং রেন্ডারিংকে আলাদা করার কারণ হ'ল স্ট্যান্ডেলোন সার্ভার চালিয়ে যদি আমি আঁকির পদ্ধতি বাদ দিতে পারি।

অ্যান্টিটি ম্যানেজার বেস-এন্টিটি টাইপের বস্তুর তালিকার মালিক। প্রতিটি সত্তা যেমন সত্ত্বার মডেল (কোনও সত্তার অঙ্কনযোগ্য উপস্থাপনা), এনটিটি নেটওয়ার্কইন্টারফেস এবং এন্টিফিজিকালবডি হিসাবে উপাদানগুলির একটি তালিকা মালিকানার রয়েছে।

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

সত্তা তৈরির কাজটি এইভাবে করা হয়: সত্ত্বা ম্যানেজারটি RegisterEntity (এনটিসি ক্লাস, কারখানা) পদ্ধতি প্রয়োগ করে যা কীভাবে সেই শ্রেণীর সত্তা তৈরি করতে হয় তা নিবন্ধভুক্ত করে । এটি ক্রিয়েটেনটিটি (সত্তাশ্রেণী) পদ্ধতিটি প্রয়োগ করে যা বেসএন্টিটি টাইপের কোনও বস্তু ফেরত দেয়।

এখন আমার সমস্যা আসে: কীভাবে কোনও উপাদানটির রেফারেন্স উপাদান সংস্থাগুলিতে নিবন্ধিত হবে? কোনও কারখানা / সমাপনী থেকে আমি কীভাবে উপাদান পরিচালকদের রেফারেন্স করব তা আমার কোনও ধারণা নেই।


আমি জানি না সম্ভবত এটি হাইব্রিড সিস্টেম হিসাবে বোঝানো হয়েছে কিনা, তবে আপনার "পরিচালকদের" মতোই আমি সাধারণত "সিস্টেম" বলে অভিহিত শুনেছি; অর্থাত্ সত্ত্বা একটি বিমূর্ত-আইডি; একটি উপাদান ডেটা একটি পুল; এবং আপনি কীভাবে "ম্যানেজার" শব্দটিকে সাধারণভাবে "সিস্টেম" বলে অভিহিত করেন। আমি কি শব্দভান্ডারটি সঠিকভাবে ব্যাখ্যা করছি?
বিআরপোকক

আমার প্রশ্নটি এখানে আগ্রহের বিষয় হতে পারে: গেমের উপাদান, গেম ম্যানেজার এবং অবজেক্ট প্রোপার্টি
জর্জি ডাকেট

Gamadu.com/artemis একবার দেখুন এবং দেখুন যে তাদের পদ্ধতিগুলি আপনার প্রশ্নের জবাব দেয় কিনা।
প্যাট্রিক হিউজেস

1
কোনও সত্তা সিস্টেম ডিজাইনের কোনও উপায় নেই কারণ এর সংজ্ঞা সম্পর্কে খুব কম sensক্যমত্য রয়েছে। @ বিবিপোকক কী বর্ণনা করেছেন এবং আর্টেমিস যা ব্যবহার করছেন তা এই ব্লগটিতে আরও গভীরভাবে বর্ণনা করা হয়েছে: t-machine.org/index.php/category/entity- সিস্টেমগুলি
সিস্টেমগুলি.উইকিডোট

উত্তর:


6

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

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

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

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

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

সংক্ষেপে:

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

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

সিস্টেম একটি নির্দিষ্ট ধরণের সমস্ত উপাদান পরিচালনা করে এবং প্রতিটি ফ্রেমকে বলা উপাদানগুলি আপডেট করার পাশাপাশি উপাদানগুলির যে অংশগুলির সাথে সম্পর্কিত সেগুলি যে উপাদানগুলির দ্বারা পরিচালিত হয় সেগুলির বার্তাগুলি প্রেরণ করার জন্য দায়বদ্ধ

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

আশাকরি এটা সাহায্য করবে. এটি একটি ডিজাইনের প্যাটার্নের একটি নরক, তবে সঠিকভাবে সম্পন্ন করা গেলে এটি হাস্যকরভাবে শক্তিশালী।


0

আমি আমার ইঞ্জিনে অনুরূপ সিস্টেমটি ব্যবহার করছি এবং যেভাবে এটি করেছি তা প্রতিটি সংস্থাতে উপাদানগুলির একটি তালিকা রয়েছে। সত্তা ম্যানেজার থেকে, আমি প্রতিটি প্রতিষ্ঠানের কোয়েরি করতে পারি এবং কোনটি কোনও প্রদত্ত উপাদানকে ধারণ করে তা দেখতে পারি। উদাহরণ:

class Component
{
    private uint ID;
    // etc...
}

class Entity
{
    List<Component> Components;
    // etc...
    public bool Contains(Type type)
    {
        foreach(Component comp in Components)
        {
            if(typeof(comp) == type)
                return true;
        }
        return false;
    }
}

class EntityManager
{
    List<Entity> Entities;
    // etc...
    public List<Entity> GetEntitiesOfType(Type type)
    {
        List<Entity> results = new List<Entity>();
        foreach(Entity entity in Entities)
        {
            if(entity.Contains(type))
                results.Add(entity);
        }
        return results;
    }
}

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


3
ক্যাভেট এমপোটার: আপনার সত্তায় যে বিন্দুতে ডেটা রয়েছে, সেই বিন্দুতে এটি কোনও বস্তু, কোনও সত্তা নয় ... এই কাঠামোর মধ্যে ইসিএসের বেশিরভাগ প্যারালাইলাইজিং (sic?) সুবিধাগুলি হারাবে। "খাঁটি" ই / সি / এস সিস্টেমগুলি সম্পর্কযুক্ত, বস্তু-ভিত্তিক নয় ... এমন নয় যে এটি কোনও ক্ষেত্রে (গুলি) এর জন্য অবশ্যই "খারাপ" নয়, তবে অবশ্যই এটি "সম্পর্কের মডেলটি ভঙ্গ করছে"
বিআরপোকক

2
আমি নিশ্চিত যে আমি আপনাকে বুঝতে পারি না। আমার বোঝাপড়া (এবং আমি ভুল হলে দয়া করে আমাকে সংশোধন করুন) হ'ল মৌলিক সত্তা-উপাদান-সিস্টেমটির একটি সত্তা শ্রেণি রয়েছে যা উপাদান রাখে এবং এতে একটি আইডি, নাম বা কোনও সনাক্তকারী থাকতে পারে। আমি মনে করি সত্তার "টাইপ" বলতে আমি কী বোঝাতে চাইছি তাতে আমাদের একটি ভুল ধারণা থাকতে পারে। যখন আমি সত্তাটি "টাইপ" বলি, তখন আমি উপাদানগুলির প্রকারগুলি উল্লেখ করছি। এটি বলতে গেলে, কোনও সত্তা হ'ল "স্প্রাইট" টাইপ যদি এতে স্প্রাইট উপাদান থাকে।
মাইক ক্লাক

1
খাঁটি সত্তা / উপাদান সিস্টেমে একটি সত্ত্বা সাধারণত পারমাণবিক হয়: যেমন typedef long long int Entity; একটি উপাদান হ'ল একটি রেকর্ড (এটি কোনও অবজেক্ট শ্রেণি হিসাবে প্রয়োগ করা যেতে পারে, বা কেবলমাত্র struct) যা এতে সত্তার সাথে সম্পর্কিত যা সত্তার একটি রেফারেন্স রয়েছে; এবং একটি সিস্টেম পদ্ধতি বা পদ্ধতি সংগ্রহ করা হবে collection ইসিএস মডেলটি ওওপি মডেলের সাথে খুব সামঞ্জস্যপূর্ণ নয়, যদিও কোনও উপাদান একটি (বেশিরভাগ) ডেটা-কেবলমাত্র অবজেক্ট হতে পারে এবং একটি সিস্টেম কেবল একটি কোড-একক সিঙ্গলটন অবজেক্ট যার রাজ্যে উপাদানগুলিতে থাকে ... যদিও "সংকর" সিস্টেমগুলি "খাঁটি" এর চেয়ে বেশি সাধারণ, তারা জন্মগত সুবিধাগুলি হারিয়ে ফেলে।
বিআরপোক্ক

2
@ বিআরপোক্ক "খাঁটি" সত্তা সিস্টেম পুনরায়। আমি মনে করি একটি বস্তু হিসাবে একটি সত্তা পুরোপুরি ঠিক আছে, এটি একটি সহজ আইডি হতে হবে না। একটি জিনিস হ'ল সিরিয়ালাইজড উপস্থাপনা, অন্যটি কোনও জিনিসের ইন-মেমরি লেআউট / ধারণা / কোনও সত্তা। যতক্ষণ আপনি ডেটা-চালিততা বজায় রাখতে পারবেন, কেবলমাত্র এটি "খাঁটি" উপায়ের কারণে অ-প্রতিচ্ছবিযুক্ত কোডের সাথে যুক্ত করা উচিত নয়।
রাইন

1
@ বিআরপোক্ক এটি একটি সুস্পষ্ট সতর্কতা, তবে "টি-মেশিন" -র মতো সত্তা সিস্টেমগুলির জন্য। আমি বুঝতে পারি কেন, তবে সেগুলি উপাদান-ভিত্তিক সত্তাগুলির মডেল করার একমাত্র উপায় নয়। অভিনেতা একটি আকর্ষণীয় বিকল্প। আমি তাদের আরও প্রশংসা করি, বিশেষত খাঁটি যৌক্তিক সত্তার জন্য।
রাইন

0

1) আপনার কারখানার পদ্ধতিটি অ্যান্টিটি ম্যানেজারের কাছে উল্লেখ করা উচিত যা এটি বলেছিল (আমি সি # উদাহরণ হিসাবে ব্যবহার করব):

delegate BaseEntity EntityFactory(EntityManager manager);

2) সত্তার শ্রেণি / প্রকারের পাশাপাশি ক্রিয়েটএন্টিটিও একটি আইডি (যেমন একটি স্ট্রিং, পূর্ণসংখ্যা, এটি আপনার উপর নির্ভর করে) পেয়ে থাকে এবং সেই আইডিটি কী হিসাবে ব্যবহার করে একটি অভিধানে স্বয়ংক্রিয়ভাবে তৈরি সত্তাকে নিবন্ধিত করে:

class EntityManager
{
    // Rest of class omitted

    BaseEntity CreateEntity(string id, Type entityClass)
    {
        BaseEntity entity = factories[entityClass](this);
        registry.Add(id, entity);
        return entity;
    }

    Dictionary<Id, BaseEntity> registry;
}

3) আইডি দ্বারা কোনও সত্তা পাওয়ার জন্য অ্যান্টিটিম্যানেজারে একজন গেটর যুক্ত করুন:

class EntityManager
{
    // Rest of class omitted

    BaseEntity GetEntity(string id)
    {
        return registry[id];
    }
}

এবং আপনার ফ্যাক্টরি পদ্ধতির মধ্যে থেকে কোনও কম্পোনেন্টম্যানেজারের রেফারেন্স করার দরকার এটাই। এই ক্ষেত্রে:

BaseEntity CreateSomeSortOfEntity(EntityManager manager)
{
    // Create and configure entity
    BaseEntity entity = new BaseEntity();
    RenderComponent renderComponent = new RenderComponent();
    entity.AddComponent(renderComponent);

    // Get a reference to the render manager and register component
    RenderEntityManager renderer = manager.GetEntity("RenderEntityManager") as RenderEntityManager;
    if(renderer != null)
        renderer.Register(renderComponent)

    return entity;
}

আইডির পাশাপাশি আপনি কিছু প্রকারের সম্পত্তি (একটি কাস্টম এনাম, বা কেবলমাত্র ভাষার ধরণের সিস্টেমে নির্ভর করতে পারেন) ব্যবহার করতে পারেন এবং একটি গেটর তৈরি করতে পারেন যা একটি নির্দিষ্ট ধরণের সমস্ত বেসেনটিটি দেয়।


1
পেডেন্টিক হতে হবে না, তবে আবার ... খাঁটি সত্তা (সম্পর্কিত) পদ্ধতিতে সত্তাগুলির কোনও ধরণের নেই, যা তাদের উপাদানগুলির দ্বারা তাদের দেওয়া হয়েছিল ...
বিআরপোকক

@ বিবিপোকক: আপনি কি এমন উদাহরণ তৈরি করতে পারেন যা খাঁটি গুণাবলী অনুসরণ করে?
জোলোমন

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

2
"বিশুদ্ধ" সত্তা সিস্টেম:: সুত্র সালে সত্তা ID সাধারণত ভালো কিছু হল: typedef unsigned long long int EntityID;; আদর্শটি হ'ল, প্রতিটি সিস্টেম পৃথক সিপিইউ বা হোস্টে বাস করতে পারে এবং কেবলমাত্র সেই সিস্টেমে প্রাসঙ্গিক / সক্রিয় সম্পর্কিত উপাদানগুলি আনতে হবে ch কোনও সত্তা অবজেক্টের সাথে, প্রত্যেককে হোস্টে একই অ্যান্টিটি অবজেক্ট ইনস্ট্যান্ট করতে হতে পারে, স্কেলিংকে আরও কঠিন করে তুলবে। একটি খাঁটি সত্তা-উপাদান-সিস্টেম মডেলটি সাধারণত সত্তার পরিবর্তে নোডের (প্রসেস, সিপিইউ বা হোস্ট) প্রক্রিয়াকরণকে আলাদা করে দেয় entity
বিআরপোক্ক

1
@ ডেভিডগুভিয়া উল্লেখ করেছে "অপ্টিমাইজেশন ... আইডি দ্বারা সত্ত্বা সন্ধান করা" ” আসলে, আমি যে কয়েকটি (কয়েকটি) সিস্টেমে এটি প্রয়োগ করেছি, তা না করার ঝোঁক। প্রায়শই, কিছু প্যাটার্ন দিয়ে উপাদানগুলি নির্বাচন করুন যা ইঙ্গিত করে যে তারা কোনও নির্দিষ্ট সিস্টেমে আগ্রহী, কেবলমাত্র ক্রস-উপাদানগুলির সাথে যোগদানের জন্য সত্তা (আইডি) ব্যবহার করে।
বিআরপোক্ক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.