Hello Alright here is my problem. I''m currently working on a 3D RTS game. I have a model class which loads, animates and renders some particular model file format. Anyway I thought that for absolutely any object in the game (from trees to units to buildings), i''ll make an ''Object'' class which would inherit properties from the model class. Now my problem is I don''t know wheather i should use inheritence (ie tObject : public tModel) or simply make a pointer to the model class in my Object class. I have always gone with the second way but is there an advantage to either method? i could think of one and that was if i made a pointer to the model class i could make a list of models instead of one, or forexample make a list of sprites for an object. My second question is, how general should my classes get? let me try to clarify: I might have my model class. The object class will inherit the model class. the Unit class will inherit the Object class. And finally the Soldier class will inherit the Unit class. Now if what i said made any sense, and we trid to do something similar for every unit in the game, wouldn''t there, at the end, be a giant network of classes, and hundereds of pages of code defining the functions for each of these classes? Is that what a finished games'' code looks like? or should i try to make more ''general'' classes which would take into acount several units in the game? Does scripting somehow come ine place here? I''m sorry for asking so many dumb questions, but i really don''t wanna continue coding and then realize i have to restructure my entire code

quote:

---

Original post by Poya

Now my problem is I don''t know wheather i should use inheritence (ie tObject : public tModel) or simply make a pointer to the model class in my Object class.

---

Think of it this way. If class B is a class A, use inheritence. If class B has a class A, use a pointer.

Why do you use the word ''Object''?
It has no semantics (in other words: its meaningless).

Everything is an object.

If you talk about an object in a world then call it ''WorldObject'' or something.

quote:

---

My second question is, how general should my classes get? let me try to clarify: I might have my model class. The object class will inherit the model class. the Unit class will inherit the Object class. And finally the Soldier class will inherit the Unit class. Now if what i said made any sense, and we trid to do something similar for every unit in the game, wouldn''t there, at the end, be a giant network of classes, and hundereds of pages of code defining the functions for each of these classes? Is that what a finished games'' code looks like? or should i try to make more ''general'' classes which would take into acount several units in the game?

---

Yes, putting all functionality into one class is the way to go.
Your class ''Unit'' could parse the following file:
- footsoldier def: type=land,speed=1,gun=m16,special=none
- medic def: type=land,speed=1,gun=heal,special=build_hospital
- tank def: type=land,speed=10,gun=40mm,special=none
- mobile_construction_yard def: type=land,speed=2,gun=none,special=deploy_base
- b2_stealth def: type=air,speed=25,gun=atomic_bomb,special=stealth
and then allow these units to be created in the game.
This may lead to a slightly cluttered class, but it is the easiest way to add new units and weapons.

---

ALL YOUR BASE ARE BELONG TO US
INTEL INSIDE: The worlds most widely used warning label.

Prefer composition.

In other words, if it''s a choice between IS-A or HAS-A (inheritence or pointers), unless there is a compelling reason to do otherwise, use pointers. Or references. Or values. Or whatever works, really

--
Get a stripper on your desktop!

quote:

---

Original post by Poya

Now my problem is I don''t know wheather i should use inheritence (ie tObject : public tModel) or simply make a pointer to the model class in my Object class. I have always gone with the second way but is there an advantage to either method? i could think of one and that was if i made a pointer to the model class i could make a list of models instead of one, or forexample make a list of sprites for an object.

---

One very good reason for using a pointer to your tModel class: NEVER mix game logic and graphics in one class. For instance, what say you later create a client/server architecture for your game. You''re gonna want all logic on the server side, but if your tObject class is ALSO a graphics class, then you run into problems.

quote:

---

Original post by Countach

Yes, putting all functionality into one class is the way to go.
Your class ''Unit'' could parse the following file:
- footsoldier def: type=land,speed=1,gun=m16,special=none
- medic def: type=land,speed=1,gun=heal,special=build_hospital
- tank def: type=land,speed=10,gun=40mm,special=none
- mobile_construction_yard def: type=land,speed=2,gun=none,special=deploy_base
- b2_stealth def: type=air,speed=25,gun=atomic_bomb,special=stealth
and then allow these units to be created in the game.
This may lead to a slightly cluttered class, but it is the easiest way to add new units and weapons.

---

Unfortunately I have to disagree here. This is where polymorphism really shines. Keep the sperate derived classes idea that you are using now.

There are too many problems with putting everything into one large class. For instance, most of your objects will act differently from each other, so now you are going to have big switch statements in almost every function for all unit specific code. If you have 100''s of units you are talking about 100 case switch statements in MANY different functions. This is MUCH slower than vtables when using virtual functions, and is EXACTLY what OOP was created to solve.

Beside the speed loss it''ll make changing/deleting specific units a pain. You think it would be bad having 100 seperate unit classes? Think of how bad it would be when they are all combined into one super class. Your one class would be absolutely HUGE. If you want to change/delete one specific unit you''d have to search every single switch statement to find your specific units code, etc.

Now think about it from a users perspective. Wouldn''t it be nice to allow users to create new unit types without having to give them your source code? Using a pluggable factory pattern you could allow users to just create new unit classes based of off your tUnit class and putting then into a DLL that your game would look for and load. You can''t do this if everything has to be in the same class.

The reasons for using seperate classes go on and on...


- Houdini