Hello all! I am currently working on a technical design for an RPG. I want to be able to design the program in such a way that it will be easy to separate the pieces so that a few programmers can work on separate modules at once. We''re going ot be using C++, choosing it over C mainly because of the data abstraction capablities. I''m not that interested in OOP for this game, as I don''t think using dynamic binding and having a huge amount of esensibility is important for a game porject like this.. I could be wrong though. Anyways, my probelms arise from the C++ implemenation of data abstraction, basically the clas hierarchy. I want the game to be separated into easy modules, yet not have to have any ugly coding take place. So far, I have the GAme split up as follows: (It''s hard to show without a chart) GAME: Interface Game World INTERFACE: Screens (like windows or overlays) Input Output INPUT: Mouse Keybaord OUTPUT: Audio Display GAME WORLD: Story Game Rules Maps Items Time STORY: Scripts Characters CHARACTERS: AI RULES: Combat Magic Stats Items Misc. MAPS: World Map Local Map It would take me too long to write out all of the classes but that is basically a pseudo code breakdown of the parts of the game. Obviously there needs to be a further breakdown of some of the classes, etc. Ok, I guess my question is, what would be the best way to go about using Inheritance between the various classes. Also, how can I make it so that the classes can interfgace easily. For example, if a funcion in the character class has to have access to the map data, is it better to use friend classes, an inheritance scheme, or simply to pass a Reference to a map object when calling that function? Any input on how to lay out the program structure logically would be greatly appreciated. I know it seems like a simple question, but I have been thiking about it for a few days, and making progress, but I just thought I would ask for input Thanks in advance Kevin

inheritance should only be used when you are certain it is the best way to go. It is very overrated.

If you''re not interested in OOP/OOD, why are you even talking about inhereitence?

My modules go something like this:
Logic Engine (Script Compiler/Executor)
Data Engine (Storage&Retrieval)
User Interface (Need Requirements)
Input Engine (Runtime Bindings)
3D Graphics Engine (Rendering)
Network Engine (Event Communication)
2D Graphics Engine (Billboarding/Windows)
Physics Engine (E=mc²)
3Dfx Audio Engine (3D 5.1 Playback)
Music Engine (mp3/midi/Fade-in&out/3D?)
Content Creation Tools (Importers/Exporters & Testbed)
Menu System (Choose Wisely
Configuration System (Twiddle Hardware
Settings, uses menusys)
Online Help System (uses menusys)


If you want to learn about using inherietence effectly read "Design Patterns" by Erich Gamma & etc. al.

Magmai Kai Holmlor
- The disgruntled & disillusioned

Alright thanks a lot for the tips guys. I was thinking of breaking my modules into something like that. Then I wondered if a more logical class tree approach would work.. Maybe it''s not the best solution.

The reason I talk about inheritance is because inheritance really isnt a feature of OOP. Multiple inheritance and dynamic binding (linking) are what really defines OOP. I don''t really see a need for that in my game engine.

However, the question of inheritance does crop up in a few of my class structures. Whether it is better to use a base class and then expand on these classes using inherited classes. For example, in the Game World you can have rules. Now rules can be broken down into combat rules, magic rules, character stat rules, item rules, and miscellaneous rules. In that case would it be better to have a class GameRules and then have subclasses called GameCombatRules, etc... derived from this class?

Maybe inheritance isn''t even an issue. I''m just trying to get people''s opinion on whether or not a class tree like I have mentioned holds any merit in creating a game such as this, or should I just use the old modular approach that you spoke of.

Thanks again guys

Kevin

Ok, so now that I think about it, inheritance is a feature of OOP, but usually when combined with dynamic binding. I guess my problem is that I usually only use inheritance to allow for a better hierarchial(???) structure in my programs. Maybe I''m just not enough of a C++ guru to know the proper usage for this type of thing in a game program.

I guess if I knew everything I wouldn''t be asking you guys for help ;o)

