Proposal: Quests as a Data Product

Status — product/strategy proposal, not shipped

This is the third piece of the quests thread, alongside the quests-data-model (Zoinkwiz — entities) and Player-Tier KPIs (Marco — tier values). Those two answer how a quest is structured and rewarded. This one answers the question that funds the whole thing: which quests produce data someone will actually buy, and which are a waste of capture. It adopts the existing model verbatim — a quest is still a lobbies party + quest_id attribution + a requirements JSON — and only fills the content side: what to put in objective / requirements, ranked by buyer value. Nothing here is shipped.

Under the Reward Economy (the reward spine), the buyer-value ranking below is also the pricing input: a quest's set cash reward is tuned to how valuable its captured scenario is. High-value quests on these axes justify larger payouts; commodity quests aren't built at all.

0. The one decision this document is built on

We are not selling gameplay video. The open web is already saturated with single-POV gameplay video (YouTube, Twitch), it is being exhausted as a training corpus, and scraping it is now a legal liability — Anthropic settled a training-data copyright suit for $1.5B; YouTubers are suing several frontier labs over scraped video. So a quest whose only output is "more gameplay video" produces a commodity and should not be built.

What is not scrapable — and is therefore what we sell:

1. Dense actions synced to frames (_input.csv ↔ video, tight). Their highest-value use for a buyer is as a seed to train an inverse-dynamics model (IDM), which then auto-labels the cheap public video the buyer already owns. OpenAI's VPT trained an IDM on 1,962 labelled hours and used it to label ~70,000 — "two orders of magnitude more data-efficient." The moat is sync precision, not hours.
2. Verbalized real-time intent aligned to the action trajectory. This is a recognized, measured lever (Embodied Chain-of-Thought: +28% absolute task success) and a genuine white space — existing game-language datasets are third-person spectator commentary, not first-person "I'm about to flank left."
3. Multiple synchronized POVs of the same session. Multi-view of one dynamic 3D scene is the native supervision for 4D reconstruction and is explicitly "the main challenge" for multi-view video generation (labs render synthetic Unreal rigs to fake it). N players in one Playroll party = this, for free — and the cross-POV pair count scales N×(N−1) (see §1.2), so party size is a value multiplier, not a linear knob. It pays off only when the viewpoints actually cover the space from complementary angles (parallax, loop closure), not when N players all stare the same way — a distinct design property we score as axis E.
4. Consent / clean provenance, PII-free. Every Playroll capture is player-authorized — the structural moat over scraped data (a purchase gate, not a feature). Buyers want PII-stripped data, not raw (no passwords, names, card numbers on screen), so quests must avoid eliciting on-screen PII.

Every quest below is scored on how much of (1)–(3) it activates; (4) it inherits for free (subject to the PII constraint). The two axes Marco prioritized — bespoke intentionality and multi-sync POV — are (2) and (3), and the market brief confirms they are the most defensible, least-filled, highest-priced characteristics.

Who actually buys

The primary paying buyer is world-model labs (action-conditioned / interactive world models). Robotics is a secondary, future-leaning option, not a near-term market — and not "useless," as an earlier draft of this doc overstated. The honest position: the architecture is proven compatible (gameplay can be trained on a robotics foundation-model net and still improve on unseen games), but no robotics lab uses gameplay data in a control pipeline today, and game engines fake contact physics, so motor-control transfer is unvalidated. The defensible robotics angle is high-level only — navigation/locomotion priors, long-horizon intent, multi-agent coordination. Net for quest design: don't build manipulation/force quests (§5, Q9); treat robotics as a future high-level option, not a dead end.

1. The triage framework — five axes

Every candidate quest is scored 0–3 on each axis. The verdict is not the sum — it is the rule in §1.3.

1.1 The axes

