A common language for game telemetry

In April 2024 I made the first commit in a repository for something currently called the Local Telemetry Standard github.com/Open-Game-Standards-Alliance/Local-Telemetry-Standard: a common way for a game to expose telemetry, pose, acceleration, engine state, whatever it has, to software and hardware on the player’s local network, so motion rigs, haptics vests, dashboards and loggers can all drink from the same stream instead of each needing a bespoke integration. I’d concluded that if nobody had built this by now, nobody was going to, and a standard nobody adopts is worthless, so mine had better be adoptable.

Progress came in bursts with long silences between, which you can see in the commit dates: a week of drafting in April 2024, then nearly a year of quiet; two days of rework in March 2025, then a year and a half more. Life got busy, as it does. Since retiring from client work to concentrate on my own projects, this one firmly among them, it’s moving again, and most of what’s in the repository today was built in the past week.

The problem

A motion rig is a chair that throws you around. To do that it needs to know what the vehicle in the game is doing, moment to moment. Same for a haptics vest, a button box with live readouts, a lap logger. They all need subsets of the same data, and currently every game either doesn’t provide it, provides it in a vendor locked way, or provides it in a shape nobody understands.

Previously when testing early-access VR games I’d often contact the developer whenever the game looked like it would be a fit for motion simulation and ask whether they’d consider adding motion support. They usually were interested, and would ask how. There are only really three ways to do it, and none is a good default. Implement a hardware vendor’s SDK, and your motion support now works with one ecosystem. Write a memory-mapped file, and it only works when the consumer software runs on the same machine as the game, which rules out consoles entirely. Send UDP packets, which works everywhere, except there is no agreed format, so every pairing of game and consumer software is a one-off integration with whatever documentation each side could find. And then the conversation would die because it all lands in the too-hard basket.

The existing ecosystem routes around the gap in ugly ways, basically every game needs its own custom plugin in motion software. One open plugin repo, GameLink github.com/Yaw-VR/GameLink-Plugins, Yaw’s open plugin repository., has 72 separate game readers built on four different mechanisms: game UDP, memory-mapped files, reading the game’s process memory, and TCP. WhitewaterVR, a rafting game, emits rpm, gear and per-corner suspension values, because that car shape is what the motion software expects, and a raft has no engine. Middleware like SpaceMonkey github.com/PHARTGAMES/SpaceMonkey, telemetry middleware that re-emits game data in the Dirt 4 packet shape. emulates the Codemasters Dirt 4 UDP packet so that anything which supports Dirt 4 supports it, which means flight sims and other non-car games get squeezed into a design based on cars. Star Citizen ships official D-BOX haptics support where the half carrying the actual game data is undocumented. Nobody involved is lazy; this is just what the absence of a standard results in.

I’d already tried the official route. I lobbied Frontier Developments for telemetry in Elite Dangerous, it cracked the top ten of their community feature vote, they said they’d look at it, and sometime later closed the issue.⊕ A community member going by Wagnard has released working memory offsets on the X Simulator forums after seemingly every update, which tells you the demand is real.

So when I sat down to write the standard, the guidelines I came up with were:

• The data structure must be easily understandable.
• The protocol must support multiple clients without opening additional ports or proxying.
• It must be implementable in both a console and a PC context.
• It must allow structured addition of extra telemetry datapoints.
• It must be network efficient.
• It must have low latency at all areas of implementation.
• It does not allow updating data within the game; the wire is read-only.

Everything since has been iteration based on those.

Where it stood a year ago

The first draft was JSON over UDP, and its structure was aggressively generic: every value self-declared its type, unit and valid range, so any game could emit anything and any client could consume it with no prior knowledge of the game. Racing, flight, marine, mechs, whatever showed up. Then the draft sat for the better part of a year.

Then I asked for feedback, and some stuck: JSON is verbose, and verbosity you hit sixty-plus times a second is a real cost. And AJ from Turtle Beach got in touch through Reddit’s chat, his message sat unnoticed for months until I saw it. By the time we finally spoke, he was the first person on the peripheral side who plainly got it, and he provided detail I didn’t already have. USB caps a device at 8 axes and 128 buttons, most games only bind 64, older ones 32, and flight sim panels eat that budget fast. A network protocol has no such ceiling. The conversation ran to wireless peripherals, force-feedback sticks that move to where the aircraft put them, readouts driven by real values instead of canned animations.

That lit a fire. I moved the data format to Cap’n Proto capnproto.org, a binary format whose wire representation is the in-memory representation, hence zero-copy. and the transport to Aeron, the messaging system from high-frequency trading. When Ron Burke, editor-in-chief of Gaming Trend, gamingtrend.com, where Ron is editor-in-chief. interviewed me about all of it for my channel, It’s VRK, youtube.com/ItsVRK, where I cover VR, motion simulators, and making the hardware actually work. I spent a fair stretch of our hour being enthusiastic at him about zero-copy and microseconds. The interview is a decent time capsule of where I’d got to. Then life commitments won again, and it all sat for another year.

Coming back to generic

Coming back to it with fresh eyes, I found the first draft was right about the important part. The leaner, racing-shaped design I’d diverged to after user input was efficient and narrow, and narrow is the wrong shape for a standard. When I started validating the schema against real sources, I found something unsurprising, but important: rafts with buoyancy corners, mechs with stomping feet, spacecraft that only expose accelerometer-style body forces, horses. Every one of those fits my generic schema; not one of them is a car.

