এমভিসি (মডেল-ভিউ-কন্ট্রোলার) গেম ইঞ্জিন আর্কিটেকচার - হ্যাঁ বা না? [বন্ধ]

Question

আমি একটি দুর্দান্ত বই, গেম কোডিং কমপ্লিট পড়ছি , এবং সেই বইটি তিনটি মূল স্তর সহ এমভিসি (মডেল-ভিউ-কন্ট্রোলার) পদ্ধতির ব্যবহারের জন্য দৃs়ভাবে সুপারিশ করেছে :

1. গেম অ্যাপ্লিকেশন স্তর
2. খেলা লজিক
3. খেলা দেখুন

আমার কাছে, এই পদ্ধতিটি মোবাইল কম্পিউটার গেমের জন্য ওভারকিলের মতো দেখাচ্ছে।

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

Comments

-১ এবং ভোট বন্ধ করুন। গেমসগুলিতে এমভিসি সম্পর্কে বলার মতো সমস্ত কিছুই গেমদেব.স্ট্যাকেক্সেঞ্জার / কুইকশানস / 3426 /… এ বলা হয়েছিল , এবং এখন পর্যন্ত আমরা এখানে যা পেয়েছি তা হ'ল আবর্জনা।

@Joe Wreschnig যে বেশ কঠোর, কিন্তু আমি সত্য অনুমান ...

— স্পুকস

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

@ জো: ওহ, ধন্যবাদ :) OOP ব্যয়বহুল এই যুক্তি কিছুটা মনকে উদ্রেক করে। আমি মনে করি কিছু স্ট্যান্ডার্ড দ্বারা আমাদের আমার পুনরুক্তার মতো পয়েন্টের প্রয়োজন হবে না , তবে নুবগুলি ঘটে এবং তাই বিতর্কিত নকল প্রশ্নগুলি করা do এটি আমার মতো সাইটে লেটকমারদের লেট ফাংশনটিও পরিবেশন করে, ক্রিয়াকলাপটি ব্যাপকভাবে মারা যাওয়ার পরেও সামান্য কিছুটা প্রতিনিধিত্ব করে ra :) আমি বলতে চাইছি, অভিশাপ, আমার কাছে 40K রেপ আছে, তবে এখানে আমি একটি ট্যাগ উইকিও সম্পাদনা করতে পারি না।

— বিশৃঙ্খলা

Answer 1

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

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

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

Comments

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

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

উত্তম উত্তর, এটিতে +1 .. থিওরিটি সমস্ত ভাল এবং ভাল তবে এটি যদি আপনি কেবল এটি সম্পন্ন না করেন তবে গেমগুলি শিপিংয়ের কারণ হতে পারে।

— জেমস

@ বুঙ্কাই.সেটেরি: এটি বিমূর্ততা যুক্ত করে এবং আইএমও এটি কার্যকর অ্যাস্ট্রাকশন যা তার অর্থ প্রদান করে। আমি কি আপনার শেষ বক্তব্যের সঙ্গে একমত, শোধন যে সঙ্গে নেই ব্যয়ে, এবং যে আমি মনে করি না আপনি এটি সম্পর্কে চিন্তা করতে হবে।

— বিশৃঙ্খলা

Answer 2

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

অনেকগুলি আধুনিক গেমগুলি প্রকৃতপক্ষে পৃথক থ্রেডগুলিতে মডেলগুলি এবং ভিউগুলি চালায় এবং বেশিরভাগ প্ল্যাটফর্মগুলিতে দুর্দান্ত পারফরম্যান্স সুবিধা অর্জন করে।

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

সম্পাদনা: সংকলন-সময় ডিজাইনগুলি সিপিইউ শক্তি গ্রহণ করে না। উত্তরাধিকারের মতো রান-টাইম ডিজাইনগুলি স্পষ্টতই করে।

Comments

-1। এমভিসি হ'ল একটি নকশা সময় সিদ্ধান্ত। উত্তরাধিকার হ'ল একটি নকশা-সময়ের সিদ্ধান্ত। উভয়ই সংকলন-সময় এবং রান-টাইমের আগে ঘটে। উভয়েরই পারফরম্যান্সে বড় প্রভাব রয়েছে। ইনলাইনিং সবসময় কোড দ্রুত করে না। আপনার থ্রেডিং প্রস্তাবটি অবিশ্বাস্যভাবে নিষ্পাপ। কিছুই বিনামূল্যে।

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

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

Answer 3

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

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

অন্যদিকে, নিশ্চিত করুন যে কোনও গেমটি আসলে শেষ হয়েছে এবং "ইঞ্জিন" তে কাজ করার জন্য এতটা সময় ব্যয় করবেন না যে এটি কখনই না হয়ে যায়।

আরও তথ্যের জন্য, দয়া করে প্রশ্নটি পড়ুন "গেমের আর্কিটেকচারে এমভিসি এবং টিডিডি কেন বেশি নিয়োগ হয় না?" এবং আমার সত্যিই দীর্ঘ উত্তর।

Comments

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

— ডেড এমজি

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

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

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

— রিকিট

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

— কাইলোটান