I believe I've found an official Answer to my Problem (Object Factories)

Searching, searching, searching...

Always I had a few questions, how the heck do I create new instances of objects without writing 30 lines of code (probably a hundred or so in some cases).


How do I pass an "Object" to a function that simply pushes the object into a vector, while being able to send all of the class "Object" derivedrens unique? Ultimately, Passing *Object to the function while *Object might be a space ship, a wall, a planet, an asteroid, a tree, etc etc...

The answer is an Object Factory. An Object factory that creates other Object Factories, a super factory to manage -EVERY- object in your entire program. This "Object Factory" would be at the very very very VERY tip top of your Include files, included once into the entire project, but used and weaved in throughout, in amazingly seemless OOP.

I believe this is the HOLY GRAIL of oop, the pinnacle of C++ as an object oriented language, and to boot, not that difficult to understand the outlying structure of the whole thing.


I will include an example of a simple Object Factory below..

The article was written by Robert Geiman and is on www.GameDev.net .

Props

The actual OO part of that design is pretty standard and not to the max at all (theres tons of design patterns, and standard OO features (multiple inheritance, etc) that it doesnt use. It is definetly close to the max it could go on this feature for sure (macro magic, templates, classes, oo, maps, etc.). God, I hate when macro magic is necessary..

The point of this is so that it returns the right subclass type, so it shouldnt be assigned to the base class Monster, it should be assigned to the subclass. So it should actually be this:

Code:

---

  GoblinMonster *monster1 = monster_factory.Create(GOBLIN_MONSTER, 34.5f, 63.0f, 7.7f);
  OgreMonster *monster2 = monster_factory.Create(OGRE_MONSTER, 83.0f, 14.2f, 54.4f);

---

You should be using monster1.UnRegister(GOBLIN_MONSTER); too.

Your examples kind of fail to show why this is useful at all. Of course you have a system to handle all objects (thats obvious). However instead of returning the base class Object, you can return the correct subclass. You've found the article on how to do that. In order to utilize this you would have to have to do sort of what the Create() method does, and search for the correct subclass by id, but instead of returning NULL, when you find it you return the subclass. So then simply add a new method to class ObjectFactory:

Code:

---

BaseClassType *Find(UniqueIdType unique_id)
      {                                                                                                   
        Iterator iter = m_object_creator.find(unique_id);       
                                       
        if (iter == m_object_creator.end())                                                               
            return NULL;       
                                                                           
        return (*iter).second;
}

---

BTW since these objects have to be searched for, the have an overhead of O(log n) instead of O(1).

The reason you're seeing the constructor for the OgreMonster is because it actually does exist in the map in the ObjectFactory, but when you assign it to Monster you arent going to be able to access functions that OgreMonster has but Monster does not. Try it out and please let me know if I'm wrong, because that would be great if I was wrong - the problem would be solved.

I can't figure out how it would work. Of course you can get the subclass you want, but you could do that anyway - that isn't the problem. The problem is the recieving end of a function. Now that you see you cant assign it to the Monster class, that should be apparent. You would have to know what class to assign it to (OgreMonster or GoblinMonster) in the function you are passing say the ID or object to. Which is the whole problem in the first place and that makes this factory pointless as a solution (its a nice factory, but I dont see it being a solution to this problem). You could template a function accept the Ogre type.

But thats just annoying and I'd rather just stick all of the information CRender, CWorld, and CPhysics need in Object and be done with this problem.

EDIT: I can't compile it to test anyhow, what compiler do you use?

EDIT: You could do the most valuable test by keeping monster1/2 as type Monster. Then simply give OgreMonster and GoblinMonster two different functions, and then calling monster1->function1(), and monster2->function2(), and see if the compiler tells you monster1/2 don't contain those functions (like it normally would).

The template class uses function pointers, therefore you can access the functions of the derived classes...

Code:

---

class WalkForwardCommand : public Command
{
public:
  WalkForwardCommand() {}
  virtual ~WalkForwardCommand() {}

  virtual void Execute()
  {
      std::cout << "\nWalking forward...\n" << std::endl;
  }
};

---

You can call Execute just fine, and I'm going to assume you can access any variables held in the walk forward command, why would it be any different?

Oh wait, command has a virtual Execute function, let me think on this one...

I think this is where you're asking too much Dae. (someone correct me if I am wrong)

What needs to access which functions in your classes?

A render function needs to access model data, therefore you create a Scene_Object class, which handles nothing but pictures.

A Game world needs to access physics and collision detection, therefore you create a Physics_Object class, the reason you can't combine Scene_Objects and Physics_Object is because the renderer doesn't need to know physics data and functions, it just needs to know a final result (x, y, z changes)

Having one class that does it all, simply isnt the essense of OO.. Think, A Goblin doesn't have physics, physics effect Goblins.

You, unfortunately Dae, cannot create a super Object class unless you use 100 virtual functions for everything any object might use, even if they don't use it... (correct me if I am wrong, someone)

I might be talking way over my head of knowledge, but you would think if you've been searching for any amount of time at all, and no one could answer your question efficiently, it simply can't happen, I've seen your posts, they make perfect sense...

I'm going to email the creator a few times and ask him questions.

Code:

---

class OgreMonster : public Monster
{
public:
  OgreMonster(float x, float y, float z)
  {
      std::cout << "Ogre monster created at coordinate: " << x << ", " << y << ", " << z << std::endl;
  }
};

---

When the OgreMonster is created, xyz is returned... OgreMonster is a function (constructor really)..... I guess that doesn't count. Is there a such thing as nested functions? Perhaps a function def inside the constructor ?

OR:

You could create an OgreMonster factory, with a couple functions specific to OgreMonster... I think that would become redundant, because that would be narrowing down our thing we wanna return, we wanna be able to return a pointer to a general monster while keeping all that data... Hmmm

FINALLY:

I think I have the answer, its function pointers, simple as that, easy as pie. Instead of having the Constructor of OgreMonster have just an x,y,z arguement, give it more arguements, one pointer for each function. This way those function pointers would be created in the new Monster object, reay to use. (right? :confused: )

No, your monster1/2 would not be able to access Ogre/Goblin specific functions because you're casting them to the base class Monster.

Quote:

---

The template class uses function pointers, therefore you can access the functions of the derived classes...

---

The function pointer is so that you can create the subclass, and its stored in a map along with an id.

I reread the article and completely understand now. It is not meant to resolve my or your issue. I was actually wrong and it doesn't even store the instances. However it does create them and then return them, so thats why your constructor for Ogre/Goblin was being called. I believe he simply casted the returned class to the base class as an example, which would be file for interfaces. Rereading the intro in that article I can't believe I spent so much time looking at it. I've decided to stop reading these specific design patterns for a while, at least until I finish the prereq Design Patterns.

Quote:

---

You, unfortunately Dae, cannot create a super Object class unless you use 100 virtual functions for everything any object might use, even if they don't use it... (correct me if I am wrong, someone)

---

I realized that, and thats why I was seeking a different way. There are many ways to do one thing yeah know.

Sorry if I was the one that got you hung up on my goal to make it so there was no dataloss when recieving an Object as a parameter. I've decided I've probably been overdoing it and yeah, expecting too much. So I've decided to simply put all information (mass, velocity, coords, etc) that CPhysics, CWorld, or CRender might need for Object's in Object.

Quote:

---

I think this is where you're asking too much Dae. (someone correct me if I am wrong)

---

However, I talked to some people at EFnet, and there is a way to accomplish want I wanted. The very simple way is to make a templated method. I could then pass it any class, problem solved. The only reason I wont do this, unless for some rare reason, is because obviously thats going to make multiple copies of the function for each class and its a bit more complicated. Plus I hear they might be the devil.

Quote:

---

I think I have the answer, its function pointers, simple as that, easy as pie. Instead of having the Constructor of OgreMonster have just an x,y,z arguement, give it more arguements, one pointer for each function. This way those function pointers would be created in the new Monster object, reay to use. (right? )

---

I've got to say thats overdoing it more than me.

Quote:

---

When the OgreMonster is created, xyz is returned... OgreMonster is a function (constructor really)..... I guess that doesn't count. Is there a such thing as nested functions? Perhaps a function def inside the constructor ?

---

Yeah it doesn't count, because of what I said two times. Nope, theres no nested functions in C++.

Quote:

---

A Game world needs to access physics and collision detection, therefore you create a Physics_Object class, the reason you can't combine Scene_Objects and Physics_Object is because the renderer doesn't need to know physics data and functions, it just needs to know a final result (x, y, z changes)

---

Well, you can combine them actually. The thing is, whats your point? CRender takes a pointer so it doesnt matter if the object has extra data it doesnt need to use, it just doesnt use it. My problem was that I thought there would be some variables that CPhysics, or CWorld might require in a generic function that not all Objects shared and therefor should not be put as high up as in the Object class. I cant think of any examples, but I was trying to think ahead. As I've said I've decided I cant think of any reason not to, and will not put velocity, mass, coords, etc. that CRender, CPhysics, and CWorld may need in Object.

Quote:

---

Having one class that does it all, simply isnt the essense of OO.. Think, A Goblin doesn't have physics, physics effect Goblins.

---

I did not mean for a class that does it all, what I meant for was a function that was generic (and I cant believe I didnt realize to use a templated method because thats a generic function) so it could accept any subclass of Object. BTW physics may effect Goblins, but Goblin still needs to know its mass, velocity, etc. and then physics uses that data to change Goblins position. Simple.

The only arguement I have is about Goblin Knowing its mass and velocity, Goblin doesn't need to know those things, some other higher power does, (a physics engine)..

But for the most part you are right.

Although, You mean we could solve the problem with function pointers in the constructors parameters, so they would be passed to the template class?

If theyre the devil, they sure allow you to do a beautiful thing.

Few words from Robert Geiman

Quote:

---

first, Dae is correct, you don't want to convert the pointer returned from the Create() function into the derived class (ie, OgerMonster *m = f.Create<OGER_MONSTER>();). If you already know the derived class type then you don't need the object factory class.

Second, I'm not sure I fully understand your problem.

Normally when you're in a situation where you want to use the object factory class, you'd create multiple instances for specific groups of classes. In other words, you don't derive every class in your game from a BaseClass type and create one BaseFactory class.

Instead you create seperate factory classes, one for each group of common classes. For example, a MonsterFactory instance for all monsters, or a RenderFactory instance for OpenGL and DirectX renderers. This way each derived class should already contain the same generic functions.

As far as accessing data that's specific to each derived class, that can be done by the class itself. For instance:

Code:

---

class Monster
{
public:
  virtual void Execute() = 0;
};

---

Code:

---

class OgreMonster
{
private:
  std::string ogre_name;

public:
  void Execute() { std::cout << "Private ogre name s: " << ogre_name << std::endl; }
};

---

Code:

---

class TrollMonster
{
private:
  bool is_cave_troll;

public:
  void Execute() { std::cout << "Private cave troll value is: " << is_cave_troll << std::endl; }
};

---

If this doesn't help you, perhaps you could give me more specifics on what exactly you're trying to accomplish.

Rob Geiman

---

I responded like this

Quote:

---

Code:

---

class Monster
{
public:
  virtual void Execute() = 0;
};

class OgreMonster
{
private:
  std::string ogre_name;

public:
  void Execute() { std::cout << "Private ogre name s: " << ogre_name << std::endl; }
 
  void Newfunction
  {
        std::cout << "new function" << std::endl; // we wanna be able to access
    }  // this function in every new instance of OgreMonster  (

};

---

We want to be able to create functions specific to only OgreMonster that don't need to be virtualized in OgreMonsters Base class (Monster)

So when we basically create a new monster with your factory, we wanna be able to access functions specific to every single individual monster as well (I.E, no data loss)

I though function pointers were a good idea, pass a pointer to a function specific to the individual monster, therefore you could access them easy as pie in the new templated class.

Any suggestions?

---

Hmm..

Well his suggestion is the best way to accomplish it, but like you said thats what we are trying to avoid - virtual functions. The thing is that function pointers could possibly work (I dont have much experience with them, especially in a case where you're using like 10 of them), but that would kind of be defeating the point since all we are trying to avoid is 1 vtable lookup.

I forgot to mention that EFnet also said that the extra vtable lookup isn't liable to be a problem unless you're planning on performing it thousands or millions of times a second (like with vectors or vertex operations).

I do understand these concepts more than I did before, but not entirely because of course they are all new to me. His article even refers you to read other articles first. If you check one of the other articles its more clear on the purpose of a pluggable factory. The point of it is to take an id and call a class based on that. Which makes complete sense when you think about say networked games. You send an id to a client and the client knows which class to call based on what id is sent. Then what his article is meant to accomplish is a generic ability to use it for any base classes, with the ability to choose which derived class is chosen at run-time, while also being quite quick because it uses a map.

Honestly theres no purpose for us to use this article because we already have access and know which classes we want to call. The only problem was that we don't know which class we want to accept in say CRender, so we use Object*. Then the problem is that when casting a subclass of Object that has data that isn't from Object (and Object isnt concrete (virtual functions)) we lose it. The thing is even though thats the problem, I cant think of ANY case that CRender, etc. will be accessing data that not all Object's share (velocity, mass, etc.) - I was just thinking ahead. Even if I can find a case where this becomes a problem, I could simply overload the function to accept that subclass, or if I dare use "the devil" templated methods. Problem solved.

For me the problem never really existed, because as I said was just thinking ahead. For you though I guess it does, you don't seem to want to give Object this data. Goblin may not need to know what his mass is, thats an opinion, but I don't agree entirely. I can think of methods that Goblin would have where it needs to know its mass, and even if it doesn't need to know its mass, it needs to store that data because its a property of itself and must send that data to CPhysics.

You could use templated methods to solve your problem (which is like many overloaded methods for each different subclass of Object).

I'm pretty clear on what I'm doing now, but good lucky to you in your search.

That's quite simply not possible in the static typing system of C++. In order to call a function on an object, you need to have a reference or pointer to that object that is of a type that actually contains the function. Therefore, to call an OgreMonster-specific function, you need an OgreMonster* to the object. If the object is currently only available as a Monster*, you have to do a downcast, which means you also need to find out if the runtime object is of type OgreMonster (or derived). This is possible using dynamic_cast or some other RTTI mechanism, but it always involes an if().

You have to see it this way. Given an object factory
unspecified create(Tag type);
and a variable
Tag tag;
the call
Monster *p = create(tag);
is for the compiler completely opaque (usually). tag might be OGRE_TAG or GARGOYLE_TAG, but there's not way to know that at compile time. Who knows, the value of tag could have been created like this:
tag = rand() % 2 ? OGRE_TAG : GARGOYLE_TAG;
The best you can supply for 'unspecified' therefore is Monster*, meaning you lose some type information.

On the other hand, one of Dae's basic requirements in this debate is flawed:

Quote:

---

My problem was that I thought there would be some variables that CPhysics, or CWorld might require in a generic function that not all Objects shared and therefor should not be put as high up as in the Object class. I cant think of any examples, but I was trying to think ahead. As I've said I've decided I cant think of any reason not to, and will not put velocity, mass, coords, etc. that CRender, CPhysics, and CWorld may need in Object.

---

What you're doing here is overdoing genericity. Or perhaps not, in a way. What it comes down to is this: CRender renders RenderableObject, CPhysics affects PhysicalObject and CWorld contains WorldObject. Whatever's not in these classes (or interfaces, more likely) is of absolutely no interest to these classes. Should you find that your CPhysics needs to access a property that's specific to OgreMonster, your class design is flawed and you need to rethink it.

There's another interesting topic here, and that's where you draw the line of additional subclasses. Take Blizzard's Diablo 2, for example. (It's a good example, because I know for a fact that it's written in C++.) Do you think they wrote a Skeleton class, a Ghoul class, a Sabercat class, and an Andariel class? Or to go further, did they write classes for BurningDead, Horror, Returned and all the other classes of skeletons you encounter?
They did not. There might be a Monster class deriving from Character, though I wouldn't even bet on that, and that Monster class is then configured solely by properties: which monster type it is, which model therefore is to be used, what class it is, what level, what special properties it has. There's behaviour scripts attached, and action scripts (e.g. those nasty oversized bugs that cast lightning every time they're hit). All that comes from data files - even the scripts. It's called data-driven design.

I'm just mentioning this because separate classes for Ogres and Goblins seem too specific for me.
But it's also a question of extensibility vs effort. It's easier to write a few specific classes than to write the environment that allows extensibility a la Total Annihilation.

Well, I guess this is where our problems begin to make a fork in the road.

If I could get his class factory to pass function pointers to the templated class, and then use them accordingly, I'm done, my quest is over, and I'm finding that one out now.

Good luck to you as well Dae :).

CornedBee

You're saying that we cant have Base class (templated) A = to a Derivedren B, C, D, or E?

We want to be able to pass a single *Object to a function, rather than a B, or a C, or a D, or an E...

This = impossible?

:eek:

Honestly, if they'd just give us the ability to recompile on runtime I'd be happy LOL.

Quote:

---

Originally Posted by CornedBee

What you're doing here is overdoing genericity. Or perhaps not, in a way. What it comes down to is this: CRender renders RenderableObject, CPhysics affects PhysicalObject and CWorld contains WorldObject. Whatever's not in these classes (or interfaces, more likely) is of absolutely no interest to these classes. Should you find that your CPhysics needs to access a property that's specific to OgreMonster, your class design is flawed and you need to rethink it.

---

You're right. I cant think of a case where that problem does exist, and I guess if it does occur then you're right I should rethink it rather than overloading methods. But I'll save that for when I actually encounter that problem.

BTW that was a typo, I meant:

Quote:

---

As I've said I've decided I cant think of any reason not to, and WILL put velocity, mass, coords, etc. that CRender, CPhysics, and CWorld may need in Object.

---

Shamino, don't you think that would be supremely complex?

Would you mind giving us an example of your ideal Object and derived classes so we can see why exactly you're avoiding putting velocity, mass, etc. in Object so much? Thats what EFnet and Gamedev recommended to do. I don't see any problem with that, the only reason I brought it up was because I was thinking ahead.

Oh yeah I forgot, thanks for the reminder CornedBee, I was planning on splitting it up into something like PhysicalObject, Renderable, nonRenderable, etc. as I read half an article about this months ago. Yeah that is an interesting topic, I wouldnt mind reading up on how to do that, haha.

Quote:

---

Shamino, don't you think that would be supremely complex?

---

Quote:

---

You're saying that we cant have Base class (templated) A = to a Derivedren B, C, D, or E?

We want to be able to pass a single *Object to a function, rather than a B, or a C, or a D, or an E...

---

Maybe in the actual creation of the system, yes, quite possibily, but the usage would be ultimately simple.



Also, in case you might be misunderstanding me, I would like to have OgreMonster control all of its own data, I don't want to split it up into a million classes, I <DO> want OgreMonster to have its own functions, its own data, so that everything can use OgreMonster correctly, I want the renderengine, the physics engine, the sound engine, everything, to be able to use OgreMonster as a client....

I ultimately wanna be able to do this (pulls up his project)

Code:

---

class Object
{
public:

        bool MarkedForDeletion;

        struct Location
        {
                float locx;
                float locy;
                float locz;
        };

};

class Cross : public Object
{
public:

        MS3DModel *Model1;

};

---

Then Ultimately..

Code:

---

    if (Obj != NULL)
    {
                Scene_Object_Manager::AddScene_Object(Obj);
    }

---

As you can see, I'd like to be able to push an Obj into the vector.... Not have to put a cross in there, or an OgreMonster, or a GoblinMonster, etc etc etc....

Then after that

we'll have a draw function in the render class simply file through that container of scene objects, grab their model data, and draw it accordingly...

Robert Geiman told me this

Quote:

---

You really want to be totally ignorant of the actual derived class type as possibe. Any class specific work should be done from within the class itself. For instance, in Quake 1 (which used C not C++) every game object had an Update() function pointer. This function pointer was called every game loop on ALL game objects, and this function pointer would just point to a class specific function for each class type. The same thing would be true of C++, except you'd have a virtual Update() function that each derived class type overrides.

---

Now that sounds like a plan.......

Then what did this mean? It implies you dont want Goblin to know its own information.

Quote:

---

Originally Posted by Shamino

The only arguement I have is about Goblin Knowing its mass and velocity, Goblin doesn't need to know those things, some other higher power does, (a physics engine)..

---

What you said in your last post, about it knowing its information and using it as a client, is exactly what I'm doing.

I think I get what you mean in your last post (even though your previous posts go against it), that you want the data to be in Goblin and not in Object? Is that what you mean? It couldnt be, because Goblin derives from Object and therefor has that data.

Your code works fine, just put MS3DModel *Model1; in Object, I mean what Object's couldn't be Rendered anyway? If there are some you can think of, just use CornedBee's advice and make a class RenderableObject and put MS3DModel *Model1; in that, and derive Goblin from that, and pass Goblin to CRender, which has parameter RenderableObject*.

I don't see you having any problem doing that Shamino.

Quote:

---

usage would be ultimately simple.

---

You don't even need a class factory to do what you want to, which requires you to have a few complex files, and register classes, and create classes, and adding it so you can add virtual functions for reach function is like you just agreed going to make it more complex. Besides that, I don't think the usage would be simple. When registering would you not have to pass a virtual function for each function your class contains? Wouldnt that be like up to 20 parameters, which could change if your classes functions change names or get removed or added. The class factory would also need to be able to accept any amount of parameters of virtual functions (...) too, so that would be fun to impliment. That is unless you made a function to add a virtual function one at a time, ie if your class had 15 virtual functions thats 15 function calls. On top of all of that, you do all of this simply to avoid a vtable lookup for each function when you're only doing this for Objects where they arent being called millions of times a second anyway (where it becomes a problem). I don't see where the complexity ends.

Quote:

---

Originally Posted by Shamino

Robert Geiman told me this



Now that sounds like a plan.......

---

Thats a great idea.

Only one vtable lookup (which I've said two times now isn't a problem unless you're calling it many times a second) thats pretty powerful.

I don't think I'll worry too much about virtual functions for my Objects. Especially when its only a few.

I contradicted myself in hopes of having his object factory be my answer, lol....

All I want is simple, but no one is saying how to do it....

I want to have a base Monster class

I want to have lots of little monster derivedrens...

I want to pass a MONSTER to my push_back call..

I want to draw what is in that vector!

I want what is in the vector to have all the little functions that the monster derivedrens have, therefore everything on the scene can do wtf they wanna do, and are created to do, (see monster derivedrens)

5 steps to uber object management....


I could pass the derivedrens of Monster to the vector instead, but then I'd have to add a case statement for every single monster, and ultimately have a 100 line long switch, figuring out which Monster derivedren to add to the vector.... (there must be a better way)....

This would solve my problem, but also be clunky and become long and unmanagable...

There we go, thats what you want eh Shamino.

Well, I've told you why thats unnecessary, as Bubba, Gamedev, and CornedBee have. Just to remind you if its accepting all Monsters, then shouldn't all Monsters have this data? Then simply have getters/setters for this data. You shouldn't need anymore than this data in your Render functions.

First solution: but if you do need data some other special subclass has that others dont, then you could just use virtual functions in Monster.

Second solution: I've said this already, but you can just make the function for Render a template so it can accept any class. The thing is that you would have to use an if statement in order to determine its this special subclass - so why not just overload the function for this special subclass instead. Templates are like overloading, so either way works, but templates reduce the amount of code.

Those are the two simple solutions that DO work.

Quote:

---

Well, I've told you why thats unnecessary, as Bubba, Gamedev, and CornedBee have. Just to remind you if its accepting all Monsters, then shouldn't all Monsters have this data? Then simply have getters/setters for this data. You shouldn't need anymore than this data in your Render functions.

---

NO, all monsters shouldn't have that data because not ALL monsters are alike, yet theyre ALL STILL CALLED MONSTERS!

Think of this like a real life situation....

we can call all mammals mammals because they give birth to live babies...

But even though a dog might have fur and a whale might have a blowhole, doesn't make them not mammals...

Therefore when we ask wtf is a mammal, we can say a whale is a mammal, we can say a dog is a mammal, even though they do completely different things....

Second solution doesnt work, well it does, but its clunky and would ultimately become unmanageable...

Solution one, thats the same as having 100 virtual functions in a monster baseclass, not happening!

Quote:

---

Originally Posted by Shamino

NO, all monsters shouldn't have that data because not ALL monsters are alike, yet theyre ALL STILL CALLED MONSTERS!

Think of this like a real life situation....

we can call all mammals mammals because they give birth to live babies...

But even though a dog might have fur and a whale might have a blowhole, doesn't make them not mammals...

Therefore when we ask wtf is a mammal, we can say a whale is a mammal, we can say a dog is a mammal, even though they do completely different things....

Second solution doesnt work, well it does, but its clunky and would ultimately become unmanageable...

Solution one, thats the same as having 100 virtual functions in a monster baseclass, not happening!

---

Not all Mammals have mass and velocity, etc.?

What kind of REAL example of information that Render would need that not all Mammals share?

The second solution is for RARE cases, as I've stated too many times, and therefor would not be unmanageable. If you used it for all subclasses of Object you could avoid virtual functions and since its used for all subclasses of Object it would not be unmanageable, it would just be one method. The problem with that is its going to create a function for every different class (in the background).

100 virtual functions? What kind of Render function do you have that needs to call 100 different functions from a generic type? Only in rare cases can I see Render needing specific information from subclasses of Object than Object does not contain, so there would be less than 5 at most.

"Object should contain all the information it needs to be rendered." - quote by 100 million people across the world. Somewhat similar to Bubba, CornedBee (who recommends RenderableObject instead), and Gamedev have said.

I think its you now thats asking too much, Shamino.

Whoa, we're not talking about just a render function anymore...

Ogremonster has to become a client to any engine I wish it to!

ONE CLIENT, for the physics engine to handle, for the renderengine to handle, for the sound engine to handle...

On top of that, each client instance has to be able to call functions specific to the client I.E ogremonster..

Okay,

You did clear up one thing in my muddled head of thoughts...


Okay, sure, you could virtualize render info, you could virtualize physics information, you could virtualize sound info...

but you can't virtualize per say, a blowhole function and a fur function...

there are tooooo many differences between each objects specific abilities to virtualize them all

That is where I'm getting 100 virtual functions..

Alright, why do Sound/Render/Physics need to call these blowhole or fur methods?

Quote:

---

Originally Posted by Dae

Alright, why would you want to virtualize a blowhole or fur method?

Why do Sound/Render/Physics need to know this information?

---

They don't.... But what would be the harm of giving them this information anyways? Would it slow us down?

But you virtualize, because every new instance of OgreMonster must be able to use its specifically designed, bashyourfreakinheadoff() function, or its specifically designed pickyouupandthrowyou() function....

And remember, if we're sending an ogremonster as an *Object, we would have to virtualize those specifically designed functions..
UNLESS

You pass pointers to those functions declared specifically in Ogremonster in ogremonsters constructor, therefore when you create the *Object you have access to those functions through pointers..

Wait wait, you're mixing me up...

WE DON'T want to virtualize the blowhole or the fur! And thats the problem! Because unless we don't, we can't access blowhole from the final *Object

Quote:

---

They don't.... But what would be the harm of giving them this information anyways? Would it slow us down?

---

It wouldn't slow you down unless your implimentation did (which some of your previous ideas would a bit). But if they don't need this information than there is no harm, so why continue looking for a solution to a problem that doesn't exist.

Quote:

---

You pass pointers to those functions declared specifically in Ogremonster in ogremonsters constructor, therefore when you create the *Object you have access to those functions through pointers..

---

Different subclasses of Object have different amount of methods, so you would have to be able to have an undeterminable amount of function pointers in your subclass - which I don't see happening. On top of that I don't see you being able to reroute those to the base Object class so they can be used to access the GoblinObject's methods. Furthermore the creation of an instance would include one hell of a long parameter (for the virtual functions) - 100 I think you stated. Lastly I don't see this as a logical solution.

Quote:

---

Originally Posted by Shamino

WE DON'T want to virtualize the blowhole or the fur! And thats the problem! Because unless we don't, we can't access blowhole from the final *Object

---

I realized that and editted my original post exactly before you posted.

Ok guys let me add my two cents here and that's probably what it will be worth. ;)

First
This design is already so complicated that you cannot even discuss it correctly.
Therefore - scrap it. It won't add to speed, graphics, gameplay, or even manage objects well. What it will do as evidenced by this thread is confuse the hell out of ya.
Scrap it.
Using one function as an overall function for rendering is a great idea, however, you are approaching it incorrectly.

Now pay attention because this is what Dae and CornedBee and Bob and all of us are saying. The ONLY common portion of any graphical object to be rendered are:

• Vertex data
• Texture data
• Physics data

Here is my suggestion. Throw templates out the window and throw the class inheritance virtual function thingy out the window. Too complicated. The problem with C++ inheritance is that when you look at your code you cannot tell at a glance what is happening because the inheritance is so deep.

Get my drift here. I don't like virtual functions because they obfuscate the code quite easily with more than 1 derivation w/o adding that much flexibility to the engine.

I don't like this:

Code:

---

class Base
{

  virtual void Render()=0;
}
class Derived1:public Object
{
  void Render();
}

class Derived2:public Object
{
  void Render();
}

class Derived3:public Object
{
  void Render();
}

---

Way too many renders for something that can be done in one function.

Here is what I do like:

1. Each object allocates it's vertex memory from a huge pool.
2. The pool manager will return a starting index and an ending index for the data.
3. Texture coord data is contained within the pool.
4. Physics data is contained within the pool.

Like this - ALL objects will have the following information, but not ALL objects will use every field in the structures. Texture coord data is contained in the VertexData struct I'll show this using vectors for now, later you would change to a static array IF your framerates suffered. I doubt they will.

Code:

---

struct PhysicsData
{
};

class PhysicsContainer
{
}

struct VertexData
{
};

class VertexContainer
{
};


struct PositionData
{
};

class PositionContainer
{
};

class MatrixData
{
};

class MatrixContainer
{
};

class TextureData
{
};

class TextureContainer
{
};


struct ObjectInfo
{
  DWORD dwStartIndex;
  DWORD dwEndIndex;
  DWORD dwID;
  DWORD *dwTextureIDs;
};


class Object
{
  ObjectInfo ObjectData;

  //One object may have more matrices
  //This is for transformation
  MatrixContainer        Matrices;

};

class ResourceCache
{
  PhysicsContainer  Physics;
  VertexContainer    Vertices;
  PositionContainer  Positions;
  TextureContainer  Textures;
};

class RenderList
{
  ResourceCache  *RenderData;
  std::vector<DWORD>  ObjectIDs;
};

---

So now all the main areas of information are encapsulated for each object and the rendering list simply has a vector that can be added to in order to create the render list. I would try to use a static array but the render list is built every frame so it's a bit tedious and time consuming.


The final render list simply holds a list of IDs that are indices into the other containers for that object. So.

Everything is based on IDs. The final result is that everything amounts to:

1 function call, 1 lookup.

If you make the arrays or vectors public in the container classes, then you don't even have to do the function call.

This is a bit complex, but in the end it is very easy to use - it's just hard to setup.

Sounds would use the same idea. All sounds reside in a sound container and can be accessed via their ID number.

The final render list is simply a huge list of IDs of the objects that are visible in the current frame. The transformation engine then just iterates through this list, grabs the vertex and position information for that ID, grabs the matrix stack (if applicable) from the object, and transforms the object. Then the renderer will grab the texture data, etc, etc.

This is a work in progress so there is still stuff to work out, but I hope you get what I'm saying here.

Har har, Dae

In Robert Geiman's object factory, do you understand what those incredibly ugly hacked macro functions do?

They create template support for up to 15 parameters, and you can easily change a single number in your code to add support for more...


Therefore, I can pass in OgreMonsters constructor, up to 15 parameters, (or more, depending on how much i feel we need)...


OMG its a perfect machine! I was right to begin with, with some modification this object factory is the holy grail...

Quote:

---

On top of that I don't see you being able to reroute those to the base Object class so they can be used to access the GoblinObject's methods.

---

Its a function pointer, it points to the function definition in the origional declaration of OgreMonsters class, which is sent to the templated Monster1...

So finally, and ultimately..

We can go Monster1->bashyourfreakinheadoff();

Okay cool bubba, but what happens when we need to send multiple objects to each engine? Each of them have different information based upon what the user gives them...

And then on top of that what about giving each object their own specific functions?

Each new instance of the object (if declared as an *Object), remember, Ogremonster is an *Object, but OgreMonster will have info declared only in ogremonster...

So therefore we need the template that creates the *Object to know how to access those specific things, so we put function pointers in the constructor so that the new *Object (Monster1)

can do this:

Monster1->Bashyourfreakingheadoff();'

or this

Monster1->getrenderdata();

or this

Monster1->getphysicsdata();

or this

Monster1->getsounddata();

You can view the PLAYER OF THE GAME as its own engine, this is where the need to access monster1->bashyourfreakinheadoff(); would be.

And this way, the render engine will get only render information by calling Monster1-> getrenderdata();, and render it...

Monsters only get registered if they are called by the user, or the gameworld (gameworld would have to create a map with no user interaction)....

Hey Bubba,

I'm sure you hate how people ask you a bunch of questions whenever you post, but..

How does your std::vector<DWORD> ObjectIDs; work? Like how do you get the ObjectData from the object instance associated with the ID's in the RenderList? A manager with a map holding the IDs and a pointer to their instance?

Thanks for the help BTW :)

Quote:

---

Its a function pointer, it points to the function definition in the origional declaration of OgreMonsters class, which is sent to the templated Monster1...

So finally, and ultimately..

We can go Monster1->bashyourfreakinheadoff();

---

I dont understand how that works out, but alright. If you get that to work I would love to see.

Code:

---

I dont understand how that works out, but alright. If you get that to work I would love to see.

---

Hm, well remember, I'm theorizing here...

And I theorize, the reason we couldn't access functions specific to OgreMonster from monster1 is because we lost the data, to remedy this, we send a pointer to the data, simple as that.

I asked, I thought you could send the object factory up to 15 arguements?

But, as Robert Geiman has just told me....

It does, but not variable parameters. That is, you can declare the object factory to accept 5 constructor parameters, but then you must pass 5 parameters for ALL monster classes. You can't pass 5 to OgreMonster and 4 to TrollMonster.

ARHG, back to drawing board...

Quote:

---

Originally Posted by Shamino

we send a pointer to the data, simple as that.

---

Well the reason I don't see it working is because it seems like you're forgetting something.

Sure, you could find a way to accept n (any amount) of parameters (you dont even need macro magic, just use ...), and sure you could pass n amount of function pointers (of a subclass) to the base class, BUT theres a problem in the next step.

Quote:

---

Its a function pointer, it points to the function definition in the origional declaration of OgreMonsters class, which is sent to the templated Monster1...

So finally, and ultimately..

We can go Monster1->bashyourfreakinheadoff();

---

You say it would be Monster1->bashyourfreakinheadoff();, but Monster1 doesn't just get extra functions because you passed it a function pointer. You would have to store that function pointer in Monster1, and then call a function that Monster1 has which calls the function pointer.

The problem is that Monster1 would have to have n amount of function pointers in this class, and n amount of functions to call that redirect to the function pointers. Your idea may work for one function pointer, but how in the hell do you plan to make it so Monster1 can have n amount of function pointer stored, and have functions for each one to boot.

I'd help you figure it out if I could see it happening at all. I'm very new to all of this, and don't know advanced C++ either, so its logical that I don't see anything working.

Quote:

---

Originally Posted by Shamino

But, as Robert Geiman has just told me....

It does, but not variable parameters. That is, you can declare the object factory to accept 5 constructor parameters, but then you must pass 5 parameters for ALL monster classes. You can't pass 5 to OgreMonster and 4 to TrollMonster.

---

Yeah, thats the part that was confusing me. I couldn't figure out how you were going to get a class to have n amount (any amount based on the subclass) of function pointers.

Read my edit, first of all this wouldn't work at all...

But, to answer your question, as if this would work...

if something points to something, it always points to it, no matter where you put it or send it...

if we pass bashyourheadoff pointer to the monster1 thingy..

and then call monster1->bashyourheadoff

simply all we're doing is referring back to the origional definition of bashyourfreakinheadoff, which is in ogremonster only... we can activate the function through the pointer, which now happens to belong to monster1...

but unfortunately, read what rob told me...

If we were to make this work we'd be the da vinci's of programming, but i don't see it happening.

Rob gave me this though, and it did give me hope...

Code:

---

class TrollMonster
{
public:
  virtual void Update()
  {
      if (daylight)
        TurnToStone(); // This function is ONLY specific to Trolls and doesn't exist in the base Monster class!
      else if (feel_like_dancing)
      {
        DoTrollDanceOfTrolls();
      }
      else
        DoSomeOtherTrollStuff();
  }

protected:
  void TurnToStone()
  {
      // Code to turn trolls to stone
  }

  void DoTrollDanceOfTrolls()
  {
      // Code to make troll dance
  }

  void DoSomeOtherTrollStuff()
  {
      // Troll stuff
  }
};

---

We virtualize a single Update function, along with a couple virtuals for rendering info, physics info, sound info and such...

Basically, the AI is handled in the Update function, or you could add to the virtualizedupdate function based on an AI engine...

We just throw an Update into a loop checking if the new Monster1 exists, if it doesnt, loop ends, no more updating for that monster and monster1 is unregistered and deleted...

I believe this is it what we're trying to do.

Quote:

---

Originally Posted by Shamino

Read my edit, first of all this wouldn't work at all...

---

I did, read my post.

Quote:

---

Originally Posted by Shamino

But, to answer your question, as if this would work...

if something points to something, it always points to it, no matter where you put it or send it...

if we pass bashyourheadoff pointer to the monster1 thingy..

and then call monster1->bashyourheadoff

---

That wasn't a question but yeah I understand that it points to it - duh.

But how is Monster1 able to have a function called bashyourheadoff just because you passed it a function pointer? You would need to store that function pointer and call it in another function, and since Monster1 is unaware of what functions you are passing it, it would not have a bashyourheadoff function, but it might have something called function1 which calls the first function pointer. However you're still unable to get n amount of function pointers and functions for those function pointers in the class.

I'm tired of rewriting that, read my old posts again if you still want to say you can call monster1->bashyourheadoff just because you passed its constructor a function pointer.

Monster1 is a mailman

All he does is deliver letters, he needs an address, he doesn't need to know who lives there, or whats in the letter...(I love it when my programming teacher is right)

Monster1 is an object, he has an address for bashyourheadin...

he doesn't need to know what bashyourheadin does to execute it as long as he has an address for it

Quote:

---

Originally Posted by Shamino

I believe this is it what we're trying to do.

---

I hope you're not talking about what I'm trying to do (and do know how to do), as I've known what I wanted to do for more than a page now and was just trying to undo what I did to your mind. I think I'm the one that got you hooked on this whole idea about render accepting a generic class without losing data and still remaining easily manageable. (even though I still think templated method is fine for that).

Yeah that Update a nice way to go about it, which I said when you originally posted it. It allows for differences in how things are handled in subclasses with one general method.

I keep forgetting our problems are seperate...

Lol, we're trying to solve them together... Bad mistake?

lmao... thats funny....

But anyways, I found my answer.... Rob's update function thingy...

My problem was passing a generic object to every engine in my game, not passing everything that the object has, only the information that the engine needs, so it's okay if I lose some data..

Just not what each specific engine needs...

Virtual functions would be an easy solution, but with 100 different specific functions that would have to be put in the base class, not good....

An update function is a solution to that, and hopefully, i'm thinking it is my final solution...

Quote:

---

Originally Posted by Shamino

Monster1 is a mailman

All he does is deliver letters, he needs an address, he doesn't need to know who lives there, or whats in the letter...(I love it when my programming teacher is right)

Monster1 is an object, he has an address for bashyourheadin...

he doesn't need to know what bashyourheadin does to execute it as long as he has an address for it

---

It doesn't matter.

Monster1 does need to know how many variables it has, and what functions it has. The amount of functions you send to Monster1 also varies, so how can that be possible?

Monster1 is unable to know the return type of bashyourheadin, or the name of the function its recieving so it cannot just up and create (or point) a function for itself called bashyourheadin.

You could do this if the amount of function pointers you passed was constant and you knew their return type and name, and created all of that in Monster1, but thats completely against the point of what you wanted to do. Since that would be the same as virtual functions.

Seriously, you can't just add functions to Monster1 because you pass 15 function pointers to its constructor. Nor could they use the same name as the functions you're passing.

Gah, I'm so done with this thread.

Edit: I dont have a problem to solve anymore, I've said that 10 times. I was replying to your problem for the last page and a half. Yeah, stick with the Update() function. Its good.

Okay, you're prolly right Dae (as I am more of a newbie than you, I gaurantee)

Only reason I though that is because robert didn't challenge that Idea when I gave it to him...

But it doesn't matter, I've solved my problem, yay...

We're both happy now :D

Defiently!

Eh, we're about the same level, its just easier to see how insane one is when its not yourself.

Theres no reason to be unhappy, its winter break damnit!

Can't wait to impliment the stuff I've read the past couple days. A lot my ideas on how to go about things was iffy before you started all these topics Shamino. :D

Questions lead to answers, and answers lead to this

:D:D:D:D:D:D:D:D:D:D
IM FREAKIN ECSTATIC ABOUT THIS!!!!

THIS IS SUCCESSSSSSSSSSSSSS

http://img.photobucket.com/albums/v131/Shamino/OMG.jpg

ONE CLIENT!!!!

MULTIPLE ENGINE USAGE!!!

I can't believe it, I programmed something INCREDIBLY OOP'd up and amazingly useful!

Nice!

P.S. I cant believe you're still using the class factory. You wont benefit from it the way you are using it. Its also slowing you down a little bit, and adding extra lines of code that aren't necessary.

Why is it slowing me down?

Adding lines of code?

What could be simpler?

Creating a new object in two lines of code

I can pass it as an *Object as well, which is the key issue here..

I'm using the language the way it was ment to be used, object orientedly, with virtual functions...

If it can realistically slow down and be noticeable just because of a few virtual functions, I'll blame that on the computer..

I think I can pass it as an object....

I hope.....

EDIT:

BTW, I added you to AIM, log on !

What could be easier is just creating an object of Ship yourself. Why go through this sidestep of giving the class factory a function pointer to your class and an id, and then two lines later call a new object of that class?

Its slowing you down a little bit because you're putting the pointers in a map which takes O(log n) to search. Whereas you could just instantiate it because you already have access to it. Just #include the header file and CGoblin SomeGoblin;.

A few pages back, I mentioned why this class factory isn't what we thought it was on the first page. But if you have some reason to be assigning classes to id's when you already have access to them, alrighty.

BTW, I could be wrong, but I reread Bubba's post a couple more times and I don't think you have it implimented the way he has it. Just so you know. If you reread it concentrating on the pool part and using id's part.

EDIT: I posted this before reading the last page. Mea culpa. Ignore if you feel like it.

You're theorizing without keeping one foot on the ground. As a result, you think up "great ideas" - but they're actually quite useless.

With your bashyourheadoff() method, it seems that you think it's necessary, but have you even tried to think up a concrete example of a situation where the PlayerEngine has to call it?

Let's for a moment assume the game is a Gamboy Pokemon-style round-based fighting game. You're in a fight with the Ogre. What does the game really need to know?

1) It needs to render an image of the ogre in the lower right corner. Character::getFightImage() is one virtual function that is required for this.
2) It needs a list of attacks the ogre can do. Character::getAttacks() is a virtual function that returns a list of Attack objects. (Actually, both these functions would be non-virtual and read from data files, but let's go with your split objects here.)
3) Each Attack object has attached a name that can be displayed to the user, perhaps an ID, perhaps an animation of the attack itself.
4) In addition, there's a Character::getAttackSequence(Attack*) to get an animation of this monster executing this particular attack.
5) Finally, you need Character::getAttackValue(), Attack::getBaseDamage() and Character::getDefenceValue() (for the player) to calculate the damage the attack did.

