class CGame
{
public:
CMap *m_pMap;
CCamera *m_pCamera;
void Initialize();
void ShutDown();
void Update();
void KeyCheck();
void Draw();
};
Of course that''s not anywhere near completion, just some basics are in there. Or should I seperate the functions such as doing keychecks and graphics?
Thanks in advance.
Overboard with the OOP?
How much OOP is too much? I see some people with their entire game as a class and I don''t see a clear benefit to doing this. For example, should I structure my game like this?
Don't worry too much about design if you are unexperienced. Focus on getting things to work instead.
[edited by - doho on March 22, 2004 1:37:53 AM]
[edited by - doho on March 22, 2004 1:37:53 AM]
there is no correct design, nor any correct amount of OOP ... OOP is a set of tools in your toolbox to build applications ... to help you with things like application organization, maintenence, quality, and other things which are common areas where programs fail to live up to expectations, or where reinventing the wheel each time is too costly. It sits along side every other decision you have to make, such as what variable names you use, how you handle errors, and what platform you target ... and when you violate the tenets of OOP to get a job done, only time can tell you if you we're "right" ...
This question is a little bit akin to a new painting student asking, "How green should the trees be? I see some people who paint their trees as a pure forrest green, and others who use many auburns and browns. Here is my quick outline of a tree, does this seem ok?"
That is a valid question .. just as long as you realize, all we can do is tell you what works in OUR minds, the way we think and program. In the end it is only up to you to be happy with your work or not - and to change the next time if you are not happy with the results ... to keep growing as a programmer.
I personally have grown to use many different interfaces to organize my programs ... but nearly all of these organizations we're invented DURING or AFTER the first time I solved the problem in code, not before ... because the really good models that SIMPLIFY the program and don't hamper your options are hard to see as you look at the blank page.
If you learn to refactor your code, to fight against time and weight's efforts to turn your growning code base into and unintelligable / unorganized / buggy mess, then you will probably eventually have a code base which functions AND pleases you AND allows you to build more programs much more quickly than the last. But you start by building programs first.
Most real invention works that way ... people didn't think up good bricks when they first needed them ... they just used whatever they knew at the time. Then they kept the designs that worked, and repeated and refined those processes, while getting rid of the ones which did not work.
[edited by - Xai on March 22, 2004 1:50:26 AM]
This question is a little bit akin to a new painting student asking, "How green should the trees be? I see some people who paint their trees as a pure forrest green, and others who use many auburns and browns. Here is my quick outline of a tree, does this seem ok?"
That is a valid question .. just as long as you realize, all we can do is tell you what works in OUR minds, the way we think and program. In the end it is only up to you to be happy with your work or not - and to change the next time if you are not happy with the results ... to keep growing as a programmer.
I personally have grown to use many different interfaces to organize my programs ... but nearly all of these organizations we're invented DURING or AFTER the first time I solved the problem in code, not before ... because the really good models that SIMPLIFY the program and don't hamper your options are hard to see as you look at the blank page.
If you learn to refactor your code, to fight against time and weight's efforts to turn your growning code base into and unintelligable / unorganized / buggy mess, then you will probably eventually have a code base which functions AND pleases you AND allows you to build more programs much more quickly than the last. But you start by building programs first.
Most real invention works that way ... people didn't think up good bricks when they first needed them ... they just used whatever they knew at the time. Then they kept the designs that worked, and repeated and refined those processes, while getting rid of the ones which did not work.
[edited by - Xai on March 22, 2004 1:50:26 AM]
I created a CDirect3D class for using d3d, a CDirectInput class for getting keyboard input, CTimer, CFont, etc...
Then I created a CGame class that is used as a level. I am going to make CGame a base class for more levels eventually.
if you want to see the CGame class and WinMain
check out this other post
http://www.gamedev.net/community/forums/topic.asp?topic_id=214646
Then I created a CGame class that is used as a level. I am going to make CGame a base class for more levels eventually.
if you want to see the CGame class and WinMain
check out this other post
http://www.gamedev.net/community/forums/topic.asp?topic_id=214646
I agree with Xai. Here''s my take on it:
I''m the sort of person who has to organize. I guess I''m a bit Obsessive/Compulsive. A place for everything and everthing in it''s place - not that you could tell that by looking at my house! LOL!
But I love OOP because I can abstract everything out as far as I want. But I don''t start out that way. For example, I''ve most recently been experimenting with DirectX sprites. I created a basic program using the VS.NET DX wizard and then i started changing stuff. Then I began adding sprites and they were added in the same function that initialized the D3D stuff. Then I abstracted things out to seperate functions. Most recently, I created an entirely seperated class (called SpriteObject), in it''s own files even, that can be reused in another program. This class creates a sprite object and stores up to 10 textures for it as well as screen coordinate vectors, etc. So now, if it want to simply draw the sprite to the screen, I just call SpriteObject.Draw(1), for example, and it will draw it using my default parameters and the first texture in the list. I can still, however, access the sprite directly in the class. So, if I wanted to draw using different parameters I could call SpriteObject.Sprite->Draw(yadda, yadda...).
This is what OOP means to me. The ability to break things down into logical units that are as self-contained as possible. Next, I''ll probably add more functionality to my SpriteObject class such as letting it keep track of animation itself. As it is, today I added an animation but the texture that is used (the animation frame) is determined outside of the object. I want the object to be able to say: "Well, I''m exploding right now, and I''m currently on the 3rd frame of animation, so I need to go up to the next frame for this render pass."
Erm, not that my SpriteObject is sentient or anything.... yet.
Either way, I would say that the "right" amount of OOP for you depends on how much you need. If you''re able to write the entire program without ANY OOP and still keep it straight without pulling out your hair, then go for it. It''s just another tool in your toolbox, as Xai sorta put it... Personally, I gotta break it down myself. But I''m a bit OCD... :-D
Rattlehead
PS: Another good thing about OOP... It helps to keep concepts seperate so that there''s less confusion when you''re trying to learn something new!
I''m the sort of person who has to organize. I guess I''m a bit Obsessive/Compulsive. A place for everything and everthing in it''s place - not that you could tell that by looking at my house! LOL!
But I love OOP because I can abstract everything out as far as I want. But I don''t start out that way. For example, I''ve most recently been experimenting with DirectX sprites. I created a basic program using the VS.NET DX wizard and then i started changing stuff. Then I began adding sprites and they were added in the same function that initialized the D3D stuff. Then I abstracted things out to seperate functions. Most recently, I created an entirely seperated class (called SpriteObject), in it''s own files even, that can be reused in another program. This class creates a sprite object and stores up to 10 textures for it as well as screen coordinate vectors, etc. So now, if it want to simply draw the sprite to the screen, I just call SpriteObject.Draw(1), for example, and it will draw it using my default parameters and the first texture in the list. I can still, however, access the sprite directly in the class. So, if I wanted to draw using different parameters I could call SpriteObject.Sprite->Draw(yadda, yadda...).
This is what OOP means to me. The ability to break things down into logical units that are as self-contained as possible. Next, I''ll probably add more functionality to my SpriteObject class such as letting it keep track of animation itself. As it is, today I added an animation but the texture that is used (the animation frame) is determined outside of the object. I want the object to be able to say: "Well, I''m exploding right now, and I''m currently on the 3rd frame of animation, so I need to go up to the next frame for this render pass."
Erm, not that my SpriteObject is sentient or anything.... yet.
Either way, I would say that the "right" amount of OOP for you depends on how much you need. If you''re able to write the entire program without ANY OOP and still keep it straight without pulling out your hair, then go for it. It''s just another tool in your toolbox, as Xai sorta put it... Personally, I gotta break it down myself. But I''m a bit OCD... :-D
Rattlehead
PS: Another good thing about OOP... It helps to keep concepts seperate so that there''s less confusion when you''re trying to learn something new!
class Post { public: Post(); string nick; string comment; private: string password; };Post::Post(){ nick = "Manip"; comment = "You can never have too much OOP!!!"; password = "Password"; }
Thanks for the great replies guys. I''ve already done two clones of games (Slime Volleyball and an obscure little strategy game called Virus) and the only OOP those had were the balls just to hold information.
I think I''m going to seperate my game and my graphics code up into two different classes then work my way on from there. My last games mixed graphics code with gameplay code and it turned out... ugly. The games worked, at least.
I think I''m going to seperate my game and my graphics code up into two different classes then work my way on from there. My last games mixed graphics code with gameplay code and it turned out... ugly. The games worked, at least.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement