29

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.

James McMahon
  • 48,506
  • 64
  • 207
  • 283
Steerpike
  • 17,163
  • 8
  • 39
  • 53
  • 8
    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()`. – Gavin Aug 05 '09 at 15:48
  • 3
    if (creature.isLivingDead() && hero.isSlayer()) hero.slay(creature); – James McMahon Aug 06 '09 at 13:05

7 Answers7

52

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.

Kylotan
  • 18,290
  • 7
  • 46
  • 74
  • That's the second fantastic answer you've provided for my game related questions. Thank you – Steerpike Aug 05 '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? – BrightIntelDusk Jan 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. – Kylotan Jan 26 '15 at 09:50
11

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:

Specifically (some noteworthy ones, google "component" and "entity" in various combinations for more):

Each of these articles links to a few more.

Try the kool-aid, you might like it. =)

leander
  • 8,527
  • 1
  • 30
  • 43
  • Thanks, I've never heard about the component driven design before, but it looks interesting. – James McMahon Aug 06 '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. – leander Aug 08 '09 at 18:22
5
<tongue_in_cheek_mode_because_it_is_friday>

Just to start:

          ----------------                    --------------
          |   Creature   |                    |  Item      |
          |--------------|                    |------------|
          | Name         |                    | Name       |
          | Hp           |                    | Value      |
          | Abilities    |--------------------| Weight     |
          |--------------|                    --------------
          | Attack       |
          ----------------
                 ^
                 |
        ----------------------
        |                    |
----------------    ----------------
|  Hero        |    |  Monster     |
|--------------|    |--------------|
| Level        |    |              |
|--------------|    |--------------|
| KillMonster  |    | AttackAndDie |
| GrabTreasure |    | DropTreasure |
----------------    ----------------

</tongue_in_cheek_mode_because_it_is_friday>
Toon Krijthe
  • 52,876
  • 38
  • 145
  • 202
  • It does look startlingly familiar to my own design I have to admit :) – Steerpike Jul 31 '09 at 12:33
  • 1
    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 Krijthe Jul 31 '09 at 12:36
  • 2
    I think my main problem is that I'm not sure exactly what 'gazebo' is supposed to inherit... – Steerpike Jul 31 '09 at 12:41
  • Great stuff and startlingly close to most RPG code I've seen ;) – zebrabox Jul 31 '09 at 12:48
  • two types of RPGs out there - one type mimics the simplicity of paper and pencil RPGs, and the other type uses the benefit of the computer doing all the rolling to make some complex monstrosity which implemented in P&P the die rolling would mimic the sound of hail. – quillbreaker Jul 31 '09 at 16:55
  • 1
    Call me old fashioned, but I still prefer tabletop rpg ;-). – Toon Krijthe Jul 31 '09 at 19:23
  • 2
    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 Thornley Aug 03 '09 at 16:25
  • 1
    @Steerpike: Obviously, Gazebo should inherit from ReallyScaryThingThatWakesUpAndEatsYou. – kyoryu Aug 06 '09 at 06:57
4

How about something of the sort :

alt text http://img217.imageshack.us/img217/4886/classwo0.png

Here are some other diagrams:

Andreas Grech
  • 105,982
  • 98
  • 297
  • 360
4

A very different approach by Steve Yegge.

h0b0
  • 1,802
  • 1
  • 25
  • 44
  • 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. – Kylotan Aug 06 '09 at 14:27
3

Look at JADE's Javadoc for a good overview of a complex game :)

changelog
  • 4,646
  • 4
  • 35
  • 62
1

Be bold, your game shouldn't be a clone of hack and slash nonsense. Your actors should be able to switch sides, take their own initiative enlist other actors, etc. Otherwise, whats the point?

   +-----------------------------+
   V                             |
[Actor] ------- [Allegiance] ----+
 - risk comfort    - weight
 - temerity
Justin
  • 4,437
  • 6
  • 32
  • 52
  • 1
    That's much further down the line. No matter what you do, you're still going to need a system like the ones above to classify all of these actors and the required AI. – Sneakyness Aug 07 '09 at 04:42