Jump to content
  • Advertisement

Archived

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

xjussix

How OO should my game be?

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

I know this is a "dangerous" topic but I'm having some trouble deciding the actual style of implementation of my game. Should I do _everything_ based on OOP & OOD? Should I only use classes and objects for characters, user interface etc? It seems to me that procedural programming makes the code look a lot more complex to a beginner than OOP.. [Sh*t, this went accidentally to the wrong forum. Sorry!] Edited by - xjussix on August 1, 2001 4:06:55 AM

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
it would make it MUCH easier to maintain and update and add new features if MOST of it is object oriented (you can never make a completely OOB program)

Share this post


Link to post
Share on other sites
OOP makes your code so much more flexable, and it''s easy to add new things and make "smart code" using all those special inheritence properties and polymorphism, etc.

Share this post


Link to post
Share on other sites
There''s no "set level". Splitting up the major parts of your program does seem to be a smart idea in most cases, and to go further you could look on a case by case basis and split up various parts of code...furthermore, some people (me included!) sometimes use very little oop and the apps turn out fine. But then again, I always use some form of oop in big/complex projects. I recommend that you at least split it into seperate code files or classes like this:

Graphics, Sound, Main, Ai, etc

Maybe further if you''re up to it. It also depends somewhat on what api you''re using (DX, opengl, etc).

Share this post


Link to post
Share on other sites
One nice use of OOP is to encapsulate operating-system-specific calls to make the game more portable, if that is any concern to you. Big areas for this are: graphics (directx GDI etc), user I/O (mouse, keyboard), networking (for online games), as well as any top-level OS related stuff (creating windows, starting up network, message loop).

Share this post


Link to post
Share on other sites
I wrote a simple game not OOP at all and I really regretted it. I''m busy rewriting it from scratch.

Share this post


Link to post
Share on other sites
Well, since I like to experiment with the programs I write, I end up rewriting my engine every little while. The last version was completely OO (in C++). The new version is completely Modular (in C). I can do all the same stuff in each and both are fun to work with. There''s no reason you can''t do a game with or without OO.

[Resist Windows XP''s Invasive Production Activation Technology!]

Share this post


Link to post
Share on other sites
Do it at the level where you feel comfortable and where you won''t end up coding yourself into corners and won''t end up writing more code than you would with straight C (its very easy to end up writing a mammoth C++ system full of extensibility which could be done 10 times smaller in C).
With proper *design* and careful, skilled implementation, a C++/OO program can be tons better and cleaner than the equivilent C program - but only if you''re careful!.

Some very true things I recently read on a mailing list :

1)
C++ (& OO) is like teenage sex:

* It''s on everybody''s mind all the time.
* Everyone talks about it all the time.
* Everyone thinks everyone else is doing it.
* Almost no one is really doing it.
* The few who are doing it are:
a. Doing it poorly.
b. Sure it will be better next time.
c. Not practicing it safely.
d. Everyone''s bragging about their successes all the time, although very few have actually had any.


2)
In olden days, the C motto was "We provide sharp tools; you may cut yourself."

Now, perhaps, the C++ motto should be "We provide sharp power tools; you may cut off a limb -- and if you work at it, the limbs of all your friends."


--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
use it when you need it, don''t use it when it isn''t necessary. Basically just view it like any other feature. Even in areas where you don''t need polymorphism you''ll probably want to design some primative classes to act like built in types. The teachers at school that are telling you that OO is going to bring about heaven on earth aren''t right. The old timers that say OO is too slow and that anything other than C is wasteful luxury aren''t right either. Just view it with an unbaised eye, see where it suits what you are doing, and use it when you want to.

Share this post


Link to post
Share on other sites
If you do plan to do it as a standard, i recommend all class members be declared virtual (unless you are absolutely sure that you won''t need them in a derived class). Even my inline functions are typically virtual by default (just makes derivation smoother).

"You call him Dr. Grip, doll!"

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!