I managed (3) with an enum actually, defined as such:
Code:
enum BODYPART {
Head, // 0
Neck, // 1
Left_Arm, // 2
Right_Arm, // 3
Left_Hand, // 4
Right_Hand, // 5
Hands, // 6
Body, // 7
Waist, // 8
Legs, // 9
Feet, // 10
Left_Finger, // 11
Right_Finger, // 12
Container, // 13
Inventory, // 14
NUM_BODY_PARTS // = 15
};
Your (1) is my weakness. I have trouble defining base abstract classes. Not that I don't understand the concept or can't actually code them. But more than I do have trouble doing it the right way. Definitely I need to read more about data structures and design patterns to better understand the advantages of abstract classes.
Your (2) is great! Didn't think about it. Thanks for the tip I'm assuming you would want this implemented as a class that I could then use as a member of the base object?
Ok... now... (4).
I don't like it. Sorry
I did think of it, but managing those many members seems repetitive and maybe unecessary. I've been giving this some more thought after Qzah's, and came up with something like:
Code:
map<CItem weak_ptr, BODYPART> contents_;
Any changes to the enum would be replicated by this container without the need to change the code (much). This container would reflect a couple important properties in a much simpler way, i reckon:
. Items cannot be replicated inside the container
. Each item in the inventory is associated with a body location (with the extra pool being location 14-Inventory)
As for the rest of your post, I do want to do it like you suggest. Or at least get close enough. I've been reading about your paradigm; Mngr and client classes. Both in C++ Primer and the recently bought Addison Wesley's Design Patterns Explained. I'm still shaky in my confidence in using these methods. But I will definitely use them. This project of mine, more than a need to have a final working game, is about learning how to correctly program in C++.