Classes

Quote:

Original post by SEEPlusplus{/i] I am creating a texted based RPG. I have a base class (cItems) which stores a linked list of items with functions to Add, Delete and Search and each item has a unique ID. I have a derived class called cCharacter , which organises the main character, Health, Mana, Strength etc, it also has details of what the character is carrying (An ID number corresponding to an Item in cItems). When requiring information on character inventory I would use Search(ID Number from character inventory). My first question is, will each of the instances of cCharacter eg Player and Monster1 use the same Item list or will each have a copy of there own Item list.

As you describe it, you have this organisation:

• cItems -> list of items (similar to a std::map


• cCharacter
  • health, stamina, ...
  
  
  • list of itemId

I may be wrong, but to me it seems that you have only one real item list - thus it will be shared by all your cCharacter instances.
This is not how I'd do it. I'd rather prefer to have a full blown Inventory class instance in the Character class (the Inventory class is essentially a list of itemObj, not a list of itemId). This way, each creature has its own inventory and I don't have to maintain a separate (and possibly huge) list of items.

Quote:

Original post by SEEPlusplus{/i] I will also want to implement a cRoom class, which reads in data from file for each room, which will need to access the Item class and the Character class also.My second question, where would the cRoom class be best placed? Comments would be appreciated , Andy

Well, I'd put it in my project tree [smile]. More seriously, I don't fully understand the question. It seems that you have the dependencies right (Room known Character and Item). What's the problem here?

Regards,

I've been having a similar problem on various projects and I think the solution lies with the answer to another problem - who controls objects in the game?

An example of a control problem is this - an item can be carried by a character so that cCharacter needs to know about cItem, but an item can manipulate the statistics of a character when used so cItem needs to also know about cCharacter!!! This kind of reliance upon each other is difficult to achieve, forward declaration or double dispatch are two viable answers but I think in your case a better solution would be to think of characters and items as containers for data and a controller class that manipulates the variables contained within the game objects.

Of course, a more OOP design would allow objects to control themselves but when you add rooms into the equation it becomes more difficult. A room could just contain a list of objects but what if NPC's want to move between rooms, they would need some info about the room which would again create an inter-dependency. However, if a controller was responsible for moving creatures then that controller could know about rooms and creatures and items and traps and whatever else equally easily and manipulate those objects itself.

So, in answer to your problem, my personal preference at the moment is to add a room class as a container for data and have a controller class control the data stored within. If you decide that your objects will need to update themselves then controller classes will be of nominal interest to you.

Thanks ED for comments,

You are right i have one huge list of items, the idea is that i would be able to manage items better this way, all i would then need in the characters inventory list is a lookup. The cItem class could hold all details of items and remove duplicates and other managment thingies.

As regards to the Room saga, I think the game would be running of the Room class, description of room, Id of room, pointers to characters in room (obviously main character will always be in room (using character class)) and ID's to Items in room (using item class). Does this sound reasonable.

I am also thinking of creating a list of monsters (just like items class) so each room instead of having pointers to character instances will have a list of ID's of monsters in room. A room then will have its own uniquie ID number, description, list ID of items, list ID of monsters, a list of choices and their corresponding room ID numbers.

Again does this make sense. The problem is i can see it in my head but i can not get it onto paper.

Any comments? Andy.

Thanks Furiousuk,

I have had various issues myself with this conundrum for some time now and wanted some kind of feedback, of which, yours is appreciated.

As you say the communication between classes of the same level can be a pain to organise. Anyhow in my description of the layout of the classes so far i have:-

Item \
Monsters - Room
Character /

As you can see in this example the base class room can read data from derived classes but derived classes cannot read from each other.

e.g The room will be able to lookup Monsters, Items and Characters but Monsters and character could not lookup items.

I need a way of organising these classes to use all data interchangabley.

Driving me mad, any help? Andy.

0) Items, Characters and Monsters are not kinds of Rooms: rather, a Room is a container for those things.

So the setup we want looks something like:

1) Containers contain their contained things (duh).

2) Contained things should know about their container. To check "siblings", a contained thing talks to its container. Thus, each "thing" interface described below implies a reference to another object implementing "container-of-thing".

3) A room can contain both "nonliving things" and "living things". It therefore implements "container of nonliving things" and "container of living things".

4) Characters and Monsters are both kinds of Creature. Creature implements "living thing", and also can contain "nonliving things". It therefore implements "container of nonliving things" and "living thing".

5) Items implement "nonliving thing".

Quote:

Original post by Zahlman 0) Items, Characters and Monsters are not kinds of Rooms: rather, a Room is a container for those things. So the setup we want looks something like: 1) Containers contain their contained things (duh). 2) Contained things should know about their container. To check "siblings", a contained thing talks to its container. Thus, each "thing" interface described below implies a reference to another object implementing "container-of-thing". 3) A room can contain both "nonliving things" and "living things". It therefore implements "container of nonliving things" and "container of living things". 4) Characters and Monsters are both kinds of Creature. Creature implements "living thing", and also can contain "nonliving things". It therefore implements "container of nonliving things" and "living thing". 5) Items implement "nonliving thing".

On a not so serious note, don't forget to make the copy constructor to turn a living thing into a nonliving thing when they die! Gotta be able to perform actions on corpses, which certainly are not alive!

However, Zahlman's representation of the game architecture is sound. Rooms are basically the "world" they are the stage or the setting for the game, without which, you have no game, just like without a stage, you have no play (arguably). So our "rooms" must contain all other things, specifically though, only those objects that lie within the room itself. Rooms must also contain information about other rooms that they are connected to [i.e. exits]. Objects (props) and Characters (actors) will also need to know which room they are in, something as simple as an integer value that corresponds to the room's unique identification number. This will be important for things like allowing characters to manipulate and perform actions on items and other characters in the same room as them.

My suggestion is that instead of trying to find out a viable way to do this, use the experience that is out there. Download a decent free mudlib, and get alot for free. Circular dependencies and other pitfalls in these designs have been studied over and over by the mud community, and there are several pretty clever solutions.