শত শত 'ইন-গেম' অক্ষরকে কীভাবে গঠন / পরিচালনা করতে সেরা

Question

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

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

একটি তালিকা কি আমার গেমের জন্য ডেটা সংরক্ষণের সেরা উপায়? বা 10000s চরিত্রটি তৈরি হওয়ার পরে এটি সমস্যার সমাধান করবে? একটি সম্ভাব্য সমাধান হ'ল তালিকাটি নির্দিষ্ট পরিমাণে পৌঁছে গেলে অন্য তালিকা তৈরি করা এবং সেগুলির মধ্যে সমস্ত মৃত অক্ষর সরিয়ে নেওয়া।

Comments

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

— ডিএমগ্রিগরি

en.wikipedia.org/wiki/Object_pool_pattern

— Evorlor

গেমটি কি সিকে 2 এর মতো, নাকি এটি অনেকগুলি অক্ষর রাখার অংশ? পুরো গেমটি সিকে 2 এর মতো হওয়ায় এটি আমি বুঝতে পেরেছি। সেক্ষেত্রে এখানে প্রচুর উত্তরগুলি ভুল নয় এবং এতে ভাল জানার উপায় রয়েছে তবে তারা প্রশ্নের পয়েন্টটি মিস করে। এটি আসলে কোনও দুর্দান্ত কৌশল খেলা যখন আপনি সিকে 2 কে একটি রিয়েল-টাইম কৌশল খেলা বলে সহায়তা করে না । এটি নিটপিকি মনে হতে পারে তবে আপনি যে সমস্যার মুখোমুখি হচ্ছেন এটির সাথে এটি অত্যন্ত প্রাসঙ্গিক।

— রাফেল স্মিটজ

উদাহরণস্বরূপ, যখন আপনি "চরিত্রগুলির সংখ্যা" উল্লেখ করেন, লোকেরা একই সাথে পর্দায় 3 ডি মডেল বা স্প্রাইটের বাকী অংশগুলি চিন্তা করতে পারে - সুতরাং, ইউনিটিতে, হাল্ট অফ GameObjects। সিকে 2 তে আমি একই সাথে সর্বাধিক পরিমাণে চরিত্রগুলি দেখেছিলাম যখন আমি আমার আদালতের দিকে তাকিয়ে সেখানে 10-15 জনকে দেখেছি (যদিও আমি খুব বেশি খেলিনি)। ঠিক তেমনি, 3000 সৈন্য নিয়ে একটি সেনাবাহিনী কেবলমাত্র একজন GameObject, "3000" সংখ্যাটি প্রদর্শন করে।

— রাফেল স্মিটজ

@ আর.শ্মিটজ হ্যাঁ আমার এই অংশটি স্পষ্ট করে দেওয়া উচিত ছিল প্রতিটি চরিত্রের সাথে গেমোজেক্ট সংযুক্তি নেই। যখনই প্রয়োজন একটি পয়েন্ট থেকে অন্য দিকে চলমান চরিত্রের মতো। একটি পৃথক সত্তা তৈরি করা হয়েছে যা আই লজিক সহ সেই চরিত্রের সমস্ত তথ্য রয়েছে।

— পল পি

Answer 1

আপনার তিনটি বিষয় বিবেচনা করা উচিত:

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

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

3. ডেটা ওরিয়েন্টেড-ডিজাইন বিবেচনা করুন। ১০০০ টি চরিত্রের অবজেক্ট থাকার পরিবর্তে এবং প্রতিটিটির জন্য একই ফাংশনটি কল করার পরিবর্তে 1000 টি অক্ষরের জন্য একটি অ্যারের ডেটা রাখুন এবং 1000 অক্ষরগুলির পরিবর্তে প্রতিটি আপডেট করার জন্য একটি ফাংশন লুপ রাখুন। এই জাতীয় অপ্টিমাইজেশন নাটকীয়ভাবে পারফরম্যান্সকে উন্নত করতে পারে।

Comments

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

— ডের কম্মিসার

অফ-স্ক্রিনযুক্ত আপডেট অক্ষরের পরিমাণ হ্রাস করে আপনি নাটকীয়ভাবে প্রক্রিয়াজাতকরণের সময় বাড়িয়ে নিতে পারেন। মানে কি হ্রাস পাবে না?

— তেজাস কালে

@ তেজসকালে: হ্যাঁ, সংশোধন হয়েছে।

