O.O. design principles

Started by
4 comments, last by jeemigdepeemig 18 years, 5 months ago
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
Advertisement
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.
-~-The Cow of Darkness-~-
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.
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.
jeemig??? No, it cant be you can it?

Why didnt you say you were a coder?

talk to me online man and i can try and help you
visit my site http://www.fullf1.com for all your formula 1 and music creation needs.
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.

This topic is closed to new replies.

Advertisement