GameObject class tree (if such a thing existst)

[ismetteren]

I am creating my game in java, but i dont think it makes much difference in this case.

I would like to know how you make you GameObject class tree... i came up with that name myself. What i mean is the tree of charactors (like you(the player), enemies, stuff)

rigth now mine looks like this:

GameObject > MovingGameObject > Ball
______________________________> bullet

(the ball it the thing you control, i think there will be two of those (2 players))

So that looks pretty logical to me... the problem is that there (so far) is no difference between Ball and Bullet, actully they are the exact same as MovingGameObject. So, is my tree an overkill, is it entirely wrong, or is it a good idea to make alot different GameObjects for the manageability ?(english is not my native language, and that word was from the dictonary... dont know if it makes sense)

Hope my class tree makes sense.

[MarauderIIC]

I'm going through posts with no responses here, dunno why this one didn't get any.

A tree implies "inheritance", which essentially says that one thing IS another thing, but it is also possible to have "encapsulation", where one thing HAS another thing. Edit: You're looking for the term "class diagram", which describes all relationships between classes. /Edit

For instance, if you were to describe some kitchen appliances in C++, you might have

Code: Select all

class Appliance {
 int wattage;
};

class Interface {
 int numberOfButtons;
 int numberOfKnobs;
};

class Microwave : public Appliance /* inheritance */{
 bool hasTurntable;
 Interface interface; //encapsulation
};

(I left out 'public' and 'private' keywords for simplicity, just assume everything is public, if you don't know what this means, don't worry about it)

Then you can do

Code: Select all

Microwave microwave;
microwave.wattage = 100;
microwave.interface.numberOfButtons = 10;

When I design classes, I write out a few of the more important classes and think about / look at what characteristics they share. If they all have an image, I might make the image itself another class and encapsulate it in other classes. Likewise, if the classes all share a certain property, I would make the properties into a 'parent' class and have the 'children' inherit from it.

If any of the English is a problem, let me know and I'll try to make it clearer.

[dandymcgee]

Very helpful explanation, I know it helped me out . Hopefully he gets the chance to return and see your reply.

[MarauderIIC]

Hope so, too. I was thinking of shooting him an email, actually.

Glad I could help you too :) As an addendum, you might see these relationships written as "IS_A" and "HAS_A", especially in databasing.