Jump to content
  • Advertisement
Sign in to follow this  
Peter Conn

Polymorphism or not?

This topic is 4501 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hiya I am trying to make a text based game, and have come across a hard decision whilst planning the enemies, players and items. Should I make an abstract class and then have each enemy derived from that with its skills defined in the constructor, or do I just make an enemy class and have a constructor which takes in the skills and makes it from those and keep them in typedefs. Example: Choice a)
class Enemy
{
public:
   Enemy();
   Attack();
(other stuff)
};

class Rat : public Enemy
{
public:
   Rat()
(other stuff, only override stuff like Attack if I want something special to happen)
};

Choice b)
class Enemy
{
public:
   Enemy(int str, int def, int health)
(other stuff)
}

(I've forgotten the exact syntax for this)
typedef Enemy(2,3,10) Rat;

Share this post


Link to post
Share on other sites
Advertisement
Hey bud,

If you plan on having enemies that are used via a common interface, but where each type of enemy does some skills differently, ie the code for that difference is not applyable to all other enemies, then yes it would be worth using inheritance here from a base interface. You can then provide pure virtual methods that allow the derrived enemy to implement it in a custom way.

However, if each enemy is identical in operation but just behaves slightly differently depending on the parameters you are passing into the constructor then don't bother with inheritance.

I hope that helps clear it up,

Dave

Share this post


Link to post
Share on other sites
The second method is considerably more flexible. You can, for instance, read the enemy data in from a file rather than hard coding it into your game. Unless your entire game consists of five or six unique opponents, giving each opponent its own class is almost certainly going to be problematic.

CM

Share this post


Link to post
Share on other sites
Even if the enemy's each had their own unique "thing", you could make that a datamember, then just create an object array with 6 enemies. You could really do this a bunch of different ways, the best part of programming is the problem solving, use your imagination :).

Share this post


Link to post
Share on other sites
I'd recommend the first way. Polymorphism is an incredibly powerful tool; from a design perspective, having related objects implement a common abstract class is a clean and effective way of organizing your code, and allows for future modifications and extensions to flow seamlessly from your initial design. Go O.O.

Share this post


Link to post
Share on other sites
Quote:
Original post by Conner McCloud
The second method is considerably more flexible. You can, for instance, read the enemy data in from a file rather than hard coding it into your game. Unless your entire game consists of five or six unique opponents, giving each opponent its own class is almost certainly going to be problematic.

CM


No offense, but I completely disagree. The second method would be better suited to a non-O.O. language like C. Why would you think the first approach would be problematic, out of curiousity? Its a solid design pattern.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!