#### Archived

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

# Game Development and OO

This topic is 6453 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Ok, this is probably gonna get me killed or something, but I think it''s a valid question. Most of us on this forum would have some exposure to OO. Personally I work with it everyday and I think it''s brilliant. Anyway, alot of articles, books, etc state that the modelling aspect of OO is particulary applicable to games. And thats true in a lot of ways. However it seems from reading posts on this forum that most game developers do things for the sake of speed that violate encapsulation and do other bad OO things (casting, etc). So is OO worth it? -- ChoasEngine "Those parts of the system that you can hit with a hammer (not advised) are called hardware; those program instructions that you can only curse at are called software." -- Unknown

##### Share on other sites
I think part of the way to become a GREAT programmer, is to find when you break the principles, and when to stick to them.
Object Orientation is a pretty idea, and it sometimes really helps to bring a design together, but sometimes you need to violate some principles for ease-of-use, or speed.

Though, usually, in a language like C++, there is a LOT you can do before you are really violating any Object Orientation principles

Give me one more medicated peaceful moment..
~ (V)^|) |<é!t|-| ~

##### Share on other sites
I''m a big OO programmer. I use it so much I can''t go back to regular procedural programming unless I am doing a simple tool. I think OO programs are easier to design, implement, debug, and are easier to buiid among teams. Don''t sacrifice good design for speed. If you design your program well, you won''t need to.

Domini

##### Share on other sites
Actually, designing a GOOD OO approach is a very hard thing to do, especially with large projects. It takes a lot of planning and vision, but it makes it SO much easier to program if you do it right.

Also, as MadKeithV said, there may be a few extreme times you may "break the rules" for speed, but if the design is good, you shouldn''t have to break rules for ease of use.

##### Share on other sites
quote:
Original post by Domini

Don''t sacrifice good design for speed. If you design your program well, you won''t need to.

I don''t mean this as an inflammatory question, but where do you get this wisdom? Have you experienced it, or is it just "what everyone else says".
Be very careful where you tread, optimising C++ is a lot harder than it seems at the beginning, and sometimes you DO need to tradeoff.

Give me one more medicated peaceful moment..
~ (V)^|) |<é!t|-| ~

##### Share on other sites
Myself I think that a good compiler should be able to optimise most of the speed deficiencies in C++.

For example get and set routines if declared inline can be optimised away.

I happen to agree with domini. I couldn''t possibly go back to procedural programming.

As an aside what about generic programming( templates )? Do they have a place in game programming?

##### Share on other sites
I''ve experienced it. If you make sloppy code that runs fast, especially at the beginning of the project, you will run into problems. I also develop my programs with the intention that I will want to upgrade them later. By using classes and encapsulating code, you can easily upgrade by just reimplementing a class, and you never have to touch other stuff.

I use to break OO design alot. I still do some of the time. Usually, I''ll just make another class a friend instead of making everything public.

Domini

##### Share on other sites
Generic programming is brilliant - it actually lets you work out some of the performance considerations of C++ without having to think about it too much. I just wish Visual C++ 6.0 would have better support for it, they''ve really skimped on the ANSI standard with respect to templates.

Domini - if you have experienced, I agree with you.
Check the resent "C++ operator overloading, and why it blows " thread, to find the evolution that lead to it.
I wrote an article on C++ Optimisation, that I hope will get published here. I''ve been editing it with some of the people here on the ''boards to make it worth reading.
You can get a version at my web page. That''s a word95 document by the way.

If you have any suggestions or criticisms, I''ll be happy to hear them!

Give me one more medicated peaceful moment..
~ (V)^|) |<é!t|-| ~

##### Share on other sites
Im a big OO user and learned the hard way. My first game was in C++ but wasnt very OO designed, I have tried to go back and update the code almost a dozen times and given up becasue even I can not follow it.
OO is essential in any big project, even a one-man project.

http://www.positech.co.uk

##### Share on other sites
Personally, I have been working with OO (language and design methodolgy) for more than 10 years.

