🔒 Locked

Object oriented programming OR Procedural in game development...wat do you think?

Started by Dark Star Jul 16, 2005 at 9:28 AM 71 replies 20.4k views

Original Post

Jul 16, 2005 at 9:28 AM

Hi Gamedev community... I just wanted to know everyone's opinion. Im about to embark on a new game. Its a baku baku type multiplayer game, to be played over the net. I was wandering if people take an object-oriented approach to game development, i.e. using objects to represent everything, or do you program procedurally or mix in OOP. Up to now Ive always used C++ to code my games but my programming style is straight forward procedural. I only ever use classes to represent things like menus and windows, you know, things that lend themselves to being objectified. And all objects have their own methods. But I use structs with public fields to just group common data. So I tend to mix and match both, but with procedural coding being the dominant. How are your games programmed OO or procedural? And what benefits do you find from each. BTW this is not a post to incite "My style is better than yours" type thing, I just wanna know how people do it and why and their own benefits. Thanks. DarkStar UK

snk_kid

132

snk_kid

Jul 16, 2005 at 9:59 AM

I just don't get this view people have of OOP & procedural as being mutually exclusive because it is typically not the case.

Imperative languages such as C++ that supports OO concepts natively in the language your still programming procedurally with those objects, the only difference is now you have native support for proper user-defined types be it non/polymorphic, parametric, or what ever kind of type. At the end of the day this is the important thing.

I have to say OO is way too overrated and aspects of it are typically abused in games and general developement (inheritance, check gdcon slides).

Besides C++ is a multi-paradigm language not just purely OO or force you into one paradigm, you can use any or mix some/all of the supported paradigms (be it natively or through library support) at the same time which will typically be the case.

[Edited by - snk_kid on July 16, 2005 4:59:11 PM]

bytecoder

Jul 16, 2005 at 10:04 AM

Quote:
Original post by snk_kid
I just don't get this view people have of OOP & procedural as being mutually exclusive because it is typically not the case.

Imperative languages suchs as C++ that supports OO concepts natively in the language your still programming procedurally with those objects, the only difference is now you have native support for proper user-defined types be it non/polymorphic, parametric, or what ever kind of type. At the end of the day this is the important thing.

I have to say OO is way too overrated and aspects of it are typically abused in games and general developement (inheritance, check gdcon slides).

Besides C++ is multi-paradigm language not just purely OO or force you into one paradigm, you can use any or mix all of the supported paradigms (be natively or through library support) at the same time.

I agree, although I should point out that inheritance is a pitfall in C++ and many other popular languages, and isn't required for OOP. The same thing can be accomplished with duck typing in more advanced languages, such as python.

For the record, I program in a procedural style using python--I use classes as glorified structs, no more, no less. Programming this way exposes a lot of rough edges in python, however, such as the lack of automatic dynamic dispatch, no way to automate type checking, and lack of rich data description facilities.

DigitalDelusion

Jul 16, 2005 at 10:06 AM

Quote:
Original post by bytecoder
I agree, although I should point out that inheritance is a pitfall in C++, and isn't actually part of OOP. The same thing can be accomplished with duck typing in more advanced languages, such as python.

It's quite possible to duck-type in C++ to... ever heard of templates?

bytecoder

Jul 16, 2005 at 10:09 AM

Quote:
Original post by DigitalDelusion
Quote:
Original post by bytecoder
I agree, although I should point out that inheritance is a pitfall in C++, and isn't actually part of OOP. The same thing can be accomplished with duck typing in more advanced languages, such as python.

It's quite possible to duck-type in C++ to... ever heard of templates?

At runtime, although, I did almost miss that.

Promit

Mod

1,082

Promit

Jul 16, 2005 at 10:12 AM

Quote:
Original post by DigitalDelusion
Quote:
Original post by bytecoder
I agree, although I should point out that inheritance is a pitfall in C++, and isn't actually part of OOP. The same thing can be accomplished with duck typing in more advanced languages, such as python.