Axis	What it measures	Why a buyer pays for it
A · Intentionality density	How much declared intent (real-time voice) is bound to a trajectory that fulfils it	(goal → trajectory) pairs are the substrate of every modern VLA; narrated rationale is a measured +28% lever and a white space
B · Multi-sync POV	N humans, same environment, same clock, multiple cameras	Multi-view of one dynamic scene = scarce 4D supervision; simultaneously yields multi-agent behavioural data; pair count scales N×(N−1)
C · Action-conditioning purity	How clean the input → on-screen effect channel is (low menu/RNG/UI noise)	A tight, legible CSV↔frame mapping is what makes the data IDM-trainable rather than garbage
D · Domain transfer	Does the data-domain map onto something a buyer trains (navigation, locomotion, long-horizon planning, social coordination)?	Decides whether the slice has any buyer at all; spite reserved for fake-transfer domains
E · Reconstruction coverage	Do the POVs cover the space from complementary angles (parallax, motion, loop closure) rather than all pointing the same way?	Turns multi-POV from "several near-identical views" into views that actually constrain 3D geometry — the difference between multi-view video and a reconstructable scene

Axis E only applies when B > 0 (no second POV, nothing to reconstruct across). A high-B / low-E quest is multi-view video; a high-B / high-E quest is a 3D capture rig made of players.

1.2 The party-size multiplier (why max_party is a value lever)

The number of cross-POV pairs in a lobby scales N×(N−1): 2 players = 2 pairs, 5 = 20, 10 = 90. Multi-POV value is therefore super-linear in party size — a 5-stack is not "a bit more" than a duo, it is 10× the cross-view pairs. And it is exactly the data that almost never gets captured — game servers process and discard it in real time, so a multiplayer session recorded from every seat is genuinely scarce. Consequence for authoring: for any B-axis quest, bias max_party upward and reward full parties — as long as axis E (angular diversity) holds, since 10 players all facing the same wall is still just one viewpoint's worth of geometry.

1.3 The verdict rule (deliberately spiteful)

