Archived

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

Am I an OOP whore?

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

Ok, so ive started designing my new game, and ive learnt alot from my past one (which you lucky buggers will get to see in a day or two ) and so here are the classes that ive got so far, is going OOP overboard? CSystem // handles initing direct3D, windows code etc... CLog // log file stuffage CTerrain // handles all terrain stuff, quadtree etc CConfig // loads config/ini files and provides set, get methods etc CLight // an instance for each light in the scene CGame // game specific what nots CCamera // handles camera stuff, frustem, position etc etc CParticleSystem // particle processing, seting, manipulation funcs CEntity // player, enemys etc, handles everything about them, eg pos AI etc CObject // models etc, and trigger and stuff for them, eg trees, buildings... etc CSprite // sprite creation, drawing etc routines CSound // speaks for itself CUtilities // misc functions eg all the 'makes life easier for the programmer' type stuff CFont // font drawing, creating stuff CConsole // handles input, output, processing etc CInput // all input related functions... as well as a few internal ones eg: CTextureManager and CSpriteManager [edited by - elis-cool on October 21, 2002 5:49:23 AM]

Share this post


Link to post
Share on other sites
I disagree i think inheritance should be avoided whenever possible in game development. It adds another layer of complexity which you could do without.

From looking at your class list it looks reasonable and i would say that there would be only 1 or 2 candidates for inheritance there.

Share this post


Link to post
Share on other sites
Well Im not really a big fan of inheritance and what not, and I see absoulutly no need for multiple inheritance, so far the only place ive used inheritance is in my linked lists (see, I like to program them by hand, none of this STL bullcrap (no flames plz and (some dont like the way I do it) but I have a seperate tail class that inherits from the node class) so yeah... its its just theres so many... seems alittle silly in some respects...

Share this post


Link to post
Share on other sites
I''d aggree that multiple inheritance is something to be avoided if possible, especially when both classes define variables/functions with the same names (*eek*)... but multiple inheritance can be very useful indeed in some situations (eg, guis). Overall, I see inheritance as something that I cannot live without, and makes large scale programming one hang of a lot easier (when used correctly). Especially in games.

Share this post


Link to post
Share on other sites
Doesn''t look very OO to me - looks more like you just made a modular design by grouping related functions in classes. It''s not really OO without polymorphism.



Faith. n. Belief without evidence in what is told by one who speaks without knowledge, of things without parallel. -- Ambrose Bierce

Share this post


Link to post
Share on other sites
inheritance is indeed very! important for game programming

imagine you have 10 monsters and have to write a new class for every monster

its damn lot of work to update them therefore ->inheritance is one of the most important parts of oop and should be used as long as you objects use same functions all over again

i woudnt want to code a game without inheritance

CBaseEntity :
-CBaseMonster:
#Cdifferentmonsters
-CBasePlayer:
#engineer
#medic......

-CbaseAnimating for animated entitiy ...

Share this post


Link to post
Share on other sites
You have a bunch of objects.. But no relationship between them really, so you''re not really doing OO programming.

Either way, you probably don''t want any OO programming going on in yoru game. OO Programming, while encouraging ''good'' (as in human readable) design, promotes ineffecient programming. The code tends to run much slower.

I''ve actually seen a Real Time project go to crap because of all the function calls introduced by the class structures being used.

Cheers,
Will

Share this post


Link to post
Share on other sites
quote:
Original post by RPGeezus
OO Programming, while encouraging ''good'' (as in human readable) design, promotes ineffecient programming. The code tends to run much slower.



This is hogwash. OO design is just as fast as anything else that performs similar functionality. Just like with all tools, you do need to know how it works before you can get the most out of it. I''ve got a book right here about OOP in real-time projects, and it''s a really good read.


Share this post


Link to post
Share on other sites
What you have is indeed not really OOP, but you could make it the base classes ... like CTerrain could be the "mother" class of every type of terrain you have, each of them having shared function and some special to each of them...

You have a good start

Share this post


Link to post
Share on other sites
Hmm. O.o

I''m also designing a game currently (It will be 2D, based on OpenGL). May I have an opinion on how my classes look?

CGame - Handles main game loop.
CLevel - Level object.
CEntityFactory - Creates and destroys Entities.
CPlatform - Any and all lower level functions.
CSound - Sound functions.
CInput - Input functions.
CWindow - Window functions.
CResourceManager - Resource Factory (hands out textures)
CGL - Factory for making GL handles (GLuint)
CLog - Self-explanatory.

CEntity - Base game object.
*CPlayer
*CEnemy
*CObject - Other items (Grass, falling rocks, etc)
*CEffect - Particle effects, ray effects, etc.

CTexture - Texture with data.
CHandle - Handle class.
*CTextureHandle - Texture handle (no data)
*CGLHandle - Texture or Display list handle


Thoughts?

*note, I left out the utility classes that I am using.

Share this post


Link to post
Share on other sites
It has been said before by others, but interactions between objects are more important than the classes themselves.

Because it is the interactions that defines the methods that each classes should expose. And it is also interactions that gets you to create new classes or add a more generic class for a set of classes.

This gets really obvious when you try to modify a design. And it also makes desining pretty efficient because you don''t need bother about methods that you don''t need.

Share this post


Link to post
Share on other sites
When you''re using classes, try not to make classes that are just groups of functions, that''s what global functions are for. Classes should have both data and functions in it; That''s what classes are good for. There''s just no point to making a CUtility class that just has a bunch of functions in it.

Paul

Share this post


Link to post
Share on other sites
quote:
Original post by NorthWoodsman
When you''re using classes, try not to make classes that are just groups of functions, that''s what global functions are for. Classes should have both data and functions in it; That''s what classes are good for. There''s just no point to making a CUtility class that just has a bunch of functions in it.

Paul

hmmn... yeah, I suppose...

Share this post


Link to post
Share on other sites
No, you''re not going overboard. Large projects can have 1000s and 10000s of classes. Look at this list of classes in an engine http://ogre.sourceforge.net/nightly/docs/classes.html.

Inheritance is good way of reducing complexity and increasing maintainability. It promotes code reuse which is a good thing. If you are putting you code in classes, inheritance is a good way to prevent multiple copies of the same code from existing in several places.

Multiple inheritance is useful if you use it for interface classes (like interfaces in Java) or mixins. Otherwise it tends to be confusing.

Its been proven again and again that OOP code can be just as fast as non-OOP code and the benefits of OOP for large projects is well documented. In practice, I''d say OOP code is slightly slower than its corresponding non-OOP code, but the benefits for large projects completely outweighs this.

STL is huge monster and it pisses me off regularly, but there are lots of reasons to use it:
1) portability
2) efficiency
3) no need to reinvent the wheel
4) standardization
5) readability of code

