Quote:Original post by Dave HuntQuote:Original post by Trillian
Anyways I think there's some nice tutorial on organising C++ code files in the ressources section of this website, check it out.
Organizing Code Files in C and C++.
Precisely, thanks =)
Correct design for a DirectX Engine
Precisely, thanks =)
Rule of thumb: do NOT include header files in headers.
Some exceptions apply to the above statement, but most of the time you don't need it.
First thing, when you go about designing your architecture, think about what you require and how you intend to use it. So far I've not run in to a single problem I couldn't solve by just organizing my headers.
Inclusion guards, never needed them, and probably never will...
Forward declarations are great, but don't overdo it!
Some exceptions apply to the above statement, but most of the time you don't need it.
First thing, when you go about designing your architecture, think about what you require and how you intend to use it. So far I've not run in to a single problem I couldn't solve by just organizing my headers.
Inclusion guards, never needed them, and probably never will...
Forward declarations are great, but don't overdo it!
My design thought:
Dont inherit Tank from Sprite.
Why?
Is tank a sprite in reality? No it isnt. Sprite is mere representation (possibly one of many) of the tank entity itself. Prefer containment to inheritance and your code will be more flexible.
You can also add TankController class later which can be user input driven or AI!
Nice article about game obejct design is here (and guess what - their example is a tank! :o)
http://www.gamasutra.com/features/20050414/rouwe_pfv.htm
MaR
Dont inherit Tank from Sprite.
Why?
Is tank a sprite in reality? No it isnt. Sprite is mere representation (possibly one of many) of the tank entity itself. Prefer containment to inheritance and your code will be more flexible.
You can also add TankController class later which can be user input driven or AI!
Nice article about game obejct design is here (and guess what - their example is a tank! :o)
http://www.gamasutra.com/features/20050414/rouwe_pfv.htm
MaR
I was going to say the same thing as Mar_dev. You should think about using composition rather then inheriting directly from sprite.
One trick I find works well is when you're designing an inheriting class is to ask yourself if the IS A makes sense. So in your example, tank IS A sprite, this doesn't really make sense because a tank isn't a sprite, it has a visual representation like the armor and the wheels, but it's not really a sprite.
Always important to seperate the logic regarding an object from the actual visual representation of this data. Another way to look at it is when you're cycling through your list of renderable objects, does it really make sense to be rendering a class which has logic in it to move and shoot?
Don't sweat it too much though, design is something that takes a lot of time to start to begin to become good with. Just study some of the various design patterns and how they are applied with games and it will become easier with time.
One extra note, avoid using singletons in your code base, they lead to lots of problems further down the road. They may seem to work well in smaller projects but as your project grows you will find they really get in the way and cause more problems then they are worth.
One trick I find works well is when you're designing an inheriting class is to ask yourself if the IS A makes sense. So in your example, tank IS A sprite, this doesn't really make sense because a tank isn't a sprite, it has a visual representation like the armor and the wheels, but it's not really a sprite.
Always important to seperate the logic regarding an object from the actual visual representation of this data. Another way to look at it is when you're cycling through your list of renderable objects, does it really make sense to be rendering a class which has logic in it to move and shoot?
Don't sweat it too much though, design is something that takes a lot of time to start to begin to become good with. Just study some of the various design patterns and how they are applied with games and it will become easier with time.
One extra note, avoid using singletons in your code base, they lead to lots of problems further down the road. They may seem to work well in smaller projects but as your project grows you will find they really get in the way and cause more problems then they are worth.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
