Dice Rolls Decoupled From Game Systems (specification)
Sep 10 21:05:31 <CSWookie> Playtools should include a die roller. Sep 10 21:05:41 <MFen> bah. application level! Sep 10 21:05:58 <CSWookie> An absurdley generic die roller that works for a variety of dicing systems. Sep 10 21:06:01 <CSWookie> I disagree. Sep 10 21:06:10 <MFen> convince me Sep 10 21:07:11 <CSWookie> I want to be able to write a thing to do the dicing for earthdawn once, and then be able to query it from a variety of programs. Sep 10 21:07:30 <MFen> ok, so centralization is an argument Sep 10 21:07:35 <MFen> but that's not enough Sep 10 21:07:48 <MFen> remember that playtools is fundamentally about data Sep 10 21:08:35 <CSWookie> Well, there are multiple layers to a dicing system. Sep 10 21:09:31 <CSWookie> For example, both D&D and Earthdawn are based on dificulty checks, but while D&D always has D20s, Earthdawn varies the dice involved dramatically based on the attributes and skill levels involved. Sep 10 21:10:18 <CSWookie> It would be nice if one could have a way to do a Difficulty Check that was independant of the dice involved. Sep 10 21:10:33 <MFen> hmm Sep 10 21:10:51 <MFen> still, this is about centralization, not data Sep 10 21:11:11 <MFen> to be sure, abstraction over game systems might be useful, but i don't know enough about what game systems require yet to do a good job of it Sep 10 21:11:30 <CSWookie> You tell it what system, character, and combination of skill/attributes you are using, and it figures out what types of dice are involved, and rolls them. I suppose mayb it should just figure the dice involved, and return them to the app, which can then roll them. Sep 10 21:11:58 <MFen> i almost see it the other way around Sep 10 21:12:18 <MFen> ok, now you're talking my language Sep 10 21:12:46 <MFen> can you then relate them to a principal? Sep 10 21:12:55 <MFen> or maybe it's principle. Sep 10 21:13:23 <MFen> weird, rdf principles and rdf principals have almost identical google scores Sep 10 21:13:42 <CSWookie> The latter is what you mean, I believe. Sep 10 21:14:15 <MFen> remember the attack tree we drew? Sep 10 21:14:22 <MFen> wonder if i still have that.. Sep 10 21:15:08 <MFen> ooh, i do Sep 10 21:15:26 <CSWookie> Well, as an example, if you have a character that has a 13 dex in earthdawn, and no melee combat, then his die step is 6 (this is determined by a table). The roll for step 6 is a d10. Therefore when he tries to hit someone with his sword, he rolls a d10 to hit. Sep 10 21:17:34 <MFen> damn, this tree is pretty smart Sep 10 21:17:59 <CSWookie> MFen: When you have a character in D&D with a strenght of 10, and a BAB of 0, he rolls a d20 to hit. Sep 10 21:18:00 <MFen> ok, so you can represent that table as data, certainly
What are we talking about here? Executive summary.
Use Cases
- ..
- (Sometimes called user stories. What person or application is going to use this feature? List them, with some mention of the connection between that'n and this'n.)
Outcomes
When this blueprint is implemented, we will be able to:
- ..
(specific functionality that will be enabled. should be obvious from reading this list that all the user stories will be satisfied, or the ones that won't be satisfied should be given strikethru formatting.)
- (this defines the SCOPE of this blueprint: what it encompasses--how we know when we're done.)
Implementation
(What files are we going to touch to make this happen. What changes will be made there, tests will be written, documentation issues to be resolved, social engineering that will be performed. Mention workarounds to problems that are related but out-of-scope.)
Open Questions
- (Implementation obstacles - how will we unit test, for example)
- (Ask for help designing stuff)