Sign in to follow this  
c-gibson-s

player classes?

Recommended Posts

c-gibson-s    313
I have an adventure RPG engine i am writing right now. As of now, i have 7 main 'players' in the game, and only 7 that the user can play with. each character has a unique set of abilities and stats, although all of them are generic (just named differently)...like a mage has Magic Points and a warrior has Technique Points. Should i make 7 different classes for each character and its properties, or should i make a generic and call it 7 seperate times during the game and use those? The only thing that changes in the Player.h class is the stats..the names, ages, and stuff are set upon initialization and dont change. thanks!

Share this post


Link to post
Share on other sites
gryfang    151
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.

Share this post


Link to post
Share on other sites
xorjesus    100
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.

//graphicswrapper.h
class GraphicsHandler
{
void DrawLine(args);
};

class OpenGLWrapper : public GraphicsHandler
{
void DrawLine(args);
}

class DirectXWrapper : public GraphicsHandler
{
void DrawLine(args);
}
// end graphicswrapper.h

// main.cpp
#include "graphicswrapper.h"

void SomeFuncThatDoesCoolThingsWithLines(GraphicsHandler *graphics)
{
for(args)
{
graphics->DrawLine(args)
}
}

void main()
{
GraphicsWrapper *graphics = new DirectXWrapper;
SomeFuncThatDOesCoolThingsWithLines(graphics);
}


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.

Share this post


Link to post
Share on other sites
Jiia    592
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.

Share this post


Link to post
Share on other sites
DesCr    100
Quote:
I forget what this methodology is called in oop. Like waterfall, or something. Anyway gl.


Polymorphism.

Share this post


Link to post
Share on other sites
PaulCunningham    132
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

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