গেমের উপাদান, গেম ম্যানেজার এবং অবজেক্ট প্রোপার্টি


15

আমি উপাদান ভিত্তিক সত্তা ডিজাইন প্রায় আমার মাথা পেতে চেষ্টা করছি।

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

পরের জিনিসটি আমি হ'ল বস্তুটি সরিয়েছিলাম এবং প্রতিটি আইডির সাথে প্রতিটি উপাদান রয়েছে। সুতরাং একটি আইডিকে একই আইডি থাকা উপাদানগুলি দ্বারা সংজ্ঞায়িত করা হয়।

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

আমার প্রথম চিন্তাটি এমন একটি ObjectPropertyশ্রেণীর ছিল যা উপাদানগুলির উপাদান হিসাবে এটির পরিবর্তে উপাদানগুলি প্রশ্ন করতে পারে। সুতরাং একটি অবজেক্টের একটি সংখ্যা ObjectPropertyএবং থাকবে ObjectComponent। উপাদানগুলির বৈশিষ্ট্যগুলির জন্য অবজেক্টকে কোয়েরি করে এমন আপডেট যুক্তি থাকতে পারে। পরিচালকটি উপাদানটির আপডেট পদ্ধতি কল করার ব্যবস্থা করবে।

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

  1. এই (হচ্ছে না ObjectProperty, ObjectComponentএবং ComponentManagerক্লাস) ওভার ইঞ্জিনিয়ারিং?
  2. একটি ভাল বিকল্প কি হতে পারে?

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


@ জোনাথন ডিকিনসন, @ ডেন: আমি মনে করি, তবে আমার সমস্যাটি হ'ল আমি কোথায় সাধারণ সম্পত্তি রাখি। উদাহরণস্বরূপ একটি পদার্থ হিসাবে একটি পদ, যা a RenderingComponentএবং a ব্যবহার করে PhysicsComponent। সম্পত্তিটি কোথায় রাখব এই সিদ্ধান্তের বিষয়ে আমি কী ভাবছি? আমি কি কেবল এটি আটকে রাখতে পারি, তারপরে অন্য কোয়েরিতে প্রয়োজনীয় সম্পত্তি আছে এমন উপাদানটির জন্য কোনও অবজেক্ট থাকা উচিত?
জর্জ ডেকেট

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

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

উত্তর:


6

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

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

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

  • এখানে কোন চামচ নেই.
    • এটি কেন্দ্রীয় পদক্ষেপ থেকে মুক্তি পেতে আপনি ইতিমধ্যে পদক্ষেপ নিয়েছেন। এটি সত্তা অবজেক্টের মধ্যে কী যায় এবং এখন আপনার কাছে থাকা সমস্ত উপাদান হ'ল সামগ্রীতে কী ঘটে যায় তার পুরো বিতর্ককে সরিয়ে দেয়।
  • উপাদানগুলি কাঠামো নয়
    • যদি আপনি কোনও কিছু ভেঙে যান যেখানে এটিতে কেবল ডেটা থাকে তবে এটি আর কোনও উপাদান নয়, এটি কেবল একটি ডেটা স্ট্রাকচার।
    • একটি উপাদান একটি নির্দিষ্ট পদ্ধতিতে খুব নির্দিষ্ট কাজ সম্পাদন করার জন্য প্রয়োজনীয় সমস্ত কার্যকারিতা ধারণ করে।
    • আইআরেন্ডারেবল ইন্টারফেস গেমটিতে দৃশ্যমানভাবে প্রদর্শন করার জন্য জেনেরিক সমাধান সরবরাহ করে। CRenderableSprite এবং CRenderableModel হল সেই ইন্টারফেসের একটি উপাদান বাস্তবায়ন যা যথাক্রমে 2D এবং 3D তে রেন্ডার করার জন্য নির্দিষ্টকরণ সরবরাহ করে।
    • আইউউসেবল হ'ল এমন কোনও কিছুর জন্য ইন্টারফেস যা কোনও খেলোয়াড় তার সাথে ইন্টারঅ্যাক্ট করতে সক্ষম হয়। কিউসেবল আইটেমটি সেই উপাদানটি হবে যা হয় হয় সক্রিয় বন্দুক থেকে গুলি করে বা নির্বাচিত ঘাটি পান করে তবে CUseableTrigger এমন এক জায়গা হতে পারে যেখানে কোনও খেলোয়াড় বুড়ীতে ঝাঁপিয়ে পড়তে বা ড্রিব্রিজ ফেলে দেওয়ার জন্য লিভার নিক্ষেপ করতে পারে।

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

