New Game Engine OODesign Idea

[krynstone]

There is an excellent Object Oriented Game design guide/whitepaper that I believe is really great. If I were to develop a game it would follow the guidelines setup in this guide(http://www.devmaster.net/articles/oo-game-design/). It is very well thought out and covers just about everything. It's missing coverage in only one area that I remember. Can't remember what it was that I thought was left out cause I read it 3 days ago. But it only lacked in one thing. The guide is very well done.

[Nidhogg]

It's certainly interesting at a high level. I have a couple of comments for the purposes of discussion:

While the division of virtual space from logical space is actually inevitable when developing a game, there is a certain overlap - e.g. the document would suggest that collision detection be performed within the logical space "where the work is done to make all the entity interactions occur" but in reality it can only be performed after the render process since collision detection is very much dependant on what the document describes as "form" which exists not in the logical space but the virtual space.
I'm not entirely comfortable with the separation of rendered and non-rendered objects as two separate abstract classes. I would much prefer to see a cleaner separation of data and presentation, especially coming from an MMORPG background where a fairly small subset of objects ever get "seen". To me it feels more natural to have an IRenderable interface and just have renderable objects implement it. This seems a cleaner OO approach than having an entirely separate class branch.
It would be interesting to see how the game maintains a steady refresh rate with either of the two proposed main loops. The time taken to process the "virtual" and the "logical" spaces differs from instant to instant and this has to be taken into account if the game is to run smoothly. I'm not saying the architecture couldn't support that given what I've seen of it, but it is one of those things that tends to tightly couple sub-systems within a game and hence "dirty" a nice clean architecture like the one proposed.
N

[krynstone]

Bingo!!...thats what i didn't like about it...I noticed that too. Those loops bothered the hell out of me. I did like alot of the rest of the stuff though. I have been looking into game design a lot recently and am thinking about doing some serious game programming things...mainly the game engine and architecture, hence my ramblings about all the stuff elsewhere on the forum. I've read a little on a few websites and would appreciate any more info you have on any good articles Nidhogg. You actually a coder Nid?....or just casual programmer....or neither?I'm Heading into my fourth year at Virginia Tech as a CS Major and loving all the coding

[RogerRamjet]

I Is All Like Ehhhhhhhhhhhhhhhhhhhh

[Heavyporker]

*Goes to read link* time passes....



*snrrrrkkkk*

*the thumping of his head upon the table wakes him up*


Now what the hell was this all about?!

[her.]

yea i tried the whole CS major thing at UCF...got a .6 GPA that semester...not really my cup of tea :(

[Brammers]

*Read while waiting for CD-Rom to burn*

Hmm interesting OO article, seperating a Render Object and NonRender object is a good idea.

So for say Neocron you could have two skins of two

RenderableObject: HurlerSkin
RenderableObject: DragonFlySkin

Now we know in Neocron a Hurler throw grenades at you, and a Dragon fly shoot with it's stinger, so seperating it like in this model.

NonRenderableObject:ThrowGrenades
NonRenderableObject:FireStingers

And then to get use them, your ComputerDataEntity:Hurler creates it's RenderableObject:HurlerSkin object, and NonRenderableObject:ThrowGrenades while the dragon fly creates it's RenderableObject: DragonFlySkin and NonRenderableObject:FireStingers objects.

Now if the the RenderableObject and NonRenderableObject classes were not seperated, could we easily have a Grenade Lobbing Dragon fly? :D

[ZoVoS]

and also dynamic weaponry?