— জ্যাক এইডলি

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

— curiousdannii

সত্যই যাচাই করা সর্বদা সর্বোত্তম, তবে এটি সাধারণত একটি নিরাপদ কার্যকরী ধারণা যে রোমানরা একে অপরকে

— নিক্ষেপ

Answer 2

এই পরিস্থিতিতে, আমি কম্পোজিশনটি ব্যবহার করার পরামর্শ দেব :

ক্লাসগুলি তাদের রচনা দ্বারা বহুকর্মী আচরণ এবং কোড পুনরায় ব্যবহার করা উচিত এমন নীতিটি (অন্যান্য শ্রেণীর উদাহরণ রয়েছে যা কাঙ্ক্ষিত কার্যকারিতা কার্যকর করে)

---

এই ক্ষেত্রে, এটি আপনার Characterশ্রেনীটি god শ্বরের মতো হয়ে উঠেছে বলে মনে হয় এবং একটি চরিত্রটি তার জীবনচক্রের সমস্ত পর্যায়ে কীভাবে কাজ করে তার সমস্ত বিবরণ রয়েছে ।

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

---

সমাধানটি হ'ল আপনার পৃথক অংশগুলিকে Characterউপ-শ্রেণিতে বিভক্ত করা, Characterএটির একটি উদাহরণ রয়েছে। উদাহরণ স্বরূপ:

• CharacterInfo নাম, জন্ম তারিখ, মৃত্যুর তারিখ এবং দলাদলি সহ একটি সাধারণ তথ্য-কাঠামো হতে পারে,

• Equipmentআপনার চরিত্রের সমস্ত আইটেম বা তাদের বর্তমান সম্পদ থাকতে পারে। এটিতে যুক্তি থাকতে পারে যা এগুলি কার্য সম্পাদন করে।

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

একবার আপনি চরিত্রটি বিভক্ত হয়ে গেলে, আপনাকে আর আপডেট লুপে কোনও জীবন্ত / মৃত পতাকা চেক করতে হবে না।

পরিবর্তে, আপনি কেবল একটি করতে চাই AliveCharacterObjectযে CharacterController, CharacterEquipmentএবং CharacterInfoস্ক্রিপ্ট সংযুক্ত করা হয়েছে। চরিত্রটিকে "হত্যা" করতে, আপনি কেবল সেই অংশগুলি সরিয়ে ফেলুন যা আর প্রাসঙ্গিক নয় (যেমন CharacterController) - এটি এখন স্মৃতি বা প্রসেসিংয়ের সময় নষ্ট করবে না।

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

---

এটি উল্লেখযোগ্য যে এই দৃষ্টান্তটি হ'ল .ক্যটি ব্যবহারের জন্য নির্মিত হয়েছিল - এবং এ কারণেই এটি প্রচুর পৃথক স্ক্রিপ্ট সহ জিনিসগুলি পরিচালনা করে। Godক্যে আপনার ডেটা পরিচালনা করার জন্য বৃহত godশ্বর-বস্তু তৈরি করা খুব কমই সেরা উপায়।

Answer 3

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

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

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

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

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

যাইহোক, আমি সত্যিই সিকেআইআই পছন্দ করি এবং এটি হাজার হাজার অনন্য এআই-নিয়ন্ত্রিত অক্ষরগুলির সাথে একটি বিশ্বকে যেভাবে অনুকরণ করে, তাই আমি জেনারটিতে আপনার অভিনয়ের জন্য অপেক্ষা করছি playing

Comments

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

— পল পি

Like "all living characters in a specific location" or "all living or dead ancestors of a specific character". It might be beneficial to create some more secondary data-structures optimized for these kinds of queries.সিকে 2 মোডিংয়ের সাথে আমার অভিজ্ঞতা থেকে, সিকে 2 কীভাবে ডেটা পরিচালনা করে তা এই কাছাকাছি। সিকে 2 সূচকগুলি মূলত বুনিয়াদি ডাটাবেস সূচকগুলি ব্যবহার করে বলে মনে হচ্ছে যা নির্দিষ্ট পরিস্থিতির জন্য অক্ষরগুলি সন্ধান করা আরও দ্রুত করে তোলে। অক্ষরের একটি তালিকা না রেখে, মনে হচ্ছে অক্ষরগুলির একটি অভ্যন্তরীণ ডাটাবেস রয়েছে, এতে সমস্ত ত্রুটি এবং সুবিধা রয়েছে।

