এক্সএনএ-তে গেম 1 স্থিতি রাখা কি খারাপ ধারণা?


10

আমার Game1ক্লাসটি স্থির হিসাবে রাখা কি খুব খারাপ ধারণা ? আমার Game1ক্লাসের এই মুহুর্তের মতোই আমার কাছে একটি ক্লাস বলা হয়েছে TileHandlerযা আমার বর্তমান টাইলসের সেটগুলির সাথে সবকিছু পরিচালনা করে এবং AnimalHandlerযা আমার সমস্ত প্রাণীকে (আশ্চর্যরূপে) পরিচালনা করে।

এখন যদি আমি প্রবেশ করি এবং AnimalHandlerযদি কোনও টাইল হাঁটতে পারা যায় কিনা তা পরীক্ষা করতে চান TileHandlerযা সমস্যার সৃষ্টি করে বা আমাকে হাঁটার যোগ্য টাইলগুলির একটি তালিকা দিতে হবে AnimalHandler, যা আমি না করেই করব।

কী সহজ হবে তা Game1স্থির করা এবং তারপরে AnimalHandlerকেবল যেতে হবে Game1._tileHandler.WalkableTile(position)

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

উত্তর:


9

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

আপনার যখন একটি চকচকে নতুন হাতুড়ি থাকবে তখন প্রতিটি সমস্যা পেরেকের মতো দেখায়।

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

আপনার ইস্যুটির জটিলতা এখানে:

... যদি আমি ভিতরে থাকি এবং AnimalHandlerযদি টাইলটি হাঁটতে পারা যায় TileHandlerতবে তা পরীক্ষা করতে চাইলে সমস্যা দেখা দেয় বা আমাকে হাঁটার যোগ্য টাইলগুলির একটি তালিকা দিতে হবে AnimalHandler, যা আমি না করেই করব।

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

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


আমেন! আপনি একটি দুর্দান্ত পয়েন্ট স্পর্শ করুন আমি আমার উত্তরে সত্যিই কথা বলিনি।
নাট

নির্ভরতাগুলি গোপন করা এবং বিশ্বব্যাপী রাষ্ট্র প্রবর্তন করা +1 সত্যিই এখানে সমস্যা
ashes999

4

স্থির প্রসঙ্গে টাইলহ্যান্ডলারকে কল করা সর্বোত্তম সম্ভাব্য নকশা নয়, এটি হ'ল এটি আপনার নকশার এমন উপাদানগুলিকে মিলিত করে যা অন্যথায় ডিকপলড হতে পারে।

আপনি যদি ভবিষ্যতে একাধিক টাইলহ্যান্ডলার রাখেন, তবে এই পরিবর্তনটি সামঞ্জস্য করার জন্য আপনাকে অনেক কাজ করতে হবে।

আপনি যদি টাইলহ্যান্ডলার অপসারণ করতে চান তবে এই পরিবর্তনটি সামঞ্জস্য করার জন্য আপনাকে প্রচুর কাজ করতে হবে।

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

যদি টাইলহ্যান্ডলারটি এটি ব্যবহার করে এমন বস্তুর পরামিতি হিসাবে পাস করা হয়, তবে আপনি পরের বারে কেবল অন্যরকম পাস করতে পারেন, বা পরে এটি ব্যবহার করা অবজেক্টগুলিতে একটি আলাদা টাইল হ্যান্ডলার সেট করতে পারেন।

ব্যক্তিগতভাবে, আমি আমার এক্সএনএ গেমসের অনেকগুলি অবিচল প্রসঙ্গ থেকে অ্যাক্সেস করি এবং ধরে নিই যে এর সাথে আমার আর কোনওটির বেশি হবে না।

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

সংক্ষেপে:

স্থির প্রসঙ্গ ব্যবহার না করার পক্ষে:

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

স্থির প্রসঙ্গে:

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


2

আমি এটি একটি সহজ খেলা একটি সুপার খারাপ ধারণা মনে করি না, কিন্তু আপনি কটাক্ষপাত থাকতে পারে http://www.nuclex.org/articles/4-architecture/6-game-components-and-game-services জন্য আন্তঃসংযোগমূলক গেমের উপাদানগুলি কীভাবে তৈরি করা যায় সে সম্পর্কে আরও ভাল ধারণা


যদি আপনি এটি কেবল একটি সহজ খেলা না হয়ে থাকেন তবে কোনও সমস্যার কথা ভাবতে পারেন?
হ্যারল্ড

কোড পাঠযোগ্যতা, পরীক্ষাযোগ্যতা এবং ভাল আর্কিটেকচার অনুশীলনগুলি এড়াতে পরামর্শ দেবে।
smnbss

2

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

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

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


0

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

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

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


0

হ্যাঁ, এটি সর্বদা একটি খারাপ ধারণা।

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

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

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

  3. এটি নির্ভরতা লুকায়। অনেকটা পরিষেবা সরবরাহকারী অ্যান্টি-প্যাটার্নের মতো (এছাড়াও এক্সএনএ, গেম.স সার্ভিসেস নিযুক্ত) আপনার ক্লাসগুলি নির্ভরতাগুলি বেছে নিতে পারে যা আপনি বাইরে দেখেন না।

এই পন্থাটি বিশেষত বিষাক্ত হয়ে ওঠে যদি কেউ ফ্রেট ট্রেন কলগুলির সাথে স্ট্যাটিক ক্লাসগুলি একত্রিত করে (জিনিসগুলি ike Game.Instance.ActorManager.Enemies.FindInRange(10)- যা ট্রেনের গাড়ির মতো শৃঙ্খলাযুক্ত প্রতীকগুলির কারণে বলা হয়), যেখানে উপাদানগুলি হঠাৎ করে কেবল একটি Gameশ্রেণির প্রয়োজন হয় না , তবে স্থিতিশীল Instanceসম্পত্তিযুক্ত একটি যা এর সাথে কিছু ফিরিয়ে দেয় with একটি ActorManagerসম্পত্তি যা একটি Enemiesসম্পত্তি আছে যে একটি FindInRange()পদ্ধতি সঙ্গে একটি বস্তু ফেরত ।

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

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