I know Emmanuel Deloget from GameDev.net but I'm not sure I would choose to use the hierarchy he's got there! Too much inheritance, not enough flexibility.
If I was writing a text-based RPG (as I have done in the past) it would look a bit like this (though I've no time to draw up a diagram for it, sadly):
- Creatures, Rooms, and Items derived
from WorldEntity, with WorldEntity
objects arranged in a Composite
structure, so items can live within
other items, carried by creatures,
who exist within rooms. Implementing
the Visitor pattern for WorldEntities
might work well.
- CreatureType and ItemType classes
which contain the 'class' data for
individual Creature and Item
instances, which refer back to their
corresponding 'type' object. (eg. base
hitpoints and stats in the former,
current hitpoints and transient effects
in the latter). I might implement these as
prototypical lists of properties that get
copied to Creature or Item instances when
they are created. You can implement property
inheritance via a 'parent' property so that
a specific goblin Creature instance may relate to the
'warrior goblin' CreatureType, which contains a
parent reference to the 'generic goblin' CreatureType. And so on.
- Exits that are owned by their Room, and are
one way, and which detail the direction of
travel, various conditions of passage, etc.
- Areas, that contain groups of rooms connected
by some logical organisation.
- A Spawn class to dictate where Creature
and Item instances are created (eg. which room,
or at what coordinates), when they are created and
with what frequency, and from
which CreatureTypes and ItemTypes. You may have
some logic in here to randomise things a bit.
- Spells, skills, abilities, etc.
all derived from a base Action class
or interface that specifies prerequisites
(eg. current position, mana points, some
degree of learning of a skill, etc). Normal
commands and actions can go here too since they
often have some sort of requirements too
(eg. a 'sleep' command requires that you're not
already sleeping.)
- A FutureEvent class which is essentially a
callback that you push onto a priority queue
to execute in the future. You can use these to
schedule combat rounds, spell cool-down times,
night/day cycles, whatever you like.
- A hash/map/dictionary of name->value pairs for
player and item statistics. Not type-safe but
you'll appreciate the flexibility later. In my
experience making stats member variables is
workable but inflexible, and having specialise
'attribute' classes becomes a convoluted
nightmare when debugging.
- A Modifier type which contains a stat name
and a modifier value (eg. +10, +15%). These
get added to your creatures as they are used
(eg. through a spell effect, or by wielding
an enchanted weapon) and get stripped off later
by a timed FutureEvent or some other event such
as a command being executed.
- Game-specific classes such as PlayerClass or
PlayerRace, each of which describe a player's class
(eg. warrior, wizard, thief) or race (human, elf,
dwarf) and set starting stat values and limits,
skill availability lists, special powers, etc.
- Basic player interface classes which will vary
depending on your actual game type. You might
have a rendering classes for a graphical game, or
in a MUD you might have a Connection class
reflecting the TCP connection to the player's client.
Try to keep all game logic out of these.
- A scripting interface. Most of your commands, spells,
and creature AI can be realised more quickly with
a decent scripting interface and it keeps compile times
down too. It also allows for some great in-game debugging
and diagnostic capabilities.
That would be the basic high level structure I'd use.