Roadmap¶
EmberMC is built in twelve milestones, in a deliberate order. Each one goes through the same loop before it is called done:
No milestone proceeds past a broken build, and no optimisation is written before its plan records the Paper behaviour it changes, the bottleneck it addresses, what plugins could observe, which thread runs what, the improvement expected, and how that improvement will be measured.
Priorities, in order¶
- Server stability
- Correct gameplay behaviour
- TPS / MSPT consistency
- Plugin compatibility
- Exploit prevention
- Entity optimisation
- Chunk optimisation
- Network efficiency
- Memory efficiency
- Administrator control
Nothing lower on this list ever wins against something higher. A benchmark number is not a reason to remove vanilla behaviour.
The milestones¶
✅ 1 · Fork infrastructure and branding¶
Paper a2a42c5b (Minecraft 26.2) built unchanged, then forked with
paperweight-patcher into ember-api, ember-server and ember-checkstyle.
Brand embermc:ember, reporting Paper-compatible to plugins. /ember status
and /ember version. Startup banner. Tested on a real Ember server with the
Ember suite, floodgate and packetevents loaded.
✅ 2 · Configuration framework¶
ember-global.yml and per-world overrides on Paper's own Configurate-based
configuration system, so there is one YAML stack, not two. Versioned, validated,
migration-friendly. Presets - Vanilla, Balanced (the default),
Performance, Extreme - set the defaults; anything you set explicitly
wins. Every option is marked reload-safe or restart-only, and /ember reload
touches only the former.
✅ 3 · Profiler and instrumentation¶
Tick-phase timing that costs nothing when the profiler is off. /ember profiler,
/ember entities, /ember chunks, /ember worlds, /ember plugins with
per-plugin tick cost and honest caveats about attribution. A lag-spike watchdog
that captures context automatically when a tick blows past a threshold and
writes a report an administrator can read. An internal metrics registry and an
opt-in Prometheus-style endpoint. Shipped alongside: the tuner (/ember tune)
and the first measured default change, Alternate Current redstone.
This comes before any optimisation on purpose: you cannot make hot paths faster until you can see them.
✅ 4 · Entity engine (measured: -29/-38/-62% entity phase)¶
Distance-tiered ticking - full, reduced, minimal - measured from the nearest active player, built on Paper's activation range rather than replacing it. Overridden by anything that matters to gameplay: a mob targeting a player, in combat, on a lead, carrying a passenger, a projectile in flight, an item near a player. A mob never freezes in front of someone. Per-world and per-type tuning.
5 · Pathfinding and collision¶
A short-lived cache of failed paths, so a mob does not recompute the same impossible route every tick, invalidated the moment a block changes in the region. Throttled point-of-interest and target searches for distant mobs. Collision search bounds for dense entity groups, with safeguards against collision-based lag machines.
6 · Items and XP¶
XP orb aggregation where the game's semantics allow it. Smarter dropped-item
merging that preserves metadata, enchantments, custom items and pickup
restrictions, and still fires Bukkit's ItemMergeEvent.
7 · Chunk engine¶
Per-player chunk-load rate limiting with queueing, tuned so exploration and elytra travel are never blocked. Smoothing for teleports and portals. Diagnostics for chunks being kept loaded for no reason.
◐ 8 · Packet Guard (core shipped)¶
One component on the network pipeline for every rate limit, payload limit and malformed-input check, with one configuration section and one diagnostics view. Every rule carries an action - log, warn, throttle, drop, kick - and a default chosen for a busy survival network. Burst-aware token buckets, not fixed per-second counts. Its own cost is one of the metrics it reports. It never logs authentication or session data.
◐ 9 · Adaptive performance engine (brought forward; first responder shipped)¶
Load levels from MSPT - normal, light, moderate, aggressive - with hysteresis
so it never oscillates. Every response is bounded, configurable, visible in
/ember status, and can be switched off. It feeds the entity tiers,
pathfinding frequency and spawning work; it never silently changes gameplay.
10 · Memory and network¶
Allocation profiling of the hot paths. Every cache bounded, with an invalidation story and a metric. Entity-tracker and metadata packet de-duplication. Every buffer-lifetime change documented and tested.
11 · Compatibility testing¶
A plugin matrix covering permissions, economy, claims, world management, world editing, protocol libraries, placeholders, NPCs, anti-cheat, Geyser, custom items and menus. A register of every observable behaviour change, each with its compatibility toggle.
12 · Benchmarking and production hardening¶
Paper, Purpur and EmberMC on identical hardware across the scenario set: 10, 50, 100 and 200 players; 10,000 entities; mob farm; villager hall; hopper system; redstone clock farm; elytra chunk loading; mass teleport; XP farm; item pile; packet spam; chunk generation. TPS, mean and p95/p99 MSPT, CPU, heap, allocation rate, GC, entity and chunk tick time. No performance claim is published without the run that supports it.