I'm trying to make a simple game using SDL with c++, and I know how to do everything that I want to do with it, but... I just can't figure out how to organize it and keep it manageable. All it is is a tilebased two player game. And I'm trying to do it all OOP, but I dont see how it can all fit together. I was trying to do it with a few different classes, a 'game' class, 'map' class, a 'tile' class, and a 'player' class. The only problem is that I'm trying to keep it spread out across files, so I can keep track of whats going on, but everything starts to bunch up in the main loop of the 'game' class, because its the class that has access to the main surface i draw to the screen.' Anyways, I'll describe what i'm trying to do in a little more detail in case anyone wants to give me some ideas as how to put it together. I want to have two viewports, and each player controls a little avatar and moves around the map, can fight with guns, and then after one wins the round is over, and the winner has can buy some upgrades from a different screen, and then they go at it again. It's really not that complicated, and I have a shell of it working already, but with everything the way it is, i'd have to rewrite the whole thing to add on a feature or whatever. Any help or comments would be welcomed, -bender

I hope your name really isn't Bender.

its my last name

Thanks for clearing that up.

There's no right or wrong way to do this, just readable and un-readable and efficient and inefficient :)

How about moving the drawing stuff into its own class and providing an interface for some common functionality?

Ok, it seems i'm incapable of writing a post that has a point, so forget that first post and give me some advice on this instead. In SDL i have a main class that has the handle to the screen i'm rendering, what is the best way of allowing member classes to draw to the screen too, pointers?

thanks for the reply light bringer, that kind of goes right into my question :)

I don't know much about SDL (or C/C++ for that matter), sorry. I'd ask for some code to look at but I'm going to bed right now. If the functionality is exposed by an sdl object and there is only one, passing a pointer is probably a good idea.

Quote:Original post by glBender
Ok, it seems i'm incapable of writing a post that has a point, so forget that first post and give me some advice on this instead. In SDL i have a main class that has the handle to the screen i'm rendering, what is the best way of allowing member classes to draw to the screen too, pointers?

Personally, I would say don't allow other classes to draw to the screen - instead, allow them to tell your main class what they want to be drawn. In other words, in each frame your main class asks the other classes "what do you look like at the moment, and where in the game world are you?" They can return a pointer to an SDL_Surface and x,y coordinates, and the main class can draw them.

Quote:Original post by Kylotan

Quote:Original post by glBender
Ok, it seems i'm incapable of writing a post that has a point, so forget that first post and give me some advice on this instead. In SDL i have a main class that has the handle to the screen i'm rendering, what is the best way of allowing member classes to draw to the screen too, pointers?

Personally, I would say don't allow other classes to draw to the screen - instead, allow them to tell your main class what they want to be drawn. In other words, in each frame your main class asks the other classes "what do you look like at the moment, and where in the game world are you?" They can return a pointer to an SDL_Surface and x,y coordinates, and the main class can draw them.

Erm, I'd say that's exactly backwards. You want to push responsibility out of main classes/functions and closer to the leaf classes. That's pretty much the point of encapsulation - everything knows how to do its own thing, rather than requiring central classes to know how to do everything.

In the case of a global resource like a screen handle (keeping in mind that I haven't even looked at SDL, so I don't know the specifics there), it's one of the rare cases where it generally makes sense to have it available to all code that's going to be doing any drawing.