Landing rules

A landing rule answers a question faceOnEnter cannot: how does the second thing dropped here differ from the first?

A zone's faceOnEnter turns every arrival the same way up. A landing rule (dropPolicy) instead holds an ordered list per component kind — the first card to land takes row 1, the second takes row 2, and so on. Each row can set the face, the orientation, and where in the space the piece parks.

The case it was built for: a settlement on a space, then a city dropped on the same space that sits tucked at 90° so both still read. Or a tableau where the second card slides under the first with only its scoring strip showing.

How to edit in the Studio

Open your game → Layout tab → select a zone → the Zone inspector → Landing rules. Pick which component kinds the rule covers, then add a row per landing. On a board you can also override a single space: click that cell and use Override this space's landing rules.

A landing rule can also read differently under a setup variant — the second card into a slot lands sideways in the advanced game only. See zones that change with the variant.

The three rules that make it predictable

1. Each kind counts separately. Cards count their own landings; tokens count theirs. Dropping two cards on a space does not advance the token list.

2. Each space counts separately. On a board, every cell — and every node and edge — runs its own count. That is what makes one rule on the zone give you settlement-then-city on every space at once, with nothing authored per cell. A space you have not used yet always starts at row 1.

An open play area is the exception, because it has no spaces: components sit wherever they were put, not in anything you named. So an open play area counts for the whole zone — the second card to arrive anywhere in it takes row 2, and depth measures against everything of that kind lying in it, wherever that is. Anything else would mean the count never left row 1, since no two things in an open play area are ever in the same spot.

3. The last row repeats. Run past the end of the list and the final row applies to everything after it. A one-row list therefore means "every landing looks like this". A landing rule never refuses a drop — it is not a capacity limit, and like capacity nothing about it is enforced. taybl models a table, not a rules engine; players still put whatever they like wherever they like.

What a row can set

Leave a field blank and it means "leave this alone" — so an empty first row plus a second row that rotates reads as "the first one lands however it would anyway; the second tucks sideways".

In an open play area, a row that sets no offset and no rotation lands its card in exactly the same spot as the one before it — same size, squarely on top — so the rule looks like it did nothing even though it applied. Give the later rows a Nudge (and a depth, if you want them the other way up the pile) and the stack fans out where you can see it.

anchor moves the piece's centre onto the named point, so a piece anchored bottom half-overhangs the space. That overhang is the tuck; use offset to pull it back if you want less of it.

offset nudges — it does not reposition. A fan works out where each card sits from how many have to fit, and your offset moves the card from there. That is what makes a tuck sayable in a play area: a small offset on the second card leaves the first one still showing.

Why anchor alone is limited to boards

anchor names one of nine positions inside a cell box, and a fan or a stack has no cell for it to point at. Off-grid, offset says the same thing in table units and says it precisely, so anchor is rejected there rather than quietly ignored. Everything else works on every arrangement.

Which one ends up on top

By default each arrival lands on top of what is already in that space. A row’s depth changes that: it says how many things of the same kind end up above it. Counting from the top, 0 is on top, 1 is one below the top, and so on.

So these four rows build the pile bottom-to-top as 2, 4, 3, 1:

Depth is decided once, when the thing lands — exactly like face and rotation. It never freezes the order: a player can still bring a card to the front afterwards and it stays there.

Depth counts only things of the same kind in the same space, so a piece never ends up beneath the tile it is standing on.

Landing on a particular side

If a component declares several states, a row can say which one it lands showing — a checker that arrives crowned, a card that arrives exhausted. The control appears in the inspector only when a component that could land there actually has states.

Overriding a single space

A cell can carry its own dropPolicy, which replaces the zone's for that cell rather than merging with it — a cell that lists only card does not inherit the zone's piece list. "This space is different" is easier to read than a partial difference.

Only a space you can name in the board editor can carry an override. Cells on a plain width × height grid, and tiles on an open lattice, are addressed by position rather than being listed individually — they always take the zone's rule, which already gives each of them its own count.

Setup placements use the same list

A setup placement with a count of 3 into one space walks the same rows: copy 1 gets row 1, copy 2 gets row 2, copy 3 gets row 3. You do not author a separate list for setup — what a player sees when they drop three pieces by hand is what the game starts with.

If the placement sets Face up or Rotation itself, that wins over the row. Leave those blank to let the landing rule decide.

A placement spread across a board (no fixed space) puts one copy on each cell. On an empty board that makes every copy that cell's first landing, so they all take row 1. Onto a board that already holds one of that kind per cell, each copy is that cell's second landing and takes row 2 — which is how a row of face-up region cards gets a hidden card tucked under every one of them, from two placements and no per-cell authoring.

Seeing a tuck in a pile

A stack zone normally draws itself as a deck — the top card and a count — because that is what a deck looks like. A landing rule changes what the zone is: the whole point of tucking card 2 is that card 1 still shows. So once a landing rule has positioned the cards, the pile spreads. A deck stacks every card on one spot, and the rule nudges from there — still additive, as everywhere else, just additive to nothing. A pile no rule has an opinion about is drawn exactly as before.

What overrides what

When a player drags something in:

1. A flip or rotate the player staged mid-drag (they turned it over in hand)
2. The row the player picked with Tab (see below)
3. The row the ordinal works out
4. The zone's faceOnEnter

During setup:

1. The placement's own Face up / Rotation
2. The landing row
3. The zone's faceOnEnter

A die has no face to turn, so a row's faceUp never applies to one.

Players can pick the row

The ordinal is a good default, not a verdict. Mid-drag a player presses Tab to walk the rows of whatever space is under the cursor — the cycle gains one stop per row, ahead of the tuck and attach modes — and the drop takes the row they stopped on instead of the one the count would have given. So a settlement can be upgraded to a city on an empty node, or a card laid face up on a space that already holds two.

Give a row a Name and that is what the drag ghost calls it (City); leave it blank and the player sees its position (Drop 2). Name the rows whenever a player would plausibly want to choose between them.

The override is drag-only. Something dealt, drawn, collected, pulled from a bag, placed by setup, or moved by clicking rather than dragging always takes the row the ordinal works out — there is no player in the air on those paths to have pressed anything. And a forced row is still clamped to the rows you authored: a player can pick a different rule of yours, never invent one.

Dealing into an open play area

Landing rules are how you spread a deal out. A setup deal into an open play area puts its whole batch on one point — it is one step drawing off a pile, with no per-card position — and then walks your rows for it: the first card takes row 1, the second row 2, and their Nudge offsets fan the pile apart.

Several deal steps into the same play area work the same way. Each step lands on a spot of its own so the batches stay apart, and the rows keep counting across them: three separate one-card deals give you rows 1, 2 and 3, not row 1 three times.

This is worth saying because it did not used to work. A dealt card had no point at all, so it sat in the corner tray marked still needs placing and your rules, though computed, drew nothing. If you tried this before and the arrows appeared to do nothing, that is what you were seeing.

Related

• Zones — where dropPolicy lives
• Grids & boards — cells, nodes and edges are all spaces
• Setup placements — counts that walk the list
• Zone visibility — faceOnEnter and who sees what
• Zones that change with the variant — a different dropPolicy per variation