Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualTispe

Posted 23 May 2013 - 01:15 AM

Hi, I have rewritten my project several times to adapt to new game structures. I do this to conform to rules such as, no static or global variables, no singleton patterns and the single responsibility principle.

 

The application consist of class objects. I often find myself creating a "super" class to only make one instance of it. Such as a Renderer class. This class handles the window, resolution, fullscreen toggle and draws the scene.

 

Another class is the Asset Manager, one instance is created and it handles loading files and preparing them for later use. It keeps an array of all assets. Since the Asset Manager needs the device to create resources (VB, IB, Textures) in the managed pool, I keep a private pointer to the device in Asset Class and make a copy in the constructor. This cross object dependancy is to conform to the "rules", maybe there is a better solution?

 

The Entity class has one instance, it has a list of (pointers to) Player objects (struct). These player structs contain information such as what Skeleton to use, what Mesh to use, and character variables.

 

When rendering I pass the list of Entities to the renderer which looks up the Asset Manager for the resources and draws them as described in the Player object. 

 

There are also other classes such as the animator and gui but I kept those out to keep it short. Is this a good game structure? What should I pay attention to, and are there any other game structures I should consider?

 

The pseudo-code:

main(){
InputOutputClass IO;
DeviceClass Renderer;
AssetClass Assets(Renderer.GetDevice());
EntityClass Entities;
GuiClass Gui(Renderer.GetDevice());

MainLoop(Renderer, Assets, Entities, IO, Gui);

}

#1Tispe

Posted 23 May 2013 - 01:13 AM

Hi, I have rewritten my project several times to adapt to new game structures. I do this to conform to rules such as, no static or global variables, no singleton patterns and the single responsibility principle.

 

The application consist of class objects. I often find myself creating a "super" class to only make one instance of it. Such as a Renderer class. This class handles the window, resolution, fullscreen toggle and draws the scene.

 

Another class is the Asset Manager, one instance is created and it handles loading files and preparing them for later use. It keeps an array of all assets. Since the Asset Manager needs the device to create resources (VB, IB, Textures) in the managed pool, I keep a private pointer to the device in Asset Class and make a copy in the constructor. This cross object dependancy is to conform to the "rules", maybe there is a better solution?

 

The Entity class has one instance, it has a list of (pointers to) Player objects (struct). These player structs contain information such as what Skeleton to use, what Mesh to use, and character variables.

 

When rendering I pass the list of Entities to the renderer which looks up the Asset Manager for the resources and draws them as described in the Player object. 

 

There are also other classes such as the animator and gui but I kept those out to keep it short. Is this a good game structure? What should I pay attention to, and are there any other game structures I should consider?

 

The pseudo-code:

main(){
InputOutputClass IO;
DeviceClass Renderer;
AssetClass Assets(Renderer.GetDevice());
EntityClass Entities;
GuiClass Gui(Renderer.GetDevice());

MainLoop(Renderer, Assets, Entities, IO);

}

 


PARTNERS