Did you see bashyourheadoff() anywhere?



On a side note, templates are done at compile time, so you can't step from runtime polymorphism to compile-time polymorphism. The moment you store the monsters together in a list, you've lost their type information.

To answer the question of IDs:

An ID is simply the index of the object in the index which contains all of the game objects, or at least all of them for the current level, or the current map area that has been loaded in (say in a flight sim).

You don't pass multiple objects to the renderer Shamino. In fact you don't pass any objects. The render function is composed of a frustrum culler that firsts trivially rejects all objects that are not in the frustrum. Once the trivial rejection is complete you could code another more accurate function but I did not for good reason. Given the complexity of objects and given that most objects will completely be inside of the frustrum or completely outside, it did not make sense to waste CPU cycles on figuring out how to split complex objects across frustrum planes. So I pretty much just let brute force hardware do it. It's not the best, but it is better than using complete brute force.

Once the object passes the tests it's ID is then put into the final render list. So you are guaranteed that at the end of the cull, you are only computing physics and other information for those objects that are visible or could be visible. Now in a flight sim where physics are computed for every object, you only do that in memory so they still don't need to be in the render list. For FPS games there really is no need to compute physics info for monster A that is 500m away from your position, unless your engine supports real-time monster movement. If you notice, most games don't. Most game worlds are quite static and for good reason. They try to cover the static portion by making the monster act realistic 'when he is visible or near', but when he is out of bounds, he really doesn't exist.
Derek Smart tried to create a fully functional real-time space sim with Battlecruiser 3000AD and had major problems. BCM actually comes quite close to doing it well, but still suffers. Don't get me wrong his engine actually does it very well, but I think that graphics suffer due to the load from the other systems updating the universe.

