Behind the Scenes: A Game Server With ZERO Dependencies
If you've ever dipped a toe into web dev, you know the joke: a modern project's `node_modules` folder weighs more than a photo of the galaxy. Hundreds of external libraries stacked on top of each other, and nobody really knows what half of them do. When we built our game in Node.js, we went the opposite way, and it's one of our proudest dev decisions: the Dovion server runs with ZERO external dependencies. Zero. Not a single third-party library at launch.
What does that actually mean?
When a studio spins up an online game server, the natural instinct is to assemble ready-made building blocks: a library for WebSockets (the real-time connection between your browser and the server), another to serve files, another for this, another for that. It's fast at first.
We wrote everything by hand. Including the most intimidating piece: the WebSocket server itself, meaning the protocol that carries ship positions, shots, and events in real time between the server and every player. That's the kind of component 99% of projects import without a second thought. We chose to understand it down to the last line.
Why put ourselves through that?
It's not (just) masochism. This choice has very concrete upsides:
- Reliability. Every dependency is a risk: an update that breaks everything, a security flaw discovered in a third party, a project abandoned by its author. Zero dependencies means zero nasty surprises from elsewhere. Our server today will boot up exactly the same way in five years.
- Leanness. No middle layers: the code does exactly what we ask it to, nothing more. For a server that has to simulate entire rooms in real time — we told you why in behind the scenes of the authoritative server — every millisecond counts.
- Full control. When a bug shows up at 2am, it's necessarily in OUR code. No need to dig through the guts of a library someone else wrote. We can fix anything, because we built everything.
- Trivial deployment. Installing the server means copying the files and starting it. No package installs, no version conflicts, no magic ritual.
The locked-down networks plan B
A concrete example of what this control enables: some networks — schools, offices — block WebSocket connections. In most games, that turns into a login screen spinning forever with nothing happening. Because we control our entire networking stack, we were able to build a fallback transport over HTTP/SSE: if the WebSocket is blocked, the game automatically switches to this alternate route, and you get to play anyway. This kind of safety net is much harder to build when the networking layer is an imported black box.
The downsides (because there are some)
Let's be honest, this philosophy has a cost: time. Writing by hand what others import in a single line means extra weeks of work, technical specs to read, twisted edge cases to handle. It's a luxury for a small passion project; a team with commercial deadlines probably couldn't afford it. We're not claiming this is THE right method for everyone — it's ours, and it fits our scale.
This handmade philosophy actually goes beyond the server: the game world itself is drawn by code, with no image files, as we explain in behind the scenes of the Ghibli-style rendering. The overall result: a lightweight game that loads fast and runs even on modest machines — proof in Dovion on low-end hardware.
All this invisible work has exactly one goal: for you to click and have it just work. See for yourself: Play Dovion for free.