C = classesEach individual item is an entry in one of these lists, such as a tower shield being equipment item #334, or E[334] in programming terms. Let's say our game has six shields in it, and they all work in different ways. Our buckler could give a -1 to hit in melee, our tower shield is handled in the ranged rules, and so on. Our game now adopts six special cases for all the shield types, and now we have to maintain these rules from now on. If we come up with one rule that handles all shields, and adjusts each shield based on type, we have simplified our design a little bit. Now we can reference one main rule for all shields, and adjust based on shield size and type.
S = skills
R = game rules
P = powers
F = feats and traits
L = leveling and progression
M = monsters
T = treasures
E = equipment
W = world rules
N = NPC rules
D = all the above sets of information, the game's master database
D = C + S + R + P + L + F + L + M + T + E + W + N ....and so on
DnD4 had a huge problem with their database of rules, and this extended in an endless series of updates, errata releases, patches to the online character designer, and changes after release. Their design theory was 'each power or equipment item was like a magic card,' and the card had special rules for use. The game had thousands of powers and equipment items, and by the time you started playing with a book, it was most likely out of date. The only real way to design a character was via the character builder, which had all the updates - the books did not.
To be fair, this was Wizards' business model, to sell DnD Insider subscriptions, and make the game play the best when you had access to the online tools. It's a valid strategy, with one flaw - they printed books. The huge database of game material became the Insider selling point, and also the downfall of the books. To be fair, you can play without DnDI, but it is not the same when you play with a group, and appreciate the speed and flexibility the designer gives you.
How do you solve the complexity problem? This problem has been solved before, in programming with design patterns and object oriented design. Think about the shield problem, if all shields work the same, and they only differ on a couple variables, you can make the shield rule an 'object' and limit the data to variations of the base object. You should define the entire game along the object-oriented theory, with simple, common rules used for the base cases, and limit special cases as much as possible.
We can solve the 'update' problem by keeping data apart from the rules, such as making equipment and spell lists online-only downloads. This way, if there are updates, your books remain valid, and you can print out the updated material you need from the Internet. Keep a basic, generic list of items in the basic rules, just as examples - but keep the huge 'download and print' items separate so these can be maintained and updated better.
If you are trying for an online, community-based game, you may not print books at all, and just sell access to the community. The rules would be free, and the value is held in the community and the tools which support play. You could say the pen-and-paper rules should be 'free-to-play' and focus on creating a community where roleplayers can gather, discuss, and play together.
When designing a game, part of the design is managing infinite complexity. How you manage this will be determined by how you want the game to be played and delivered. Some formats, like the ideal DnDI model, require a rethink, and allow you to have a more complex database. With a simple printed book roleplaying game, you need to make decisions to limit 'game database' complexity, since your format is much more limited and focused. Any way you can simplify the design and handled a lot with a little helps in all cases, since this streamlining makes the game easier to play and understand.
No comments:
Post a Comment