The point is, if you cannot see it, don't render it. If you are not anywhere near it, don't update it.

Ok, now you have the render list. Now transform, do the physics calcs, collision test, and render.

See the render list is built every frame or in a really good system, it is cached and re-used. As objects leave the frustrum they are removed from the list. This is NOT easy to code but it is a good system. This is why I've been slamming my head against a wall trying to get this stuff working.

I don't use Object factories, I use vectors and arrays or simply container classes. Objects are just that - objects. So treat them as such. It is a whole lot easier creating containers to manage the separate portions that make up the whole than creating several objects with identical functions. My system basically has resources that are out there in memory to use at any time. All you need is the index. The index or ID is a universally unique identifier for ALL vectors/arrays. So object 1 is at physics 1, vertex data 1, etc, etc.

So this render list:
2,10,400,10000,14000,23,40,55,6782

Would mean that objects with these indexes are currently in the frame and need attention. But you still need to do some type of quadtree cull and then a frustrum cull to get the data size down to something the CPU could do in this lifetime. The quadtree or BSP would determine which objects are at least in proximity of the player. The frustrum cull would eliminate those objects close to the player that he cannot see. You would probably update physics information for all objects that passed the quadtree so that objects behind the player can still fire on him, move, etc.
But you only draw the one's that pass the frustrum cull.

