গেম ইঞ্জিনে ইভেন্ট-চালিত যোগাযোগ: হ্যাঁ বা না?

Question

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

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

এটি কি প্রমাণিত এবং প্রস্তাবিত পদ্ধতি? এটি কীভাবে ব্যবহার করব তা আমি কীভাবে সিদ্ধান্ত নেব?

Comments

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

— বুঙ্কাই.সেটেরি

এটিকে একটি উত্তরে রাখুন এবং স্ট্যাক ওভারফ্লোতে একটি উত্তর হিসাবে আমি দিয়েছি এমন একটি ইভেন্ট মেসেজিং সিস্টেমের উচ্চ স্তরের ওভারভিউয়ের একটি লিঙ্কে যুক্ত হয়েছে। উপভোগ করুন! কেবল মনে রাখবেন যে কিছু লোক জটিল হিসাবে বিবেচনা করে তা হওয়ার দরকার নেই :)

— জেমস

: আপনি ভাল হিসাবে C ++ 11 ব্যবহার করা এই উত্তরটি পরীক্ষা করতে পারবেন stackoverflow.com/a/22703242/2929762

— user2826084

libuvসম্প্রতি একটি সফল ইভেন্ট লাইব্রেরি হিসাবে আত্মপ্রকাশ করেছে। (এটি সি নোড.জেজেসে এর সর্বাধিক বিখ্যাত ব্যবহারের ক্ষেত্রে রয়েছে))

— আনকো

Answer 1

এটি সম্পূর্ণ মন্তব্যে আমার মন্তব্যের সম্প্রসারণ , যেমনটি প্রস্তাবিত।

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

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

সম্পাদনা : কোন বস্তুটির বার্তাটি পাওয়া উচিত তা কীভাবে আপনি জানেন সে সম্পর্কে একটি মন্তব্য প্রশ্নের সমাধানের জন্য : বস্তুগুলিকে নিজেরাই Requestইভেন্টগুলি সম্পর্কে অবহিত করা উচিত । আপনার EventMessagingSystem(ইএমএস) Register(int iEventId, IEventMessagingSystem * pOjbect, (EMSCallback)fpMethodToUseForACallback)পাশাপাশি একটি ম্যাচিং Unregister( iEventIdঅবজেক্ট পয়েন্টার এবং কলব্যাকের বাইরে একটি অনন্য এন্ট্রি করা ) প্রয়োজন হবে। এইভাবে, যখন কোনও বস্তু Register()সিস্টেমের সাথে এটি করতে পারে এমন কোনও বার্তা সম্পর্কে জানতে চায় । ইভেন্টগুলির সম্পর্কে যখন আর এটির প্রয়োজনের দরকার নেই, তখন তা পারেUnregister()। স্পষ্টতই, আপনি এই কলব্যাক রেজিস্ট্রেশন অবজেক্টগুলির একটি পুল এবং তালিকা থেকে এগুলি যুক্ত / সরানোর কার্যকর উপায় চাই। (আমি সাধারণত স্ব-অর্ডারিং অ্যারে ব্যবহার করেছি; বলার এক অভিনব উপায় যা তারা অব্যবহৃত অবজেক্ট এবং অ্যারেগুলির পুল স্ট্যাকের মধ্যে তাদের নিজস্ব বরাদ্দগুলি ট্র্যাক করে যা প্রয়োজনের সময় তাদের আকারগুলি স্থান পরিবর্তন করে)।

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

Comments

হ্যালো জেমস, আমি যেমন অভ্যন্তরীণ ইভেন্ট মেসেজিং সিস্টেমটি সম্পর্কে আরও ভাবছি, আমি মনে করি এটি ইঞ্জিনে আরও ব্যয় যুক্ত করার দরকার নেই। উদাহরণস্বরূপ, যদি স্ক্রিনে 50 টি অবজেক্ট থাকে তবে তাদের মধ্যে কেবল 5 টি তাদের আচরণ পরিবর্তন করার কথা; traditionalতিহ্যবাহী সিস্টেমের অধীনে, সমস্ত 50 জন প্রজেক্টকে তাদের সম্ভাব্য সমস্ত পদক্ষেপের জন্য তাদের কিছু করা উচিত কিনা তা পরীক্ষা করে দেখতে হবে। তবে ইভেন্ট ম্যাসেজিংয়ের ব্যবহারের সাথে নির্দিষ্ট ক্রিয়াকলাপের সাথে সেই 5 টি অবজেক্টকে কেবল 5 টি বার্তা পাঠানো হবে। এটি একটি সময় সাশ্রয়ের পদ্ধতির মতো দেখাচ্ছে।