It's quite possible to duck-type in C++ to... ever heard of templates?

Furthermore, I'm not clear how that replaces inheritance. Template specialization can behave like inheritance in some ways, but it's not a replacement.

Anyway, to the OP, I say, do whatever has a solid logical structure to it. I like most of my things to be objects, since it allows me to take advantage of techniques such as RAII. But if you have some way of designing that makes sense, and is easy to work with, then that's all that matters.

[Edited by - Promit on July 16, 2005 1:12:04 PM]

snk_kid

132

snk_kid

Jul 16, 2005 at 10:20 AM

Quote:
Original post by bytecoder
although I should point out that inheritance is a pitfall in C++ and many other popular languages, and isn't required for OOP. The same thing can be accomplished with duck typing in more advanced languages, such as python.

Hehe I would not say that would make it more/less advance, they both achieve different goals. This is the first time I have heard dynamic type system referred to as duck typing so I have learnt something new today [grin].

Yes, C++ is not particularly well suited to a fully dynamic type system that is supported natively like Python, in c++, you have to program for that kind of level yourself and it will still severely suck. C++ aims in the opposite direction where the preference is the static type system and in fact with the two Python & C++ together can be an awesome force.

Sometimes i cringe when I see game object types (Monster etc, etc) implemented in C++, its such a daft idea.

[Edited by - snk_kid on July 16, 2005 1:20:35 PM]

nas1982

Jul 16, 2005 at 10:31 AM

The OO approach is best suited where the program flow is modularised and seperated in to further classe (form a Java perspective). I have to agree that some aspects of procedural programmimg are unavoidable. However If you take the Object stuff further when dealling COMs and LDAPs etc, it becomes more apparent to use and Object-Oriented approch in order to interface with other languages, which may be more important in the future.

OO is better and is widely used. it was/is used in the development of Linux and Windows. Do you need any more of a reason to adopt this approach.

bytecoder

Jul 16, 2005 at 10:31 AM

Quote:
Original post by snk_kid
Quote:
Original post by bytecoder
although I should point out that inheritance is a pitfall in C++ and many other popular languages, and isn't required for OOP. The same thing can be accomplished with duck typing in more advanced languages, such as python.

Hehe I would not say that would make it more/less advance, they both achieve different goals. This is the first time I have heard dynamic type system referred to as duck typing so I have learnt something new today [grin].

Yes, C++ is not particularly well suited to fully dynamic type a system that is supported natively like Python, in c++, you have to program for that kind of level yourself and it will still severely suck. C++ aims in the opposite direction where the preference is the static type system and in fact with the two Python & C++ together can be an awesome force.

Sometimes i cringe when I see game object types (Monster etc, etc) implemented in C++, its such a draft idea.

I suppose Duck Typing does acheive a goal that inheritance doesn't--be helpful ;) Really, though, they are basically the same thing, just that Duck Typing does it automatically. In any event, just because a language is staticly typed doesn't mean it can't build hierarchies automatically and acheive the same thing as duck typing--it's just laziness on the part of the language designer/compiler writer.

bytecoder

Jul 16, 2005 at 10:32 AM

Quote:

OO is better and is widely used. it was/is used in the development of Linux and Windows. Do you need any more of a reason to adopt this approach.

"Better"? Do you have any proof to back up that very broad statement?

DigitalDelusion

Jul 16, 2005 at 10:38 AM

Quote:
Original post by snk_kid
Hehe I would not say that would make it more/less advance, they both achieve different goals. This is the first time I have heard dynamic type system referred to as duck typing so I have learnt something new today [grin].

The rationale is: "if it looks like a duck, acts like a duck and sounds like a duck..."

_the_phantom_

496

_the_phantom_

Jul 16, 2005 at 10:56 AM

Quote:
Original post by DigitalDelusion
Quote:
Original post by snk_kid
Hehe I would not say that would make it more/less advance, they both achieve different goals. This is the first time I have heard dynamic type system referred to as duck typing so I have learnt something new today [grin].

