KILLSTREAM
In Development
A 2–6 player party game set in a dystopian broadcast — in development for Steam.
- Built the networking foundation — FishNet transport, Steam authentication, lobby host/join and reconnect
- Designed the minigame framework — definition, validation, lifecycle, result contract and run coordinator
- Deterministic random source, game state machine, scene flow and startup sequence
- Persistent UI router, run scoring/placement pipeline and pooled audio system
- Lead the technical direction, with the final call on design, packages and releases
- Unity 6
- C#
- URP
- FishNet
- Steamworks.NET
- GitHub
- JetBrains Rider
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 Ozanay is the second developer.
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.
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, Steamworks authentication, lobby create/host/join/leave, and disconnect → reconnect that restores the same player identity
- Minigame framework — the definition and validator, the lifecycle and result contract, and the coordinator that runs a session, all kept independent of the networking layer
- Core systems — game state machine, deterministic random source, scene flow, startup sequence and the composition root
- Run layer — production run coordinator, placement-to-score pipeline, persistent UI router and a pooled audio/mixer foundation
- Test foundation — shared fixtures and fakes, with EditMode and PlayMode suites gating each system
Design Pillars
The five pillars every minigame is measured against:
- Easy to understand — a minigame has to read instantly; no complicated mechanics
- Fun even when simple — simple rules are fine, dull ones are not
- Players interact — room for manipulation or cooperation between players
- Chaos, in the right dose — randomness is welcome as long as it stays fun
- 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.
That separation is what makes a >30 minigame catalogue plausible for a three person team. Each new minigame is content against a contract, not another integration problem.
Where It Is Now
The production target is a catalogue of over thirty minigames with ten played per session. The current milestone is smaller and deliberately so: a first playable with three minigames — Giant Dwarf, Assembly Memory and Chair Grab — proving the complete core loop end to end.
- Giant Dwarf is through design and technical mapping and is being wired up
- Assembly Memory and Chair Grab are still in design, held on open balance decisions
- The networking layer is running: Steam authentication and lobby flow pass their smoke tests, and reconnect keeps player identity stable across a drop
- Multiplayer has been verified with three players connected to a server; the full two-to-six player matrix is not confirmed yet
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.
The open question is whether that discipline holds under a real release deadline and a catalogue this size. That is the part I am still finding out.