উপাদান সত্তা সিস্টেম - আপডেট এবং কল আদেশ


10

প্রতিটি ফ্রেম আপডেট করতে সক্ষম হওয়ার জন্য উপাদানগুলি পেতে (এবং এই কার্যকারিতাটি যে উপাদানগুলির প্রয়োজন হয় না তার বাইরে রেখে দিন) আমি একটি আপডেটকোম্পোন উপাদান তৈরি করার ধারণা পেয়েছি। অন্যান্য উপাদান যেমন MovableComponent(যা বেগ ধারণ করে) IUpdatableবিমূর্ত শ্রেণীর দ্বারা উত্তরাধিকার সূত্রে প্রাপ্ত হয় । এটি MovableComponentএকটি Update(gametime dt)পদ্ধতি এবং অন্যটি RegisterWithUpdater()যা UpdateComponentএকটি পয়েন্টার দেয় তা প্রয়োগ করতে বাধ্য করে MovableComponent। অনেক উপাদান এটি করতে পারে এবং তারপরে কে বা কী সেগুলি যত্ন না করেই UpdateComponentতাদের সমস্ত Update(gametime dt)পদ্ধতি কল করতে পারে ।

আমার প্রশ্নগুলি হ'ল:

  1. এটিকে কি এমন কিছু মনে হয় যা সাধারণ বা কারও দ্বারা ব্যবহৃত হয়? বিষয়টিতে আমি কিছুই খুঁজে পাচ্ছি না।
  2. পদার্থবিজ্ঞানের মতো পদক্ষেপের পরে অবস্থান পরিবর্তনের মতো কীভাবে আমি একটি অর্ডার বজায় রাখতে পারি? এটি কি প্রয়োজনীয়?
  3. প্রতিটি ফ্রেমের প্রক্রিয়া হওয়া উচিত এমন উপাদানগুলি প্রকৃতপক্ষে প্রক্রিয়াজাত করা উচিত কিনা তা নিশ্চিত করার অন্যান্য উপায়গুলি কী কী?

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

এখনও। আমার প্রশ্নগুলি আমার কাছে বৈধ থাকে। আমি জানি না এটি যুক্তিযুক্ত / সাধারণ কিনা, বা অন্যেরা কী ঝোঁক করে।

এছাড়াও, নিদ্রাহীন লোকেরা দুর্দান্ত! / সম্পাদনা

পূর্ববর্তী উদাহরণের জন্য সিদ্ধ ডাউন কোড:

class IUpdatable
{
public:
    virtual void Update(float dt) = 0;
protected:
    virtual void RegisterAsUpdatable() = 0;
};

class Component
{
    ...
};

class MovableComponent: public Component, public IUpdatable
{
public:
    ...
    virtual void Update(float dt);
private:
    ...
    virtual void RegisterWithUpdater();
};

class UpdateComponent: public Component
{
public:
    ...
    void UpdateAll();
    void RegisterUpdatable(Component* component);
    void RemoveUpdatable(Component* component);
private:
    ...
    std::set<Component*> updatables_;
};

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

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

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

@ মাইক আমার বক্তব্যটি এমন উপাদান নয় যা কখনই / কখনই পরিবর্তন হতে পারে না। আমি সম্মত যে নির্বোধ। তাদের কেবল প্রতিটি ফ্রেম আপডেট করার দরকার নেই, পরিবর্তে যখন প্রয়োজন তাদের তথ্য পরিবর্তন করার জন্য অবহিত করা হবে। সময়ের সাথে সাথে স্বাস্থ্যের উদাহরণে, একটি স্বাস্থ্য বোনাস উপাদান থাকবে যার একটি আপডেট রয়েছে। আমি মনে করি না যে দুটোকে একত্রিত করার কোনও কারণ আছে।
পিটিপেটারসন

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

উত্তর:


16

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

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

আপনার যা করা উচিত তা হ'ল প্রতি প্রকারের পুলগুলি সঞ্চয় করা এবং আপডেটগুলি সম্পাদনের জন্য প্রতিটি প্রকারকে স্বাধীনভাবে পুনরাবৃত্তি করা।

এটিকে কি এমন কিছু মনে হয় যা সাধারণ বা কারও দ্বারা ব্যবহৃত হয়? বিষয়টিতে আমি কিছুই খুঁজে পাচ্ছি না।

এটি বড় গেমগুলিতে সাধারণ নয় কারণ এটি সুবিধাজনক নয়। এটি প্রচুর গেমগুলির মধ্যে সাধারণ, তবে এটি প্রযুক্তিগতভাবে আকর্ষণীয় নয়, তাই এটি সম্পর্কে কেউ লেখেন না।

পদার্থবিজ্ঞানের মতো পদক্ষেপের পরে অবস্থান পরিবর্তনের মতো কীভাবে আমি একটি অর্ডার বজায় রাখতে পারি? এটি কি প্রয়োজনীয়?

সি ++ এর মতো ভাষাগুলিতে কোড কার্যকর করার আদেশ দেওয়ার প্রাকৃতিক উপায় রয়েছে: সেই ক্রমে বিবৃতিগুলি টাইপ করুন।

for (PhysicsComponent *c : physics_components)
    c->update(dt);
for (PositionComponent *c : position_components)
    c->update(dt);

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

physics_step();
for (PositionComponent *c : position_components)
    c->update(dt);
// Updates the position data from the physics data.

ধন্যবাদ। আমি এই পুরো প্রকল্পটি ডেটা ওরিয়েন্টেড (ডেটা চালিত ডেটার মতো নয়) মাথায় রেখে, ক্যাশে মিস করা এবং এরকম প্রতিরোধ করে শুরু করেছি। তবে একবার আমি কোডিং শুরু করলাম ঠিক করেছিলাম ঠিক এমন কিছু তৈরি করার জন্য যা ডট কমের কাজ করে। এটি আমার পক্ষে জিনিসকে আরও শক্ত করে তুলেছে। এবং গুরুতর জন্য, যে অনিদ্রা নিবন্ধ দুর্দান্ত ছিল!
পিটিপ্যাটারসন

খুব ভাল উত্তরের জন্য জো +1 যদিও আমি জানতে চাই যে একটি আইচাচি এবং ডেস্ক কী। ধন্যবাদ
রায় দে

নির্দেশের ক্যাশে এবং ডেটা ক্যাশে। কম্পিউটার আর্কিটেকচারের যে কোনও প্রারম্ভিক পাঠ্য তাদের আবরণ করা উচিত।

@ptpaterson: দ্রষ্টব্য যে অনিদ্রিয় উপস্থাপনায় একটি ছোট্ট ভুল রয়েছে - উপাদান শ্রেণীর অবশ্যই তার রোস্টার সূচক থাকতে হবে, বা রোস্টার সূচকগুলিতে আপনার জন্য পুল সূচকগুলির পৃথক ম্যাপিং দরকার।

3

আমার মনে হয় আপনি যে বিষয়ে কথা বলছেন তা যুক্তিসঙ্গত এবং মোটামুটি সাধারণ। এটি আপনাকে আরও কিছু তথ্য দিতে পারে।


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

0

আমি এই পদ্ধতিগুলি পছন্দ করি:

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

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.