player classes?

I would personally suggest one player class with all the tools to make all the different players and make 7 instances. It's reduces the overhead of making 7 seperate classes that all have 90% of the same information and making one one instance of each class.

The benefits of this is that you can make your spells and stuff target only one type of class that all are a part of instead of making a lot of overhead for 7 different classes being compatable with the one.

You can make a super class that holds all the information that is exactly the same between the classes (like a name variable and an isDead() method) and then make 7 mini classes that inherit from the big class. They all share the same super class that can be targeted by actions such as being attacked, but each have there own unique data.

That also I think helps whenever you edit previous code or wish to make a sequel using similar classes. Because in the future you may want to have a group of mages on a same team and you are prepared in the future. Also you can have the monsters inherit from the superclass and have yet unique data for them and share a commonality with the PCs such as generic stats and similar actions.

Hope it helps.

Yah I'd like to emphasize that superclass idea. I have what I call god classes, that are obviously named in the most generic way possible, but it represents all classes that derive from it. The greatest thing about these type of god classes is that you can functions and objects that use pointers to to these god classes, but the god class itself can be any of the derived object. So you don't have to have a function that uses all 7 versions of that god class, just one function that points to the god class. Heres an example.


On your slightest whim you could switch between opengl and directx by change one line. I forget what this methodology is called in oop. Like waterfall, or something. Anyway gl.

You should always go for reusability. The advantage of having one very flexible class compared to several hard-set classes becomes more and more obvious as your game grows.

It's mostly interaction with that class / classes. For example, imagine having a function which accepts a pointer to your player, to handle his death, or play a sound effect for him. Even deriving each player class from a base player class will not be as flexible as a good multi-purpose class.

The exception is of course when the differences between the "types" becomes very large. For example, it would be useful to have derived versions of a 1st-person camera and a 3rd-person camera, rather than chuck it all together. The reason is because the routines are quite different. Most of the camera code will change.

Quote:

I forget what this methodology is called in oop. Like waterfall, or something. Anyway gl.

Polymorphism.

If the BEHAVIOUR is different between classes then go for seperate classes. Don't use specialisations just for differing data attributes.

e.g.

My bullet does 10 points of damage and my super bullet behaves the same way but does 25 points of damage, 1 bullet class with a damage attribute would suffice.

However - If the super bullet explodes and causes an earth quake effect, mush room cloud and sceen flash, then I'd probably go with a different class (the behaviour is different).

here is a very good article on data driven designs - it's a postmortem from the game SmashTV 3D.

www.engin.umd.umich.edu/CIS/course.des/cis487/ppt/Schumaker1.pdf