Component-based design of RPGs

[RenjiKage]

Two weeks ago I read about John Kirk's RPG Design patterns. I downloaded the book, read it and was very excited. As a student of computer science, focused on software engineering, and a hobby game designer, it makes perfectly sense to me to transfer knowledge from the software engineering domain to the RPG design domain. So I thought about how to contribute to this... Then I remembered a lecture about component-based software design I heard one year ago. Thus, I got the idea to transfer this to the RPG design domain.

So, here I am! I have a first prototype of a component-based approach. I divide the game into different kind of modules. These modules might expose interfaces (they don't have to) to show that only a certain part of the module is involved in dependency relations. Last but not least, there are dependencies. They show which modules are dependent from which parts of other modules.
Let me explain my notation:

This is a concrete module. Yeah, it's just a box with the module's name in it. This represents any game module that you can play with. Of course, you need all modules on which this one depends for playing.
Examples: core rules, medieval setting, utopic setting, telepathy rules,...


This is an abstract module. It's a dotted box with the module's name in it. This represents any generic rule sets you can derive concrete modules from.
Example: Your game consists of a core rule book and you want to have different settings. You write a set of rules and guidelines that each setting must contain and respect. Congratulations! You just have created an abstract module.


This is a set of modules. This is just an easier way to express that some modules have the same basic meaning and the same dependencies.
Example: Take the last example. You created an abstract setting module. Now you can add a set of derived modules to your diagram (to represent all possible settings for your system).


This is an interface. It's a part of a module which is exposed explicitly to other modules. You don't have to use interfaces, but they show you exactly on which part of your module other modules depend. This is crucial if you want to change some parts of, say, the core rules!


Last but not least, the dependencies. These arrows go from one to another module and show that one module depends on another.

I think it's time for a bigger example:

This diagram shows you how you can use the component-based technique. You see that there is one core rule module which exposes its conflict resolution mechanism and its rules concerning skills explicitly to other modules. Now there is an abstract module which defines how rules concerning any kind of magic have to look like. This module adds magic conflict resolution to the core rules and extends the skills by defining magic spells. So it depends clearly on the two interfaces of the core rules. Right below the abstract module, there is a set of derived magic rules. Each of them can look totally different, but all of them are based on the core rule's conflict resolution mechanism and define magic spells as skills in the sense of the core rules. This way, you are free to use any combination of magic rules for your actual games. Finally, there is a set of modules that represents different settings. All settings depend on the core rule's skill subsystem because they introduce setting specific skills to the game. There can also be some kind of magic in the settings, but the settings must allow any kind of magic. That's why the settings only depend on the abstract module, not on the set of derivations.

The advantages of this approach are:

• Better overview of the whole system: You can just see how all of your parts fit together. You get the big picture!
• Traceability of dependencies: You can see where you have dependencies in your RPG. You can also see which effect a change to a module has by looking at its dependencies

Finally, I want to tell you how to use this one with John Kirk's Design Patterns. You can put your pattern diagrams into the modules and expose certain gauges or patterns via interfaces to others. So if you want to add a gauge etc., you can see exactly if some dependent modules are affected. If you design your game with John's pattern approach and my component-based design approach before you write the rule text, you can possibly detect flaws and critical (= nearly unchangeable once released) rules in your game.

I hope this is a help for somebody out there. Excuse the big pictures, but it was my first try with OpenOffice 2 and Draw...
If you want to have a template for producing your own diagrams:
http://renjikage.living-galaxy.de/theforge/Komponentenbasiertes%20RPG-Design.odg (OpenOffice 2.0)
http://renjikage.living-galaxy.de/theforge/Komponentenbasiertes%20RPG-Design.sxd (OpenOffice 1.1.x)
(Although the filenames are in German, everything inside is in English)

[John Kirk]

RanjiKage,

Two weeks ago I read about John Kirk's RPG Design patterns. I downloaded the book, read it and was very excited. As a student of computer science, focused on software engineering, and a hobby game designer, it makes perfectly sense to me to transfer knowledge from the software engineering domain to the RPG design domain. So I thought about how to contribute to this... Then I remembered a lecture about component-based software design I heard one year ago. Thus, I got the idea to transfer this to the RPG design domain.

That is an excellent idea.  Component-oriented design techniques can be extremely helpful, especially in designing RPG's that span several books.  (Components are a means of implementing the Loose Coupling design pattern.)  Legendary Quest, for example, is heavily influenced by both object-oriented and component-oriented software concepts.

Can I recommend, though, that we start with UML (Unified Modeling Language) and modify that diagramming technique to suit RPG design needs rather than starting from scratch?  UML is very widely known (at least in software circles) and very well thought out. In fact, I see that your technique takes a number of ideas from from UML dependency and class diagrams.  If we start with UML, I expect that most of the RPG component diagramming needs will be a subset of that technique.

For those that don't know UML, it is actually a collection of diagramming techniques.  It includes use-case diagrams, class diagrams, dependency diagrams, sequence diagrams, and others.  (It does not include anything like a gauge diagram, though, which is why I came up with my own technique for that.)  Each of these types of diagrams focuses on a specific view of a software system.  In that way, key concepts can be highlighted while abstracting away unrelated details.

A number of people have made suggestions about modifying and/or enhancing the diagramming technique I introduced in my book.  I have been keeping track of these suggestions and have added UML to that proposal.  You can download the current version of that document here.   The addition of UML component and dependency diagrams spans pages 2-4 in that document.  (Note that I am giving the name "UML component diagram" to what is generally referred to as a "UML class diagram" because "class" is already a defined term of art in RPG circles.)  For another example, please note that the sample diagram in the Loose Coupling design pattern is an example of a UML Dependency Diagram.

[RenjiKage]

Using UML is an excellent idea. I should have though of that myself. I read your document and it is very, very good (and helps me a LOT for my game). The only thing I didn't understand was the second gauge diagram on the first page.

I see that you already thought of a lot of things by yourself. You have even done what I intended to do (it seems to me like that after having read your proposal pdf). But I still want to contribute since I think these ideas and thoughts will be very useful for many rpg designers.

So, how can I help you?

[John Kirk]

The only thing I didn't understand was the second gauge diagram on the first page.

That notation is intended to let a diagram distinguish between a set and the individual gauges contained within it.  The "element of" symbol indicates a gauge is an element of a set and that relationships pointing to it effectively point to the elements of the set.  For example, a relationship pointing to a skill might indicate it raises its rank and this notation allows the diagrammer to illustrate this relationship even though the skill is contained within a set.  A relationship pointing to the set directly, though, can influence the set itself.  So, a resource could be spent that buys a new skill and thereby increases the number of elements in the set.

So, how can I help you?

You already are.  When you have good ideas (like the ones above), tell us about them.  The diagramming technique is already much improved over what is presented  in the book.  This is largely attributable to all of the wonderful feedback I have been receiving.  In case you weren't aware of it, there is another thread discussing the diagramming technique here. I'd be interested in hearing your opinion on those suggestions as well.  For example, if you have a better idea on how to represent the "element of" relationship between a gauge and its containing set, please voice it.

[RenjiKage]

You already are.  When you have good ideas (like the ones above), tell us about them.  The diagramming technique is already much improved over what is presented  in the book.  This is largely attributable to all of the wonderful feedback I have been receiving.  In case you weren't aware of it, there is another thread discussing the diagramming technique here. I'd be interested in hearing your opinion on those suggestions as well.  For example, if you have a better idea on how to represent the "element of" relationship between a gauge and its containing set, please voice it.

Thank you. I read the other topic and your 4th proposal for changes (I'll soon post my opinion there). I want to use this thread to delve a little bit more into component-based design and diagram techniques.

I think we should consider introducing abstract components and derivations. Furthermore, how about packages?
Look at thisthis UML diagram, please:

As you can see, the "magic (generic rules & guidelines)" component is abstract. It is a collection of generic rules and guidelines to "implement" a magic core rule book (I don't know a good name for this in English - my German terminology is so different from yours...). So, i.e. the abstract component has some rules:

• There is magic energy and it has to be quantified. Magic energy is used to cast spells. This asserts the existence of a gauge that represents the character's magic energy. It has to be a filled circle.
• Magic spells are skills with respect to the core rules of game XYZ. This defines the representation of magic spells and their relations to other gauges (like "skills").

This is especially useful if you want to have different kinds of magic rules that share basic rules. So you can play your game with any of the derived / realized / implemented components.

The package notation ought to group different components with the same relations. In my example above, each magic component depends on the same abstract magic component. So they can be put into the same package.

It is very diffcult to tell you what I want. We should try to establish a vocabulary that we can use both...

Do you like these ideas?

By the way, how do you draw your diagrams? I am searching for a good free software... The best was OpenOffice so far. The example above was made with ArgoUML, but it is not so user-friendly...

[John Kirk]

I think we should consider introducing abstract components and derivations. Furthermore, how about packages?

I think packages would be a good addition.  I'm not so sure about component derivations (i.e. "class" derivations), though.  I think deriving one interface from another makes sense, but I think that deriving one component from another might introduce too much confusion for readers.  Computers can override methods and keep track of what methods have been overridden by other methods.  But, a reader could easily get confused if you re-define what a component property means based on its "type".  So, while it makes conceptual sense, I'm not sure the benefits of doing so would outweigh the potential drawbacks.

In any case, I think that interface inheritance alone can satisfy your goals and would be far less problematic in practice.  Essentially, I think all you would need to do in this case is to define a fairly broad abstract interface that a set of rules must satisfy and then allow supplements to "fill in the blanks" for their specific case.

This is especially useful if you want to have different kinds of magic rules that share basic rules.

In this case, I think that the "basic rules" would act as a sort of framework that would allow modular rule components to be plugged in.

Do you like these ideas?

I'm not sure yet. Doing this would certainly make a game more extensible.  But, it would also make it more complicated.  Whether it is a good idea to do this or not really depends on your design goals, I suppose.

By the way, how do you draw your diagrams? I am searching for a good free software... The best was OpenOffice so far. The example above was made with ArgoUML, but it is not so user-friendly...

I use Microsoft Word.  About the best Open Source software I've found for UML is ArgoUML.  I was personally disappointed with the drawing capabilities of OpenOffice 1.  I haven't tried OpenOffice 2 yet.

[RenjiKage]

I'm not so sure about component derivations (i.e. "class" derivations), though.  I think deriving one interface from another makes sense, but I think that deriving one component from another might introduce too much confusion for readers.  Computers can override methods and keep track of what methods have been overridden by other methods.  But, a reader could easily get confused if you re-define what a component property means based on its "type".  So, while it makes conceptual sense, I'm not sure the benefits of doing so would outweigh the potential drawbacks.

I thought more about that and you are right. I don't even need this for my concept... it would be too restricting for the other develpers (yeah, I am not the only one! :-) ).
I think that the model for component-based design is pretty complete. I'll try to use it in my design. When I get something done, I'll post it. Perhaps we can identify weaknesses of the model (or my design), then (if there are any).