An OO language does have certain pitfalls for new programmers resulting in (and always do) awful code and badly implemented designs, this leads to bugs, inefficient code and general bad mouthing of OO.

Experience can produce fast efficient OO code. In fact IMHO OO methododolgy is ideal for game writing.

##### Share on other sites
quote:
Original post by DeltaVee
Experience can produce fast efficient OO code.

Exactly. Experience! ( or skill ).
OO is not a magic box of tricks, it is just another tool ( a very useful one ) that requires some skill and practice to master. It''s probably harder to master than procedural-style programming.

Give me one more medicated peaceful moment..
~ (V)^|) |<é!t|-| ~

##### Share on other sites
Is OO worth it? I should think that Unreal Tournament answered your questions there.

Epic can use the same code base to make the next gen engine (as they have so frequently stressed), Digital Extremes already have their new persistent online world game up and running with a modified version of it (although they have now got a team working on something new so that they can release their dependency on Epic).

Where is id? They''re gonna have to rewrite all their stuff

But on the difficulty side, it''s taken Epic like 5 years to get to this stage so it is definitely far from an easy task to completely mastermind a successfully OOPed game.

Generic programming is more correctly termed Programming with Parametric Types and if you need justification for it''s existence then Tim Sweeney''s next gen scripting language is being designed with them heavily in mind, much improving over the weak concept of templates.

Can you tell who my heroes are?

- FlyOnTheWall

##### Share on other sites
quote:
Original post by ChaosEngine

Myself I think that a good compiler should be able to optimise most of the speed deficiencies in C++.

For example get and set routines if declared inline can be optimised away.

I happen to agree with domini. I couldn''t possibly go back to procedural programming.

As an aside what about generic programming( templates )? Do they have a place in game programming?

I read an interesting article that claimed anytime you use accessor and mutator methods, that your design isn''t really OOP. The claim, in which he made some great points, was that get/set methods void the concept of encapsulation. The example he used was a bank. Lets say you had a class account as (leaving out all the other stuff for simplicity):

class Account{private:   int balance;public:   setBalance(int value);   int getBalance();}

What if you needed to change the size of the balance property (maybe Bill Gates wants to be a customer) and you need to make it a double, all of a sudden you will have to change every piece of code that uses this class; it doesn''t really encapsulate anything.

I won''t go into his solution for this, but if you are interested the link for the article is:

http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html

Very interesting article.

Hitman

##### Share on other sites
If that''s his case, then he thinks no class should receive/return data. It would make OO programming basically useless.

##### Share on other sites
It IS an interesting article, but I'm afraid I don't agree with him.
He says every object should have it's own UI, so that it doesm't have to worry about the format of the data coming into it.
Ok, what if the UI changes from say a 2d display to some sort of 3d interface (far-fetched, I know, but bear with me). We now have to go to EVERY class and recode the UI.
Whereas if we have a defined standard for the data then we just replace the interface object.

and if we encapsulate the data form the screen into an object then we change the format of the data got from the screen and simply return it with the corresponding get method.

Edited by - ChaosEngine on June 21, 2000 11:39:52 AM

##### Share on other sites
Dear Mr Anonymous:

No, ID''s code is very clean and I doubt they will rewrite it, especially since they have made 3 versions of quake.

Now this is just turning into a procedural bashing. How does every post turn into a flame war? Im sure if i posted ''I like hamburgers'' id find a reply from someone who likes cheeseburgers trying to insult me and hamburger with it leading to eachother at our necks. Just be careful what you say/

-----------------------------

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

##### Share on other sites
Are Get / Set methods really necessary? I mean if you have a protected memeber, say int x...do you need to have GetX() and SetX() methods...why not make x public since it practically is anyway? You''re not really hiding the data if the only purpose of GetX() and SetX() are to return and set the value of x. Obviously if GetX() and SetX() affects other members it makes sense to provide these methods...but otherwise, do you need them?