Cheers.

Share this post


Link to post
Share on other sites
I shake my head sadly whenever I hear someone spout the "OOPS is slower" myth. No, really, I do-- I look up from my computer and slowly, sadly shake my head.

People who say that OOP is inefficient, when they are thinking at all, are usually thinking of runtime function binding. That is, calling the Draw() method on a CBase pointer which points to a CDerived. There is, thus, an extra layer of indirection as the computer needs to do a lookup in the vtable. What these people are forgetting is that in a procedural design, the extra computation would STILL BE THERE! It'd be in a case statement or an if statement.

Don't listen to me. I've had too much coffee.

[edited by - sneftel on October 22, 2002 1:26:11 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Nypyren
How NOT to use STL:
(code bloat, general "yuck" feeling)

using namespace std;

How to use STL:
(no code bloat, no "yuck" feeling)

using std::vector;



"using namespace std" doesn''t cause code bloat, only namespace pollution.


Don''t listen to me. I''ve had too much coffee.

Share this post


Link to post
Share on other sites
After seeing ur code and the simple amount of classes/objects listed their it reminded me of a small game (aught to be around 3000 to 4000 lines when finnished) i''d recently started developing that not only will contain at least 20 high level objects and perhaps 100''s of abstract, or game objects/things. But also shows an extreme heirachii of polymorphic decisions to allow for more control over my code.

A sample of some of the objects/classes i will prob have follows

base
(base class for ALL other objects classes allowing extended use of the ''delete'' keyword, and simpler use of pointers and what polymorphism is good at)

stacker : base
(used for storing and sorting (stacking) objects. For example a level''s worth of images or SFX etc...)

obase : base
(used as instance of polymorphic example functions used in ALL other subsystem object (like graphics). functions like ''virtual int run(void);'' or an init and quit function)

graphics :obase
(by now ur prob gettin bored of this post so i''ll leave it here)

As u can see i''ve formed a neat way of organizing every function of the engine in a way that allows for some awsome control and really dictates what languages like java were made for.
It also will NOT be slow at all since like was said before all functions are looked up in the vtable and also the guys who created C++ created it as a replacement for C so i doubt it would be slow in ANY sense of the word.

This is prob a bit excesive for what some of the people here are coding (or not?), but it gives at least some insigt (i hope at least) into just how complicated and yet remaining simple ur OOP code could be or why perhaps for some reason u''d rather just code procedural.

-----< KRYSOLE >------------------------------------------------
note: please do NOT complain or flame this post as u may have ur own oppinion but this is just mine and ONLY my oppinion.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
OOP is not slower becouse of v-table lookups, but becouse every data type is hidden behint its interface, wich couses the folowing:

1) processing time is waisted on calling interface functions, not every data type needs to be hidden behind interface

2) each data type has its own methods, but most computing problems are much better solved by using common methods for few data types, most data processing problems are such, that we have multiple data types on input, and multiple data types on output, procedural aproach maks it easier to deal with such cases, produces much smaller and faster code

i''m not totaly against OOP, i can see, how binding data witch it''s method can be helpfull in many cases, i use it, i alsow can see how inheritance can reduce code complexity, but those are tools, that need to be used wisely

in my opinion it is much better to use full procedural/modular design for the whole program, than make it complitly oop with all the classes put into hierarchy

the original poster showed typical modular design, he has split his program to modules performing different tasks rather into objects, but this is good, he should stick with it

Share this post


Link to post
Share on other sites