class CFoo {
...
int GameStateInit(void * whatever);
int GameStateQuit(void * whatever);
int GameStateMain(void * whatever);
int Render();
...
};
CFoo::mainloop()
{
//...
this.AI();
this.physics();
this.Render();
//...
}
// then in main...
int main (whatever)
{
CFoo the_foo;
Foo.init();
Foo.mainloop();
Foo.quit();
}
Classes and games
Author
I'm a semi-beginner (I've accumulated knowledge but not the experience), and I've noticed that most people seem to be using a lot of classes in their games, for pretty much everything.
My question is, is it a good idea to use classes for EVERYTHING in a game? I mean like MFC style, only instead of overlaying Win32, overlaying the rest of the game so all you do is fill in the different game states? Here is sort of what I'm talking about:
Is this how I should approach my programming from now on?
It is kinda really a matter of your own style. Thats how i do it, but i have also done it with the input system inside the main() function. The point of OOP is for ease of code use and so you dont have to chop up huge peices of code when messing with it.
It's really up to you. I have used both, i personally dont care for either way more..whatever works for me. I have found, however, that the bigger projects usually are good to have everything in classes (like you have).
It's really up to you. I have used both, i personally dont care for either way more..whatever works for me. I have found, however, that the bigger projects usually are good to have everything in classes (like you have).
Quote:Original post by Oberon_Command
My question is, is it a good idea to use classes for EVERYTHING in a game?
Absolutely not. Object-oriented programming is just a tool, use it where it makes sense. Does it make sense to manage your game as a series of states with each state being an object (ie. a class)? It can. Does it make sense to implement your maths library as objects? I don't think so.
As for the design you mention, it looks like your trying to make an engine, not a game. I suggest you just start by worrying about the game to begin with and don't be overly concerned with the design. If you don't have the experience you're not going to be able to tell what design choices are good or bad. Once you've got a few small games under your belt, THEN start thinking about making a bigger, 'well designed' game.
If the only person that is going to see / work on the code is you, then by all means, design your games whichever way you feel best in doing so. However, if you have a team working on a project, or you have a very large project, the usefulness of OOP starts to become evident. If you want my opinion though, I would strongly suggest becoming familiar with the use of OOP, as it helps promote good program design.
The key ideas are to avoid duplicating stuff, organize the code into coherent bits of functionality, and have logical data structures to represent various "things" with functions that represent their logical "behaviour" rather than simply allowing for random manipulation of their data. It so happens that OOP is a very nice way to accomplish those goals, most of the time. With practice and experience, you will learn how to pick the best tool for the job. You can develop a pretty good instinct for it by making an effort to understand the concept...
I got the same problem, i dont see how using classes is better than not using them, i feel more comfortable using many globals and functions rather than using functions. My main reason is the way of how everyone tells you how classes work but they dont say when its a good idea to use them or why??
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
