Three zones, three processes
The Linux server is built from the engine source and running on its own machine — one dedicated process per zone, each with its own map and its own port.
Zizeeria's architecture says one server process per zone rather than one big world server, and until today that was a sentence in a document. It is now three processes on one machine, holding three UDP ports, each having loaded a different map and brought its world up for play: a marsh harbour, a burnt plain and a cave system.
Getting there took the engine built from source on a dedicated Windows host, a cross-compiler producing Linux binaries, a cook that packs the maps into a container, and 2.2 GB moved across the network. The build itself took seventy-six minutes and the cook another thirty-seven.
The interesting failures were in the last hundred metres. Moving the build with the obvious command — pack it on one machine and unpack it on the other through a single pipe — does not work, and it does not fail either: it hangs, completely, with the connection established, the receiving process running and zero bytes ever crossing. It sat like that for eleven minutes before anybody measured the far side instead of watching the near one. The cause turned out to have nothing to do with the size or the network, and the way to find it was to shrink the problem until one small file could be watched failing.
What this is NOT yet is the milestone that ends pre-production. That one is stated as a cube that can move in a networked zone, and specifically as two clients seeing each other move — which needs a client, and the client is the next build. The server half is done; the half a player would notice is not.
There is a rule about this in the project's own plan: never enter the next phase before the exit criterion is met. It exists because the largest risk on the register is not a technical one — it is deciding a thing is finished because most of it is.