
Event Leaderboards
Event Leaderboards enable fair and structured competitive events that run alongside your core gameplay. Unlike standard leaderboards where new players might end up competing against veterans, Event Leaderboards place each player into a small cohort of similarly-skilled opponents, giving everyone a realistic chance to win. The system handles scheduling, matchmaking, reward distribution, and tier progression automatically.
Event Leaderboards support two types of competition:
- Time-based events: Players compete for rankings within a fixed time window. The cohort ends when the timer expires. This suits weekly tournaments, seasonal competitions, and league systems.
- Score-based events: Players race to reach a target score. The cohort completes when enough players hit the target. Players can then claim rewards and immediately roll into a new cohort for another round. This enables fast-paced, repeatable competitive loops within a single event phase.
Both types can be combined with tiers (e.g. Bronze, Silver, Gold leagues) to create long-term progression systems.
Key terms #
Phase #
A phase is a single cycle within an Event Leaderboard, governed by the event’s schedule (e.g. a daily reset, a weekly reset, or a fixed start/end time). Each phase gives players a fresh window to compete.
In time-based events, a phase typically contains a single competition: players join a cohort, compete until the timer expires, and claim rewards. In score-based events, a single phase can contain multiple rounds of competition where players complete a cohort, claim rewards, and re-roll into a new cohort, all within the same phase. See Multi-stage challenge for an example.
When a new phase begins, all roll counts reset and players start fresh.