— বুনকাই.সেটেরি

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

— জেমস

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

— বুঙ্কাই.সেটেরি

পর্যবেক্ষক প্যাটার্ন হ'ল ভোট দেওয়ার সাধারণ বিকল্প। en.wikedia.org/wiki/Oserser_ Pattern

— রিকিট

@ হ্যামলিন 11 এই তথ্যটি এখনও মানুষকে সাহায্য করছে খুশি :) নিবন্ধকরণের ক্ষেত্রে, যদি এটি কিছুটা ঘটে তবে মনে রাখবেন আপনি গতির জন্য এটি অপ্টিমাইজ করতে চাইবেন, রেজিস্ট্রেশন সামগ্রীগুলির একটি পুল পাবেন ইত্যাদি ইত্যাদি

— জেমস

Answer 2

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

এবং এটি ঠিক আছে, কারণ আপনি যখন কাজটি শেষ করেছেন তখন আপনার আসলে একটি গেম থাকবে এবং একটি গেমটি বার্তা-পাসিং সিস্টেমের চেয়ে শীতল।

Comments

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

— বুঙ্কাই.সেটেরি

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

— ব্যবহারকারী 441521

Answer 3

আরও ভাল প্রশ্ন হল, বিকল্পগুলি কী কী? পদার্থবিজ্ঞান, এআই ইত্যাদির জন্য যথাযথভাবে বিভক্ত মডিউলগুলি সহ এমন একটি জটিল সিস্টেমে আপনি আর কীভাবে এই সিস্টেমগুলি অর্কেস্টেট করতে পারেন?

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

বার্তাগুলিও আন্তঃসম্পর্কিত যোগাযোগের মাধ্যম হিসাবে একই অর্থে ব্যবহৃত হয়; স্ট্রিম বা পাইপ হ'ল অন্যান্য সাধারণ কৌশল, যাতে পরিবর্তে প্রাথমিক ডেটা আইটেমগুলির ক্রম হিসাবে ডেটা প্রেরণ করা হয় (ভার্চুয়াল সার্কিটের উচ্চ স্তরের সংস্করণ)।

(ইন্টারপ্রেস যোগাযোগ হ'ল অপারেটিং সিস্টেমের পরিবেশের মধ্যে প্রক্রিয়াগুলির (যেমন প্রোগ্রামগুলির চলমান উদাহরণগুলি) মধ্যে যোগাযোগ)

সুতরাং যদি এটি একটি অপারেটিং সিস্টেমের জন্য যথেষ্ট ভাল, এটি সম্ভবত একটি গেমের পক্ষে যথেষ্ট ভাল, তাই না? এছাড়াও অন্যান্য সুবিধাগুলি রয়েছে, তবে আমি বার্তা প্রেরণে উইকিপিডিয়া নিবন্ধটি ব্যাখ্যাটি করব।

আমি স্ট্যাক ওভারফ্লোতেও একটি প্রশ্ন জিজ্ঞাসা করেছি, "কোনও প্রোগ্রামের মধ্যে থাকা বার্তার জন্য ডেটা স্ট্রাকচার?" , যা আপনি পড়তে চাইতে পারেন।

Comments

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

— বুঙ্কাই.সেটেরি

আমাকে এই প্রশ্নটি কিছু সময়ের জন্য উন্মুক্ত রাখতে দিন। এটি বন্ধ করার আগে আমি আরও মতামত সংগ্রহ করতে চাই।

— বুঙ্কাই.সেটেরি

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

— রিকিট

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

— বুঙ্কাই.সেটেরি

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

— deft_code

Answer 4

বার্তাগুলি সাধারণত:

1. বার্তাটি প্রেরণ করা জিনিসটি এটি পেল কিনা তা বিবেচনা করে না।
2. প্রেরকের প্রাপকের কাছ থেকে তাত্ক্ষণিক প্রতিক্রিয়া পাওয়ার দরকার নেই।
3. একক প্রেরকের শোনা একাধিক রিসিভার থাকতে পারে।
4. বার্তাগুলি অবিশ্বাস্যভাবে বা অপ্রত্যাশিতভাবে প্রেরণ করা হবে। (অন্য কথায়, যদি প্রতিটি বস্তুকে প্রতিটি একক ফ্রেমে একটি "আপডেট" বার্তা পাওয়ার প্রয়োজন হয়, বার্তাগুলি সত্যিই আপনাকে বেশি কিনে না))

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

