Ten years ago as a computer science undergraduate, I took C++ programming. Since then, I've done next to nothing with it. Sadly my programming skills are still very basic, and I'm trying to fix that. I always loved single-player RPGs as a kid (Anyone remember Questron???), so I figured it might be fun to create a really simple RPG in C++ in order to get some programming experience/confidence. (Doesn't every beginner programmer make one of these?)

Anyway, I've started a text-based Roguelike RPG, and I've got the basics down: created a maze, some creatures, random encounters. Now I find that maybe I should have sat down with a pencil-and-paper and done some more concrete preliminary design, because I'm not quite sure how some elements are going to fit together elegantly.

First off, I should probably learn to use the standard template library, right? I created my own linked list template that I was pretty proud of, but every time I modify it, I feel like I'm reinventing the wheel. Presumably to be a real C++ programmer, you've got to know your way around the STL, right? Any advice on tutorials or books that might help?

Second, here's a design issue I've been struggling with. Now that I've created a character class (with the player and NPCs derived from this class), I need to start making stuff for them to carry around: weapons, armor, potions, treasures, and other goodies. I've been struggling with how to do this. I could create an 'item' class, then derive various other classes from it (weapon, potion, etc.). All of these could be put into a linked list that is the character's inventory.

But should I then derive more classes from the weapon class in order to create individual types of weapons (knife, sword, rolling pin, etc.)? To me, deriving class after class like this (are they called subclasses? child classes?) seems like it might be a programming no-no that could turn into a real mess.

I guess my question is, how would this work in a "real" game? Having played games like this since I was 8 years old, I never thought to myself, "when I pick up that sword, how does the code implement this?"

Sorry if my questions are a bit vague. I get a chance to work on this project for only a few hours a week. After being away from it for several days, stuff like this makes my brain hurt. Any advice is appreciated!

I can't really comment on your other questions, but in regards to the items->weapons->specific weapons distinctions: what does a rolling pin vs. a knife have in common? What's different between the two?

If there are specific properties that are unique to that item in particular(for example, a knife with a sharpness of 2 and a rolling pin with a bluntness of 4), then create more derived classes. If there are no differences between the two weapons, then leave them as they are - you should only be deriving classes for things that need more properties than the base class provides.

Thanks. I think you've got me thinking on the right track. Part of what I need to do is think of what virtual functions I need to use on the items in the linked list and base the base class on this... and I should base that on how I'd like the main code to handle the inventory.

Guess I just need to learn to think like a programmer. I'm trying to think high-level and then work my way down to low-level... when the low-level stuff should actually be dictating the high-level stuff. Or do I have that backwards?

Thankfully it's a slow work day and I can work this out.

Yes, I would suggest using the STL more so than your linked library unless you have some sort of heavy modification.. but if it's just the normal run of the mill linked library the STL will be faster, less error prone, and more efficient than yours (assumption on my behalf - you might be a genius and not have told us).



Yes, class inheritence is a good thing. My RPG I have been dinking with off and on over the year operates on strick inheritence.
Example you have abstract class Weapon. You know that every weapon will have:
an ID,
an attack value,
a name,
an owner,
and attack type (blunt, slice, arrow, etc)

All of these go up in your base weapon class.
Now you should break things down by type
So you have a Weapon_Blunt class that inherits from the weapon class. It set's the type variable here, and you can dump any generic blunt weapon mechanics here.
You then also create a Weapon_Slice class that does the same thing except it has all the slicing weapons specifics.

Now you can go different routes here.. Say you have a club in the game.. well if it's only one then you probably don't want to make a class for it.. but if you have fifty types of clubs then you would want to inherit the blunt class and put your club specific things there.

Inheritence outline like this:

The joys of inheritence come from if you need to make a sweeping change to all things blunt then you have direct access to that part (versus hundreds of smaller classes). My weapon system cascades through inheritence, and truth be told many of the middle classes (like at 'blunt' or 'slice') are fairly meager in size, but a litte foreplanning helps when I need access to them.

Also there is something to be said about parameters that I can define at either the weapon level or the blunt level. Everything's a weapon at some level, just the granularity of choice.

This post has been edited by modi123_1: 17 Jul, 2008 - 09:39 AM

Referring to your "STL" question, if you click that "my contributions" link under my name and look at tutorials, there's plenty of stuff there to get you started