How OO should my game be?

Started by
15 comments, last by xjussix 22 years, 8 months ago
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
- Just another sad bastard
Advertisement
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)
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.
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).
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).
I wrote a simple game not OOP at all and I really regretted it. I''m busy rewriting it from scratch.
In my thunking device, what happens to the inherited pointer to the original base class when I override the function & how do I access it in my inline assembly code, assuming that we are referencing the higher byte of the 16-bit variable?
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!]
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

Simon O'Connor | Technical Director (Newcastle) Lockwood Publishing | LinkedIn | Personal site

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.
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!"
"You call him Dr. Grip, doll!"

This topic is closed to new replies.

Advertisement