docs: describe ordered setup placements
Document that setup is an ordered list of placements, each moving its parts to a path, in the format reference and the tabletop plan.
This commit is contained in:
+11
-6
@@ -268,19 +268,24 @@ surfaces:
|
||||
- board#harbor
|
||||
- hud#hand
|
||||
setup:
|
||||
/dock/0: harbor:boat#fleet
|
||||
/deck: harbor:card
|
||||
- path: /dock/0
|
||||
parts: harbor:boat#fleet
|
||||
- path: /deck
|
||||
parts: harbor:card
|
||||
```
|
||||
|
||||
`surfaces` lists the surfaces enabled at the start. A surface not listed is
|
||||
disabled and not rendered. When `surfaces` is omitted, all surfaces are
|
||||
enabled.
|
||||
|
||||
The value on a setup path can be either a string, or a string list.
|
||||
`setup` is an **ordered list of placements**. Each placement moves its `parts`
|
||||
to its `path`, and entries are applied in order — so a part listed in a later
|
||||
placement ends up on that placement's path. This makes a setup read like "deal
|
||||
the deck, then move these cards to the flop".
|
||||
|
||||
The string can either be a one part string, or a type without an id.
|
||||
|
||||
When id is omitted, it expands to all parts in that type during game state initialization.
|
||||
`parts` can be a single part id, a bare type without an id, or a list of
|
||||
either. A bare type expands to all parts of that type during game state
|
||||
initialization.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user