Jump to content
  • Advertisement
Sign in to follow this  
glBender

code organization

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

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

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
I hope your name really isn't Bender.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Thanks for clearing that up.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!