Objective
Reduce matchmaking queue times and increase effective player liquidity by introducing an optional asynchronous battle system that shares the same matchmaking pool as live battles.
Overview
Ranked Modern battles would support two matchmaking modes:
Players may choose if he is entering live battle or putting a battle in queue.
There could be only up to 50 games be put in queue from each player.
Shared Matchmaking Pool
The key to this proposal is that Live and Async battles are matched together.
When a Live player enters matchmaking, the server searches in the following order:
From the Live player's perspective, nothing changes. The battle feels exactly like a normal Ranked battle. If no opponent is found within 60 seconds Live player is matched with Async battle team.
This dramatically increases available opponents without requiring more players to be online simultaneously.
Rewards
Async battles provide convenience and eliminate waiting, so rewards should be slightly reduced.
All other progression, including rating, Focus progress, and rewards, remains unchanged.
This model incensitives live playing with small boost on SPS earnings. While also encourages async battles with additional glint and slight reduce in SPS rewards.
**Double glint option / SPS burn **
Not applicable in async battles.
Queue Expiration
To prevent abandoned battles:
Async battles automatically expire after 48 hours if unmatched.
Players receive a notification.
They may reclaim or requeue the battle.
No battle remains permanently stuck.
Last 50 hours in a season entering Async battles is disabled.
Benefits
For Async Players
For Live Players
For Splinterlands
Negative side
Async Battles - putting tactics blindly
I dont have a solution for this. This is something that you sacrifice in order to skip the waiting time to be matched with an opponent. We are doing the same in brawls and tournaments.
Matchmaking
From live player perspective, when 60 seconds passes the system is matching him with async battle in a way:
Implementation Flexibility by team
This proposal focuses on solving the matchmaking liquidity problem while minimizing development effort. The exact implementation details are intentionally left flexible so the development team can choose the solution that best fits the existing architecture.
The following elements are suggestions rather than requirements:
The only core principles are:
By leaving these implementation details flexible, the team can iterate on balance and user experience without changing the underlying concept. This should also allow the feature to be implemented more quickly, as it does not require a specific UI design or fixed reward model to deliver its primary objective of improving matchmaking liquidity.
