The great debate, this time with Java!

[Kdansky]

Re: The great debate, this time with Java!

 

Hehe, you are simulating with randomness, that also works. I do it differently: I calculate every single die roll and count them. So yeah, with 10d6 I roll everything from 1111111111 to 6666666666 and then the location from 3 to 18 for each one again. I cannot (yet) go to 12 DC, because then I explode my heap

 

Next thing I have planned is actually as tiered set-up. If you shoot two times, what are your chances of stunning at least once, or doing total X stun. And if you shoot three times... and so on. Should give me a feel of how plinks and stuns work out in the long term. The reason you get such high Stunned results for EB is the CON. It's a lousy 25 when Attacks are 12d6. I would expect it to be 35 (which again, gives similar results to 9DC).

 

As pointed out, stunX from hitlocations is after defenses, therefore plinks don't change.

[Hugh Neilson]

Re: The great debate, this time with Java!

 

Which of these things is not like the others?

 

Apts of defense to 'bounce' 30 Apts of attack power:

 

Ego attack: 18

 

Flash: 12

 

Well, one sense of Flash. Multiply by the number of sense groups you want protected.

 

Killing Attack: 66

 

Drain: 18

 

AVLD: 13-19

 

Would you say that the amount you have to invest in an apropriate defense is consistent from one attack power to another?

 

You left out "Energy Blast" which, at 36 points, is a lot higher than your other comparatives, though not near as expensive as complete immunity to a KA. And those KA defenses also protect you against normal attacks - the other examples don't.

[SteveZilla]

Re: The great debate, this time with Java!

 

I think it came from the practical pronunciation of the words during face to face games.

 

"Positron is hit for 62 Stun and 14 Body. Is he Stunned?"

"No. 34 Stun got past his defenses so he has 26 left."

"What is Positron's Constitution?"

"33"

"So he is Stunned then."

"No. He has 26 Left!"

....

 

Positron's player is confusing CON-Stunned with CON-Knocked-Out.

[Kdansky]

Re: The great debate, this time with Java!

 

Positron's player is confusing CON-Stunned with CON-Knocked-Out.

PAIN!!!

 

 

On topic: nobody commented on the hit location for normal damage, i re-read my code and could not see any mistakes (which does not mean there are none). Or are you all still asleep due to time difference? That might be the case :/

[Tonio]

Re: The great debate, this time with Java!

 

Now, just to make things interesting, I changed the parameters to something that is more likely in my Champions game.

I used the following:

DC = 12 (12d6 normal, 4d6 killing)

CON= 25

DEF = 25

Since I don't really care that much about the BODY damage, I didn't keep track.

But...

 

Running Killing (4d6)
Running Normal (12d6)
Normal Results:
Total Attacks: 100000000
Average Damage: 17.00
plink %: 0.21
stunned %: 7.60
---------
Killing Results:
Total Attacks: 100000000
Average Damage: 16.29
plink %: 40.09
stunned %: 29.07

So, in this case, you are 200X more likely to "plink" with a killing attack, and only a little less than 4X more likely to STUN when when killing. Now, that seems a pretty high likelihood of stunning... but we are talking pretty much stun or plink here, since you are about 30% likely to do non-stunning damage.

 

Again, to me, I would prefer to do the 17 damage each attack (on average). For a typical target, that would mean I get a KO in 3 shots, while in 3 shots I might stun the person, but won't be as likely to achieve a KO.

 

That makes me think... maybe I should modify to collect that stat as well... number of attacks required to KO (assuming 40 STUN?).

 

While I can imagine the result, I think the statistics would be the most telling.

 

Maybe tomorrow... now it is time for V-Day

 

Dunno... is that "average damage" calculated "per damaging hit" or "per hit"? If it's "per hit", then I think you might be misinterpreting the stats. With the EB, you'd get a KO in 3 shots... and so would you, probably, with the KA. Not as likely as with the EB, but pretty likely. Sure, a little less than half the shots will do no damage (plinks), but those that do hurt will hurt for more than the 17 STUN (it must be so, to get a ~17 average per hit). Moreover, you're likely to get a Stun, which will help you hit, help you not get hit, and might have other effects (for example, you might decide to Rapid Fire your KA to take advantage of the lowered DCV, which means more STUN).

 

The more hits you need to KO, the less helpful consistency becomes. If a single hit from a "standard effect" EB will KO a target, then using anything that has any chance of not KO'ing the target is a worse idea, since any "extra" damage will be unneeded. But as the number of hits increases, variable damage's total will start evening out, and the added chance of Stunning wins.

