U
/u/Status_Ant5860
Guest
**Building a distributed matchmaking and ELO rating system on a Minecraft network — architecture breakdown**
I'm working on a project I'm calling Ranked Index. The goal is a fully persistent, skill-based competitive environment — not a minigame server, but a structured ranked platform where match outcomes drive a real rating model.
I want to share the architecture and get feedback from people who've built at this layer before.
---
**System Structure**
The network separates into two layers:
- **Control layer** — matchmaking, ranking, player routing
- **Execution layer** — isolated match servers that run a single game and reset
Components:
- **Velocity** as the proxy — handles all connections and routing
- **PaperMC instances** — lobby (queue/UI), game servers (stateless match instances), dev
- **LuckPerms** on proxy + all servers via shared MySQL
- **MariaDB** as the single source of truth — stores player ratings, match history, outcomes
---
**Rating Model**
Standard ELO with a few additions:
- Dynamic K-factors based on match count (higher early, stabilizes over time)
- Upset multiplier — beating a significantly higher-rated opponent scales the gain
- Momentum and variance tracking as secondary metrics
- A composite Skill Index combining rating, consistency, and recent form
Matchmaking pulls from a queue and pairs players within a rating range. Once paired, they're routed to a game server, the match runs, result is written to the database, ratings update, players return to lobby.
---
**Current State**
Infrastructure is complete:
- Multi-server network running
- Proxy routing and secure forwarding working
- Shared database and global permissions live
Not yet built:
- Queue and matchmaking logic
- Player rating schema
- Game loop and result reporting
- Server reset lifecycle
---
**What I'm looking for**
Has anyone built queue/matchmaking logic at this layer before? Specifically:
Happy to go deeper on any part of this. Full architecture doc available if useful.
submitted by /u/Status_Ant5860
[link] [comments]
Continue reading...
I'm working on a project I'm calling Ranked Index. The goal is a fully persistent, skill-based competitive environment — not a minigame server, but a structured ranked platform where match outcomes drive a real rating model.
I want to share the architecture and get feedback from people who've built at this layer before.
---
**System Structure**
The network separates into two layers:
- **Control layer** — matchmaking, ranking, player routing
- **Execution layer** — isolated match servers that run a single game and reset
Components:
- **Velocity** as the proxy — handles all connections and routing
- **PaperMC instances** — lobby (queue/UI), game servers (stateless match instances), dev
- **LuckPerms** on proxy + all servers via shared MySQL
- **MariaDB** as the single source of truth — stores player ratings, match history, outcomes
---
**Rating Model**
Standard ELO with a few additions:
- Dynamic K-factors based on match count (higher early, stabilizes over time)
- Upset multiplier — beating a significantly higher-rated opponent scales the gain
- Momentum and variance tracking as secondary metrics
- A composite Skill Index combining rating, consistency, and recent form
Matchmaking pulls from a queue and pairs players within a rating range. Once paired, they're routed to a game server, the match runs, result is written to the database, ratings update, players return to lobby.
---
**Current State**
Infrastructure is complete:
- Multi-server network running
- Proxy routing and secure forwarding working
- Shared database and global permissions live
Not yet built:
- Queue and matchmaking logic
- Player rating schema
- Game loop and result reporting
- Server reset lifecycle
---
**What I'm looking for**
Has anyone built queue/matchmaking logic at this layer before? Specifically:
How are you handling server allocation — static assignment or dynamic spin-up?
For the reset lifecycle, are you running a full server restart or resetting world/state programmatically?
Any experience with inter-server messaging beyond basic plugin messaging — considering Redis for real-time sync
Happy to go deeper on any part of this. Full architecture doc available if useful.
submitted by /u/Status_Ant5860
[link] [comments]
Continue reading...