The same broadening happened on the consuming end. The idea started firmly centred on motion simulators; that was the itch I was trying to scratch after all, the early drafts were clearly shaped by it. But a data stream that says what a game is doing is useful to anything on the local network that cares: haptics vests, dashboards, button boxes with live readouts, loggers, people building physical cockpits to match the one in the game. The standard treats them all as first-class consumers now, and because it’s multicast they all join the same group; nobody opens extra ports or runs a proxy. The GitHub organisation went the same way: it began life as the Open Motion Alliance and became the Open Game Standards Alliance, because a motion-only name was too narrow, and because there’s room for more open standards in gaming than the one I’m building.

v1, which is what the repository holds now, is a two-layer design. A DiscoveryFrame goes out at session start, on any change, and re-sent every two seconds: game name, environment, the objects being streamed, and channel declarations, each with an id, name, type, unit, range and description. That’s the metadata, sent at the cadence metadata actually changes. MotionFrames go out every telemetry tick, 60 Hz typical and not a ceiling, and carry the bare samples keyed by id; a pose-only frame is about 68 bytes, and a full car with four wheels of extended data and eight channels still fits comfortably under a UDP MTU. An EventFrame carries discrete stimuli for haptics, impacts, gunfire, footsteps, with short replay and deduplication so lossy transport won’t lose them. Motorsport solved this decades ago with CAN buses and DBC files: declare the signal dictionary once, stream bare values. LTS is that, for games.

A lot of the early thinking went into hunting the optimal protocol and format, something flexible enough for the constraints, and that produced the Aeron detour. What I settled on is the pragmatic but boring answer: plain UDP multicast, one socket, one group (239.255.17.17:40123 by default), no broker, no driver process, and every client on the machine or LAN just joins the group. Cap’n Proto stays: there’s no encode/decode step, frames are readable in place straight off the wire, and old decoders skip unknown fields and unknown union variants, so the schema can grow without breaking anything already deployed.

One decision went against where I was leaning in the interview: LTS for now is read-only. Telemetry that could command the game is a cheat vector for anything competitive, and commands need reliable, ordered, authorised delivery, which lossy multicast can’t safely carry. If a write path ever exists (and I do hope to get to it) it will be a separate opt-in profile with its own endpoint and handshake, never a flag on the telemetry stream. Force feedback doesn’t need this anyway; torque flows game to middleware on the read path, and the middleware already knows how to drive a wheel.

Does it fit real games

Talk is cheap, so I tested it: sixteen mapping exercises across six classes of source and more than a hundred documented game outputs, taking in official SDK documentation (MSFS 2024, iRacing, X-Plane 12), community reverse-engineered offsets (Elite Dangerous), vendor-encapsulated integrations (Star Citizen’s D-BOX path), game-native UDP outputs, injected providers, and consumer-side documentation.

Zero open gaps: every field in every source maps to a schema field, a ratified channel, or a sender-declared custom channel, which means the standard will do its job.

MSFS 2024 is the satisfying one. Its SDK exposes 1,354 variables, and the mechanism carries all of them, because a SimVar declaration and a channel descriptor turned out to be the same shape: name, unit, type. There are sender references written for MSFS 2024 and iRacing mapping their full documented sets, and a new conventions document that settles questions which can hurt integrations. Is positive steering left or right? Right. Radians or degrees? Radians, always, with a short whitelist of exceptions like °C and rpm. Road wheel or handwheel? Road wheel; the handwheel is a control-input channel. Every one of those was previously something you learned per game, usually the hard way.

There will be a .NET reference implementation: the envelope codec, a multicast sender and receiver, generated bindings, a demo sender, a conformance-checking receiver, and a test suite that passes, including a two-process loopback over real UDP multicast.

What happens next

The plan from here is engine plugins for Unity, Unreal and Godot, each shipping pre-generated Cap’n Proto code so a game developer never has to meet a schema compiler, plus low-level examples for custom engines. For anyone new to the concepts there’s a companion primer on motion telemetry github.com/Open-Game-Standards-Alliance/Motion-Telemetry-Documentation, a plain-language walkthrough of what motion software actually needs from a game. in the alliance’s repositories.

The corporate interest from the interview has since evaporated. Yaw have folded, and my contact at Turtle Beach, enthusiastic as he was, went quiet. At this stage the effort can’t depend on anyone external blessing it, so it doesn’t. The plugins, the sender references, the conventions document, the reference implementation are all things I will finish myself (but hopefully with additional input), so that when a game or hardware developer does look, everything they need is already sitting there.

The standard’s name will likely change eventually too: LTS already means long-term support in most software circles, and searching for it is an adventure. If you have a good idea, let me know!

If you develop games, or motion or peripheral hardware, the repository is the place to start: read the design document, open an issue, tell me where it doesn’t fit what you’re building. There’s a Discord server discord.gg/tseF4Q6U99, the Open Game Standards Alliance’s server. for the alliance, and my personal one discord.gg/yyCp5D2Ccp, my personal server. too. The standard is designed to be free to implement, developed in the open, and deliberately not owned by me; it lives under the Open Game Standards Alliance for that reason, and it only becomes a real standard if the people it’s for help shape it.

And a plain closing admission: I do still have bills to pay, this is a project I see benefiting a huge audience. If it’s useful to you or your company, sponsorship is welcome Via GitHub Sponsors, Buy Me A Coffee, or PayPal., as is code, feedback, and telling game developers about it.