Huge array of data
- QuadTree test - close to the player, store and cache
--- Frustrum Cull - visible - store and cache, and render

Update all objects that pass QuadTree test - maintain cache and remove items that are no longer in proximity.

Only draw those that pass the frustrum cull test. Cache these as well for quick reference. If an object fails the frustrum test - remove it from the list.

Perhaps Bob and I should get something like this up and running.
Don't get me wrong, it's not easy and it's not really fun programming, but it is extremely necessary.

So you see that if your resource cache is in such a state as to be unusable or overly 'C++' then when it comes time to start using the data and objects you will have a huge mess.

Keep it simple and straightforward. No one cares how you get it done, just that it's fast, usable, robust, and does the job well.
Don't use OOP just for the sake of being OOP elite or something. It is a tool that can be used, but it can also be abused.

In my system the container classes handle all accesses to the objects they contain. You do not create the objects but you do ask the container class to create them. So I guess it is a factory of sorts, but I avoid all the templates, pre-processor, and functor issues in C++. A member function pointer cannot be called w/o being called from an object. You cannot easily assign a member function pointer to point to a non-member function. Look up functors. A good topic for containers would be singletons as well.

Final word. Use inheritance and virtual functions wisely.

I'm not saying this is the only way to do it, but it works for me.

This warrants another post.

