PokerSeating

The table geometry and deal plan for a poker variant — where every card goes, in what order, derived from three counts.

What it does

PokerSeating turns a variant's three counts — cardsPerPlayer, riverSize, npcCount — into the static plan a dealing system reads once. getLayout() (cached on the component) returns four things:

• seats come from computeNpcSeats(npcCount): NPCs sit along a half-ellipse across the top, left to right. Side seats fan their cards along Z, top seats along X, and each seat carries a baseRotY so its cards point at the player behind them.
• allCards is one flat array of per-card transforms — the player hand first, then the river (if riverSize > 0), then each NPC hand.
• groups is a Map from group id (player, river, npc0, npc1, …) to a { start, count } slice into allCards. A group never owns its own array; it indexes the flat one.
• dealOrder is the index sequence to deal in: round-robin across the seats with the player first, then the river dealt last.

resolveFlipIndices(groups, groupId, indices?) maps a group plus optional within-group positions back to global allCards indices — that's how a reveal phase flips "the first three river cards" without knowing where the river sits in the flat array.

It has no per-frame System. Build the layout from the seating entity with the collectSeatingLayout(world) query, or read component.getLayout() directly. The per-card transform factories (createDealtCardData, createCardGroup) are inlined, so PokerSeating depends on no card-fan mechanic.

Use it in a scene

bjs download scene PokerSeating

{
  "Table": {
    "components": {
      "PokerSeating": {
        "cardsPerPlayer": 2,
        "riverSize": 5,
        "npcCount": 3
      }
    }
  }
}

Props

• cardsPerPlayer (number, default 2) — cards dealt to the player and to each NPC. 2 for Hold'em, 4 for Omaha, 5/7 for stud.
• riverSize (number, default 5) — community/river cards. 5 for Hold'em/Omaha, 0 for stud and draw (no river group is created).
• npcCount (number, default 3) — NPC opponents seated across the top of the table.

Events

None. PokerSeating is static layout data — it neither emits nor listens. A dealing/animation system reads the plan and drives the cards.

Dependencies

None. The layout math and the per-card transform factories are self-contained. In a playable scene PokerSeating pairs with whatever owns the cards (a card-fan / deal system) and a MeshPrimitive felt to deal onto, but it requires no sibling component to compute its plan.

Notes

• One table per scene: collectSeatingLayout returns the first active PokerSeating entity's layout.
• getLayout() is cached on the component; call invalidateLayout() after changing cardsPerPlayer / riverSize / npcCount so the next read rebuilds.
• Counts drive the plan deterministically: the same variant always yields the same seat positions, group ranges, and deal order. Only per-card jitter (origin scatter, small rotation) uses Math.random, and that never changes a count or a range.
• A single NPC sits at the top center; with npcCount of 0 there are no NPC groups and the deal order is just the player hand (then the river, if any).
• riverSize: 0 omits the river group entirely — stud and draw layouts have only player and npcN groups.