উপাদান-ভিত্তিক আর্কিটেকচারের জন্য গ্রানুলারিটির উপযুক্ত স্তর কী?


26

আমি উপাদান-ভিত্তিক আর্কিটেকচারের সাথে একটি গেমের সাথে কাজ করছি। একটি উদাহরণগুলির Entityএকটি সেটের মালিক Component, যার প্রত্যেকটির একটি সেট রয়েছে Slotযার সাথে মানগুলি সংরক্ষণ, প্রেরণ এবং গ্রহণ করতে হবে। কারখানা ফাংশন যেমন Playerপ্রয়োজনীয় উপাদান এবং স্লট সংযোগ সহ সত্তা উত্পাদন করে।

আমি উপাদানগুলির জন্য গ্রানুলারিটির সেরা স্তর নির্ধারণ করার চেষ্টা করছি। উদাহরণস্বরূপ, এখনই Position, Velocityএবং Accelerationসমস্ত পৃথক উপাদান, সিরিজে সংযুক্ত। Velocityএবং Accelerationসহজেই একটি অভিন্ন মধ্যে পুনর্লিখিত করা যেতে পারে Deltaউপাদান, বা Position, Velocityএবং Accelerationযেমন উপাদান পাশাপাশি মিলিত হতে পারে Frictionএবং Gravityএকটি একশিলা মধ্যে Physicsঅংশ।

কোনও উপাদানটির ক্ষুদ্রতম দায়িত্ব সম্ভব (আন্তঃসংযোগ প্রচুর পরিমাণে) হওয়া উচিত বা সংশ্লিষ্ট উপাদানগুলি একঘেয়েমিগুলিতে (নমনীয়তার ব্যয়ে) একত্রিত করা উচিত? আমি প্রাক্তনের দিকে ঝুঁকছি, তবে আমি দ্বিতীয় মতামতটি ব্যবহার করতে পারি।



আপনি কি নিজের পদার্থবিজ্ঞান ইঞ্জিন ব্যবহার করছেন বা বিদ্যমান একটি সংহত করতে যাচ্ছেন?
ডেন

@ ডেন: আমি কিছু পদার্থবিজ্ঞানের কোড লিখছি , তবে এটি কোনও উপায়ে ইঞ্জিন নয় । শুধু মুন্ডানে 2 ডি গতিবিজ্ঞান।
জন পুরি

উত্তর:


14

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

স্পষ্টতই জিনিসগুলির একটি থাকতে পারে Positionতবে এগুলি অগত্যা গতিশীল নয় (সুতরাং কেন আছে Velocityএবং Acceleration?)। যাইহোক, একটি সঙ্গে কিছু Velocityচলমান বস্তু হতে চলেছে, সুতরাং এটি Accelerationভাগ করাও বোধগম্য ।

আপনি একটি মামলা যেখানে আছে যাচ্ছি বনাম এবং একটি প্রয়োজন হতে যাচ্ছি, কিন্তু আপনি তাদের জন্য একটি পদার্থবিদ্যা সিমুলেশন চান না? একইভাবে, Gravityযদি তারা পদার্থবিজ্ঞানের বস্তু না হয় তবে সেখানে একটি বিন্দু হতে চলেছে ?

tl; ডাঃ গ্রুপ কী বোঝায়।


1
ফর্সা লাগছে। আমার সিস্টেম খুব সামান্য কেঁদ্রীকরণ আছে: যদি কোনো Entityএকটি আছে Positionএবং কিছু উপাদান তা নিশ্চিত করুন Positionপদার্থবিদ্যা অংশগ্রহণের, তারপর Entityহয় কার্যত শারীরিক। আমি মনে করি আমি যা করতে পারি তা হ'ল যৌক্তিক গোষ্ঠীকরণের জন্য কিছু উপাদান যুক্ত করা এবং সমস্ত মৌলিক উপাদানকে একক দায়বদ্ধ করে রাখা। তাই যোগ বলুন, একটি Movableএকটি থেকে Entityযোগ করার সময় একটি হিসাবে একই প্রভাব ফেলবে Position, Velocityএবং Acceleration
জন পুরী

6

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

তাই তাড়াহুড়া উদাহরণের জন্য আপনার গেম রয়েছে। খেলা পরিবেশ + রাজ্যে বিভক্ত হয়। পরিবেশ স্ট্যাটিক ওয়ার্ল্ড + মুভিংস্ট্যাফে বিভক্ত। রাজ্য AIControlled + প্লেয়ার নিয়ন্ত্রণে বিভক্ত। ক্ষতির ক্ষয় ধারণাটি টেকসড্যামেজ + গিভিসড্যামেজে বিভক্ত।

ইত্যাদি।

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


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

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

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

4

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

তবে এটি আপনার গেমের বৈশিষ্ট্যগুলি কীসের উপর নির্ভর করে (যদি আপনি কোনও নির্দিষ্ট খেলা মাথায় না রেখে কাঠামো তৈরি করে থাকেন))


2
অনেকগুলি ইন্টারঅ্যাকশনের সাথে উপাদানগুলির সংমিশ্রণে সমস্যাটি হ'ল কখনও কখনও অন্য অংশের প্রয়োজন হয় না।
কমিউনিস্ট হাঁস

4

আমি বুঝতে পারি এটি একটি পুরানো প্রশ্ন তবে সম্ভবত কেউ এই উত্তরটি দরকারী বলে মনে করবে।

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

উদাহরণস্বরূপ, যদি আপনি একটি থাকতে পারে MovementSystemযা তার সংস্থাগুলো আপডেটগুলি Positionতাদের উপর ভিত্তি করে Velocity। এটি গেমটিতে সরল সত্তার জন্য হতে পারে। তবে, প্লেয়ার এবং শত্রুদের জন্য, আপনি যে Accelerationপ্রক্রিয়াটি প্রক্রিয়াধীন রয়েছে এমন কোনও আন্দোলন করতে পারেন AcceleratedMovementSystem। তবে বাধা বিপক্ষে আপনি চাইতে পারেন Frictionভূখণ্ড এছাড়াও ঘর্ষণ থাকতে পারে, কিন্তু এটি একটি বেগ উপাদান থাকবে না। তবে কি Gravity? কেবল এটিকে প্লেয়ার, শত্রু এবং অন্তরায় যুক্ত করুন এবং GravitySystemএটি প্রক্রিয়া করার জন্য একটি তৈরি করুন ।

নীচের লাইনটি আপনার আরও ডিকপলডComponents হয়, আরো প্রসার্যEntities যখন ব্যবহার করা হবে Systems

সম্পাদনা করুন: সর্বশেষ বিবৃতিটি পরিষ্কার করা হয়েছে।

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


আমি সম্প্রতি একটি ব্লগ পোস্ট পড়েছিলাম যা এরকম কিছু বলেছিল:

"আপনার কাছে যদি এমন ডেটা থাকে যা 2 টি পৃথক উপাদানগুলির সাথে গোষ্ঠীভুক্ত করা যায় তবে সেই ডেটা দিয়ে তৃতীয় উপাদান তৈরি করা ভাল" "

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