01 The Short Version
Everywhere else on this site, Server Floor is a company and you're applying for a job. This page steps out of character, because the way this game got built is a better story than anything we could make up.
Server Floor started as a pure-ASCII terminal game played over telnet. Its first players were malware. It has been, at various points, a terminal game, a browser game, a WebGPU game, and a fully 3D voxel game — sometimes several of those at the same time, on the same live server. Here's the timeline, then the stories.
| March 5, 2026 | Initial release — a multiplayer terminal roguelike served over telnet and SSH |
| March 2026 | Port-scanning bots discover the open telnet port and become the first player base |
| March 2026 | First web client — same server, same world, rendered on an HTML5 canvas |
| April 10, 2026 | The game gets its name — Server Floor at serverfloor.com. The telnet era officially ends the same day |
| Late April 2026 | Renderer rebuilt on PixiJS v8 / WebGPU in a worker thread; the old canvas renderer is deleted |
| May 2026 | The Unity 3D build — full-voxel terrain, HDRP lighting, multiplayer with accounts |
| Summer 2026 | Full focus returns to the 2D game: the jungle, the dock, the flooded sublevels, the abyss, the rifts |
02 The Terminal Era
Server Floor was born from a love of classic roguelikes — the kind where a D is a dragon, a * is treasure, and your brain fills in the rest. We wanted that, but multiplayer, and set in an IT warehouse, because a haunted corporate warehouse is scarier than any dungeon.
So the first version was the full classical experience: a terminal UI rendered server-side, played over telnet and SSH. Players connected to a Linux box, got a screen full of @ symbols and # walls, and fought printers with text characters and imagination. Combat, tunnel generation, boss telegraphs, the ticket system, vendors, loot — all of it worked, all of it in a monospace grid. Every system in today's game was designed and proven in ASCII first.
03 First Contact
To run a public telnet game, you have to open port 23 to the internet. Port 23 is one of the most scanned ports on Earth. We knew this. We did it anyway.
The bots arrived almost immediately. Automated scanners — the kind that sweep the whole IPv4 space probing for routers with default passwords — found the open port, connected, and were greeted not by a login shell but by a character-creation prompt. So they did what bots do: they mashed input at it. And because the game happily accepted their garbage as a name, the bots created player accounts. Dozens of them. Our first player base wasn't early adopters — it was malware, standing motionless in the warehouse with names like keyboard static, probing the game for an exploitable router firmware that wasn't there.
We'd like to say we ran a careful private beta. The truth is our launch-day population was botnets, and they found bugs.
04 Why the Terminal Died
Here's the thing the bots taught us. In a terminal game, every frame every player sees is rendered on the server. Each connected session burned a chunk of server CPU, whether that session was a human fighting a boss or a botnet in Bucharest staring at the character-creation screen. Around ten simultaneous players the server was already sweating — so when a wave of scanners logged in to probe the port, they were indistinguishable from a launch-day traffic spike, and they lagged out the game for the humans. The bots were an accidental load test, and the architecture failed it.
That was the honest end of the console dream. A terminal game in 2026 is a relic — a beautiful one, but a relic — and this particular relic scaled like a museum piece too. The version of this game we wanted to build could not live there.
05 The Browser Bet
The move to the browser gets misread as a retreat — browser games have a reputation as the compromise platform. That reputation is twenty years out of date, and the actual story is the opposite.
For most of gaming history, the browser was the impossible platform: no real graphics API, no threads, no audio worth having — everything was a hack. But while the terminal stood still, the browser quietly became one of the most capable runtimes ever shipped. Today it hands you a modern GPU API, worker threads, spatial audio, and instant zero-install distribution on every device on the planet. This game runs a WebGPU renderer on a dedicated worker thread, in a browser tab. The 1985 grid of text could never.
It also fixed the thing that killed the terminal: the rendering moved to your machine. The server went from drawing every player's screen to sending lightweight game state, and the population ceiling stopped being a rendering problem. We didn't abandon the terminal for something shinier — we outgrew a platform that had already died, and landed on the one that had just been born.
06 Engine Switches
The first web client was an HTML5 Canvas renderer — colored rectangles for tiles, pixel-art sprites, a hand-rolled particle engine, thousands of draw calls issued one at a time by the CPU. It looked great and it got the game out of the terminal, but it was doing GPU work on a CPU, and it had a ceiling.
In late April 2026 the renderer was rebuilt on PixiJS v8 with a WebGPU backend, running in an OffscreenCanvas worker — the entire render pipeline lives on its own thread, and the main thread only handles input and the network. Batched GPU passes replaced per-frame canvas calls, which paid for effects the old renderer could never afford: animated flowing water and lava, real-time lighting, full-quality bloom on integrated graphics, particle counts that don't apologize.
Once the new renderer reached parity, the old one — some fifteen thousand lines of canvas code that carried the game for two months — was deleted in an afternoon. No fallback flag, no legacy mode. Ships get burned around here.
07 The 3D Build
In May 2026 we built the 3D version. Not a mockup — a real one, and the road to it was its own engineering story: first a Babylon.js web prototype to de-risk the architecture (full voxel terrain on a 10 cm grid, greedy-mesher chunking, the 2D player ported to a rigged, motion-captured 3D character), then a full Unity build with HDRP lighting — the warehouse remastered in 3D, mineable voxel walls, breakable floors, the shipping-line conveyor moving real boxes, first-person controls, and working multiplayer with a proper account layer. You could dig through the floor of one zone and fall into the zone below it.
It's real, it works, and it's on the shelf. Building it made one thing obvious: the 2D game wasn't a stepping stone to the “real” version — it was the real version, mid-sentence, with a world that deserved finishing. So the voxel build waits, finished-enough and patient, while the game that earned the attention gets it. We're proud of both halves of that decision.
08 One World, Every Client
The strangest artifact of this history: because every version of Server Floor was a client to the same authoritative server, they could all share one live world. When the web client launched, browser connections were simply wrapped to look like terminal sockets — the game logic never knew the difference. For a stretch in 2026, someone in a browser tab and someone in a raw telnet session were walking the same warehouse at the same moment, seeing the same monsters — one of them as a pixel-art sprite, the other as a letter M.
The Unity build could have joined them — same protocol, same world, a first-person voxel client standing next to a telnet ghost. We chose not to wire it up. Some restraint is good for you. But we know it would have worked, and honestly, knowing is most of the fun.
09 The Tooling
A game that changed platforms this many times survives on its pipelines. Along the way we built a small factory's worth of custom tooling: sprite pipelines that turn concepts into the game's 8-direction animated sheets; a rig-to-sprite renderer that takes rigged 3D models and animation data and bakes them down to 2D frames (that's how the sharks swim); zone generators that carve rivers and roads with pathfinding instead of stamping them from templates; procedural map builders; an audio pipeline for a 50-plus-track soundtrack and hundreds of effects; and an in-house ticket board that runs both the dev process and, naturally, the in-game fiction.
Plenty of that tooling is AI-assisted — that's part of how a game this size gets built by a team this small — but the pipelines exist precisely so nothing is a one-off: art can be regenerated, recolored, re-cut, and rebuilt on demand, and everything answers to the same art direction. The tools serve the game, not the other way around.
10 Under the Hood Today
What's actually running when you clock in: a single authoritative Node.js server owns the whole world — every zone, monster, and dropped item. Your browser connects over a WebSocket and receives compact JSON state deltas — only what changed, only what's near you — with a fast position channel for the things that move every frame. Movement is free pixel movement, client-side and instant, with the server validating rather than puppeteering; nothing snaps to a grid.
Rendering is PixiJS v8 on WebGPU inside an OffscreenCanvas worker — the renderer owns its own thread and the game stays responsive even when the screen is on fire, which around here is often. The whole client is vanilla JavaScript: no framework, no bundler, no build step. Every file is served exactly as written, and you're welcome to View Source — it's a roguelike, spoilers are a you-problem.
Saves live in a proper database with scrypt-hashed passwords, snapshotted nightly to encrypted off-site storage. If the server caught fire tonight, the whole world — every character, every hoarded relic — would be back within the hour. The printers, regrettably, would also be back.