You also do not want to hard-code functions that perform actions per se. Your script system should be closely connected to the engine so that it can manipulate objects at will - again based on IDs.

Your system should be message based. Instead of the system always querying for information you need to get to the point that the systems can communicate back and forth. If an object needs attention then the object should be sent a message through the message system.

This changes the whole paradigm of games programming because once you get this working you can now create demos and testbeds for the game by simply writing a script. Instead of this:

Code:

---


if (Mouse.Pressed(Controls.dwFire)
{
  Object->Fire();
}

---

You have this:

Code:

---

if (Mouse.Pressed(Controls.dwFire)
{
  MessageSys->SendMessageToObject(MSG_FIRE,Object,TargetObject)
}

---

So now when you do the multiplayer, you just look at the incoming message and send it to the system and it will do what you want. For scripts you simply interpret the script and then relay the correct message and the action is performed.

It's a lot like Win32 programming and the systems for it. Hopefully not as messy or slow, but you get my drift.

Notice the sheer genius of the MSG structure in Windows. This one structure is applicable to all windows objects and every object relies on it. This is what you need for your game. That way you can use one function to send messages and based on the message, the parameters will have diff meanings.

In Windows to repaint a window you can either call your Paint function or you can send a message to a window provided you have its handle. But Windows does not specifically call the Paint function for that object. It sends a message and the object(s)responds to it. This allows any implementation of the WM_PAINT message and allows any function name to be used. Much the same for bashyourheadoff(). If you hard-code it, you will code yourself into a corner.

What does Windows do? It calls your WndProc() and the MSG is a parameter. You then act on the message and the Windows SDK tells you what that message is pertaining to and so you code your implementation of it.

Get a message system up and running soon after your resource system. And when you design your resource system and all systems keep in mind the underlying message-based structure. There is more to talk about concerning documents and views, the document being the game data, and the view being the render. If you implement this right, switching cameras is a simple matter of switching views.

Ah, I see Bubba, thats how I thought you meant it (after rereading it a few times). Of course besides the specific game programming lingo, that I haven't learned yet. Your system definetly seems efficient. I'd love to make a newb version of it, haha, too bad I won't be able to impliment anything of the sort until I learn more about the specific game programming part.

Thanks for the help of course, anything I can get. :)

I'll continue following your work, I think this is the forth topic you've shared insight on your engine.

Well my 'engine' so to speak is not anywhere close to this. This is my design philosophy. The engine died a horrible defrag death - so I'm recoding it. I did recover a lot of my lost files from my dev team but it will need some re-work.

The engine for the Zelda remake we are doing is the same engine I used in XSpace. Starting over in XSpace allows me to implement this design from the word go. This will speed up development and plus the new blender version exports into X file format. Quite nice. Now to learn blender, which doesn't look fun. Perhaps some modellers are in order here.

Also going to rewrite the DX sound engine to use DirectSound instead of DirectMusic. Did some more research and seems DSound has more to offer. It is possible to get DSound from DMusic so I will prob go that route. My music system unfortunately died in the defrag as did my animation system so I must start over. The music system is fairly simple and the animation is well a pain in the arse but I'll get it.

I'm learning just as you guys are. It's threads like this that helped me.
Very good thread.

Message-based systems are very interesting, but they can cause problems when you try to track what's going on in the game. And unless your message system is good, it can lead to very ugly and unmaintainable code. (I would, for example, consider Win32 messages quite ugly.) Nevertheless, the decoupling it offers is a great advantage.
Messages also allow very interesting effects. For example, pressing the move forward key in some games might not directly make your character move, it might send the game server a request to move forward. This game server might be on a remote machine, or in-process - many games, like Quake 3 or Diablo 2, realize single-player games by launching a local multiplayer server. The game server then sends a move message back to the client, which makes your character move.
One visible effect of this is phantom hits in Diablo 2. The server and client, although running in the same process, are effectively independent. Now, in multiplayer the server might be on a remote computer, and messages might be delayed. For this reason, Diablo calculates many things, in particular projectile hit testing, twice - once on the server for the game mechanics, and once on the client for graphics. Sometimes the two disagree. When that happens, you can see monsters die from your fireball, but the fireball itself flies on. This can even happen in single player, because server and client are still separate.
Nevertheless, it's a nice example of message passing. The physics engine on the server makes the fireball move, and tests intersections with monsters. When they intersect, it does damage, potentially sending kill messages. These messages reach the client, and you see monsters die apparently without having been hit.

Hmm, Bubba,

Theres just two things I don't understand:

1) How do you have something tracking all the game objects when subclasses are different? If you were using a map you'd have to use Object*, which is the base class and you lose methods specific to the subclass. Are you keeping track of just Object* and then using a virtual method (thats doubtful) to send commands to which would reach the subclass, where a huge switch statement would be? :confused: I doubt that because you said Object->Fire();, which means you have access to specific subclass methods. So are you keeping track of every subclass in its own map or such? but wouldn't that be quite hard considering youd need to add a map for every new subclass, and find a way to organize their id's correctly to boot.