— মরফিলদুর

Answer 4

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

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

Comments

এটি একটি আরটিএস আমাদের ধরে নেওয়া উচিত যে কোনও নির্দিষ্ট সময়ে, যথেষ্ট পরিমাণে ইউনিট আসলে পর্দায় রয়েছে।

— টম

আরটিএসে খেলোয়াড়ের সন্ধান না করা অবস্থায় বিশ্বের চালিয়ে যাওয়া দরকার। একটি বড় আপডেটটি ঠিক ততক্ষণ সময় নিতে পারে তবে আপনি যখন ক্যামেরাটি সরান তখন একটি বড় ফেটে পড়তে পারে।

— PStag

Answer 5

প্রশ্নের স্পষ্টতা

আমি একটি সাধারণ আরটিএস গেমটি তৈরি করে চলেছি, যার মধ্যে ক্রটিতেড কিংস 2 এর মতো কয়েকশ অক্ষর রয়েছে Unক্যের।

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

কোন কার্যকারিতা Characterক্লাস

সুতরাং আমি "ক্যারেক্টার" নামে একটি সি # ক্লাস তৈরি করেছি যাতে সমস্ত ডেটা থাকে।

গুড, কারণ তোমার খেলা একটি অক্ষর হল শুধু তথ্য। আপনি স্ক্রিনে যা দেখেন তা হ'ল ডেটার উপস্থাপনা। এই Characterক্লাসগুলি গেমের খুব হৃদয় এবং এগুলি " objectsশ্বর বস্তু " হওয়ার ঝুঁকিতে রয়েছে । সুতরাং আমি এর বিরুদ্ধে চূড়ান্ত ব্যবস্থা গ্রহণের পরামর্শ দেব: classes শ্রেণি থেকে সমস্ত কার্যকারিতা সরিয়ে ফেলুন। একটি পদ্ধতি GetFullName()যা প্রথম এবং শেষ নামটি সংযুক্ত করে, ঠিক আছে, তবে এমন কোনও কোড যা আসলে "কিছু করে"। সেই কোডটি ডেডিকেটেড ক্লাসে রাখুন যা একটি ক্রিয়া করে; উদাহরণস্বরূপ Birther, কোনও পদ্ধতি সহ একটি ক্লাস ক্লাসে Character CreateCharacter(Character father, Character mother)সেই কার্যকারিতাটি রাখার চেয়ে অনেক ক্লিনার হয়ে উঠবে Character।

কোডে ডেটা সংরক্ষণ করবেন না

তাদের সংরক্ষণের জন্য সহজ বিকল্পটি হ'ল স্ক্রিপ্টযোগ্য অবজেক্ট ব্যবহার করা

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

বিমূর্ত ধারণা

প্রক্রিয়া চলাকালীন চরিত্রটি "জীবিত" কিনা তা নিশ্চিত করার জন্য আমি একটি সাধারণ চেক যুক্ত করেছি [...] তবে তিনি মারা গেলে "চরিত্র "টি সরাতে পারি না কারণ পারিবারিক গাছ তৈরি করার সময় আমার তার তথ্যের প্রয়োজন ছিল।

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

Answer 6

আমি কিছুটা অভিজ্ঞতা থেকে কথা বলতে যাচ্ছি, কঠোর OO- নকশা থেকে কোনও সত্তা-উপাদান-সিস্টেম (ইসিএস) ডিজাইনে যাচ্ছি।

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

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

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

সুতরাং, আমি এখানে এটি যেখানে যাব:

প্রথম এবং সর্বাগ্রে, IDআপনার অক্ষরের জন্য একটি তৈরি করুন । একটি int, Guidআপনি যা খুশি। এটি হ'ল "সত্তা"।

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

একইভাবে, আমরা "চরিত্রটি জীবিত বা মৃত?" এর জন্য একটি সিস্টেম তৈরি করতে চাই? এটি আপনার ডিজাইনের একটি গুরুত্বপূর্ণ সিস্টেম, কারণ এটি অন্য সমস্তকে প্রভাবিত করে। কিছু সিস্টেম "মৃত" অক্ষরগুলি মুছে ফেলতে পারে (যেমন "স্প্রাইট" সিস্টেম), অন্যান্য সিস্টেমগুলি অভ্যন্তরীণভাবে নতুন স্থিতিকে আরও ভালভাবে সমর্থন করার জন্য জিনিসগুলি পুনরায় সাজিয়ে তুলতে পারে।

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

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

