adding a physics engine...

I believe you should separate your physics engine from your rendering engine.
I would then think of a pong ball like it contains from following entities:
1. Renderable entity
2. Physic part entity

When going farther to game logic, I suggest to create a class that will handle both of these entities, like this:

class CPongBall : public IGameObject {
IRenderableEntity m_pongballentity;
IPhysicEntity m_physicentity;

Kill() {
physic_Engine.unregisterEntity(m_physicentity);
render_Engine.unregisterEntity(m_pongballentity);
}

// i think you've got the point
};

Thus, the game logic module will operate without knowledge anything about render and physic engines.

by rendering engine I'm guessing you mean the graphics?

I am a noob at game programming though and I also havent had a lot of experience with OOP, hence my posting here for an idea of implementing this. So my next question is:

What are you thinking with the IGameObject? I dont need a full run down of code though...just sort of the theory behind it if you could please?

We can assume there is a Graphics Engine and Physics engine. From there I've got Main that has an instance of the ball and two instances of players each of which have an instance of a paddle.

Main
- Ball
- Player1
- Paddle
- Player2
- Paddle

Okay, I probably jumped too far from a beginner's experience.

IGameObject is an abstract interface for all game objects. It must have enough members to satisfy the Game module (you call it Main).

At least, you can determine what your game needs to do with its objects. For example:

1. LoadFromFile(...) - here you can load the renderable part, i.e. texture and mesh, or sprite. Also, you can load physical information, such as simulation model type. The ball can be represented as a sphere, paddle as a box. Physic engine will use this information to determine how this object will interact with others.

2. SetObjectPosition(x,y,z) - when pong game starts, you will want to place player's paddles at their initial positions.

3. GetPosition() - you can pool this to check whether a ball went outside critical zone, or, you'll probably want to use this information for a paddle to check whether it hitting the ball or not. Usually this is done by physic engine.

4. Move(vector) - player can start moving his paddle.

5. SetSpeed( float speed ) - can be set from player's mouse speed for a paddle, or can be set to affect the speed of a ball in some special cases.

6. bool IsMoving()

7. Update(float frametime) - if your game objects wants to update its internal states, then this is where it must do it.

8. Freeze() - you can call it for all of your objects when pausing the game.
9. UnFreeze()

10. Show() - can be used to ask rendering engine to show the renderable part, and/or physic engine to set physic part in its active objects list for simulation.

11. Hide() - vice versa.

10. Kill() - usually, used when you don't want to use this object any longer. So, physic and render engines must completely forget about it.

Thanks for the reply...it makes a lot more sense now!!