কোনও উপাদান-ভিত্তিক গেমটিতে সত্তা রাজ্য এবং অ্যানিমেশনগুলি কীভাবে আপডেট করবেন?

Question

আমি শেখার উদ্দেশ্যে (এবং পরে কিছু গেমের জন্য ব্যবহার করুন) জন্য একটি উপাদান-ভিত্তিক সত্তা সিস্টেমটি ডিজাইনের চেষ্টা করছি এবং সত্তার রাজ্যগুলি আপডেট করার ক্ষেত্রে আমার কিছু সমস্যা হচ্ছে।

উপাদানগুলির মধ্যে নির্ভরতা রোধ করতে আমি কম্পোনেন্টের অভ্যন্তরে একটি আপডেট () পদ্ধতি রাখতে চাই না।

আমার বর্তমানে যা মনে আছে তা হ'ল উপাদানগুলি ডেটা এবং সিস্টেম আপডেটের উপাদান রাখে।

সুতরাং, যদি আমার কিছু সত্তা (যেমন প্লেয়ার, শত্রু 1, শত্রু 2) এর সাথে একটি সাধারণ 2 ডি গেম থাকে যা ট্রান্সফর্ম, মুভমেন্ট, স্টেট, অ্যানিমেশন এবং রেন্ডারিং উপাদান রয়েছে আমার মনে হয় আমার উচিত:

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

আমি আর্টেমিস ফ্রেমওয়ার্কের মতো কিছু বাস্তবায়ন দেখেছি, তবে এই পরিস্থিতি কীভাবে সমাধান করা যায় তা আমি জানি না:

ধরা যাক যে আমার গেমের নিম্নলিখিত সত্তা রয়েছে। প্রতিটি সত্তার প্রতিটি রাজ্যের জন্য একটি সেট এবং এক অ্যানিমেশন রয়েছে:

• খেলোয়াড়: "নিষ্ক্রিয়", "চলন্ত_ ডান", "জাম্পিং"
• শত্রু 1: "চলন্ত_আপ", "চলন্ত_ ডাউন"
• শত্রু 2: "চলন্ত_ বাম", "চলন্ত_ ডান"

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

আপনি দেখতে পাচ্ছেন যে, আমি এখানে বেশ হারিয়েছি, তাই আমি যে কোনও সাহায্যের খুব প্রশংসা করব।

সম্পাদনা: আমার মনে হয় এই কাজটি করার উদ্দেশ্যটি যেমন আমার ইচ্ছা তেমন সমাধানটি হ'ল:

আপনি স্টেটকম্পোন্ট এবং অ্যানিমেশন বিভাগকে সমস্ত সত্ত্বার জন্য যথেষ্ট জেনেরিক তৈরি করেন make তাদের থাকা ডেটা হ'ল কোন অ্যানিমেশনগুলি বাজানো হয় বা কোন রাজ্যগুলি উপলভ্য তা পরিবর্তিত করতে পারে things - বাইট 56

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

Comments

আমি ধরে নিলাম আপনি এটি দেখেছেন: সত্তা বা উপাদানগুলির মধ্যে রাজ্য পরিবর্তন ? আপনার প্রশ্নটি কি সেই থেকে মূলত আলাদা?

— MichaelHouse

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

— miviclin

আপনি করতে statecomponentএবং animationcomponentজেনেরিক যথেষ্ট সব সত্তার জন্য ব্যবহৃত হবে। তাদের থাকা ডেটা হ'ল কোন অ্যানিমেশনগুলি বাজানো হয় বা কোন রাজ্যগুলি উপলভ্য তা পরিবর্তিত করতে পারে things

— মাইকেলহাউস

আপনি যখন নির্ভরতা সম্পর্কে কথা বলেন, আপনি কি ডেটা নির্ভরতা বা এক্সিকিউশন অর্ডার নির্ভরতা বলতে চান? এছাড়াও, আপনার প্রস্তাবিত সমাধানে, মুভমেন্ট সিস্টেমটি এখন কিছু স্থানান্তরিত করতে পারে এমন বিভিন্ন উপায় প্রয়োগ করতে হবে? দেখে মনে হচ্ছে এটি উপাদান-ভিত্তিক সিস্টেমের ধারণাটি ভঙ্গ করছে ...

— ADB

@ এডিবি আমি ডেটা নির্ভরতার কথা বলছি। অ্যানিমেশনটি আপডেট করার জন্য (যেমন মুভ_রাইট অ্যানিমেশন থেকে মুভ_এল্ট অ্যানিমেশনটিতে পরিবর্তন) আমাকে সত্তার বর্তমান অবস্থা জানতে হবে এবং এই 2 উপাদানগুলিকে কীভাবে আরও জেনেরিক করা যায় তা আমি দেখতে পাই না।

— মিভিক্লিন

Answer 1

আইএমএইচও Movementউপাদানটির বর্তমান অবস্থা ( Movement.state) রাখা উচিত এবং Animationউপাদানটি Movement.stateতার বর্তমান অ্যানিমেশনটির পরিবর্তনগুলি পর্যালোচনা করে এবং Animation.animationসেই অনুযায়ী অ্যানিমেশনে স্টেট আইডিটির সরল অনুসন্ধান ব্যবহার করে (ওপিটির তত্ক্ষেত্রে শেষে পরামর্শ দেওয়া হয়েছে) update স্পষ্টতই এর অর্থ Animationনির্ভর করবে Movement।

