Read up a little more on the syntax of the language, paying particulary close attention to the section on VARIABLE SCOPE, as many people here have pointed out. Don''t pay attention to the people talking about inheritance or class factories. That''s not what you need to learn about right now. Walk before you run.

Where is the error occuring? Is your intent to learn more about C++ and classes? Is that why you''re using them for different players? If not, then I would try to make the player a single class, and just use some switch statements for different types of characters. If that is your intent, I would learn the smallest amount about virtual functions and inheritance that''s possible. In other words, stop reading once you know how to get passed your problem.

Jiia

I am really amused by all the replies. Funny all of them advocate inheritence to the solution of your problem, when composition is a better solution. Inheritence is a compile time determined, and is limited by as many as you implement. For example, a sage who is a mage and cleric, a paladin who is a cleric and warrior. There are 6 classes involved here, not to mention they would need to all derive from a single Player class. (Multiple inheritence when dealing with a common base class, also known as the dread diamond inheritence is tricky unless you know how to handle it). So that''s a total of seven class.

Consider however, this. An abstract CharacterClass class interface is defined(some could call this a policy). It can hold another instance of CharacterClass, or you can have the Player class holds two instance of CharacterClass. This class will define non-instance specific manipulations(though it can perhaps hold information of skill levels, or other ''class specific information'', not ''player specific information'' like hp, mp, etc). Thus, in order to create a Player class, you can create an instance of a Player, then aggregate a Cleric and a Fighter CharacterClass. So you are building new classes out of existing class. In fact, you''re reusing codes. Not doing massively copy and paste that *might* occur.

A better example could be expressed in terms of monster. Some people might suggest an abstract Monster base class. And then you get Flying Monster, Sea Monster, Land Monster derived. Then you furthur derive each type into Smart, Dumb and Average monster. That''s a total of 9 classes eventually, AND 3 in the middle, PLUS a base. Now, what happens if you decide that each monster can furthur be catagorized to friendly and hostile monsters? You get another 18 classes to implement. The BETTER solution is to identify and break the abstract monster into these composotion. The abstract monster will hold a Type class(identify if it can fly, swim, or just walk), and its intelligence(smart, dumb or average), and then friendliness(hostile or friendly). So you end up with 3 type classes, 3 intelligence classes, 2 friendliness classes, and a generic monster class. That''s a total of 9 classes that can produce the same effect as 18+9+3+1=31 classes created by inheritence!

Do not blindly follow and think inheritence is the solution Most times, it is not. Compostion, runtime or compile time, is almost always a better solution.

*note, almost, though i would champion it as the solution in this particular case*
*and note, i was suggesting runtime compostion. You could go with compile time compostion via templates, but you end up with far more possibility, plus other issues I do not wish to go into because they require another discussion on problem face and needed solutions*