12 Replies - 1213 Views - Last Post: 18 July 2013 - 04:46 PM Rate Topic: -----

#1 Mr_Fraggs   User is offline

  • D.I.C Head

Reputation: 10
  • View blog
  • Posts: 89
  • Joined: 17-June 12

Game Architecture Advice

Posted 14 July 2013 - 05:32 PM

Hey guys, so i've been working on setting up my game architecture, and have tried a couple different things, running into the same problems of visibility between systems. Basically what I have going on right now is this. Keep in mind i'm using C++, so i'm also using pointers and references and all that fun stuff.

1) Game Class, which basically runs the game, loads content, and handles the window and renderer.
2) Below that, the GameStateManager, which handles the transitions, updating and rendering of the game states. (Some of you might think Game Screen instead of Game State)
3)This is the tricky part for me. Now we have Managers like TextureManager to hold all the textures, SpriteManager to deal with the sprites, InputManager, etc.

What do you guys think about that setup? I've been putting an instance of each manager in Game, then tried passing that Game object to each manager, which doesn't work since I can't include the managers into the game class, then include the game class into the managers. I'm trying to set up a system so that each manager can see all the other managers.

I could pass a reference of each manager to each other manager, but then the problem comes of when I would Initialize the GameManager and pass in say, the TextureManager, then set up the TextureManager and pass in the GameManager, wouldn't that be very similar to the problem you would get from including the game class into the manager class, and vice versa?

I also thought about making a SubSystemManager type class, where it holds all the SubSystem Managers, but I still feel like the same problem would occur.

The last option I thought about was making them static, but I know how much of a no-no that is. :P

If you're wondering why the subsystems might need to see each other, imagine the TextureManager and SpriteManager. Each Sprite HAS a texture, so the SpriteManager would need access to the TextureManager.

I may definitely be thinking way too hard about this, and that's causing me to get nowhere.

I hope I made this clear, as I'm still trying to figure out how to tackle this problem, but I wanted to know if this would even be a worth-while way to do this, or if I should just scrap the idea and figure out something new. Thanks guys!

Is This A Good Question/Topic? 0
  • +

Replies To: Game Architecture Advice

#2 Mylo   User is offline

  • Knows all, except most.

Reputation: 265
  • View blog
  • Posts: 747
  • Joined: 11-October 11

Re: Game Architecture Advice

Posted 14 July 2013 - 09:19 PM

View PostMr_Fraggs, on 14 July 2013 - 09:02 PM, said:

What do you guys think about that setup? I've been putting an instance of each manager in Game, then tried passing that Game object to each manager, which doesn't work since I can't include the managers into the game class, then include the game class into the managers. I'm trying to set up a system so that each manager can see all the other managers.


I believe this is called 'Dependency Injection', and yes, it can be done using 'Forward Declarations' which indicate that a class will be used, but does not need to be included. (pointers in member variables, return types, and parameters don't require an include as they will always be the same size).

Also I'd avoid calling classes 'manager' as it is ambiguous as to what they are actually doing. StateManager = StateMachine, TextureManager = TextureLoader/TextureCache etc.

This post has been edited by Mylo: 14 July 2013 - 09:22 PM

Was This Post Helpful? 0
  • +
  • -

#3 aaron1178   User is offline

  • Dovakiin, Dragonborn
  • member icon

Reputation: 169
  • View blog
  • Posts: 1,310
  • Joined: 22-October 08

Re: Game Architecture Advice

Posted 15 July 2013 - 01:34 AM

View PostMr_Fraggs, on 15 July 2013 - 11:32 AM, said:

1) Game Class, which basically runs the game, loads content, and handles the window and renderer.


I've been creating an Asset Manager, which sets the global paths and the resource directories (i.e Meshes, Textures and Audio). This Asset Manager will give each new resource a unique ID, for access later. These IDs are like so:

  • AE9838EZ - Mesh
  • BA1234AB - Textures


The first alphabetical letter distinguishes whether the resource is a Mesh, Texture etc. Along with a unique ID, the resource will get a name, like for a mesh for instance, will receive a name like 'CastleWallDoor01'... just a name for in game use.

Another thing I am implementing into my Asset Manager is; If a mesh does not exist, it will show 'meshError.mesh', so it will always load a mesh, even if the mesh is not there. And if a texture is missing, it will load a default error texture.

P.S: It took me ages to think of a viable solution to my asset manager.

Just my 2 cents :)
Was This Post Helpful? 0
  • +
  • -

#4 Mr_Fraggs   User is offline

  • D.I.C Head

Reputation: 10
  • View blog
  • Posts: 89
  • Joined: 17-June 12

Re: Game Architecture Advice

Posted 15 July 2013 - 12:54 PM

Those are two pretty interesting tips, I didn't think about my managers that way! I need to look into using unique ID's, but that uses Global Managers, right?

