গেমম্যানেজার গড অবজেক্টটি কীভাবে এড়ানো যায়?


51

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

প্রথমত, প্রোটোটাইপিং রয়েছে। কেউ দুর্দান্ত কোড লেখার বিষয়ে চিন্তা করে না, আমরা গেমপ্লেটি জুড়েছে কিনা তা দেখার জন্য কেবল কিছু চালানোর চেষ্টা করি।

তারপরে একটি সবুজ আলো আছে, এবং জিনিসগুলি পরিষ্কার করার প্রয়াসে, কেউ লিখেছেন a GameManager। সম্ভবত একগুচ্ছ রাখা GameStates, সম্ভবত কিছু সংরক্ষণ করা GameObjects, বড় কিছু নয় really একটি সুন্দর, ছোট, পরিচালক।

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

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

সেই সময়ে, সাধারণত, এটি GameManagerএকটি আসল বড় জগাখিচুড়ি (ভদ্র থাকার জন্য)।

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

অবশ্যই এটি একটি ধ্রুপদী অ্যান্টি-প্যাটার্ন: গড অবজেক্ট । এটি একটি খারাপ জিনিস, একীভূত হওয়ার জন্য একটি ব্যথা, বজায় রাখতে একটি ব্যথা, বোঝার জন্য একটি ব্যথা, রূপান্তরিত করার জন্য একটি ব্যথা

এটি যাতে না ঘটে তার জন্য আপনি কী পরামর্শ দেবেন?

সম্পাদনা

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


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

@ GameManagerব্র্যান্ডন আমাকে আপনার জন্য আমার প্রশ্নটির পুনঃব্যবস্থাপনা করতে দিন: আমি উপরে বর্ণিত প্রভাবটির নিজেকে প্রকাশ না করে আপনি কীভাবে পুরো গেমটির যুক্তি নিয়ন্ত্রণ করতে পারেন ?
লরেন্ট কুইভিদু

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

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

উত্তর:


23

তারপরে একটি গ্রিনলাইট রয়েছে এবং জিনিসগুলি পরিষ্কার করার প্রয়াসে কেউ গেমম্যানেজার লিখেছেন। সম্ভবত গেমস্টেটের একগুচ্ছ রাখা, সম্ভবত কয়েকটি গেমবজেক্টগুলি সঞ্চয় করা, বড় কিছু নয় really একটি সুন্দর, ছোট, পরিচালক।

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

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

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

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

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

এটি যাতে না ঘটে তার জন্য আপনি কী পরামর্শ দেবেন?

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

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

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

সম্পাদনা করুন - আরও কিছু তথ্য:

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

বিশেষত গেমের বিকাশের জন্য, "বিশেষত গেমের আর্কিটেকচার" টিপস সম্পর্কিত স্ট্যাকওভারফ্লো সম্পর্কে এই প্রশ্নের গৃহীত উত্তর বলে:

অবজেক্ট ওরিয়েন্টেড ডিজাইনের সলিড নীতিগুলি অনুসরণ করুন ....

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

  • আপনি যে কোডগুলি দিন ঠিক সেদিনেই জিনিসগুলি ঠিক করুন।
  • আপনি কয়েক ঘন্টা মধ্যে খুশি হবে।

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

আপনার নির্দিষ্ট উদাহরণের উত্তর দিতে:

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

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


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

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

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

@ লরানকৌ হেহে, এটা ভাল ... সেভাবেই উন্মাদনা রয়েছে :)
ড্যানিয়েল বি

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

7

গেম প্রোগ্রামিংয়ের ক্ষেত্রে এটি আসলে সমস্যা নয়, তবে সাধারণভাবে প্রোগ্রামিংয়ের ক্ষেত্রে।

সমস্ত উত্স কোডটি আসলে গেমটি পরিচালনা করার জন্য এখানে রয়েছে।

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

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

