Jump to content
  • Advertisement

Archived

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

veruna2k

It doesn't apply an object oriented development model why in game development?

This topic is 5817 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

Why difficult to applying object oriented development process to game development? please answer... [edited by - veruna2k on December 4, 2002 4:53:26 AM]

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
quote:
Original post by veruna2k
Why difficult to applying object oriented development process to game development?

Who said it was difficult?

Share this post


Link to post
Share on other sites
I agree, it does seem to be "difficult" ... Thats probobly why many people have yet to adopt object oriented programming fully. (That, and many people hate 'new' things. Even if the thing has been around for 30 years and is only new to the person in question hehe)

But what might offer some insight is the reason that I didnt switch to full on object oriented programming until recently:
It forces you to plan. Plan plan plan. Every detail. If you have a shoddy functional program design, it is easy to make it work and keep working on it, figuring the plan as you go.

With full object oriented code, I find I run into a dead end where I _must_ refactor if the design isnt clean enough. (This is a good thing!)

Too much work to hack up a quick program, and more thinking than coding goes into a project.

Then again, those arent good reasons. There just reasons.

... my 2 cents.

[edited by - Kevlar-X on December 14, 2002 7:46:42 PM]

Share this post


Link to post
Share on other sites
Kevlar is correct. To be fast in 3D you must do it how the hw likes it and not the other way around. Too bad hw isn''t oop. Also, engines are evolutionary where lots of code gets thrown out during dev. stages and is not oop friendly. This breaks down any planning you had thought of previously. New hw features or techninques come completely invalidating your old code base note lightmapping to real-time per-pixel lights/shadows. Notion of light in lightmapping code doesn''t make sense while it does in per-pixel light code. Major reason is that hierarchies and extended planning locks you in, this is completely orthogonal of how engines/tools are produced. You just don''t keep on using 10 year old code base in gfx development as the technology moves too fast. Notice performer and d3d retained mode situation. Or Java3D scene graph. Very few if anyone is using them for games. They''re slow and frequent new tech. makes them obsolete thus need to be rewritten invalidating user''s entire code structure. Plus lang. authors want you to buy their books so they start the propaganda machine and newbie is then led to believe that oop is the only way to program. Then newbie gets frustrated when everything doesn''t fit his new found oop paradigm and he gives up programming because it just became too hard. If you''re spending more time in c++ standard book or in design stage rather then writing your game code then something went wrong on the way to kansas, toto. In the real world, you need to produce code fast and have a product on the store shelves pronto otherwise you don''t eat and die. Real life sucks

Share this post


Link to post
Share on other sites
It isn''t difficult once you got the rule. As Kevlar said, you should have almost the entire program design wrote down into paper before you can start writing a single line of code, but not necesarily, and that can also be applied to linear programming.

I find OOP a good way to "encapsulate" low level programming into a higher level structure, easy to understand, hard to mess with (because it protects data from dirty hands like mine), easy to scale and easy to mantain. After you write the structure, then you only play with objects, properties and actions (methods), like playing with toys. Of course writing those objects isn''t easy, but it isn''t harder than writing global functions.

my 0.10 cents.

Share this post


Link to post
Share on other sites
Correct xaxa. Your engine must have some kind of structure in order for you to make head or tail of it. You can use high level constructs if you think they will help out but you shouldn't force yourself into using them on something that would just not work well. Engines are evolutionary and you won't have all the pieces nailed down because of this. You should accept that you will find new ways to do gfx stuff as you progress and your framework should take this into account. Two things helped me the most were object data encapsulation and breaking my functions into blocks that could be reused and more complex algos created from the simple functions. I don't use inheritance nor oop as much as I used to because it hides your intent and makes it harder to understand. Inheritance sometimes works well othertimes the meaning of inheritance doesn't make as much sense on some objects.

[edited by - JD on December 15, 2002 5:28:30 PM]

Share this post


Link to post
Share on other sites
If your engine framework can''t handle the addition of per-pixel lighting effects, then take the opportunity to determine why the design failed and learn from it. How could it be redesigned so that adding this effect would be easy? I''m actually interested in how using an OOD could make adding that harder than if a modular or procedural design was used? It seems it would be about the same.

How is added support for a custom pixel shader any different than adding/having support for different vertex formats? And your going to want your engine to support more than one format.

It has long-reaching consequences with the material that the engine renders, but it doesn''t seem hard to add the capability to an existing engine.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!