Archived

This topic is now archived and is closed to further replies.

matias suarez

Is OOP the right one for game development?

Recommended Posts

I do not see why there must be a different approach to games than for any other software.
Games are software, nothing special.
OOP is just a technique for writing SW.

I''m personally not a strong believer in OOP. I mean is not the solution to everything like many claim.
Sure OOP fits for an entity system; for Input handling...well some nice function is probably enough.
Generally I think that more than OOP the game industry needs to lear I''m more atomic component programming(that seems an unknown topic for most of the university teachers).
Maybe this topic should have been posting in the SW Engeneering forum.

ciao
Alberto

-----------------------------
The programming language Squirrel
http://squirrel.sourceforge.net

Share this post


Link to post
Share on other sites
When your problem domain consists of objects with state and behavior, it is probably a good candidate for an object-oriented solution. But as the previous poster stated, not everything is best modeled with objects.

C++ supports OO, procedural, and generic programming, which is why it''s such a good general-purpose language.

--
Dave Mikesell Software & Consulting

Share this post


Link to post
Share on other sites
Yeah, of course it''s fine. Many, if not most, of the professionals now use it.

The only thing you need to be wary of is which mechanisms are slow and which are fast. C ''seems'' faster to some people, but that''s because it provides fewer mechanisms

Richard "Superpig" Fine
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4
ry. .ibu cy. .y''ybu. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu
OpenGL is a language

Share this post


Link to post
Share on other sites
Using OOP may be slower because the overhead needed (methods are not stardard calls, they are _thiscall). But there is a small secret: private (and probrably protected) are faster. So, what you need is a good OOP desing. Put what you really need in public and hide everything in private. I thinck that is not a good idea to put costumizable members in private because you will need to make functions calls to work with them instead of accessing them imidiatly!

Procedural paradig works great for low level programing:

class Math{
float cos(float ang);
float sin(float ang);
...
};
extern Math math;

I thinck that this is.....stupid? Or maybe not!! Or maybe yes!!

Share this post


Link to post
Share on other sites
I think there's always some confusion surrounding OOP: the most important thing to understand, is that its a paradigm.

I'm just going to take some time to vent here in regards to C vs. C++ - even though I'm aware OOP can be carried to a great number of languages ...

Firstly, to "use OOP", doesn't mean _everything_ is an object. For example, a program where you have an application class, an instance of that application class, a class for the renderer, etc. I see a lot of projects using this motif, and it proves to be _more_ complicated to write and understand, in terms of setting up the multitudes of heirarchies, than it would be if half of the program had been written using standing C techniques.

I once tried to develop an engine this way. After weeks of designing intricate class hierarchies and UML diagrams, I realized that I could have been half-done by this time. Elegant solutions are nice, but they can cost you more time and headaches than they're worth.

