Guide

Game conveyor belt and moving walkway systems explained

Harbor Assembly shipped a crate-sorting factory floor where players rode horizontal belts through timed laser gates. Playtest telemetry showed 44% drop-off on the second belt segment: the implementation teleported the player each frame by adding belt offset directly to world position, ignoring the character controller’s velocity integration. Walking against a fast belt felt like ice; walking with it felt like a speed hack; jumping off the trailing edge zeroed horizontal momentum so players missed the next gate by one tile every time. Refactoring to surface velocity coupling, input-relative effective speed, and edge exit carry lifted floor completion from 44% to 79% and cut “belt is broken” feedback by 68%.

Conveyor belts and moving walkways look like moving platforms but behave differently: they apply continuous tangential velocity along a surface rather than transporting riders along discrete waypoint paths. Belts teach timing, direction reading, and factory rhythm. This guide covers surface velocity models, friction coupling with player input, belt edges and exit momentum, reversible and vertical belts, hazard and puzzle coupling, networked determinism, the Harbor Assembly refactor, a technique decision table versus moving platforms and static tiles, pitfalls, and a production checklist.

Belts vs moving platforms: different reference frames

A moving platform carries riders through space along a path; when you jump, you inherit the platform’s instantaneous velocity vector. A conveyor belt is usually a stationary collider (or a looping texture) that imparts tangential velocity to anything grounded on it. The geometry often does not translate — only the contact surface has motion.

That distinction drives implementation:

Platforms — add position delta or parent transforms; velocity on exit equals platform velocity plus jump impulse.
Belts — set or add a surface velocity vector each frame while grounded; player input modifies speed relative to the belt, not always relative to world zero.

Treating belts as “platforms that slide sideways one tile per second” works for very slow tutorials but breaks once players run, dash, or fight against the flow. Production platformers model belts as velocity fields applied during grounded movement resolution.

Surface velocity and friction coupling

Full coupling (factory default)

While grounded on a belt, the player’s world velocity along the belt axis becomes v_surface + v_input, where v_surface is the belt direction times speed and v_input is the player’s walk/run contribution along the same axis. Standing still on a belt still moves you at belt speed — that is the point. Perpendicular input (walking “across” the belt) uses normal ground friction without adding surface velocity to that axis, unless you deliberately design omnidirectional walkways.

Partial coupling (slippery or worn belts)

Scale surface contribution by a coupling factor 0 < k ≤ 1. At k = 0.4, the belt drags the player slowly; fighting the belt with full run speed can overcome it. Use partial coupling for ice-factory comedy, damaged machinery, or puzzles where players must sprint upstream.

Acceleration ramp on belt entry

Snapping instantly to full belt speed on first contact feels harsh. Ramp v_surface contribution over 80–150 ms or blend toward target surface velocity with a lerp. Pair with a short SFX (rollers engaging) so the acceleration reads as physical. Harbor Assembly added a 120 ms ramp and saw “sudden yank” complaints drop 51%.

Jumping on belts

On jump takeoff, add the full surface velocity vector to the player velocity before applying jump impulse — same rule as moving platform jump-off carry. Horizontal belt speed must persist through jump arcs until airborne friction or air control modifies it. Forgetting vertical belt components on angled conveyors is a common source of short jumps.

Belt edges, gaps and exit momentum

The trailing edge of a belt is where most feel bugs appear. When the player walks off the end, they must leave with v_player = v_walk_off + v_surface on the belt axis unless you intentionally design a dead stop (rare and usually feels bad). Harbor Assembly’s bug was zeroing velocity at edge exit because ground contact ended before surface velocity merged.

Edge detection pattern

On leave-ground events, check whether the previous frame’s ground contact was a belt collider. If yes, merge surface velocity into player velocity before clearing the grounded flag. Use a one-frame grace buffer so raycasts that flicker at tile seams do not strip carry.

Gaps between belts

Short gaps (1–2 tiles) between aligned belts test jump timing; long gaps need static floor or coyote time on the upstream belt edge. If gap width equals jump distance at belt speed plus run, document the intended solution (jump early vs run off vs wait for sync).

Side edges and fall zones

Belts without guard rails should use clear visual stripes and consistent fall damage or reset volumes. Lateral input off the side edge should not apply surface velocity once the player is airborne — only the velocity at moment of leave counts.

Reversible, switchable and vertical belts

Direction toggles

Switches, timers, or story flags flip v_surface sign. Telegraph direction changes 400–600 ms with arrows, audio, and roller animation reversal. Players standing on a belt when direction flips should ramp velocity through zero — instant sign flip while fully coupled throws riders off unless that is the puzzle.

Speed tiers

Slow (tutorial), medium (standard factory), fast (challenge) speeds should be color-coded or labeled in art. Expose speeds in tiles-per-second in level data so designers do not hand-tune per instance. Keep max belt speed below sprint plus surface unless the level is explicitly a chase sequence.

Vertical and angled conveyors

Vertical belts behave like escalators: apply surface velocity along the ramp normal projected onto the walk plane, or along the collider tangent. Angled belts used in mining or temple levels need consistent gravity projection — the player should not slide off uphill belts unless coupling is partial. For wall-mounted vertical belts (lifts without platforms), treat as climbing surfaces with locked lateral input or auto-centering on the belt volume.

