Build on yourmove.live
Bring your own hardware, connect it to a real live-room platform, and get it online privately before you ever think about going public. We want this to feel like home for builders.
Start Here
The goal is to get a developer from concept to a private working node with as little friction as possible.
Learn the Integration Path
Read the docs for the architecture, edge runtime, MQTT command model, and private launch checklist.
Run the Linux Edge Path
The supported path today is our Linux-based edge runtime near the rig. It handles live publishing, buffered clips, and runtime health.
Launch Privately First
Get a private node, wire up the hardware, tune it, and prove reliability before it ever reaches the public side of the platform.
Built For Developers
Your Hardware
Run your own motors, relays, sensors, feeders, launchers, lights, or custom mechanisms. If you can control it electronically, you can connect it.
Your Camera Feed
Bring an IP camera or other live feed that shows the action clearly. Viewers need to understand the target, the motion, and the result at a glance.
Your Integration
Connect over MQTT, translate commands into physical behavior, and report state back cleanly. We are optimizing for practical builders, not academic demos.
Private First
Developer nodes start private. You can wire it up, calibrate it, and test it in peace before it is reviewed for public launch.
What Makes a Good Node
The most successful developer-built experiences tend to share the same traits.
Immediate Cause and Effect
Players should be able to tell right away what their action did. If the feedback loop is muddy, the product gets weaker fast.
Clear Visual Framing
The target, motion, and result should read cleanly on camera. A good node is easy to understand even with the sound off.
Reliable Recovery
Nodes need sane limits, clear fail states, and safe recovery paths. Reliability matters more than showing off complicated hardware.
Clip-Worthy Moments
The strongest nodes naturally create moments people want to replay and share. That matters for retention and discovery.
What You Build
The physical part is yours. The better you design it, the better the live experience feels.
A Physical Device
Water cannon, treat dispenser, ball launcher, paint sprayer, switchable environment, kinetic sculpture, or something stranger. If it can be driven by commands, it can fit.
A Camera
Use an RTSP, RTMP, or otherwise ingestible live feed that clearly shows the interaction area.
A Feed Bridge
You need a small local machine that takes your camera feed and sends it up to the platform reliably. You can use our existing Linux edge code for that today, and we plan to offer a Windows version later.
A Command Client
Your device connects through MQTT. Subscribe to commands, execute them safely, report results, and keep state current. Run it on an ESP32, Raspberry Pi, or your own edge runtime.
An Internet Connection
Stable upstream connectivity matters. Video quality, viewer confidence, and command reliability all suffer when the network is weak or inconsistent.
Developer Toolkit
The practical pieces you need to connect hardware to the platform and iterate on it.
Local Edge Runtime
Run the edge software locally to manage live video publishing, buffered clip creation, health reporting, and node-side coordination close to the hardware.
Reference Firmware
Use the existing ESP32 firmware path as a starting point for motion control, relay actions, reporting, bounds, and command execution patterns.
Schematics and Pinouts
We already have working control patterns, pin mappings, and hardware assumptions for current node types. The goal is to expand those references, not keep them tribal knowledge.
MQTT Command Model
Commands, acknowledgements, presence, and reported state already follow a concrete lifecycle. Your integration does not need to invent a control protocol from scratch.
Diagnostics and Calibration
The platform already includes diagnostics, boundary controls, inversion settings, cooldown tuning, scheduling, and operator visibility for real-world rigs.
Private Integration Path
You can build privately first, test against the live platform, and only move toward public launch once the node is actually stable and worth showing.
How the Integration Works
At the core, this is a command-and-state loop over MQTT with explicit reporting back to the platform.
Command Flow
{
"command_id": "uuid",
"class": "action",
"type": "fire",
"payload": { "pan": 45.0, "tilt": -12.5 },
"issued_at": 1710000000,
"expires_at": 1710000002
}When a player aims, moves, or fires, the platform emits a command with a lifecycle and expiry window. Your runtime validates it, executes it safely, and reports back what actually happened.
Device Reporting
{
"command_id": "uuid",
"status": "ack"
}
{
"command_id": "uuid",
"status": "completed"
}
{
"state": "online"
}Your runtime reports acknowledgements, completion, presence, and current state. That lets the product know whether the hardware is healthy, in-bounds, and ready for the next player.
Need Help With a Private Launch?
If you want help choosing a hardware pattern, bringing a private node online, or packaging a project for the platform, send a note here.
No spam. We will only use this to follow up about building on the platform.
