views:

375

answers:

4
+7  Q: 

Proper OO Pong

How should I design a "Proper" OO Pong?

The idea of Proper being that any element can be changed: The shape of the ball, the court, and the paddles, adding obstacles, and even "powerups", like "can stick the ball to the paddle".

The two more pressing questions, right now, are:

  • Who checks for colissions? and
  • When a colission does happen, who tells the ball how to bounce?
+8  A: 

I imagine you could make a physics engine object that you update continuously at given time intervals. It would check for collisions, move the ball, compute bounce angles, etc.

EDIT #1: To add a little more detail, the "game physics" object would store, among other things, references to other game objects like the ball and paddles. The game physics object would have an "update" method that would be called continuously as the game runs. Some of the steps this method would perform are:

  • Get the current position of the paddles (which are controlled by the players).
  • Update the position of the ball based on its previous speed and direction and the time that has elapsed since the last update.
  • Detect collisions with other objects (paddles, walls, etc.).
  • Recompute the speed and direction of the ball based on any collisions.

Just a few ideas.

EDIT #2: To elaborate with a bit more of an OO focus...

The various physical objects, like the ball and paddles, would store innate physical states and parameters for themselves (position, speed, mass, etc.) as properties. The game physics object would essentially represent all of the equations of physical motion as methods.

As an example... Let's say you want to model the effects of air friction on the ball. The ball object would store properties such as "velocity" and "drag coefficient". The game physics object would have a method for computing the force of air resistance on an object by fetching the necessary properties of that object and plugging them in to a given equation of fluid drag.

By encapsulating things in this way, updates to the code can be easier. For instance, if you want to use a different equation for fluid drag, the only modification you need to make is to the appropriate method of the game physics object. None of the other objects need to be modified.

gnovice
+3  A: 

Seems to me like the court would be the appropriate object to do the checking, or depending on how complex the logic is, a separate class for dealing with collisions (i.e. some kind of physics engine like gnovice said).

The balls and paddles shouldn't have to know about each other since they're not directly related in an object oriented sense. One doesn't contain the other nor does one derive from the other.

Davy8
+1  A: 

In a typical setting like this. Each object gets a chance to respond to the event of colliding with every other object they happen to be interacting with. In some kind of psuedo(python)code:

class Moveable:
     def Update(self):
          self.move()

class Ball(Moveable):
     def Collide(self, target):
          self.restore() # move out of the bounding box 
                         # of whatever we collided into from 
          self.reflect() # change direction after bouncing
          if target is a Paddle:
              self.speedup() # Make it a little harder after hitting a paddle

class Paddle(Moveable):
     def Collide(self, target):
         if target is a Ball:
             self.AwardSomePoints()

def main_loop():
    ...
    while True:
        for thing_one in Moveables:
            thing_one.Update()

            for thing_two in Moveables:
                if thing_one is not thing_two 
                        and thing_one is touching thing_two:
                    thing_one.collide(thing_two)
TokenMacGuy
+2  A: 

I like to use Model-View-Controller methodology so in that case you would have a game controller that would handle controlling the collision but in drilling down it would just be controlling a controller... it's way too complicated to explain here and I'm not that smart so check it:

http://en.wikipedia.org/wiki/Model-view-controller

Kludge