feat(deck-slice): Fruit-Ninja-style slice game driven by deck-pose (phase 3) #908

Closed

lytedev wants to merge 1 commit from deck-slice into deck-pose-events

pull from: deck-slice

merge into: lytedev:deck-pose-events

lytedev:main

lytedev:propose/fallback-fail-fast

lytedev:propose/detect-agent-death

lytedev:propose/local-fallback

lytedev:propose/local-inference

lytedev:propose/bc250-image

lytedev:pinephone-niri

lytedev:propose/herdr-keybinds

lytedev:propose/spoof-reject-cleanups

lytedev:propose/finance-pipeline

lytedev:propose/jj-ripe

lytedev:propose/reminder-history

lytedev:steamframe-plan

lytedev:deck-pose-wip

lytedev:pinephone-buildable

lytedev:aerc-open-html

lytedev:local-auth-unification

lytedev:esphome-music-panel

lytedev:wifi-system-profile

lytedev:gauge-history

lytedev:validate-gate-fix2

lytedev:validate-slot-no-hugepages

lytedev:pinephone-reenable

lytedev:cyberdeck-research

lytedev:git-anon-ratelimit

lytedev:headscale-basedomain

lytedev:ssd-fast-tier

lytedev:hold-impermanence-flip

lytedev:zen-browser

lytedev:initrd-remote-unlock

lytedev:beefcake-rpool-backup

lytedev:sec-sso-plan

lytedev:sec-mail

lytedev:flab-lid-wake

lytedev:hearth-k8s

lytedev:zulip

lytedev:router-guest-vlan

lytedev:headscale-extra-records

lytedev:beefcake-advertise-lan

lytedev:push-qrvuuqmxtznv

lytedev:voxtype-per-host-model

lytedev:cleanup

lytedev:push-kanidm-opt-in

lytedev:push-voxtype-flake-fix

lytedev:push-uvqqknxvqlvy

lytedev:push-qrqsxkmlrevert

lytedev:fix-kanidm-uid-attr-map

lytedev:nix-on-droid

lytedev:self-hosted-dns

lytedev:fix-runner-tmpfs-revert

lytedev:beefcake-email

lytedev:beefcake-immich

lytedev:firefox-nightly-devedition

lytedev:fix-bun-baseline

lytedev:flab-stuff

lytedev:printer-sftp

lytedev:dragon-vr-monado

lytedev:clever-vr-game-clamshell-mode-detection

lytedev:wireguard-mesh

lytedev:rescue-beefcake-unpushed-nix

Conversation 1 Commits 1 Files changed 13 +947 -7

lytedev commented 2026-08-03 10:06:10 -05:00

Owner

Copy link

The first real consumer of the pose daemon's socket — and as much a test that the protocol is usable as it is a game.

Stacked on #907, which is stacked on #906. Base is deck-pose-events. Merge order: #906 → #907 → this.

Packaged as pkgs.deck-slice, not enabled on any host, nothing deployed.

What it is

Targets are flung up from the bottom; you slice them by swiping a wrist through them. Up to six players, each with their own blade colour and score. Bombs cost 10 points and are distinguished by shape as well as colour, so a colour-blind player is not the one who finds out by losing. Six GDScript files, no binary assets — it is all reviewable in the diff.

No daemon changes were needed

Godot 4.6 ships StreamPeerUDS, so the game reads the Unix socket directly. I checked before assuming: I had been ready to add a TCP transport to #907 for this, and it turned out to be unnecessary. Verified against the actual nixpkgs binary (ClassDB.class_exists("StreamPeerUDS") == true on 4.6.3).

One gotcha that cost real time and now carries a comment: FileAccess.file_exists returns false for a Unix socket — it is not a regular file — so the "is the daemon up yet" check goes through DirAccess instead. Without that the game silently never connects.

Two decisions that shape how it feels

Slicing is driven by the pose stream, not by swipe events. A swipe event is one discrete notification per motion — it has a refractory period by design. But one swing can pass through three targets and the player expects all three to fall. So every blade's swept segment is tested against every target every frame. Swipe events drive only the "you swung" feedback, which should fire even on a miss.

Hits test the segment the hand travelled, not where it is now. At 60fps a fast swipe moves a hand hundreds of pixels between frames; a point-in-circle test tunnels straight through and the player would swear they hit it.

The view is mirrored. Not cosmetic — without it the game is unplayable in a way people struggle to articulate.

Defensive about the daemon

Polls for the socket, connects whenever it appears, survives a daemon restart, tolerates partial lines and malformed JSON, and caps its read buffer. While disconnected it says so on screen and prints the command to start the daemon — a pose game with no daemon looks identical to one that cannot see you, and "nothing is moving" is not a diagnostic.

Packaging

Project directory plus a wrapper running godot4 --path, not an exported binary: export would pull in godotPackages.export-templates-bin (hundreds of MB of prebuilt engine binaries) to produce a .pck of the same GDScript already in the tree.

