I recently got into the whole class derivation/class polymorphism thing, and was wondering how everyone thought it should/shouldn''t be used. I have used it extensively in a game that I am currently working on, and I get 120 fps on my computer with the graphics completely implemented(more or less). I was wondering if anyone knew if derived classes were considerably slower, or some of the drawbacks to using them. Also, I wanted to note that I designed a dynamic game loop that contained pointers to a Event Class that had children that did different things(render characters, move characters etc) An array contains 20 events that can be swapped in and out... ie a character goes invisible, remove the render character event, he becomes visible, put it back etc. Any comments on this approach are appreciated, although so far it is working much better than a huge loop that has a lot of if statements. Thanks for reading my rambling

Wow, nobody responded was It too much of a mess, or just nobody gives a damn?

Just because nobody responds within a day doesn''t mean that people don''t care... You just have to wait a little longer.

/. Muzzafarath

Sounds quite good to me... 120 f/s is good anyway =)

Based on my limited knowledge I''d say that the advantages of derived classes far outweigh the disadvantages... apart from that you''ll nearly always find using a class structure neater...

Don''t quote me on anything... As I said, everything based on my *limited* knowledge =)
J2xC

There are no disadvantages of using derived or overloaded classes. However, multiple inheritance can really screw things up though if you aren''t careful, so stick with single.

I was just kidding about no one responding :-)
Why can multiple inheritance mess you up? Here''s one way that I''m using it right now, tell me if this makes any sense:
There are many characters in my game. Each guy can have up to 2 actions, and actions can be weapons. Heres how my derivation works:

BattleAction is the base class/interface
It has a child weapon that has children for my different weapons(melee, missle, radial, boomerang, etc.)
BattleAction also has children for different actions(invisibility, confusion, stun, and a host of others)

Each of these has the same interface, so any character can have any action/weapon. My main worry is that this will cause big headaches down the road, or be really slow. Everything actually works right now, but who knows what will change before the game is through. I''ve heard a lot of people say derivation was not a good practice for game programming, but never heard many reasons why(speed?)
Thanks for reading the ramblings
Lotan

Hi,

you have to decide if you need the "has a" or "is a" dependence. In your example i would use "has a" which means, you do not derive from this interfaces but use pointers to those action/weapon whatever objects. This is also better cause you can change the objects while the game is running (f.i. equip your character with another weapon).

Michael

Actually right now, they are "is a", and I use the same interface for all of them so that they''re completely interchangeable, and therefore, I can change what each character has... They each have a pointer to a BattleAction which I instantiate as a weapon or whatever.
Lotan

I understand Micheal''s statement about the "is a" and "has a" issue. Normally you would not have Weapon, inheirit from BattleAction, because it "is" not a battle action, but instead "has" a BattleAction. But what was not really stressed was that the BattleAction class is a VERB, and it is also simply an interface. So to inheirit from it is a perfectly acceptable way to implement "has a" which would be read as "A Weapon has a BattleAction" or in more traditional terms "Weapon implements the BattleAction interface." The normal rule that public inheiritance is an implementation of "is a" is only for the common Noun / Noun form of inheiritance. Such as "Square" is a "Shape." But there are MANY more complex relationships that can be implemented when you use some advanced OO technics.

BTW - you are doing the right thing inheiriting from BattleAction, because in C++ (as opposed to SmallTalk) that is the only way to take advantage of polymorphism.

As for in the future. Realize that no matter what system you choose, adding abilities that cannot be expressed in your current interface (BattleAction) will require a fair amount of work. I would like to suggest the possiblity of Simply creating addition base classes that inheirit from BattleAction, such as AdvancedBattleAction, or GroupBattleAction, when the need arises. Then, your existing code will still operate as it should, but New classes that support the new interfaces can be added without affecting the old. So a SimpleCreature carrying a magic weapon (AdvancedBattleAction) can only use its standard battle action. But an AdvancedCreature that picks it up can call it''s AdvancedBattleAction Functions.

If your AdvancedCreatures need to also be able to use Non-Advanced objects then you may need to use RTTI to take full advantage of this (assuming you don''t program your classes like COM components) which will add to your programs size. If you do find yourself wanted to go to this level, and having some trouble with it, I recomend reading the first few chapters of "Inside COM" MS Press, and using that programming paradigm (NOT the whole COM thing ... just the QueryInterface idea. If you want any help with this, just email me or ICQ me. Good Luck

Hi,

maybe i missread something but i thought multiple inheritance was used to create the BattleActionTypes, this means derive from more than one interface to collect all features into one object. And in this case, you have to create all possible combinations as real classes which is very uncomfortable. If you only use single inheritance to implement a class hierarchie theres no problem and we have the BattleAction "is a" weapon etc. and also the Character "has a" BattleAction dependence.

Michael