তত্ত্ব এবং ব্যবহারিকতার মধ্যে একটি ভাল লাইন চেষ্টা করুন এবং আঁকুন।

আশাকরি এটা সাহায্য করবে.


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

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

"যদি আপনি এমন কোনও কিছু ভেঙে দেন যেখানে এটিতে কেবল ডেটা থাকে তবে এটি আর কোনও উপাদান নয়, এটি কেবল একটি ডেটা স্ট্রাকচার।" - কেন? "উপাদান" এমন একটি জেনেরিক শব্দ যা এর অর্থ ডেটা স্ট্রাকচারকেও বোঝাতে পারে।
পল মানতা

@ পলমন্ত হ্যাঁ এটি একটি জেনেরিক শব্দ, তবে এই প্রশ্ন ও উত্তরের পুরো বিষয়টি কোথায় লাইনটি আঁকতে হবে। আমার উত্তর, যেমন আপনি উদ্ধৃত করেছেন, কেবলমাত্র এটি করার জন্য একটি নিয়মের জন্য আমার পরামর্শ। সর্বদা হিসাবে আমি কখনও তত্ত্ব বা ডিজাইনের বিবেচনাগুলি বিকাশকে চালিত করে না দেওয়া, এর পক্ষে সহায়তা করার উদ্দেশ্যে প্রচার করি।
জেমস

1
@ জেমস এটি একটি আকর্ষণীয় আলোচনা ছিল। :) chat.stackexchange.com/rooms/2175 আপনার বাস্তবায়ন যদি হয় যে উপাদানগুলি অন্যান্য উপাদানগুলিতে কী আগ্রহী সে সম্পর্কে খুব বেশি জানতে পারে I'd আমি ভবিষ্যতে আলোচনা চালিয়ে যেতে চাই।
পল মানতা

14

আপনি ইতিমধ্যে একটি উত্তর গ্রহণ করেছেন, তবে এখানে একটি সিবিএসে আমার ছুরিকাঘাত। আমি দেখতে পেয়েছি যে জেনেরিক Componentক্লাসের কিছু সীমাবদ্ধতা রয়েছে, তাই আমি জিডিসি ২০০৯ এ র‌্যাডিকাল এন্টারটেইনমেন্ট দ্বারা বর্ণিত একটি নকশার সাথে গিয়েছিলাম, যিনি উপাদানগুলিকে পৃথকীকরণে Attributesএবং পৃথক করার পরামর্শ দিয়েছিলেন Behaviors। (" গেম অবজেক্ট কম্পোনেন্ট আর্কিটেকচারের তত্ত্ব এবং অনুশীলন ", মার্সিন চ্যাডি)

আমি দুটি পৃষ্ঠার নথিতে আমার নকশার সিদ্ধান্তগুলি ব্যাখ্যা করি। আমি এখানে লিঙ্কটি পোস্ট করব কারণ এটি সমস্ত এখানে আটকানো খুব দীর্ঘ। এটি বর্তমানে কেবল যুক্তিযুক্ত উপাদানগুলি (রেন্ডারিং এবং পদার্থবিজ্ঞানের উপাদানগুলিও নয়) জুড়েছে তবে এটি আমি কী করার চেষ্টা করেছি তার একটি ধারণা দেওয়া উচিত:

http://www.pdf-archive.com/2012/01/08/entity-comp جز- সিস্টেম / প্রিভিউ / পৃষ্ঠা / 1

এখানে নথির একটি অংশ:

সংক্ষিপ্ত বৈশিষ্ট্য এবং আচরণ

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

Behaviorsগেম ইভেন্টগুলিতে সত্তা কীভাবে প্রতিক্রিয়া দেখায়, সিদ্ধান্ত নেয় এবং Attributesপ্রয়োজনীয় মানগুলিতে পরিবর্তন করে তা নিয়ন্ত্রণ করুন । Behaviorsউপর নির্ভরশীল কিছু এর Attributes, কিন্তু তারা করতে পারেন না সরাসরি একে অপরের সাথে যোগাযোগ - তারা শুধুমাত্র কিভাবে প্রতিক্রিয়া Attributes’মান অন্যান্য দ্বারা পরিবর্তিত হয় Behaviorsএবং ঘটনা তারা পাঠানো হয় হয়।


সম্পাদনা করুন: এবং এখানে একটি সম্পর্কের চিত্র রয়েছে যা দেখায় যে উপাদানগুলি একে অপরের সাথে কীভাবে যোগাযোগ করে:

বৈশিষ্ট্য এবং আচরণের মধ্যে যোগাযোগ ডায়াগ্রাম

