You can also use a bigger deck. 10% would mean 10 crit cards in a 100 card deck. The more cards you use, the less able a player will be to "count cards", so to speak, and try to line up guaranteed crits. At least without third-party tools to do the job for him. With in-place shuffling, you can mitigate the overhead of shuffling so that the larger decks do not become a performance problem. Set your deck size to correspond to the smallest increment of crit chance.

You wouldn't be able to guarantee one crit in 10 though. You could only guarantee one crit in 91 attacks.

Lets say player has 4% crit chance. We can implement arbitrary critical chances the following way:

Plain logic:

1) Create a deck size of 100 cards.

2) Mini deck size = 100 / 4 = 25

2) place 1 critical card at each minideck[0,25].

b) [optional prevent doublecrits] with the restriction that the distance between 2 critical cards is at least A.

if (critical Chance <= 10%) A = 5;

else if (critical Chance <= 20%) A = 2;

else if (critical Chance <= 30%) A = 1;

else A = 0;

Code: performance = O( mini-decks ).

int A ;
for each minideck
{
int randomPos = random( minideck.min, minideck.max);
if ( A + randomPos > minideck.max)
{
getNextMinideck().min = ( randomPos + A );
}
}

Lets see what points this algorithm covers:

1) arbitrary critical chance;

2) prevents too frequent crits if critical chance < 30%.

3) [predictable].If player knows critical chance, he knows A, he knows the source code (assume open source game),

he knows minideck size.

Can we remove point c? predictability ? what if we make minidecks variable size ?

instead size=25, make it size = random[20, 30].

There is one big problem that makes it complicated / impossible to implement in rpgs.

What if critical chance changes ? e.g a player uses an ability with +20% critical chance ?

Then it will have to reconstruct all decks from the beginning, losing the previous result = flawed critical chance calculation.

**Edited by n00b0dy, 13 July 2012 - 02:52 AM.**