And I'll definitely be going back through my framework so far and try to get away from the name Manager, so ignore the fact that I just used it in this post again :P Just being consistent for the thread!

The error texture is actually a pretty interesting idea. Right now, when my game crashes because it can't find a resource (even though I only have one or two), it doesn't do a whole lot aside from send an error back, which doesn't really show up too well since it's a console command. I'm working on getting a Bitmap font working next, right after I get this stuff set up.

Thanks for the input guys, you both have some pretty interesting ideas!
Was This Post Helpful? 0
  • +
  • -

#5 anonymous26   User is offline

  • D.I.C Lover

Reputation: 2
  • View blog
  • Posts: 3,638
  • Joined: 26-November 10

Re: Game Architecture Advice

Posted 15 July 2013 - 01:48 PM

View Postaaron1178, on 15 July 2013 - 05:34 AM, said:

View PostMr_Fraggs, on 15 July 2013 - 11:32 AM, said:

1) Game Class, which basically runs the game, loads content, and handles the window and renderer.


I've been creating an Asset Manager, which sets the global paths and the resource directories (i.e Meshes, Textures and Audio). This Asset Manager will give each new resource a unique ID, for access later. These IDs are like so:

  • AE9838EZ - Mesh
  • BA1234AB - Textures


The first alphabetical letter distinguishes whether the resource is a Mesh, Texture etc. Along with a unique ID, the resource will get a name, like for a mesh for instance, will receive a name like 'CastleWallDoor01'... just a name for in game use.

Another thing I am implementing into my Asset Manager is; If a mesh does not exist, it will show 'meshError.mesh', so it will always load a mesh, even if the mesh is not there. And if a texture is missing, it will load a default error texture.

P.S: It took me ages to think of a viable solution to my asset manager.

Just my 2 cents :)/>

This has so many potential problems. I'll go over some of them:

1. When you say 'sets global paths' do you mean that the asset paths are determined during runtime? This is not good, the paths to such resources should be being retrieved from some sort of schama like and XML manifest or something - making your paths standard and known.
2. Do not load default textures and meshes! Work out what the exceptions are and fix them. What exactly is a default texture anyway? Surely you have specific ones for specific models, right?
3. Your texture and mesh IDs make for poor naming conventions when enumerating your assets, and your tool should be able to tell the type of file from its content and not its ID - as in analyzing the file header.

I wouldn't plug this system into a game.
Was This Post Helpful? 0
  • +
  • -

#6 anonymous26   User is offline

  • D.I.C Lover

Reputation: 2
  • View blog
  • Posts: 3,638
  • Joined: 26-November 10

Re: Game Architecture Advice

Posted 15 July 2013 - 01:54 PM

View PostMr_Fraggs, on 14 July 2013 - 09:32 PM, said:

1) Game Class, which basically runs the game, loads content, and handles the window and renderer.
2) Below that, the GameStateManager, which handles the transitions, updating and rendering of the game states. (Some of you might think Game Screen instead of Game State)
3)This is the tricky part for me. Now we have Managers like TextureManager to hold all the textures, SpriteManager to deal with the sprites, InputManager, etc.

This tells me that you don't understand the appropriate use of OO methods. You should be aware of 'is-a' and 'has-a' relationships for classes that help you think through what one class represents and how it relates to other classes when looking into inheritance.

Right, so you have a base class. This base class should have very few global settings appropriate to the game with maybe some pure virtual methods that need to be defined for derived classes; think of it as a stem cell that can be given a purpose by being defined in derived classes.

Have a little read up on OO. :)
Was This Post Helpful? 0
  • +
  • -

#7 aaron1178   User is offline

  • Dovakiin, Dragonborn
  • member icon

Reputation: 169
  • View blog
  • Posts: 1,310
  • Joined: 22-October 08

Re: Game Architecture Advice

Posted 17 July 2013 - 01:31 AM

View PostButchDean, on 16 July 2013 - 07:48 AM, said:

View Postaaron1178, on 15 July 2013 - 05:34 AM, said:

View PostMr_Fraggs, on 15 July 2013 - 11:32 AM, said:

1) Game Class, which basically runs the game, loads content, and handles the window and renderer.


I've been creating an Asset Manager, which sets the global paths and the resource directories (i.e Meshes, Textures and Audio). This Asset Manager will give each new resource a unique ID, for access later. These IDs are like so:

  • AE9838EZ - Mesh
  • BA1234AB - Textures


The first alphabetical letter distinguishes whether the resource is a Mesh, Texture etc. Along with a unique ID, the resource will get a name, like for a mesh for instance, will receive a name like 'CastleWallDoor01'... just a name for in game use.

Another thing I am implementing into my Asset Manager is; If a mesh does not exist, it will show 'meshError.mesh', so it will always load a mesh, even if the mesh is not there. And if a texture is missing, it will load a default error texture.