Roll #
A roll is the act of joining a cohort within the current phase. When a player rolls, they are assigned to a cohort of opponents at their tier level and can begin submitting scores.
The first roll in a phase places the player into a cohort for the first time. Any subsequent roll within the same phase is a re-roll.
Re-roll #
Re-rolling happens when a player leaves a cohort and joins a fresh one with new opponents, all within the same active phase.
Re-rolling is only possible when all of the following are true:
- The player’s current cohort is complete, whether individually or for the entire cohort.
- The player has claimed their reward from the current cohort.
- The player has remaining rolls (that is, their roll count has not reached
max_rolls). - Any applicable roll cooldown (
roll_cooldown_sec) has elapsed. - The phase has not expired.
When a player re-rolls, their score from the previous cohort is preserved so other players in that cohort can still see it. The player then starts with a clean slate in the new cohort. See Ending a cohort.
Reroll count freeze #
Reroll count freeze controls whether a roll counts against the player’s max_rolls limit. When frozen, the roll is “free” and the player’s roll count does not increment.
This can be configured based on two outcomes:
Based on tier change (in change zones):
promotion_reroll_count_freeze: free roll if the player is promoted to a higher tierdemotion_reroll_count_freeze: free roll if the player is demoted to a lower tiernochange_reroll_count_freeze: free roll if the player stays in the same tier
Based on reward placement (in reward tiers):
reroll_count_freeze: free roll if the player finishes in this reward bracket
This mechanic is useful for encouraging specific behaviors. For example, making promotions “free” means players who are climbing through tiers can keep playing without burning through their roll limit.
Controlling re-rolls with max_rolls #
max_rolls is the maximum number of times a player can roll (join a cohort) within a single phase. It is the primary control for whether an event allows re-rolling, and effectively determines what type of event you are running.
max_rolls value | Behavior |
|---|---|
0 or 1 | Player joins one cohort per phase. This is the default behavior. 0 is treated as 1. |
N | Player gets 1 initial roll + (N-1) re-rolls within the phase. |
Each player’s roll count (the number of times they have rolled within the current phase) resets to 0 at the start of each new phase.
Cohort #
A cohort is a group of players competing against each other on a shared leaderboard. Each cohort contains up to cohort_size players and exists within the context of a single phase.
How players are assigned to cohorts #
When a player rolls, the system determines their current tier and finds them a cohort:
- Tier determination: New players start at tier 0. Returning players have their tier calculated based on previous performance using change zones or reward tier rules.
- Tier matching: The system looks for cohorts at the player’s current tier level.
- First-come-first-served: Within the tier, players are assigned to existing cohorts that have available slots.
- New cohort creation: If no suitable cohort has space, a new one is created.
- Re-roll exclusion: When re-rolling, the system excludes cohorts the player has already been part of, ensuring they always face new opponents.
Custom matchmaking: You can implement custom cohort selection logic through the SetOnEventLeaderboardCohortSelection callback for more sophisticated matching (e.g. skill-based matching beyond tiers, custom cohort assignments, or forced new cohort creation).
Cohort behavior in time-based events #
In time-based events, cohorts follow a straightforward lifecycle:
- The cohort starts when players are assigned and ends when the phase timer expires
- All players compete for the full duration of the phase
- No early completion is possible
- Re-rolling within the phase is not practical, since the cohort only ends when the phase ends
Cohort behavior in score-based events #
In score-based events, cohorts can complete before the phase timer expires:
- A player’s cohort can complete when they reach the
score_target - Individual players can complete their cohort independently
- When enough players reach the target to fill all reward slots, the entire cohort locks and no new players can join it, since the results are already determined
- The phase timer still acts as an ultimate deadline
Ending a cohort #
A cohort ends when any of the following conditions are met. Which conditions apply depends on which configuration fields are set:
- Phase expires: The phase timer runs out. This always applies regardless of other settings.
- Player hits score target: If
score_targetis configured, a player’s cohort completes for them individually when they reach the target score. Everyone else may remain in the cohort. - Score target saturation: If both
score_targetandscore_target_playersare configured, the cohort completes everyone when that many players reach the target. No new players can be assigned to a completed cohort. - All players timed out: If
score_time_limit_secis configured and the cohort is full, the cohort completes when every player’s individual time limit has expired. - All attempts exhausted: If
max_num_scoreis configured and the cohort is full, the cohort completes when every player has used all their score submissions.
These conditions are independent. When multiple are configured, whichever triggers first wins. Once a cohort is complete for a player, they can claim rewards but can no longer submit scores.
Claim #
Claiming is the act of collecting rewards from a completed cohort. A player can claim when their cohort is complete and they haven’t already claimed.
For convenience, the roll endpoint accepts a claimReward parameter that claims the current reward and rolls into a new cohort in a single call. This is the recommended approach for re-rolling, as it reduces round-trips and avoids the player needing to manually claim before rolling. See the Unity SDK guide for usage examples.
Rewards #
Rewards are prizes distributed to players based on their final ranking within a cohort. Each Event Leaderboard defines one or more reward tiers — rank-based brackets that map finishing positions to prizes. For example, an Event Leaderboard might define three reward tiers: ranks 1–3 receive a “Gold-tier” reward, ranks 4–10 receive a “Silver-tier” reward, and ranks 11–20 receive a “Bronze-tier” prize. Each reward tier can also trigger a tier promotion or demotion (see Tiers below). For more details on reward contents, see Rewards.
Tiers #
Tiers represent skill or progression levels that persist across phases. Players can move up or down tiers based on their performance, creating long-term progression beyond individual events. Common examples include league systems that see players progress from “Bronze III” to “Grandmaster I” over the course of several seasons. Players always start at the lowest tier and cannot drop below it or exceed the maximum configured tier.
Change zones #
Change zones define the promotion and demotion rules for each tier. A change zone specifies what percentage of top performers advance to a higher tier and what percentage of bottom performers drop down. These can be configured differently per tier to create varied competitive dynamics.
Time-based events #
In time-based events, players join a cohort, compete for the highest score over a fixed time window, and claim rewards when the timer expires. Use this for weekly tournaments, seasonal events, ranked leagues, or any competition where all players compete over the same duration.
General flow:
- Player rolls into a cohort at the start of the phase
- Player submits scores throughout the phase
- Phase timer expires, completing the cohort for everyone
- Player claims rewards based on final ranking
- Next phase begins
Key characteristics:
- Cohorts always run for the full phase duration
- All players in a cohort experience the same start and end
Example: Weekly tournament #
This is the simplest Event Leaderboard pattern and works well for any game with a core gameplay loop that produces scores. The recurring schedule creates a natural reason for players to return each week.
How it works: Every Monday a new phase begins. Players are placed into cohorts of 50 and compete for the highest score over 7 days. When the phase ends on Sunday, rewards are distributed based on final rankings. A new phase begins the following Monday.
Example configuration
| |
Score-based events #
In score-based events, players race to reach a target score. Once the target is hit, the cohort completes for that player, even if the phase timer hasn’t expired yet. Combined with max_rolls > 1, this enables a loop where players compete, finish a cohort, claim their reward, and then roll into a new cohort, all within a single phase.
Use this for race-to-the-finish challenges, multi-round competitions, and events where players can win and play again for more rewards.
General flow:
- Player rolls into a cohort
- Player submits scores, racing toward the
score_target - Player (or enough players) hits the target, completing the cohort
- Player claims rewards
- If rolls remain, player rolls into a new cohort with new opponents
- Repeat until out of rolls or the phase expires
Key characteristics:
- Cohorts can complete before the phase timer expires
- Players can participate in multiple cohorts within a single phase
max_rollsis set higher than1to enable re-rollingscore_targetdefines the completion threshold
Example: Race-to-the-finish #
Players race to reach a target score before their opponents. The first players to hit the target win rewards, and once the race is over, everyone can immediately roll into a new cohort for another round. Change zones promote top performers and demote those in last place. This type of Event Leaderboard is used in many popular games, such as Sky Race from Royal Match.
How it works: A weekend event runs Friday through Monday. Players are grouped into small cohorts of 5 and race to complete 15 levels (represented as a score target of 15). The first 3 players to finish claim rewards. After a race ends, all players can immediately join a new race with fresh opponents. There is no limit on races per phase. At the end of each phase, change zones determine who moves up or down across 5 tiers (Bronze through Diamond).
Example configuration
| |
Variation: cooperative completion
If you want every player to have a chance to finish and earn rewards, set score_target_players equal to cohort_size. For example, with cohort_size: 7 and score_target_players: 7, all 7 players can reach the target and earn position-based rewards. The cohort only completes when all players finish (or the phase timer expires). This shifts the feel from competitive elimination to a cooperative race where everyone can succeed, but faster players still earn better rewards.
Example: Multi-stage tournament #
Players progress through escalating difficulty stages, implemented as tiers. Each stage has a harder target, a smaller cohort, and better rewards. Only the first player to finish each stage advances, and everyone else stays and can try again immediately. This is another popular implementation of event leaderboards, found in titles such as Royal Match’s Space Missions.
How it works: A weekend event features 3 tiers. All players start at tier 3. Within each stage, players race to complete a streak of consecutive levels. The first player to hit the target wins, advances to the next tier and faces tougher competition. Players who don’t win stay at their current tier and re-roll into a new cohort. At the end of the event, everyone resets back to tier 3.

