Sign in to follow this  
Peter Conn

Polymorphism or not?

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
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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this