এমভিসি এবং টিডিডি কেন গেম আর্কিটেকচারে বেশি নিয়োগ হয় না? [বন্ধ]

155

আমি এই বলে এই বিষয়টির উপস্থাপনা করব যে আমি প্রচুর গেমের উত্স দেখিনি, গেমসের পথে খুব বেশি কিছু তৈরি করি নি।

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

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

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

ভুল # 4: একটি গেম নয়, একটি সিস্টেম তৈরি করা

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

একটি মার্জিত গেম উপাদান উপাদান লিখবেন না, সম্পাদককে পুরোপুরি এড়িয়ে যান এবং কোডটিতে রাজ্যটিকে শক্ত করুন, ডেটা-চালিত, স্ব-পার্সিং, এক্সএমএল উন্মাদনা এড়ান এবং জঘন্য জিনিসটি কোড করুন।

... যত তাড়াতাড়ি সম্ভব পর্দায় জিনিসগুলি পান।

এবং কখনও কখনও কখনও যুক্তিটি ব্যবহার করবেন না "যদি আমরা কিছু অতিরিক্ত সময় নিই এবং এটি সঠিকভাবে করি তবে আমরা গেমটিতে এটি পুনরায় ব্যবহার করতে পারি"। কখনোই না।

এটি কি কারণ গেমগুলি (বেশিরভাগ) দৃষ্টিভঙ্গিযুক্ত তাই এটি বিবেচনা করে যে কোডটি ভারী হয়ে উঠবে এইভাবে, মডেলগুলি / নিয়ন্ত্রণকারীগুলিতে স্টাফগুলি সরানো থেকে কোনও সুবিধা মোটামুটি ন্যূনতম, তবে কেন বিরক্ত করবেন?

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

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

সম্ভবত আমি কেবল ভুল উত্স কোডটি দেখছি, তবে কেন আমরা গেম ডিজাইনে নিযুক্ত এই 'এন্টারপ্রাইজ' অনুশীলনগুলিকে বেশি দেখি না? গেমগুলি কি তাদের প্রয়োজনীয়তার তুলনায় সত্যিই আলাদা, বা কোনও লোক / সংস্কৃতির সমস্যা (যেমন গেম ডেভস একটি ভিন্ন পটভূমি থেকে আসে এবং এভাবে কোডিংয়ের বিভিন্ন অভ্যাস থাকে)?

architecture design-patterns project-management

— timoxley
সূত্র

137

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

প্রোটোটাইপ এবং পুনরাবৃত্তি আরও ভাল কাজ করতে থাকে। শেষ পর্যন্ত, একটি দুর্দান্ত নকশা এটি থেকে বেরিয়ে আসতে পারে তবে প্রায়শই আরও সাধারণ এবং পরিশ্রুত কিছু এ থেকে আসে। KISS এবং YAGNI মাথায় আসে।

আমি ব্যক্তিগতভাবে বিশ্বাস করি যে ভারসাম্য থাকা দরকার। যদি আপনার গেমের মূল মেকানিক থাকে তবে এটিতে কাজ করুন। আপনার এখনও পুনরাবৃত্তি করতে হবে তবে আপনাকে এটি পরিমার্জন করতে হবে। ইঙ্গিত: আপনার কোডের সংগঠন আপনার গেমের মূল মেকানিক নয়।

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

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

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

