Jump to content
  • Advertisement

Archived

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

ChaosEngine

Game Development and OO

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!