Touchline: bringing the match into the room

By Kitsune

I want an esports event to feel like the match is happening in the room, even beyond the screen.

A change in lighting, a projection, or a carefully timed visual can make a moment feel larger. That gets interesting when those elements can respond to the game itself. It also gets complicated very quickly: someone still has to run the show, the data has to arrive, and the visuals have to mean something.

That is the idea behind Touchline, a project I’ve been exploring to connect live game data to TouchDesigner. My initial scope is custom games, where the experience can be designed around an organized match and its operators.

The data is part of the design

It is tempting to start with the effect. A player goes down, so their portrait loses its color. A fight breaks out, so the room changes. An important ability becomes available, so a graphic reacts.

But each effect is also a question about information. Do I actually know that the player died? Can I identify them consistently? Did I receive a new event, or am I looking at the same state again?

The TouchDesigner work has involved very practical pieces: extracting player information from JSON, flattening it into tables, mapping identities, and working on effects such as grayscale on death and smoothed responses to sound. Those small pieces are where the larger idea starts becoming tangible.

They are also where a convenient assumption can turn into a visible mistake. If a table changes order, I don’t want a visual associated with one player to silently become someone else’s.

A shared language for the show

One direction I’ve been working through is giving Touchline a stable message format. I want the visual project to receive recognizable events and state, without needing to understand every detail of the source that produced them.

A proposed message such as {"id":"team-protect","team":1} illustrates the shape: a named event with explicit context. The exact vocabulary still needs to serve the actual production.

There is another distinction I want to preserve: observed information versus inferred information. A feed reporting an event and a rule guessing that an event happened deserve different treatment. Otherwise, a clever heuristic can quietly become the thing everyone trusts.

That matters when a visual could mislead the audience or distract an operator. I would want uncertain events marked as uncertain, with the production deciding whether to use them.

Try an operator policy

Send the proposed team event as reported data, an inference, or a manual trigger. In this model, inferred events are held unless the operator permits them. A held event leaves the existing cue unchanged.

{
  "id": "team-protect",
  "team": 1
}

The provenance choices are part of this teaching example, not a finalized Touchline message schema. Returning the room to neutral is deliberately available throughout.

Leave room for the operator

Automation is useful when it gives the operator more control over the experience. A manual trigger, a correction, or a way to return to a neutral state belongs in the design from the beginning.

I’m still working through the adapters, event vocabulary, and production behavior. This is a development direction, rather than a claim that every game integration is finished.

The part that keeps me interested is the connection between systems and atmosphere. A JSON message is a small thing. Giving it the right meaning can change how a room experiences a match.