Am I an OOP whore?
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]
base classes are only a small part of OOP. their inheritance hierarchy is the real meat...
<-- smile :-)
Project-X
<-- smile :-)
Project-X
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.
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.
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...
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.
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
Faith. n. Belief without evidence in what is told by one who speaks without knowledge, of things without parallel. -- Ambrose Bierce
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 ...
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 ...
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
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
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.
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
You have a good start
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement