Jump to content
  • Advertisement
Sign in to follow this  
AsOne

Derived class abstract if parent class is not?

This topic is 4331 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

The title pretty much says it all. Is it bad design if I have something like this:
class Base
{
public:
  virtual void update();
};

class Derived : public Base
{
public:
  virtual void update(); // i need to update too
  virtual void something() = 0;
}; 


Why would I want to do this? Well I have an Actor class which defines basic behavior for all objects in my game (rendering, animation, etc.), however, I want to derive classes from Actor such as Character, Item, etc.. But, in some of these derived classes it makes sense to make them abstract. Actor itself is actually derived from a SceneNode class, I suppose I could have pure virtual functions in the Actor class, but, at the same time I might want to create an Actor object (e.g. for just a non-interactive object in the game). I'm thinking I might just create interfaces for each type of object instead of deriving classes from Actor.
class Laser : public Actor, public IWeapon
{
// ...
}; 


Suggestions? EDIT: I'm using the prototype pattern for the game objects, i.e. data driven. However, I think I might need to change this becasue I'm realizing I need a wider range of object behavior not just different data with the same behavior, e.g. even though I can specifiy 10 parameters for a weapon, I still need to define completely different behavior for some of them.

Share this post


Link to post
Share on other sites
Advertisement
What is your question ? ... Whatever...

1. Does it make sense to create abstract classes even if the parent class is not abstract ?
Yes, it makes sense if you start a new type of sub hierarchy, like you already said. Scenenode is not abstract, but actor is, this is ok. In this case actor introduces a new kind of object-class with a specific behaviour.

2. Does it make sense to add behaviour to a certain class by adding a new interface ?
Yes and no. A interface should be a interface nothing more. Your IWeapon interface is fine, use interfaces in this way. It is not a new behaviour, but a new interface to your object. Don't do something like ILaserWeapon, IPulseWeapon, IMeleeWeapon, these are just diffenent behaviours which should be accessed through a single interface.

3. Is there a better way to add different behaviour to an object ?
Hmmm....yes... it depends..
You can use delegation. I.e. create a IBehaviourInterface which will implement a certain kind of behaviour (AI, Weaponbehaviour).


class IBehaviourInterface
{
public:
void doSomething() = 0;
}

class StupidOrcBehaviour : IBehaviourInterface
{
public:
void doSomething() {call script "stupid_orc_behaviour"}
}

class Actor : Scenenode
{
private:
IBehaviourInterface* myBehaviour;
public:
void doSomething() { if(myBehaviour!=NULL){myBehaviour->doSomething();}}
}




4. Now, when to use what ?

Use 1 for your base hierarchy. You have already done quite well.
Use 2 for interfaces, not behaviour. Good interfaces are:
- IRender
- IOrder
- IControl

Use 3 for certain behaviours:
- movementbehaviour
- AI-Behaviour
- weaponbehaviour

--
Ashaman


Share this post


Link to post
Share on other sites
Quote:
Original post by AsOne
Why would I want to do this? Well I have an Actor class which defines basic behavior for all objects in my game (rendering, animation, etc.), however, I want to derive classes from Actor such as Character, Item, etc.. But, in some of these derived classes it makes sense to make them abstract.


Then make them abstract. The only design problem you may encounter is too many levels of inheritance - which is more a problem of maintenance than conceptual design. I'll give you a warning, though - it may be better to distinguish between game concepts, and engine concepts. This means, have a seperate line of inheritance for SceneGraphNodes and engine-related stuff, and have another line of inheritance for things like Weapons, Characters, InanimateObjects, etc, for game-related things (whatever they be). Main problems in engine designs are that these concepts need to mix and mingle a great deal - figuring out a maintainable way of doing so is one of the Great Challenges.

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!