Is OOP better for developing games?

better than?

Better than functions?

There are many programming paradigms, and OO is only one of them. What do you want us to compare it to? Functional programming? Declarative languages?

It's like asking "is a bike a better means of transportation?". Even if you provided something for us to compare it to, like a car, you might find that even though the car usually wins, in some cases the bike is still preferable.

EDIT: Functions as in procedural programming, or functional programming?

There's no point in discussing "which paradigm is better" without a very specific context. Functional programming will in some cases solve problems much more efficiently, while other problems are best tackled with an object-oriented or procedural approach.

This is entirely subjective.

This question is quite similar to asking if Ford is better than Chevrolet. The truth is that while both have their strengths and weaknesses, but both will get you to your destination equally well. That still doesn't stop people from arguing and fighting over Fords and Chevys.

If you are working for a company, do what they require (probably C++). If this is just a hobby for you, go with what you find to be the easiest and most intuitive. For me, that is plain, vanilla C. I'm learning C++, but I will always prefer C. I can do exactly the same thing in both languages, but I find C to be much easier, more intuitive and far less obfuscated.

@MarkS: When you have a collection of objects that are almost of the same type but need a little bit of specialized behavior, what technique do you use to specialize that behavior? In OOP land the usual approach would be creating an interface for whatever you are going to iterate over, then deriving from that and overriding where you need to create specialized behavior.

I would personally think that without an OO aproach, GUI objects can start becoming a bit weird and unnecessarily convoluted. On the other hand, when things start to be counted in the thousands (particles for example) in physics simulations, I've found myself often wandering away from OO approach that usually deals with behavior specification without regard to the amounts of objects existing. For example, instead of making the CPU handle vtable traversals for a thousand object, a non OO approach would find itself naturally optimizing away the overhead [I got the example from the impression of a featured article here on GDNet].

In my personal and very limited opinion, OO within the games realm can often be just a syntactic sugar over a strictly procedural approach (as in you could have just replaced that object call with a function call with a this pointer attached to it). I don't think of that as bad however and I hope others with more relevant experience can correct me.

Hope it helps.

Quote:

Original post by arithma @MarkS: When you have a collection of objects that are almost of the same type but need a little bit of specialized behavior, what technique do you use to specialize that behavior? In OOP land the usual approach would be creating an interface for whatever you are going to iterate over, then deriving from that and overriding where you need to create specialized behavior.

Like what, for example? I cannot think of anything off the top of my head to give a reply.

Quote:

Original post by arithma When you have a collection of objects that are almost of the same type but need a little bit of specialized behavior, what technique do you use to specialize that behavior? In OOP land the usual approach would be creating an interface for whatever you are going to iterate over, then deriving from that and overriding where you need to create specialized behavior.

Delegates/closures/callbacks and conditional branching over data.
So in C that's function pointers, for example rather than an OO Comparator interface you just supply a pointer to a comparator function, see qsort. Either way it's the same principle of late binding realised differently by different languages.

What I have found myself doing is integrating bits of C++ into my C code over the years. For instance, rather than inlining an entire function in multiple places, I use the inline function operator. However, I still find it hard to agree that classes are better than structures. I've heard both sides, but I find the C method easier to code, and for me, to understand.

There are useful points in C++ to be sure, but in my own personal experience, I just find that I like C better. This is purely subjective, but it is my opinion based on my own experience.

I could probably make a case for OOP better than functional as having done a lot of both I certainly prefer OOP methods as it feels more natural in most places that games go - lists of similar units in a tank game, similar sprites in 2D etc.

But, and this is by far the most important point imo:

Program whatever way you feel is more natural and productive. Syntax issues really shouldn't be a major factor when programming a game, so just don't sweat it.

Quote:

Original post by MarkS I'm learning C++, but I will always prefer C. I can do exactly the same thing in both languages, but I find C to be much easier, more intuitive and far less obfuscated.

