How object oriented are you?

I'm realizing that I don't really write deep object oriented code much. I basically use C++ using the same functionality as C, i use classes as structs basically, keep everything public.

I use C++ 'cause I get to use the friendlier syntax object.dothis() instead of objectdothis(object), operator overloading for 3d math and the STL.

If make 2 or 3 similar classes it's not a big deal, to abstract them seems overkill.

I get the feeling you really need object oriented if you are writing a well thought out library easy for others to use, but for applications I dont feel there's much need for encapsualtion polymorphism etc.

Also I really don't see why iI use object.setx(3) instead of object.x=3, heck my classes are pretty obvious, I just want my object's x to be 3, why do i need to write a function for that...

My current game is being written with a pseudo-object-oriented system in C.

I like some things about object orientation, but I don't subscribe to the religion some programmers have about it. Like anything else in the programming world, there are times to use it and times not to. You just have to know when to apply it as a solution to your current problem and when to write the code another way.

I find OOP is well-suited to GUI stuff, but for games it's just overkill, unless you're making something on the scope of Grand Theft Auto, IMHO. 100% of my coding was Objective-C before iPhone came along. Now I hardly have any OOP code except for asset loading and state saving and OS API calls. 90% of it is bare-bones C, using static arrays. I'm not even using dynamic memory allocation at all for my scene objects (i.e. no linked lists). Everything is pre-allocated once and referenced by index. Coming all the way from one extreme of OOP to static arrays in C has massively simplified the process of getting stuff done. I'm not suggesting I've sworn off OOP at all, but I will say I have a renewed respect for good ol' C.

I'm obsessively object oriented, and my entire code base relies on it. The vast majority of my code is in one hierarchy, which extends to contain in-game objects, UI elements, and other data structures. Any new classes need to be incorporated into this hierarchy, or else I redesign them so they can.

Najdorf Wrote:I get the feeling you really need object oriented if you are writing a well thought out library easy for others to use, but for applications I dont feel there's much need for encapsualtion polymorphism etc.

It comes down to what you're comfortable working with. Personally, I've found polymorphism to be incredibly useful and I use it whenever I can. It allows me to very rapidly create new types of in-game objects that immediately fit into my engine and behave like everything else.

Najdorf Wrote:Also I really don't see why iI use object.setx(3) instead of object.x=3, heck my classes are pretty obvious, I just want my object's x to be 3, why do i need to write a function for that...

I've run into situations where setting a member variable requires other things to happen. For instance, now that object.x is now 3, object.otherobject.x needs to also be 3. I do, however, also find writing accessors for everything to be a pain in the ass, and I will use a public variable whenever I can. Worst case, I can always put an accessor on top of it if I need to later on.

I'm pretty obsessively object oriented, but I do fine in non-object oriented languages too. Chipmunk was written in C, but with a lightweight semi-OO style.

Why object.setX(value) instead of just object.x = value? That is one of the basic motivating forces behind OOP. Say you need to recalculate some other value when you change x, and say you didn't realize that you would need to do so until after writing a bunch of code using object.x = value. Now you have to go and change all the places where you set value directly and make it recalculate stuff. Even worse, what if 1000 people also have code written against your library?

Some languages make statements like object.x = value into a method call implicitly. Ruby changes such a statement to object.x=(value), "x=" is actually the name of a method with one parameter. Obj-C 2.0 has something similar, and both let you define trivial getters/setters without typing out methods for each of them. That way, if you change your mind later about what the setter does, you don't have to change any of your code other than changing the getter/setter definition.

I use OO for most stuff, but I try to be flexible and use other paradigms where it makes sense to do so.

AnotherJake Wrote:I find OOP is well-suited to GUI stuff, but for games it's just overkill, unless you're making something on the scope of Grand Theft Auto, IMHO.

If you want to have a scene graph system, then the best way is through OO and polymorphism. It also makes many other things easier to use. Have a bunch of different kinds of objects that you want to be updated every frame? Have them all inherit from an interface and loop over them. Overall, it can make everything a lot more general purpose and easier to expand upon later.

That said, it's also important to know when not to use polymorphism. For example, if you have a vector object, you don't really want that to have a virtual function table. If it does, then suddenly you have an extra 4 bytes (or 8 on a 64 bit system) for each vector, and if you have an array for things such as a vertex list, then it's not going to be equivalent with a float array. (it's still good to have a non-polymorphic class, though, to encapsulate the functionality for your vector)

Everything I do is OO. I don't really like inheritance though, so I try to always use composition where available. I really like the model Unity uses where you attach components to game objects and then pass messages to those, so we've mimicked that at work (not that Unity is the only implementation of that).
That and/or a singal/slot messaging passing system seems to be what I like to use. I do use inheritance where it's appropriate though, but never multiple-inheritance.

akb825 Wrote:If you want to have a scene graph system, then the best way is through OO and polymorphism.

That's true, and I can't argue against it because I've taken the OOP approach to the scene graph myself, and indeed there are many advantages to be had. But like I said, I recently went from OO to !OO and I'm loving it. It's some of the most fun I've ever had programming. I break all the rules whenever I want, with zero regard for design patterns, and I cannot believe how easily things have come together. All I'm doing is following the path of least resistance to problem solving -- brute-force if you will. I have globals and enums and static arrays all over the place. To a trained OOP programmer it would look like the ultimate hell, but it's incredibly easy for me to work with. There is one caveat: I do have to pound out a lot more code than if it were OO, I'm not going to lie about that. Polymorphism would be helpful in that respect, no doubt, but I can't honestly say I need it.

Personally when I'm writing a game I know where I'm starting from but I don't really know where I'm going. This comes from the fact that it's hard to rationalize and predict the fun factor, and many times you have to try it to see if it's fun or not.

I think OO programming requires you to have a more solid understanding of what the full program will be, or you might end up rewriting your architecture many times and lose a lot of time.

Najdorf Wrote:I think OO programming requires you to have a more solid understanding of what the full program will be, or you might end up rewriting your architecture many times and lose a lot of time.

I'd have to disagree here- having a whole class hierarchy to tie into means I can experiment with things very quickly, with very little wasted code. One example is I have a base GameObject class that has everything any healthy game object needs: position, velocity, angular velocity, that sort of thing, plus a few extras, like a sprite, a bounding volume, and a list of behaviors.

If I wanted to experiment with a new type of enemy, it will automatically have a sprite, bounding volume, and everything necessary for physics and collision detection, and all the logic that those require. And say I need this thing to occasionally shoot at the player, I have a behavior for that- I just add it. If this new object ends up being not fun, I have lost very little in the way of code, and the time required to piece these things together is minimal.

And even the creation of the engine itself was pretty spontaneous. I never really planned on the behaviors, for instance, it was just something I thought would be cool to have one day.

Really, all it comes down to is what jives with your personal style of coding. I guarantee no one is going to be convinced to code in a different way because of this thread. Some people like to think procedurally. I've tried it and it works for me to a point, after which there's so much code in the same place it drives me crazy. I personally love having managers and factories and having things be as automated as possible, and I can visualize my code better when it's spread out over many objects with specific purposes.

I like writing accessor and mutator methods because I can stick asserts all over the place inside of them, and save myself quite a bit of time not trackng down simple errors. I especially love checking for NULL pointers, since my programs seem to die quite a bit from my forgetting to properly initialize things '-_-