Hose and water¶
The design intent behind the hose. For what the code actually does today, see Hose system.
The hose is one object, not a weapon slot¶
A backpack, a length of simulated hose, and a nozzle in the hand. It is never holstered and never swapped out. Everything the player does to the world goes through the nozzle, so the design question for any new mechanism is always "what does it do when you point water at it".
The hose itself is physical — a Verlet chain that hangs, drags on the ground, and spools in and out as the distance from backpack to hand changes. It is not decoration: it is the visual feedback that tells you where your pressure is coming from.
Recoil is the movement system¶
Water leaves the nozzle, the boy goes the other way. Pointing down and behind you is a jump; holding it is a hover. The implemented recoil already has the shape this needs — upward push is multiplied hard (player gravity is 75, so the recoil has to be generous to lift at all), drag is overridden while spraying so the controller's idle damping does not eat the push, and the controller's speed cap is broken at high pressure so the hose can throw you faster than you can run.
Consequences the design leans on:
- Aim is movement. There is no separate traversal input. Learning to climb is learning to aim behind yourself while looking where you are going, which is exactly what first person is good at.
- You cannot hover forever. Hovering is the most expensive thing you can do with the tank, by construction.
- Heavy fluids kick harder. Recoil is scaled per fluid, so a late-game tap changes how the boy moves, not just what the water does on impact.
The water gauge¶
A gauge in the corner reading tank level, with the liquid sloshing against the player's sideways acceleration. It is the only HUD element that matters and it is deliberately physical rather than a bar — the slosh is how you feel the difference between a heavy fluid and a light one before you read a number.
Behaviour: the drawn level lags the real one slightly, the surface tips with lateral acceleration and springs back with overshoot, drawing adds agitation to the wave, and below a low threshold the glass flashes. All colours come from the current fluid, so a tap that hands you something else retints the gauge with no UI work.
Known issue
The gauge component exists (FluidMeterUI) and is not in any scene, and the tank it reads
is not in any scene either. Wiring and fixing the gauge is the first item in
wave 1.
Pressure economy¶
| Phase | What happens |
|---|---|
| Draw | Tank drains at the fluid's rate, scaled by throttle. Throttle ramps rather than snapping, so taps of the trigger cost less than they look like they should. |
| Dry | The jet cuts out. With lockout on, it stays out. |
| Delay | Nothing refills for a beat after you release. This is what stops feathering the trigger from being free. |
| Refill | Climbs back at the fluid's refill rate. |
| Restart | After running dry, the tank must recover past a threshold before it will fire again — so running out mid-climb is a real fall, not a stutter. |
Inlets, buttons and platforms¶
The mountain's mechanisms are water-driven, which is consistent with the setting: the city runs on pumps, so pointing a hose at a fitting is the normal way to make something move.
- Inlets — a fitting that accepts a jet. Hold water on it to drive a moving platform along
its track; stop and it stops or returns. The Hello Mario Framework
MoverandMoverButtonutilities already implement moving platforms and button-driven movers and are the intended substrate. - Buttons — momentary. Pressure on, active; pressure off, inactive after a grace period. Forces the player to solve "how do I be in two places at once", which is what a hose with a long reach is for.
- Taps and pumps — the refill points. A tap is also the fiction's progression gate: a pump master granting you a tap is what opens the next zone.
All of this hangs off one interface: anything that wants to react to being hosed implements
IWaterTarget and receives the contact point, the surface normal, the water's travel direction
and the current pressure. Nothing needs to know about the hose.
Draft
Inlets, buttons and water-driven platforms are not implemented. They are wave 2.
Inverse kinematics¶
The boy holds the hose properly, in both perspectives, because there is no viewmodel to fake it with — first person shows the same skinned character everyone else sees.
- Third person. The arm solve runs at reduced weight, so the nozzle tracks aim but the character animation still reads. He is carrying a hose, visibly, and the hose hangs and drags behind him.
- First person. The solve runs at full weight. The hose is visible in your hands, and the nozzle points where the reticle is. Not approximately — the same aim vector drives the arm, the jet trace and the crosshair, so what you see the character holding is what is about to happen.
- The head is removed, not the body. The head bone is collapsed so the camera is not inside the face, and everything else stays on screen. Look down and there is a real body there.
Polish still owed: hand alignment on the nozzle grip, the elbow hint pose in first person, and the transition weight blend when the camera changes mode. See wave 1.