# Planning/Design Classes

This topic is 3310 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

(Using: C++, SDL) So, I'm working on my second 2d game that focuses on concepts like motion and frame rates. The first game with graphics I made was Tic-Tac-Toe. So, in that game, when I updated the screen, I had a function called updateBoard where it displayed the current state of the board such as the board itself, any markers that have been placed, etc. With this game that I'm working on, I'm having trouble trying to know where to put things. The maximum things that should be on the screen at once are: 1. Background 2. Distant moving objects 3. Foreground 4. Score 5. Life Counter 6. Asteroids 7. Player I know that I should create a function that updates all components of the screen at once, once logic has been checked. I know that I should have separate classes for things like the player, the asteroids, and the distant moving objects but what about the background and foreground? I feel like creating classes for those is a waste of time and memory but then again I don't ever use global variables. The background and foreground don't ever do anything but display to coordinates (x,y). btw...my game is not an asteroids clone. The player is a robot on a station who needs to dodge asteroids from hitting him.

##### Share on other sites
Really, it all boils down to what is going to make your life easier. You need to consider what information each part of your code will need to know about your backgrounds and how best to send that information. I often find it useful to start and the end goal and work backwards.

For instance, you could make a general-purpose Drawing function that takes an object of any type (asteroid, player, background) and then simply draws it. All you would have to do is call the function, passing the object in, and it would draw the object right then and there.

So, the question is, what info would the function need in order to do its job? If I remember correctly, the SDL blit call needs to know what SDL surface to draw from, the source rect, and the destination rect. It may also need to know what surface is the back buffer (I don't remember, but you probably already know).

So, your function might look something like this:
void DrawItem(SDL_Surface *targetSurface, RenderableItem *pItem){    SDL_Blit(targetSurface, pItem->SrcSurface, pItem->SrcRect, pItem ->destRect);}

Forgive me if my function names and arguments are off -- I don't remember SDL very well, but I think this gives the general idea.

RenderableItem, in this case, would be a class or struct that you make, that has (minimally) a pointer to an SDL surface where its image data lies, and a source and destination rect.

Now, to put this generic RenderableItem struct to use, you could add a RenderableItem to each class that needs it (the Player class, the Asteroid class, etc.). Or, if you're familiar with inheritance, you can derive your other classes from the RenderableItem type.

Either way, you'll need to update the destination rect each from for moving objects, like players and asteroids. For objects that animate, like the player, you may also need to update the source rect.

Once everything is all updated, draw all the objects using that function, and just make sure to draw them in the right order (background first, then the player and asteroids and stuff, then the score).

This is one way to do it. It allows you to have multiple object types that all pass common data to a single function to be drawn.

Alternately, you could have each class define its own Draw function, and each frame, after everything is updated, you can iterate through your lists of objects and have each object draw itself in its own way.