I was scared to jump into object oriented programming, and avoided it for months when I first began programming. But once I began programming in an OO way, I never wanted to go back to the old days of declaring variables and functions outside of classes.
I guess my questions are:
-Is this average?
-Are there any modern games, that aren't programmed in an OO way?
Once you go OO, you never go back?
I was scared to jump into object oriented programming, and avoided it for months when I first began programming. But once I began programming in an OO way, I never wanted to go back to the old days of declaring variables and functions outside of classes.
I guess my questions are:
-Is this average?
-Are there any modern games, that aren't programmed in an OO way?
When someone "gets" OOP, it's somewhat of an eye opener and what you experience is probably typical. It's a great tool, but don't be fooled into thinking it's the ONLY tool. There will be plenty of times when the correct tool will be a non-class function and variables.
As for any "modern" games programmed in non OO? I'd guess probably not, but not too long ago, (late 90's, early 00's) many big games were done in pure C.
I have no statistics so I'll make unsubstantiated sweeping generalizations instead 
Most places outside of games DEFINITELY do OOP, whether or not they understand why they are using it and its advantages and disadvantages. Most game studios/engines I'm aware of also do OOP. I've seen a very small shift away from OOP in favor of thinking in terms of data transformations.
In my opinion OOP is very often a good choice. But unfortunately it seems like this is the way *everyone* learns how to program and don't understand the pros/cons of that style. "This is the way thou shalt make software."
You benefit from OOP by easy data hiding/encapsulation, and if we mean OOP as in common language features, ability to use polymorphic functions and type safety/inheritance. It's also a well-understood style by the person coming behind you.
A bad side of OOP is that few people succeed in only having a single concern per each object type and so what often happens is you get large classes that throw a bunch of unrelated functionality together with its data, and it makes it very difficult to extract a single aspect of the class out for reuse. You end up creating generalized objects that are more complex than necessary to solve a problem. OOP is also a trap for people to make code that attempts to model the real world (i.e. your objects are "chair" or "car" when maybe the better solution would be SitableComponent or DrivableComponent that's attached to something more general). It's difficult to have the discipline to break down a seemingly simple object into the various concerns it has, but failing to do so makes bad OOP designs.
One alternative might be a data transformations style, where you have lots of homogeneous data and you simply rip through it all using loose functions. Even with such a style, you can think in terms of OOP and limit how/when/where you access data in those lists. And yet you can keep data and logic separated. In other words, you can get the advantages of OOP without using the class keyword.
I think OOP is so prevalent because it's almost always a decent solution and it's very intuitive. So for big companies that just want to grow a workforce of moderately skilled people who can make standard business software without needing to have the depth of understanding to choose what style to use, OOP is a good choice.
I think the most important thing is realize that you can get the benefits of OOP without using the class keyword, while skirting the negative aspects of it by either being careful to keep your objects single-minded or thinking in a more raw form of data transformations in sequence. Consider many solutions/styles and *think* about the tradeoffs you make with your choice.
Most places outside of games DEFINITELY do OOP, whether or not they understand why they are using it and its advantages and disadvantages. Most game studios/engines I'm aware of also do OOP. I've seen a very small shift away from OOP in favor of thinking in terms of data transformations.
In my opinion OOP is very often a good choice. But unfortunately it seems like this is the way *everyone* learns how to program and don't understand the pros/cons of that style. "This is the way thou shalt make software."
You benefit from OOP by easy data hiding/encapsulation, and if we mean OOP as in common language features, ability to use polymorphic functions and type safety/inheritance. It's also a well-understood style by the person coming behind you.
A bad side of OOP is that few people succeed in only having a single concern per each object type and so what often happens is you get large classes that throw a bunch of unrelated functionality together with its data, and it makes it very difficult to extract a single aspect of the class out for reuse. You end up creating generalized objects that are more complex than necessary to solve a problem. OOP is also a trap for people to make code that attempts to model the real world (i.e. your objects are "chair" or "car" when maybe the better solution would be SitableComponent or DrivableComponent that's attached to something more general). It's difficult to have the discipline to break down a seemingly simple object into the various concerns it has, but failing to do so makes bad OOP designs.
One alternative might be a data transformations style, where you have lots of homogeneous data and you simply rip through it all using loose functions. Even with such a style, you can think in terms of OOP and limit how/when/where you access data in those lists. And yet you can keep data and logic separated. In other words, you can get the advantages of OOP without using the class keyword.
I think OOP is so prevalent because it's almost always a decent solution and it's very intuitive. So for big companies that just want to grow a workforce of moderately skilled people who can make standard business software without needing to have the depth of understanding to choose what style to use, OOP is a good choice.
I think the most important thing is realize that you can get the benefits of OOP without using the class keyword, while skirting the negative aspects of it by either being careful to keep your objects single-minded or thinking in a more raw form of data transformations in sequence. Consider many solutions/styles and *think* about the tradeoffs you make with your choice.
Actually a "new" paradigm is getting increasingly popular called Data Oriented Design: http://gamesfromwithin.com/data-oriented-design
For example, Bitsquid engine uses it: http://bitsquid.blogspot.pt/2010/05/practical-examples-in-data-oriented.html
I've been rewriting some parts of my engine to a more data oriented approach instead of object oriented, and once you start thinking data oriented you'll see a lot that a lot of your object-oriented code could probably run faster if it was data-oriented.
In my opinion, after starting to write OO code, most people fail to write code that takes advantage of the memory cache effectively...
For example, Bitsquid engine uses it: http://bitsquid.blogspot.pt/2010/05/practical-examples-in-data-oriented.html
I've been rewriting some parts of my engine to a more data oriented approach instead of object oriented, and once you start thinking data oriented you'll see a lot that a lot of your object-oriented code could probably run faster if it was data-oriented.
In my opinion, after starting to write OO code, most people fail to write code that takes advantage of the memory cache effectively...
In some situations, you will want to go back to non-OO for performance reasons. Usually OO is just fine and the overhead (if any) is neglegible. However, in some situations, it can cause adverse effects to processor caches (read up AoS versus SoA), and some OO constructs can sometimes cause significant overhead.
Virtual function calls are an example of a feature that usually doesn't matter at all, but can matter a lot in some situations. In the normal case, you pay a dozen cycles extra for the call in the worst case, mostly because the call cannot be inlined. In the average case, it's often rather something like 3-4 cycles. Burning 3 cycles a hundred times is exactly nothing for a modern CPU.
Now, in the worst case, you do a million calls per frame and the object type varies almost every time, and there are a few types to choose from, so you pay for a data cache miss, a branch misprediction, and an instruction cache miss. Multiplied by a million.
EDIT: Found what I was looking for, there is a good summary on the pitfalls of OO: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
I remember there being another one (if I could find it now... I think it was on Gamasutra or something from GDC) which was much more radical, entirely condemning OO for performance reasons. That's a bit too harsh in my opinion. OO Performance can become a problem, but not if you are a bit savy.
Virtual function calls are an example of a feature that usually doesn't matter at all, but can matter a lot in some situations. In the normal case, you pay a dozen cycles extra for the call in the worst case, mostly because the call cannot be inlined. In the average case, it's often rather something like 3-4 cycles. Burning 3 cycles a hundred times is exactly nothing for a modern CPU.
Now, in the worst case, you do a million calls per frame and the object type varies almost every time, and there are a few types to choose from, so you pay for a data cache miss, a branch misprediction, and an instruction cache miss. Multiplied by a million.
EDIT: Found what I was looking for, there is a good summary on the pitfalls of OO: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
I remember there being another one (if I could find it now... I think it was on Gamasutra or something from GDC) which was much more radical, entirely condemning OO for performance reasons. That's a bit too harsh in my opinion. OO Performance can become a problem, but not if you are a bit savy.
As was mentioned - remember it's one of many tools, and tools, while they can be typically used for just about anything, are usually specialized for certain things. (I could go cut a board in half with a screwdriver, given enough time, but better to use the saw for that and use the screwdriver for what it's meant for.)
OOP tends to be a good fit for self-contained black-boxes that don't (usually) know about the inner workings of each other. This allows them to be highly reusable for many situations. A fantastic example is a GUI system.
Procedural programming tends to shine when it comes to algorithms and complicated ... procedures. Take code for reading/writing JPEGs for instance. I've seen this done with minor use of OOP (by Intel, in fact) and it was very awkward. I've also seen it done fully procedurally, and it is just easier to follow.
Data Oriented Design is another way of thinking that is getting a lot more attention lately (it is nothing new though). This has more to do with layout and memory structure being the first thing on your mind, and so can then be wrapped up in whatever little package you want, whether it is using OOP idiom, PP idiom, or something else.
(Note that just because you use SoA does not mean it isn't wrapped up in a nice neat little object)
There's also functional programming, stack based programming, event based programming, etc... but most of all you will find what works best and what doesn't - and more importantly why, as you get more experience. So even if you just keep doing what you're doing, and pure OOP comes back and bites you hard, it's good - that's how you must usually learn!
OOP tends to be a good fit for self-contained black-boxes that don't (usually) know about the inner workings of each other. This allows them to be highly reusable for many situations. A fantastic example is a GUI system.
Procedural programming tends to shine when it comes to algorithms and complicated ... procedures. Take code for reading/writing JPEGs for instance. I've seen this done with minor use of OOP (by Intel, in fact) and it was very awkward. I've also seen it done fully procedurally, and it is just easier to follow.
Data Oriented Design is another way of thinking that is getting a lot more attention lately (it is nothing new though). This has more to do with layout and memory structure being the first thing on your mind, and so can then be wrapped up in whatever little package you want, whether it is using OOP idiom, PP idiom, or something else.
(Note that just because you use SoA does not mean it isn't wrapped up in a nice neat little object)
There's also functional programming, stack based programming, event based programming, etc... but most of all you will find what works best and what doesn't - and more importantly why, as you get more experience. So even if you just keep doing what you're doing, and pure OOP comes back and bites you hard, it's good - that's how you must usually learn!
After you understand OO, you should try functional programming too. Not all languages support it properly, but you can usually manage, even with Java. Learning functional programming will help make your code more maintainable and bug free, even if you use OO. The best part is that you can mix and match OO and FP(though some people think OO and FP are mortal enemies. IMO they are wrong)
Well I started in python (without using its OOP features particular), then VB.net and C# which are of course OOP (and I do use OOP for my computer science coursework) but outside of school I've been playing with a little bit of plain C so I have sort of gone into OOP and then out of it again. C is for an embedded device btw, anything I develop for actual usage would normally be C# although I might consider C++ one day.
After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?
But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer.
A recent example that I can think of is the IW engine (used in every single major Call of Duty title). It's based directly on the Quake 3 source, so I can imagine it's probably in C still.
But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer.
A recent example that I can think of is the IW engine (used in every single major Call of Duty title). It's based directly on the Quake 3 source, so I can imagine it's probably in C still.
whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?
You wouldn't, that would be dumb and you'd deserve to be shot out of a cannon into the sun.
What you might want however is a function which does the same logical job but can support multiple function signatures for the parameters; at which point its not so dumb.
This also has nothing todo with OOP.. but then again most comments about OOP both in this thread and beyond generally have very little todo with it (at best they focus on an implementation detail of language X) too so.. ya know.. whatever.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
