Page 1 of 1
Game OO architecture
Posted: Fri Oct 05, 2007 8:53 am
by 3p
I have problem I can't decide about.
What would be the best way to structure game application, more specifically in-game objects. I'm writing simple space shooter, so i need few types of aircraft, asteroids, and so on. Of course these need some attributes, like remaining fuel, damage etc and they also need to be scene manager objects...
If I inherit ISceneNode, i have to program all the logic plus I cant create these nodes the same way other can be created (smgr->add***SceneNode). If I inherit IAnimatedMeshSceneNode (or somehow CAnimatedSceneNode) then all objects have to be animated meshes. If I have member variable representing scene aspects of in-game objects then OnAnimate member can't access (in a reasonably simple way) attributes like damage...
No Irrlicht SDK examples are big enough to have to cope with this kind of problems, I guess...
So how would YOU go about this?
Posted: Fri Oct 05, 2007 9:56 am
by Saturn
I wouldn't inherit from any Node type at all. Instead I'd use my own GameObject class and have a ISceneNode(or a derived type) member in it.
This way, you can have GameObjects using different node classes, detach them from nodes, which is useful in that the GameObject does not need to be in the scene graph at all. (Like an item that either lies in the map or is in your characters inventory)
This is the low-tech easy-to-pull-off version. Another one is to seperate Model and View/Control even further by having GameObject state depending view components that take a GameObject as input and visualize it. (In the mentioned case either as a SceneNode-Wrapper in the map, or as an Icon in the inventory)
What is useful depends on the scale of your project in your case the first version is probably better anyway.
Posted: Fri Oct 05, 2007 10:25 am
by rogerborg
^^^
Yup. Encapsulate, don't inherit. It's generally a good idea to have as clean a boundary as possible between your game and any third party libraries, so that you don't get locked in to using them.
Posted: Fri Oct 05, 2007 10:46 am
by Cristiano87
You should create your own spaceship class
E.G.
Code: Select all
class SpaceShip {
irr::scene::IAnimatedMeshSceneNode * node;
public:
SpaceShip(const char * modelname,const char * texname, irr::f32 x=0.0, irr::f32 y=0.0, irr::f32 z=0.0);
};
Code: Select all
SpaceShip::SpaceShip(const char * modelname,const char * texname, irr::f32 x, irr::f32 y, irr::f32 z){
irr::core::vector3d<irr::f32> position;
irr::scene::IAnimatedMesh * t = smgr->getMesh(modelname);
node = smgr->addAnimatedMeshSceneNode(t);
//no error checking
node->setMaterialFlag(irr::video::EMF_LIGHTING,false);
node->setMaterialTexture(0,driver->getTexture(texname));
position.X = x;
position.Y = y;
position.Z = z;
node->setPosition(position);
}
Posted: Fri Oct 05, 2007 3:14 pm
by Vsk
Hello, I would create an Actor Interface with his coordinates and basic function like doAction(action), etc.
The inherit from it two clases or ControllableActor and SecondaryActor.
The first one is the one who can receive order from humans (the one that will iteract with the "controller Module".
The I would have "Actorgraphic" as an asosation to actor interface. This class will manager the graphic logic (not graphic but graphic logic, it is different).
Well then woul be good to make an IMotorGraphic interface that will have every operation about graphic, in this way you would desaclopping in part the motor that you use.
Then you must inherit from ControllableActor in the aircraft case and from secondaryActor in the case of the rest objet (obviuly not the terrain).
You must redefine the abstract operation from the class (c++ interface) according to the objetc spefic.
For example: you must redefin doAction (int action ) on Aircraft class and define in this class the types of action.
More precissly:
typedef enum{down, up, right, left,shoot} action.
The int the redefinition of doAction:
void doAction(int action){
if action = down
/*what ever you want*
else...
esle..
}
Well I hope that it was not so confuse and help you.
And of course try to ecapsulate by delagating (where correspond).
Vsk
Posted: Fri Oct 05, 2007 3:54 pm
by kburkhart84
Saturn wrote:I wouldn't inherit from any Node type at all. Instead I'd use my own GameObject class and have a ISceneNode(or a derived type) member in it.
This way, you can have GameObjects using different node classes, detach them from nodes, which is useful in that the GameObject does not need to be in the scene graph at all. (Like an item that either lies in the map or is in your characters inventory)
This is the low-tech easy-to-pull-off version. Another one is to seperate Model and View/Control even further by having GameObject state depending view components that take a GameObject as input and visualize it. (In the mentioned case either as a SceneNode-Wrapper in the map, or as an Icon in the inventory)
What is useful depends on the scale of your project in your case the first version is probably better anyway.
The first one sounds about like what I would do. If the enemies and players, or more than one player, happen to use the same type of ship, then I would create just one class for the ship, with functions that tell it to turn, throttle, thrust, shoot, whatever it does. Then I'd have one instance of said class for each player, which is hooked up to the input/keyboard/joystick. Then if any enemies happen to use the same ship, like in a dogfight style shooter, then I'd have another instance of the same class to represent said enemy, which would be hooked up to your AI instead of the player input. But the class itself would be the same.
Posted: Fri Oct 05, 2007 4:47 pm
by 3p
Thanks, everyone.
So, I will just encapsulate ISceneNode* into my basic CSpaceShooterObject. This will make me put all my in-game objects into another container and do animation (based on thrust, gravity) in program's main loop...
Since the game i'm working on is simple and small this will be ok.
But how is this done in big games? Do you have separate renderer scene graph and physics scene?