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 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.
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)
- 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. =)
Menu
863
