How should a typical C++ program look/work?

[EvilDavo]

Hi.
You've probably been asked this a million times in one form or another but, ....
What is the correct way to write a C++ OOP program (eg. for a game)?

I've researched the concepts of OOP several times over a long period of time and I have a (seemingly) decent knowledge of C++, but as soon as I go to apply OOP principles to a major project, I get stuck (because I didn't really understand how to practically apply OOP).

I understand how to get the program to compile whatever I do. So I know how to do multi-source programming, how to declare a class in the header, and give it's guts in the source.... etc.

But when it comes to say, having different components of a game, Graphics, Sound and objects, Alien, HumanShip, Gun, .... (just generic game stuff. I'm not focusing on a project atm, just want to understand C++ properly before diving in again)....
I run into problems.

Could you provide a general overview of what a C++ program should look like. I really need to get my head around it properly so I can actually use it.

Thx for your time.

[Tom Gunn]

I don't think that kind of thing can be taught. You just have to read code to see how other programmers did it and try out things for yourself. The more you do it the better you'll get at it. There's no 'right' way to design OO programs. Nobody can agree on what OO even means, much less how it should be practically applied. ;)

Start small and build on what you learn. That's how I did it, but I'm still not good at OOP.

[kvprajapati]

Never loose patience to learn the tiniest feature of a programming language. Only the practice taught you the principle of program design.

[EvilDavo]

Fair enough.

I've tried looking at existing OOP code, but because it's multi-source, it generally tends to be very cryptic. Too cryptic for me to visualize how the program might actually work altogether, or even find where, how and in what class they're storying the data.

Hmmm... guess I should just keep learning, see if I can find something useful.

Are there any 'basic' guidelines to give a hint maybe?

[mOoEyThEcOw]

I did lots of searching and application, type things like game engine design in to google, it gave me some good ones, but to me you sound right on track. Just think of a way to design it, then try it, see the short comings and redesign after learning from your mistakes.

[EvilDavo]

Thanks for letting me know that there is no right way, I can just try my own ways until I find what is most efficient. Having that burden off my mind was all I needed. I'm actually starting to figure out something I think.

If anyone's interested here's my concept. Hmm.... it's a lot harder to read without the syntax colouring of vc++ :P

// concept (these classes are declared in reverse order to what they should be, to demonstrate my thinking)

int main ()
{
	Manager manager;
	manager.Run();
	return 0;
}

class Manager
{
	Engine engine;
public:
	void Run();
};

class Engine
{
	Renderer renderer;
	GameManager game;
public:
	void RenderGamePlayer (); // methods that need the data from both the renderer and the game go in Engine
};

class Renderer
{
	// keep renderer-specific data in here
public:
	void drawSprite (Sprite sprite); // methods which only need Renderer data go in here
};

class GameManager
{
	// game data
	Sprite currentSprite;

	SpriteManager spriteManager; // (these objects can by dynamically allocated)
public:
	void SetSprite (Sprite newspr); // methods which only need GameManager data in here
	void Duplicate_Current_Sprite (); // also, methods which use both GameManager data and SpriteManager data go in here
};

class SpriteManager
{
	// sprite manager data
public:
	void CreateBlankSprite (int w, int h); // methods which don't require data outside of SpriteManager go in here
};

// general-purpose functions are global
void UtilityFunction ()
{
}

// note. use vector<>'s to keep lists of data,
//       or a list of dynamically-created objects, if you want to give it an automatically managed virtual function (maybe manage that from
//		 the Manager class).

[EvilDavo]

Hmmm... that technique is such a hassle when it comes to data access.

Maybe I should go back to the good old days of having global class instances.