On the plusses and minues of Object Oriented Programming in game development... I really like an object oriented approach to programming. I like the maintainability of a large code base that follows a strong OO approach. Want to make a change? It is easy to change an underlying implementation detail as long as you keep the same interface. Now, that module could be accessed thousands of times by pieces of your code, but it would be non the wiser to the change, as long as the interface remained constant. I am using Java in my current project for a variety of reasons, not the least of which is related to Java forcing an OO approach on its users. And yes, I know that all of this can be acomplished in other languages, like C++, the only langauge any game programmer wouled ever use, blah blah blah! I am using Java for other reasons as well! !!!THIS IS NOT A JAVA SUCKS/KICKS ASS THREAD!!! However, sometimes an OOP approach can be taken a little overboard. While it is a good idea conceptually, it does have the easily reached possibility of being over designed. So where does OOP fall in game development? I plan on using it extensively. I find it easiy to read and follow. Just make a quick diagram of how things relate and it can be followed like a map. But we need speed, speed, speed, and is that readability worth an extra function call? I don''t really know the downsides (specifically speed related) of this approach, so since I am already sold on it, maybe some people can give reasonable reasons to refrain from using a solid OO structure...or heaven forbid, maybe someone can agree with me and further elaborate. --OctDev

The book 3D Game Engine Design takes an entirely OO approach to developing an engine. Nowadays, except for a small minority, developers seem to be using OO design in their projects. Just look at Half-Life, the Unreal engine, the NetImmerse engine, LithTech, etc. They''re all OO, even their scripting languages are OO.

The more I learn about OO (and I mean the nitty gritty details of code that freak you out when you first see them), the more I like it. It can be very, very powerful.

However, I''m not so sure there''s such a thing as overuse of OO. If it looks like someone is overdoing it, then there''s a 99% chance that they are misusing it. There are various ways to use OO of course, but there''s also right ways and wrong ways, and I''ve seen some pretty nasty wrong ways (from myself included) that looked like overuse. Just something to think about..

Kevin

System.out.print as opposed to std::cout as an example of overly OO

I think it''s well-neigh impossible to over design.
The problem lies in over-engineering a solution. It''s not particular to OOP, but you''re probably more likely to over- rather than under-engineer a design using OOP. Designed capibilities/features take time to implement, and more time to support.

The minus is that the only people who will want to use and understand your code are other people who understand OOP.

The current state-of-the-art OOPing has progressed quite a ways in the last 5 years. Read up on Design Patterns and Refactoring for more info.

Magmai Kai Holmlor
- The disgruntled & disillusioned

Well, as far as overuse of OOP...my best example of this is somewhat specific with a recent compiler class that I had. We had all of our symbol objects designed as classes in a big huge inheritance tree, and sometimes you had to go through some crazy function calls to get the type of the object that you were using, as instructed. Sometimes, it was much easier just to use java''s instanceof call. But that was described as horrible programming by our second professor. Our first prof said it was a good and real world solution, but the second was the software engineering expert. Never the less, we did use instanceof iin quite a few places as it seemed a cleaner and better solution from the perspectives of myself and my partner. So, I think that occasionally OO can be overly used.

BUT....I am not at all arguing against OOP, as it is gggrrrreeeaaatttt! I am still wondering if anyone knows if these embedded function calls are significantly more costly in terms of speed...that is my only concern with very large and extensive OO models.

Gone are the days when us graphics coders have to squeeze everything possible from every single clock cycle. Doing a dereference before calling a function is nothing drastic, and there''s no way you''d ever notice the effects unless you''re calling the function a million times a frame.

People who claim that OO languages are inherently slow, don''t know how to write OO programs. Simple as that.

---

War Worlds - A 3D Real-Time Strategy game in development.