2) How do you get a return value from a system message to that command scope from Object (that might be needed)? MessageSys->SendMessageToObject(MSG_FIRE,Object,TargetObjec t)

I like the idea, definetly. I'm still unsure about how to go about it though so I'll stick with the basics for now, but as soon as I can I'll attempt a message system.

ad 1) Plain Object*. (Although in his system, it's something similar but not identical.) His system is constructed in a way that he doesn't need to access the subclasses' methods. It's in the messages. And there's no need for a switch statement either - what would that do?

ad 2) You don't. If there's a response, the target of the message will in turn send a message back.

Quote:

---

Originally Posted by CornedBee

ad 1) Plain Object*. (Although in his system, it's something similar but not identical.) His system is constructed in a way that he doesn't need to access the subclasses' methods. It's in the messages. And there's no need for a switch statement either - what would that do?

ad 2) You don't. If there's a response, the target of the message will in turn send a message back.

---

In his example he used the method Fire(), which would be a subclass method, eh? Also hes going to need to access subclasses eventually, and if everythings based on ID then I dont see any other choice than storing the entire subclass to be accessed (no upcasting to Object*).

What if in if(Mouse.Pressed(Controls.dwFire)) theres a few messages to send. The first sends something, the second is based the result of the previous, and the third is based off the previous. You'd need that message to be immediate because the next message depends on the results, and to be sent to the middle of that if statement (aka. something returned).

