Message when overshooting w/Fire dice has un-raised value

[dwvanstone]

In game 1843 on the dev site, I had a pB(17) showing 14. I used a fire die to raise it up to 17 before doing a Power attack. Here's the two log messages in order:

"Devious chose to perform a Power attack using [pB(17):14] against [q(11):7]; Devious must decide whether to turn down fire dice" "Devious turned down fire dice: Fo(13) from 12 to 9; Defender q(11) was captured; Attacker pB(17) rerolled 14 => 2"

However it should read "Attack pB(17) rerolled 17 => 2" since I raised it to 17.

[cgolubi1]

On Mon, 14 Sep, 2015 at 11:08:24 -0700, dwvanstone wrote:

However it should read "Attack pB(17) rerolled 17 => 2" since I raised it to 17.

Should it? I mean, this is kinda philosophical, but when you Fire a die, do you actually raise the die to the fired value (i.e. flip your die over until it shows the higher number), or just use the Fire sides to assist without physically flipping the die to the larger number?

When you use Fire to assist a multi-die Skill attack, i don't think the backend actually assigns the Fire points to a particular attacking die --- it just does the math to make sure it's possible. And IMO it would be much more confusing if the action log entry, in the Skill case, contained derived before-reroll numbers the player had never seen before.

IMO the Power case should work like the Skill case, and the action log should show the player the number the die actually rolled, not a derived intermediate number.

Chaos

[dwvanstone]

Yes, in my head I was physically flipping the die to a larger number, and I concur that for a skill attack that putting the new values in the log might make things more confusing. I much prefer consistency, so unless someone else things this is a bug I will close it.

[irilyth]

Something about the description of Fire makes me think that it is modifying the showing-value of the dice in the attack -- and it occurs to me that this could actually have an effect on e.g. a Konstant die.

The particular phrase is

"Before making a Skill or Power Attack, you may increase the value showing on any of the attacking dice, and decrease the values showing on one or more of your Fire Dice by the same amount."

That makes it sonds like you actually increase the value that's actually showing on the actual die; although later it says

"Turn the Fire Dice to show the adjusted values, and then make the attack as normal."

and doesn't explicitly say to turn the attacking die; but that would generally be a waste of time, since you're about to roll the die anyway. (Except in a case where you're not about to roll the die, like Konstant.)

I agree that it should be consistent in any case.

[blackshadowshade]

I see two possible solutions here: (i) we change the description to make it clear that the Fire dice are contributing values, but not actually changing the attacking die values (ii) we somehow work in a more complicated UI for Fire

I really don't want to pursue option 2, especially after the comments about fire overshooting and the already too-complex UI for Fire. Shall we rework the description?

[dwvanstone]

There are two issues here:

• the text describing what's happening [I'll address that below]
• the functionality that Josh describes: can a konstant die participating in a skill attack be increased through a Fire attack?

Assuming the answer to the second is no (that Fire dice doesn't actually cause the participating buttons to change their sides), how about something like:

"Devious turned down fire dice: Fo(13) from 12 to 9 donating 3 sides to the attack; Defender q(11) was captured; Attacker pB(17) rerolled 14 => 2"

However in this world (where the participating buttons don't change sides) then we should also modify the Fire skill text to not say that the values are being increased/decreased. I'm happy to work on revised text if that's the direction we're going.

[blackshadowshade]

I think this proposed solution makes a lot of sense.

If you're reworking the description of Fire, it will also need a mention of fire overshooting and the user preference bound to this.

[blackshadowshade]

@dwvanstone, I'm assigning you to this issue, so that you can rework the description of Fire, and we can discuss it. Once you've done that, I'll implement the changes necessary.

[blackshadowshade]

I've also sent you an invite into the dev team. Once you accept that, I'll set the Assignee properly. :)

[dwvanstone]

I think I'm on hold on this until the consensus issue (#1704) is resolved. It's possible Fire won't be changed at all for this release.

[dwvanstone]

I do have an appointment with cgolubi1 to help me get a dev setup on my computer in the next few weeks. (Thanks!) Do I need to figure out how to update the Fire description in github before then or can it wait a few weeks?

[blackshadowshade]

I'm happy to update the Fire description whenever you're ready with it.

[dwvanstone]

I'd have to see the text of the preference to clean up the final sentence, but this rewriting should clarify that the dice participating in the attack don't actually have their sides changed.

Fire Dice cannot make Power Attacks. Instead, they can donate sides to other Dice in making Skill and Power Attacks. They cannot donate sides to other types of attacks. After selecting your dice and your type of attack, you may decrease the values showing on one or more of your Fire Dice (not already participating in the attack) in order to donate that number of sides to the attack. For example, if you are making a Skill Attack and need 5 more sides, you can take 5 points away from one or more of your Fire Dice. Turn the Fire Dice to the reduced values, and then make the attack as normal. You cannot decrease the value of a Fire Dice below its minimum value and you cannot donate more sides than the receiving Dice could receive. (I.e., a 10-sided Die showing 7 cannot receive more than 3 sides from Fire Dice).

If your have set your preference to allow overshooting, you can allow a single Die to overshoot during a Power Attack by donating more sides than the Die needs to complete the attack.

[danlangford]

I really don't want to pursue option 2, especially after the comments about fire overshooting and the already too-complex UI for Fire. Shall we rework the description?

FWIW (which is nothing) I dislike the idea of altering the correct rules or the game designers skill description to conform it to a UI that is already implemented because the alternative would be complex. We can come up with a newbie friendly ui to accomplish the correct description.

I'm an outsider though my opinion is moot

[blackshadowshade]

I think that the point here is that Fire was designed in isolation, and so did not need to consider potential interactions with other skills. For buttons that do not combine Fire with other skills, there is no issue with the current UI --- it gives the same result as a more complicated UI that would change the value of the fired dice. However, when you have two skills that have conflicting intents, like Konstant and Fire, at some stage it is necessary to alter at least one of the skills so that the exact wording will need to change. The question is always which compromise is going to be the most acceptable.

[irilyth]

FWIW (which is nothing) I dislike the idea of altering the correct rules or the game designers skill description to conform it to a UI that is already implemented because the alternative would be complex. We can come up with a newbie friendly ui to accomplish the correct description.

I generally agree with this, and I think it's worth distinguishing between "we're making a long-term change to the rules of the game to accommodate a limitation of the UI", and "we're making a short-term change to what the help text says is possible, to accommodate a current bug that we intend to fix some say".

I think this is more like the latter: We think Fire should work the way the rules say it should, but it doesn't right now; so we should document the fact that it doesn't right now, so that people aren't confused about the discrepancy. (And this would be true whether the bug/limitation/whatever was UI, or backend, or whatever.)

[AdmiralJota]

I agree with irilyth. And given that, it would probably make sense to note it as such when/if we modify the text.