টার্ন-ভিত্তিক গেমটির নকশা যেখানে ক্রিয়াকলাপগুলির পার্শ্ব-প্রতিক্রিয়া রয়েছে

Question

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

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

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

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

Comments

হ্যালো এপিস ইউটিলিস, এবং জিডিএসইতে স্বাগতম welcome আপনার প্রশ্নটি ভাল লেখা আছে, এবং আপনি যে সম্পর্কিত প্রশ্নগুলি উল্লেখ করেছেন তা দুর্দান্ত। যাইহোক, আপনার প্রশ্নটি অনেকগুলি বিভিন্ন সমস্যা coveringেকে রেখেছে এবং এটি সম্পূর্ণরূপে aাকতে একটি প্রশ্ন সম্ভবত প্রচুর হওয়া দরকার। আপনি এখনও একটি ভাল উত্তর পেতে পারেন, তবে আপনি নিজের সমস্যাটি আরও কিছুটা ভেঙে ফেললে আপনার এবং সাইটটি উপকৃত হবে। সম্ভবত একটি সহজ গেম তৈরি এবং ডমিনিয়ন পর্যন্ত তৈরি দিয়ে শুরু করুন?

— michael.bartnett

আমি প্রতিটি কার্ডকে এমন স্ক্রিপ্ট দেওয়া থেকে শুরু করতাম যা গেমের অবস্থা পরিবর্তিত করে, এবং যদি কিছু অদ্ভুত কিছু না ঘটে থাকে তবে ডিফল্ট

— টার্নের

Answer 1

আমি জারি কম্প্পার সাথে একমত যে শক্তিশালী স্ক্রিপ্টিং ভাষার সাথে কার্ডের প্রভাবগুলি সংজ্ঞায়িত করার উপায়। তবে আমি বিশ্বাস করি যে সর্বাধিক নমনীয়তার মূল চাবিকাঠি স্ক্রিপ্টযোগ্য ইভেন্ট হ্যান্ডলিং।

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

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

আপনার ডাবল-টার্ন কার্ডটি এর পরে এমন কিছু করবে:

add_event_hook('cleanup_phase_end', current_player, function {
     setNextPlayer(current_player); // make the player take another turn
     return false; // unregister this hook afterwards
});

(ডোমিনিওনের কাছে "ক্লিনআপ ফেজ" এর মতো কিছু আছে কিনা আমার কোনও ধারণা নেই - উদাহরণস্বরূপ এটি খেলোয়াড়দের পরিবর্তনের কাল্পনিক শেষ পর্যায়)

একটি কার্ড যা প্রতিটি খেলোয়াড়কে তাদের ড্রয়ের পর্বের শুরুতে একটি অতিরিক্ত কার্ড আঁকতে দেয় তা দেখতে এই রকম দেখাবে:

add_event_hook('draw_phase_begin', NULL, function {
    drawCard(current_player); // draw a card
    return true; // keep doing this until the hook is removed explicitely
});

একটি কার্ড যা লক্ষ্য প্লেয়ারকে হিট পয়েন্ট হারাতে সক্ষম করে যখনই তারা কার্ড খায় এটির মতো দেখতে:

add_event_hook('play_card', target_player, function {
    changeHitPoints(target_player, -1); // remove a hit point
    return true; 
});

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

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

Comments

কি দারুন. এই বিশৃঙ্খলা কনফেটি জিনিস।

— জারি কম্প্পা

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

— fnord

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

— ফিলিপ

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

— জ্যাক এইডলি

Answer 2

আমি এই সমস্যাটি দিয়েছি - নমনীয় কম্পিউটারাইজড কার্ড গেম ইঞ্জিন - কিছু সময় আগে কিছু ভেবেছিল।

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

দ্বিতীয়ত, অনমনীয় "টার্ন" সমস্যার কারণ হতে পারে।

আপনার কিছু ধরণের "টার্ন স্ট্যাক" দরকার যাতে "বিশেষ টার্ন" রয়েছে, যেমন "2 কার্ড বাতিল করুন"। স্ট্যাকটি খালি থাকলে, ডিফল্ট স্বাভাবিক মোড় অবিরত থাকে।

ফ্লাক্সে, এটি সম্পূর্ণরূপে সম্ভব যে এক পালা এমন কিছু হয়:

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

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

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

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

Comments

এটি একটি দুর্দান্ত উত্তর, এবং আমি যদি থাকতে পারি তবে আমি উভয়ই গ্রহণ করতাম। নিম্ন সুনামের সাথে ব্যক্তির উত্তরটি গ্রহণ করে আমি টাইটি ভেঙে দিয়েছি :)

— এপিস ইউটিলিস

কোনও সমস্যা নেই, আমি এখনই

— এটিতে অভ্যস্ত হয়েছি

Answer 3

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

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

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

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

কিছু দরকারী লিঙ্ক।

• https://www.youtube.com/watch?v=JxI3Eu5DPwE
• http://gamesfromwithin.com/data-oriented-d
• https://www.danielsefton.com/2016/05/developing-a-data-oriented-game-engine-part-1/

দ্রষ্টব্য: ইসিএস রান-টাইমে একজনকে পরিবর্তনশীল (উপাদানগুলি বলা হয়) যুক্ত করতে / মুছে ফেলার অনুমতি দেয়। ইসিএস কীভাবে "দেখতে" পারে তার উদাহরণ সি প্রোগ্রাম (এটি করার এক টন উপায় আছে)।

unsigned int textureID = ECSRegisterComponent("texture", sizeof(struct Texture));
unsigned int positionID = ECSRegisterComponent("position", sizeof(struct Point2DI));
for (unsigned int i = 0; i < 10; i++) {
    void *newEnt = ECSGetNewEntity();
    struct Point2DI pos = { 0 + i * 64, 0 };
    struct Texture tex;
    getTexture("test.png", &tex);
    ECSAddComponentToEntity(newEnt, &pos, positionID);
    ECSAddComponentToEntity(newEnt, &tex, textureID);
}
void *ent = ECSGetParentEntity(textureID, 3);
ECSDestroyEntity(ent);

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

unsigned int textureCount;
unsigned int positionID = ECSGetComponentTypeFromName("position");
unsigned int textureID = ECSGetComponentTypeFromName("texture");
struct Texture *textures = ECSGetAllComponentsOfType(textureID, &textureCount);
for (unsigned int i = 0; i < textureCount; i++) {
    void *parentEntity = ECSGetParentEntity(textureID, i);
    struct Point2DI *drawPos = ECSGetComponentFromEntity(positionID, parentEntity);
    if (drawPos) {
        struct Texture *t = &textures[i];
        drawTexture(t, drawPos->x, drawPos->y);
    }
}

Comments

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

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

আপডেট করা হয়েছে যে নির্দেশ করার জন্য আপনাকে ধন্যবাদ।

— নীল_পায়রো

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

— ব্লু_পায়রো