Thanks, just didn''t wanna sound like too much of a jack ass on that last post.

Kevin

uhmmm...multiple inheritance defines OOP?

I meant in the context of C++. Sorry inheritance is a part of OOP I just coneeded that ;oP Anyways, read my original post... this is supposed to be about something else!

Thanks though hehe

Kevin

At the high level like you are showing it there doesn''t seem to be alot of cases where inheritance is called for. The one obvious choice is to have a base class for Local Map and World Map, since there would most likely be alot of similar code in those.

Base classes really help you to keep from rewriting or copying the same code over and over.

The Rules might benefit from it. Have a base class CRulesDefinition and then derive all the rules types from it.

In the screens area you absolutely should use base classes. It would be silly to keep replicating common screen code to all the different screen classes. But those are mostly implementation dependent. I mean you are doing the class and you think "This looks alot like xxx class" and then you join them in a common base class.

It''s really not that difficult a concept. Sounds like you have been reading too many C++ theory books &ltgrin>

Douglas Sutherland

Yeah you are probably right, maybe I have been too worried about C++ theory. The problem is I am trying to plan everything out before I start coding, which isn''t really a problem, but it means I have to decide which classes are simliar before I start.

I pretty much know where I should use inheritance for my program, in places like you suggested. I had a base map class and a base rule class, and then derived specialized classes from there.

I think I am ok there, my problem really lies with the data abstraction aspect. I want things to be elegant and split into easy modules without having to use horrible looking code to get what I need. For example, let''s say I have the following.

class GameStory {

GameCharacter mHero;
GameScript mScripts[MAX_SCRIPTS];
.
.
.
};

class GameCharacter {

GameCharacterAI mCharacterAI;
.
.
.
};

class GameCharacterAI {

who knows
.
.
};

NOW! Haven given you that class tree, or small sample from it, what happens if class GameChracterAI needs to know something about the script. Or if class GameCharacter needs to know the same thing. They aren''t derived from class GamScript, mearly, they are data objects in this class. How can you use classes in this way to keep things neat and tidy, yet still have access to the data that you need? I''m sure I could do it by passing referencs to classes or at least references to class data, but is there a simpler way?

Also, say for example there is another class GameMap, which isn''t related to class GameCharacter at all, the have no connection. In this case I realize you have to pass references to the class members if you want to be able to access them. For example, if you were wrote a fucntion in class GameCharacter that needed to know things about the map you could do the following

void GameCharacter::Walk ( GameMap &mymap )
{

do something with mymap;


};

Is that the only way to do things or is there a better way?

Thanks for reading this and giving me your opinions guys.

Kevin

For one, you aren't showing inheritance, but a member-of relationship.

It should be like this instead

class GameCharacterAI : public GameCharacter
{
};

class GameCharacter
{
};

That way GameCharacterAI derives from GameCharacter, and has access to everthing there directly.

About the data abstraction, you're right - C++ does impose a few more problems accessing data than you have if you use global C data. The whole idea is that data is pushed down into a class and made private, so the whole world doesn't know about it. You add access functions or operations to the class, and then the whole world can use those to get what they need.

You can make all your class objects global, and then they can see each other and call each other's member functions with no problem, but it still rubs people the wrong way that they have to call functions to get data instead of just getting it. There are many ways around that, depending on how sneaky you want to get.

You can have a function that just returns a reference or a pointer to a block of data inside the class (bad design but people do it anyway)

byte* GameCharacter::GetCharacterData(void);

you can also go crazy with friend classes and let everything be friends of the class with the data and get it directly that way (I've seen this one alot actually)

Another way of course is to leave blocks of data as global c-style data. In D3d programming you will see this one ALOT. There are classes to act on the data but the actual arrays of objects and vertexes are just global arrays.

Hope this helps

Doug Sutherland








Edited by - DSutherland on May 20, 2001 7:26:45 PM