Minecraft 游戏技术
EnderRealm Game Tech
From accounts, configuration, and server scheduling to the lobby, minigame room, and settlement, EnderRealm's Minecraft core backend spans the whole chain.
One backend across the Minecraft service
Its shape is similar to a web backend: one API, authentication, business logic, and database. A Minecraft platform also operates a fleet of continuously running servers, so the backend additionally handles service governance, instance scheduling, load balancing, and cross-server coordination. Proxies and Paper servers call these capabilities through API keys.
Unified data services
Structured data for accounts, economy, configuration, permissions, settings, progression, and results comes from the core backend.
Server registration and status
Proxies, Paper servers, and other runtimes can register themselves, reporting liveness, heartbeats, leases, capacity, and runtime status.
Scheduling and load balancing
The proxy reads available downstream servers and load information from the backend, while reporting its own and downstream status back for coordinated routing.
Runtime coordination
Paper-side lobbies, minigame rooms, shared services, and proxies use API keys to read backend data, register services, and report status.
Registration, heartbeats, leases, scheduling, and load balancing form its control-plane responsibilities; worlds, entities, combat, and in-match state are executed by real-time runtimes.
From stacked plugins to a self-built distributed architecture.
EnderRealm began on a traditional plugin architecture, where modes were assembled from plugins and different versions only barely fit together. As modes and players grew, that architecture quickly hit its limit.
Today, FastAPI is the core backend of the Minecraft platform. Structured data including server registration, runtime status, accounts, permissions, configuration, economy, player settings, progression, and match results is accessed and managed through this backend.
It also connects service registration, heartbeats, leases, instance allocation, and load balancing, so proxies and game runtimes know which services are available, where players should go, and which results must be persisted reliably after a match.
How does a single minigame run?
From joining a server to saving a result, a minigame can be split into four stages. The core backend handles data and coordination, while the lobby and minigame rooms inside Paper handle low-latency gameplay.
Access & Compatibility
Handle login, protocol versions, and client capabilities so different devices can enter the server smoothly.
Lobby & Scheduling
The proxy and lobby read registration, downstream-server, and load information from the backend, then route players to an available instance.
Minigame Room
The unified room runtime inside Paper manages the lifecycle; each mode only implements its own rules and maps.
Settlement & Records
The runtime submits a result; the core backend updates accounts, economy, and records for review and troubleshooting.
Accounts, permissions, economy, and i18n are shared across all minigames; testing, release, monitoring, and diagnostics run throughout the chain.
Different clients, the same game.
EnderRealm serves both Java and Bedrock players. Beyond the protocol, the UI, resources, movement, and presentation all need per-client adaptation. BungeeCord + Geyser provide the proxy-side cross-platform entry path, while Floodgate works with both the proxy and downstream Paper runtimes so Java and Bedrock players can enter the same server.
Whichever client you join from, the rules are the same: runtimes judge live gameplay, while the core backend persists long-lived data such as currency, settings, and match results.