Game Object factory feedback?

[danielmccarthy]

Hi I have created like a game object factory. Am I on the right track? Can I have feedback and is the way I have designed this decent?
I have already had to redesign parts of my game due to design flaws so I have used one of the irrlicht examples as an example.
Someone give me the thumbs up and I will start implementing it into my main game. If not could you explain a better way of doing things

Here is the code: http://codejaw.com/379ux

Posted their because this forum limits how much code you can see at a time

Thanks,
Dan

[Seven]

it looks good to me.

the only things i do differently are :
I put the scenenode creation in the object instance instead of passing it to the object class.
allows the class to completely handle it's own variables, including saving / loading from disk.
it also helps with animations if the object can be certain what scenenode type it has

also, i let the object have it's own setposition() rotation and scale functions.
later, if you add physics and such, this will come in handy.
void object::setPosition(vecto3df pos)
{
if (scenenode) scenenode->setPosition(pos);
// do whatever else this object might do if it changes position
// like check in with a zone manager, update it's physics representation etc....
}

[danielmccarthy]

I think I know what you mean by the object instance. So basically in the objects constructor have a switch that uses the object id and then load the correct files that way?


This way you can just do something like

NPC* npc = new NPC(npcId);

[Seven]

something like that.
I will give an example here that uses a quick and dirty LOD system, but the thought can be applied to lots of things related to the object class.

let's say that in your game, you have an LOD system that uses 3 different models for each object depending on how close it is to the camera
"elf.X", "elf2.x" and "elf3.x" (elf is 1000 triangles, elf2 is 500 triangle and elf3 is 100 triangles.

inside object you can easily check distance to camera and use the right elf file

object
{
model1 = createmodelwithfile(elf.x)
model2 = createmodelwithfile(elf2.x)
model3 = createmodelwithfile(elf3.x)
}

each frame :
if (distancetocamera < 500) model1->setVisible(true); else
if (distancetocamera < 1000) model2->setVisible(true); else
model3->setVisible(true);

this would encapsulate all of the model related stuff into the object class.

otherwise you would have to have a manager class that swapped out the models

each frame
for each object
if (object->distancetocamera < 500) object->setSceneNode(elf.X)
if (object->distancetocamera < 1000) object->setSceneNode(elf2.X)
else object->setSceneNode(elf3.X)

but the manager would need to know what model you assigned to that object so it becomes
each frame
for each object
iscenenode* whichModel = somehowDetermineWhatModelToUseForLOD(object, object->distancetocamera); // how do you know which file was used?
object->setSceneNode(whichModel)

[Seven]

In that example, the manager would have to keep track of what file it loaded for the object (in this case elf.x) so it knows which lod model to use.
if the game is small enough, you could just keep track of the modeltype and use that

switch(object.modeltype)
{
case ELF:
if distancetocamera < 500 setscenenode(elf1.x)
if distancetocamera < 1000 setscenenode(elf2.x)
break;
case DWARF :
if distancetocamera < 500 setscenenode(dwarf1.x)
if distancetocamera < 1000 setscenenode(dwarf2.x)
}


but it seems more intuitive to me to just let the object handle all of this itself when you call the object's frame() function.

beginframe();
for each object : object.frame();
render();
endframe();


and in the object frame function let it handle everything.
virtual void frame()
{
}

anyhow, just my $0.02 worth.....