-
Notifications
You must be signed in to change notification settings - Fork 40
Count the number of successes #4
Comments
So I've used Scrivener to brainstorm this. Yikes! Here's what Scrivener compiled from my notes: tackle the evaluatorThe funny thing about this task is that we don't need the parser. We already has the "> X" parser in place. What we need is for the "> X" dice to
Chapter One: handle the modifiers differently?the planSo "/r 3d6+2>1" should return the number of successes by rolling d6 three times and applying the "+2" modifier to each roll. Now how do we do that? In order to be able to parse and handle the modifiers
recognize the modifiersMake the parser eat the modifiers. It should chew on "3d6+2". spew the modifiersBy default the dice evaluator should spew the modifiers unmodified. E.g. "3d6+2" should evaluate to "(d6+d6+d6)+2". propagate the successWhen we roll, we should look ahead and see if there is a success number condition. E.g. check if the first Dice::ops is a TargetNumber. I think we might be conservative here and check only the first Dice::ops. For example, "3d6+2>5" is evaluated as (modified_d6+modified_d6+modified_d6)>5, but "3d6+2 d1 >5"... huh. I don't know how it's evaluated. Well, shucks, I've checked roll20 and they just ignore the drop in this case. E.g. "/roll 3d6 +2 dl 1" they evaluate to (d6+d6+d6)+2. I beg to differ there. If we want to drop some rolls then we might as well take the modifiers into account. The question is... how do we unit test this? Because unit testing all those cases seems more and more important. One way to unit test the dice is to implement a mock roller. E.g. tell the roller what it should roll instead of a truly random number. And another nifty thing to have would be unit testing through Discord. E.g. "/r test" should do the unit tests and print the results. Capish? So... when we roll, we should check ahead and see whether we have any ops on the dice. Because if we have then it doesn't make sense to leave the modifier to the outer evaluator. "3d6 +modifier $any_op" should apply the modifier inline. "3d6 +modifier" should leave the modifier alone (spew it back for the outer evaluator to chew on). Something like that. Chapter Two: unit testsdiscord testingAs a developer or even a curious user I should be able to run the unit tests right from the discord UI with, say, "/r test", to save the hassle of going into a different terminal UI just to run the tests. Alternatively, I might see the tests being run right after a fresh build, in the editor. This seems even better. test modifiers working with drops"/r 3d6 +2 dl 1" should work as follows: roll d6 and modify, thrice, apply drop lowest. E.g. the modifiers should be handled right away. On the other hand, "/r 3d6 +2" should work as before: roll d6 thrice and then modify. the real thingWe should test that "/r 3d6+2>5" evaluates to the proper number of successes. We should test that we can do math on the number of successes. "3d6>5+2" (remember: +2 is not parsed into the dice specification here). Chapter Three: being successfullmodify the printer"3d6>5" should print the number of successes. In order to do this I think it's enough to recognize in the printer that the last op is the TargetNumber op. If it is, then instead of (d+d+d) we print (x successes). cleanupShould replace "(x successes)" with "(x)" before handling it to the outer evaluator. |
There should be a modifier that makes the dice bot return the number of passed rolls instead of the sum of them.
https://www.reddit.com/r/discordapp/comments/4vfbqi/looking_for_a_dice_bot/d780297
=> Note that the number of successes might be negative in some cases. E.g. an oWoD botch.
The text was updated successfully, but these errors were encountered: