Sign in to follow this  
jeemigdepeemig

O.O. design principles

Recommended Posts

Hey all, I'm making a game in C++ for fun and it's getting larger larger, the managing of the project isn't a problem yet but it soon will be if I don't do something soon. What I have is a Game class and a Sprite class. The Sprite class evolved into a sprite and character class really (it manages sprite control, hitpoints, movementpoints). What you really want is a structure like (I think): A game class calls a characterclass-functions which calls spriteclass-functions. But if I define a character in the gameclass and i want it to move cause the user clicked on a tile to the left to it how should i call the sprite class? It seems not right to pass parameters to a character-class function which just passes the parameters to a Sprite-class function. I would really like to know what's the best way to organise the classes. Thanks in advance

Share this post


Link to post
Share on other sites
Since, presumably, there is going to be one sprite per character, I don't see why the sprite class needs to be within the character class. It seems to me that the best way would be to have the character class contain everything about the character, including type, position, health, etc. Then the only thing left is to translate that data into exactly what gets drawn on the screen, which could even be done from within your character class (character->draw or whatever) without a seperate class at all.

Maybe this isn't what you want, but it just seems that each character has a corresponding sprite, so I don't see why you'd even separate them.

Share this post


Link to post
Share on other sites
Sprite and character should be seperated IMO. Sprite is basically a bunch of animation. There could be one Green Monster sprite, for example, but several Green Monsters running around in the screen at the same time.

Jeemigdepeemig, in your case you must seperate in your head what a "character" is and what a "sprite" is. The sprite doesn't have a position, or even a current animation frame. It's a resource. You don't move or animate the sprite, you move and animate the character and you draw a copy of the sprite in the position of the character and at the current animation frame of the character.

Share this post


Link to post
Share on other sites
mikeman's right that you need to separate the character class from the sprite class. I find it's best to try to think in terms of what each object would do. A Green Monster might Move(), Talk(), Fight(), etc, but a Green Monster would never BlitToScreen().

In my experience, it's been best to separate the program into three sections: game, data, and presentation. The game section would contain the classes that move characters, update the attributes of the world, and so on. These operations would affect information that's stored in the data section. It's then up to the presentation to read what's in the data section and display it on screen (or play the sound, or whatever).

game <------> data ------> presentation ------> screen, speakers, etc.

HTH.

Share this post


Link to post
Share on other sites
haha, hey Holding! w.t.f. what a coincidence [smile].

Yeah I make webapplication with Silverstream (s.s. Java) as a parttime job and now i'm making a Pocket PC game, just for fun.

Cool man, I could use some help... speak to you soon online.

Share this post


Link to post
Share on other sites

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