Should I use Object Oriented programming for games?

C Senthil Kumar

I am really confused whether or not to use object oriented programming for game development.

I know that using classes correctly will help keep my code organized but I am confused about the performance.

I have searched the web and I haven't got the exact answer.. not even close.

Some people say, object construction and destruction (among others) is a performance degrader in OO programming (especially when it is repeated many times per frame). OO proponents say that it is not, if OO is used in the 'right way'.

The problem is, I am not sure I know much about that 'Right Way'.

So, can you please help me figure out what's best for my game Should I use classes or not

Thanks!

magicalclick

Trust me, go with OOP. The reason is that you want to optimize on higher level rather than lower level. Like Optimization on sorting, on the archtecture of the game engine, and so on. Object construction and destruction is really quick IMO. And you are not going to construct everything in one frame, they should be constructed dynatimcally and desctruct dymanically, even better, use data streaming to make loading screen a thing of the past. Using OOP, you can concerntrate things like those, not those tiny bit of lower level performance that doesn't effect the overall experience.

It is always the best to optimize things that take the most performance hit, like physics calculation and pixel shaders (especially the particle effects), not those tiny 0.1% of low level optimization.

Stanley1271

You should really go with OO. When your building a game you call the update and draw methods on each frame, but you should not be destroying or creating items until they are needed or need to be destroyed. On the update method you will most likely be just telling sprites and such that they are now at a different position or something to this effect. The draw method you are now drawing these sprites to the device.

So the idea is that you do not really do any real creation or destruction in these methods.

Jim Perry

Have to add my "Go with OOP" recommendation here. It's usually easier for people to think it terms of objects so when you're progrmaming try to imagine the objects and the pieces of it and things it can do. For example - if you're writing a Pong clone you have a couple of objects, paddle, ball, and possibly the playing area. Properties of the ball could be position, size, direction moving, etc. The ball would have similar properties. Methods for the objects could be Move, Draw, CheckCollision, etc.

You'll thank yourself for learn OOP, trust me.

Fluxtah

Make it work, make it right, make it fast is all I want to add :)

C Senthil Kumar

Thanks a lot people!

I was really confused as to which method to take. Now I will definitely take the Object Oriented method.

A few articles on subjects like C vs C++ and OOP vs Not OOP confused me by introducing stuff that I didn't understand.

Anyway, thanks for clearing up my doubt.

magicalclick

BTW, if you are new to OOP, I recommand you to start with C#. C# has lower learning curve. It has automatic memory allocation and deallocation. You don't have to worry about memory leak, or worse, memory lost. C# also has those unsafe pointers (like C++) for trickier approach, and you can use function pointer to shorten your code using this, it is very crazy and tricky, but works like magic. C# is easier to learn than C++, but it is as deep as C++.

HolySmokes

Sadly, you have to use OOP, unfortunately with all of the power of computers, the computer science types have to make things more complicated. That is the best!

You know, I realize that this is the future, we don't get the antigravity cars, etc. but I had hoped that the process of creating meaningful games would have been simplified.

Take a look at Garage Games if you want to do higher level programming. Oh wait, no, even this game system requires that you write some archane OOP to make things work.

If you got to go with a language, it looks like C# is the way to go, Java sucks, and Visual Basic appears to have no respect, although it is the type of language that should be used for game programming, if you can't get a real visual programming tool, like the Microsoft Robotics SDK. The Game programmers like complication, but the robotics community won't put up with it.

So I go along with C# and OOP, but only because of the lack of imagination on the part of the computer science community. The motto of the computer science community: "Make it hard and difficult to the artists and people with real work to do so we can seem important."

But seriously: C# and OOP with XNA, it's the best and it is winning awards! Microsoft is great, the java community and OpenGL REALLY suck. So for now you have to pound keys and have to spend more time on programming then on game story and graphics.

C Senthil Kumar

I have been programming in VC#.net for the past year or so. I know enough about it to write only simple applications.

But C++... I've been programming for more than 7 years (I am 19). Also, I've been using DirectX from version 8 (past 4 years or so).

I asked this really fundamental question because, my school and now my college, thought me how to create objects and use them and polymorphism and inheritance...that too, only the basics of them. The rest of what I know, I learned by trial and error and by reading articles on the internet, and thank god there was MSDN. Though I had been programming for quite some years, I never learned the concepts in a formal way and I couldn't argue about the pros and the cons of OOP or the language itself.

I feel confortable working with native VC++ and using pure DirectX calls even though Managed DX, VC# .net and XNA are neat stuff.

Anyway, thanks for your thoughts!

C Senthil Kumar

Hey, one more thing about OOP... this is much more specific than my previous question.

In my game, I have my own 3D model class say CModel3D and classes for billboards and sprites say... CBillboard and CSprite etc...

Definitely, I have to store the vertex and other data within these classes. But for the rendering, I think there are two options.

1. We could write a Render() function within these classes to make them more reusable with the all the related rendering code within these classes themselves. We just have to give the device to render to as a parameter and the appropriate object would be rendered.

2. Or, we could use one Render() function in the main loop and just use the data from these classes and render them.

Which one is the better approach

Thanks.

BClarenbach

If there are only these two options, I would choose the first one. An object should know how to render itself (through a an Api-Wrapper for added bonus, not accessing e.g. DirectX or OpenGL directly).

You might also consider having render job classes that bundle references to vertex, constant and texture data. These can easily be sorted by material (which makes things fast), abstract direct device manipulation out of your objects (which is good) and generally help keep things clean. Remember to fill those with references, try not to copy the data. Render jobs can also be used for a multi-threading approach. The only problem you will get then is locking of non-static resources (e.g. CPU skinned buffers, particles etc.) which will need clever programming. :)

C Senthil Kumar

I wrote those 2 options because I know only those two options! If there are others, I'd sure like to know.

So, you are saying that using render job classes is good because you get to abstract the device related stuff from the classes where data is stored and also get fast rendering. Did I get you right

If I did, thanks for the advice. If not, please help me with this render job class thing.

BClarenbach

Job classes are good because they
- help abstracting the rendering from the api
- bundle rendering code into a small spot
- help with performance because you can sort jobs by shader/texture, thus reducing state changes.
- set a good foundation for expanding your rendering engine to multi-core/thread architectures

Cons:
- Can take extra time to implement
- May lead to extra allocations during frames ("avoidable" with memory pools)
- threading approach needs good synchronisation for dynamic buffers

C Senthil Kumar

Thanks for clearing up my doubt about job classes. It would be helpful to me in designing my game.