Sign in to follow this  

Class building

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

Ok I'm on my way to creating some little console games. I'm not so new to programming but have never really embarked on a real project before. I've decided to make a game in just a Win32 Console so i thought i should create a class(es) to help out with all the things i will have to do. This class can be reused for other projects i plan on doing (my hope is to create a few different types of games in a console enviroment) So in the process of trying to come up with these classes the whole OO stuff has started to bog me down: Say i have a class that handles the screen, one for input, one for time. These are basically all i need. so that's fine, but what if i want to create one class that encapsulates all that for ease of use like: CConsole Then i could simply go: Console.Screen.Draw() or Console.Input.GetKey(KEY_A) But this is bad programming isn't it? Like my console class is having to allow access to its data members (the screen and input object). To solve this i could simply make the objects private and do like Console.Draw() but this seems redundant. Is it? Or would this be the proper way to do this. The second problem is that if i don't put the Screen and Input objects into like a main console class then when i want the console to be able to do something specific like draw a rectangle of stars or something stupid that i would probably do alot i would have to have the method be passed a pointer to a screen object. This solution, to me, seems useless if i have to pass the screen anway inorder to use all the functionality of the class. So basically i'm in a design deliema. I know it's probably going a little over the top for a Console game but i would really like to bulid some proper, well designed code for these games before moving on and tackeling Windows programming or Direct X. Any ideas would be great. Thanks

Share this post


Link to post
Share on other sites
Quote:
Original post by SirSmokey
Ok I'm on my way to creating some little console games. I'm not so new to programming but have never really embarked on a real project before. I've decided to make a game in just a Win32 Console so i thought i should create a class(es) to help out with all the things i will have to do.
Bad move. Until you've been the client, you have no idea what services to provide. By this I mean that until you've used the class libraries of others (or built up your own horrible hacks as you go along), you have no idea what is really needed and makes for a good design. Unfortunately, far too many people embark on and encourage this approach, which is part of why so few projects are finished.

My recommendation is to find a library that you consider feature-complete and use that to develop your first game. Based on that (and possibly subsequent) project, you'll have the insight into what functionality your class library needs to provide.

Happy hacking.

Share this post


Link to post
Share on other sites
I'd consider it like this:

You're creating a program that is, by design, only supposed to be supported by the console even in future revisions, versions, etc.

Just keeping that in the back of your head while you write the game might make a world of difference. Consider, now, that you were concerned about having to pass a pointer to a Screen class as an argument every time you wanted to draw a new frame on the screen. Most computers, fortunately, only use one screen though, right? One screen, one keyboard for input, one audio device for playing sounds, and so forth.

What I'd do is something like this:


/**
* Defines several extern global pointers to common classes the app uses.
*
* @file global.h
*/

#include "Screen.h" /* this defines the Screen class */
// define a global pointer to a Screen class instance that will be initialized
// in main() during program initialization:
extern Screen *gpMainScreen;

#include "Keyboard.h" /* defines the Keyboard class */
// global pointer to a Keyboard class instance initted in main():
extern Keyboard *gpKeyboard;

/* etc, etc */


And then, in main.cpp, you'd do something like:


/**
* @file main.cpp
*/

#include "global.h" // to define global class instances

// These are expected to be somewhere since global.h declares them extern...
Screen *gpMainScreen;
Keyboard *gpKeyboard;

// ====================
//
// main ()
//
// ====================

int main (int argc, char *argv[])
{
gpMainScreen = new Screen;
gpKeyboard = new Keyboard;

init_more_junk();
main_loop();

// delete unused data before main() returns:

delete gpMainScreen;
delete gpKeyboard;

return 0;
}


Then, in a file that included your draw() function, you'd just include global.h and use gpMainScreen as your instance to the main screen.

Clever, intuitive designs should really take some planning. It's not something I practice enough myself, but there's one rule that I always try to follow: KISS - Keep It Simple Stupid.

Hope this was helpful. [looksaround]

-svx

-svx

Share this post


Link to post
Share on other sites

This topic is 4665 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this