B. Stroustrop (if I'm spelling that correctly) has said publicly that this was never his intention in developing C++. He maintains that OOP should only be used where it serves an obvious benefit to your program. Carmack has stated the same thing on several occasions.

The point I'm trying to get across is - don't get the impression that OOP is everything. It isn't "god's answer" to programming.

[edited by - carb on October 21, 2003 12:43:17 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by carb
B. Stroustrop (if I''m spelling that correctly) has said publicly that this was never his intention in developing C++. He maintains that OOP should only be used where it serves an obvious benefit to your program. Carmack has stated the same thing on several occasions.



This is the correct answer. Know what you''re trying to do, know your priorities, and know your tools. OOP is one such tool. An entity class is probably a good idea, a triangle class for your renderer is probably not.

Share this post


Link to post
Share on other sites
quote:
Filami, you are an idiot.

WHAT A FUCK???? Whats hapening to you guys?? seems that no one can now their opinions in this damn Forum
What Did I sayed to offend you? I''ve just sayed that private methods can be faster and less function calls can be faster too...I''ve sayed that mathematics functions don''t need OOP design! Can ANYBODY tell me what is going wrong?? ...I''m getting tire of this guys!!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Filami
quote:
Filami, you are an idiot.

WHAT A FUCK???? Whats hapening to you guys?? seems that no one can now their opinions in this damn Forum
What Did I sayed to offend you? I''ve just sayed that private methods can be faster and less function calls can be faster too...I''ve sayed that mathematics functions don''t need OOP design! Can ANYBODY tell me what is going wrong?? ...I''m getting tire of this guys!!


Probably because making your interface private makes it impossible to call from the outside without going through a public interface, which was what you were trying to avoid in the first place. And so your code is just ..stupid as the other AP was getting at

Share this post


Link to post
Share on other sites
There is a very recent article from Stroustroup going into more usefull detail and giving examples of such things ... places where he makes it obvious for those with less experience, that each problem to solve has one or efficient ways of being tackled, and not to use just one tool to do every job. He does in fact believe in using C++ for nearly every task, but that is why he believes in adding support for all paradigms to C++. His goal is that C++ someday be as easy to start with as shell programming or PERL, but that from every step of the way access to the more advanced paradigms are there to support what you want to acomplish.

Personally, I do not think of most "generic" programming as seperate from OO programming, because I never ever write an OO C++ program without using templates, this is just the absolute best system from modeling things like containers ... and when I go to using Java or C# there are only TWO langauge features missing to make life easy, templates, and multiple inheiritance. And for anyone who thinks using interface replaces multiple inheiritance, you just don''t use either enough. Every program I write has multiple interfaces, and multiple utility classes, and how can you quickly and easily combine a few utility or simple objects, each implementing a standard version of its own interface, without multiple inheiritance. The only way in Java or C# is to provide all of the function hook-ups for the second and third base interfaces manually. How silly for new langauges.

To the original poster, there are almost no large teams using standard C for large PC projects anymore. When I got out of school, standard C was still in use in embedded and performance critical domains, but in the years 2000-2002 just about every team that was using C, moved to C++. It has to do with langauge and compiler maturity more than anything else, in the days when Visual Studio 4 and 5 we''re out, there where hardly any truely mature C++ compilers, where the errors and warnings we''re not absolutely archaic and the compiler didn''t barf on complicated constructs. Now, the C++ compilers are expected to "just work" and they mostly do. So now, using C++, everyone can mix and match exactly which constructs provide for the best development and performance mix ... many time game developers leave out certain common OO techniques in the name of speed, but usually only in the guts of their engines, the leafs, and areas used by the AI and available game interactions are usually quite OO, in fact, they are some of the most intricate systems in the game from a design perspective. Not using OO had led to too many systems where things which should behave similarly didn''t, now with base classes and interfaces, they are almost guaranteed in the design to interact correctly.

So, for game development, I highly recommend C++, but learn the trade offs of everything, learn what the cost of member functions is, constructors, virtual functions, etc ... each feature has a cost and a benifit, make sure you use them wisely (well to start with just use them "correctly" but later you must develop wisdom to be a truely talented developer).

good luck

Share this post


Link to post
Share on other sites
Well you seems to be right guys, few days ago i read that strjtrp comment too and it makes a lot of sense, i always at some point get the oo headache of trying to fit things into it, while it may be academic concept is not practical (everywhere).
But then, i made a mess on c with my first game, i mean it works and great but i clearly failed in the design since when i tried to add levels and reuse the code it just didn''t fit the way i did it, i feel that in a way the design itself of a game is slightly different than a normal application (maybe is my lack of experience designing the framework of a game)
But seems that oop will add more problems if i do it careless as before :D

Share this post


Link to post
Share on other sites
quote:
Probably because making your interface private makes it impossible to call from the outside without going through a public interface, which was what you were trying to avoid in the first place. And so your code is just ..stupid as the other AP was getting at

I'm talking about:

class Billboard{
CVector normal, right, up;
void CalculateTranformationMatrix();
void CalculateNormal();
void CalculateRightUp();
void DrawQuad();
public:
float size;
void Draw();
};

as you can see, the size is public so you can access it directly. The Draw is public too to lettting you draw the thing.
The CalculateTransformationMatrix and others function are private because user don'r need to see them!! I thinck that it isn't nothing stupid to do this!! I just thinck!!

Edit: That damn tags again :\

[edited by - filami on October 21, 2003 1:23:33 PM]

Share this post


Link to post
Share on other sites
I''ve used OOP most of my professional career. I think it''s a very valuable tool. But I can''t understand the OOP purists & evangelists. To me, it''s a tool - used properly, it makes your job easier. If used improperly (or overused when a better tool would suffice), it can make your job much more difficult.

The big dream of OOP has largely failed - the idea of reusable componants sold individually like electronic componants in plastic baggies at your local radio shack. However, it has encouraged many software practices that make software easier to develop in teams, and easier to maintain. It''s the dominate paradigm today, for mostly good reasons. For that reason alone, I''d recommend using OOP so you can get experience using it.

But remember ... C++ gives you all the ability to create coding nightmares that C gave you, and then a WHOLE heck of a lot more. The more modern languages (Java, C#) seem a bit cleaner, forcing certain practices to help keep code organized in a predictable way, but they can still get pretty awful very easily.

Share this post


Link to post
Share on other sites
I totaly agree with theJay Barson post. OOP is just a tool and must be used if it is logical to use. That brings me to the case of:
class Math{
float cos(float ang);
float sin(float ang);
...};
extern Math math;

That I thinck is not a good example of design!...But is just what I thinck. Some other person can thinck thats a good choice...that the other person choice and I respect that!

Share this post


Link to post
Share on other sites
Here''s the interview in question: http://www.artima.com/intv/goldilocks.html

Here''s some choice quotes from Bjarne:
"To get out of writing low level code, you needn''t start writing a lot of classes."

"The other way people get into trouble is exactly the opposite. They believe that C++ should be an extremely high level language, and everything should be object-oriented. They believe that you should do everything by creating a class as part of a class hierarchy with lots of virtual functions. This is the kind of thinking that''s reflected in a language like Java for instance, but a lot of things don''t fit into class hierarchies. An integer shouldn''t be part of a class hierarchy. It doesn''t need to. It costs you to put it there. And it''s very hard to do elegantly."

"Going to the big class hierarchy is again, you write more code than you need to, and you get too much connection between different parts. I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn''t have been a class in the first place. It''s just a data structure. And if it really is a data structure, make it a data structure."

Share this post


Link to post
Share on other sites
C++ contrarly to Java is not a pure Object Oriented Language. OOP is one of the features of C++, but, C++ continues to behave like C. Thats why C++ is so versatil as Kylotan says!

Share this post


Link to post
Share on other sites
quote:
Original post by Filami
Using OOP may be slower because the overhead needed (methods are not stardard calls, they are _thiscall). But there is a small secret: private (and probrably protected) are faster.

Secret indeed! I have certainly never heard of access modifiers having any impact on speed, and I don''t believe it now. Care to explain what exactly you''re talking about?

On a side note, it''s not necessary to make member variables public for speed reasons if reading is all you need; accessor functions can be made inline to preserve data encapsulation without sacrificing speed.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
namespace MathLib = Mathematics_lib_v9r4;

namespace MathLib {
float cos(float ang);
float sin(float ang);
}

Share this post


Link to post
Share on other sites
Sure, use OO often and as much as possible Seriously, it''s great and forces you to design before coding which is what all of us should be doing anyways. It does mean that coders became designers but that''s evolution. Anyways, I found two helpful sites you might want to check out.

http://ootips.org/
http://cpptips.hyperformix.com/cpptips.html

There are Robert Martin and Bjarne S. snippets in there.

Share this post


Link to post
Share on other sites
Ok, I will citate a portion from my book "C++ Algoritmos e estrutura de dados" that is a Portuguese book about C++:

"As seguintes definições do tipo Y são equivalentes

struct Y{
int f();
private:
int k;
};

class Y{
int k;
private:
int f();
};

Uma das vantagens de declarar como privados (encapsulaos) os atributos de uma classe, é poder otimizar o seu desempenho sem daí resultarem alterações no acesso aos objectos da class."

and the traduction is of the last statment is:
"One of advantages to declare class''s atributes as privates (encapsulated), is to optimizing his "desempenho"(speed, ificency) without resulting in modifing in access to the members of the class."
Hope you understand the traduction. In this statment, I''ve understanded that private parts may be optimized his access. I don''t know what is going under this (must see the disassembler) but I thinck that is has something to do with the this.

Share this post


Link to post
Share on other sites
Hey filami, i understand that as i can read portuguese.
But beware, early optimizations are the root of all evil.
I don''t know which way is better but you can start your design with speed in mind or you can forget about speed, do a clean design and then adjust the parts that needs to be adjusted, both are classical advices on design but since my designs are usually not very good i''m not suitable for an advice on that :D

Share this post


Link to post
Share on other sites