Jump to content
  • Advertisement
Sign in to follow this  
dzeligman

Seeking Tangible Help on Game Architecture/Design

This topic is 3629 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 .

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
You really just need to experiment, see what you like. In that particular case, I'd say go with the non-abstract class, as long as you are only going to have a few types. But try it both ways, and see which works better with the rest of your system. It's not too hard to change.

This article might help with inheritance issues: http://www.objectmentor.com/resources/articles/lsp.pdf

I found this one particularly helpful on other architectural issues
http://www.objectmentor.com/resources/articles/dip.pdf

They are a little dense, but they're worth reading carefully.

This page contains links to those articles, and many others. Look through them, especially the ones in the link labeled design principles.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!