EDIT: I assumed MSG_FIRE is an ID to a command Object is to perform on TargetObject, and Object and TargetObject are IDs to their corresponding objects. You said it then processes what the command is... how do you do that other than a switch/if?

Another thing I don't get is what if the messages are more complex than just 3 parameters.. overload a ton of message abilities?

Well at the base level it is a switch. This may seem odd but it will end up looking like a MsgProc in Win32 programming. But when you get it working you can implement other things like multi-player, GUI, etc, quite easily. Just add more messages.

The message system needs to be robust. In fact you should create a RegisterClass function that actually registers the object with the system. The system then contains a pointer to the message function in the class. You must use a functor for this which is annoying, but you can get it to work. This way all Objects can receive messages and you know where they are going to receive it at. As well each Object will have a message queue so that messages can be pumped and/or retrieved/sent to other objects, etc, etc.

You can use inheritance to derive from Object. Object would contain the default function for handling common messages. However there are other ways to do this. In my theory, the default handler is inside of CMessageSystem and each message is a class in itself. So you have this:

CMessageSystem
--CMessageRouter -> sends/receives CMessage(s)
--CMessageHandler -> default handler class for default behavior on messages

CMessage

What needs to be sorted out is that if the class does not re-define a message handler for the message, I need to auto-call the default handler. I haven't quite figured out how to do this w/o having a lot of macro crap.

Hmm, Object would contain the default function for handling common messages. Wouldn't that be the switch of some sort? or some type of lookup. Wouldn't there have to be some virtual function somewhere in order to access subclasses methods because you're storing Object*'s?

Sounds like one hell of a tied up framework. Too bad I'm not even doing multiplayer so I can't take advantage of all its features.

Quote:

---

Originally Posted by Dae

Hmm, Object would contain the default function for handling common messages.

---

I'd say that would be more of an "Update" function, in my case Dae...

Yes, well, that would be a virtual method. Theres 2 reasons why that doesn't make sense. 1) Bubba's against virtual methods and hasnt said it was virtual when I mentioned it. 2) If it is virtual then the handling would be done in the subclass too (because you'd have to have a method in the subclass (Update) to call those subclass methods based on the parameter), but Bubba said the handling was done in the base class.

But without it being virtual, I don't see how you're using Object*'s and calling methods of the subclasses from the base class. Thats the most confusing part.

EDIT: I have another question, if you're working off all ID's, then wouldn't retrieving the instances to use all the time from a map be O(log n) instead of O(1), and wouldnt that be a lot of calls? Or is that not an issue in a network game.

You only retrieve IDs when needed.

Code:

---


DWORD dwNeededID=ObjectContainer[x].dwID;
DWORD dwCacheID=0;


if (m_dwCurTexID!=dwNeededID)
{
  bool InCache=TextureCache.IsInCache(dwNeededID,&dwCacheID);
  if (!InCache)
  {
    //Cache miss
    Device->SetTexture(0,TextureContainer[dwNeededID]);
    m_dwCurTexID=dwNeededID;
    TextureCache.PutInCache(dwNeededID);
  }
  else
  {
    //Cache hit
    Device->SetTexture(0,TextureContainer[dwCacheID]);
    RendererCache.Update();
    m_dwCurTexID=dwCacheID;
  }

}

---

I'm afraid I don't understand why you are not understanding how this works.

I understand how that works. You're passing around the ID. I see now how you're using it, that the search wouldn't be necessary.

The only thing I'm still unclear on is your messaging system. You are sending the Object commands, which are handled in the base class Object. Now you said it would use something along the lines of a switch to resolve the command. Now if SHOOT_FIRE is the command, which is part of the subclass Sorcerer, how do you call that function when you're using a container of Objects? You'd have to make the handler in Object virtual, and overwrite that handler in the subclass Sorcerer to add more command handling specific to Sorcerer (probably calling Object's handler first to see if it can handle it). Is that wrong? does it have more to do with the functor thats giving you the ability to call subclass methods?

Sorry for bothering you, but I just couldn't figure out how that part worked. I did try to make some pseudo code before I posted though.

To give you an idea of how this ID stuff works I'll show you my animation class system.

Note this class is for Windows GDI. DirectX would look just a tad different.

CAnimSystem.h

Code:

---

#ifndef CANIMSYSTEM
#define CANIMSYSTEM


#include "CTileSystem.h"


class CAnimSequence;

class CAnimFrame
{
  friend class CAnimSequence;
  DWORD m_dwTileID;
  float m_fFrameDuration;
  CPoint m_XYOffsets;


  public:
    CAnimFrame(void):m_dwTileID(0),m_fFrameDuration(0.0f),
                    m_XYOffsets(0,0) {}

    void Create(DWORD dwID,float fFrameDuration,CPoint XYOffsets)
    {
      m_dwTileID=dwID;
      m_fFrameDuration=fFrameDuration;
      m_XYOffsets=XYOffsets;
    }

   

};

class CAnimSequence
{
  std::vector<CAnimFrame *> AnimFrames;

  CPoint m_Position;
  DWORD m_dwCurFrame;
  float m_fAccumTime;

  CTileManager *m_pTileManager;
  bool m_bLooping;
 
  public:
    CAnimSequence(void):m_dwCurFrame(0),m_Position(0,0),m_bLooping(false),
                        m_fAccumTime(0.0f) {}

    virtual ~CAnimSequence(void)
    {
      AnimFrames.clear();
    }

    void Create(CPoint pos,CTileManager *ptrTileManager,bool bLooping=true)
    {
      m_Position.x=pos.x;
      m_Position.y=pos.y;
      m_dwCurFrame=0;
      m_pTileManager=ptrTileManager;
      m_bLooping=bLooping;
      m_fAccumTime=0.0f;
     
    }

    void AddFrame(DWORD dwID,float fFrameDuration,CPoint XYOffsets)
    {
      CAnimFrame *frame=new CAnimFrame();
      frame->Create(dwID,fFrameDuration,XYOffsets);

      AnimFrames.push_back(frame);
    }

    void SetFrameData(DWORD dwID,float fFrameDuration,CPoint XYOffsets)
    {
      if (dwID<AnimFrames.size())
      {
        AnimFrames[dwID]->m_fFrameDuration=fFrameDuration;
        AnimFrames[dwID]->m_XYOffsets=XYOffsets;
      }
    }

    void Reset(void) {m_dwCurFrame=0,m_fAccumTime=0.0f;}
    void Update(float fTimeDelta);
    void Draw(CDC *pDC,int iScrollX=0,int iScrollY=0);

};


class CAnimSequenceContainer
{
  std::vector<CAnimSequence *> AnimSeqs;

public:
  CAnimSequenceContainer(void) {}
  virtual ~CAnimSequenceContainer(void)
  {
    AnimSeqs.clear();
  }

  void AddSeq(CAnimSequence *ptrSeq)
  {
    AnimSeqs.push_back(ptrSeq);

  }

  void Update(float fTimeDelta)
  {
    for (DWORD i=0;i<AnimSeqs.size();i++)
    {
      AnimSeqs[i]->Update(fTimeDelta);
    }
  }

  void Draw(CDC *pDC,int iScrollX=0,int iScrollY=0)
  {
    for (DWORD i=0;i<AnimSeqs.size();i++)
    {
      AnimSeqs[i]->Draw(pDC,iScrollX,iScrollY);
    }
  }

};


#endif

---

CAnimSystem.cpp

Code:

---

#include <stdafx.h>
#include "CAnimSystem.h"
#include "MainFrm.h"
#include "ZeldaEditorView.h"



void CAnimSequence::Update(float fTimeDelta)
{
  m_fAccumTime+=fTimeDelta;

  if (m_fAccumTime>=AnimFrames[m_dwCurFrame]->m_fFrameDuration)
  {
    m_fAccumTime=0.0f;
    m_dwCurFrame++;
    if (m_dwCurFrame>AnimFrames.size())
    {
      m_dwCurFrame=0;
      m_fAccumTime=0.0f;
    }
  }
}

