Pondering

my name is andrew
i am a student at CSM of La Plata, MD. i am currently studying in C++ and will start the advanced C++ course in spring 2005.
inbetween last and upcoming semester i am working on a consol based game. at first its going to be text based but later im going to make it graphic if posible.

the game is going to be a rpg using the rules of "GURPS."
can any one give me any tips on how to keep track of skills and spells. any other tips on creating games would be nice =D

currently i have a player class that gets, updates, and maintains information about the player. but its the spells and skills that puzzle me because other things beside the player are going to use them as well.

is inheritence the answer... or is there a better way....

Polymorphism is a very useful tool when you have different things that have the same base properties. You could have a generic spell class that has virtual functions to be implemented by any number of spells.

There's tons of tutorials out there for polymorphism, just do a google search.

I would have a Skills class and a Spells class, containing the member functions specific to the class.

actually Rod, I'm thinking you should probably have a Skill (singular) and Spell (singular) class. Then create lists of these. This may be a good place for a hierarchy as jverkoey has suggested, as there are different types of skills and spells that a player could have.

thanks guys

Good point FYB.

Polymorphism is your best friend and your worst enemy at the same time. It provides a LOT of functionality that would be very hard to gain without it BUT it also incurs quite a bit of function call overhead.

Frankly, I don't use it much in games because the function call overhead can grow exponentially as you add more and more classes. Normally I limit derivations to a maximum of 3 levels and normally only use the (base - > derived 1) format for my classes. Trying to do (base -> derived 1 -> derived 2) creates more function calls. While this may be appropriate for Windows GUI programs and others, it is not advisable in games especially if its happening inside the main game loop.

There are many articles on this on the net as well as in several books. It's a great feature of C++ just don't overuse it.

The overhead incurred by polymorphism is not present in just deriving classes and inheritting functionality. virtual functions are the problem (if you want to see it that way).

I would submit however that the alternative to a function pointer is a large switch statement in most cases. function pointers are a faster method for making decisions of this type. This is why I usually disregard those who speak of overhead here. No offense to bubba. He's right, sorta. In his defense of course, a lot of people feel this way and would back him up.

Well the derived example was assuming that you had virtual functions in the base and/or derived's. Sorry for the lack of clarity in my post.

I guess I mixed two replies into one. The base/derived 1 argument stems from the fact that most people tend to derive far too often and end up with a huge derived mess that is nearly unusable.

not being argumentative here. But classes give you the means for being structured. Not vice-versa. Bad programmers are bad programmers regardless of the tool. In my experience with bad coders, C is the king of spaghetti code. The so-called overhead argument against C++ always ........ed me off because someone who uses it properly will write FASTER code than someone using straight C 9 times out of 10.

You obviously are not paying attention to what I'm saying. I'm not talking about writing pure C code or anything like that. My advice is this:

If you want FPS, stay away from virtual functions, set/get accessor functions, etc.


I will also explain why get/set functions are not the best. Let's say you have created an uber cool sprite class that handles sprites. Each sprite holds a texture or vector of textures (bad idea). But you want to be super C++ coder so you make the IDirect3DTexture9 interface pointer private or protected. Here is the problem.

Let's say you are rendering from outside of the class object that you are currently drawing. In other words a non-member render function is doing the rendering for your object. That render function must call GetTexture() or something like it to get access to the texture member. Now let's say you have 5000 of these objects on screen. That's 5000 calls without even messing with virtual functions!!! Not a good idea. Make the texture member public - sure its ugly but its much better than hiding it simply for the sake of being C++'ey.

sure, but again you're talking about bad design. Usually, if you have sets and gets happening constantly it means you did something wrong in your architecture. Nobody should be doing that much accessing of someone else's data. That's why its theirs and not yours.

and if you MUST for some reason do a Get(), you should make the Get() inline. This is almost (depending on the compiler) as fast as a direct access to a public member.

Even so, I have to question your logic if you require frequent GetTexture() calls.

Meh, to the original poster, inheritance is a good way to go for what you are trying to do...in my humble opinion.

I'm quite certain that the only people that need to worry about the overhead from function pointers (which, to my understanding, is all that a virtual function is) are professional game developers who are actually working on code that needs that much optimization. This guy just wants to cast spells...I'm not sure of the algorithms to turn a cup into a toad or whatever but I'm sure it can be put into a virtual function. But better watch for that fillyourbrain that guy can prove even me wrong :)

wow didnt mean to start a fight =D lol

thanks for the tips guys! (raises hand) "the answer is inheritance"

and i will look into polymorphism, when i figure it out i might use it.

besides who knows what ill learn in the advanced C++ class =D!
thanks for your adivise guys and wish me luck on my next semister

btw this is a great site.

fyb doesn't want to fight. fyb loves bubba. fyb sorry.