Introduction
When playing a computer card game one have to trust in some fundamentals. The deck is shuffled at random, random effects have equal probability.
Nobody expects bugs in the simplest things and therefore it is the easiest for them to sneak through unnoticed.
7 years passed since the release of Gwent Homecoming, almost 2 years of Gwentfinity and finally in August 2025 a bug in the Create mechanic got discovered. How many esports games got decided by a slight bias of game RNG? We would never know.
How The Bug Got Discovered?
In August 2025 due to Balance Council changes the pool of 5-cost crimes got narrowed to 4. Open, Sesame got nerfed to 6-cost, while earlier Eavesdrop got buffed to 4-cost. Shady Vendor is a card which played into ranged row Creates a 5-cost Crime. Create keyword means that the player gets randomly chosen 3 possibilities out of the pool to pick from.
Another circumstance which helped in the discovery in exactly this month was an overnerf of the popular Syndicate decks reliant on Open, Sesame! The unnerfed alternative was Cove Gangs netdeck, which got more popular than usual. This deck makes use of Shady Vendors to create Pulling The Strings – a 5-cost bronze crime card.
Create should choose randomly 3 out of 4 crimes at 5-cost and present them to player. It is easy to see that the probability to find Pulling the Strings should be equal to 3/4 = 75%.
Something weird though appeared – Vendor was finding PtS very consistently. Players noted it and started to look closely into every Vendor roll. PtS was always amongst the options to pick… nobody missed it a single time.
What Is Going On?
Trusting people who say “it never finds” or “it always gives” in card games may not be the best idea due to personal bias. I wasn’t aware of the bug myself because I didn’t play Cove Gangs. I heard about it from Shinmiri late in the August season. RyRy/Rykov done experiments with PtS and other Create cards and shared results with Shinmiri.
I learned from them and Shin about following observations:
- not only Vendors, but all create cards are bugged – the pool of 4 cards always gives one card guaranteed
- based on tests, the guaranteed card is likely the latest released one. Other keys are unclear; it is also unclear what decides between two or more cards released in one expansion (it is for example confirmed not to be ID)
- (RyRy via Rykov) the bug likely is caused by a combination of the initial list of cards not being randomized and a faulty shuffling module
Origins Of The Bug (Assumption)
How would you normally design Create algorithm? Perhaps just choosing 3 random numbers up to the length of the list of possible targets, then pulling respective cards by such index.
Alternatively you can shuffle the cards in the pool and just pick top 3 and show them to player. They would be random. If you have a shuffling module ready and working, this way should be even more convenient.
How to get a bug that one card is guaranteed in a pool of 4? It is actually very easy – we have to add a constraint that the pool is regarded as shuffled only if every card changed its position.
Then if we have ordered cards (1,2,3,4), shuffle them with this constraint and take 3 from the end, (1) would always be in the one of 3 last positions or the configuration is illegal.
As the initial list is ordered by some rule which is unknown in exact, the guaranteed card is always the same. For example Vendor would always offer Pulling the Strings.
Sidenote: there is another common Create card with exactly 4 options – Filavandrel at 5 power. I’ve made a test and Backup Plan (latest released out of these 5-cost specials) was created in 42/42 tries (100%).
If the assumption on bug origins is correct, then not only Create but also other stuff reliant on shuffling module may be bugged – we might have just hit the tip of the iceberg.
Testing The Wacky Algorithm
I asked ChatGPT to write in Python a simulation of the faulty algorithm with the rules stated above in order to determine the probability of Creating a card with respect to the initial position in the stack (let’s say we take 3 from the end). For 100k Creates the probability distribution is as follows:
The “5 of” columns are simulations including Runemage – a card which increases the num of displayed cards from 3 to 5. As we can see, exactly the same effect of a card being guaranteed should obey for “5 of 6” scenario (as expected if you think about it ;-)). Indeed, I’ve done a test with 6-elves pool for Backup Plan, where Trapmaker (again one of the latest released elves) appeared in 36/36 cases
The most interesting part here though is that the probability is uneven between presumably undistinguished cards. What is really the difference between 2nd and 4th card in a stack of 4 – the allowed positions are the same for both in the choice context. I didn’t really dive to the end into this topic, but that’s a good math excercise with a twist. If we go by permutations, then all of 2-4 should have even probs. If by a tree of events, then the prob of 2nd is 5/9 and for 3rd and 4th 10/13, but… we recognize we end up in illegal configurations sometimes.
Another basic conclusion is that not only 4-card pools are affected, but the bug impact decreases rapidly, so that for the difference of 3 or more between number of cards displayed and cards in the pool we can usually forget about the bug for practical play.
Let’s see if the Wacky Algorithm simulation results reproduce reality anyhow on the example of two common RNG cards: Shupe and Radeyah with Runemage.
Shupe
(all tables can be found in a google sheet here)
Model is reproduced pretty well by Shupe, but still in spite of ~100 tries for each Shupe the sample is not big enough to be certain.
Numbers above may be important for non-Runemage Shupe players both at in-game decisions and deckbuilding level. For example one can hope for safe pointslam / resilience value with Shupe: Knight, but the odds to destroy artifact look worse than 50/50 – perhaps other artifact removal should be included in the deck.
Renfri + Runemage
Here the sample is even smaller because the testing process with Renfri is even more tedious than with Shupe for a human tester. At peak I was able to denote 2×5 bleesings in a turn, but often I wasn’t fast enough therefore there is a difference between Blessings and Curses pool size. A more determined tester or a brainiac capable of automating the process is called for.
If the sample of 75 or 57 is enough to give a hint, then Renfri is quite biased for control (Pride = Destroy 8, Wrath = Damage by 6), while Blessings are biased for carryover (Patience = Cooldown 8, Humility = Boost by 4 after pass, Kindness = boost even/uneven).
Note that without Runemage the differences between Renfri probabilities likely wouldn’t be significant.
Closure
Shame on the CDPR for the Create bug – it shouldn’t have happened and probably isn’t even really a bug but a programming fault. I can’t understand how the core of the game could have been written without basic cautiousness. Whether the bug will be fixed is unclear to my knowledge, probably not given that the support for the game finished.
I’d love the Gwent community to continue research on the Create bug – sadly I don’t have enough time to do more myself in this regard. Especially it would be great to somehow make tests on big samples and also to figure out what are the exact keys by which the cards are ordered.
Happy Gwenting! Don’t believe only in the heart of cards, but also in the heart of an unkown programmer who thought exactly about you. If you missed the line, all tables can be found here.
lerio2