Worlds with rules of my own
I am a developer, and I have always been drawn to making games. What I love is building a world and writing its rules myself. A single-player world is easy to give to people: it is a page, a file, a link. But the moment I wanted a second person to be in the same world, I ran into the same wall, every time. The wall was the server.
Where the server bill comes from
Everything about networked games seemed expensive, and the reasons are not mysterious.
- It is always on. A game server is a process that must be running whether ten people are playing or nobody is. You pay for the empty hours too.
- It carries every message. If each player's update has to reach every other player, the server sends about n × (n − 1) messages per tick: 90 for ten players, 9,900 for a hundred. That is before any clever filtering, and it is bandwidth and CPU you rent by the hour.
- Latency means geography. Players far from your machine feel lag, so a serious game wants servers in several regions.
- Someone has to run it. Scaling, monitoring, restarts and abuse protection are all work that has nothing to do with the world you wanted to build.
The worst part is the order of events. You pay for the server before you know whether anyone will come. For a hobby project, a game jam entry or an experiment with an unknown audience, that is the wrong kind of cost: it is fixed in advance and paid against a success that has not happened yet.
What changed: browsers can talk to each other
Then I found WebRTC. It is a set of browser APIs that lets two browsers exchange data and media directly, with no server in the middle of the conversation. For a game, the interesting part is the data channel (RTCDataChannel): an ordinary pair of “send a message, receive a message” calls between two players.
It can also be configured the way game networking usually wants. A channel created with ordered: false and maxRetransmits: 0 drops a late message instead of holding everything back to deliver it, because in a game the freshest position beats a perfectly delivered old one. Traffic is encrypted by default. Voice and video use the same kind of connection, so talking to the people in your world comes almost for free. And nobody installs anything: a player opens a URL.
The fan-out from the previous section still happens, since every update still has to reach every other player. But it now travels over the players' own connections instead of through a machine on your invoice. That was the moment the cost stopped being a wall.
What WebRTC does not remove
It is easy to overstate this, so here is what stays.
- Signalling. Two browsers cannot find each other on their own. They exchange short connection descriptions through a channel you provide, usually a small WebSocket service. It is a server, but it carries a handful of messages per connection, not the game itself.
- Relays for hard networks. A STUN service helps a browser learn its public address, and that is cheap. When a direct path is impossible, for example behind a strict firewall, traffic has to go through a TURN relay. That is the bandwidth-heavy server you hoped to avoid, used for the share of connections that cannot be made directly.
- No referee. Without an authoritative server, players have to trust each other. Cheating is possible, so peer-to-peer fits cooperative, creative and social games better than competitive ones, unless one peer acts as the host.
- Small rooms. In a full mesh each of n players holds n − 1 connections and uploads every update that many times. That works for a table of friends, not for a stadium.
Which worlds become affordable
Small shared spaces: a co-op puzzle, a board or card game, a sandbox that a few friends build together, a creative tool with a cursor for each person. The cost model changes with them. Instead of carrying every message, you introduce players to each other, and you keep hosting a static page. A world that nobody is visiting no longer needs a game server running for it, only a light signalling service, and that is the property I had been missing.
Why we built Weei on it
The parts of WebRTC that remain are the parts nobody wants to rebuild for every project: signalling, finding who is in the room, identifying players, handling cameras and microphones. Weei provides them. A hosted service handles signalling, your site's configuration and identity verification; participants on the same site and in the same room connect to each other over WebRTC; and your page works with peers, rooms and media through a small API.
For your own shared state there are site widgets. A connector sends a message to every participant or to one, and a widget shows the result, so a score, a cursor or a block placed in a world is just a message between players, with no messaging backend of your own. The tutorial builds a shared counter, which is a toy with the same shape as a multiplayer world.
Weei is not a game engine and not an authoritative game server. It gives you the session, and the rules of the world stay yours, which is how I wanted it.
Where to start
Follow the integration guide to load Weei on a page and see two browser tabs find each other. Then build the shared counter, and change it into the smallest piece of your own world.