When to use tickcli
tickcli is a live-session engine for small games: one player’s browser (the host) runs the rules, the hub keeps the shared state, membership and order. That shape decides where it fits.
Good fits
Section titled “Good fits”- Party and co-op games, tag, races, casual shooters, team battles, dungeon crawlers.
- Turn and board games with people watching (seats), knockout tournaments (cups).
- Games written in one HTML file, by a person or an AI, that must work without a server deploy per game.
- Live presence in any app: cursors, who is here, small shared toys (see Neon Paint).
Not a fit
Section titled “Not a fit”| You need | Why tickcli is wrong | Use instead |
|---|---|---|
| Precise competitive shooters | The host is a player’s browser; there is no server-side physics, lag compensation or rollback | A server-authoritative engine with prediction (for example Colyseus) |
| Collaborative documents, whiteboards, kanban | Last write wins per key, 64 KB of shared state, no history, undo or offline merge | A CRDT such as Yjs with a server such as Hocuspocus (both MIT); tickcli can still carry the live cursors |
| Big persistent worlds | One room at a time plays a saved world of up to 64 KB | A game backend with a database |
| Anything that must not be cheated | Whoever is host could change the rules on their machine | Server-side rules |
Compared with other multiplayer SDKs
Section titled “Compared with other multiplayer SDKs”| tickcli | Colyseus | Playroom Kit | |
|---|---|---|---|
| Where the rules run | the host player’s browser | your server code | the host player’s browser |
| Server | one generic hub, no game code | a Node server you program per game | hosted |
| License | MIT | MIT | not stated in its npm metadata |
| Engines | any (shell, three.js mode, headless) | tutorials for Phaser, PixiJS, Babylon, Kaplay, three.js, PlayCanvas | docs for PixiJS and three.js |
Sources: Colyseus docs, Colyseus + Phaser tutorial, Playroom Kit docs, npm registry metadata (checked 2026-11-13).