fundamentally classes are types, just like int and double. Sure they have some differences but the main thing to understand is that they are types. Ever want to make a new type? Now you can. For example I have an angle type. It has only one variable: double value; I gave it all the operators but they make sense for angles. So no matter what you add to an angle you''ll end up with a value between 0 and 2pi. It works just like a real angle. For simplicity I have a constructor that takes a double and a conversion operator that converts to a double. So they can be used in any function that takes a double and they can accept a value from any function that returns one. Is it slower? I doubt it, later I''m going to inline everything and that should get rid of all the overhead. What I get is a nice new value type.

Later you''ll want to make more complex things, like monsters. Treat these guys a little differently, for one thing you''ll want to pass them by pointer. Start thinking in terms of behavior and/or data, depending on the purpose of the class.

Well I''m short on time but here is an important piece of advice: avoid inheritance. Inheritance is great when you need it, but most OO programmers overuse it greatly, because they were taught that way in school.

Oh and don''t focus on reuse. A much beter strategy is to just make the game and then extract the reusable parts from it. Thus reuse evolves naturally and eventually you will be doing a lot of reuse and it won''t have taken you much effort.

"
There is no object oriented design until there is a virtual function and inheritence, consequentially polymorphism.
"

Not sure I would agree with that

I have designed several small OO applications that did not require the use of inheritance, yet they were still quite object-oriented. In some cases the scope of the project makes inheritance an unnecessary burden.

I think a better way of putting it is that there is no OOD without encapsulation

There are also cases when inheritance should be used exclusive of virtual functions. Sometimes you only want to inherit the data

But in the scope of games inheritance/polymorphism is generally a good idea I think.


Seeya
Krippy

I''d say that polymorphism is the key to object oriented programming. Inheritance is used to support it. The problem is that sometimes people use inheritance even when there is no compelling reason for it. Design Patterns agrees with me, somewhere in chapter 1 it says to cut back on inheritance and use variables instead.

Also you have to consider the person asking the question. Reuse is great but if you don''t have experience with OOP you don''t know how to go about it. I think the correct way to learn this stuff is the way I did it: trial and error, including starting over again and again. Then picking up Design Patterns and realizing that you learned half the patterns through trial and error, it will make it a lot easier to understand. Now I do reuse code but the best way to get started is to not focus on reuse. In the C++ programming language Stroustrup says that instead of setting out to make a template you should first make it for the case you are using it in and only after you get it working should you generalize it. Basically there is no point to making reusable code your first time through. As for Quake yeah they should be writing reusable code but newbies should start with the simple goal of getting something to work.