Answer 5

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

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

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

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

Comments

ভাল অতিরিক্ত তথ্যের জন্য +1। হাই, মিস্টার ক্র্যাঙ্কি, ধন্যবাদ আপনি যা বলছেন সে অনুসারে এমনকি মোবাইল গেমসের জন্য ইভেন্ট মেসেজিং সিস্টেমটি বিবেচনা করা ভাল। তবে পরিকল্পনার দিকে নজর দেওয়া উচিত নয় এবং মেসেজিং সিস্টেমটি কোথায় ব্যবহৃত হবে তা খুব ভালভাবে বিবেচনা করা উচিত।

— বুঙ্কাই.সেটেরি

Answer 6

ঠিক আছে, আমি জানি যে এই পোস্টটি বেশ পুরানো, তবে আমি প্রতিরোধ করতে পারিনি।

আমি সম্প্রতি একটি গেম ইঞ্জিন তৈরি করেছি। এটি রেন্ডারিং এবং পদার্থবিজ্ঞানের জন্য 3 ডি পার্টি লাইব্রেরি ব্যবহার করে তবে আমি মূল অংশটি লিখেছি, যা সত্তা এবং গেম যুক্তির সংজ্ঞা দেয় এবং প্রক্রিয়া করে।

ইঞ্জিন অবশ্যই একটি traditionalতিহ্যগত পদ্ধতির অনুসরণ করে। একটি প্রধান আপডেট লুপ রয়েছে যা সমস্ত সত্তার জন্য আপডেট ফাংশনকে কল করে। সংঘর্ষগুলি সরাসরি সংস্থাটিতে কলব্যাকের মাধ্যমে রিপোর্ট করা হয়। সত্তা মধ্যে যোগাযোগ স্মার্ট পয়েন্টার সত্তা সত্তা মধ্যে বিনিময় করা হয়।

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

আদিম বার্তা ব্যবস্থা থাকা সত্ত্বেও আমি বলব যে সিস্টেমটি মূলত "আপডেট লুপ ভিত্তিক"।

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

তবে, আমি আরও মনে করি যে খাঁটি "আপডেট লুপ ভিত্তিক" সিস্টেমের মতো আমারও কিছু সমস্যা আছে।

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

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

Comments

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

— ব্যবহারকারী 441521

Answer 7

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

ইভেন্টগুলির আর একটি বড় সুবিধা হ'ল এগুলি সহজেই কোনও নেটওয়ার্ক বা অন্য পাঠ্য চ্যানেলের মাধ্যমে প্রবাহিত হয়। আপনি পরে প্লেব্যাক জন্য তাদের রেকর্ড করতে পারেন। সম্ভাবনার শেষ নেই.

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

ইভেন্টগুলির সাথে আপনি একটি মার্জিত এবং ডিকোপলড সমাধান পান যা সীমাহীন ধরণের অসীম সংখ্যক অবজেক্টগুলিকে সমর্থন করে যা আপনার ইভেন্টে কিছু ঘটতে পারে কেবল সেই ইভেন্টগুলিতে সাবস্ক্রাইব করতে পারে এবং তাদের জিনিসটি করতে পারে। এজন্য ইভেন্টগুলি দুর্দান্ত।

আরও বিশদ এবং একটি বাস্তবায়ন এখানে ।

Comments

দুর্দান্ত পয়েন্টগুলি যদিও একতরফা। আমি সর্বদা সাধারণতার বিষয়ে সন্দেহ করি: ইভেন্টগুলির জন্য কি অ্যান্টি -ইউজ-কেস রয়েছে?

— আনকো

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

— ব্যবহারকারী 2826084

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

— ব্যবহারকারী 441521

Answer 8

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

• গেম ইঞ্জিনগুলি প্রচুর পরিমাণে ডেটা নিয়ে কাজ করে।
• গেমগুলি দ্রুত হতে হবে (20-30 এফপিএস সর্বনিম্ন হওয়া উচিত)।
• প্রায়শই এটি জেনে রাখা দরকার যে কিছু করা হয়েছে বা কখন করা হয়েছে।

"এটি যথাসম্ভব দক্ষ হতে হবে" এর সাধারণ গেম বিকাশকারী পদ্ধতির সাথে এই জাতীয় বার্তাপ্রেরণ এটি সাধারণ নয়।

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

Comments

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

— ব্যবহারকারী 441521

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

— ইয়ান ইয়ং