একটি প্রয়োগের বিশদ: সত্তা-স্তরটি EventManagerকেবলমাত্র এটি ব্যবহৃত হলে তৈরি হয়। Entityশ্রেণী শুধু একটি একটি পয়েন্টার সঞ্চয় করে EventManagerযে সক্রিয়া করা হয় শুধুমাত্র যদি কোন উপাদান যদি অনুরোধ করুন।


সম্পাদনা: অন্য প্রশ্নে আমি এর উত্তরটির অনুরূপ উত্তর দিয়েছি। সিস্টেমের একটি, সম্ভবত আরও ভাল ব্যাখ্যা জন্য আপনি এটি এখানে পেতে পারেন:
ps /gamedev//a/23759/6188


2

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

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

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

কোনও নিখুঁত সিস্টেম নেই। কিছু গেম সহজ সিস্টেমের সাথে আরও ভাল হবে যখন অন্যগুলিকে সিস্টেমে আরও জটিল সিঙ্ক্রোনাইজেশন প্রয়োজন।

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

কিছু সম্পত্তি অনুলিপি করতে কোন লজ্জা নেই। যদি কয়েকটি উপাদান একটি স্থানীয় অনুলিপি ধরে রাখার প্রয়োজন হয় তবে এটি কখনও কখনও "বাহ্যিক" মানটি অ্যাক্সেস করার চেয়ে অনুলিপি এবং সিঙ্ক করার পক্ষে আরও কার্যকর

এছাড়াও প্রতিটি ফ্রেমে সিঙ্ক করার দরকার পড়ে না। কিছু উপাদান অন্যদের চেয়ে কম ঘন ঘন সিঙ্ক করা যায়। রেন্ডার উপাদান প্রায়ই একটি ভাল উদাহরণ। যেগুলি খেলোয়াড়দের সাথে কথোপকথন করে না সেগুলি প্রায় দূরে যেমন ঠিক তেমনভাবে সমন্বয় করা যায়। ক্যামেরা ক্ষেত্রের বাইরে ও বাইরে যারা আরও ঘন ঘন সিঙ্ক করা যায়।


যখন এটি আপনার আকারের উপাদান আসে এটি সম্ভবত আপনার অবস্থানের উপাদানগুলির মধ্যেই বান্ডিল হতে পারে:

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

আকারের পরিবর্তে আপনি এমনকি আকার আকার পরিবর্তন করতে পারেন, এটি হ্যান্ডিয়ারে আসতে পারে।

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


2
বিটিডাব্লু +1 বা -1 আমাকে কারণ আমার বর্তমান প্রতিনিধিটি নভেম্বরের নবম থেকে 66 666 হ'ল ... এটি ভয়ঙ্কর।
কোয়েট

1

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

সি ++ বা C # এই সাধারণত এর অর্থ আপনার মত সত্তা উপর একটি টেমপ্লেট পদ্ধতি আছে চাই T GetComponent<T>()। এবং একবার আপনার কাছে সেই রেফারেন্স হয়ে গেলে, আপনি ঠিক কী কী সদস্যের ডেটা ধরেছেন তা জানেন, তাই কেবল এটি সরাসরি অ্যাক্সেস করুন।

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

বস্তুগত বৈশিষ্ট্যের জন্য জিজ্ঞাসা করা স্পষ্টভাবে শোনায় যে ভাষা আপনার জন্য কাজটি করতে পারে যা স্ট্যাটিকালি-টাইপ করা ভাষার জন্য সংকলন সময়ে অথবা গতিশীল টাইপযুক্তগুলির জন্য রান সময় হয়।


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

এটি উপযুক্ত হলে কেবল একটি বিদ্যমানটিকে বাছাই করুন বা সম্পত্তিটি যদি এটি না দেয় তবে একটি নতুন উপাদান হিসাবে ফ্যাক্টর করুন। উদাহরণস্বরূপ Unক্যের একটি 'ট্রান্সফর্ম' উপাদান রয়েছে যা কেবলমাত্র অবস্থান এবং অন্য কোনও কিছুর জন্য যদি বস্তুর অবস্থান পরিবর্তন করতে হয় তবে তারা সেই উপাদানটির মাধ্যমে এটি করে do
কাইলোটন

1

"আমি মনে করি, তবে আমার সমস্যাটি হ'ল আমি কোথায় সাধারণ সম্পত্তি রাখি Eg এটি উভয়ই মধ্যে রয়েছে, তারপরে অন্য কোয়েরিতে প্রয়োজনীয় সম্পত্তি আছে এমন উপাদানটির জন্য কোনও অবজেক্ট রয়েছে? "