P.S: It took me ages to think of a viable solution to my asset manager.

Just my 2 cents :)/>/>/>

This has so many potential problems. I'll go over some of them:

1. When you say 'sets global paths' do you mean that the asset paths are determined during runtime? This is not good, the paths to such resources should be being retrieved from some sort of schama like and XML manifest or something - making your paths standard and known.
2. Do not load default textures and meshes! Work out what the exceptions are and fix them. What exactly is a default texture anyway? Surely you have specific ones for specific models, right?
3. Your texture and mesh IDs make for poor naming conventions when enumerating your assets, and your tool should be able to tell the type of file from its content and not its ID - as in analyzing the file header.

I wouldn't plug this system into a game.


While I am still learning, I will just say lets agree to disagree, since you have not seen my first games code and tool integration.
Was This Post Helpful? 0
  • +
  • -

#8 anonymous26   User is offline

  • D.I.C Lover

Reputation: 2
  • View blog
  • Posts: 3,638
  • Joined: 26-November 10

Re: Game Architecture Advice

Posted 17 July 2013 - 03:54 AM

It isn't about seeing about what you've done, it's about dealing with issues correctly. It isn't up to your tools to have such default behavior, if a texture is missing for instance, it flags the issue and you provide the texture.

There's no valid reason to do it like this. Yes, you are learning but you're offering it as advice.
Was This Post Helpful? 0
  • +
  • -

#9 jRaskell   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 5
  • Joined: 06-February 12

Re: Game Architecture Advice

Posted 17 July 2013 - 01:15 PM

Quote

I'm trying to set up a system so that each manager can see all the other managers.


Why? This should be a huge red flag that there's something wrong with your architecture. Map out your hierarchy. Why should your Texture Manager have any idea that a Sprite Manager exists? Why should your Input Manager know that a Texture Manager exists? Each Manager should only know just as much as it needs to know to get it's job done, and the less each Manager knows, the better. Give visibility only where it's needed, and be sure it absolutely is needed anywhere you give it.
Was This Post Helpful? 1
  • +
  • -

#10 Mr_Fraggs   User is offline

  • D.I.C Head

Reputation: 10
  • View blog
  • Posts: 89
  • Joined: 17-June 12

Re: Game Architecture Advice

Posted 18 July 2013 - 02:25 PM

View PostjRaskell, on 17 July 2013 - 03:15 PM, said:

Quote

I'm trying to set up a system so that each manager can see all the other managers.


Why? This should be a huge red flag that there's something wrong with your architecture. Map out your hierarchy. Why should your Texture Manager have any idea that a Sprite Manager exists? Why should your Input Manager know that a Texture Manager exists? Each Manager should only know just as much as it needs to know to get it's job done, and the less each Manager knows, the better. Give visibility only where it's needed, and be sure it absolutely is needed anywhere you give it.


Well I've been reworking it, and realizing that not EVERY manager would need to see each other. But for instance, a SpriteManager would need to see the TextureManager to set the Sprite's texture to one in the TextureManager. Think of TextureManager as basically a TextureBank for now, that loads all the images and assigns them to a texture. The texture holds the image, and info about it like width, height, etc. Then, the sprite has a pointer it's texture in the TextureManager class, that way I don't need to have a ton of textures all over the place. Just one, and anything that needs it can just get a pointer to it. I took out the SpriteManager class for now, and haven't put it in again yet, but I was just using that as an example.

This could be a really shoddy way of setting up a game, but it's just what i've gotten going so far. It's not easy to find tutorials out there that deal with game programming as a whole, instead of specific topics (like rendering an image, checking collisions, etc), so i'm going basically on what I've learned using XNA.

Basically what I have going so far, is the Game class handles initialization, shutdown, and renders and updates the game. That is done through the GameStateManager class, which holds whatever GameStates my game may use, and has a currentGameState object, that can be set to any kind of Game State. All this does is decide which Game State should be current, and Renders and Updates that game state. Then I have the TextureManager class, that loads in and holds all the textures.

Lastly is each GameState, that renders and updates the logic and graphics specific to that game state. For instance, a LoadingState may just Render a texture that says "Loading", while the logic loads all the assets. Then say, PlayingState, would Update and Render all of the logic and graphics that apply when the user is playing the game.

Aside from smaller classes that just handle stuff like textures, input, etc, that's about all I have so far. If this is an awful way to be doing this, let me know! I don't know where to find a reliable source to handle the structure of a game, and I found this way aside from the Game State part in a book I read for XNA, so it's really all I have to go on for now. I've read many game programming books over the years, but none that really deal with setting up a full game architecture, and mostly deal with making simple games that only deal with one play section, and only uses other classes to deal with objects. Like Pong or Snake, the examples startup, run through the game until the game ends, then shuts down. Other classes may include things like Paddle.cpp & Paddle.h for Pong and Ball.cpp and Ball.h. Nothing that really deals with the overall structure and flow of a full game that has things like menus, different states, etc.

