Try just sitting down and drawing out how your game will work. For example, sit down and draw a little circle, and put "game" in that. Then draw a bunch of lines off of that and write down all of the things that will go into your game. Let''s say you put down resource management, rendering, UI, character animation, sound, and so on. Then go into each of those and break them down. Say under UI, you''ll put down developer console and game input. Decide on all of the features you want to incorporate into your game. Then sit down and think, ok, what objects do I need to make all of this work? You need a keyboard object, a mouse object, a console object, and so on. Then ask yourself, what functionality does each object have to provide? The keyboard object should be able to tell you whether a key is down or not, whether it is being pressed or released and so on. Then develop a class that does all of that. So the basic process you''ll be following is:

1) Figure out what you want to do
2) Develop classes and libraries that do it
3) Write high-level code that uses classes to solve your problems

Then, once you have a keyboard object, you can do things like:

if(kbobject.keydown(VK_TAB)) sound.playmp3("test.mp3");

The idea is to eventually get your high-level code to be really really general and understandable, with all of the nasty details handled by objects.

You should also do little diagrams to define which classes require other ones. For example, if you do a resource class, which supplies handles to various resources like textures or sounds, you''ll probably wnat your texture object to inherit from the resource class. A heirarchy of classes will help you keep this straight. Don''t be afraid to have classes interact a bit, but if a class doesn''t function at some level as a self-contained unit you''re writing spaghetti code.

So to sum it up:

1) Think before you code
2) Heirarchies are the best way to organize your program and classes
3) Keep class interaction to a minimum
4) Make sure each object corresponds to a specific task

If you''re still not clear on stuff, if you give us a rundown of your class structure, I''d be happy to point out what''s good and what''s not. OOP is not so much a set of rules as a way of approaching a problem, and the best way to learn it is to write lots of spaghetti code, forcing you to clean it up again and again. In my own game engine, everything is an object, even the opengl window. Then there''s just one cpp, called imnplementation.cpp, which implements the draw routines, the update which gets called every frame, and so on. The more object-oriented your code is, the easier it will be for someone else to understand what you''re writing (and the easier it will be for you to reuse your code later).

What Ishan said isn''t wrong, but can''t be considered enough for those wishing to master OO.

To program proficiently using OO you must know Design Patterns. Read the book "Design Patters" (Erich Gamma, print by Addison Wesley) or look for other references about design patterns (I believe you can find some at ootips.org).