Let players fall over

sermuns commented

2026-10-20 23:40:44 +00:00

Owner

A player in this game cannot fall over. There is no pose for it, no way to be
knocked down, and nothing on the campus can push you over — a bus drives
through you and you step out of its way, because the vehicles have no mass
and the players have no body.

That is the cheapest thing a physics engine gives and the one that changes the
feel of the campus most: a body that can be knocked over, lie there, and get
back up.

What it buys

Getting hit. A vehicle that reaches you moves you. A football that
reaches you moves you. A player that reaches you at speed moves you.
Falling. Off the roof, off a cliff, off the top of the seesaw.
Being knocked down and recovering. The important half is the getting
back up: a ragdoll that stays down is a nuisance, a ragdoll that gets up
after a moment is a laugh.

How a ragdoll works here

A ragdoll is a set of rigid bodies joined by impulse joints: a pelvis, a
torso, a head, two upper arms, two lower arms, two thighs, two shins. Rapier
has everything for this — RevoluteJointBuilder for the shoulders and hips,
FixedJointBuilder for the neck and the spine, and a MultibodyJointSet for
the reduced-coordinate version if the joint chain wants to be exact.

The project already has most of the hard half. liuverse-world::avatar builds
the joints — planted feet, analytic knee IK — and liuverse-render::avatar
draws a body as PART_COUNT parts, each a FramePart of one mesh and a
transform. So the ragdoll does not need a new body model: it needs the
existing joints to be driven by the simulation rather than by the pose,
which means the renderer has to accept joint poses from a source other than
the player controller.

Where it fits

The ragdoll is a client-side affair, which is unusual for this project and
deliberately so. Players are client-authoritative and cheating is out of scope
for a co-op game, so the local client's ragdoll can be its own business. But
peers have to see it, which means the ragdoll's state travels on the wire:
the ClientPose grows a flag for it, and the ragdoll's own pose goes out
beside it. The wire contract is append-only — new fields go at the end of the
struct — so this is a field, not a reshuffle.

The local ragdoll physics runs in the client, which is where the physics
world for the player lives. That means the client has a physics world even
though the server owns the vehicles, which is one of the two worlds the
physics issue has to decide between.

Where it lives

The joint chain and the ragdoll simulation belong in liuverse-world::avatar
or beside it, next to the existing joint maths. The renderer needs no new
model — only a way to be handed joint transforms.

Related

#110 the physics engine itself is the blocker.
#111 the vehicles have to reach the player first, which is the vehicle work.
#112 the thrown objects have to reach the player too.
#113 the playground is the other place a body gets carried by something else.

A player in this game cannot fall over. There is no pose for it, no way to be knocked down, and nothing on the campus can push you over — a bus drives through you and you step out of its way, because the vehicles have no mass and the players have no body. That is the cheapest thing a physics engine gives and the one that changes the feel of the campus most: a body that can be knocked over, lie there, and get back up. **What it buys** - **Getting hit.** A vehicle that reaches you moves you. A football that reaches you moves you. A player that reaches you at speed moves you. - **Falling.** Off the roof, off a cliff, off the top of the seesaw. - **Being knocked down and recovering.** The important half is the getting back up: a ragdoll that stays down is a nuisance, a ragdoll that gets up after a moment is a laugh. **How a ragdoll works here** A ragdoll is a set of rigid bodies joined by impulse joints: a pelvis, a torso, a head, two upper arms, two lower arms, two thighs, two shins. Rapier has everything for this — `RevoluteJointBuilder` for the shoulders and hips, `FixedJointBuilder` for the neck and the spine, and a `MultibodyJointSet` for the reduced-coordinate version if the joint chain wants to be exact. The project already has most of the hard half. `liuverse-world::avatar` builds the joints — planted feet, analytic knee IK — and `liuverse-render::avatar` draws a body as `PART_COUNT` parts, each a `FramePart` of one mesh and a transform. So the ragdoll does not need a new body model: it needs the existing joints to be *driven by the simulation* rather than by the pose, which means the renderer has to accept joint poses from a source other than the player controller. **Where it fits** The ragdoll is a **client-side** affair, which is unusual for this project and deliberately so. Players are client-authoritative and cheating is out of scope for a co-op game, so the local client's ragdoll can be its own business. But peers have to *see* it, which means the ragdoll's state travels on the wire: the `ClientPose` grows a flag for it, and the ragdoll's own pose goes out beside it. The wire contract is append-only — new fields go at the end of the struct — so this is a field, not a reshuffle. The local ragdoll physics runs in the client, which is where the physics world for the player lives. That means the client has a physics world even though the server owns the vehicles, which is one of the two worlds the physics issue has to decide between. **Where it lives** The joint chain and the ragdoll simulation belong in `liuverse-world::avatar` or beside it, next to the existing joint maths. The renderer needs no new model — only a way to be handed joint transforms. **Related** - #110 the physics engine itself is the blocker. - #111 the vehicles have to reach the player first, which is the vehicle work. - #112 the thrown objects have to reach the player too. - #113 the playground is the other place a body gets carried by something else.

sermuns added this to the Play milestone

2026-10-20 23:40:44 +00:00

sermuns added the

medium

feature request

labels

2026-10-20 23:40:44 +00:00

sermuns referenced this issue

2026-10-20 23:41:18 +00:00

Add a physics engine (rapier3d) #110

sermuns referenced this issue

2026-10-20 23:41:19 +00:00

Give the vehicles real wheels #111

sermuns referenced this issue

2026-10-20 23:41:20 +00:00

Throw and roll real objects #112

sermuns referenced this issue

2026-10-20 23:41:20 +00:00

Make the playground toys real mechanisms #113

sermuns referenced this issue

2026-10-20 23:42:27 +00:00

Ride the zip line and play on the playground #71

sermuns added the

labels

2026-10-25 02:22:25 +00:00

sermuns added a new dependency

2026-10-25 02:47:16 +00:00

#113 Make the playground toys real mechanisms

sermuns added a new dependency

2026-10-25 02:47:16 +00:00

#110 Add a physics engine (rapier3d)

sermuns removed the

blocked

label

2026-10-25 02:48:09 +00:00

sermuns commented

2026-10-26 13:18:31 +00:00

Author

Owner

The comic mortality loop from #230 (65ebde9) already gives the knockdown half: a light vehicle or a slow hit trips the body, a hard fall or a heavy hit kills it, the avatar lies down, and it gets up at the last safe ground. What is still missing is the ragdoll this issue specifies — the body is a pose with a timer, not a joint chain, and #113 depends on that body. Leaving the issue open on #110 (physics engine).

The comic mortality loop from #230 (`65ebde9`) already gives the knockdown half: a light vehicle or a slow hit trips the body, a hard fall or a heavy hit kills it, the avatar lies down, and it gets up at the last safe ground. What is still missing is the ragdoll this issue specifies — the body is a pose with a timer, not a joint chain, and #113 depends on that body. Leaving the issue open on #110 (physics engine).

Rows
Columns

Let players fall over #114