Does anyone know where I can find examples of class diagrams for RP game development? Something similar to here would be quite useful. I'm not looking for things I can slavishly copy, but just for different examples that diagram various solutions to the problems I'm discovering as I try and pencil down my own classes.

I love the one you linked to. I swear most of us programmers, especially the ones with ordinary day jobs, must only do RPGs for the cathartic experience of writing functions like bool isLivingDead().
– GavinAug 5 '09 at 15:48

7 Answers
7

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's the second fantastic answer you've provided for my game related questions. Thank you
– SteerpikeAug 5 '09 at 10:55

If you were to use an MVC architecture for this game. What would the separation of the model, view and controller look like for this class structure?
– BrightIntelDuskJan 24 '15 at 21:11

@IntegrityFirst: I wouldn't use MVC so that's a question you'd have to answer yourself. But handling I/O (including graphics) depends entirely on the platform the game is being made for.
– KylotanJan 26 '15 at 9:50

You may want to consider a component entity system rather than a traditional inheritance hierarchy; they tend to be more flexible to certain types of change, make tool (e.g. world editor) development much easier, and present opportunities for parallelization that might not otherwise be obvious or easy.

Many modern game engines are moving away from the "monolithic class Object" (or class Entity, whatever) and toward a "bag of components" approach.

There are numerous books and articles around. Generally:

the Game Programming Gems series (apparently both volume 5 and 6 have component articles, and I think 2 might have had one as well)

the Game Developers Conference website often has links to presentations from prior years, and is a goldmine for this sort of thing -- you can even usually buy the CDs/DVDs for former years cheaply (especially if you attend)

Thanks, I've never heard about the component driven design before, but it looks interesting.
– James McMahonAug 6 '09 at 13:14

@nemo: thanks for the note, it was working two days ago. =( I've put his new blog link in, but it doesn't appear to have the presentation, and a note that you can still get to the presentation using google's cache.
– leanderAug 8 '09 at 18:22

Lol, it totally depends on the system you want to implement. It can be simple, but as usual, rpg systems are extremely complex. But then again, the game is not finished until you found the hackmaster+12 ;-).
– Toon KrijtheJul 31 '09 at 12:36

2

I think my main problem is that I'm not sure exactly what 'gazebo' is supposed to inherit...
– SteerpikeJul 31 '09 at 12:41

In a tabletop RPG, you can do something the designer never thought of. If you get that with a computer RPG, it won't work as you might expect. I see no way to change that in the near future.
– David ThornleyAug 3 '09 at 16:25

Yeah, the key/value concept is like another version of Greenspun's 10th Rule: almost every system ends up with it somewhere. I suggest using it for character and item properties, including the inheritance model that Steve and others talk about.
– KylotanAug 6 '09 at 14:27