That's because, as you said, you're still learning C++. In the beginning, C++ tends to look very unintuitive to programmers used to C, since they typically find it hard to jump over the "C with classes" barrier. This will change once you gain more experience, not only with the language, but also with the whole concept of OOP. Your question about whether structs or classes are better (apart from small semantic differences, they're the same in C++) shows that you are still in the realm of "C+", missing the final, yet most important part.

Maybe you should look into a different OO language, such as C# or even Java. They're farther away from C, and might make it easier for you to understand the real benefits of OOP.

Quote:

Original post by MarkS For instance, rather than inlining an entire function in multiple places, I use the inline function operator.

Note that the inline keyword is mostly ignored by modern compilers.

Quote:

Original post by Yann L Maybe you should look into a different OO language, such as C# or even Java. They're farther away from C, and might make it easier for you to understand the real benefits of OOP.

No, I want to stick with C/C++. Java doesn't have much use outside of the internet (some, yes, but not much) and I refuse to touch C# on principle. *Maybe* when it becomes standardized, but not right now. I am not a fan of interpreted languages, even when a VM is being used.

Quote:

Original post by Yann L Note that the inline keyword is mostly ignored by modern compilers.

Well that sucks! Good to know though.

Erm, C# IS an ECMA standard and has been for some time. Nor is it 'interpreted' but JIT compiled.

As for 'inline', it still provides a 'hint' to the compiler however generally the compiler can make a better call than you as to when it should inline; this means that a function might be inlined in some places and not in others as the compiler sees fit.

Quote:

Original post by MarkS No, I want to stick with C/C++. Java doesn't have much use outside of the internet (some, yes, but not much) and I refuse to touch C# on principle. *Maybe* when it becomes standardized, but not right now. I am not a fan of interpreted languages, even when a VM is being used.

the moral is... Mafioso, use OOP or you might end up like this guy here.

Quote:

Original post by MarkS No, I want to stick with C/C++.

Have fun with that, but please at least be aware that every single point you're using to justify doing so is factually incorrect.

Quote:

Java doesn't have much use outside of the internet (some, yes, but not much)

In reality, Java is used all over the place - from gigantic enterprise business systems to casual games for cell phones. I hope you're not perhaps confusing it with &#106avascript, which <b>has nothing to do with Java except the name</b>.<br/><br/><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE-->and I refuse to touch C# on principle. *Maybe* when it becomes standardized,<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE--><br/><br/>In reality, C# has been standardized for a long time.<br/><br/><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE-->but not right now. I am not a fan of interpreted languages, even when a VM is being used.<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE--><br/><br/>In reality, neither Java nor C# is "an interpreted language" by classical definitions - not only do they "use a VM", but the byte-codes for that VM persist (which is not the case for, say, Perl), and in-memory code is optimized on the fly - something that is actually not really feasible with a statically compiled language like C++.<br/><br/>Further, there is a meaningful sense in which compiled C++ executables "use a VM". It just isn't a particularly safe or well-defined one.<br/><br/><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE--><!--QUOTE--><blockquote><span class="smallfont">Quote:</span><table border="0" cellpadding="4" cellspacing="0" width="95%"><tr><td class="quote"><!--/QUOTE--><!--STARTQUOTE--><i>Original post by Yann L</i><br/>Note that the inline keyword is mostly ignored by modern compilers.<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE--><br/><br/>Well that sucks! Good to know though.<!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE--><br/><br/>No, it doesn't suck at all. It means that the compiler is making decisions about what to inline, rather than you. Hint: it probably does this better than you, because it behaves consistently whenever it makes this decision. Also, it gets to make this decision on a per-call basis rather than a per-function basis, which you can't do with the 'inline' keyword.<br/><br/>Modern compilers also mostly ignore the 'register' keyword. This doesn't suck either.

MarkS, are you self taught? Self taught C was my first real programming language and I had a thought process like you for a very long time. I did every thing in C because I always thought it was better and easier to understand. The real problem is I just didn't understand how C++ worked so I didn't use it. It wasn't until college where I had to deal with Java and C++ that it really clicked for me. I haven't used C in several years now.

As for Java use, outside of games Java is one of the most widely used languages out there.

Quote:

Original post by Zahlman Quote: Quote: Original post by Yann L Note that the inline keyword is mostly ignored by modern compilers. Well that sucks! Good to know though.

This isn't quite true. Most compilers have 3 options to consider inlining candidates: no inlining, functions marked inline, all functions. As a practical matter I haven't found a reason not to pick the last one, in which case the inline keyword does almost nothing.

C++ does assign one practical meaning to inline, relating to function implementations in header files. By declaring a function inline, you can avoid multiple definition errors in the link step.

I guess they should call it an inLIE func cause they tell you it's going to do all these things that it doesn't.

From another perspective, C is just so much more fun for some people than C++. I've not done any programming to pay the bills in a while. When I did, it was largely via Java. But for my own for-giggles projects, I often use straight C. Like I said, it's just fun for me. I particularly enjoy implementing certain algorithms or data structures that are usually already available in, for example, the STL or the Java standard library. Maybe I'm just masochistic (people who were still using assembly for fun a decade ago said the same thing -- anyone still mucking around with that?).

But when a project isn't strictly for fun and I need to be productive, I usually reach for a language that has built-in OOP support. And because productivity is a key goal, that language is almost never C++.

Quote:

Original post by MarkS No, I want to stick with C/C++.

I guess that is exactly the problem. You shouldn't use "C/C++" when you want to learn C++, as you shouldn't use "C/C++" when you want to learn C. Learn either C++, or C, but don't mix them up for starters. Both have very, very different paradigms.

Quote:

mrchrismnh I guess they should call it an inLIE func cause they tell you it's going to do all these things that it doesn't.

On the other hand, there's inline linkage. Further: Virtually all programmers are less capable then the compiler to decide whether it is better to inline or not. It is not the 80s anymore, both w.r.t. compiler technology and CPU technology.