এটি হার্ড-কোড সামগ্রীতে কেন খারাপ?


41

আমি বেশিরভাগ গেমগুলিতে ফাইলগুলিতে সংলাপের পাঠ্য জানি, তবে আমি কয়েকটি টেক্সট-ভিত্তিক গেমসও আসলে খেলার কোডটিতে সামগ্রী (মানচিত্র, পছন্দগুলি, সম্ভাব্য প্লেয়ার কমান্ড, গল্পের পাঠ্য) প্রোগ্রাম করে।

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

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

কিছু গেম এমনকি কোডের মধ্যে গ্রাফিকগুলি (ASCII আর্ট?) ধরে রাখে। আমি জানি এটি সঠিক নয় এবং আমি এটি খারাপ হওয়ার কয়েকটি কারণ অনুমান করতে পারি, তবে এর প্রধান কারণটিও জানি না।

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

আমি প্রাথমিকভাবে জিজ্ঞাসা করি কারণ এক্সএমএল ফাইলগুলি তৈরি, পার্স করা, এবং কাজ করা পিএটিএর কিছুটা। আপনি জানেন ... প্রতিটি অনন্য অন্ধকার (বিষয়বস্তু) এর নিজস্ব শ্রেণি তৈরির অলস বিকল্পের সাথে তুলনা করুন।


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

7
উত্সে এম্বেড থাকা সামগ্রীতে আই 18 এন করা খুব কঠিন হবে।
প্লিজ

5
এটি গেম ডেভেলপমেন্ট নির্দিষ্ট কিনা তা নিশ্চিত নয় sure ভবিষ্যতে প্রোগ্রামারগুলিতে এসই বা স্ট্যাকওভারফ্লো সম্পর্কে জিজ্ঞাসা করুন।
MichaelHouse

13
just making every unique dungeon (content) its own class.এটি আমাকে কাঁপিয়ে তুলেছিল। যুক্তি থেকে ডেটা পৃথক করা আমার কাছে এমন একটি মৌলিক নীতি যা আমি অবাক হয়েছি এখনও সেখানে বিকাশকারীরা এটি লঙ্ঘন করছে।
লিলিয়ান্থাল

4
আপনি যা সিদ্ধান্ত নিন না কেন, হার্ডকোডিং সামগ্রীটি আরও অনেক বিশেষ ক্ষেত্রে মঞ্জুরি দেয় realize একটি নির্দিষ্ট বসকে কেবল মধ্যরাত এবং 7 টা (আসল সময়) এর মধ্যে উপস্থিত হতে চান? দানবদের নির্দিষ্ট সময়ে প্রদর্শিত হওয়ার জন্য জেনেরিক উপায় তৈরি করার চেয়ে হার্ডকোড করা অনেক সহজ।
ব্যবহারকারী 253751

উত্তর:


85

যে জন্য বেশ কয়েকটি কারণ আছে। আমি কেবল কয়েকটিকে স্পর্শ করব:

  1. এটি আপনার উত্স কোডটিকে জগাখিচুড়ি করে তোলে। আপনার যদি প্রচুর সংলাপ (গাছ) থাকে তবে আপনার কোডবেসের একটি বিশাল অংশটি কেবলমাত্র পাঠ্য যা আপনার আসল গেম কোডের সাথে কোনও সম্পর্ক রাখে না।
  2. আপনি যখনই একক চরিত্রের মতো এত বেশি পরিবর্তন করেন তখন প্রতিবারই আপনার পুনরায় সংকলন করতে হবে।
  3. ডায়ালগটি নিজেই নেভিগেট করা শক্ত। আমি পুরো ডায়লগ ট্রি প্রয়োগ করার চেষ্টা করেছি বলে মনে করি, আপনার উত্সের অভ্যন্তরে পুরোপুরি বেশ কয়েকটি ছেড়ে দিন, ফলে স্প্যাগেটি এবং নেস্টেড ifএস, switchএস ইত্যাদির নেস্ট গণ্ডগোল হবে। এরপরে কোডের ফলাফল যা ত্রুটিযুক্ত, পড়ার পক্ষে শক্ত এবং ডিবাগ করা শক্ত hard
  4. যদি আপনি আপনার গেমটি মোড বা প্রসারিত করতে লোককে সক্ষম করতে চান তবে তাদের যদি কিছু পরিবর্তন করার জন্য উত্স কোডটি ব্যবহার না করতে হয় তবে তা অনেক সহজ।
  5. উপরোক্ত বিষয়গুলি আরও গুরুত্বপূর্ণ যদি আপনি একটি দলে কাজ করেন। আপনি চান না যে আপনার লেখককে কোডটির সাথে গোলমাল করতে হবে কেবল একটি ডায়ালগের টুকরো প্রবেশ করার জন্য।
  6. আপনি যদি বিদ্যমান লাইব্রেরিগুলি ব্যবহার করেন তবে এক্সএমএল বা অন্যান্য স্ট্যান্ডার্ড ফাইল ফর্ম্যাটগুলি পার্সিং করা বেশ সহজ কাজ, সুতরাং আপনাকে প্রচুর সুবিধা দেওয়ার সময় এবং উপরে উল্লিখিত সমস্যাগুলি এবং আরও অনেক কিছু এড়ানোতে সেভাবে এটি প্রয়োগের ব্যয় খুব কম is
  7. @ মাইলোপ্রিস নীচের দিকে ইঙ্গিত করেছেন, আপনার পাঠ্য বাহ্যিক ফাইলগুলিতে থাকলে গেমটি স্থানীয়করণ করা আরও সহজ। আপনি একটি ফাইল যুক্ত করে একটি ভাষা যুক্ত করতে পারেন, আপনার দল উত্সটি স্পর্শ না করেই অনুবাদটি যত্ন নিতে পারে (এটি বিশেষত গুরুত্বপূর্ণ যদি আপনি এমন লোককে অনুবাদ করতে দেন যাঁদের আপনার কোডের সবকটি দেখতে না লাগে - মনে করুন ফ্রিল্যান্সাররা, লোকেরা আপনার টিমের সাথে সম্পর্কিত নয় এমন সম্প্রদায় ইত্যাদি)।

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

