1st of all, i made a game, having just 1 controlled player in it. No other chars. So i wrote almost everything i needed for that in a single class. Character input, animation control, everything. That`s like 0 reusability.
Well, now i`m working on another project, and i wanna do things differently. Gonna have a player character, enemies and maybe NPCs. How should i separate everything?
I was thinking about creating a Character class, which has a "State" structure that links a state to an animation, and the common fields like health, etc. Then creating 2 subclasses for Player and Enemy. The Player class should treat and change states based on a character controller class (keyboard input, etc), while the Enemy class would have a kind of action queue. Like .attack(target) , .walkTo(position) etc. A separate animation player class would play animations corresponding to the player`s / enemy`s actual state.
Will this be ok?
What kinda problems will i walk into? Any suggestions, ideas?
Need help designing a Character class
There's no one-size-fits-all design. What makes sense in one game may be a tragic mistake in another. We'd really have to know a lot more about your particular design to know whether or not it is sensible, let alone what kind of architectural issues it may produce.
In these cases, the best thing you can do is just try it. If you find yourself at a sticking point where something is more awkward or ugly than it seems like it should be, then consider design changes. In the best case, everything works fine in your initial design; in the worst case, you'll have concrete experience to point to why one design is more appropriate than another, and that's worth far more than any abstract advice we can offer :-)
In these cases, the best thing you can do is just try it. If you find yourself at a sticking point where something is more awkward or ugly than it seems like it should be, then consider design changes. In the best case, everything works fine in your initial design; in the worst case, you'll have concrete experience to point to why one design is more appropriate than another, and that's worth far more than any abstract advice we can offer :-)
I'm not sure if others might agree with me, but what I like to do is grab a piece of paper, and start categorizing things into 'object's in hopes I find similarities between them and inevitably minimize redundant work I have to do when trying to come up with classes for game objects. If you can consider it an object, you can make it into a class. That's how I go about making classes, but like mentioned, if you want specifics, you'll have to give specific details. 
This design could work well, but of course it depends on your game as has been rightfully pointed out already.
In my last project, I did not do things that way - all enemies shared a common superclass, but player characters (there were 3) were separate entirely and did not share this superclass. In my case, there simply wasn't enough in common between these classes to justify that kind of structure. They would have shared hitpoint counters and model references between each other, but enemies has had AI controllers and different attributes within them , while PCs were treated very differently and had far more complex structures (weapon arrays, camera points, input handling, etc.). The updating between PCs and enemies as also handled separately within the main loop, and there are certain advantages to decoupling them like that.
Consider how much they have in common in terms of both structure and behavior, and determine how many common elements they really have. In my case, it was surprisingly little, and as such, deriving both from the same class would have been unnecessary overhead.
In my last project, I did not do things that way - all enemies shared a common superclass, but player characters (there were 3) were separate entirely and did not share this superclass. In my case, there simply wasn't enough in common between these classes to justify that kind of structure. They would have shared hitpoint counters and model references between each other, but enemies has had AI controllers and different attributes within them , while PCs were treated very differently and had far more complex structures (weapon arrays, camera points, input handling, etc.). The updating between PCs and enemies as also handled separately within the main loop, and there are certain advantages to decoupling them like that.
Consider how much they have in common in terms of both structure and behavior, and determine how many common elements they really have. In my case, it was surprisingly little, and as such, deriving both from the same class would have been unnecessary overhead.
why use classes? i mean i dont understand! global data types are enough or structs maybe but classes? sorry i dont really prefer or encorage any to use OOP
why use classes? i mean i dont understand! global data types are enough or structs maybe but classes? sorry i dont really prefer or encorage any to use OOP
You also didn't recognize C++ code as C++ in another forum. And you also don't know what a scripting language is per a post in another forum. That leads me to the conclusion that you are grossly under-qualified to weigh in on "preferring" or "encouraging" the use of OOP.
Perhaps a wannabe troll? And a poor one at that?
try it,then reconstitute it.In the beginning,you can code more particular class,then abstract it.
Forgive my poor English.
Forgive my poor English.
A class system I am planning on doing for my racing game goes something like this. Maybe you could use something from it.
First of all I have a racecar class. The racecar is a subclass of the generic entity in my 3D world. So that inherits the ability to do animations. I then create a contestant class that has a standard interface for controlling the car. Then ContestantHuman and ContestantComputer both inherit from Contestant. The subclasses of Contestant then use the interface provided by Contestant to control the car. This allows me to switch out the controlling logic on a car. The structure could look something like this.
This obviously isn't complete. You would extend the interface to Contestant as needed such as adding a mechanism to get the cars position and heading for the ContestantComputer to be able to detect obstacles.
In an adventure game the interface could include function like, moveBy(double angle, double speed), attack() or jump() The base class would handle the animations for the movements. What is controlling the character is completely arbitrary. This would allow any character to be controlled by a human player.
But like others have said. You really need to analyze the requirements of your own project to determine the structure of classes in their interactions but feel free to draw from what I presented here.
First of all I have a racecar class. The racecar is a subclass of the generic entity in my 3D world. So that inherits the ability to do animations. I then create a contestant class that has a standard interface for controlling the car. Then ContestantHuman and ContestantComputer both inherit from Contestant. The subclasses of Contestant then use the interface provided by Contestant to control the car. This allows me to switch out the controlling logic on a car. The structure could look something like this.
class Racecar : public Entity
{
private:
public:
}
class Contestant
{ Racecar* mRacecar;
protected:
void setAcceleration(double value); // value from -1 to 1, negative causes the car to brake. Positive is throttle
void setTurnRate(double value);
public:
virutal void update(double dt) = 0;
}
class ContestantHuman : public Contestant
{
public: virutal void update(double dt);
}
class ContestantComputer : public Contestant
{
public: virutal void update(double dt);
}
This obviously isn't complete. You would extend the interface to Contestant as needed such as adding a mechanism to get the cars position and heading for the ContestantComputer to be able to detect obstacles.
In an adventure game the interface could include function like, moveBy(double angle, double speed), attack() or jump() The base class would handle the animations for the movements. What is controlling the character is completely arbitrary. This would allow any character to be controlled by a human player.
But like others have said. You really need to analyze the requirements of your own project to determine the structure of classes in their interactions but feel free to draw from what I presented here.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
