How Slotathon Researches Slot Mechanics
Slotathon researches slot mechanics by starting with how the game behaves, then tying specific claims back to the evidence that supports them.
Feature names, marketing labels and familiar patterns can be useful clues, but they are not enough on their own. The behaviour comes first.
It sounds simple, but slots are full of edge cases. Two providers can use different names for very similar behaviour, while two games using the same label can work quite differently. A feature can also change between builds or markets.
Those differences stay visible rather than being flattened into one tidy answer.
What we research
We start with how a game behaves: how a win is formed, what starts a feature, what changes once it begins, whether progress carries over, resets or stops, and how one mechanic interacts with another.
For each game, we look at individual mechanics in context rather than treating the slot as one bundle of features. We record the factual points we can support about each behaviour, such as its trigger, effect, progression, persistence, reset or limits.
Where a game has a materially different documented build or market configuration, that is treated separately too.
The evidence we use
We prefer direct game and first-party evidence wherever it is available. That can include in-game rules, help screens, paytables, official developer documentation, factsheets, game sheets and public developer pages.
Certification or regulatory material can also matter, particularly when the point being checked is specific to a jurisdiction, build or betting mode.
Third-party reviews have a different role. They can flag contradictions or details worth another look, but they do not settle the question on their own.
Search results, competitor pages and SEO tools help us understand how people talk about a mechanic and what they ask. We use that for wording and coverage, not as mechanic evidence.
Some supporting evidence is only available in-game or through authenticated developer systems. In those cases we can record what was reviewed and what it supports without republishing restricted material.
A source only proves the point it supports
We do not treat one source as proof of everything about a game.
An official page might confirm that a feature exists but say nothing about how long it persists. A paytable might explain the reset rule but not whether the same configuration is offered in every market. A developer label can tell us what the provider calls a feature without proving that every similarly named feature behaves the same way.
Each source counts only for the point it supports.
This is also why provider terminology is recorded without letting the name dictate the classification. Cascading Reels, for example, can appear under labels such as Tumble or Avalanche. What matters is the behaviour after the qualifying win, not the branding on the feature.
When sources disagree
Conflicting evidence is not unusual. A third-party review might describe a feature one way while the in-game rules say something else. Two official documents can also refer to different builds or dates.
When that happens, we compare what each source is describing, how direct it is, which build or market it relates to and exactly which claim it supports.
Wolf Gold is a good example. One Pragmatic Play overview contains conflicting details about its Free Spins, including the number of starting spins and which reels form the giant symbol. The current in-game rules, official game page and UK rules agree on five Free Spins and reels 2-4, so that is the version our published explanation follows. The conflicting wording stays in the research record.
If stronger evidence resolves the conflict, the published explanation follows it. Where only part of the issue is established, we qualify the wording. If the evidence still cannot settle the point, we leave it unresolved or leave it out.
We do not quietly merge conflicting versions just because a single answer would be easier to publish.
Different builds and Great Britain
The same slot can exist in more than one documented configuration.
RTP settings, betting modes, feature availability and other rules can differ between documented builds or jurisdictions. When that difference affects the meaning of a claim, Slotathon keeps the configurations separate.
Big Bass Splash shows why. Its general game data documents Buy Free Spins where the feature is allowed, while the UK certification material we reviewed states that Buy Feature should not be enabled from the backoffice.
Because Slotathon is written for Great Britain, the UK evidence controls what we say about GB availability.
What we do not infer from a mechanic
A mechanic tells you how part of a game behaves. It does not, by itself, tell you the game’s RTP, volatility, hit frequency, feature frequency, maximum win or likelihood of winning.
It also does not show that a game is more rewarding, more generous or better value.
Those characteristics are separate. We only state them when the underlying evidence specifically supports them.
The same principle applies to familiar versions of a mechanic. A common implementation is not automatically the definition, even when it appears repeatedly across well-known games.
How we choose examples
Examples on Slotathon are there to teach something.
A game might show the basic behaviour especially clearly, demonstrate an important variation, or sit right on the boundary between two mechanics that are easy to confuse.
An example is not a ranking or endorsement. Showing a game here does not mean we think it is better simply because it demonstrates a mechanic clearly.
We also do not try to mention every game we have researched. A shorter set of well-supported examples is usually more useful than a long catalogue with very little explanation.
Before a page is published
Before publication, factual claims are checked against their supporting evidence and against what we mean by the mechanic being described.
If the subject is sensitive to market or build differences, the jurisdiction wording is checked as well.
The copy is then edited for clarity. Evidence-heavy writing can easily become stiff or over-technical, so the aim is to keep the qualifications that matter while explaining the idea in ordinary English.
Drafting and editing may use AI assistance, but factual claims are checked against the underlying research evidence before publication.
Links are added where another mechanic or example genuinely helps explain the point, not simply for the sake of adding more links.
Corrections and stronger evidence
Publishing a page does not close the research.
If stronger or more relevant evidence changes our understanding of a game or mechanic, the explanation should change with it. Keeping an older claim just for consistency would defeat the purpose.
We do not promise that every page is rechecked on a fixed timetable. If better evidence changes the picture, we update the explanation.
Behaviour first, labels second
We start with evidence of how the game behaves, then document the variants, exceptions and boundaries.
That is the same approach behind the guides in our Slot Mechanics section.