hogarth wrote:Sashi wrote:It still doesn't explain why game designers can't seem to do the math in secret in the background.
The whole idea of "doing the math" is flawed to begin with because 99% of the time the goals that game designers set are vague things like "the game should be fun to play" and not mathematically provable things like "a level 97 blastomancer armed with the Sword of Mork should be able to defeat an owlbadger 78.3% of the time".
THIS! This right here is the problem!
(With apologies to hogarth, but the thing he said is cancerous AIDS for design work)
Absolutely, design goals start out fluffy and insubstantial. If you don't derive no-shit requirements from them, you have
fucked up.
There are a bunch of ways to do that, but the one I'm most familiar with is the "Systems Engineering V". Basically anything else which is halfway functional is a variation of it, so it's worth learning. Here goes:
1) Elict Needs. Figure out what you're building. Hopefully, this part is easy. "A car." "A toaster." "A space shuttle." " A new RPG."
2) Document Needs. Figure out your high-level user needs. This should be the list of key characteristics which make your product acceptable; if you get them, you succeed, otherwise you fail. For a new car, it's probably 30ish pages of requirements, for a new Dnd, I'd expect 10 pages. Generally, these should be what your widget does vice how it does them, but that's not a hard and fast rule.
3) Requirements Analysis/Derivation: write down a specification for something that fills those user needs. Every single line you write here should be definite, testable, and traceable back to a user need (i.e., user needs can be for "easy to play," functional requirements have to be for "no more than four mathematical operations for any resolution" or whatever). Check that your spec meets your user needs statement. For a car, this is probably a couple hundred pages; for DnD I would SWAG it as around 60. (The DoD also requires you to document how each requirement will be tested, which is generally good practice but not strictly necessary.)
4) Requirements Decomposition: Break your system into subsystems. E.g., 3E could have been something like classes, combat, spells, exploration, items, monsters. Each subsystem gets it's own subsystem spec. and interface spec. Check your traceability. There's wild variation in SSS lengths, but for DnD, using the subsystems I listed, I'd WAG them as averaging 30 pages. Same guideline as before on saying 'what' vice 'how'.
5) Realization/Implementation: Now you finally get to get down with your bad self. Design and build those subsystems to meet spec. Remember to have good configuration management, if only so that the classes group doesn't get surprised by the combat group radically redesigning every week. (This is often broken out to several different phases, but it doesn't have to be. Generally, those phases are roughly describe what your plan is, select hardware, and build your subsystem. That's more important if you have actual hardware).
That's the "down" side of the V. The rest is the upstroke.
6) Unit test: check that your subsystems meet your SSS, and that their interfaces are as advertised.
7) Integrate! Glom those subsystems together.
8) Verification: test that when your subsystems Voltron together, they form something which meets your functional spec.
9) Validation: test that you meet your user needs.
10) Package and Deploy.
For folks following along at home, you'll notice that Frank's instructions for RPG design don't match this, but that you could
very easily map them to this process. As a rule of thumb, if you can't describe your design process in terms of what I wrote here, you don't have a design process. ("wish really hard" and the Feynman method do not count).
Saying that "99% of the time the goals that game designers set are vague things like "the game should be fun to play" " is either ignorance of proper design methods, or is an explicit indictment of that 99% of the time. There is no middle ground.