Hope that makes sense!

mhanna@nyc.rr.com

##### Share on other sites
I still believe that procedural programming has its place. All the simple tools and conversion utilities that I make are written in DOS using procedural programming.

OO was developed to be a better alternative to procedural programming, so why should anyone expect it to be worst. The transition from OO to procedural can be hard at first, but its usually worth it.

Domini

##### Share on other sites
I think the point is that if your class is just a big list of Get/Set methods and very little else, then you''re not really understanding the point of Object Orientation. Of course, nearly all classes will need some Gets, and some Sets, but generally you work with your objects on a higher level than that.

##### Share on other sites
quote:
Original post by ChaosEngine

It IS an interesting article, but I''m afraid I don''t agree with him.
He says every object should have it''s own UI, so that it doesm''t have to worry about the format of the data coming into it.
Ok, what if the UI changes from say a 2d display to some sort of 3d interface (far-fetched, I know, but bear with me). We now have to go to EVERY class and recode the UI.
Whereas if we have a defined standard for the data then we just replace the interface object.

and if we encapsulate the data form the screen into an object then we change the format of the data got from the screen and simply return it with the corresponding get method.

Edited by - ChaosEngine on June 21, 2000 11:39:52 AM

I think the idea would be to encapsulate your graphics object so you don''t care whether its a 2d display or a 3d display. If you tell an object to display itself by passing a graphics object and say it calls something like GraphicsObject->DisplayString(string), or something, then it doesn''t have to know if it is being displayed on a 2d surface or a 3d surface. If your graphics object doesn''t change its interface, you don''t have a problem. You could change your implementation of the graphics object to actually display on a wrap around screen to simulate a fully immersed world, but if the interface doesn''t change, the objects don''t care. I realize this is a simplistic example, I''m still trying to get my head around this theory.

I''m not saying I agree with him 100% either, its just that looking at his credentials, he''s a lot more experienced than I am, so I will rethink the way I do things, and maybe I will agree with him more.

Hitman

##### Share on other sites
quote:
Original post by Kylotan

I think the point is that if your class is just a big list of Get/Set methods and very little else, then you''re not really understanding the point of Object Orientation. Of course, nearly all classes will need some Gets, and some Sets, but generally you work with your objects on a higher level than that.

Well his biggest points are that you shouldn''t ask an object for data that you need to do something, rather ask the object to do something with that data for you. That goes against the encapsulation rules. I''m having trouble with this personally, but so far, in my most recent project, I have been able to move towards what he is talking about. It seems to be working, though I am just at the beginning stages.

##### Share on other sites
At some point, however, there has to be an exchange of data between objects. Consider this scenerio:

Two ships in space, one needs to intercept the other. In order for this to happen the interceptor needs to know the location of the other ship. I can think of no way to do this other than to have the iterceptor object ask the object that it is targeting for its location.

##### Share on other sites
At this point when you start to abstract data and treating it as an entity, you start writing code that can become cumberson and moderately difficult to use.

If you are enforcing business rules for a large DB process this is ok, you can always strap on another server to make your backend services execute a little faster.

In gaming (programming) you generally call a spade a spade. In other words, you decide up front how 'fixed' your data types are and how they are access. Cuz' if you don't, your code is going to be soooooooooooooooooooo slow. Once you have decided that you don't need an abstract data type, acces/manipulation is straight forward.

Gaming class hierarchies generally are not very deep (BTW shallow class hierarchies are a good design), but they are generally wide. The reason for this is that you pack in as much functionality into the base (and child classes) as you can without adressing the final derivation (BTW this is what your supposed to do in OO, its called abstraction).

Remember the engineers rule of thumb, KISS. Keep it simple (stupid). This is especially true in OO.

Edited by - DeltaVee on June 21, 2000 1:58:20 PM

Edited by - DeltaVee on June 21, 2000 1:59:23 PM

Edited by - DeltaVee on June 21, 2000 2:16:47 PM