A Live-Broadcast Architecture for Virtual Events

A convention exists for one reason: to put people in the same room. That couldn't happen anymore, and there was no way to fake it. The goal wasn't to replace a live event, since that's not possible. It was to find a different kind of experience that could still feel genuinely engaging, on its own terms.

Concept

The idea was a platform of virtual locations: explorable, interactive spaces that could host an event the way a physical venue would, but built and reused across different formats and clients. Each location would work as a venue in its own right: somewhere people could move through, gather in, and follow a live program. One of these locations, built as a working prototype, was Tetris Virtual Palace.

Roles

Running an event like this needs the same kind of team a live event would need: someone directing the show, someone operating lights and effects, someone mixing video, someone shaping the space itself. None of that goes away just because the venue is virtual.

My role was to design and build the systems that let this team actually do their job, live, inside the platform. Not run the show myself, but make it possible for a show to be run.

Orchestration

None of these roles can do anything without tools that actually talk to each other.

Getting any of this into the venue itself meant solving two separate problems. The mixed broadcast signal needed a streaming layer to reach the Unity environment live, which is what the streaming media server was built for. The console's signals followed a different path entirely: PHP calls running on their own line, straight into the venue, independent of the video feed.

The console could be docked inside OBS so the operator worked from a single screen. That was a convenience, nothing more. Underneath, lighting and broadcast never shared a pipeline: two systems that needed to feel like one.

Challenges

Running sixty people through the same virtual room in real time exposed problems no single-user demo would have shown.

Lag and sync were the constant pressure: every light cue, every camera move, every interaction had to reach everyone close enough together that nothing felt delayed or out of step.

Solving that meant being deliberate about what the scene was actually allowed to cost. Lighting was baked wherever it didn't need to react live, geometry stayed simple by design rather than by compromise, and every input had to be checked against both resolution and frame rate, not just one or the other. Getting all of these systems to talk to each other reliably, without one piece silently lagging behind the rest, took as much work as any single piece on its own.

Testing

The platform was tested with sixty people connected from a university classroom: part technical stress test, part real user test. The technical side held up. The feedback pointed somewhere else entirely: at how people wanted to move and act inside the space, not at the broadcast itself.

None of that made it into the prototype, but it shaped what the next version needed to become, including a longer-term idea of a multiplayer system, with authenticated avatars and a group chat layer for attendees to interact directly.

What I Learned

Looking back, the roadmap prioritized the wrong things:

• Lighting Console: elaborate, useful for the pitch, but it wasn't where the priority should have been.
• The Space Itself: a deeper study was missing, and it stayed too liminal to fully hold people inside it.
• Multiplayer: even an embryonic version of interactive multiplayer would have done more for engagement than another control on the console.

Treating a virtual venue as a set design problem is almost always the wrong instinct. The harder, more valuable problem is giving someone real-time authority over an experience other people are inside of at that exact moment. Once that authority exists, the space stops feeling like a render and starts feeling like a show.

It's an idea I'd come back to, in different forms, well after this project ended.