Ampmp11 wrote: It does seem like cascades are happening with much more frequency though ...
Volrak wrote: I'd say my games have been fairly normal cascade-wise. But that's completely non-notable and almost too uninteresting to post. Almost... except I also get the chance to explain to anyone who doesn't know what confirmation bias is: it's this thread.
Sorin81 wrote: What I've run into with this event more so than before is the ai having the ability to string together insane amounts of mana cascades. Leaving me with very little to work with. Has this been a problem for anyone else in this event?
buscemi wrote: Mersicide Mersicide Mersicide Elvin1972 Mersicide
Volrak wrote: I should add - It's of course not impossible that the devs spent weeks working on a gem drop algorithm whose effect is to control how often cascades happen, in such a way as to produce a result that's statistically indistinguishable from what you'd expect if gem drops were simplistically random.
Ironwolf wrote: I definitely have noticed an increased rate of cascades and ranted about it during that event. I have an 87% win rate and lost 6 out of the initial 9 you start with due to the insane cascades. The AI was casting 2-3 cards per turn. It is definitely programmed to do so. Most often the AI has ignored it's own color matches to get landfalls, but I've noticed it has been making color matches that seem off at first (e.g. red for Kiora) only to have it cascade 7 times. And I'm not talking the combinations you can see and plan to cascade - I'm talking about the ones that are off the board that the AI only knows. I get that they have to program the AI a little to offset the human factor and not storing loyalty, not eliminating weak creatures on the board (from say, a Frog or Moon), but I think they balanced it a little too far in one direction that event.
Volrak wrote: I should add - It's of course not impossible that the devs spent weeks working on a gem drop algorithm whose effect is to control how often cascades happen, in such a way as to produce a result that's statistically indistinguishable from what you'd expect if gem drops were simplistically random. But if that's what they really did, then based on the evidence so far, it was even less useful than making the UI blue. I should also add that more evidence is always awesome and I don't want to discourage that aspect. buscemi wrote: Mersicide Mersicide Mersicide Elvin1972 Mersicide Wrong thread perhaps.. nobody's talking about matchmaking, which is known to have a strong non-random component.
buscemi wrote: Mersicide Mersicide Mersicide Elvin1972 Mersicide See also this thread:viewtopic.php?f=31&t=58559 I think it's highly relevant when talking about shonky RNGs in a game to consider other shonky RNGs in the same game.
buscemi wrote: We don't *know* that matchmaking has a string non-random component
Volrak wrote: buscemi wrote: I think it's highly relevant when talking about shonky RNGs in a game to consider other shonky RNGs in the same game. I'm not concerned about the possibility that matchmaking biases imply systemic biases in all random game events, because underlying RNG library calls are simple and well tested (by thousands of apps), while any event-specific code (e.g. matchmaking) by definition won't affect other types of RNG result (e.g. card drops).
buscemi wrote: I think it's highly relevant when talking about shonky RNGs in a game to consider other shonky RNGs in the same game.
Volrak wrote: buscemi wrote: We don't *know* that matchmaking has a strong non-random component I for one think we can safely eliminate the null hypothesis.
buscemi wrote: We don't *know* that matchmaking has a strong non-random component
buscemi wrote: The assumption that the dev team have used standard library functions to handle randomness without substantial modification is a very large one. The library functions do work well, but their results may have been fed through any number of other functions, and the random numbers generated may have become tainted on their way to influencing graphical elements on the screen. It's even possible the library functions themselves may not have been used. Don't laugh. I've worked for places that have done that.
buscemi wrote: However, if the *intention* of the dev team was to make matchmaking random, and whilst in attempting to do this they somehow ended up with a system that is clearly non-random in practice, then it's fair to assume that any of the systems in the game which were intended to be random can be skewed to any degree.
buscemi wrote: Hibernum's handling of player decks illustrates that they are a team that don't think that pure random is 'random enough' to eliminate perfectly normal attributes of randomness like clumpyness. Doesn't it seem at least plausible that a team which seeks to reduce clumpyness in card draw would also seek to reduce it in cascades, an area of the game which players frequently complain about? Doesn't Hibernum's past history also suggest the possibility that if they'd got the code wrong, and it did the opposite of what it was supposed to, they'd leave it in place because it wasn't a priority and get on with solving a different problem?