আমি কি এই উপাদান আর্কিটেকচারের সাথে সঠিক পথে রয়েছি?


9

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

পূর্বে, আমার একটি শ্রেণিবিন্যাস ছিল যা এরকম কিছু হয়েছিল:

Item -> Equipment -> Weapon
                  -> Armor
                  -> Accessory
     -> SyntehsisItem
     -> BattleUseItem -> HealingItem
                      -> ThrowingItem -> ThrowsAsAttackItem

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

আমি তখন বেস আইটেম ক্লাসে রিফ্যাক্টর এবং কার্যকারিতা স্থাপনের চেষ্টা করেছি। তবে আমি লক্ষ করছিলাম যে আইটেমটিতে প্রচুর অব্যবহৃত / অতিরিক্ত অতিরিক্ত তথ্য ছিল। এখন আমি আর্কিটেকচারের মতো কোনও উপাদান করার চেষ্টা করছি, আমার অন্যান্য গেমের ক্লাসে চেষ্টা করার আগে কমপক্ষে আমার আইটেমগুলির জন্য।

কম্পোনেন্ট সেটআপের জন্য আমি বর্তমানে যা ভাবছি তা এখানে:

আমার একটি বেস আইটেম ক্লাস রয়েছে যা বিভিন্ন উপাদানগুলির জন্য স্লট রয়েছে (যেমন একটি সরঞ্জাম উপাদান স্লট, একটি নিরাময় উপাদান স্লট, ইত্যাদি পাশাপাশি স্বেচ্ছাসেবী উপাদানগুলির জন্য একটি মানচিত্র) যাতে এরকম কিছু:

class Item
{
    //Basic item properties (name, ID, etc.) excluded
    EquipmentComponent* equipmentComponent;
    HealingComponent* healingComponent;
    SynthesisComponent* synthesisComponent;
    ThrowComponent* throwComponent;
    boost::unordered_map<std::string, std::pair<bool, ItemComponent*> > AdditionalComponents;
} 

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

মানচিত্রটি মূল আইটেম উপাদান নয় এমন যথেচ্ছ উপাদানগুলি সঞ্চয় করতে ব্যবহৃত হয়। আইটেম ধারকটি আইটেম কম্পোনেন্ট পরিচালনা করা উচিত কিনা বা এটি কোনও বাহ্যিক উত্স দ্বারা পরিচালিত হচ্ছে কিনা তা বোঝাতে আমি এটি একটি বুলের সাথে জুড়ি করছি।

আমার ধারণাটি এখানে ছিল যে আমি আমার গেম ইঞ্জিনের সম্মুখভাগে ব্যবহৃত মূল উপাদানগুলি সংজ্ঞায়িত করি এবং আমার আইটেম ফ্যাক্টরিটি আইটেমটির আসলে যে উপাদানগুলি দেয় তা নির্ধারণ করে দেবে, অন্যথায় তারা বাতিল হয়। মানচিত্রে স্বেচ্ছাসেবী উপাদান থাকবে যা সাধারণত স্ক্রিপ্টিং ফাইলগুলির মাধ্যমে যুক্ত / গ্রহণ করা হত।

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

উত্তর:


8

এটি একটি খুব যুক্তিসঙ্গত প্রথম পদক্ষেপ মত মনে হয়।

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

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

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

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

আপনার দৃষ্টিভঙ্গির সাথে আমি যে বড় ক্ষতি দেখতে পাচ্ছি তা হ'ল আপনি "সত্তা" অবজেক্টে সমস্ত উপাদান একসাথে ক্লম্পিং করছেন যা আসলে সর্বদা সেরা নকশা নয়। থেকে আমার সংশ্লিষ্ট উত্তর আরেকটি উপাদান-ভিত্তিক প্রশ্ন করুন:

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

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

তবে আমি এটিকে কেবল ভবিষ্যতের দিক হিসাবে বিবেচনা করার মতো কিছু হিসাবে দেখিয়েছি - আপনি অবশ্যই এটিকে ওভারবোর্ডে যেতে চান না; আপনি ধ্রুবক রিফ্যাক্টরিংয়ের মাধ্যমে ক্রমান্বয়ে রূপান্তর করতে পারেন বা আপনি আবিষ্কার করতে পারেন যে আপনার বর্তমান বাস্তবায়ন আপনার প্রয়োজনগুলি পুরোপুরি পূরণ করে এবং এটির পুনরাবৃত্তি করার দরকার নেই।


1
আইটেম অবজেক্ট থেকে মুক্তি পাওয়ার পরামর্শ দেওয়ার জন্য +1। এটি আরও কাজ আপ-ফ্রন্ট হবে, এটি একটি ভাল উপাদান সিস্টেম উত্পাদন শেষ হবে।
জেমস

আমার আরও কয়েকটি প্রশ্ন ছিল, আমি নতুন টপিয়ুক শুরু করা উচিত কিনা তা সম্পর্কে অনিশ্চিত, তাই প্রথমে এখানে চেষ্টা করার চেষ্টা করছি: আমার আইটেম শ্রেণির জন্য, আমি এভার্ট ফ্রেম (বা এমনকি নিকটে) কল করব এমন কোনও পদ্ধতি নেই। আমার গ্রাফিক্স সাবসিস্টেমগুলির জন্য, আমি আপনার পরামর্শ নেব এবং সমস্ত বস্তুকে সিস্টেমে আপডেট করার জন্য রাখব। অন্যান্য প্রশ্ন আমার কাছে ছিল আমি কীভাবে উপাদানগুলির চেকগুলি পরিচালনা করব? উদাহরণস্বরূপ, আমি দেখতে চাই যে আমি কোনও আইটেম এক্স হিসাবে ব্যবহার করতে পারি কিনা তাই স্বাভাবিকভাবেই আমি আইটেমটি এক্স সঞ্চালনের জন্য প্রয়োজনীয় উপাদানটি রয়েছে কিনা তা পরীক্ষা করে দেখতে চাই this এটি করার সঠিক উপায় কি এটি? উত্তরের জন্য আবার ধন্যবাদ
ব্যবহারকারী 127817
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.