jankenbots/docs/prototype-plan.md

Prototype build-plan — networked shared bot

Goal: the smallest thing that lets me + 2–5 friends get into a shared arena over the internet and feel out whether coordinating one janky bot together is fun. Throwaway code — feel over fidelity. If it's fun, we keep going; if it groans, we iterate the control model (or flip to the asymmetric drive fallback) before spending anything on real netcode.

Stack (decided)

• Unity (engine, decided) — project lives on the Windows host.
• Netcode for GameObjects (NGO) — high-level networking.
• Unity Relay + Lobby — friends join by code, Relay handles NAT so nobody port-forwards. Needs a free Unity account / Unity Gaming Services project.
• Host-authoritative physics — the host owns the bot's Rigidbody simulation; clients send tread inputs (RPCs / NetworkVariables), host simulates, NGO replicates transforms. Remote clients see interpolated transforms (non-host bots/parts kinematic). This is the simple version of "Plan A" server-auth — not a commitment to the final architecture.

Deliberately not doing client-side prediction, rollback, or Quantum here. Low-latency friends + host-authoritative + interpolation is plenty to judge the feel.

Milestone 1 — "two treads, some friends, a flat floor"

The thesis test. Build order, each step independently testable:

1. Empty networked scene. NGO + Relay wired: Host button (creates a Relay allocation → shows a join code) + Join button (enter code). Two builds connect over the internet. Prove connectivity first, nothing else.
2. A capsule you can drive, replicated. One networked player-controlled cube on the floor; movement host-authoritative (input → RPC → host moves it → replicates). Confirms the input→host→replicate loop and that it feels ok over real ping.
3. The shared bot: chassis + 2 treads. One bot in the scene. Each tread is a force-applying part on the shared chassis Rigidbody. Seat assignment: first two players claim left/right tread (unclaimed treads = neutral/free, per leaver-safety).
4. Tread control = the v0.1 model.
   • Snap-to-cruise throttle (stick/trigger): full-forward → fixed cruise force; partial = proportional. Both treads at cruise ⇒ straight.
   • Lock-pivot (button): plant this tread as a pivot anchor.
   • Passive lean (stick sideways): apply a ballast torque to fight tipping.
   • Apply as literal forces to the shared body so differential drive + jank emerge.
5. Something to do: a big physics ball to shove around, or a few cones / a rough goal. No scoring needed — just a shared objective to make coordination matter.
6. Feel juice (cheap): weighty tuning (mass/drag so it's not twitchy), a follow camera framing the whole bot, and — if quick — the audio "grind on mismatch" cue. Skip haptics/vfx for v1.

Success = the answer to one question: with friends on voice chat, is wrestling this bot around funny and satisfying, or infuriating? Watch for the kill signal: groans not laughs + people asking for direct solo control → iterate the model (try the asymmetric throttle/steer split) before going further.

Explicitly out of scope for M1

Building/scavenge phase · weapons · gremlins · voting · themes/art · 25 players · dedicated servers · prediction/rollback · the real netcode architecture. All later.

Milestone 2 (only if M1 is fun) — "add a hammer"

One weapon pilot on the shared bot → test the three-body call-and-response (telegraphed wind-up, braced-bonus plant-and-pound, weapon-as-counterweight). This is where the coordination comedy should really sing. See DESIGN.md → Weapon pilots & three-body coordination.

Open setup tasks

• Create the Unity project on Windows; pick Unity LTS; add the NGO + Relay + Lobby packages via Package Manager.
• Set up a Unity Gaming Services project (free tier) for Relay/Lobby; note the project link (not secrets) in memory.md references.
• Decide the Unity project's version control (git on F:\ pushed to Forgejo, vs symlinked into this repo).
• Stand up the Unity MCP server so Claude can help build in-editor.