Hazards, puzzles and object coupling

Carried objects and crates

Physics crates on belts need the same surface velocity field as the player. Kinematic crates (puzzle state machines) should advance position by belt_speed * dt each tick. Mixed stacks (player pushing crate on belt) resolve as: crate velocity = surface velocity + push impulse, capped by friction.

Timed gates and synchronized lasers

Factory puzzles often sync hazards to belt phase. Use a master timeline belt_phase shared across segments — same pattern as multi- elevator chains in moving platform design. Gate open windows should account for player effective speed (surface plus run), not belt speed alone.

Hazard belts

Spike rollers, crush rollers, and laser grids on moving surfaces must damage using the player’s world-space hurtbox, not belt-local coordinates. Telegraph hazardous segments with texture, particles, and 300 ms audio lead time.

Drop-through and one-way tiles on belts

Combining belts with drop-through platforms requires clearing surface velocity contribution when the player initiates drop-through — otherwise they drift horizontally while falling through a hole. Disable belt coupling for 100–200 ms after drop-through input.

Networked and deterministic belts

Belt speed and direction should be functions of simulation tick and level state, not replicated mesh animation speed. Authoritative sim computes v_surface(tick); clients apply the same field during grounded movement. For physics objects, integrate on the same tick as the player controller. Rollback netcode must save belt phase in savestates; mispredicting edge exit carry is a top desync source for factory co-op levels.

Visual roller UV scroll can interpolate for display; gameplay logic must never read scroll offset as position truth.

Harbor Assembly sorting floor refactor (case study)

Before: Belt motion implemented as per-frame position nudge on the player transform; no input-relative speed; edge exit zeroed velocity; crates used physics material friction only. Metrics: 44% floor completion, 31% of deaths on belt-to-belt jumps.

Changes:

Replaced position nudge with v_surface + v_input coupling in fixed tick.
120 ms ramp on belt entry; full carry on jump and walk-off edges.
Shared sorting_phase clock for belts and laser gates.
Kinematic crate mover using same surface field as player.
Direction flip telegraph: arrow lights + 500 ms beep before reversal.
Widened third belt by 0.2 tiles after near-miss telemetry cluster.

After: 79% completion, belt-jump deaths down 62%, unfair-mechanic reports down 68%. Level geometry tweak contributed ~6 points; velocity refactor contributed the rest.

Technique decision table

Goal	Prefer	Avoid
Continuous factory flow, timing gates	Surface velocity field + phase-synced hazards	Translating whole platform colliders for every belt segment
Teaching belt mechanics	Slow belt, guard rails, wide landing, no hazards	Fast reversible belt as first introduction
Vertical transport between floors	Moving platform elevators or escalator ramps with clear tangent	Vertical position nudge without jump carry rules
Fight-the-flow puzzle	Partial coupling (k < 1) + readable speed tier	Full coupling at sprint-breaking speeds
Physics crate sorting	Kinematic crate path or shared surface field	Raw friction on dynamic bodies without belt velocity term
Precision jump between belts	Edge exit carry + coyote on upstream belt	Zero momentum at belt end
Organic boat deck / swaying floor	Moving platform path with rotation	Infinite tangential belt on rocking mesh

Pitfalls

Position nudge instead of velocity coupling — fights character controllers and breaks jump arcs; use surface velocity fields.
Zero exit momentum at belt end — merge surface velocity on leave-ground when previous contact was a belt.
Instant full speed on contact — ramp coupling 80–150 ms unless puzzle demands snap.
Direction flip without telegraph — players blame controls; animate and audio-lead reversals.
Gate timing from belt speed only — account for run speed with and against flow.
UV scroll as gameplay truth — sim tick drives velocity; scroll is cosmetic.
Drop-through while coupled — disable belt field briefly after down+jump input.
Physics crates without belt term — crates slide wrong; apply same v_surface as player.
Omnidirectional walkway on one-way art — players read arrow direction; match collision axes to visuals.

Production checklist

Model belts as tangential surface velocity, not translating platform tiles (unless hybrid design).
Integrate surface coupling in the same fixed tick as grounded movement.
Compute effective speed as v_surface + v_input along belt axis at full coupling.
Ramp surface contribution 80–150 ms on belt entry.
Add full surface velocity to player velocity on jump takeoff.
Merge surface velocity on walk-off edge with one-frame grace at seams.
Expose direction, speed, and coupling factor per belt in level data.
Telegraph direction changes and hazardous segments 300–600 ms ahead.
Sync timed hazards to a shared phase clock across belt segments.
Apply identical surface field to kinematic crates and rideable objects.
Disable belt coupling briefly after drop-through input.
For netplay, derive v_surface from f(tick); include belt phase in rollback state.
Playtest at min and max run speeds with and against belt direction.
Log near-miss landings after belt jumps in telemetry.

Key takeaways

Conveyor belts are velocity fields, not sliding platforms — couple surface speed with input-relative movement.
Edge exit carry matters as much as on moving platforms — Harbor Assembly’s miss rate was mostly zero momentum at belt ends.
Ramp entry, telegraph reversals, and phase-sync hazards make factory floors readable instead of chaotic.
Crates and players must share the same surface model for sorting puzzles to feel fair.
Use moving platforms for path transport; use belts for continuous flow and timing puzzles.