OOP insanity

[Super Bakemono]

I have no OOP design skillz. Check the object structure of my rpg engine out('[]' denotes(am I using that right?) an array):

o Universe
o Party
o Character[]
o Scene[]
o Map
o Entity[]


I guess that's all fine and dandy(shut it braddo!!!) Answer this: when I go to render all the graphics, what should I call? I could have a 'Universe::render().' Is that the best solution? More questions to come soon.

[Strike]

I don't know if a Universe object would really be well-suited for this. I mean, it would just be a container for all of your variables, reallly. Though I suppose you could associate methods like draw() with it that provide convenient wrapper routines that are applied across all objects. That could be useful.

But, here's how I understand most games work when it comes to rendering. Generally there is a linked list that contains pointers to the objects that are to be drawn. And generally these objects are all derived from one big base class (for example, Object), and they have virtual methods for those global routines like draw() or maybe something like isVisible(). So, they simply walk the list and call the appropriate function after derferencing the pointer.

So, what I'm getting at is that you might consider things even more abstractly and consider using a big base class from which all objects in the universe derive.

[Super Bakemono]

Hmm

[Super Bakemono]

Then what functions should register the graphics and how should they be called? Please forgive my OOP stupidity...

[Strike]

I mean, it all depends upon your framework and what you need to happen. I don't know when you need to do what in your programs, so it's not really up to me to answer those questions. Perhaps look at a game SDK. I've toyed with the Half-Life SDK, and that is what gave me some of the ideas I mentioned above. It's free to download.

[nanode]

They very general benefit to using OOP in this circumstance is for generic and reusable code.

Strike is right on about base classes. Consider having a BasicDrawableOject (call it whatever) which has all the core methods you'll need. Perhaps: render(), draw(), setLocation(), refresh() etc.

Whatever extends (subclass) that base class, can override those core methods to suit particular needs to that ojbect, as well as the corresponding super method.

This sort of design works really well when you are iterating through a set of various object types and you want to programmatically do something (like render them graphically).

[Super Bakemono]

Ok, I think I got all this under control, but expect more questions...