Hey all, I've been a pretty consistent read of these forums, XNA's and a few others and at a point with my game that I could use some pretty solid help. What I could really use is a guide to some sort of standards or examples of either abstract or an implemented game architecture. I have a pretty solid understanding of common design patterns, factories for object creation ,etc. However, understanding better ways for designing the high level class structure of a game is something I would like. Some examples I guess would be comparing the use of aggregation and/or delegation vs inheritance with the pros/cons. The separation of physics,collision,drawing modules within multiple scenegraphs(or something similar) or putting them all together .

This is difficult to find information on, because it falls into the category of 'no best way in general,' that is, the optimal organization starts to become extremely sensitive to the context of the game -- it's individual rules and requirements.

Although I have some minor objections to it, you may want to check out David Eberly's books on game engine architecture. They illustrate one possible organization to the various components that make up a game.

Otherwise you're likely to get more useful answers if you can provide more details about the kind of game you want to build -- and if you don't know what kind of game you want to build, you should make that decision first. The best way to learn this stuff is to practice, and as I said, there is no universal best technique you can learn in isolation.

Years of hands-on experience in general domain are about the only guide you can get. This goes for all design/architecture issues.

The reason is simple: how can be found in books. why is the actual hard question which precedes how, and the very point of design.

People can recite you hundreds of patters and examples, the trick is choosing the right one.

Thanks for the replies. Yeah I definitely realize its a difficult question to approach due to their never being a one size fits all, or a "best way" sort of thing.

I guess I'll try to ask much more specific questions.

The following example deals with a question of whether to split up a class into subclasses or keep a slightly larger one with more passed in parameters.

The game I've been working on a 2d shooter with many different customizations, one being my use of powerups.

Currently I have an abstract powerup class that inherits from my base Gameobject.
It provides an abstract doEffect() method and some other common functionality. Now the only thing my sub-powerupclasses have is their small implementations of the doEffect and a different texture.

Prior to changing the PowerUp to abstract I just had a if statement based off a PowerUp enum for what effect to perform. (I currently only have three different powerups and I probably won't add anymore to keep scope down). The non-abstract one took the powerup type enum and the texture it had as parameters to the constructor.

Basically I find that moving the doEffect logic to a lower level allows for easier addition of new powerups by just making a new class and updating whereever I set the texture for that class, however the old setup was so small and minor I had trouble deciding whether it was even worth it to make the change.

I'm come into a few different decisions like this and having trouble determining what I prefer.