To all game developers, general C++ game dev approach?

[Seiko]

I've posted this in the coding forum but wanted to ask you guys explicitly so here it is again.
Guys, I'm switching over from VB/.Net to VC++ and wanted some general opinions on what most people prefer in terms of general approach for game programming in terms of class usage etc. I've never really enjoyed the OO approach for games as I think it can often limit a design and end up requiring more code. In short how are people splitting the use of classes and general generic functions etc? I appreciate this is a little vague but he whole argument for and against OO is huge but hopefully limiting to what styles people are using I'll be able to garner a safe direction. Of course I'll tailor this as I progress but I'm very reluctant to start creating millions of classes and methods etc as opposed to a few well chosen generic gaming functions?

Look forward to the comments?

 

[K.I.L.E.R]

The whole point of OOP is to break up a massive project into many little parts.
For simple programs this would mean better/faster error correction as errors would show up in a specific class and the errors would most likely be only in that specific class.

For larger programs it would mean better error correction and a lot of time saved.

How this relates to games?

engine
|
API init
|
inputs
|
etc...

See how they all break up?
You can have someone working on the API init part while another person working on inputs and have another person working on a GUI and so forth.

 

[Anonymous]

thx

The whole point of OOP is to break up a massive project into many little parts.
For simple programs this would mean better/faster error correction as errors would show up in a specific class and the errors would most likely be only in that specific class.

For larger programs it would mean better error correction and a lot of time saved.

How this relates to games?

engine
|
API init
|
inputs
|
etc...

See how they all break up?
You can have someone working on the API init part while another person working on inputs and have another person working on a GUI and so forth.

Thanks Killer, Of course thats the theory although easily achievable with standard and well practiced methods. I was really after a technical breakdown although having had a chance to read a couple more C++ books it's quite apparent as to why classes are utilised so much.

BTW, anyone hazard a guess if John Carmack has finally adopted OOB?

 

[Saem]

An ongoing series of arcticles called Enginuity is up at gamedev.net. I suggest you have a look at the overall architecture there. I think it'll give you some idea as to what needs to be made. Of course, the diagram he put up wouldn't directly translate to objects mostlikely, you'd have to examine the messages being passed and see what's supposed to become and object and what's not.

 

[Anonymous]

thx, nice article

An ongoing series of arcticles called Enginuity is up at gamedev.net. I suggest you have a look at the overall architecture there. I think it'll give you some idea as to what needs to be made. Of course, the diagram he put up wouldn't directly translate to objects mostlikely, you'd have to examine the messages being passed and see what's supposed to become and object and what's not.

Thanks Saem, yes they are nice articles. I've only covered the 1st two but already plan to print them out and collate.

Many thanks

 

[Saem]

You're welcome.

What's funny is that I haven't been able to find a completely/maintained article or set of articles that can compete with that series. It's sad really, but that's the state of affairs.

BTW, 3 and 4 are out.