The rationale is: "if it looks like a duck, acts like a duck and sounds like a duck..."

then its dinner?

Anyways, I'm pretty much in line with 'whatever works and is logical', there is no real reason to try and go all out in either direction. If objects make sense then use objects, if free functions make sense then use them, as long as your design is solid it shouldnt matter.

bytecoder

Jul 16, 2005 at 10:56 AM

Quote:

Hehe I would not say that would make it more/less advance, they both achieve different goals. This is the first time I have heard dynamic type system referred to as duck typing so I have learnt something new today .

Oh yeah, I forgot how doing stuff for you was so "un-advanced." Now if you excuse me, I'm going to go program my game in assembly, because, you know, nobody likes it when the computer does stuff for them [grin]

Fish HF

Jul 16, 2005 at 11:04 AM

Before, I use classes for everything.
Now, I avoid classes when possible.

I my current project, I put objects that'll only have one instance in a cpp file instead of in a class, then theres a "all.h", which is the only header in the project...
Those objects will have methods like this "MyObject_Method"...
If the objects will have multiple instances, I'll use structs with those methods...

When I wanted to add some cool methods in a object, I'll just code it in the cpp file, then I'll copy it's declaration into "all.h"(if it's a public method)...
It feels like drag&droping gui stuff into a form in VB :P

_the_phantom_

496

_the_phantom_

Jul 16, 2005 at 11:27 AM

ewwww... EWWWWW!! NO! BAD PROGRAMMER! BAD!!!

If you are using C++ then use namespaces, dont pre-fix your function names, for for the example above you'd do it as

namespace MyObject{    void Method();}// called asMyObject::Method();

Also, one header with everything in?? sweet lord, that gives me shivers just thinking about it..

Jingo

Jul 16, 2005 at 11:33 AM

Quote:
Original post by snk_kid

Sometimes i cringe when I see game object types (Monster etc, etc) implemented in C++, its such a draft idea.

Whats daft about a monster class?

Fish HF

Jul 16, 2005 at 12:21 PM

Quote:
Original post by _the_phantom_
ewwww... EWWWWW!! NO! BAD PROGRAMMER! BAD!!!

If you are using C++ then use namespaces, dont pre-fix your function names, for for the example above you'd do it as
*** Source Snippet Removed ***

Also, one header with everything in?? sweet lord, that gives me shivers just thinking about it..

namespaces...good idea!! Why didn't I think of that? lol

my mighty header is more understandable than the hacked together headers in the half life 2 SDK..lol..maybe it's because headers don't have a table of contents...

DigitalDelusion

Jul 16, 2005 at 12:29 PM

Quote:
Original post by _the_phantom_
Also, one header with everything in?? sweet lord, that gives me shivers just thinking about it..

I second that... That monstrosity must be a nightmare to test or reuse.
But OTOH not everyone belives in TDD or ease of reusability.

_the_phantom_

496

_the_phantom_

Jul 16, 2005 at 12:38 PM

Quote:
Original post by Fish HF
my mighty header is more understandable than the hacked together headers in the half life 2 SDK..lol..maybe it's because headers don't have a table of contents...

Maybe so, but by placing everything into one header when you make a small change to an unrelated class/struct you force everything to need a recompile, plus they slow down compile times anyways.

Add to that DigitalDelusion's comments about ease of reuse and testibility, logical seperation will gain you alot of clarity and improve your code base no end.

Promit

Mod

1,082

Promit

Jul 16, 2005 at 1:22 PM

Quote:
Original post by Fish HF
my mighty header is more understandable than the hacked together headers in the half life 2 SDK..lol..maybe it's because headers don't have a table of contents...

1) HL2 is pretty much one gigantic mess that produces pretty pictures.
2) If HL2 used your design, every time even a minor change was made to one of the structures, just under a million lines of code and comments would need to be recompiled. This is not the quickest thing ever.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.