To address a valid criticism posted above that this is too easily exploitable by "tracking the future", let's change rule 2 of the original post to:
2. Instead of rolling a d20, you draw single card from the top of the deck and after that, remaining cards are reshuffled.
Now, let's stop theorizing and see some actual data. Here is a very simple implementation of proposed generator, already with the above change. This is raw permutation, without replacement or other tweaks. The code aims for simplicity, in real game code it would of course be parameterized by deck size, had a save/load routine, etc.
#include <algorithm>
#include <vector>
#include <random>
#include <iostream>
class CNewBG3RNG
{
public:
CNewBG3RNG() : gen ( dev() ) {}
void reset()
{
state.resize ( 20 );
std::iota ( state.begin(), state.end(), 1 );
std::shuffle ( state.begin(), state.end(), gen );
}
unsigned int operator()()
{
if ( state.empty() )
reset();
const unsigned int val = state.back();
state.pop_back();
std::shuffle ( state.begin(), state.end(), gen );
return val;
}
private:
std::vector< unsigned int > state;
std::random_device dev;
std::mt19937 gen;
};
int main()
{
CNewBG3RNG rng;
for ( size_t i = 0; i != 100; ++i )
std::cout << rng() << " ";
return 0;
}
And here is the result of single run, for 100 values:
9 2 12 13 8 16 15 1 20 14 3 17 5 7 6 10 11 19 18 4 2 13 14 17 3 11 1 9 10 18 4 16 6 8 5 12 20 15 7 19 1 13 12 15 9 3 4 19 7 5 14 6 20 18 2 17 10 11 16 8 3 15 16 17 9 8 18 19 11 14 13 5 12 1 7 2 10 4 20 6 7 15 13 17 2 1 19 4 14 3 9 12 11 20 16 6 18 10 5 8
And another one:
17 8 5 16 20 9 18 15 2 10 14 12 6 13 4 19 1 7 3 11 13 12 4 1 18 20 3 14 11 5 7 9 2 15 17 8 6 16 10 19 15 8 7 14 10 5 19 20 11 12 1 13 9 6 2 3 4 16 17 18 16 2 17 5 11 6 9 18 14 19 13 1 10 4 7 20 15 12 8 3 8 16 18 10 7 20 2 1 14 13 3 12 5 4 9 11 17 6 15 19
What we can see is quite nice pseudorandom sequence, with all possibilities uniformly spread out, without any patterns, anomalies or apparent predictability. Note that it still has some clusters of low values (e.g. 1 7 2) and high values (18 20) and it's possible to have two identical outcomes in row on cycle boundaries (examples do not show that). So, at 95% chance to hit, you can still miss twice in a row, but not thrice and it will happen very rarely. There is surely a hint of "real randomness" here. This is required to make things like Divination school or Lucky feat viable, you still will have use for them.
On the other hand, outcome e.g. 20 (crit hit) is present exactly 5 times in 100-element sequence, as well as 1 (crit miss) and any other value. Yet their positions are unknown in advance. The determinism is well-hidden behind an illusion of random, and that's the effect we want.
This effect can't be achieved by simply seeding the RNG as proposed in above post. Seeding RNG by anything other than physically obtained value means we ditch randomness completely and get fully determined sequence. Finding appropriate seed value (so that the sequence meets our conditions) requires conducting an exhaustive search. Result is a RNG code with additional "magic constant" (seed value). The sequence must be cut off at some point (when it stops fulfilling requirements) and be repeated afterwards. But why bother with RNG at all? Let's just write down some invented sequence according to requirements, and repeat this, e.g.
17 8 5 16 20 9 18 15 2 10 14 12 6 13 4 19 1 7 3 11 17 8 5 16 20 9 18 15 2 10 14 12 6 13 4 19 1 7 3 11 17 8 5 16 20 9 18 15 2 10 14 12 6 13 4 19 1 7 3 11 17 8 5 16 20 9 18 15 2 10 14 12 6 13 4 19 1 7 3 11 ...
The problem is: people will immediately complain "this is not random!", as it obviously is not. So we might try making longer sequence, but what's the point of all that? The permutation code is trivially simple (and sufficiently fast) already, no clear advantage of replacing it with table of numbers or a RNG with magical seed constant.
We of course must have several decks to prevent situations like "player gets all the hits, enemies all the misses" or vice versa. Separate decks are for saves, so that saves do not "steal" crits. Separate decks must be used for smaller dice (e.g. for damage). All of this is not a problem at all, doing several decks is exactly same programmer's effort as doing single deck. Just instantiate the class multiple times.
And we have a thing called Champion. This class means a bold sacrifice, you give up all goodies Eldritch Knight or Battlemaster gives you in exchange for lowered crit threshold (and nothing more). If you do so, you want to actually see him crit and want it ASAP. This system will give you these crits, but it is quite worth considering giving him his own deck for AR. This will actually guarantee he will crit for you, as you expect.
One of the posters above pointed out that you might find yourself in a situation you get only bad rolls left in current cycle and can't do anything about it. That's the situation when Divination school (Portent), or a Luck point might come in handy, of course these ablities have separate decks also. Game engine is really capable of handling thousands of decks like this, it is no performance problem and no extra effort.
Dynamically rearranged probabilities -- a different approach, certainly bringing different experience, might worth trying as another mode. It would be great if Larian provided several modes of randomness, selectable by the player. There is no "perfect" solution satisfying everyone, so let players choose. Also these things are not hard to code at all, this is not rocket science, just basics of programming.