আমি মনে করি এটি জ্ঞান এবং অনুশীলনেরও কেবল একটি সাধারণ অভাব। আমি মনে করি না যে টিডিডি অন্যান্য ক্ষেত্রেও প্রচলিত আছে, তবে চতুর বিকাশের মতো, আমি মনে করি এটি ছড়িয়ে পড়েছে। আপনি বলতে পারেন যে এটি তার সময়ের আগে (বা সম্ভবত না, যেমনটি এখন থেকে বছরের পর বছর হতে পারে)। টিডিডির চেয়ে বেশি গুরুত্বপূর্ণ হ'ল "আরডিডি" - প্রয়োজনীয়তা চালিত বিকাশ। _{আমি সবেমাত্র তৈরি করেছি}তোমার লক্ষ্য কি? একটি খেলা করতে। আর সব কিছু পরে আসে। আপনি যদি প্রমাণ করতে পারেন যে টিডিডি উত্পাদনশীলতা বৃদ্ধি করে এবং দলগুলিকে সময়সীমাতে পৌঁছে দিতে সহায়তা করে, তবে আপনি কি ভাবেন না যে সবাই এটি ব্যবহার করবে? এবং সম্ভবত এটি ক্ষেত্রে। তবে এখনই, আমাদের শিল্পটি আগের তুলনায় আরও বেশি প্রতিযোগিতামূলক, আরও কঠিন এবং তাড়াতাড়ি শেষ সময়সীমা রয়েছে এবং স্টাফগুলিকে কেবল কাজ করা দরকার। নির্মাণ শ্রমিকরা প্রথমে ভারা তৈরি করে না; তারা একটি ভিত্তি স্থাপন করে, তারপরে তারা কিছু দেয়াল এবং মেঝে বাড়ায় এবং কেবল তখনই তারা নির্দিষ্ট কাজগুলি করতে স্ক্যাফোল্ডিংয়ের বেছে বেছে বিট তৈরি করে যা ভাস্কর্যটি আরও সুবিধাজনক করে তোলে। আমি মনে করি এটিই সফ্টওয়্যার বিকাশের ক্ষেত্রে প্রযোজ্য।

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

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

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

— Ricket
সূত্র

32

কমপক্ষে আপনার প্রশ্নের এমভিসি অংশ সম্পর্কিত, এসও সম্পর্কিত অনুরূপ প্রশ্নের আমার মূল উত্তরটি এখানে :

এটি গেমগুলিতে খুব কমই ব্যবহৃত হয়। এটি বুঝতে আমার কিছুটা সময় লেগেছে তবে এখানে আমার চিন্তাভাবনাগুলি:

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

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

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

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

পরিবর্তে, গেমগুলি ডোমেনের সীমানা বরাবর জিনিসগুলি ডিকুয়াল করার ঝোঁক দেয়: এআই, পদার্থবিজ্ঞান, অডিও, রেন্ডারিং ইত্যাদি যথাসম্ভব পৃথক রাখা হবে।

— উপুড়হস্ত
সূত্র

20

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

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

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

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

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

— জ্যাসপার বেকারস
সূত্র

13

এমভিসি এবং টিডিডি কেন গেম আর্কিটেকচারে বেশি নিয়োগ হয় না?

সতর্কতা: সামনে মতামত।

এমভিসি ব্যবহার করা হয়নি (অনেক) কারণ:

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

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

টিডিডি ব্যবহার করা হয়নি (অনেক) কারণ:

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

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

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

— Kylotan
সূত্র

9

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

আপনি যে উপাদানটির মডেলটি দেখেছেন যেমন ইউনিটি 3 ডি গেম কোডটি সাজানোর সেরা উপায়।

— আয়ান
সূত্র

4

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

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

3

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

আমার ব্যক্তিগত গেম প্রকল্পগুলিতে, আমি কোড মন্তব্য করার চেষ্টা করি বা কমপক্ষে এটি পাঠযোগ্য করে তোলার চেষ্টা করি এবং আমি এমন একসাথে এমন সিস্টেমে ছুঁড়ে ফেলেছি যা পরে যতটা সম্ভব (অর্থাৎ সাধারণতা) আরও কিছুটা নমনীয়তা দেয় তবে দিনের শেষে, যদি আপনি আপনার খেলাটিকে এগিয়ে নিয়ে যাননি এটি খুব ভাল লাগে না।

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

— Deleter
সূত্র

2

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

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

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

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

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

— ড্যাশ-হুলো ঠুং
সূত্র