আমরা বেসিক সিস্টেম-উপাদান-সত্তা পদ্ধতির থেকে শুরু করি ।
আসুন এসেমব্লেজগুলি তৈরি করুন ( এই নিবন্ধটি থেকে প্রাপ্ত শব্দটি ) কেবলমাত্র উপাদানগুলির ধরণের সম্পর্কে তথ্যের বাইরে । এটি রানটাইমের সময়ে গতিশীলভাবে সম্পন্ন হয়, যেমন আমরা কোনও সত্তায় উপাদানগুলি একে অপরের সাথে যুক্ত / অপসারণ করতে চাই, তবে আসুন কেবলমাত্র নামটির নামকরণের কারণ এটি কেবল টাইপ তথ্য সম্পর্কিত।
তারপরে আমরা তাদের প্রত্যেকের জন্য অ্যাসেমব্লেজ উল্লেখ করে সত্ত্বা তৈরি করি। একবার যখন আমরা সত্তাটি তৈরি করি, এর সমাবেশটি স্থায়ী হয় যার অর্থ আমরা এটি সরাসরি জায়গায় পরিবর্তন করতে পারি না, তবুও আমরা বিদ্যমান সত্তার স্বাক্ষর একটি স্থানীয় অনুলিপিতে (সামগ্রী সহ) পেতে পারি, এতে যথাযথ পরিবর্তন করতে পারি এবং একটি নতুন সত্তা তৈরি করতে পারি means এটা।
এখন মূল ধারণার জন্য: যখনই কোনও সত্তা তৈরি করা হয়, তখন এটি এসেম্ব্লেজ বালতি নামে একটি বস্তুকে বরাদ্দ করা হয় , যার অর্থ একই স্বাক্ষরের সমস্ত সত্তা একই ধারক (যেমন স্টাড :: ভেক্টর) এ থাকবে।
এখন সিস্টেমগুলি কেবল তাদের আগ্রহের প্রতিটি বালতিতে পুনরাবৃত্তি করে এবং তাদের কাজ করে।
এই পদ্ধতির কিছু সুবিধা রয়েছে:
- উপাদানগুলি কয়েকটিতে সংরক্ষণ করা হয় (অবিকল: বালতির সংখ্যা) সামঞ্জস্যপূর্ণ মেমরি খণ্ড - এটি মেমরি বন্ধুত্বের উন্নতি করে এবং পুরো গেমের স্থিতি ছড়িয়ে দেওয়া সহজ is
- সিস্টেমগুলি রৈখিক উপায়ে উপাদানগুলি প্রক্রিয়া করে, যার অর্থ উন্নত ক্যাশে সংহতি - বিদায় বাই অভিধান এবং এলোমেলো মেমরি লাফ দেয়
- একটি নতুন সত্তা তৈরি করা বালতিতে একটি অ্যাসেমব্লাজ ম্যাপিং এবং প্রয়োজনীয় উপাদানগুলি তার ভেক্টরে ফিরিয়ে দেওয়ার মতোই সহজ
- কোনও সত্তা মুছে ফেলা স্টাডিতে একটি কল করার মতোই সহজ: মুছে যাওয়াটির সাথে শেষ উপাদানটি অদলবদল করতে সরানো, কারণ এই মুহুর্তে অর্ডার কোনও ব্যাপার নয়
যদি সম্পূর্ণ আলাদা স্বাক্ষর সহ আমাদের প্রচুর সত্তা থাকে তবে ক্যাশে সুসংহত ধরণের সুবিধা হ্রাস পায় তবে আমি মনে করি না এটি বেশিরভাগ অ্যাপ্লিকেশনগুলিতেই ঘটবে।
একবার ভেক্টরগুলি পুনরায় স্থানান্তরিত হওয়ার পরে পয়েন্টার অবৈধকরণেও সমস্যা রয়েছে - এটি কাঠামো প্রবর্তন করে সমাধান করা যেতে পারে:
struct assemblage_bucket {
struct entity_watcher {
assemblage_bucket* owner;
entity_id real_index_in_vector;
};
std::unordered_map<entity_id, std::vector<entity_watcher*>> subscribers;
//...
};
সুতরাং যখনই আমাদের গেম যুক্তিতে কোনও কারণে আমরা একটি নতুন তৈরি করা সত্তাকে ট্র্যাক করে রাখতে চাই, বালতির ভিতরে আমরা একটি সত্তা_ওয়্যাচারকে নিবন্ধভুক্ত করি এবং সত্তাটি অপসারণের সময় স্ট্যান্ড :: চালিয়ে যেতে হবে, আমরা তার পর্যবেক্ষকদের অনুসন্ধান করব এবং আপডেট করব তাদের real_index_in_vectorনতুন মান। বেশিরভাগ সময় প্রতিটি সত্তা মোছার জন্য এটি কেবল একটি একক অভিধানের জন্য অনুসন্ধান চাপায়।
এই পদ্ধতির আরও কোনও অসুবিধা আছে কি?
বেশ সুস্পষ্ট হওয়া সত্ত্বেও কেন সমাধান কোথাও উল্লেখ করা হয়নি?
সম্পাদনা : মন্তব্যগুলি অপর্যাপ্ত হওয়ায় আমি "উত্তরগুলির উত্তর দিতে" প্রশ্নটি সম্পাদনা করছি।
আপনি প্লাগযোগ্য উপাদানগুলির গতিশীল প্রকৃতি হারাবেন, যা স্থির শ্রেণি নির্মাণ থেকে দূরে সরে যাওয়ার জন্য বিশেষত তৈরি হয়েছিল।
আমি না। সম্ভবত আমি এটি যথেষ্ট পরিষ্কারভাবে ব্যাখ্যা না করলাম:
auto signature = world.get_signature(entity_id); // this would just return entity_id.bucket_owner->bucket_signature or so
signature.add(foo_component);
signature.remove(bar_component);
world.delete_entity(entity_id); // entity_id would hold information about its bucket owner
world.create_entity(signature); // automatically assigns new entity to an existing or a new bucket
এটি কেবল বিদ্যমান সত্তার স্বাক্ষর গ্রহণ, এটি পরিবর্তন করে নতুন সত্তা হিসাবে আবার আপলোড করার মতো সহজ। সাশ্রয়ী, গতিশীল প্রকৃতি ? অবশ্যই. এখানে আমি জোর দিয়ে বলতে চাই যে এখানে কেবল একটি "সমাবেশ" এবং একটি "বালতি" শ্রেণি রয়েছে " বালতিগুলি ডেটাচালিত হয় এবং রানটাইমের সময় একটি অনুকূল পরিমাণে তৈরি হয়।
আপনাকে এমন সমস্ত বালতিতে যেতে হবে যাতে একটি বৈধ লক্ষ্য থাকতে পারে। বাহ্যিক ডেটা কাঠামো না থাকলে সংঘর্ষ সনাক্তকরণও তত সমান কঠিন হতে পারে।
ঠিক আছে, এ কারণেই আমাদের উপরে উল্লিখিত বাহ্যিক ডেটা স্ট্রাকচার রয়েছে । ওয়ার্কআরউন্ডটি সিস্টেম ক্লাসে একটি পুনরাবৃত্তি প্রবর্তনের মতোই সহজ যা পরের বালতিতে কখন লাফিয়ে যায় তা সনাক্ত করে। জাম্পিং বিশুদ্ধরূপে যুক্তিবিজ্ঞান স্বচ্ছ হতে হবে।