I’ve spent the past few weeks deep in a personal project that started from a technical frustration, and I want to tell you where it ended up.
For those not into the technical side of Minecraft, quick context: a server isn’t infinite. It’s a computer that costs real money (electricity, CPU, RAM) and has a physical limit. Think of it like a stadium: it has a maximum capacity. If you try to cram 20,000 people into a space built for 10,000, the system collapses. In the game that’s called “lag”, and it’s what kills the fun.
Until now, the standard solution was crude: when the stadium filled up, anti-lag systems would start kicking people out or deleting things at random to free up space.
I wanted something better. That’s where Aurora Optimizer came from.
Stop cleaning, start managing
The goal was to build a manager, not a cleanup robot. The architecture was a headache, mostly because of modern server technology (like Folia), which splits the world into pieces processed by separate threads: get that wrong and the server doesn’t slow down, it breaks.
I split the system into three components with clearly separated responsibilities:
- The Eye: it watches the server without interfering. Its job is to understand the actual problem. Is it a resource farm? Too many dropped items? Too many players in one spot?
- The Orchestrator: it decides what to do based on context, not blind rules.
- The Executor: it applies the solution in a contained way, so the gameplay doesn’t break.
The code was only part of the challenge. The other part was defining the management policy.
The lag economy
Running a high-performance server costs money. If it goes down from overload, nobody plays: not the people paying, not the free players.
So the optimizer doesn’t just save memory; it also protects the project’s sustainability. I implemented a resource priority (QoS) system with this logic:
When the server is calm, everyone gets maximum quality. Far view distance, complex physics, everything maxed out.
When it hits its critical point (the stadium is full), the system makes adjustments to avoid collapse:
- For the general community, near-imperceptible micro-adjustments: slightly reducing the distance at which monsters are visible, lightly simplifying physics. A saver mode that keeps them playing smoothly without the server kicking them or freezing.
- For subscribers, who fund the hardware that keeps the server on for everyone, a power reserve: their experience stays untouched.
It’s not pay-to-win; it’s pay-to-sustain. That makes a stable, free experience possible for thousands of people, because the system distributes resources so the people paying the bills get a fair deal.
Transparency
A system that makes decisions on its own raises suspicion (“why can’t I see as far today?”). That’s why I dedicated an entire development phase to making sure nothing was a black box: every time the system adjusts quality for a player or a group, it leaves a record in plain language, not error codes:
“Saver protocol activated in the South Sector due to a 90% overload. Connection stability was prioritized over view distance.”
That way the adjustment stops feeling arbitrary: anyone can see what happened and why.
Where the project is headed
I just closed phase 10: the system is now extensible and stable. Making it work in a multithreaded environment without corrupting data was some of the hardest programming I’ve done, and several solutions I had to invent because the manuals didn’t cover what I was trying to do. That part, the threads and the odd implementation decisions, deserves its own denser post. If there’s interest, I’ll write it.