How EaseCation runs its games
After a player presses Play, the network checks the connection, finds a match, starts a room, runs the game and records the result. Much of what EaseCation has built over the past ten years sits inside that one match.
From Nukkit plugins to a complete game framework.
When EaseCation first launched, its mini-games were plugins running on a single Nukkit server. As the number of players and games grew, and mobile, desktop and Java Edition clients joined, that setup quickly reached its limits.
Today, player connections pass through proxies, lobbies and game clusters. Shared services handle accounts, parties and tasks, while client extensions and production tools support the experience and day-to-day operation.
What happens when a player starts a match
A match can be read as four steps, from joining the network to saving the final result. Shared player services and production tools support the entire path.
Sign-in, protocol versions, resources and client capabilities are checked before the player enters the network.
Parties, matchmaking and room allocation move players from a shared lobby to an available game instance.
CodeFunCore manages the room lifecycle while each game supplies its own rules, maps and presentation.
Results update accounts, tasks and rankings. Behaviour records support review, appeals and diagnostics.
Testing, releases, monitoring and diagnostics run across the whole path.
Mini-games share one way of running a room.
Every mini-game creates a room, waits for players, starts, runs, settles the result and cleans up. CodeFunCore handles this repeated work, along with player state, events, persistence and communication between servers.
On top of that foundation, each game builds its own rules, teams, maps and presentation. Bed Wars, Rune Legend, Biochemical Escape and Disaster Games all use the same framework without losing what makes each of them different.
Lobbies, matchmaking and game servers each do one job.
The entry layer accepts the connection, the lobby receives the player, and matchmaking finds an available room. When a party joins a queue, the system also keeps its members together while moving them between servers.
Accounts, friends, guilds, tasks and the economy continue across matches, so shared services maintain them separately. A game server can then start, stop or update without taking the rest of the network with it.
Different clients still join the same game.
EaseCation serves Bedrock players on mobile and desktop as well as Java Edition players. Supporting them involves more than translating packets: interfaces, resources, movement, entities, cosmetics and camera behaviour all need to make sense on each client.
Client extensions add settings, diagnostics, replay and richer presentation where the server cannot do the whole job. The server still decides the game rules, keeping each client on the same terms.
Settlement and records continue after the match.
When a match ends, its result updates accounts, tasks, the economy and rankings. Behaviour records and replay tools help the team reproduce faults and review reports with the full sequence of events in view.
Game configuration can be updated separately from core code. Builds, tests, releases, monitoring and client diagnostics keep each change under control. Server-side validation and records support fair play, and the team continues to improve its anti-cheat work.
Sharing our groundwork with the Minecraft community.
Over the years, we have put reusable server, compatibility and content tools on GitHub. The list runs from Nukkit and ViaBedrock to animation, cameras, model conversion and replay, all shaped by real work on EaseCation.