help with object oriented programming

Quote:

For example say i was making a simple top down tank game, I presume that tank would be a class that was derived from a unit class, along with other enemies.

That would be a valid approach, and it's been done that way in many games. I'll mention though that there's been a shift away from inheritance-based systems recently in favor of component-based systems, which in general are more flexible and easily extensible (IMX, at least).

Quote:

In a C game i would generally have a source file for logic and it would have something like for (i=0; i< NUM_OF_UNITS; i++) {move_unit(&enviroment->unit);} , or something along those lines. Is the way to do that in OO to have a class called enviroment with an array of units inside and a function run_logic() that calls units.move_unit() for every unit? as in the whole program would have no functions outside of classes.

That's a fairly reasonable analysis.

In C, it's typical to do things as you describe: you have objects represented as collections of data (e.g. using struct's), and then you pass them by reference (using pointers) to functions that operate on them. In C++, you would typically make the object data private and make the functions that operate on the data member functions of the class/struct. (In fact, the way C++ handles member functions internally mirrors the C way of doing it somewhat, in that the function is implicitly passed an argument - the this pointer - that mirrors the 'object to operate on' argument of the corresponding C function).

Now, this is (necessarily) a drastic simplification of the topic. In reality there are many exceptions to the above, and many different ways to structure a program in C++. For example, it's not necessary in C++ - or even desirable - that all functions be member functions. Also, it's perfectly acceptable to make data public if there's no need for it to be private.

You'll discover all of these things as you proceed, but as far as making the initial transition from a strictly procedural approach to a multi-paradigm approach, it sounds like you're on the right track (IMO).

Thanks that clears some things up; I was a little worried that I did anything remotely procedual style then C++ wouldn't write the code for me/solve world hunger like I have been promised it would.

Quote:

Original post by jyk Quote: For example say i was making a simple top down tank game, I presume that tank would be a class that was derived from a unit class, along with other enemies. That would be a valid approach, and it's been done that way in many games. I'll mention though that there's been a shift away from inheritance-based systems recently in favor of component-based systems, which in general are more flexible and easily extensible (IMX, at least

I've found myself starting to avoid inheritance for entity types (bigtank is a type of tank is a type of unit is a type of gameentity), but using it for value types (a name is a type of string).

Inheritance for entities almost always seems like one of those things that just ends up causing pain in the end. Instead, I'd go with a more interface-based approach personally.

Of course, I've taken some weird turns in my coding style in the past year or two, so a lot of what I'd suggest wouldn't be common idiom. It does seem to match up with a lot of advice given by some of the "gurus", though...