জিনিস যে RenderingComponent হয় ব্যবহার অবস্থান, কিন্তু PhysicsComponent প্রদান করে এটা। কোন ব্যবহারকারী উপাদান ব্যবহার করবেন তা আপনাকে জানাতে একটি উপায় প্রয়োজন need আদর্শিকভাবে অজ্ঞাত উপায়ে, অন্যথায় একটি নির্ভরতা থাকবে।

"... এই প্রশ্নগুলি কোথায় যেতে হবে সে সম্পর্কে আমার প্রশ্নটি বিশেষত যেখানে একাধিক উপাদান দ্বারা কোনও সম্পত্তি ব্যবহৃত হয় এবং কোনও একক উপাদানই এর মালিক বলে বলা যায় না the প্রশ্নটিতে আমার তৃতীয় এবং চতুর্থ মন্তব্য দেখুন" "

কোনও সাধারণ নিয়ম নেই। নির্দিষ্ট সম্পত্তি উপর নির্ভর করে (উপরে দেখুন)।

একটি কুরুচিপূর্ণ কিন্তু উপাদান-ভিত্তিক আর্কিটেকচারের সাহায্যে একটি গেম তৈরি করুন এবং তারপরে এটি রিফ্যাক্টর।


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

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

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

1

আপনার বুদ্ধি দিয়ে আপনি যে থাকার বলছে ThingProperty, ThingComponentআর ThingManagerযে জন্য Thingউপাদান একটি ধরণ সামান্য Overkill। আমি মনে করি এটা ঠিক আছে।

তবে, আপনাকে কী কী সিস্টেমগুলি ব্যবহার করে, কোন সত্তার সাথে সম্পর্কিত সেগুলি সম্পর্কিত ক্ষেত্রে সম্পর্কিত উপাদানগুলির ট্র্যাক রাখতে আপনার কিছু উপায় প্রয়োজন etc.

TransformPropertyখুব সুন্দর একটি হতে চলেছে। কিন্তু এর দায়িত্বে কে, রেন্ডারিং সিস্টেম? পদার্থবিজ্ঞানের ব্যবস্থা? সাউন্ড সিস্টেম? কেন একটি Transformউপাদান এমনকি নিজেকে আপডেট করা প্রয়োজন?

সমাধানটি হ'ল গেটরস, সিটার এবং ইনিশিয়ালাইজারের বাইরে আপনার সম্পত্তি থেকে কোনও ধরণের কোড সরিয়ে নেওয়া। উপাদানগুলি হ'ল ডেটা, যা বিভিন্ন সিস্টেম যেমন রেন্ডারিং, এআই, সাউন্ড প্লেব্যাক, মুভমেন্ট ইত্যাদির জন্য গেমের সিস্টেমগুলি ব্যবহার করে is

আর্টেমিস সম্পর্কে পড়ুন: http://piemaster.net/2011/07/entity-comp घटक- artemis/

এর কোডটি দেখুন এবং আপনি দেখতে পাবেন যে এটি সিস্টেমের চারপাশে ভিত্তিক যা তাদের নির্ভরতাগুলি তালিকা হিসাবে ঘোষণা করে ComponentTypes। আপনি আপনার প্রতিটি Systemক্লাস লিখুন এবং কনস্ট্রাক্টর / আরআইডি পদ্ধতিতে ঘোষণা করুন যে সিস্টেমটি কী ধরণের উপর নির্ভর করে।

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

তারপরে আপনার লুপের আপডেট পর্ব চলাকালীন আপনার Systemএখন কী কী সত্তা আপডেট করবেন তার একটি তালিকা রয়েছে। এখন আপনি উপাদান গ্র্যানুলারিটি থাকতে পারে, ফলে আপনি একটি আউট পাগল সিস্টেম, বিল্ড সত্ত্বা উইল করতে পারেন ModelComponent, TransformComponent, FliesLikeSupermanComponent, এবং SocketInfoComponent, আর কিছু করতে মত অদ্ভুত একটি উড়ন্ত পিরিচ যে গ্রাহকদের মধ্যে মাছি একটি মাল্টিপ্লেয়ার খেলা সাথে সংযুক্ত। ঠিক আছে, সম্ভবত এটি না, তবে ধারণাটি হ'ল এটি জিনিসগুলিকে ডিকপলড এবং নমনীয় রাখে।

আর্টেমিস নিখুঁত নয়, এবং সাইটের উদাহরণগুলি কিছুটা মৌলিক তবে কোড এবং ডেটা পৃথকীকরণ শক্তিশালী। আপনি যদি এটি সঠিকভাবে করেন তবে এটি আপনার ক্যাশের পক্ষেও ভাল। আর্টেমিস সম্ভবত এটি ঠিক সম্মুখের দিকে না করে তবে এটি থেকে শেখা ভাল।

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