একটি বিকল্প কাঠামোতে জেনেরিক Stateউপাদান থাকবে যা Animationপর্যবেক্ষণ করে এবং Movementপরিবর্তন করে যা মূলত মডেল-ভিউ-কন্ট্রোলার (এই ক্ষেত্রে স্টেট-অ্যানিমেশন-আন্দোলন)।

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

শুভকামনা।

Comments

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

— miviclin

প্রথম ঘটনা: Movementহবে নিয়ন্ত্রণ State (মান্য নয়)। সর্বশেষ কেস: হ্যাঁ Movementকরবেন entity.dispatchEvent(...);তাই, এবং অন্যান্য ইভেন্টের সমস্ত যে টাইপ শোনা উপাদান এটা পাবেন। পারফরম্যান্স অবশ্যই বিশুদ্ধ পদ্ধতি কলগুলির চেয়ে খারাপ, তবে বেশি নয়। উদাহরণস্বরূপ আপনি ইভেন্ট অবজেক্টগুলিকে পুল করতে পারেন। বিটিডব্লিউ, আপনাকে "ইভেন্ট নোড" হিসাবে সত্তাটি ব্যবহার করতে হবে না, আপনি নিজের সত্তা শ্রেণিটিকে একেবারে বাদ দিয়ে একটি উত্সর্গীকৃত "ইভেন্ট বাস" ব্যবহার করতে পারেন।

— অশ্লীল

Answer 2

আপনার সমস্যা সম্পর্কে, যদি স্টেটটি কেবল অ্যানিমেশনগুলিতে ব্যবহৃত হয়, তবে আপনাকে অন্য উপাদানগুলির কাছে এটি প্রকাশ করারও দরকার নেই। যদি এর একাধিক ব্যবহার হয় তবে আপনার এটি প্রকাশ করা দরকার।

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

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

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

বিভিন্ন গেমের অবজেক্টের জন্য আপনি বিভিন্ন রাজ্য / অ্যানিমেশনের যে সমস্যাটি জিজ্ঞাসা করছেন তা সম্পর্কিত, আমি কী করব তা এখানে । প্রথমত, বাস্তবায়নের এই পর্যায়ে আমি খুব অভিনব হয়ে উঠব না: এটি কাজ করার জন্য আপনার এখন যা প্রয়োজন কেবল তা প্রয়োগ করুন, তারপরে আপনার প্রয়োজন মতো ঘণ্টা এবং সিঁড়ি যুক্ত করুন।

সুতরাং, আমি একটি 'স্টেট' উপাদান দিয়ে শুরু করব: প্লেয়ারস্টেট কম্পোনেন্ট, শত্রু 1 স্টেট, শত্রু 2 স্টেট। রাষ্ট্রীয় উপাদান উপযুক্ত সময়ে রাষ্ট্র পরিবর্তন করার জন্য যত্ন নেবে। স্টেট হ'ল আপনার সমস্ত অবজেক্টের কাছে এমন কিছু রয়েছে যা এটি গেমবজেক্টে থাকতে পারে।

তারপরে, একটি অ্যানিমেশনকম্পেন্ট থাকবে। এটিতে এনিমেশনগুলির একটি অভিধান থাকবে যা কীডকে রাজ্যে আটকানো হয়। আপডেট () এ, রাষ্ট্র পরিবর্তন হলে অ্যানিমেশন পরিবর্তন করুন।

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

আমি প্রস্তাবিত প্রয়োগটি বেশ নিখুঁত, তবে আপনি আরও ব্যবহারের ক্ষেত্রে যুক্ত হওয়ায় এখানে কিছু সম্ভাব্য উন্নতি রয়েছে:

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

Comments

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

— miviclin

Answer 3

এডিবি'র উত্তর ছাড়াও আপনি http://en.wikedia.org/wiki/D dependency_inication ব্যবহার করতে পারেন , যা আপনাকে যখন তাদের নির্মাণকারীর তথ্যসূত্র হিসাবে পাস করার মাধ্যমে অনেকগুলি উপাদান তৈরি করার দরকার হয় তখন তা সহায়তা করে। স্পষ্টতই তারা একে অপরের উপর নির্ভর করবে (যদি এটি আপনার কোড বেসে প্রয়োজন হয়) তবে আপনি সেই সমস্ত নির্ভরতা এমন এক জায়গায় রাখতে পারেন যেখানে নির্ভরতা সেটআপ থাকে এবং আপনার কোডের বাকী অংশটি নির্ভরতা সম্পর্কে জানতে হবে না।

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

সাধারণ সিস্টেমগুলির জন্য আপনি ডিআই বা ক্লিন কোড ব্যবহার না করেই পালিয়ে যেতে পারেন, আপনার রেন্ডারিং সিস্টেম ক্লাসগুলি মনে হচ্ছে আপনার স্ট্যাটিকভাবে তাদের কল করতে হবে বা কমপক্ষে প্রতিটি উপাদানগুলিতে তাদের উপলব্ধ করা উচিত যা এটি একে অপরের উপর নির্ভরশীল এবং পরিবর্তন করা শক্ত। আপনি যদি আরও পরিষ্কার পদ্ধতির প্রতি আগ্রহী হন তবে উপরের ডিআই উইকির লিঙ্কের লিঙ্কগুলি দেখুন এবং ক্লিন কোড সম্পর্কে পড়ুন: http://clean-code-developer.com/

Comments

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

— miviclin