Building a browser .io strategy game with a Go server

I'm building Warhex.io, a free .io strategy game that runs in the browser. You build a base out of walls, turrets, snipers and barracks, defend key positions and fight players from all over the world in real time. This post is about how the game is put together, in case you are thinking about making a multiplayer browser game of your own.

If you used to play bloble.io or similar base-building .io games, Warhex.io is made for that kind of player. It is an independent project and is not affiliated with bloble.io.

The shape of the stack

• Server: Go. One authoritative game loop owns the whole match, and clients only send intentions (place a building, move units, buy an upgrade).
• Transport: WebSockets with a small binary protocol. Every message is one type byte followed by a compact payload, so a camera update or a unit position costs a handful of bytes.
• Client: plain JavaScript, a canvas renderer and webpack. No game engine. The renderer only draws what the server says exists.
• Accounts and data: Supabase for login (Discord only) and for things that must survive a restart, like progress and ranking.
• Community: a Discord bot in Node that syncs the global top 10 to server roles.

Why Go for the game server

A match is a lot of small updates: bullets, units, buildings and health bars changing many times per second. Go gives cheap concurrency (one goroutine per connection, one loop for the world) and predictable memory use, which matters when you want a cheap server to hold many players.

The important rule is that the server decides everything. The client can ask "place a turret here", and the server checks the cost, the position, the limits and who owns the space before it replies. That one rule removes most of the cheating you would otherwise have to chase.

A tiny binary protocol

Text JSON is easy, but at a few hundred updates per second it gets expensive. Our messages look like this:

[ type: 1 byte ][ playerID: 1 byte ][ payload ... ]

On the client a worker decodes each frame by type and hands plain objects to the game. Rarely sent things (a clan list, a chat line) can still use JSON inside the same envelope, so you only pay for binary where it matters.

Boss fights as a game design tool

The most fun feature to build was three world bosses. Each boss is a fortified base made of the same pieces players use, with a shield made of generators. You have to break the shield generators first, then the core. Because bosses reuse the normal building and damage code, there was almost no special-case logic, and balancing them is just changing numbers.

What I would tell my past self

1. Make the server authoritative from day one.
2. Keep the protocol small before you need to.
3. Reuse your own game rules for new content (bosses, events, tutorials).
4. Put the moderation tools (chat filter, rate limits) in early.
5. Ship the community (Discord, wiki, guides) alongside the game, not after.

You can play Warhex.io for free at https://warhex.io and join the community at https://discord.gg/CsVHA7R7Vx. There is also a wiki with a full guide at https://warhexio.fandom.com/pt-br/wiki/Warhex.io

Questions about the netcode or the Go server? Ask in the comments and I will answer.