Thread: question about classes... maybee

If I follow you correctly, you are saying you want a Character class, and actual character objects would be the different kinds of characters (wolfman, shegirl, godface, etc) that players could choose from. So in that sense, character would me a trait of a player object, right?

Sounds fairly straightforward. I think the 2D array idea is a bad one. You would want two separate 1D array (players, and characters). You just include a pointer to a character object in the player class:

Code:

Character *archetype; // or whatchamacallit

This points to a pre-existing instance (object) of class Character (such as the shegirl or the godface). You do not need more than one pointer for this.

However, if the character object contains data that can change (eg, how many slimebuckets this godface player has left), then that model needs a slight tweak: rather than using a pointer to the one instance of the specific character archetype, you should initialize the player with a copy of such an object. This way Bobo the Godface can spend slimebuckets without it affecting the number of slimebuckets available to other godface players.

General rule: KEEP IT SIMPLE. As simple as possible. Make simplicity a priority. Do not get unnecessarily complex because you think that will be better. It won't.

Well, I agree to what MK27 has said. Character is better of as a member of Player that can be initialized inside a customized ctor of the Player class.

i.e:

Code:

class Player
{
private:
  Character archetype;

public:
  Player(Character &chara): 
      archetype(chara)
  {
  }
};

Also by doing it this way, you're actually using a dependency injection that is actually a good programming practice.

For the Character objects itself, maybe you should consider using std::vector so you can add items indefinitely.

both ideas sound good to me... but i dont see how making Player the parent to Character will work... i would think it would be the other way around... having Player be a child of Character... I need to only load the data for each character once... and if im understanding the above properly, it seems like i would have to load it for each character...

if i load the character data once for every player i will run out of memory really fast, i cant have that...

how would i go about using std::vector with my classes?

to get a little more complicated in explaining my situation the Character class holds mesh data and the default animation controller for the mesh data (directx9) and i need each instance of the Player class to have its own clone of the default animation controller... this i dont need help with... i just have to figure out the best way to make the Player class... I have to set it up something like this but im not sure how to go about it

Character Class:
Vertex and material data
A function to load from an x file
Any addition functions loading might require
An unused animation controller
Player Class:
A copy of the animation controller
A function to render the model instance
Any player specific data like ammo or position

The only way I see this of working is if in some way Character acts as a base class and Player acts as an instance class... But since im going to have an array of Character classes and an array of Player classes for each index of the Character array, im having trouble determining the best way to set this up

Have you looked up std::vector?
For the second statement, it shouldn't cause problems since it's part of Character and Character would be part of Player.

Originally Posted by gizmo3

so u r saying that the way they have told me to do it above Character is both child and parent to Player and Player is both child and parent to Character...

No, no one told you to do that. What was recommended to you was to make it such that a Player has-a Character. Character would be an abstract base class, but you derive the actual Character subclasses from it.

Where did you get archetype from???

Originally Posted by MK27

Code:

Character *archetype; // or whatchamacallit

This points to a pre-existing instance (object) of class Character (such as the shegirl or the godface). You do not need more than one pointer for this.

and...

Originally Posted by g4j31a5

Well, I agree to what MK27 has said. Character is better of as a member of Player that can be initialized inside a customized ctor of the Player class.

i.e:

Code:

class Player
{
private:
  Character archetype;

public:
  Player(Character &chara): 
      archetype(chara)
  {
  }
};

It's simply a name. You can call it whatever you will.

DAMN...

now i feel like more of a noob than i did before...

I must be either REALLY tired or REALLY confused...

it seems to me like Player Is-A Character makes more sense than Player Has-A Character

That's because you're confused about your abstractions. A "Character", in your game, is a template, containing stuff like "how does this thing look". A "Player", on the other hand, is a concrete instance. It contains stuff like "where am I".
A Player will typically be an instance of Character, in that there can be many players with the same character, and they have shared properties in the character. However, going from here to "Player is-a Character" is the same fallacy as, given a class Rectangle and an instance myRect, that "myRect is-a Rectangle". It's true in the English language semantics, but in object-oriented thinking, those two things exist on different levels of abstraction.

The idea here is that each player contains some data. Textures or whatever it is/was.
From this Character class, create instances of it for as many players you need.
If you need different kinds of characters, then derive subclasses from them with specialized properties. Then create instances of those.
Each instance should hold the data it requires to function, put simply.