Question

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.

Answer 1

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.