• Advertisement
Sign in to follow this  

Game classes

This topic is 4043 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

Well, still working on the timescape I need to begin actually programming my ultimate game. :-) ITMT, I've been reading up on a few things, including the PopCap engine. A technique, if you will, seems to be in fairly common use, not only in games, but in other applications, wherein the application is defined as a class unto itself and a single instance of the class is declared. The Windows (or other OS, I presume) entry point is defined somewhere in the object and control of the program/game procedes from there. The programmer designates something like a Run() function to get things really underway. My question is, what is the point of designing a program this way? Maybe if I could get my head around the reason, I wouldn't be as confused as to how to conceive my game. Is this a means of packaging a framework? Putting on airs? Being different? Thanks, Lilith

Share this post


Link to post
Share on other sites
Advertisement
I think the thing you're referring to is called a Singleton. I am not entirely sure because I'm not the best coder, but that's what I've picked up.

The point of a singleton (and I'm not even sure if the idea of a singleton is proper standard or efficient) is if you only want exactly 1 instance of that - never ever more.

Thats about as far as I can explain :(

Share this post


Link to post
Share on other sites
Amoung other things, building a test harness around your app just got lots easier.

Second, this delays the "real start up" to a point after the C run time and static initializers have been run, and the "real shut down" to some time before static destruction and the shut down of the C run time. These times are far more controlable.

Third, it gives a place to store "global variables". This provides a bit of dicipline. You could even get extra keen and insist that your application is capable of being created and shut down multiple times in a single program launch. This is somewhat challenging sometimes, but the result gives you a large amount of flexibility.

Forth, this removes the "how your game options are set" problem from the game itself. Your entrypoint is now a function -- you can place the arguement parsing or a pre-launch dialog code outside of your game proper.

Fifth, it allows you to more finely deliniate "side-effect-less" functions. A function that takes no pointer or a const pointer to your game doesn't change your game state, while one that takes a normal pointer can change your game state.

There are a bunch of reasons. They may not be convincing -- but they can help.

Share this post


Link to post
Share on other sites
Quote:
Amoung other things, building a test harness around your app just got lots easier.

[snip]

There are a bunch of reasons. They may not be convincing -- but they can help.


Quite a bit to consume there and I'm not sure I'm going to see it all in one glance. I may have to try this two or more ways to see what works and if I can warp, uh, wrap my head around it. Thanks for your input.

Lilith

Share this post


Link to post
Share on other sites
The reason is also for consistency. Everything, including the the highest level of the application, is an object.

Share this post


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

  • Advertisement