ROYALFIRE

game infrastructure · 2026

Minecraft server stack

Running a game server that stays consistent when the owner is not watching it.

Role
Build and operations
Status
active
Stack
Paper 1.21ProtocolLibDeluxeMenusFancyNpcsDecentHologramsSNBT

A server plugin is not finished when it works once. It is finished when it still behaves correctly after a reload, a restart, and a player using it in a way nobody predicted.

What is on the server

A Paper 1.21 network with custom plugins built on ProtocolLib, where the interaction work — packet-level NPCs, shops, and holograms — lives. Shops are NPC-driven through DeluxeMenus so players never leave the world to trade. Holograms display live server state rather than a value that was set once and quietly went stale.

Items are handed out as SNBT-formatted books, which means a crafted item can carry its own lore, enchantments, and metadata without a plugin having to reconstruct it from a database row.

The engineering problem

Everything that touches packets has to survive a ProtocolLib version bump without taking the server with it. That means wrapping every packet handler in a guard that fails closed, keeping state in a single authoritative source that survives reload, and testing behaviour under load rather than assuming it holds. A crash in a packet handler takes the whole server with it, so the handler is treated as the least trustworthy code in the system.

What I would change

I would move configuration out of code and into validated files that fail loudly on load if a value is wrong. Half the debugging time in this stack went to a typo in a hardcoded constant, and that is entirely avoidable.