So now...

Now I have a working MS3D Model Loader, a Working Render Engine, though it may be a small and nearly featureless one, I got one that works.

My next logical step is to create an Object class, and many derivedrens for each individual object I want to be in my world, Using proper inheritance I can make a powerfully object oriented game engine.

Each object will contain information telling us where in 3d space each model is. I will create a Mobile class which inherits Object, that will also contain movement variables, e.g, How fast can this object move? How fast can it accelerate? How fast can it turn? Etc etc... Also an index to a model the Mobile will need to use... Or in case the object doesn't have a three dimensional object already created for it, We'll store a Texture ID or two as well as a pointer to where the model is defined (maybe a box, or something like that, that we don't have an MS3D file for)..

I will also have a Statics class which inherits Object, this class will be essentially the same as mobiles, except for one key difference, these objects are "dummies", as in, they don't have their own movement variables, all they do is hold a location in space and maybe some extra information.. For instance,Things like resource type, resource amount... For resource production....


So This is the stage in my project I am at right now.... After I do all this junk I will plan on making enemy AI... This is the tough part, we have to add flight sim mathematics in for each AI ship so that they can be a competent opponent...

All this spacethemed dogfighting accompanied by a HOT techno metal track my friend made.... Will definately make for some intense space combat, on a very large scale!

My vision is this, remember episode three, of star wars? The game will be an RTS, meaning you can control each ships individual orders, (or follow prebuilt attack plans you can make back at base), all while fighting along side your AI pilots, pwninating capital ships and battlecruisers, FREAKIN SWEET!!

Any suggestions?

Yeah don't use inheritance for your rendering system. I would only use it on GUI. At most, I would use one layer of inheritance on objects with very limited, if any, virtual functions.

Perhaps some others here might want to expand on why.

Well the only things the objects have to do with the Renderer is this, they are like a client to the render engine...

Each individual object holds a pointer to an MS3D Model.

An example of the inheritance I will use would be like this:

Objects->Mobiles->Ship1


the Ship1 class will hold a pointer to a ship1 Model, as well as location information, and among other things, speed variables, etc etc...

Another function Loads all the models I tell it to (ship1.ms3d would be included)

Now we pushback all the individual objects into a vector (only if the world class requests that they do so!!!), we use a nifty "AddObjectsToRenderer" function for this :D...

then we Draw all the models according to the vector we just made, changing the locations given by the objects (like Ship1)...


It seems so ingenious, where could it go wrong bubba? Please enlighten

Bubba the Pirate!

As of now I will not be using any virtual functions in the Objects master class, there might be 1 or 2 virtual functions for mobiles (because they all move? right?) None for statics, I don't think...


I feel like I'm sounding like a competant programmer alluva sudden, when did this happen?

Quote:

---

At most, I would use one layer of inheritance on objects with very limited, if any, virtual functions.

---

Yeah, using inheritance can be useful only under certain conditions in my experience. As Bubba stated, I also try to stay away from multiple levels of inheritance. In my personal experience it just makes things turn into a mess much easier...it has made finding certain bugs harder, and in general I have stayed with a single level of inheritance. I suggest you experiment though. Other C++ type languages such as java have decided to sidestep the multiple inheritance aspect of the language altogether.

This isn't to say, however, that I haven't had a single object derive from multiple other objects. A spacecraft may want to derive from a mobile class, from, oh, I dunno, a 'pathfinding class,' or some sort of AI class, as a palette for its entire functionality...but as long as each of the classes it derives from don't derive from anything else, then it's not multiple levels/layers of inheritance.
One added thing, not that this is something you really care about at this stage in your game programming, but there are also hidden costs associated with making classes that are purely virtual. A virtual function is really just a function pointer. It takes about %30 longer to execute a function call through a function pointer. This is because it takes longer to access any variable through a pointer, the reason is that in order to access any sort of data through a pointer you must access two variables, first the pointer itself (which is a memory address) and then after that, access the data which resides at the memory address.

I don't know if I should have even said this last bit, the worst thing you could do right now is change your design to avoid something that won't realistically be a problem, but it just gives you something to think about.

<--- not using any virtual functions as of now :D

I suggest using a proper object oriented design with virtual functions as neccessary. Calling a virtual function is just an extra table look up.... the experience you'll gain from building a proper object oriented design is way more valuable than the tiny bit of performance you gain by not designing this way.

Well, we're using inheritence hardcore throughout the project, we havn't found any uses for a virtual function though in defining our objects.. Yes all Mobiles->Objects have a speed, but those are variables, not functions, right?

Quote:

---

Originally Posted by Shamino

Well, we're using inheritence hardcore throughout the project, we havn't found any uses for a virtual function though in defining our objects.. Yes all Mobiles->Objects have a speed, but those are variables, not functions, right?

---

I'm having a hard time thinking of when it would be necessary too. I haven't gotten into engine design yet so its hard to think. I'm sure all of you know what I'm talking about below, and even see how incorrect it is - which is sort of why I'm posting it. Sorry if this is a highjack, I'd like to know more about how to go about this. Its easier getting answers from gurus when you post a bunch of guesswork.

Without a virtual function you wouldn't be able to access Object->Mobile.speed from say AddObjectsToRenderer(), because it takes Objects (for generics). Unless of course it was Object.speed, which would be pointless in design and inefficient space-wise. Then again you probably wouldn't need to access Object->Mobile.speed anyway, but Object.x/y/zCoord (normal accessor method) you would - which would have to be protected or public (for derived classes), so that doesn't even matter. Other Render methods or functions in the engine might really need that ability though. Which would mean virtual functions or possibly delegation (adds complexity) in the Ship/etc. mobiles would be useful?

I guess if you wanted everything pointing to Ship1 to point to Jeep2 instead, it would be easier to do using an abstract (pure virtual) class. Simply changing the object of the abstract class to point to (a derived from) a Jeep2 object instead of a Ship1 object. Of course you could use a visitor design instead, or possibly void pointers.

Ultimately what the grand scheme of things I'm trying to accomplish is this


Objects (contains a location xyz)
Mobiles (inherits objects, Contains physics variables common to all mobiles)
Statics (inherits objects, more of a dummy object, doesn't move under its own power){

Cross(inherits Mobiles, which inherits objects, holds a pointer to a model, simply put, might perform some function that will be figured out later)

I'll take cross, and dynamically allocate it somewhere, so we can have multiple cross objects on the screen, if the user demands another cross is built, so be it, another cross is dynamically allocated..

I don't see a use for virtual functions yet..

I'll have a world class that determines what needs to be drawn in the world, where, when, and why...

World sends this information to a function in the render engine that dynamically allocates all objects that world says is needed on the screen, (there will be like, an update function in Cworld, that determines what is drawn and what isnt, where, when, and why)

which is sent to the draw function, bam, one call, whole scene is drawn..

That is my grand master plan, it probably is stupid and buggy though...


/////////////////////////////////////////////////////////////////////////////

I really misunderstand what you're saying Dae, could you please try to clear it up?

I know a few things, We will never need to access Object->x,y,z

Inheritence makes it so we need to access Ship1->x,y,z

I don't see why these objects would ever become unavailable for direct access like that..

Quote:

---

Originally Posted by Shamino

I really misunderstand what you're saying Dae, could you please try to clear it up?

---

Sorry if I was confusing because I'm sure you already know this.

Quote:

---

I know a few things, We will never need to access Object->x,y,z

---

How exactly do you plan to have a Render function accepting generic Objects that can access x,y,z? Even though Ship1 derives from Object you need to have the variables/functions in the Object class, or use virtual functions to go down the heirarchy to the derived class (the one you're passing).

Quote:

---

I don't see why these objects would ever become unavailable for direct access like that..

---

If you're making a vector of Object's for your Render class, then you would need to access Object->x,y,z. Of course Ship1 inherits that from Object if x,y,z are protected or public. If they weren't in Object, and were in Ship1, then you would not be able to access them unless you changed your Render function to accept Ship1's and not Object's.

Quote:

---

Inheritence makes it so we need to access Ship1->x,y,z

---

You *could* access x,y,z through Ship1 because its inherits from Object and are actually stored there and could be accessed from there too (obviously).

I don't know if I'm wrong - I could be and it wouldn't be the first time. I just wanted to get more ideas out of you guys.

Quote:

---

I suggest using a proper object oriented design with virtual functions as neccessary. Calling a virtual function is just an extra table look up.... the experience you'll gain from building a proper object oriented design is way more valuable than the tiny bit of performance you gain by not designing this way.

---

Usually I agree with you Perspective but not in this instance. Game programming is an entirely different breed, has entirely unique challenges that do not always have simple solutions and usually cannot be solved efficiently using pre-built mechanisms and/or the existing mechanism is not exactly suited to the task at hand.

I stress this - It is NOT a good idea to use virtual functions and/or lots of inheritance in a game system.

It IS a good idea to use aggregate data types by using pointers and/or creating objects on the stack.

Virtual functions in themselves might not be a bad idea if you only have a few objects. But think about a game. Very easily you could have well over one thousand virtual function calls taking place at the same time. That multiplied by the 30% time differential that Bob posted will result in some major problems.

GUI's are very well suited for multiple inheritance - but games are more suited to actually using C for the API and C++ to encapsulate it or use it. Most game APIs are written in C and/or C++. Most of them I've seen do not use a lot of inheritance. Several game programming books I've read also state this same fact. Game Coding Complete is written by someone who has developed games for Origin (Ultima series), Microsoft (aka Halo), and other game companies as well. The stuff he mentions in the book is exactly what I've found to be true in my own experience. This piece of advice to the OP will save him thousands upon thousands of lines of re-work. A game system is much different than any other program on earth and it HAS to run fast. That is it's lifeline, it HAS to run fast or it will die a horrible death. So, in games, every and I mean every CPU cycle and GPU cycle counts. 30% is a lot in a main render loop.

So stick to 1 level of inheritance. It makes your objects easier to construct, easier to use, and much less confusing. It also allows you to destroy the objects a bit more efficiently instead of relying on destructor calls - which when it comes to COM do not do exactly what you might want them to. A specific ShutDown() and Init() function for all game objects is almost essential to properly destroying COM and/or releasing memory back to the system.

There is more behind this whole theory, but I don't have the time or space to dive into it.

Perspective has good advice there so don't get me wrong, it's just not applicable to game engine and/or game design in this instance.

To render efficiently Shamino you must first think about what a render is:

A render is simply drawing the vertices in a set order to create textured triangles through various hardware texture mapping algos.

So a renderer only needs to know certain information about an object.

1. It's local rotation
2. It's world position (or translation relative to 0,0,0 which is the camera in world space)
3. It's world rotation (if any)
4. It's vertex data to include color(s), uv coord(s), etc.
5. It's texture(s) and associated data

The list could go on, but I leave that to you. So you need to send your renderer only pertinent information. Since each object in the world has vertex data, making a universal render function for all objects is actually fundamentally quite simple.

The renderer doesn't care if it's drawing an uber-cool space ship, or a super-boring billboard sprite. It just renders. If you approach it like that, I think you might get a bit farther.
The inheritance method as it is right now is NOT the correct approach. You are sending far too much data to the render function and losing efficiency. Keep it simple and to the point.
Don't force your render to do one more lookup than it has to. Even if it's just looking at a pointer in the vtable. Build the function so it doesn't have to do that. The render function should not be a member of any object class and should be a member of the rendering system only. Transformation, frustrum culling, and visible object list creation should also be done by the render function. So send all relevant data to the function in order to properly, efficiently, and quickly render the scene. It can get quite complex.

Remember in a 3D engine.....speed is everything

I think that most of my friends and colleagues here will agree with most of what I've said here. We've all experienced this in one way or another when we attempted to "C++'ize" our engines by deriving from everything and realized.....something isn't right here.

As for constructors - they should construct only.
Do not attempt any operation that might fail or could fail. In other words don't open files, don't allocate memory, don't create COM objects, etc., etc. Make your constructors parameterless so that creating an object of that type is extremely easy.

Do the bulk of the work in an init function that either returns an HRESULT from DX or perhaps a boolean result indicating success or failure. You can use exceptions although DX will NEVER EVER recover from an exception so a simple message and an immediate cleanup and exit will suffice.

This is fine:

Code:

---

CGameEngine TheEngine;

---

If:

* The constructor for CGameEngine absolutely cannot ever fail

Because:
* If it can fail, you have no way of finding out if it failed or not except by using exceptions which will force an immediate exit and failure of the system


I suggest purchasing Game Coding Complete 2nd edition for more information as well as Real Time Rendering.
These are available on www.amazon.com.
For reviews of books and recommendations go to www.gamedev.net and click on Books.

For more information about do's and dont's and tips and tricks on how the pro's code - go to www.gamasutra.com.

Quote:

---

Usually I agree with you Prelude

---

It was Perspective :)
But we know what you mean.

Why do I always get them mixed up? I did this before in another thread here not too long ago. Doh!!!!

::konk::

Anyways, I corrected it.

Quote:

---

Originally Posted by Bubba

Why do I always get them mixed up? I did this before in another thread here not too long ago. Doh!!!!

::konk::

Anyways, I corrected it.

---

Cough

Quote:

---

Prelude has good advice there so don't get me wrong, it's just not applicable to game engine and/or game design in this instance.

---

So, clear out all the inheritance I'm using, obviously, the render engine doesn't need to know my speed variables, etc etc, so I don't need to put all those information into my scene_objects class.. We don't want to pass any unecessary variables to the renderer that the renderer really doesn't need...

So ultimately, will I have a Scene_Objects class that only handles location variables? What will handle all the speed variables and movement? Will each object use a physics class in the same way they use the renderer?

Since every one is on the topic of inheritence and its use tell me this. You are all saying that multi level inheritence is very bad, which i agree with, but what about having an object inheriting from a bunch of singular classes.

Quote:

---

BobMcGee123 said:
This isn't to say, however, that I haven't had a single object derive from multiple other objects.

---

I thought multiple inheritence in any case was a bad idea for games. I know that inheriting from a multi layer object would be worse but isent it still bad to ues multiple inheritence? :confused:

That isn't multi-level/layer inheritance.

It's only bad because it isn't as useful, in my experience, as other methods. Do whatever you want.

Yeah, uses for multiple inheritance is rare and if it is used it just adds complexity to the design IMO. That's why Java doesn't allow it.

Finding faults in your language is worrysome...

It's like finding out that the sheet metal you're using for your car has holes in it - no good!

These are not necessarily bad, just not very good for games. People have found very good ways to use the virtual aspect of C++ and multiple inheritance out side the realm of games. In addition, I still don’t say that using pure virtual functions is necessary bad for games, remember that article about modular game programming. Every DirectX function is virtual, so it’s not slow at all when used correctly. Don’t you remember the discussion of that article Bubba?

I have a case where I think virtual functions are required. I'm a newbie so I can't seem to find a way to make it work otherwise. Lets say you have a game that allows you to switch (in options) the graphics library from Direct3D to OpenGL and visa versa. Now you'd like to keep the scripting the same for either case whether or not its D3D or OGL. Lets take a Vector class for example, I dont care if its correct, and its not the way I'd do it, its just for example.

Code:

---

class IObject
{
private:
        static CVector* m_Center; //would be the abstract class

public:
        IObject() : m_Center(new D3DVector) {} //initially set to D3D
        static CVector* GetCoords() { return m_Center; }

};

class D3DVector
{
private:
        d3dVector m_xCoord;
        d3dVector m_yCoord;
        d3dVector m_zCoord;

public:
        void SetX(d3dVector p_x) { m_xCoord = p_x; }
};

class OGLVector
{
private:
        glVector m_xCoord;
        glVector m_yCoord;
        glVector m_zCoord;

public:
        void SetX(glVector p_x) { m_xCoord = p_x; }
};

int main()
{
        CVector* Vector = IObject::GetCoords(); //returns D3DVector atm

        Vector.SetX(new d3dVector);
        Vector.SetX();
        Vector.SetAll(new d3dVector, new d3dVector, new d3dVector);
        Vector.GetX();
}

---

I don't see any way of allowing the call to IObject::GetCoords() result in either D3D or OGL, based on whichever is set at the moment, without of course making a CVector abstract class (virtual).

I also have another issue where if I used a vector class like this, then when switching from D3D to OGL or visa versa, every coord would be set to 0 or incorrect - so I would have to do some operations to convert from D3D to OGL or vv. That or I could check everywhere to attempt using a union (which I'm hoping would work, but I know know). Hell I don't know maybe I could just store floats and set d3dVector to the corresponding float and return that.

Also, between using an extra if statement or function call, or virtual function, which would be the best choice for speed?

I found uses for virtual constructors, but nothing more...

If you want a class factory design you *need* virtual constructors, I'll show you some code...

Code:

---

class Control
{
};

class PushControl : public Control
{
};

class Factory
{
 public:
  // Returns Factory subclass based on classKey.  Each
  // subclass has its own getControl() implementation.
  // This will be implemented after the subclasses have
  // been declared.
  static Factory * getFactory(int classKey);

  virtual Control * getControl() const = 0;
};

class ControlFactory : public Factory
{
 public:
  virtual Control * getControl() const
  {
    return new PushControl();
  }
};

Factory * Factory::getFactory(int classKey)
{
  // Insert conditional logic here.  Sample:
  switch(classKey)
  {
    default:
      return new ControlFactory();
  }
}

---

I think this is a singleton class factory design...

One Factory class handles all class factories, you can have a scene_object factory, or a GUI factory, etc etc...

It looks like that link would work, a way to get around requiring an abstract class for the objects. Thats not a Singleton though, you would have to store an instance of itself and new if the instance is null, otherwise just return the instance in order to do that.

ATM I'm using a Template Method (concrete class) for each "System", which DX (DirectX) libs, or OL (Other Library - SDL/OpenGL), etc. derive from that. Which means I can switch between say DirectInput and SDL without losing data. Then I'm using a Singleton (CSystem class) as a Singleton Factory of Template Method classes (concrete classes).

Code:

---

class CSystem
{
private:
    enum m_eLibChoice {NONE, DX, OL};
    static m_eLibChoice m_eRenderLib;
    static m_eLibChoice m_eSoundLib;
    static m_eLibChoice m_eInputLib;

    //static CTimerSystem* m_CTimer;
    static ISoundSystem* m_Sound;
    static IRenderSystem* m_Render;
    static IInputSystem* m_Input;
    static LLObjectSystem* m_Object;
    static CSystem* m_Instance;

protected:
    CSystem(); // only allow instantiation from within the this or derived classes

public:
    void SwitchRenderSystem();
    void ReleaseRenderSystem();
    static IRenderSystem* Render();

    void SwitchSoundSystem();
    void ReleaseSoundSystem();
    static ISoundSystem* Sound();

    void SwitchInputSystem();
    void ReleaseInputSystem();
    static IInputSystem* Input();

    //static CTimerSystem* Timer();

    void ReleaseObjectSystem();
    static LLObjectSystem* Object();

    static CSystem* Instance();
};

////////////////////////////////////////////////////////////////////////////////

CSystem::CSystem() {}

CSystem* CSystem::m_Instance = 0;
IRenderSystem* CSystem::m_Render = 0;
ISoundSystem* CSystem::m_Sound = 0;
IInputSystem* CSystem::m_Input = 0;
LLObjectSystem* CSystem::m_Object = 0;
CSystem::m_eLibChoice CSystem::m_eRenderLib = NONE;
CSystem::m_eLibChoice CSystem::m_eSoundLib = NONE;
CSystem::m_eLibChoice CSystem::m_eInputLib = NONE;

///////////////////////////////// MAIN /////////////////////////////////////////

CSystem* CSystem::Instance()
{
    if(m_Instance == 0)
        m_Instance = new CSystem();

    return m_Instance;
}

//////////////////////////////// RENDER ////////////////////////////////////////

IRenderSystem* CSystem::Render()
{
    if(!m_Render)
        if(m_eRenderLib == DX)
            m_Render = new DX::CRenderSystem();
        else if(m_eRenderLib == OL)
            m_Render = new OL::CRenderSystem();

    return m_Render;
}

void CSystem::SwitchRenderSystem()
{
    if(m_eRenderLib == DX) {
        m_Render = new OL::CRenderSystem();
        m_eRenderLib = OL;
    } else {
        m_Render = new DX::CRenderSystem();
        m_eRenderLib = DX;
    }

    //call updates required
}

void CSystem::ReleaseRenderSystem()
{
    if(m_Render)
        delete m_Render;
    m_Render = 0;

    m_eRenderLib = NONE;
}

//ETC

namespace OL
{

class CRenderSystem : public IRenderSystem
{
private:
    unsigned int m_uiWindowWidth;
    unsigned int m_uiWindowHeight;

    float m_fAngle;

protected:

public:
    CRenderSystem(void) {}
    virtual ~CRenderSystem(void) {}

    bool Init(void);
    bool Shutdown(void);
    void SetupProjection(unsigned int, unsigned int);
    void Prepare(float);
    void Draw(void);

    void DrawObject(NObject*);
};

---

I think I need to revamp it though. I'll read up some more on design patterns first. I think Metaclasses might be what I want.

Here is my Object building manager (its not accurately named as of yet)

NOTE: Largely Incomplete :D

Code:

---

template <typename T>
struct Build{
    //
    // Callback functor for buttons to make buildings
    //
    void operator()(int PlayerNum, int x, int y, int z)
        {
        //
        // Creates building type T at x,y under ownership of player
        owner.buildings.push_back(building);
        game.objects.push_back(building);

        Object  *Building= NULL;

                switch (PlayerNum)
                {
                case GAME_MASTER:
                                // insert conditional operators here
                        Building = new T(PlayerNum, x, y, z);
                        break;
                case PLAYER_ONE:
                        break;
                    Building = new T(PlayerNum, x, y, z);
                case PLAYER_TWO:
                        break;
                  Building = new T(PlayerNum, x, y, z);
                case PLAYER_THREE:
                        break;
                  Building = new T(PlayerNum, x, y, z);
                case PLAYER_FOUR:
                        break;
                  Building = new T(PlayerNum, x, y, z);
                case PLAYER_FIVE:
                        break;
                case PLAYER_SIX:
                        break;
                  Building = new T(PlayerNum, x, y, z);
                case PLAYER_SEVEN:
                        break;
                  Building = new T(PlayerNum, x, y, z);
                case PLAYER_EIGHT:
                        break;
                  Building = new T(PlayerNum, x, y, z);
                case WORLD:
                        break;
                  Building = new T(PlayerNum, x, y, z);
                }

            //
            // these next two lines are better off in the
            //  T constructor
            //
 
    }
};

---

Ultimately I would call it like this

Code:

---

barracks_button.onClick = new Build<barracks>();

---

I think this is about as OO as it gets (though I could probably have a player template, I think that is a point where the OO would get redundant), at least when it comes to adding objects to your renderer..

when we call the new Build<barracks>, we grab the model data held in barracks and send it to a vector to be managed and rendered...

We will also send it to another vector that will handle only collision detection...

Yeah thats incomplete, and is it even correct?

Almost all of your cases are empty because I think you meant to have that stuff in the case, but have the break on the wrong line.

You're passing an integer PlayerNum, and how does that compare to a constant enum choice?

What are you pushing at the beginning of the operator() (that doesn't have a capital B)?

EDIT: I see the idea.. but I don't think it would work and I'd at least get the concept to work for real (or else you don't know if its possible) before leaving it as even pseudo code.

lol i whipped that code up just now, didn't realize where I put the breaks..

It's basically pseudocode atm, let me repost it.
Not 100% if it works or not, it's based upon something someone gave me at GameDev...

I know that the pushback calls in this thing are all goofy, i don't even have an owner.buildings vector, but i will figure it all out in time...

Code:

---

template <typename T>
struct Build{
    //
    // Callback functor for buttons to make buildings
    //
    void operator()(Player::PLAYER_NUMBER, int x, int y, int z)
        {
        //
        // Creates building type T at x,y under ownership of player


        Object  *Building= NULL;

                switch (Player::PLAYER_NUMBER)
                {
                case GAME_MASTER:
                                Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_ONE:
                                Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_TWO:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_THREE:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_FOUR:
                        break;
                  Building = new T(Player::PLAYER_NUMBER, x, y, z);

                case PLAYER_FIVE:
                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_SIX:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_SEVEN:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_EIGHT:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case WORLD:
               
                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                }

            //
            // these next two lines are better off in the
            //  T constructor
            //
        owner.buildings.push_back(building);
        game.objects.push_back(building);
    }
};

---

If you want to see the whole thing that is currently up to date with an explaination go here:

http://www.gamedev.net/community/for...opic_id=364152

Reply Number 8

Oh, I see. Yeah what he posted is nice. It doesn't solve the exact problem of losing data though, as you can see in your code you are assigning T to Object (and if T is a subclass you would be losing data, assuming Object isn't concrete [which if it was this entire thing wouldn't be necessary]).

Also logically storing T in an Object* is pointless if you're only adding buildings (owner.buildings.push_back(building);). You could just make it Building* aBuilding; and then push that back to objects/buildings. Basicly it doesn't solve anything.

Cool, in one of your posts (http://www.gamedev.net/reference/art...rticle2097.asp) that had a template method with function pointers - that looked useful (maybe not for the Object structure, but for something).

What I meant in my last post is you have it defined Object *Building= NULL;, but you are calling owner.buildings.push_back(building);, without a capital b in building. Also FOUR's break is off.

I'm going to start reading Design Patterns again, and see if GD can help me figure out my problem with Object and deriving from it.

This:

Code:

---

void operator()(Player::PLAYER_NUMBER, int x, int y, int z)
        {
        //
        // Creates building type T at x,y under ownership of player


        Object  *Building= NULL;

                switch (Player::PLAYER_NUMBER)
                {
                case GAME_MASTER:
                                Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_ONE:
                                Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_TWO:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_THREE:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_FOUR:
                        break;
                  Building = new T(Player::PLAYER_NUMBER, x, y, z);

                case PLAYER_FIVE:
                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_SIX:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_SEVEN:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case PLAYER_EIGHT:

                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                case WORLD:
               
                  Building = new T(Player::PLAYER_NUMBER, x, y, z);
                        break;
                }

            //
            // these next two lines are better off in the
            //  T constructor
            //
        owner.buildings.push_back(building);
        game.objects.push_back(building
...
...

---

is a disaster.

I know I know Bubba, I've been suggested like 5 different possible ways of solving my problem and i keep trying to use them and failing miserably, I think i just need to take two steps back...