Data Structures and refrences!

Started by
15 comments, last by Zahlman 15 years, 9 months ago
You should only ever pass objects parameters that they need. Class heirarchies with loose relationships (coupling) is often a better design choice than tighty coupled methods.

Your code looks a lot like a C game structure. Structures are used in functions instead of class calling their own functions passing data to their children which call their own methods with their own sub-data.

Instead of what you have done with structures and global functions, try implementing it into an Application class that is created inside your program's entry point, not globally, so that an object may only get a pointer to the Application if the parent of that object hands it out (and the parent knows about it itself).

class Application{public:     SceneGraph* GetSceneGraph();     bool Open (void);     void Logic (double delta_time);     void Render ();     void Close (void);     bool IsRunning (void);private:     /* application objects */     bool m_Running;     std::list <IGameObject*> m_Objects;     Renderer* m_Renderer;};int main (){     Application app;     if (app.Open ()) {          Timer timer;          while (app.IsRunning ()) {               timer.Start ();               app.Logic (timer.DeltaTime); // delta time of last frame..               app.Render ();               timer.End ();          }          app.Close();     }  }// Application::Logic () functionvoid Application::Logic (double dt){    std::list <IGameObject*>::iterator obj = m_Objects.begin ();    while (obj != m_Objects.end ()) {        (*obj)->Update (this, dt); // pass the Application object and delta time        ++obj;    }}


In this design, the heirarchy is only loosely coupled. Objects don't know about their parents until its time to update them every frame. Theyre not explicitly coupled to one particular Application or one particular Renderer.

Alternatively to relinquish immediate access to the Application object, have a World class or something which contains a list of the game objects. The World class would further abstract the Application from its contents so that the Application can simply update whatever 'world' its currently loaded, and the world class manages changes and whatnot to all objects.

The game objects can either be passed a World* object into their Update functions or they may contain a pointer to their parent World class.
Advertisement
perhaps this is a better solution? (The other thread just confused me because I haven't learned what a singleton is yet)

struct GameVariables;class Character;while(!done){gameloop(GameVariables, Character);}gameloop(struct &GameVariables, class &Character){   switch{gamestate){      case menu: logicmenu(Specific Variables);                 rendermenu(Specific Variables);                 break;   }}


At least this way logic menu does not gain all the variables only the one it needs.
Have you learnt about classes yet? Have a read up on polymorphism too.

A game state mechanism is usually implemented through virtual base classes.

So you have a base class called IGameState then a bunch of derived classes called MenuGameState and PlayGameState. Each derived class performs its own operations in an Update/Render set of member functions.

class IGameState{public:    virtual void Update (double dt);    virtual void Render (void);};class MenuGameState : public IGameState{public:    void Update (State*& state, double dt)    {         if (playButton->Pressed) {               state = new PlayGameState();               delete this;         }    }    void Render (void);};IGameState* state = new MenuGameState;while (state) {    state->Update (dt);    state->Render ();}
Ive learned about classes(Nothing 2 deep), but I am trying to keep this reasonably simple.
btw what is this? "State*& state" a pointer to a reference?
Quote:Original post by Shadowwoelf
Ive learned about classes(Nothing 2 deep), but I am trying to keep this reasonably simple.
btw what is this? "State*& state" a pointer to a reference?


Well actually that was a slightly poor example of managing the state changes. You usually have a state manager or similar class which handles changes of states so that a state might call StateManager::changeTo (new PlayState()) and the StateManager will queue up a change to the new state next update.

Alternatively you can push states onto a stack with something like StateManager::pushState (new PlayState())
Thanks guys, Well I suppose I better start relearning classes a bit(and polymorphism...)
Quote:Original post by Shadowwoelf
Ive learned about classes(Nothing 2 deep), but I am trying to keep this reasonably simple.
btw what is this? "State*& state" a pointer to a reference?


A reference to a pointer. &, * and 'const' on type names are read right to left, basically.

This topic is closed to new replies.

Advertisement