যদিও স্পষ্টতই, আপনি যদি গেমম্যানেজারে জিনিস রাখার জন্য প্রলুব্ধ হন তবে এর অর্থ হ'ল আপনার খুব স্বাস্থ্যকর কোড বেস নেই। দুটি সমস্যা হতে পারে:

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

  • আপনার কোডটি সুগঠিত নয়। আপনি (অ্যাবি) গ্লোবাল ভেরিয়েবল ব্যবহার করছেন, ক্লাসগুলি আলগাভাবে মিলিত হয় না, কোনও ইন্টারফেস নেই, কোন ইভেন্ট সিস্টেম নেই ইত্যাদি।

কোডটি যদি ঠিক মনে হয় তবে প্রতিটি প্রকল্পের জন্য আপনাকে "কী ভুল হয়েছে" মনে রাখতে হবে এবং পরের বার এটি এড়ানো উচিত।

অবশেষে, এটি একটি দল পরিচালনার সমস্যাও হতে পারে: যথেষ্ট সময় ছিল? আপনি যে আর্কিটেকচারটির জন্য যাচ্ছিলেন সে সম্পর্কে কি সবাই জানত? এর মধ্যে "ম্যানেজার" শব্দটি দিয়ে কোন ক্লাসের সাথে কমিট করার অনুমতি কে দিয়েছে?


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

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

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

5

সুতরাং, আরও এন্টারপ্রাইজ-ওয়াই বিশ্ব থেকে একটি সম্ভাব্য সমাধান নিয়ে আসা: আপনি কি নিয়ন্ত্রণ / নির্ভরতা ইনজেকশনটির বিপরীতটি পরীক্ষা করে দেখেছেন?

মূলত, আপনি এই ফ্রেমওয়ার্কটি পান যা আপনার গেমের সমস্ত কিছুর জন্য ধারক। এটি এবং কেবল এটিই জানে যে কীভাবে সমস্ত কিছু একসাথে তারে করা যায় এবং আপনার বস্তুর মধ্যে সম্পর্কগুলি কী the আপনার কোনও বস্তু তাদের নিজস্ব নির্মাণকারীর ভিতরে কিছু ইনস্ট্যান্ট করে না। তাদের যা প্রয়োজন তা তৈরি করার পরিবর্তে তারা আইওসি কাঠামো থেকে তাদের যা চান তা জিজ্ঞাসা করেন; তৈরির পরে, IoC কাঠামো নির্ভর করে সন্তুষ্ট করতে কোন বস্তুর প্রয়োজন এবং এটি পূরণ করে "" জানেন "। আলগা সংযুক্ত FTW।

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

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

বাস্তবতাত্ত্বিকভাবে, আপনার জন্য এটি করার জন্য আপনার এই বিগুওহোমাইগোড কাঠামোর দরকার নেই: আপনি এটির গুরুত্বপূর্ণ বিটগুলি নিজেই করতে পারেন। মুল বক্তব্যটি হ'ল যদি আপনি নিজেকে ম্যানেজার টাইপ অবজেক্টগুলি তৈরি করতে দেখেন তবে সম্ভাবনাগুলি হ'ল, আপনি আপনার ক্লাসগুলির মধ্যে সঠিকভাবে আপনার দায়িত্বগুলি বিতরণ করছেন না বা কোথাও কোনও ক্লাস মিস করছেন missing


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

আইওসি, আমরা কি একে একে সাধারণ জ্ঞান বলার জন্য ব্যবহার করি নি?
brice 22

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

3

অতীতে, আমি সাধারণত generallyশ্বর শ্রেণীর সাথে শেষ করি যদি আমি নিম্নলিখিতগুলি করি:

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

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


1

আমি জানি এই প্রশ্নটি এখন পুরানো, তবে আমি ভেবেছিলাম আমার 2 সেন্ট যোগ করব।

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

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

সংক্ষেপে, আমি অন্য শ্রেণীর ব্যবহারকে অর্কেস্ট্রেট করার জন্য একটি অর্ধ-godশ্বরের মতো বস্তু ব্যবহার করি।


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