KILLSTREAM

Context

KILLSTREAM is a party game built around a minigame catalogue, for 2–6 players, made in Unity for PC and targeting a Steam release. Three of us are making it: I lead the project and work across design and development, Baran is game designer and leads the art, and Ozanay is the second developer, who also owns one of the first three minigames end to end.

The game is still in development, so the source code and assets are not public. This page describes the game and the systems behind it rather than showing them.

The premise is a dystopian broadcast. In a future where the ultra-rich need entertainment, men over eighteen are entered into an annual lottery; if your name comes up, you are on live television whether you agreed to it or not. The show sells itself as bright and energetic — the game shows it the way the contestant actually experiences it, in a bleak cyberpunk register.

Elevator pitch: a machine party turned into entertainment for the rich.

The Game

A session is a run of short minigames hosted by an on-screen announcer. Each minigame is played over several sets, every set produces a placement for each player, and those placements turn into points on a shared leaderboard. The goal is not to win one minigame — it is to finish the whole broadcast on top.

The first three minigames, all for 2–6 players:

• Giant Dwarf — a reaction game. The announcer calls up or down; a TV behind them says whether to obey or do the opposite. Miss the window and you are out, and the window keeps shrinking.
• Assembly Memory — a memory and visual search game. Machine parts are put on display, then fused into one object; each player has to rebuild the set from a cluttered workbench, with the right parts in the right numbers, before time runs out.
• Chair Grab — musical chairs under a spotlight. Chairs spin on a central platform while the music plays; when it cuts, everyone scrambles for a seat — and shoving a rival out of the way is allowed.

My Role

I lead the project and am one of two developers, with final authority on technical direction, packages and releases. So far I have built:

• Networking and Steam layer — FishNet transport over Steam, verified authentication and a player registry, lobby create/host/join, scene flow across peers, and disconnect → reconnect that restores the same player identity
• Minigame framework — the definition and its Editor validation, the lifecycle and result contract, and the coordinator that takes a minigame from load to cleanup, all kept independent of networking
• Run layer — the production run coordinator, set-placement aggregation, a pure placement → score policy and an idempotent score ledger, proven first with a three-minigame local core loop running on fake results
• Core systems — game state machine, deterministic random source, composition root and startup sequence, plus localization, audio and cutscene adapters
• Minigames — Giant Dwarf and Assembly Memory, from runtime rules to their network adapters, presentation and playtest tooling
• First-playable UI — the persistent UI router, the entry, lobby, score and leaderboard screens, and a Figma pass on the UI direction
• Test foundation — shared fixtures and fakes, with EditMode and PlayMode suites gating each system

Design Pillars

The five pillars every minigame is measured against:

1. Easy to understand — a minigame has to read instantly; no complicated mechanics
2. Fun even when simple — simple rules are fine, dull ones are not
3. Players interact — room for manipulation or cooperation between players
4. Chaos, in the right dose — randomness is welcome as long as it stays fun
5. Competitive — the scoring has to keep the rivalry alive

The target is a lightly competitive party game for players 16 and up, built for playing with friends and for the kind of moment that survives being clipped.

Architecture

The thing I care most about here is that a minigame should not need to know how networking works. The framework defines what a minigame is — a definition, a lifecycle, and a result — and the coordinator owns everything around it: turn of play, scoring, scene transitions and session flow. Networking sits behind an adapter, so a minigame can be built and tested locally before it ever touches multiplayer.

Every minigame follows the same split: a pure rules layer that the server runs, a separate network adapter, and a presentation layer on top. All three of the first minigames were built that way, by two different developers, without either of us having to change the framework to fit them. That is the part that makes a >30 minigame catalogue plausible for a three-person team — each new minigame is content against a contract, not another integration problem.

Scoring is shared the same way. A minigame only reports who placed where in each set; turning those placements into points, resolving ties and handling a player who drops mid-set is one common policy, so the leaderboard means the same thing no matter which minigame produced it.

Playtesting

The first playtests ran over Steam on separate machines, with the three of us as players. Giant Dwarf surfaced the clearest lesson: the host could see every client duck and stand, but the clients could not see their own character move. The cause was a size check on the visual state packet that assumed a fixed width, while the transport packs small values into fewer bytes, so perfectly valid packets were being thrown away on the client. The fix was one number; the more useful part was reproducing it first in an automated test across two to six players, so it cannot come back quietly.

Chair Grab has been through several online rounds of its own, and they changed the design rather than just the code: the outer floor no longer rotates, a missed shove now costs as much as a successful one, and a knocked-down player cannot be hit again until they are back on their feet.

Where It Is Now

The production target is a catalogue of over thirty minigames with ten played per session. The current milestone is a first playable with three minigames, proving the complete loop end to end: Steam lobby → minigames → scoring → leaderboard. The playlist at the top of this page has our first playtest and our pitch for Deep Jam 2026 — both are work in progress, not final art.

• All three minigames are implemented and in playtest review
• The core loop runs end to end locally, and the networking layer is up: Steam authentication, lobbies and reconnect are working
• Online tests so far have covered two to three players; the full two-to-six player matrix is not confirmed yet
• The art direction is coming together — a retro, broadcast-glitch look with posterized colour, dithering, CRT interference and neon outlines on the players — and the first-playable UI is designed and being wired in
• Standalone builds turned up a networking bug that never showed in the Editor; tracking it down is part of getting the first playable into other people’s hands

Design work is gated deliberately: a minigame is not implemented until its design document is complete and approved, so that nobody builds against a decision that has not actually been made.

Reflection

The lesson I took from KAM was that the systems I refused to hardcode were the ones that survived contact with players. KILLSTREAM is me applying that from the start rather than discovering it at the end — the framework, the scoring contract and the networking adapter were written as contracts before there was a single minigame to run through them.

Three minigames in, the contracts have held: a second developer built one on them without needing anything changed. The open question is whether that discipline holds under a real release deadline and a catalogue ten times this size. That is the part I am still finding out.