আপনার "নাম" সিস্টেম এবং "পারিবারিক বৃক্ষ" সিস্টেমটি সম্ভবত চরিত্রটিকে (জীবিত বা মৃত) স্মৃতিতে রাখা উচিত। এই সিস্টেমে চরিত্রের অবস্থা কী তা বিবেচনা না করেই সেই তথ্যটি পুনরায় স্মরণ করা দরকার। (জিম এখনও জিম, এমনকি আমরা তাকে কবর দেওয়ার পরেও))

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

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

আপনি কোনও সিস্টেমের কিছু অংশ বাইরের দিকে প্রকাশ করতে চাইবেন। আপনার Pathfinderসিস্টেমে আপনি সম্ভবত একটি চাইবেন Vector2 NextPosition(int entity)। এইভাবে, আপনি সেই উপাদানগুলিকে শক্তভাবে নিয়ন্ত্রিত অ্যারে বা তালিকায় রাখতে পারেন। আপনি আরও ছোট, structপ্রকারের ব্যবহার করতে পারেন যা আপনাকে ছোট, স্বচ্ছ মেমরি ব্লকগুলিতে উপাদান রাখতে সহায়তা করতে পারে যা সিস্টেম আপডেটগুলি আরও দ্রুত তৈরি করতে পারে । (বিশেষত যদি কোনও সিস্টেমে বাহ্যিক প্রভাবগুলি ন্যূনতম হয় তবে এখন কেবল এটির অভ্যন্তরীণ অবস্থা যেমন যত্ন নেওয়া দরকার Name))

তবে, এবং আমি এটির পক্ষে যথেষ্ট চাপ দিতে পারি না, এখন Entityএটি কেবলমাত্র একটি ID, টাইলস, অবজেক্টস ইত্যাদিসহ যদি কোনও সত্তা কোনও সিস্টেমের অন্তর্ভুক্ত না হয় তবে সিস্টেমটি এটি ট্র্যাক করবে না। এর অর্থ আমরা আমাদের "ট্রি" অবজেক্টগুলি তৈরি করতে পারি, সেগুলি সিস্টেমে Spriteএবং Movementসিস্টেমে সংরক্ষণ করতে পারি (গাছগুলি সরবে না, তবে তাদের "অবস্থান" উপাদান রয়েছে) এবং এগুলি অন্যান্য সিস্টেমের বাইরে রাখতে পারি। আমাদের আর গাছের জন্য বিশেষ তালিকার দরকার নেই, যেহেতু পেপারডলিং বাদে গাছের রেন্ডারিং চরিত্রের চেয়ে আলাদা নয়। (যা Spriteসিস্টেম নিয়ন্ত্রণ করতে পারে, বা Paperdollসিস্টেম নিয়ন্ত্রণ NextPositionকরতে পারে )) এখন আমাদের সামান্যই আবার লেখা যেতে পারে: Vector2? NextPosition(int entity)এবং nullএটি এমন সত্তাগুলিগুলির জন্য অবস্থানের পক্ষে ফিরে আসে যেখানে এটি যত্ন নেয় না। আমরা এটি আমাদের ক্ষেত্রেও প্রয়োগ করি NameSystem.GetName(int entity), এটি nullগাছ এবং শিলার জন্য ফিরে আসে ।

---

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

Comments

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

— পল পি

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

— রাফেল স্মিটজ

Answer 7

আপনি যেমন ityক্যে এটি করছেন, সবচেয়ে সহজ পদ্ধতির এটি হ'ল:

• প্রতিটি চরিত্র বা ইউনিট টাইপের জন্য একটি গেম অবজেক্ট তৈরি করুন
• এগুলি প্রিফ্যাব হিসাবে সংরক্ষণ করুন
• আপনি যখনই প্রয়োজন তখন একটি প্রিফাব ইনস্ট্যান্ট করতে পারেন
• যখন কোনও চরিত্র মারা যায়, গেমোবজেক্টটি ধ্বংস করুন এবং এটি কোনও সিপিইউ বা মেমরি গ্রহণ করবে না

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

আপনার গেমের মাধ্যমে আপনি যখন অগ্রগতি করবেন আপনি দেখতে পাবেন যে পৃথক গেমের জিনিসগুলি আপনাকে নেভিগেশন এবং এআই সহ অনেকগুলি সুবিধা দেয়।