Trying to be all Object-oriented. But for example in my Pong game that I am starting out with while learning SDL, I have a bunch of globabl variables of type SDL_Surface* which are all the images/backgrounds/fonts and such used by the program. Then in the main, I instantiate two "Paddle" objects to represent each paddle. The Paddle class has a copy constructor which initializes the x and y values of the paddle and then dislays it and such. It also has a hadle_input() function. My question is, is this a good approach for the input, or should I handle the input in a standard function outside of the class. Because if I do it this way, I don't know how to tell the function what keys to use to move the paddle. I am using SDLK_UP and SDLK_DOWN for one of the paddles, and SDLK_s and SDLK_x for the other. Is there any way to pass these values through parameters? I don't know much about enums. I tried using the integer equivalent of those, but the paddles became all jittery when moving so that doesn't work. BTW, this is my first game in SDL, really my first game, so just wondering what the standard method is, and if this is a good approach or should I just not have a Paddle class since I know there will be two paddles. Even still, can those enum values be passed through parameters?

Your paddle objects should have very explicit interfaces, much like a car does. A car has functions like Start(), Shift(), Accelerate(), Brake(), and Fillerup(). A car would NOT have public functions like InjectFuelToEngine(), or IgniteSparkPlug(). Those are internal sorts of things the driver ought not to be worrying about.

Now consider a Paddle object. What does a paddle *do* that a client would care about?

MoveUp()
MoveDown()

And that's about it really. So your event handling should be in more a global area. You decode the incoming events and pass them to the appropriate object/function. Like so:

// pseudocodePaddle p1();Paddle p2();while (event e) {   if (e.type == button press && e.button == SDLK_UP) {      p1.MoveUp( some_amount );      }   }

Nice, that more than answers my question, exactly what I was looking for, leiavoia. thanks, will do that.

yeah, but it is so tempting to have global variables for like picture names which you might want to change to something else, so you don't have to look through all your code to find where it is. Also, the constats like X_MIN or X_MAX and such, I make those globals.

Quote:Original post by Lanky007
Also, the constats like X_MIN or X_MAX and such, I make those globals.

You could easily make those defined constants in a header file so that you can easily reuse them all over without them being runtime variables (constant or otherwise). Now, if you do ever want to change them during the game for some reason, then using a global variable may be a good way to go.

Trying to be all Object-oriented is sounding like a willingness to learn and I think Pong is a good starter.

Begin with a small game like Pong and put everything inside the Game class (Not Object Oriented) and when you have your game working in the non OO style you can move portions of code to other classes and fix the code to work with these new classes

Once you have done that you can get into inheritance and make Paddle and abstract base class and derive some funky paddles and then you can spice the game up with little effort.

OO may not be the best paradigm in all situations agreed, but I think that even simple games benefit by using OO because it allows you to add new features (like the pong I suggested above) which would have been very ugly to do without using OO. And in all this you learn the very essence of OOP.