Example configuration
| |
Player progression #
Event Leaderboards implement a tier system that promotes progression over time:
- Players are assigned to tiers (e.g. Bronze, Silver, Gold) with tier 0 being the lowest
- The system supports configurable numbers of tiers
- Each tier can have different reward structures, cohort sizes, score targets, and competitive dynamics via
tier_overrides
Promotion and demotion #
Change zones (primary method): The system uses configurable promotion and demotion percentages to determine tier movement. A promotion percentage defines what portion of top performers advance to higher tiers, while a demotion percentage determines how many bottom performers drop down. These percentages can be configured per tier to create different competitive dynamics at various skill levels.
Reward tiers (fallback method): When change zones aren’t configured, the system uses reward tiers for advancement. Each reward tier defines specific rank ranges and their associated tier changes, allowing players within certain positions to move up, down, or remain in their current tier.
Handling idle players #
The system includes configurable rules for handling inactive players. When idle demotion is enabled (demote_idle in change zones), players who fail to submit scores are automatically demoted. The system calculates tier drops based on how many complete phases they’ve missed, with a configurable maximum limit (max_idle_tier_drop) that caps the number of tiers they can drop when they return. Idle demotion only applies when a phase has fully expired; re-rolling within an active phase does not trigger idle penalties.
Additionally, tier_delta_per_phase can be used to apply an automatic tier adjustment when a phase expires, on top of regular change zone rules. For example, setting it to -1 creates a decay mechanic where players must actively participate to maintain their tier.
Calculating tiers #
Tier changes are calculated when players roll into a new phase, considering:
- Previous rank within the cohort
- Whether the player was idle (no score submissions)
- Applicable change zones or reward tier rules
- Maximum tier drop limits for idle players
- Any
tier_delta_per_phaseadjustments
Players cannot drop below tier 0 or exceed the maximum configured tier, ensuring the system maintains appropriate boundaries for all participants.
Configuration #
This section describes every configurable property of Event Leaderboards. The JSON schema defines an event_leaderboards object containing an individual object for each event leaderboard you wish to define. You can configure as many Event Leaderboards as needed for your game. Depending on your use case, some fields will not be needed at all. See Quick reference.
| Property | Type | Description |
|---|---|---|
event_leaderboards | string:EventLeaderboard | A map of all event leaderboards. |
EventLeaderboard config #
Properties that describe the behaviour of the overall Event Leaderboard. For complete examples of various JSON configurations, see Time-based events and Score-based events.
| Property | Type | Description |
|---|---|---|
name | string | The display-friendly name for this event leaderboard. |
description | string | The description text for this event leaderboard. |
category | string | The category that this event leaderboard belongs to. |
ascending | bool | Whether the records are sorted in ascending order or not. |
operator | string | The leaderboard operation (e.g. set, best, incr, or decr). |
reset_schedule | string | The reset schedule expressed in CRON format. |
cohort_size | int | The size of the cohort that participants will be grouped into. |
additional_properties | string:string | A map of key value pairs that can contain additional context. |
max_num_score | int | Maximum number of score submissions per participant per reset. A value of 0 means there is no limit. |
reward_tiers | string:[]RewardTier | The various rewards (as an array) per tier, keyed by tier as a string. |
change_zones | string:ChangeZone | The promotion and demotion zones per tier, keyed by tier as a string. |
tiers | int | The number of tiers that users can progress through. |
max_idle_tier_drop | int | The maximum number of tiers that an idle user can be demoted. |
start_time_sec | int64 | The start time, expressed as a UNIX timestamp. |
end_time_sec | int64 | The end time, expressed as a UNIX timestamp. |
duration | int64 | The duration in seconds for the active period. |
max_rolls | int | Maximum number of times a player can roll (join a cohort) within a single phase. Defaults to 1 (classic single-roll behavior). Set higher to enable re-rolling. |
score_target | int64 | The score a player must reach for their cohort to complete. When set to 0 (default), cohort completion is time-based only. |
score_target_players | int64 | The number of players that must reach the score_target for the cohort to complete. Defaults to 1 when score_target is set. It is recommended that this value aligns with the number of rewarded positions in reward_tiers. |
score_time_limit_sec | int64 | Per-player time limit in seconds (from their roll time) to submit scores. When all players in a full cohort have timed out, the cohort completes. |
roll_cooldown_sec | int64 | Minimum number of seconds that must elapse between a player’s rolls. The cooldown timer is capped at the phase expiry. Can be overridden per reward tier. |
tier_delta_per_phase | int64 | An additional tier adjustment applied when a phase expires, on top of regular change zone promotion/demotion rules. |
tier_overrides | string:TierOverride | Per-tier overrides keyed by tier as a string. Overridable fields: name, description, cohort_size, max_num_score, score_target, score_target_players, score_time_limit_sec, tier_delta_per_phase. |
Example tier_overrides
Use tier_overrides to give each tier its own settings. Any field not specified in the override inherits from the top-level config:
| |
RewardTier config #
Properties that describe the rewards players receive for achieving certain rankings within their tier, including any upward or downward progression. See Promotion and demotion.
| Property | Type | Description |
|---|---|---|
name | string | The display-friendly name for this reward tier. |
rank_max | int | The maximum rank number (inclusive) that is eligible for this reward. |
rank_min | int | The minimum rank number (inclusive) that is eligible for this reward. |
reward | Reward | The rewards that a user should receive when within the eligible range. |
tier_change | int | Optionally defines a change in tier the user should receive for getting this reward. |
roll_cooldown_sec | int64 | Overrides the global roll_cooldown_sec for players who land in this reward tier. For example, top finishers can be given a shorter (or zero) cooldown. |
reroll_count_freeze | bool | When true, a roll where the player lands in this reward tier does not count against max_rolls, giving the player a free roll. |
ChangeZone config #
Properties that determine the percentile of players who should move up or down a tier. See Promotion and demotion.
| Property | Type | Description |
|---|---|---|
promotion | float64 | The percentage (expressed as a number between 0 and 1) of users at the top of the cohort who will be promoted. |
demotion | float64 | The percentage (expressed as a number between 0 and 1) of user at the bottom of the cohort who will be demoted. |
demote_idle | bool | Whether or not idle users in the cohort should be automatically demoted. |
promotion_reroll_count_freeze | bool | When true, a roll that results in the player being promoted does not count against max_rolls, giving the player a free roll. |
demotion_reroll_count_freeze | bool | When true, a roll that results in the player being demoted does not count against max_rolls, giving the player a free roll. |
nochange_reroll_count_freeze | bool | When true, a roll that results in no tier change does not count against max_rolls, giving the player a free roll. |
use_max_cohort_size | bool | When true, promotion and demotion percentages are calculated based on the max cohort size rather than the current number of players in the cohort. |
Score operators #
The score operator determines how new score submissions are processed. Can be overridden on the client.
| Operator | Behavior | Notes |
|---|---|---|
INCREMENT | Adds new score to existing total | Cumulative scoring - all submissions contribute to team total |
DECREMENT | Subtracts new score from total | Penalty-based events - mistakes reduce team score |
SET | Overwrites with most recent score | Latest submission replaces previous - no accumulation |
BEST | Keeps optimal score based on sort | Ascending: lower is better; Descending: higher is better |
Quick reference #
Not every field is relevant to every event type. The table below shows the primary fields for each type of competition. See the full property tables above for all available fields.
| Field | Time-based | Score-based |
|---|---|---|
name | Required | Required |
description | Required | Required |
operator | Required | Required |
ascending | Required | Required |
cohort_size | Required | Required |
tiers | Required | Required |
duration | Required | Required |
reset_schedule or start_time_sec/end_time_sec | Required | Required |
reward_tiers or change_zones | At least one | At least one |
max_idle_tier_drop | Optional | Optional |
score_target | — | Required |
max_rolls | — | Required |
score_target_players | — | Optional |
score_time_limit_sec | — | Optional |
roll_cooldown_sec | — | Optional |
Event Leaderboards vs Challenges #
While both Event Leaderboards and Challenges provide competitive gameplay features, they serve different purposes and have distinct characteristics. Event Leaderboards are designed for structured, recurring competitive events with predefined cohorts and tiered progression. Challenges, on the other hand, are intended for on-demand and player-driven competitive experiences.
The following table outlines their differences:
| Property | Event Leaderboards | Challenges |
|---|---|---|
| Structure | Recurring or one-off events with predefined cohorts and tiered progression. | Player-driven competitions with limited player customization. |
| Scheduling | Fixed schedules with predetermined periodic cadence. | Flexible, on-demand scheduling with player-defined start times. |
| Matchmaking | Automated matchmaking (based on skill, region, etc) with tiered cohorts. | Players can invite other players to join their events or make them open to the public. |
| Progression | Long-term progression through tier system. | Individual competition-based progression. |
| Use Case | Structured competitive seasons and tournaments. | Friendly competitions and community events. |
The key distinction is that Event Leaderboards are designed for creating fair, engaging competitive experiences that scale well with large player bases, while maintaining player engagement through tiered progression systems.