This post has been edited by Mr_Fraggs: 18 July 2013 - 02:38 PM

Was This Post Helpful? 0
  • +
  • -

#11 Mylo   User is offline

  • Knows all, except most.

Reputation: 265
  • View blog
  • Posts: 747
  • Joined: 11-October 11

Re: Game Architecture Advice

Posted 18 July 2013 - 03:41 PM

Quote

SpriteManager would need to see the TextureManager


Not necessarily. Remember you could SpriteManager.getSprite(), Sprite.setTexture(TextureManager.getTexture("")) inside your game logic (initialization probably). You could also have a Factory class that returns a Sprite for a given Texture.

To touch on the architecture more, I'm currently reading through Game Coding Complete 4 (I haven't been able to found much else on architecture either, there is a few books, but of course each one can only teach you so much, experience will trump them eventually), and as a person with minimal exposure to game architecture previously, it has been incredibly helpful, I've learned quite a bit about architecture (Keeping in mind it is only one of many ways to do it) from it. I haven't gotten right down into the details of a few of the classes yet, but have read the general concepts.

To sum up GCC4's structure basics in relation to your problem to my understanding (Code: http://code.google.com/p/gamecode4/ ):

  • Three 'Layers'
    • Application Layer - Handles Input (Device Handling), Files, Memory, etc.
    • Game Logic Layer - Handles State, Data Structures, Events, etc.
    • Game View Layer - Handles Display, Video, Audio, etc.
  • Application Layer holding the managers (GameCodeApp) - Has ResCache (TextureManager), File Readers, Renderers, Input (Player Doing Stuff), etc.
  • ActorFactory (Sprites) - Creates Actor given data input (Texture for sprites).
  • Logic and View communicate to each other via game message, providing a separation of these components.


There is a lot more in the engine of course, but I don't know all of it. It seems pretty good to me and the book has good ratings for a reason. But you'll have to read it yourself to see.

More personally, I create my window and have my Game class a as a drawable component, which then basically does what yours does too. But my focus is on creating a game, not an engine. I haven't had enough experience with it to know all the pros/cons. I do think GCC4 is touching on a similar structure though, it just has to make sure it can be well maintained and take care off many more technical aspects which throws in the extra complexity.

3d game engi

I hope that helps somewhat.

This post has been edited by Mylo: 18 July 2013 - 04:02 PM

Was This Post Helpful? 1
  • +
  • -

#12 anonymous26   User is offline

  • D.I.C Lover

Reputation: 2
  • View blog
  • Posts: 3,638
  • Joined: 26-November 10

Re: Game Architecture Advice

Posted 18 July 2013 - 04:05 PM

Quote

This could be a really shoddy way of setting up a game, but it's just what i've gotten going so far. It's not easy to find tutorials out there that deal with game programming as a whole...

That is because you cannot have a tutorial to teach you enough about programming games in order to go write your own - it's simply too huge a subject. You need to get used to not only finding solutions to your problems, but finding good solutions off your own back. If you don't you will always be stuck and looking for tutorials.

This post has been edited by ButchDean: 18 July 2013 - 04:07 PM

Was This Post Helpful? 2
  • +
  • -

#13 Mr_Fraggs   User is offline

  • D.I.C Head

Reputation: 10
  • View blog
  • Posts: 89
  • Joined: 17-June 12

Re: Game Architecture Advice

Posted 18 July 2013 - 04:46 PM

View PostButchDean, on 18 July 2013 - 06:05 PM, said:

Quote

This could be a really shoddy way of setting up a game, but it's just what i've gotten going so far. It's not easy to find tutorials out there that deal with game programming as a whole...

That is because you cannot have a tutorial to teach you enough about programming games in order to go write your own - it's simply too huge a subject. You need to get used to not only finding solutions to your problems, but finding good solutions off your own back. If you don't you will always be stuck and looking for tutorials.

I completely agree with that. I'll say time and time again, the only way I personally learn is by doing. I can get a good idea of something by reading, but i'll never absorb the information unless I'm doing something. That's why after I read a few C++ books, I just jumped right in to programming. That's not all I read, as I started learning C++ years ago, but drifted away when I had to learn Java in school, but I learned a lot about programming in general, along with game programming over the years where once I knew the language, I just started programming again. I obviously don't know every in and out of the language, but i'll run into a problem, and look for advice to solve it. That way, I know what information I actually know, and refine it by using it, and learn things that I don't know by figuring out that I clearly don't know it.

Every post I make asking for advice on these forums, I do after much trial and error on my own part in actual programming, and not just getting stuck and hiding from my problem by getting you guys to do my work for me. :)
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1