28
স্থানীয়করণ / অনুবাদে সহজেই আরেকটি বড় সুবিধা।
মিলো পি

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

2
ব্যক্তিগতভাবে আমি এখানে গণ্য একই কারণে আরও শক্তিশালী পদ্ধতির পক্ষে: আপনার কোডের বেশিরভাগটি একটি স্ক্রিপ্টিং ভাষায়ও সরান। সি / সি ++ এ একটি কোর তৈরি করুন, পাইথন বা লুয়ার মতো একটি ভাষা এম্বেড করুন এবং এটিতে একটি API রফতানি করুন। Don't Starveএই পদ্ধতির অনুসরণ করে এবং এটি আমি দেখেছি সেরা-লিখিত গেমগুলির মধ্যে একটি। অতীতে এবং বর্তমানের অন্যান্য অসংখ্য গেমও এটি করে, পাশাপাশি অ্যাপ্লিকেশনগুলি (এবং খুব কমই ইউটিলিটিস)। আমি বলব যে সামগ্রিকভাবে, ছোট প্রকল্পগুলি এবং ক্ষুদ্র উপযোগের বাইরে ভারী লেয়ারিং এবং বিচ্ছিন্নতা সর্বদা আপনার বন্ধু।
mechalynx

3
আড্ডায় এই আলোচনা চালিয়ে যান দয়া করে ।
জোশ

30

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

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

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

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

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

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


আমি মনে করি না যে সংকলনের সময়গুলি সত্যই গুরুত্বপূর্ণ তবে বিকাশকারী হিসাবে আমরা সবসময় "ঝরঝরে কোড" এর জন্য চেষ্টা করি ... জিনিসগুলিকে নিজের অধিকারে আলাদা করার এটি বেশ ভাল কারণ ... বিষয়বস্তু কোডের নয় বিষয়বস্তু হওয়া উচিত!
যুদ্ধ 21

4
@ ওয়ার্ডি সংকলনের সময়গুলি সি ++ এ সত্যই গুরুত্বপূর্ণ। প্রকল্পগুলির আকার, টেমপ্লেটের আক্রমণাত্মক ব্যবহার বা এমনকি বিকাশকারী অলসতার কারণে (অপ্রয়োজনীয় শিরোনাম সহ) তৈরি করতে আমি 15 মিনিটেরও বেশি সময় নিয়ে এমন সমাধান নিয়ে কাজ করেছি। এবং আমি নিশ্চিত যে এটি বিশাল বাণিজ্যিক গেমগুলির ক্ষেত্রে।
ধারণাগুলি

1
@ ধারণাগুলি 3 ডি: আমি আশা করি আমার প্রকল্পটি 15 মিনিটের মতো হবে। ডেডিকেটেড বিল্ড সার্ভারে একটি পরিষ্কার বিল্ড লাগে ~ 50 মিনিট।
হাঁসকে 14

সোর্স কোডে অল্প অ্যাক্সেস প্রাপ্ত লোকের সংখ্যা, সি ++ এর কারণে মস্তিষ্কের ক্ষতির সংখ্যা কম হবে people : পি
সার্জে বোর্স

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

7

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

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

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

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

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

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

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


7
"তবে মনে রাখবেন যে আপনার তৈরি বিমূর্তির প্রতিটি স্তর আপনার প্রোগ্রামকে আরও জটিল এবং বুঝতে আরও কঠিন করে তুলবে" " আমার একমত হতে হবে, বিমূর্ততা একটি প্রোগ্রামকে আরও সহজ করে তুলতে পারে এবং অবশ্যই এটি বুঝতে সহজ হওয়া উচিত easier
এনপিএসএফ 3000

1
@ এনপিএসএফ 3000 বিমূর্ততা জটিলতা যুক্ত করবে তবে তারা যুক্ত করার চেয়ে আরও জটিলতা সরিয়ে ফেলতে পারে
ব্যবহারকারী 253751

