How Homegames works

What Homegames is, and how the whole system fits together — from a tap on a phone to the code running your game. For making games, see the docs; for running it on your own machine, see self-hosting.

What is Homegames?

Homegames is a platform for making, sharing, and playing simple multiplayer games in the browser. There's nothing to install for players: games run in any browser, on any device, and phones work as first-class controllers and screens. Games are small JavaScript programs — usually a single file — and everything on the platform, including every published game, is open source under GPLv3.

There are two ways to use it:

• The website — browse the catalog and play published games directly, or build your own in the Developer Studio without leaving the browser.
• Your own server — run Homegames on a machine at home, and everyone on your network gets a game dashboard by typing homegames.link into a browser. See self-hosting.

Playing games

Clicking Play on a game page starts one of two kinds of session:

• Local session (single-player) — the game's code, the runtime, and its assets are fetched and run entirely in your browser tab. Nothing server-side is involved after the initial download. This is also how the Download button works: it packages the game, runtime, and assets into one HTML file that runs offline.
• Hosted session (multiplayer) — for games that declare the multiplayer service, the platform spins up a real game server for that session. The creator gets a shareable link; anyone who opens it joins the same game from their own device.

Either way, the game code is identical — the same class runs in a browser tab or on a hosted server, and it can't tell the difference.

Games are scene trees, not canvases

A Homegames game never draws pixels, touches a canvas, or opens a socket. It maintains a tree of nodes — shapes, text, and assets (images/sounds) — positioned on a 100×100 coordinate grid. The game mutates that tree (move this square, change that label) and signals "something changed." That's its entire interface with the world.

Everything else is the platform's job: rendering the tree to an actual screen, delivering taps and key presses back to the game (tagged with the acting player's id), and keeping every connected player in sync. Because the game is just a description of what exists, one game instance can serve many players at once — and nodes can be scoped to specific players, which is how a shared card game keeps each hand secret.

Squish: the wire format

The scene tree travels between game and screen as a compact binary format called squish (the library is squishjs). Think protobufs, but purpose-built for game scenes: each node serializes to a few dozen bytes — positions, colors, text, asset references — and the client deserializes ("unsquishes") and renders them. Input travels the other way as small JSON messages.

Squish is versioned, and every game pins the version it was written against (that's the squishVersion: '142' in game metadata). The platform keeps old versions around, so games written years ago keep working as the platform moves forward.

The browser side is a small rendering engine (homegames-client) that connects over WebSocket, unsquishes frames onto a canvas, and forwards input. It's the same engine everywhere: the website's player, hosted multiplayer sessions, self-hosted dashboards, and offline downloads.

Where games run

In your browser (local sessions)

For single-player play, the client engine runs the whole loop in-tab: it instantiates the game class, runs the squish serializer locally, and renders the frames — a complete client and server in one browser tab. No account, no latency, no server cost.

On a session server (hosted sessions)

Multiplayer sessions run on the platform's session infrastructure. Each session is an isolated process (a locked-down container where available) running just that game, on its own port, with resource limits. A small management API — Homenames — creates sessions, tracks players, and tears sessions down when everyone leaves. Players' browsers connect directly to the session over WebSocket.

The game is server-authoritative: all logic runs in one place, and clients are thin. That's why there's no netcode to write and no way for a modified client to cheat beyond sending inputs.

The pieces

End to end, the platform is a handful of cooperating services:

Publishing & safety

Anyone with a verified account can publish. Because published games are code that the platform will run — in hosted sessions and in players' browsers — every submission goes through automated validation before it can go live:

1. Static analysis. The game's source is scanned at the syntax-tree level. Games may only use the squish library and their own files — no Node built-ins, no network, no filesystem, no eval, no dynamic require. Anything else is rejected outright.
2. Sandbox run. The game is actually executed for a few seconds inside a container with no network access, to confirm it loads, renders, and doesn't crash.
3. License check. Every published game must be GPLv3, and its source is publicly browsable from its game page.
4. Listing. A passing game is publicly listed in the catalog. Featured games are hand-picked by a human. Uploaded images are also automatically screened.

Homegames on your network

The self-hosted experience is the original heart of Homegames: one machine in your house runs the server, and everyone on the wifi plays together by visiting homegames.link — no app, no setup on anyone else's device. Two small pieces of platform machinery make that URL magic work:

• Discovery. Your server keeps a lightweight connection to the homegames.link service and tells it "I'm at this address on my local network." When any browser on the same network visits homegames.link, the service recognizes the network and redirects the browser straight to your server. Traffic never leaves your LAN — it's just a redirect.
• Real HTTPS on a LAN. Browsers increasingly require HTTPS, but you can't normally get a certificate for a private address. Homegames solves this by assigning each network its own subdomain of homegames.link, pointing that subdomain at your server's local address, and issuing it a real certificate. Your server generates its key locally and sends only a signing request — the private key never leaves your machine.

The result: any device on your network gets a secure connection to a server in your own house, with zero configuration. The full setup guide is at self-hosting.

Open source map

Everything is on GitHub under github.com/homegamesio. The main repos:

Something wrong or confusing on this page? Email joseph@homegames.io or open an issue on GitHub.