• PREMIUM — high (≥2) on A or B, and ≥2 on C, and the data is hard to get elsewhere. B-axis premiums additionally need ≥2 on E to be worth their capture cost (otherwise they're commodity multi-view video).
• PLAUSIBLE — high on one axis, mediocre elsewhere, but still produces a non-scrapable signal. Build opportunistically.
• COMMODITY — produces mostly video a buyer can scrape for free. Do not build, regardless of how fun it is.
• USELESS / FAKE-TRANSFER — pitches a domain (contact physics, manipulation) the buyer cannot use from game data at all. Refuse to build even if asked.

2. Game catalogue, classified by data-domain

From the live res/games.json (all 20 enabled), grouped by what they actually produce — not by genre:

Data-domain	Games	Best for axis
Open-world driving + urban navigation	GTA V, Cyberpunk 2077	D (navigation/locomotion), C (driving = clean control)
Open-world 3D traversal + object interaction (SP)	Witcher 3, Elden Ring, Starfield, Hogwarts, BG3, Cyberpunk	A (intent-rich), D (navigation)
FPS tactical squad (shared bounded space)	CS2, CSGO, Valorant	B (multi-POV), A (callouts = native intent)
FPS / BR squad (traversal + combat)	Apex, PUBG, Fortnite, Overwatch 2	B, D (traversal)
Continuous vehicle control + multi-agent, clean physics	Rocket League	C (purest action channel), B
Manipulation / construction / long-horizon planning	Minecraft (Bedrock + Java)	A (planning), D (long-horizon), B (co-op build)
Top-down strategy (multi-agent, low embodiment)	LoL, Dota 2	weak — see §5

3. The quest catalogue (triaged)

Each quest gives: the four-axis score, the v1-shippable form (fits the current requirements DSL: min_party, min_qualified_minutes, required_game, plus a rich text objective), and the ideal form (what it becomes once the DSL is extended — §4), so the feature gap is explicit.

---

Q1 · "Convoy" — synchronized multi-POV driving relay ⭐ PREMIUM

Game: GTA V (or Cyberpunk). Party: 3–4. Domain: driving + nav. A → 2 · B → 3 · C → 3 · D → 3 · E → 2

Three-to-four players drive a fixed route through the city as a convoy — same start, same waypoints, same clock — each recording their own POV. One scene, multiple synchronized cameras, plus a maximally clean action channel (steering = analog input → on-screen motion, almost no menu/RNG noise).

• Why premium: delivers B (multi-POV of one dynamic scene) and C (cleanest possible CSV↔frame mapping) at once — the exact combination the IDM-seed and the 4D-reconstruction buyers both want. Driving is also the domain robotics will actually touch (locomotion/navigation priors).
• Reconstruction caveat (axis E): a naive convoy where everyone faces forward along the same heading gives correlated viewpoints — weak parallax, poor point-cloud coverage. Design the route to spread the angles: stagger positions, include a roundabout / plaza where cars face inward, or assign one member a trailing/overhead role. This is the difference between "multi-view driving video" and a reconstructable street. Raises E from ~1 to 2–3.
• v1 objective: "Form a convoy of 3. All members drive the marked route (Vinewood → docks) together without splitting up. Record ≥10 minutes of continuous driving."
• v1 requirements:

  { "min_party": 3, "required_game": "gta5", "min_qualified_minutes": 10 }

• Ideal requirements (needs DSL §4):

  {
    "min_party": 3,
    "required_game": "gta5",
    "min_qualified_minutes": 10,
    "multi_pov": { "min_synced_povs": 3, "max_clock_skew_ms": 50 },
    "route": { "waypoints": ["vinewood", "docks"], "max_split_distance_m": 200 }
  }

• Gap to premium: verified cross-POV clock sync (max_clock_skew_ms) and a proximity check that the party actually stayed together. Without them it's still good; with them it's the flagship.

---

Q2 · "Callout" — narrated tactical clear ⭐ PREMIUM

Game: CS2 / Valorant. Party: 2–5 (bias to 5 — §1.2). Domain: FPS squad. A → 3 · B → 3 · C → 2 · D → 2 · E → 3

A squad clears/holds a site while each player narrates intent in real time ("I'm smoking A-main, you flank") — the callouts are the intent labels, time- aligned to each player's action CSV, across synchronized POVs of one bounded 3D space.

• Why premium: hits A (narrated intent — the white space) and B (multi-POV + multi-agent) maximally. FPS callouts are the most natural source of first-person verbalized intent that exists — players already do it, we just capture and align it. This is the single most defensible quest in the catalogue for the intentionality buyer.
• Best-in-class on axis E: a 5-stack clearing a site naturally spreads across the space facing different directions and angles — exactly the complementary coverage a point cloud needs. A bounded competitive map is a near-ideal reconstruction volume, and at party 5 the N×(N−1) multiplier gives 20 cross-POV pairs per session. Run this at full party, not as a duo.
• PII watch (§0 point 4): competitive lobbies can surface usernames / chat — keep the quest framing on voice + in-world action and rely on PII sanitization before any sale.
• v1 objective: "5-stack a competitive match. Use voice the whole time and call your intent out loud before you act (entries, utility, rotations). Record ≥15 minutes."
• v1 requirements:

  { "min_party": 5, "required_game": "cs2", "min_qualified_minutes": 15 }

• Ideal requirements:

  {
    "min_party": 5,
    "required_game": "cs2",
    "min_qualified_minutes": 15,
    "voice_required": true,
    "intent_density": { "min_utterances_per_min": 2 },
    "multi_pov": { "min_synced_povs": 5, "max_clock_skew_ms": 50 }
  }

• Gap to premium: voice capture + a speech-density check (voice_required, min_utterances_per_min). The v1 form relies on the objective text to prompt narration and on downstream filtering to keep only voiced sessions — shippable, but lossy. The ideal form makes intent a hard requirement.

---

Q3 · "Think Aloud" — narrated solo traversal & decision ⭐ PREMIUM (single-axis)

Game: Elden Ring / Witcher 3 / BG3 / Starfield. Party: 1. Domain: 3D traversal + intent. A → 3 · B → 0 · C → 2 · D → 2 · E → n/a (single-POV)

A solo player narrates what they are about to do and why while navigating an open world and making decisions ("I'll take the cliff path to avoid the patrol; saving my flask for the boss"). Pure (goal → trajectory) generation with a running rationale — exactly the data ECoT had to synthesize because human narration paired to trajectories is scarce.

• Why premium on A: densest possible intentionality per capture-hour, no coordination overhead. Scales trivially (every solo player can do it).
• Why not B: single-POV by design — that's fine, the value is the narration, not the multi-view.
• v1 objective: "Play for 20 minutes and think out loud: before each major move, say what you're trying to do and why. Keep talking through detours, fights, and decisions."
• v1 requirements:

  { "min_party": 1, "required_game": "eldenring", "min_qualified_minutes": 20 }

• Ideal requirements: adds voice_required, intent_density, and optionally a post-hoc segment-tagging pass (player marks sub-goals).
• Gap: same voice-density gap as Q2. This is the cheapest premium quest to run (no party) but needs the voice feature to be worth the premium price.

---

Q4 · "Co-op Build" — long-horizon collaborative construction · PLAUSIBLE→PREMIUM

Game: Minecraft. Party: 2–4. Domain: long-horizon planning + manipulation-in-sim + co-op. A → 3 · B → 2 · C → 2 · D → 2 · E → 2

A party plans and builds a specified structure together, narrating division of labour and sub-goals. Long-horizon, goal-directed, multi-agent — and Minecraft is already a proven world-model corpus (Oasis conditions next-frame prediction on logged Minecraft input over "millions of hours"), so the buyer fit is demonstrated, not hypothetical.

• Why not automatically premium: Minecraft single-POV gameplay is somewhat scrapable, so the value rests on the narrated plan + multi-agent sync, not the footage. With voice + multi-POV it's premium; without, it drifts toward commodity.
• Honest caveat: the "manipulation" here is in-engine block placement, not contact dynamics — sell it as long-horizon planning + multi-agent coordination, never as robotic manipulation transfer.
• v1 objective: "Team of 3 builds the target blueprint together in one session. Split roles out loud (who gathers, who builds) and talk through the plan. Record ≥25 minutes."
• v1 requirements:

  { "min_party": 3, "required_game": "minecraft", "min_qualified_minutes": 25 }

• Ideal requirements: voice_required, multi_pov, plus a semantic completion check (structure_completed) that needs structured game-state extraction (§4, hardest gap).

---

Q5 · "1v1 Mechanics" — clean control under a fixed goal · PLAUSIBLE

Game: Rocket League. Party: 1–2. Domain: continuous vehicle control. A → 1 · B → 1 · C → 3 · D → 1 · E → 1

Rocket League is the purest action channel in the catalogue: continuous analog control, deterministic physics, almost zero UI/menu/RNG contamination between input and on-screen effect. Ideal IDM-seed material — the data trains a clean inverse-dynamics model.

• Why only plausible (not premium): it maxes C but is weak on A/B/D — the domain (arcade car-soccer physics) transfers narrowly. Build it specifically when a buyer wants a high-purity action↔frame calibration set, not as a flagship.
• v1 objective: "Play 15 minutes of focused 1s/2s. No idling in menus — continuous play."
• v1 requirements:

  { "min_party": 1, "required_game": "rocketleague", "min_qualified_minutes": 15 }

• Ideal: add a menu_time_max_pct purity gate (needs menu/active-state detection) so we only keep the clean-control portion.

---

Q6 · "Squad Wipe" — synchronized BR engagement · PLAUSIBLE

Game: Apex / PUBG / Fortnite. Party: 3–4. Domain: traversal + multi-agent combat. A → 2 · B → 3 · C → 2 · D → 2 · E → 1

A squad drops together and plays a full rotation with voice. Strong multi-POV + multi-agent + traversal, but the BR loop has more downtime (looting, running) than CS2's bounded engagements, so intentionality density is lower per minute.

• Verdict: a solid B/multi-agent quest; pick it over Q2 when you want traversal coverage in addition to coordination. Same voice/multi-POV gaps.
• Why E is low (the key contrast with Q2): BR squads spread out over huge maps — players are often hundreds of metres apart looking at different places, so the POVs rarely overlap on the same geometry. Great for multi-agent behaviour, weak for 3D reconstruction (axis E). This is exactly why a bounded-map quest (Q2) beats a BR quest for multi-view geometry even at equal B. Use Q6 for behavioural-trajectory buyers, Q2 for reconstruction.
• v1 requirements:

  { "min_party": 3, "required_game": "apex", "min_qualified_minutes": 20 }

---

Q7 · "Tourist" — open-world free-roam, no narration, single POV · COMMODITY ✗

Game: any open-world. Party: 1. A → 0 · B → 0 · C → 1 · D → 2 · E → 0

Just "play and record." Produces single-POV gameplay video with an action CSV attached. The action CSV has some value, but a buyer can train an IDM from a handful of focused sessions and then label scrapable video themselves — so a volume play of unstructured free-roam is low-margin at best.

• Verdict: do not build as a flagship. Acceptable only as a cheap top-up to reach IDM-seed volume in a domain we're thin on, and only if it costs us almost nothing. Never price it as premium.

---

Q8 · "Grind" — maximize recorded hours, any game · COMMODITY ✗

A → 0 · B → 0 · C → 1 · D → 1 · E → 0

A pure-volume quest ("record 100 hours this week"). This is the trap the market brief warns against directly: raw single-POV video volume is the commodity, and the IDM result means hours past the seed threshold add little. It also incentivizes low-effort capture that dilutes dataset quality.

• Verdict: refuse. If we need volume, it's volume of a premium shape (more Convoy/Callout sessions), not undifferentiated hours.

---

Q9 · "Robot Hands" — anything pitched as manipulation/force transfer · USELESS / FAKE-TRANSFER ✗✗

Any quest sold to robotics on the promise of contact dynamics, grasping, force/torque, or fine motor control.

Game engines fake contact physics; passive game video reveals what is attempted but not the contact forces — it adds noise, not signal, for motor control, and no robotics lab uses gameplay data in a control pipeline today.

• Nuance (don't overstate it as "useless"): the architecture is proven compatible — gameplay can be trained on robotics foundation-model nets and still improve on unseen games. So the correct refusal is narrow: don't build manipulation/force quests (the signal genuinely isn't in the data), but don't tell a robotics buyer game data is worthless — the high-level slice (navigation/locomotion priors, long-horizon intent, multi-agent coordination — Q1/Q3/Q4/Q6) is a plausible future option, just not a near-term control product.
• Verdict: refuse the manipulation framing; keep the high-level robotics door open. Selling contact/force transfer from game data is a credibility risk with a skeptical buyer; selling behavioural-trajectory breadth is defensible.

---

3.1 Triage summary

Quest	A	B	C	D	E	Verdict	Build?
Q1 Convoy (driving multi-POV)	2	3	3	3	2*	PREMIUM	First
Q2 Callout (narrated FPS squad)	3	3	2	2	3	PREMIUM	First (full party)
Q3 Think Aloud (narrated solo)	3	0	2	2	n/a	PREMIUM (A)	First (cheap)
Q4 Co-op Build (Minecraft)	3	2	2	2	2	PLAUSIBLE→PREMIUM	Soon
Q5 1v1 Mechanics (Rocket League)	1	1	3	1	1	PLAUSIBLE	On demand (IDM-seed)
Q6 Squad Wipe (BR)	2	3	2	2	1	PLAUSIBLE	Soon (behaviour, not 3D)
Q7 Tourist (free-roam)	0	0	1	2	0	COMMODITY	Top-up only
Q8 Grind (volume)	0	0	1	1	0	COMMODITY	No
Q9 Robot Hands (manipulation)	–	–	–	0	–	FAKE-TRANSFER	Refuse

*Q1's E is 2 only if the route is designed for angular diversity (§Q1); a naive forward-facing convoy is E≈1.

The pattern is deliberate: everything we build first is high on A or B — the two axes Marco prioritized and the two the market values most. Axis E is the tie-breaker among multi-POV quests: it promotes Q2 (bounded map, E=3) to the top of the pack and demotes Q6 (dispersed BR, E=1) to a behavioural-only play. Everything we refuse is single-POV, narration-free, or fake-transfer. Remember the N×(N−1) multiplier (§1.2): among B-axis quests, run them at full party, not minimum.

4. What the requirements DSL needs to make premium quests real

The current v1 DSL (min_party, min_qualified_minutes, required_game) can express every premium quest's objective, but it cannot verify the properties that make them premium. Each v1 form above therefore leans on the text objective + downstream filtering. To make the moat enforceable rather than hoped-for, the DSL needs, in priority order:

1. voice_required + intent-density check (unlocks A — Q2, Q3, Q4). Requires the voice-capture path to be on for the session and a minimal speech-presence / utterance-rate signal. Highest ROI: A is the white space and the cheapest premium axis to run (Q3 needs no party).
2. multi_pov block: min_synced_povs + max_clock_skew_ms (unlocks B — Q1, Q2, Q6). The party is already single-game and co-recording, so the data exists; what's missing is a verified shared clock across POVs and a check that N actually recorded simultaneously. This is the sync-precision moat the market prices highest — it is the one thing to over-engineer.
3. Action↔frame sync verification (raises C everywhere). Not a quest field — a quality gate on the capture itself, surfaced as a per-session score. The IDM-trainability of the whole product depends on it. Already partly in the pipeline's wheelhouse (frame-numbered _input.csv); needs a measured, reported alignment confidence.
4. Reconstruction-coverage signal (axis E) — a per-session score for how well the synchronized POVs cover the space (viewpoint angular spread / overlap / parallax). This is what separates "several near-identical views" from "reconstructable 3D." It pairs with (2): a multi-POV session should be scored on both sync tightness and coverage. Bias max_party up (§1.2) but gate on coverage, not headcount.
5. route / proximity check (raises Q1, Q6 from good to premium). Needs in-game position — i.e. structured game-state extraction.
6. Semantic completion checks (structure_completed, objective_reached) — needs structured game-state extraction, the hardest and least-portable gap (per-game). Defer until a specific buyer pays for it; do not build speculatively.

Sequencing

(1) and (2) — voice and verified multi-POV sync — are the whole game. They turn Q1/Q2/Q3 from "good objective text + hope" into enforceable premium products and map exactly onto Marco's two priority axes. (3) and (4) — sync verification and reconstruction coverage — are what make the data IDM-trainable and 3D- reconstructable; build them right after voice. (5)/(6) require per-game state extraction and should be buyer-pulled, not built on spec.

5. Explicitly low-value (don't waste capture)

• LoL / Dota 2: top-down, low-embodiment, and competitive mastery doesn't need human data (self-play already superhuman). Human value would only be human-coordination modeling — a narrow buyer, and the top-down view is poor for the world-model/3D pole. Park them.
• Single-player open-world without narration: that's Q7 — commodity.
• Anything optimizing for raw hours: Q8 — the IDM result caps the value of volume past the seed.
• Any manipulation/force/contact framing for robotics: Q9 — refuse the framing (the signal isn't in the data), but keep the high-level robotics door open (§0 "Who actually buys") — game data is architecturally compatible, just not for motor control.

6. Recommended first slate

Three quests, chosen to cover both priority axes and validate the two DSL gaps that matter, with minimal new infrastructure:

1. Q2 Callout — proves A + B + E together on a bounded scene (E=3, the best reconstruction volume in the catalogue); competitive squads already narrate, so it's the lowest-friction way to validate voice-intent capture. Run at full 5-stack for the N×(N−1) multiplier. The flagship multi-POV quest.
2. Q1 Convoy — proves B + C and the verified-multi-POV-sync gap on the cleanest driving channel; design the route for angular diversity (axis E) so it reconstructs, and it doubles as the high-level navigation slice for a future robotics conversation (not control).
3. Q3 Think Aloud — proves A alone with zero coordination cost; the cheapest way to start accumulating the narrated-intent white-space corpus while the multi-POV plumbing lands.

Run all three in their v1-shippable form now (objective text + the existing three requirements), in parallel with building DSL gaps (1) and (2). Each v1 run is already sellable; the DSL work is what lets us charge premium for it and enforce the moat instead of filtering for it after the fact.

---

Open items, deferred to a later conversation: exact price tiers per axis (and per N×(N−1) pair yield); whether structured game-state extraction (§4.6) is ever worth its per-game cost — answer only when a buyer asks for Q1's route check or Q4's completion check by name.