Class diagram examples for RPG (Role Playing Game)

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

<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>

Answer 2

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

Answer 3

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.

Answer 4

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)
• Gamasutra's feature article archives and the Game Developer Magazine backissues

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

• Evolve Your Hierarchy, Mick West
• Entity Systems are the future of MMOG development; also part 2 and part 3
• Introduction to Dungeon Siege Architecture on the Gas Powered Games wiki
• A Data-Driven Game Object System, Scott Bilas (GDC 2002) (should reappear here at some point, but you can use google cache to get to the original page)
• the Nocturnal Initiative, a openly-licensed collection of libraries and tools from Insomniac Games (they have one of the biggest tool efforts in the industry, from what I've seen)

Each of these articles links to a few more.

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

Answer 5

This is a simplified interpretation of what I'm using in my roguelike right now (Just listing the names and their variables):

GameObject
-location (NSPoint)
-isPassable (bool)
-beenSeen (bool)
//Everything that is in the game will have these basic attributes
//beenSeen is used to "remember" things outside the current FOV

Wall : GameObject
//nothing extra variable-wise, but it will have it's own draw function
//and it's own init that would set the isPassable and beenSeen to NO

Floor : GameObject

Door : GameObject
-isLocked (int)
-integrity (int)
-isOpen (bool)
//isLocked is an int, with 0 being unlocked, higher levels would require more skill
//integrity would determine if you could kick the door down or not

GameCharacter : GameObject
-health (int)
-sightRadius (int)
-inventory (NSMutableArray)
-inventoryValue (int)
-inventoryWeight (float)
//everything else is up to you for this, there are many stat systems
//each with their own pros and cons

Player : GameCharacter
-steps (int)
//Forgot this the first time through, this is important

Monster : GameCharacter
//you might put AI specific things here

Skeleton : Monster

Item : GameObject
-value (int)
-weight (float)
//everything else is specific to what the item is
//weapons, potions, ammo, etc

Gold : Item
//example
//value = 1
//weight = 0.1

Container : Item
-contents (NSMutableArray)
-contentsValue (int)
-contentsWeight (float)
-capacity (float)
-isLocked (int)
//capacity would use the weight, but that could get silly
//maybe add size to items as well? it's up to you!

I've left quite a bit out, but once you have the foundation down everything else should fall into place.

I noticed after the fact that I put used integrity twice, maybe you could set it in GameObject and have -1 be invincible or something. It's up to you.

Don't sit there and make 9,000 classes. You will never finish it and will only get mad when you change one thing that mucks the rest of everything up. Just code exactly what you need, and as you add features and expand on it, you will see what will need to be changed/implemented, and refactor from there. You will most likely be learning a lot in between these refactorings, and will look back at old code and wonder what the hell you were thinking.

What's up with 6 upvotes on the guy that wrote name out twice? Where are the locations being stored? Asking for headaches later on. If you wanted to put a name in, it would obviously go under GameObject, same for description. I'm not that far along in mine by any means, and I personally think that naming things from the get-go is a perfect example of one of the things NOT to do from the start, as you'll spend too much time on them, and they do nothing. Focus on getting things working right first, then spend your time naming things and adding descriptions.

Focus on getting things working right first. It doesn't have to be pretty. That might seem like the fun part, but if nothing works all your names are useless. I repeated this because it's very common to try and lay everything out from the very start, and it will burn you out. You are going to run into a lot of things you weren't expecting. Like a very large majority of people here, you have probably played a lot of RPG games, and are familiar with them. It might seem "obvious" and "make sense" to lay things out certain ways from the beginning, but as you go deeper into this beast (cave, dungeon, castle, hole, etc.), you will find that sometimes the way that makes sense in your head from your experience of playing the games will not make ANY sense from a coding standpoint.

Stick to it, don't start a billion projects, stick to it, you can make it pretty later. You'll come out of this with a much higher appreciation for game programmers.

Try not to talk about it too much, either. I've found that saps all the motivation out of me some days, just sitting there talking about everything you want to do. You finally get to the computer, open up XCode, and you don't feel like touching it. Seems hypocritical of me to say this after laying all that out, and it is. Sometimes you can't help it.

Don't be quick to come here and ask either, do original research, look through documentation. I'm not saying this to be mean, but everything you will want to ask has been done before and somebody has probably blogged about it. If you aren't sure if something will work or not, try it anyways, you'll learn something. It's not about trying not to make mistakes, it's about making as many mistakes as you can (within reason).

Sorry for the novel.

Answer 6

A very different approach by Steve Yegge.

Answer 7

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