2
@ মিম্বিস, সুতরাং একটি বিমূর্তকরণ বাস্তবায়নের পরে প্রকল্পের জটিলতার মোট যোগফল আগের তুলনায় কম হওয়া উচিত
এনপিএসএফ 3000

3
@ এনপিএসএফ ৩০০০: আমার বক্তব্যটি হ'ল কেবলমাত্র আপনি পারার কারণে বিমূর্ততা তৈরি করবেন না। কখনও কখনও হার্ডকোডিং ডেটা চারপাশে সহজ, আরও বোধগম্য এবং সহজ। আরও প্রায়ই না, আমি গেমগুলি সফটকোডিংয়ের পথে যেতে দেখেছি , যা আমি আফসোসযোগ্য find এও মনে রাখবেন যে বিমূর্ততা যোগ করা সর্বদা তাদের অপসারণের চেয়ে সহজ, সুতরাং আমি যখন আপনার প্রয়োজন কেবল তখনই বিমূর্ততা যুক্ত করার দৃ firm় সমর্থনকারী।
পান্ডা পাইজামা

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

3

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

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

স্ক্রিপ্ট এবং ফাইলগুলিতে ডেটা সঞ্চিত পাঠ্য ভিত্তিক গেমগুলি অতিক্রম করার সময় পুনরায় সংযোগের সময় হ্রাস পাবে এবং ডেটা সহজেই চালিত করার জন্য আপনাকে একটি ইন্টারফেস তৈরি করতে দেয়।


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

3

দ্রুত পরিবর্তন আনার স্বার্থে, এটি টন দ্বারা বৃহত্তর উত্পাদনের উন্নয়নের গতি বাড়ায়।

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


3

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

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


3

আমি মনে করি একটি মূল বাক্যাংশ উদ্বেগের বিচ্ছেদ

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

স্থানীয়করণ নিয়ে তাকে ভাবতে হবে না। স্থানীয়করণ করছেন এমন ব্যক্তিকে কোড সম্পর্কে চিন্তা করতে হবে না।


3

আমি মনে করি যে 'শুকনো-সাদা' লোক হওয়া খুব সহজ এবং বাহ্যিক পাঠ্য সংস্থান ফাইলটি উষ্ণতার সাথে সুপারিশ করব।

কেন? কারণ এখানে একটি বিকল্প রয়েছে যা প্রতিটি সমাধানের ব্যয় / সমস্যা / সুবিধার ভারসাম্য বজায় রাখার বিষয়ে।

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

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

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

(স্থানীয়করণ সম্পর্কে মন্তব্য করুন: এটি কেবল একটি হ্যাশ টেবিলের দূরে, সুতরাং এটি একটি স্বতন্ত্র এবং সহজে সমাধানযোগ্য সমস্যা))


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

1
অবশ্যই: সম্ভবত আমি যথেষ্ট পরিষ্কার ছিল না, এর অর্থ হ'ল এটি কেবলমাত্র কয়েকটি পুনরাবৃত্তির পরে আপনি নিজের ডায়লগগুলির আকৃতি কী তা জানেন (একটি সরল সরল রেখা থেকে জটিল গাছ বা রাষ্ট্রের মেশিনে)। প্রথম পদক্ষেপে কয়েকটি (সবচেয়ে সহজ) ifs + কিছু হার্ড কোডড স্ট্রিং ঠিক আছে imho ho তারপরে আপনি যখন প্রতিটি সমাধানের ব্যয় / সুবিধাগুলি মূল্যায়নের পরে পরিষ্কারভাবে আপনার প্রয়োজনগুলি অনুগ্রহ করতে পারেন, তখন একটি চয়ন করুন।
গেমএলচেমিস্ট

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

2

আমার ধারণা লাইসেন্সে কোডের বিষয়বস্তু অন্তর্ভুক্ত না করার একটি কারণও হতে পারে।

উদাহরণ স্বরূপ,

  • আপনার কোডটি এফএলএসএস হতে পারে তবে আপনি আপনার সামগ্রীটি একেবারেই লাইসেন্স করতে চান না (সম্ভবত আপনি নিজের গেম কোডটি প্রকাশ করতে চান যাতে অন্যরাও এটিকে বিভিন্ন সামগ্রী সহ একই গেম তৈরি করতে ব্যবহার করতে পারে)
  • আপনার কোডটি এফএলএসএস হতে পারে তবে আপনি আপনার সামগ্রীর জন্য ক্রিয়েটিভ কমন্স লাইসেন্স ব্যবহার করতে চান (যেহেতু সফ্টওয়্যার লাইসেন্সগুলি সামগ্রীর জন্য দুর্দান্ত কাজ করে না এবং বিপরীতে)
  • আপনার কোড মালিকানাধীন হতে পারে তবে আপনি ফ্রি সামগ্রী পুনরায় ব্যবহার করছেন
  • আপনার কোড মালিকানাধীন হতে পারে, তবে আপনি একটি ফ্রি / লিবার লাইসেন্সের আওতায় আপনার নিজস্ব সামগ্রী প্রকাশ করতে চান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.