সি ++ এ গেম ইঞ্জিনটি কীভাবে সংগঠিত করবেন? আমার উত্তরাধিকার ব্যবহার কি একটি ভাল ধারণা?


11

আমি গেম ডেভলপিং এবং প্রোগ্রামিং উভয়ই একজন শিক্ষানবিস।

আমি গেম ইঞ্জিন তৈরিতে কিছু নীতি শিখার চেষ্টা করছি।
আমি একটি সহজ গেম তৈরি করতে চাই, আমি সেই স্থানে রয়েছি যেখানে আমি গেম ইঞ্জিনটি বাস্তবায়নের চেষ্টা করছি।

সুতরাং আমি ভেবেছিলাম আমার গেম ইঞ্জিনের এই বিষয়গুলি নিয়ন্ত্রণ করা উচিত:

- Moving the objects in the scene
- Checking the collisions
- Adjusting movements based on collisions
- Passing the polygons to the rendering engine

আমি আমার বিষয়গুলি এইভাবে ডিজাইন করেছি:

class GlObject{
private:
    idEnum ObjId;
    //other identifiers
public:
    void move_obj(); //the movements are the same for all the objects (nextpos = pos + vel)
    void rotate_obj(); //rotations are the same for every objects too
    virtual Polygon generate_mesh() = 0; // the polygons are different
}

এবং আমার গেমটিতে আমার কাছে 4 টি ভিন্ন অবজেক্ট রয়েছে: প্লেন, বাধা, প্লেয়ার, বুলেট এবং আমি সেগুলি এইভাবে ডিজাইন করেছি:

class Player : public GlObject{ 
private:
    std::string name;
public:
    Player();
    Bullet fire() const; //this method is unique to the class player
    void generate_mesh();
}

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

এই একটি ভাল ধারণা?

class GameEngine{
private:
    std::vector<GlObject*> objects; //an array containg all the object present
    Player* hPlayer; //hPlayer is to be read as human player, and is a pointer to hold the reference to an object inside the array
public:
    GameEngine();
    //other stuff
}

গেম ইঞ্জিন কনস্ট্রাক্টর এর মত হবে:

GameEngine::GameEngine(){
    hPlayer = new Player;
    objects.push_back(hPlayer);
}

আমি যে পয়েন্টারটি ব্যবহার করছি তা হ'ল কারণ আমাকে fire()প্লেয়ার অবজেক্টের কাছে অনন্য call

সুতরাং আমার প্রশ্ন: এটি একটি ভাল ধারণা? আমার উত্তরাধিকার ব্যবহার কি এখানে ভুল?



আমি তাদের পোস্ট করার পরে দেখেছি, এবং আসলে রচনাটি দুর্দান্ত ধারণা! আমি সত্যই সি ++ ডিজাইনের পরিবর্তে ক্লাস সহ সি ব্যবহার শেষ করতে ভয় পাই!
পেলে 86

আমি মনে করি উত্তরাধিকারের চেয়ে রচনা ব্যবহারের আরও অনেক কারণ রয়েছে ... আমার উত্তর এটি সরবরাহ করে নমনীয়তার সুবিধার চারপাশে কয়েকটি উদাহরণ দেয়। বাস্তবায়নের একটি ভাল উদাহরণের জন্য আমি লিঙ্কিত নিবন্ধগুলি চেক করুন।
কোয়েট

উত্তর:


12

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

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

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

সহজভাবে করা; যে কোনও আকারের ইঞ্জিনের জন্য, আপনি দ্রুত দেখতে পাবেন যে বস্তুগুলি খুব কমই একটি ঝরঝরে শ্রেণিবদ্ধ কাঠামোর মধ্যে পড়ে যার জন্য উত্তরাধিকার কাজ করে। এটি উপযুক্ত হলে এটি ব্যবহার করুন, তবে এটি সমস্ত কিছুর জন্য ব্যবহারের ফাঁদে পড়বেন না - বস্তুগুলিকে আন্তঃসম্পর্কিত করার অন্যান্য উপায় শিখুন।


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

8

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

এছাড়াও সত্তা সিস্টেম এই নিবন্ধটি যখন আমি প্রথম এটা পড়তে আমাকে অনুপ্রাণিত।

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

উপাদানগুলি বিভিন্ন পরিস্থিতিতে খুব কার্যকর। এগুলি ব্যবহার করে আপনি আরও অনেক কিছু অর্জন করতে পারেন:

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

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

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

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

আরও ভাল অন্তর্দৃষ্টি জন্য [উপাদান উপাদান ভিত্তিক] এবং [সত্তা-সিস্টেম] ট্যাগ করা প্রশ্নগুলি একবার দেখুন।


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