The build runs godot4 --headless --import twice, and that is load-bearing rather than cargo-culted — Godot writes its import cache into .godot/ inside the project, and a /nix/store path is read-only at runtime. I verified that a read-only project fails without it. Two passes because the first registers the scripts and the second resolves the scene's references to them.

Verified

nix build .#deck-slice succeeds, and the packaged binary was run end to end against a synthetic pose stream (a wrist swept across the frame at a known speed, emitting the real NDJSON):

deck-slice: connected to /tmp/claude-1000/fake-pose2.sock
deck-slice: P1 sliced target, score 1
...
deck-slice: P1 sliced BOMB, score -6
WARNING: pose daemon disconnected: daemon closed the connection

So: connects, parses, tracks blades, slices, applies the bomb penalty, and handles the daemon vanishing.

Untested — please read this part

• No real camera has driven it. Daniel's browser held /dev/video0 for the whole session and I was not going to kill it. The daemon side is validated live (#906/#907); the join between daemon and game has only been exercised against the synthetic stream.
• Nothing has run on the steamdeck, under gamescope or otherwise.
• Only one player. The multi-player paths are written but two people have never stood in front of it.
• Cut threshold and spawn rate are guesses, tuned against a synthetic sweep rather than a person. Expect to adjust them the first time anyone plays.

Gamescope

Not fought, as instructed — but written down rather than waved at. lib/doc/deck-slice.md has a section listing what Game Mode will actually need: the daemon as a user service started before the session, camera access inside that session, whether a Steam-launched game shares $XDG_RUNTIME_DIR with a user service, adding it to Steam as a non-Steam game, and how the daemon and game split four cores.

The first real consumer of the pose daemon's socket — and as much a test that the protocol is usable as it is a game. **Stacked on #907, which is stacked on #906.** Base is `deck-pose-events`. Merge order: #906 → #907 → this. Packaged as `pkgs.deck-slice`, **not enabled on any host**, nothing deployed. ## What it is Targets are flung up from the bottom; you slice them by swiping a wrist through them. Up to six players, each with their own blade colour and score. Bombs cost 10 points and are distinguished by shape as well as colour, so a colour-blind player is not the one who finds out by losing. Six GDScript files, no binary assets — it is all reviewable in the diff. ## No daemon changes were needed Godot 4.6 ships `StreamPeerUDS`, so the game reads the Unix socket directly. I checked before assuming: I had been ready to add a TCP transport to #907 for this, and it turned out to be unnecessary. Verified against the actual nixpkgs binary (`ClassDB.class_exists("StreamPeerUDS") == true` on 4.6.3). One gotcha that cost real time and now carries a comment: **`FileAccess.file_exists` returns `false` for a Unix socket** — it is not a regular file — so the "is the daemon up yet" check goes through `DirAccess` instead. Without that the game silently never connects. ## Two decisions that shape how it feels **Slicing is driven by the pose stream, not by `swipe` events.** A swipe event is one discrete notification per motion — it has a refractory period by design. But one swing can pass through three targets and the player expects all three to fall. So every blade's swept segment is tested against every target every frame. Swipe events drive only the "you swung" feedback, which should fire even on a miss. **Hits test the segment the hand travelled, not where it is now.** At 60fps a fast swipe moves a hand hundreds of pixels between frames; a point-in-circle test tunnels straight through and the player would swear they hit it. The view is mirrored. Not cosmetic — without it the game is unplayable in a way people struggle to articulate. ## Defensive about the daemon Polls for the socket, connects whenever it appears, survives a daemon restart, tolerates partial lines and malformed JSON, and caps its read buffer. While disconnected it says so on screen **and prints the command to start the daemon** — a pose game with no daemon looks identical to one that cannot see you, and "nothing is moving" is not a diagnostic. ## Packaging Project directory plus a wrapper running `godot4 --path`, not an exported binary: export would pull in `godotPackages.export-templates-bin` (hundreds of MB of prebuilt engine binaries) to produce a `.pck` of the same GDScript already in the tree. The build runs `godot4 --headless --import` twice, and that is load-bearing rather than cargo-culted — Godot writes its import cache into `.godot/` inside the project, and a `/nix/store` path is read-only at runtime. I verified that a read-only project **fails** without it. Two passes because the first registers the scripts and the second resolves the scene's references to them. ## Verified `nix build .#deck-slice` succeeds, and the **packaged** binary was run end to end against a synthetic pose stream (a wrist swept across the frame at a known speed, emitting the real NDJSON): ``` deck-slice: connected to /tmp/claude-1000/fake-pose2.sock deck-slice: P1 sliced target, score 1 ... deck-slice: P1 sliced BOMB, score -6 WARNING: pose daemon disconnected: daemon closed the connection ``` So: connects, parses, tracks blades, slices, applies the bomb penalty, and handles the daemon vanishing. ## Untested — please read this part - **No real camera has driven it.** Daniel's browser held `/dev/video0` for the whole session and I was not going to kill it. The daemon side is validated live (#906/#907); the *join* between daemon and game has only been exercised against the synthetic stream. - **Nothing has run on the steamdeck**, under gamescope or otherwise. - **Only one player.** The multi-player paths are written but two people have never stood in front of it. - **Cut threshold and spawn rate are guesses**, tuned against a synthetic sweep rather than a person. Expect to adjust them the first time anyone plays. ## Gamescope Not fought, as instructed — but written down rather than waved at. `lib/doc/deck-slice.md` has a section listing what Game Mode will actually need: the daemon as a user service started before the session, camera access inside that session, whether a Steam-launched game shares `$XDG_RUNTIME_DIR` with a user service, adding it to Steam as a non-Steam game, and how the daemon and game split four cores.

