There is nothing quite as antithetical to the nomenclatorial Confucian as the proliferation of several identical acronyms, especially when they are used in similar enough contexts as to be confused. That's why I'm here today to talk to you about BSDs.
Predictably I of course mean neither any Berkeley Software Distribution or Bipolar Spectrum Disorder, much less the Birch and Swinnerton-Dyer Conjecture. Instead I mean, and am proud to have contributed another meaning to a not yet confusingly overloaded acronym, Balance Standard Documents.
"But H13", you might say, "what is this @#%!?". Well, it's an idea I've been carrying around in my head for a while, but reading this excellent RPG design article has motivated me to expound on it, which I figure might benefit at least some people who like to write up Tabletop RPGs.
A BSD is, in essence, a white paper detailing how to implement some Design Goal. It is thus a document that is at an intermediate level between ideas and mechanics, and of utmost importance.
Consider the classical case of D&D, which is a dead horse I will never tire of beating. It has unclear design goals, conflates content and mechanics and, most damningly especially for it as a highly Gamist system, has little or no guidelines on balancing content against other content, and absolutely none on the mechanics level, which, thanks to the upper-level confusion that characterizes especially 3.x/Pathfinder, leads to huge amounts of published options that vary enormously in usefulness. To add insult to injury, this, of course, further adds to the confusion, with predictable effects.
People who have the misfortune to talk with me about tabletops often will know that I hold D&D 4e in fairly high regard precisely because it considerably improved on these considerations, but even that system fails rather spectacularly in keeping player options near the same level of usability.
Of course, blaming it all on a lack of BALANCE STANDARDS WHICH ARE A COOL THING WHAT I TOTALLY ORIGINALLY THOUGHT OF would be a rather silly move (and nb I pretty much lifted the idea from a silly web browser game which has been trying to retroactively impose them for years) would be rather stupid, since evidently there is some thought going into how to balance options. The other problem that BSDs can solve is metagame control.
Often, options that look evenly balanced on paper will turn out, in actual play, to be totally mismatched, because one is only rarely ever useful and the other all the time — it turns out that the weapon damage BSD failed to note that most enemies in the game do not resist damage type X, whereas a lot of them resist damage type Y.
This is the kind of problem that is very hard to deal with in the planning phase, because it requires knowledge of the content that will be produced in the future and how it is used. That means that for optimal results, it is unavoidable to update the rules and standards to reflect the metagame. This happens in competitive multiplayer video games, but very rarely in other games, especially not tabletops (and the kind of tabletop that might do that tends to either not exist or not have a metagame). Hence, for these more rules-static media it is a good idea to pre-empt at least some portion of this and define a projected frequency target for game mechanics, if you so will. These mechanics can then be balanced against how common or uncommon they are projected to be, which if done right can take a lot of these problems out of the game.
Now I've been talking a lot about the more gamist sort of game, but even for narratively oriented games BSDs can be very useful, simply as part of getting your design straight. An optimal process starts with codifying the design goals, writing BSDs to detail the implementation plan, building the mechanics and then using these to build whatever content you have.
This may sound like a lot of pedantry, but considering that especially indie RPGs often stop short of the content level and put the burden of that on the GM, and that doing this sort of thing is part of the appeal of tabletops in the first place (not to mention any game-theoretic things about system exploration), it is clear that the important thing you are making is the system, and if that is coherent and easy to use in all ways, and that includes content creation, it can only be good. Besides, you won't want to end up like this anyways:
Predictably I of course mean neither any Berkeley Software Distribution or Bipolar Spectrum Disorder, much less the Birch and Swinnerton-Dyer Conjecture. Instead I mean, and am proud to have contributed another meaning to a not yet confusingly overloaded acronym, Balance Standard Documents.
"But H13", you might say, "what is this @#%!?". Well, it's an idea I've been carrying around in my head for a while, but reading this excellent RPG design article has motivated me to expound on it, which I figure might benefit at least some people who like to write up Tabletop RPGs.
A BSD is, in essence, a white paper detailing how to implement some Design Goal. It is thus a document that is at an intermediate level between ideas and mechanics, and of utmost importance.
Consider the classical case of D&D, which is a dead horse I will never tire of beating. It has unclear design goals, conflates content and mechanics and, most damningly especially for it as a highly Gamist system, has little or no guidelines on balancing content against other content, and absolutely none on the mechanics level, which, thanks to the upper-level confusion that characterizes especially 3.x/Pathfinder, leads to huge amounts of published options that vary enormously in usefulness. To add insult to injury, this, of course, further adds to the confusion, with predictable effects.
People who have the misfortune to talk with me about tabletops often will know that I hold D&D 4e in fairly high regard precisely because it considerably improved on these considerations, but even that system fails rather spectacularly in keeping player options near the same level of usability.
Of course, blaming it all on a lack of BALANCE STANDARDS WHICH ARE A COOL THING WHAT I TOTALLY ORIGINALLY THOUGHT OF would be a rather silly move (and nb I pretty much lifted the idea from a silly web browser game which has been trying to retroactively impose them for years) would be rather stupid, since evidently there is some thought going into how to balance options. The other problem that BSDs can solve is metagame control.
Often, options that look evenly balanced on paper will turn out, in actual play, to be totally mismatched, because one is only rarely ever useful and the other all the time — it turns out that the weapon damage BSD failed to note that most enemies in the game do not resist damage type X, whereas a lot of them resist damage type Y.
This is the kind of problem that is very hard to deal with in the planning phase, because it requires knowledge of the content that will be produced in the future and how it is used. That means that for optimal results, it is unavoidable to update the rules and standards to reflect the metagame. This happens in competitive multiplayer video games, but very rarely in other games, especially not tabletops (and the kind of tabletop that might do that tends to either not exist or not have a metagame). Hence, for these more rules-static media it is a good idea to pre-empt at least some portion of this and define a projected frequency target for game mechanics, if you so will. These mechanics can then be balanced against how common or uncommon they are projected to be, which if done right can take a lot of these problems out of the game.
Now I've been talking a lot about the more gamist sort of game, but even for narratively oriented games BSDs can be very useful, simply as part of getting your design straight. An optimal process starts with codifying the design goals, writing BSDs to detail the implementation plan, building the mechanics and then using these to build whatever content you have.
This may sound like a lot of pedantry, but considering that especially indie RPGs often stop short of the content level and put the burden of that on the GM, and that doing this sort of thing is part of the appeal of tabletops in the first place (not to mention any game-theoretic things about system exploration), it is clear that the important thing you are making is the system, and if that is coherent and easy to use in all ways, and that includes content creation, it can only be good. Besides, you won't want to end up like this anyways: