প্রতি ফ্রেম ফাংশন গেম ডিজাইনে ইভেন্ট বনাম মেসেজিং বনাম কল


11

ঐতিহ্যগত খেলা নকশা , আমি জানি, ব্যবহার পলিমরফিজম এবং ভার্চুয়াল ফাংশন আপডেটের খেলা রাজ্যের বস্তু। অন্য কথায়, একই ভার্চুয়াল ফাংশনগুলিকে গেমের প্রতিটি বস্তুর নিয়মিত (প্রাক্তন: প্রতি ফ্রেম) বিরতিতে ডাকা হয়।

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

ইভেন্ট ড্রাইভড গেম আর্কিটেকচারটি ভালভাবে বর্ণিত হয়েছে: মাইক ম্যাকশ্যাফ্রি দ্বারা গেম কোডিং সম্পূর্ণ

আমি কি দয়া করে নিম্নলিখিত প্রশ্নগুলির সাহায্যের জন্য জিজ্ঞাসা করতে পারি:

  • উভয় পদ্ধতির সুবিধা এবং অসুবিধাগুলি কী?
  • একজনের চেয়ে অপরটির চেয়ে ভাল কোথায়?
  • ইভেন্টটি চালিত গেমের নকশা সর্বজনীন এবং সব ক্ষেত্রেই আরও ভাল? সুতরাং এটি এমনকি মম্বাইল প্ল্যাটফর্মগুলিতে ব্যবহারের জন্য সুপারিশ করা হয়?
  • কোনটি আরও দক্ষ এবং কোনটি বিকাশ করা আরও কঠিন?

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


উদাহরণ: এই প্রশ্নটি এখানে কিছুটা বিতর্ক সৃষ্টি করেছিল, তাই আমি আপনাকে উদাহরণটি দেই: এমভিসি অনুসারে, গেম ইঞ্জিনটি মূলত তিনটি ভাগে বিভক্ত:

  1. অ্যাপ্লিকেশন স্তর (হার্ডওয়্যার এবং ওএস যোগাযোগ)
  2. খেলা লজিক
  3. খেলা দেখুন

একটি রেসিং গেমে, গেম ভিউ কমপক্ষে 30fps, যত তাড়াতাড়ি সম্ভব স্ক্রিনটি সরবরাহ করার জন্য দায়বদ্ধ। গেম ভিউ প্লেয়ারের ইনপুটটির জন্যও শোনে। এখন এটি ঘটে:

  • প্লেয়ারটি জ্বালানীর প্যাডেল 80% চাপায়
  • গেমভিউ একটি বার্তা তৈরি করে "গাড়ী 2 ফুয়েল পেডাল 80% চাপ দেওয়া" এবং এটি গেম লজিকে প্রেরণ করে।
  • গেম লজিক এই বার্তাটি পেয়েছে, নতুন গাড়ির অবস্থান এবং আচরণটি মূল্যায়ন করে, গণনা করে এবং গেমভিউয়ের জন্য নিম্নলিখিত বার্তাগুলি তৈরি করে: "গাড়ি 2 ফুয়েল প্যাডাল চাপুন 80%", "গাড়ী 2 শব্দ ত্বরণ", "গাড়ী 2 স্থানাঙ্ক এক্স, ওয়াই" .. ।
  • গেমভিউ বার্তাগুলি গ্রহণ করে এবং সে অনুযায়ী তাদের প্রক্রিয়া করে

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

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

5
হতে পারে আমি বোবা হয়ে যাচ্ছি, তবে পলিমারফিজমটি ব্যবহার না করে আপনি কীভাবে কোনও মেসেজিং সিস্টেমকে কাজ করতে যাচ্ছেন ? আপনার ইভেন্টের রিসিভার ইন্টারফেসটি সংজ্ঞায়িত করার জন্য আপনার কি কোনও ধরণের বেস ক্লাস (বিমূর্ত বা অন্যথায়) দরকার নেই? (সম্পাদনা: ধরে নিচ্ছেন যে আপনি কোনও প্রতিচ্ছবি সহ কোনও ভাষায় কাজ করছেন না))
তেত্রাদ

2
এছাড়াও, দক্ষতা প্রয়োগের বিশদ সাথে অত্যন্ত আবদ্ধ হতে চলেছে। আমি মনে করি না "কোনটি আরও দক্ষ" এটি এমন একটি প্রশ্ন যা এর বর্তমান আকারে উত্তর দেওয়া যেতে পারে।
টেট্রাড

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

উত্তর:


8

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

উভয় পদ্ধতির সুবিধা এবং অসুবিধাগুলি কী?

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

একজনের চেয়ে অপরটির চেয়ে ভাল কোথায়?

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

ইভেন্টটি চালিত গেমের নকশা সর্বজনীন এবং সব ক্ষেত্রেই আরও ভাল? সুতরাং এটি এমনকি মোবাইল প্ল্যাটফর্মগুলিতে ব্যবহারের জন্য সুপারিশ করা হয়?

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

কোনটি আরও দক্ষ এবং কোনটি বিকাশ করা আরও কঠিন?

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


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

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

7

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

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

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

নীচের লাইন: এর চেয়ে ভালতর কোনও কৌশল নেই, না এগুলি একচেটিয়াও।


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

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

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

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

1
যদি আপনি দ্বিতীয় সংস্করণটি পেয়ে থাকেন তবে প্রধান লুপটি নিয়ন্ত্রণ করা নামক অধ্যায়টি দেখুন। তৃতীয় সংস্করণে এটি একই জিনিসটির নামকরণ করা উচিত। এটি সত্যই আপনার প্রশ্নের উত্তর দেওয়া উচিত।
রায় দে

4

এটি বমজ্যাকের উত্তরের মন্তব্য হিসাবে শুরু হয়েছিল, তবে দীর্ঘ হয়েছে।

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

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

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

এগুলি দুর্দান্ত সরঞ্জাম, তবে বামমজ্যাকের মতো বলেছে যে, বহুবর্ষ এবং ইভেন্টগুলি একই সমস্যাটিকে সমাধান করে এমনটি ধরে নিবেন না।


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

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

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

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

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

2

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

যাইহোক, আমি আমার অবজেক্ট ম্যানেজমেন্ট অবজেক্টগুলিতে বা আমার ব্যবহারকারীর ইনপুট অবজেক্টগুলিতে বা এর মতো কিছুতে প্রতিটি ফ্রেমকে কল করি না। ফ্রেমের প্রতিটি বস্তুর কাছে ভর ভার্চুয়াল কলগুলি একটি ভয়ানক ধারণা।

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

আমার প্রথম বাক্যে আরও স্পষ্ট হতে সম্পাদিত।


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

@ বুঙ্কাই: সুতরাং আপনার কাছে এমন কিছু ডিজাইন রয়েছে যা ইভেন্ট-চালিত এবং কিছু ডিজাইন যা প্রতিটি ফ্রেম বলে। এটি আমার উত্তরটির সাথে বেশ সম্মত।
ডেড এমজি

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