lytedev added 1 commit 2026-08-03 10:06:10 -05:00

feat(deck-slice): Fruit-Ninja-style slice game driven by deck-pose ... 76b274b40f

The first real consumer of the pose daemon`s socket, and as much a test that
the protocol is usable as it is a game. Targets are flung up; you slice them by
swiping a wrist through them. Up to six players, each with their own blade
colour and score.

Godot 4.6 has StreamPeerUDS, so the game reads the Unix socket directly. No
bridge process, and no reason for the daemon to grow a TCP transport just to be
playable. (Gotcha worth the comment it carries: FileAccess.file_exists returns
FALSE for a socket — it is not a regular file — so the "is the daemon up yet"
check goes through DirAccess instead.)

Two decisions shape how it feels:

* Slicing is driven by the POSE STREAM, not by swipe events. A swipe event is
  one discrete notification per motion by design, but one swing can pass
  through three targets and the player expects all three to fall. So every
  blade`s swept segment is tested against every target every frame; swipe
  events only drive "you swung" feedback, which should fire even on a miss.

* Hits test the SEGMENT the hand travelled, not where it is now. At 60fps a
  fast swipe moves a hand hundreds of pixels between frames, so a
  point-in-circle test tunnels straight through and the player would swear they
  hit it.

The view is mirrored, which is not cosmetic: without it the game is unplayable
in a way people struggle to articulate.

The game is defensive about the daemon`s lifetime — it polls for the socket,
connects whenever it appears, survives a restart, and says on screen that it is
waiting and how to start the daemon. A pose game with no daemon looks identical
to one that cannot see you, and "nothing is moving" is not a diagnostic.

Packaged as the project directory plus a wrapper rather than an exported
binary: export would pull in hundreds of MB of engine templates to produce a
.pck of the same six GDScript files. The build does run --import twice, and
that is load-bearing — Godot writes its cache into .godot/ inside the project,
which a store path cannot allow at runtime.

Validated end to end against a synthetic pose stream (a wrist swept at a known
speed): connects, tracks blades, slices, applies the bomb penalty, and
reconnects when the daemon exits. Not driven by a real camera yet — the
development machine`s camera was in use — and never run on the steamdeck.
lib/doc/deck-slice.md records what Game Mode will need.

lytedev referenced this pull request 2026-08-03 10:46:02 -05:00

feat(deck-slice): spatial framing, self-view and edge cues #909

lytedev force-pushed deck-slice from 76b274b40f to 5b0b8ff52b 2026-08-03 10:57:44 -05:00 Compare

lytedev referenced this pull request 2026-08-03 10:58:30 -05:00

fix(deck-slice): make the cut threshold body-relative and forgiving #910

lytedev force-pushed deck-slice from 5b0b8ff52b to 8232c55017 2026-08-03 11:01:57 -05:00 Compare

lytedev referenced this pull request 2026-08-03 11:29:34 -05:00

WIP: markerless full-body pose input (deck-pose daemon + deck-slice game) #915

lytedev commented 2026-08-03 11:30:03 -05:00

Author

Owner

Copy link

Superseded by #915, which consolidates the whole markerless-pose-input program into a single WIP branch against main. Every commit from this PR is preserved there — nothing was squashed, so the root-cause writeups in the commit messages are intact. Closing here; review happens on #915.

Superseded by #915, which consolidates the whole markerless-pose-input program into a single WIP branch against `main`. Every commit from this PR is preserved there — nothing was squashed, so the root-cause writeups in the commit messages are intact. Closing here; review happens on #915.

lytedev closed this pull request 2026-08-03 11:30:08 -05:00

All checks were successful

Hide all checks

/ check-format (push) Successful in 11s

Details

/ build (push) Successful in 6m30s

Details

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

bug

Something is wrong

  

enhancement

New feature

  

question

Awaiting information

  

scary

Potentially problematic change

  

upstream

Awaiting upstream changes

No labels

bug

enhancement

question

scary

upstream

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lytedev/nix!908

No description provided.