OsoParty

I built OsoParty for a group of people playing together, each with a phone. One person opens a room, shares a six-character code or invitation link, and everyone joins in their browser. There are no accounts to create or apps to install.

Four games

The same party can move between four games:

• CapyTrivia: choose topics and answer multiple-choice questions, then reveal who picked each answer.
• LoroStop: fill categories using a shared starting letter, call Stop, and vote on the group's answers.
• DibuPudú: take turns drawing a secret word while everyone else guesses. Faster correct guesses earn more points.
• MichiSus: share clues, discuss who seems suspicious, and vote to find the hidden impostor without giving away the secret word.

The host can add a room password or hide the code while streaming. Party chat stays alongside the games, and Infinite mode lets the group vote on what to play next. A pack editor supports custom content, import and export, so a game night can use the group's own questions and words.

Keeping the room in sync

I built the React, TypeScript and Vite client, the shared game engines, and the multiplayer service on Cloudflare Workers. Each party has its own Durable Object, with WebSockets connecting the players to that room.

The game rules are deterministic TypeScript packages that run in both the browser and the server. They do not read the DOM, open network connections, or own their own clocks. The application supplies those effects, keeping the rules testable without a browser and avoiding a separate implementation for each environment.

The server applies player actions and sends each person only their own view of the game. Secret roles and unrevealed answers are excluded from the data sent to other players. Drawing strokes are sent to the group while guesses, timers and scoring continue.

Languages and game data

OsoParty supports English, Spanish and Brazilian Portuguese. Each player chooses their interface language, while the host separately chooses the language of questions and words. That distinction lets people share a room without forcing every phone to use the same interface.

Gameplay, drawings and chat stay in room memory instead of becoming a saved history. The device can remember a display name and a draft from the pack editor; those preferences are separate from the live game state.

Motion, sound, and testing

The interface uses Motion with reduced-motion handling, canvas drawing, and Web Audio feedback. I made the sound cues with Nielo SFX.

Vitest exercises the game rules, while Playwright covers multiplayer flows and axe checks accessibility. The checks cover shared state across phones and which information each player receives.