DICE in Formula 6.08

Dice

Raw

As we move forward, we will end up with some variables of "non-number" formats, because that will be rather convenient for processing the necessary items on a PC. One of those is dice, since that is mostly well-structured and understood.

I recently got a question from Andrew M, so I want to type out where I am, since there are some nuances in determining the gory details of how dice work. I think this is "stable", but certainly still subject to gathering input and changes as necessary. It is not currently in the code.

Let's naively introduce a format called "DIE" for a moment, such that we have:

  d6
  d8
  etc.

as valid entries.

  MODIFY:MyDie|SET|d6

As has been pointed out in various ways, most recently on a query from Andrew M on hit dice for classes, this will often not work... because the hit dice might be 2d6 for a level, so it's not a die, it's dice.

So let me assert without proof for a moment that DIE is rare enough as a data format that it is not useful (relative to DICE)

So let's assume for a moment we do DICE as the format instead.

  MODIFY:MyDice|SET|2d6

...now works.

The problem comes from how this can be modified. I suspect we need things like STEPUP and STEPDOWN:

  MODIFY:MyDice|STEPUP|1

turns d6 into d8, for example (the 1 in this case is how many steps to go up)

Perhaps:

  MODIFY:MyDice|ADDDIE|1

turns d6 into 2d6.

There is one thing to work through:

If the incoming dice are d6+1, and you do "step up", do you end up with d8+1 or d8+d2? In other words, is a trailing constant equivalent to 1d1, or is it a constant? (Said another way, if I want it to step up to d8+d2, did I need to start with d6+d1?)

The truth is, I'm not sure we actually have any rules to help speak to that other than looking at the (R)SRD scaling and that it steps down through "1"... and I think it would be weird if a number was passed through STEPUP and wasn't processed, so given both of those, I'm inclined to say no constants, it would be d8+d2.

The reason I make that assertion is that the actual order of modification would probably be something like this anyway:

On weapon:

  PART:1:MODIFY:Damage|SET|d8

In Global Mod file:

  MODIFYOTHER:EQUIPMENT.PART|ALL|Damage|STEPUP|CurrentSize-BaseSize|PRIORITY=10000
  MODIFYOTHER:EQUIPMENT.PART|ALL|Damage|ADD|Plus|Priority=15000

So a magic weapon is designed to do the "stepup" at a priority processed after when the magical bonuses are added, so there is away around stepping up the constants by intelligent application of Priority.

=

I know this leaves out things like "fire damage" on weapons, and am aware we need to solve that as well. We should be able to end up with:

d8 + d8 (lightning) + d6 (fire) + 1

...or some such.

That one requires a bit more development on my part to determine which of a few paths I take... so nothing concrete there yet. I'm trying to avoid variable proliferation (it should be doable all on the original variable "Damage") and it should avoid having to specify when the damage is "Normal". Getting both at the same time will require a new capability relative to other parts of the variable system.

I am aware of dice modifications that would be triggered by: Hit Die Setting/Locking Weapon Size Changing

Anything else we need on dice pools in the short time frame? What else would use dice that needs some form of modification of those dice beyond SET, STEPUP, STEPDOWN, ADD, SUBTRACT, ADDDIE (and maybe SUBTRACTDIE?)?

Does the above strike anyone as a problem or missing something we need to address?

Tom

UPDATE:

To clarify one point:

  MODIFY:MyDice|SET|d6
  MODIFY:MyDice|ADD|d8

works just fine.... the result is d8+d6. ADD will just "put things into the dice" (or dice pool, or roll, not sure what we should really call it)

What I want to avoid is the "(Normal)" in something like:

  MODIFY:MyDice|SET|d6 (Normal)
  MODIFY:MyDice|ADD|d8 (Normal)
  MODIFY:MyDice|ADD|d4 (Fire)

I want something more more like:

  MODIFY:MyDice|SET|d6
  MODIFY:MyDice|ADD|d8
  MODIFY:MyDice|ADD|d4 (Fire)

...the problem with that being it plays poorly with localization/error catching/wanting to share similar capabilties elsewhere...