If you have to go through ''crazy function calls'' to figure out what kind of object you''re dealing with, then you missed the entire purpose of OOD, a-mon-avis. A primary objective when abstracting A system in an object-oriented fashion is so that you don''t care what kind of object you''re actually dealing with. If you need to know what kind of object something is, then you''ve missed the polymorphic capibilites of a OOD. I''ll give you that it''s sometimes just easier to do a switch off the typeid (instanceof in java), but it means the design failed to account for whatever is happening in that switch. The problem compounds itself when you decide you need a new subclass; now you have to hunt down all the instanceof''s and make sure the right thing happens for the new subclass (I know I always seem to miss one when hunting for things like that).
So in your case, it''s an OO explotation that you can use; but overly using instanceof is a misuse of OOP.

The huge tree of inheritence seems to be a side effect of ''signle inheritence only'' systems. The COM tree is very broad whereas MFC, VCL (or CLX), and/or Java inheritence trees are deep (yes MFC is C++ code, but it makes little use of MI).

In a recent flaming thread, Stoffel showed that a this call takes the same number of ops as a cdecl that did the same thing. The only possible issue is when a virtual call is made, I''m not entirely familar with Java so I don''t know the corresponding terminology for it. And the real issue with virtual calls is that a different function can be executed each time it''s called (the extra time from the lookup is not an issue). If you are looping and calling a virtual method in the loop then there is more potential for additional page faults than for a non-virtual call. Again it probably doesn''t matter

...

quote:

---

System.out.print as opposed to std::cout as an example of overly OO

---

Nested namespaces are too much OOP? Would you like a file system that only allowed one level of sub-directories? C+++ is hurting for a ''with'' clause, I''ll give you that.

I agree that abstracting the system and not concerning yourself with the object type is one of the primary purposes of OOP. However, as for the case that I presented (attempted), at some point you need to deal with a specific object. Elaboration: So, in writing our compiler, we passed objects up and down our grammar and throughout our project, and manipulated them most of the time with a parent (or grandparent, etc) class. However, at some point you have to check and see exactly what that object is. Example: is it a variable or a constant? If it is a constant, you can do a whole lot more with it at compile time (i.e., constant folding, size declarations, etc). But if it is a variable you cannot do very many compile time calcualtions--it becomes a runtime calculation. While parsing through the input code, most constants and variables are used in a like manner, and were passed around by a constvar superclass. But when you have something like:

//pseudo
const a = 4;
var b;

b = a;

array{5} c;
array{a} d;
array{b} e; //ERROR

you can put in a constant as a size for declaring an array size, but not a variable. That is a language spec (specifically for this project). So if these had been passed around by the ultimate super class, to perform this check, I would at some point have to get the type of this object. There is no way around that, if it has been passed around in an abstract form (as we both agree that it should be for OOP). So now it is just easier to do an instanceof (in Java). At least it seems like it is to me; it is prewritten and does not require more functions to be written and called, and since it is a part of the language, you always know that it is there so its just easier to use (especially when you are seperated from the code for a while and don't want to look up all the function names that you wrote!). Agreeing (I think) with what you mentioned, I don't think any type of speed issue is present either; I think it is just a matter of style. So it is not the premier elegant OO solution; however, in this case I think that premier OO solution qualifies as overkill and not making use of langauge features (granted, I am talking about Java, because that's all I'm really good at anymore without a reference book sitting next to me).

Anyway, I have enjoyed this little thread and look forward to your response (I'm curious if you think I'm totally wrong...plus I had this same discussion with my lab partner about 3 months ago, so it is an interesting rehash, especially since originally I was undecided on the issue ).

--OctDev

all these edits are because some brackets I used in the pseudo code earlier caused it to try and put in some HTML... hope this fixes it ok.

Edited by - OctDev on July 6, 2001 6:54:20 PM

Well the DP interpreter uses classes for each grammer rule to build an abstract syntax tree; each grammer rule object has an Interpret() method that compiles the code. However, it''s fairly involved and not ideal for efficent compilation, but it would be an OO method that doesn''t require any RTTI.

OO stuff is useful and I can''t imagine writing a great program without it. Non OO stuff is useful and I can''t imagine writing a great program without it. I think that some people get too wrapped up in devotion to one paradigm or another and forget that all paradigms (well all the ones we hear about, I''m sure there are some bad ones) have their place. Learn them all.