[Hugh Neilson]

Re: The great debate, this time with Java!

 

Positron's player is confusing CON-Stunned with CON-Knocked-Out.

 

Or with STUN-Knocked Out

 

Not to be confused with BOD-KO'd (ie dead).

[Silbeg]

Re: The great debate, this time with Java!

 

Dunno... is that "average damage" calculated "per damaging hit" or "per hit"? If it's "per hit"' date=' then I think you might be misinterpreting the stats. [/quote']

 

Specifically the formula I used was:

public void addAttack ( DamageResult damageResult ) {
       numberOfAttacks += 1;
       this.totalDamage += damageResult.getStunTaken();
       if ( damageResult.isPlink() ) {
           plinks++;
       }
       if ( damageResult.isStunned() ) {
           stuns++;
       }
   }

So, you are correct in that there probably is some interpretation going on, as any attack that deals no damage will add 0 to the average.

 

So, it is average damage, with a floor of 0. For combat purposes, this still tells us what the average damage for a given attack and defense would be. Since you cannot do negative damage to a target, this I think this is a correct interpretation, and I think that Kdansky's formula and mine work about the same for that.

 

Hehe' date=' you are simulating with randomness, that also works. I do it differently: I calculate every single die roll and count them. So yeah, with 10d6 I roll everything from 1111111111 to 6666666666 and then the location from 3 to 18 for each one again. I cannot (yet) go to 12 DC, because then I explode my heap [/quote']

 

I see... so for your tests, 11113 and 31111 are two separate results? Interesting way to do it, but expensive as well... I was having similar heap issues when I was trying to capture all of my results, and then aggregate... rather than doing as I show above. Was limited to tests of about 1million rolls, now my only limiter is time.

 

So, I am about to try working out the average number of rolls to KO with this process. I will be working with the following parameters:

 

12DC attacks

DEF 25 (ignoring BODY damage for now)

CON 25

STUN 40

 

These values seem to me to be pretty close to "book characters" levels, excepting bricks (or other high DEF characters).

 

I might make a second run with a set of brick-like stats...

12DC attacks

DEF30

CON33

STUN70

 

Will post later with these results.

[Tonio]

Re: The great debate, this time with Java!

 

Damn, all this Java talk makes me wanna write up my own, for no particular reason other than me not wanting to do the work I'm s'posed to be doing. =/

[Silbeg]

Re: The great debate, this time with Java!

 

Damn' date=' all this Java talk makes me wanna write up my own, for no particular reason other than me not wanting to do the work I'm s'posed to be doing. =/[/quote']

 

That's the reason I am doing it. Heh.

 

So, I went in and added the parameters I talked about, in order to see how many hits were required (on average) to KO a target. This time, the TEST_CYCLES did not count the exact number of attacks rolled, but was the number of KOs rendered.

 

TEST_CYCLES = 100000000
Running Killing (4d6)
Running Normal (12d6)

character 'defenses' = Defenses{con=25, def=25, stun=40}


Normal Results:
Total Attacks: 288248498
Average Damage: 17.00
plink %: 0.21
stunned %: 7.60
attacks to KO (avg): 2.88
---------
Killing Results:
Total Attacks: 362350923
Average Damage: 16.29
plink %: 40.08
stunned %: 29.08
attacks to KO (avg): 3.62

 

What is interesting to me is that this shows that there is a pretty good statistical advantage to attacking with a similarly powered normal attack... It appears to take about 1 less attack to KO a target with the normal attack than with the killing.

 

Since none of these calculations are checking attack rolls, no advantage would be gained by stunning a target (assuming non-powered defenses).

 

Now, going up against a mythical brick

 

character 'defenses' = Defenses{con=35, def=30, stun=70}
---------
Normal Results (12d6):
Total Attacks: 638835168
Average Damage: 12.04
plink %: 2.54
stunned %: 0.00
attacks to KO (avg): 6.39
---------
Killing Results (4d6):
Total Attacks: 655691944
Average Damage: 13.43
plink %: 47.70
stunned %: 13.45
attacks to KO (avg): 6.56

 

So, with higher defenses, and higher STUN, the killing attack loses some of its disadvantage. There is (statistically) no chance for the normal attack to stun a target (at least within 2 digits of precision).

 

I find it interesting that the Killing Attack does on average better damage, but takes more attacks to KO. My guess would be that this is caused by the highly variable damage from a KA.

 

Either way, in a fight you'll have to be patient. To me, the almost 50% plink chance on the killing attack would make things not so fun... but I can see where the 13.5% chance to actually stun the target would make it more exciting for a player. This means that it is likely that one of the 6+ attacks needed to KO will actually stun!

 

enjoy

[Comic]

Re: The great debate, this time with Java!

 

What is interesting to me is that this shows that there is a pretty good statistical advantage to attacking with a similarly powered normal attack... It appears to take about 1 less attack to KO a target with the normal attack than with the killing.

...

 

Since none of these calculations are checking attack rolls, no advantage would be gained by stunning a target (assuming non-powered defenses).

 

...

 

I find it interesting that the Killing Attack does on average better damage, but takes more attacks to KO. My guess would be that this is caused by the highly variable damage from a KA.

 

This is pretty much what I found with my simulation.

 

Once Stunned, but not Knocked Out, the target of a KA has a huge advantage in likelihood of recovering, ever.

 

Which is not to say this ends the debate, of course.

 

Just ends the combat between a KA user and an EB user.

[Kdansky]

Re: The great debate, this time with Java!

 

What I do: I roll all dice in all variants (leading to problems with more than 10 dice, sadly), but then I collect the results up, meaning, my code sums the dice and then only differentiates by sum (and the important thing is: how often did I roll a certain value?). That gives me a big array with the index signifying the sum, and the value signifying how often that sum came up. so for 1d6: 0: 0, 1: 1, 2: 1, 3: 1 , 4: 1, 5: 1, 6: 1

That leads me to the next problem: these numbers get really big (more than an integeger for 11d6+ rolls). So I will need to change formats there from int to BigInteger. Crap

But well, I never miss a single roll, and I think 12d6 is still doable with 30 seconds of calculation. I will do some sort of shootout later, but now Im busy with RL Anyone has an apartment in tokyo to rent out?

[SteveZilla]

Re: The great debate, this time with Java!

 

What I do: I roll all dice in all variants (leading to problems with more than 10 dice, sadly), but then I collect the results up, meaning, my code sums the dice and then only differentiates by sum (and the important thing is: how often did I roll a certain value?). That gives me a big array with the index signifying the sum, and the value signifying how often that sum came up. so for 1d6: 0: 0, 1: 1, 2: 1, 3: 1 , 4: 1, 5: 1, 6: 1

That leads me to the next problem: these numbers get really big (more than an integeger for 11d6+ rolls). So I will need to change formats there from int to BigInteger. Crap

But well, I never miss a single roll, and I think 12d6 is still doable with 30 seconds of calculation. I will do some sort of shootout later, but now Im busy with RL Anyone has an apartment in tokyo to rent out?

 

Are you trying for 12d6 the brute force method (i.e., 12 nested loops)? If that's the main problem, you could try something I call the "array addition method"

 

1. generate a 1d6 array of results (i.e., 6 cells, each holding a 1)

2. add this array to a larger array 6 times with an "offset" that increments from 1 to 6.

3. You now have an array for the results of 2d6. Repeat step 2 as many times as needed to add more dice to the total result.

 

This method only uses two loops. One for however many dice you want to get results for, and the second to add the prior result array to the new array 6 times.

[Kdansky]

Re: The great debate, this time with Java!

 

You guessed right, I'm doing it recursively Mainly becase I know I suck at recursion and I wanted to do it that way because I suck at it. As you can see, I figured it out, even if it took me quite a few tries. I will probably change it to the array method (awwwww) because that works a bit (haha) better.

 

looks like this:

public int[] rollXd6(int x, int[] container){
	return rollXd6rec(x, 0, container);
}

private int[] rollXd6rec(int x, int sum, int[] results)	{
	if (x > 0) {
		for (int i = 1; i < 7; i++) {
			results = rollXd6rec(x - 1, sum + i, results);
		}
	} else {
		results[sum]++;
	}
	return results;
}	

[Netzilla]

Re: The great debate, this time with Java!

 

A while back I wrote a program for determining the odds of rolling X result on Y dice with Z sides. This page was highly useful to me when writing my code:

 

http://en.wikipedia.org/wiki/Wikipedia:Reference_desk_archive/Mathematics/2006_September_25

 

The above link also contains a Perl script to do the same thing. My code is in Java, so if anyone would like to see it, let me know.