Rivertale

A tense co-op loop built on three constraints: the ship is always moving, roles are divided between pilot and crew, and every action requires a physical prop.

Structure

The pilot steers via a rotary encoder while the crew manages cannons, the anchor, and repairs. No single player can handle everything. The ship's constant forward motion means indecision has immediate consequences: every second spent not communicating is a second closer to a wall or an enemy swarm.

Short, legible encounters follow an "I see this, it does that, I respond" pattern. Each challenge is designed to be read and solved within the time the ship takes to pass through the area.

Why It Works

The inability to stop the ship transforms communication from optional to structural. Players verbalize needs, delegate tasks, and solve problems in real time under real pressure. The Arduino props make every action tactile: twisting the steering wheel, spinning the capstan, loading the cannon.

Three enemy types, each with a distinct role in the encounter structure: damage dealer, setup tool, and final test.

Ranged Enemy (Damage)

Fires slow projectiles that use a quadratic intercept formula to predict where the player will be if they do not move. Shots are dodgeable but threatening, forcing players to decide: dodge, shoot, or handle another active task.

The system uses player velocity and position combined with projectile speed to calculate the future intercept point, converting it to a rotator for projectile spawn. An animation notify triggers the exact spawn frame. The result: readable threat, not random punishment.

Swimming Enemy (Setup)

Spline-based movement triggered by a trigger box. Speed stays constant via a rate calculation over the full spline path. Level designers place the enemy and adjust the spline: no code required.

During playtesting, players kept trying to shoot this enemy even though it was intended as a setup tool, not a combat target. Rather than blocking the behavior, I made the enemy killable. Players had more fun, communication increased, and the encounter became richer. Sometimes the player solution is better than the design solution.

Boss Enemy (Final Test)

Combines all mechanics into a climax encounter. Attacks via a spline-based rock projectile that drops the anchor, stops the ship, and deals damage. At close range, switches to a weighted random decorator in the behavior tree that rolls between summoning a hazard (damage-dealing statue) or spawning a ranged enemy.

An enemy-triggered mechanic that stops the ship completely, forcing a player to sprint to a physical capstan prop and spin it to restore movement.

How It Works

An enemy drops the anchor, instantly overriding the ship's speed to zero. A player must reach the physical capstan prop (containing a rotary encoder) and rotate it in the correct direction. The Arduino reads encoder input and increments a float until it reaches maximum, at which point the anchor raises and movement resumes.

The first prototype used a button hold, which felt arbitrary. The final rotary encoder solution creates physical feedback that matches the mental model: you are winding up rope. A motor in the prop physically lowers a visual element when the anchor drops in-game.

Design Evolution

A non-intrusive correction system that prevents players from turning around or leaving bounds, while preserving a genuine sense of freedom.

How It Works

Invisible guidance splines follow the river's center path. The ship smoothly interpolates back to the path if it deviates for more than 4 seconds. A 110-degree detection arc (55 degrees left and right of the ship's nose) checks for spline presence: within the arc, no correction; outside it, auto-return triggers.

V2 added collision-triggered border splines for hard-boundary edge cases. On contact, the ship instantly but smoothly reorients. The 4-second delay gives players enough room to feel free while preventing real exploits.

Why It Matters

QA revealed that players fought the forward momentum, causing frustration and out-of-bounds states. The solution was not restricting them more. It was giving them the illusion of freedom within safe bounds. Players stopped noticing the system and started focusing on objectives.

An 8m x 3.5m screen with lighthouse tracking and custom Arduino props: every in-game action maps to a physical interaction in the real space.

The stage's scale, the big screen, and the lighthouse tracking system were the constraints we built around. Custom Arduino kits became cannons, an anchor capstan, and a steering wheel. Performing any action in the physical space translates directly to the screen, creating a level of immersion impossible with standard controllers.

Iterative solutions to reduce collision risk, motion sickness, and prop-interaction confusion in a large-scale physical play space.

Key Iterations

Wired to wireless: early builds used wired Arduino connections in a cramped space, creating tripping risks. Switching to WiFi receivers let us spread props across the full play area.

Stationary pilot: a moving pilot at elevation risked falls. Anchoring the pilot position and designing steering challenges around that constraint eliminated the risk while creating new tactical interest.

Prop feedback: players interacted too roughly with props because they assumed they were broken. Changing the trigger condition (first interaction requires multiple presses to "repair") and adding clear VFX and SFX cues fixed the expectation mismatch.

Why This Matters

Discomfort is not immersion. Players cannot engage with an experience if they feel physically at risk. Safety design is not a constraint on the creative work: it is the precondition for it.