void CAnimSequence::Draw(CDC *pDC,int iScrollX,int iScrollY)
{
  //Draw to pDC with TileDC

  if (AnimFrames.size()>0)
  {
    CRect rect;
    CMainFrame *ptrFrame=(CMainFrame *)AfxGetMainWnd();
    CZeldaEditorView *ptrView=(CZeldaEditorView *)ptrFrame->GetActiveView();
    ptrView->m_wndTileRenderer.GetClientRect(&rect);

    DWORD m_dwTileID=AnimFrames[m_dwCurFrame]->m_dwTileID;
    CDC *TileDC=m_pTileManager->GetDC(m_dwTileID);

    int ScreenX=m_Position.x+AnimFrames[m_dwCurFrame]->m_XYOffsets.x;
    int ScreenY=m_Position.y+AnimFrames[m_dwCurFrame]->m_XYOffsets.y;

    m_Position.x=ScreenX;
    m_Position.y=ScreenY;

    ScreenX+=iScrollX;
    ScreenY+=iScrollY;

    if (ScreenX>rect.left && ScreenX<rect.right && ScreenY>rect.top &&
      ScreenY<rect.bottom)
    {
      pDC->BitBlt(ScreenX,ScreenY,
                  ptrView->m_wndTileRenderer.m_RenderInfo.dwViewTileSize,
                  ptrView->m_wndTileRenderer.m_RenderInfo.dwViewTileSize,
                  TileDC,
                  0,0,
                  SRCCOPY);
    }
  }
}

---

And to answer the questions of monster problems.

This would be much better:

Code:

---


enum Modes 
{
  SET_X=0x01,
  SET_Y=0x02,
  SET_HEALTH=0x04;
  SET_STAMINA=0x08;
};


struct MonsterAttributes
{
  int iPosx;
  int iPosy;
  int iHealth;
  int iStamina;
 
};

class Monster
{
  DWORD m_dwID;
  MonsterAttributes MonsterInfo;

  Monster(void);
  Monster(const MonsterAttributes m);
  Monster(const Monster &m);
  virtual ~Monster(void);
 
  void SetInfo(int mode,int value)
  {
  if ((mode & Modes::SET_X)==Modes::SET_X)
  {
    MonsterInfo.iPosx=value;
  }

  ...
  ...
  }
 }
};

class MonsterContainer
{
  std::vector<Monster *>  Monsters;

  //Cannot copy monster container
  MonsterContainer(const MonsterContainer &m) {}
  MonsterContainer &operator (const MonsterContainer &m) {}

  public:
    virtual ~MonsterContainer(void)
    {
      for (int i=0;i<Monsters.size();i++)
      {
          //MSVC 6 bug
          if (Monsters[i])
          {
            delete Monsters[i];
          }
      }

    }
    DWORD Add(MonsterAttributes &attr)
    {
      Monster *m=new Monster(attr);
      Monsters.push_back(&m);
      return Monsters.size()-1;
    }
 
    bool Remove(DWORD dwID);
    void Update(void);
    ...

};

---

There really is no need to derive from Monster.

Ohhh I see now. The containers do their own thing with the IDs, but the IDs match up to the ID returned from your monster container?

What I thought was going on was you had an Object Container and were using that to get your object instances based on ID and then worked with those (originally I assumed a map). So what do you do if you want to add extra functionality to a Monster? For instance FireBall(), when not all Monsters should have that method? Just add every method to Monster? Or add some scripting/retrieve from file system that CornedBee was talking about and Diablo?

That makes a lot more sense now at least. I was trying to get some psuedo c++ code (obviously bubbeudo), but I found if I was retrieving Object's from an ObjectSystem then there would be no use for a functor (because I could just call it from the object), therefor a map (in MessageSystem) either, so that didn't match up with what you were saying.

Would inheriting from MessageSystem solve the problem to have them use the default handler unless defined? might be kind of illogical though.

This is some of the bubbeudo I got from your posts, without all the bells and whistles, in order to try and grasp the message system (I think I failed):

Code:

---

#include <iostream>
#include <vector>

#include "windows.h"

struct ObjectInfo;
class Object;
class ObjectContainer;
class Message;
class MessageSystem;

class Message
{
public:
    std::vector<DWORD> ObjectIDs;
    std::vector<DWORD> CommandIDs;
};

struct ObjectInfo
{
    DWORD dwStartIndex;
    DWORD dwEndIndex;
    DWORD dwID;
    DWORD *dwTextureIDs;
};

class Object
{
private:
    ObjectInfo ObjectData;

public:
    //queue and such here

    void RecieveMessage(Message* p_Message)
    {
        HandleMessage(p_Message);
    }

    //enum commands { FIRE, ICE, LIGHTNING }

    void HandleMessage(Message* p_Message)
    {
        //handle all commands in the message
        for(int i = 0; i < p_Message->CommandIDs.size(); ++i) {
            switch(p_Message->CommandIDs[i]) {
                case 1: Fire(p_Message->ObjectIDs[i]);
                break;
                case 2: Ice(p_Message->ObjectIDs[i]);
                break;
                case 3: Lightning(p_Message->ObjectIDs[i]);
                break;
            }
        }
    }

    void Fire(DWORD dwID) { std::cout << "Fire! on " << dwID << std::endl; }
    void Ice(DWORD dwID) { std::cout << "Ice! on " << dwID << std::endl; }
    void Lightning(DWORD dwID) { std::cout << "Lightning! on " << dwID << std::endl; }

    DWORD GetID(void) { return ObjectData.dwID; }
    void SetID(DWORD dwID) { ObjectData.dwID = dwID; }
};

class ObjectContainer
{
    std::vector<Object*> m_Objects;

    static ObjectContainer* m_Instance;

public:
    Object* GetObject(DWORD dwID)
    {
        return m_Objects[dwID];
    }

    DWORD Add(void)
    {
        Object* Obj = new Object();
        Obj->SetID(m_Objects.size()-1);
        m_Objects.push_back(Obj);

        return m_Objects.size()-1;
    }

    bool Remove(DWORD dwID)
    {
        delete m_Objects[dwID];
    }

    static ObjectContainer* Instance(void)
    {
        if(!m_Instance) {
            m_Instance = new ObjectContainer;
        }

        return m_Instance;
    }
};

ObjectContainer* ObjectContainer::m_Instance = 0;

class MessageSystem
{
private:
    //std::vector<DWORD> m_Registered;
    static MessageSystem* m_Instance;

public:
    void RegisterObject(DWORD dwID)
    {
        //
    }

    void SendMessageToObject(Message* p_Message, DWORD dwID)
    {
        ObjectContainer::Instance()->GetObject(dwID)->RecieveMessage(p_Message);
    }

    //enum commands { DIE, STUFF }

    void HandleMessage(Message* p_Message)
    {
        for(int i = 0; i < p_Message->CommandIDs.size(); ++i) {
            switch(p_Message->CommandIDs[i]) {
                case 1: //Defualt1();
                break;
                case 2: //Defualt2();
                break;
            }
        }
    }

    static MessageSystem* Instance()
    {
        if(!m_Instance) {
            m_Instance = new MessageSystem;
        }

        return m_Instance;
    }
};

MessageSystem* MessageSystem::m_Instance = 0;

int main()
{
    ObjectContainer* ObjCon = ObjectContainer::Instance();
    MessageSystem* MsgSys = MessageSystem::Instance();

    DWORD Obj = ObjCon->Add();

    //MsdSys->RegisterObject(Obj);

    Message* Msg = new Message;
    Msg->CommandIDs.push_back(3); //Lightning Command 3
    Msg->ObjectIDs.push_back(2); //Use Command on Object 2
    Msg->CommandIDs.push_back(1); //Fire Command 1
    Msg->ObjectIDs.push_back(4); //Use Command on Object 4

    MsgSys->SendMessageToObject(Msg, Obj);

    std::cin.get();
}

---

As you can see, HandleMessage() has a switch, and thats the only way I could visualize it. Maybe its the handler that I'm ultimately unclear on. Like if you're recieving messages that use command IDs like FIRE_BALL, then wouldn't you HAVE to use a switch to resolve the function. And if you did derive from Object in my example, then you would have to make it virtual and overwrite it in the derived so it could call its new methods. See why I'm so confused? lol.

Anyway, feel free to give up on me whenever - I won't mind. I'm having a hard time understanding because my experience with game programming is: few days; my experience in c++ is: 6 months (include vacation/school/learning flash/java).

EDIT: Updated the bubbeudo a bit based on your last posts before I go out.

EDIT: I'll reread all your posts and see if I can impliment some stuff and hopefully understand whats going on.

Quote:

---

Would inheriting from MessageSystem solve the problem to have them use the default handler unless defined? might be kind of illogical though.

---

Scratch that. It's really stupid and illogical to do that for every class just to use the default handler. Lemme know if you figure out a way without macro magic.

Quote:

---

but I found if I was retrieving Object's from an ObjectSystem then there would be no use for a functor

---

Scratch that. I see why the functor was necessary, since it might not always be Object's you're working with. I just missed that because you went off talking about Object's.


I'm still unclear on the handler using a switch or not, and how to pass MSG_FIRE instead of a number - that require either a macro, global const, or global enum?

EDIT: I guess if the message system was that robust there would be a global enum or enum in the handler class or something.

EDIT: Found a nice powerpoint on scripting: http://www.cmpevents.com/sessions/GD...sy_UPDATED.ppt

Quote:

---

Use script handlers
- For flexibility and prototyping
- To avoid C++ dependencies
- Reduce C++ subclasses

Use C++ handlers
- For special arg handling
- Performance, maintainance

---

It answered my question on how to handle a special amount of arguments and a few other things. Still though, I have a lot to learn before I can impliment this message system or scripting system.