The thorny interaction between konstant and fire

Those who have been on the site for a while will know that there are quite a few buttons that are not yet playable. Mostly, this is because a die or button skill hasn't yet been implemented. But sometimes, the reasons are more subtle.

Two of the US States buttons, Arizona [k(7) g(9) (12) F(15) (X)] and Hawaii [n(4) m(5) k(8) F(13) d(Y)] have been disabled for the entirety of the time that most of the other US States buttons have been playable, since January 2016. And on a first glance, it would appear that these buttons should have been enabled for play, since all the component die skills were already implemented at the time.

The story really starts in September 2015, when devious and irilyth found a konstant bug while testing the button Hawaii on the dev testing site. It turned out to be caused by the underlying code not correctly determining whether an attack involving konstant requires fire support.

I submitted a fix for this, and as usual, Chaos ran her automated testing bot on the new code base to see if she could find obscure bugs. As part of the testing, it became apparent that the fix did not address another konstant/fire interaction bug, caused by the assumption that fire support would always increase the total value of the attack. This is patently wrong when a konstant die value is increased and the konstant contribution to the skill attack is negative.

We decided in December 2015 to disable Arizona and Hawaii until this new bug could be fixed.

In the next few years, both jl8e and I ran our eye over the code to see if there was an easy fix, but it ended up in the too hard basket.

This week, I decided that it was time to set my mind to the task of fixing this bug once and for all. I looked at the code base again, worked out a plan to fix it, and then started scribbling a solution on scrap paper.

And then I stumbled across another problem. What happens when we use fire support to increase the value of a konstant die? Surely the new value of the konstant die remains after the attack?

It turns out that this issue had already been discussed at some length with respect to the UI and the action log, including the philosophical question of whether fire support actually changes the value of the attacking dice or not. The discussion reached the conclusion that we would really like fire support to actually change the value of the attacking dice.

This means that any full implementation of fire support for konstant dice needs to be complex enough to allow for a new value after the attack.

In the case where there is only one konstant die present and the konstant die is contributing a negative value to a skill attack, it is possible to calculate how much the konstant die value must increase for a certain amount of fire support.

However, in the case where the konstant die is contributing a positive value to a skill attack, there may be many ways of distributing the fire support across the attacking dice, so the final value of the konstant die cannot always be deduced from the amount of fire support used.

So, what to do? Put off fixing this problem until we have a full UI that allows individual die values to be altered when fire support is used? Put in a partial fix for the case when the konstant die contributes a negative value to a skill attack?

I'm sure there'll be some way through, but it'll be more involved than I imagined a week ago.

Just another day in the life of a Button Weaver.

Comments

  1. AnonymousNovember 17, 2020 at 6:33 AM

    AnnoDomini:
    From konstant description:
    If another skill causes the die to change its value without rerolling (e.g., Focus, Fire), the die's value does change and then continues to show that new value.

    So yes, Fire die should be able to increase value of konstant die.
    Normally, when user wants to make a skill attack with 2 normal dice, then Fire can be used to increase the value of other dice, but it doesnt really matter which one - so user doesnt need to specify that.
    Now, when making a skill attack with 1 normal die + konstant die and using Fire to increase the value, it does make a difference which die increases the value - and system should prompt the user to tell which die they increase value on. If it is normal die - than nothing happens after the attack, but if it is a konstant die, then its value should increase and stay increased after the attack.

    So we now need to add this possibility for user to point value of which die is going to increase.

    Also, one more thing Say normal die has value N, konstant has K, we use fire to increse values by F.
    If user points on N to be increased, the possible skill attack is N+F+K or N+F-K
    But if user points K, the possible skill attack is N+K+F or N-(K+F)=N-K-F.

    ReplyDelete

Post a Comment

Popular posts from this blog

Phases of a turn

One of the first times I really thought about game states in a game was when I was learning Magic: the Gathering. There, it can be really important to know which phase of the turn is currently occurring, so much so that sometimes, you need to explicitly say things like "I'm beginning my upkeep phase" or "I'm about to end my main phase", so that opponents were given the opportunity to react during that phase. When I started working on Button Men, I thought that things would be much simpler, and that turn order wouldn't be nearly as important. Looking at the status of class BMGameState in July 2013, many of the game states were already present: startGame applyHandicaps chooseAuxiliaryDice loadDiceIntoButtons addAvailableDiceToGame specifyDice determineInitiative startRound startTurn endTurn endRound endGame Interestingly, we haven't yet used the game state set aside for allowing a handicapped game, it's just there as a placeholde...
Read more

Why PHP? A brief history of the resurrection of Button Men Online

For anyone who knows anything about web development, it may seem odd that we are using PHP for our back-end, especially since we made the decision in 2012, when there were many other feasible languages available. Here is the story of how we started out, and how we incidentally ended up being stuck with PHP. 12 Nov 2012 I broached the subject of resurrecting the Button Men Online site on the  Buttonmen Site Outage News  group, after nine months of downtime of the old site. One of the things that I left open was the choice of programming languages. 13 Nov 2012 After getting a bit of interest, I posted a suggestion on November 13 that we go with Python and PostgreSQL. Brooks chimes in that he is a Zend certified PHP developer, and suggests that Python frameworks may not be as robust as the Apache backend, and that the Apache backend is more widely supported on cloud architecture. He also mentions Pagodabox, which he uses for his PHP projects. Chaos posts that she knows Pyt...
Read more