Tutorial 21 of 4211 min read

Conditions

Make every item in a component collection pick its own design automatically with priority-ordered layout conditions, and show or hide single elements per item.

Conditions are how an item picks its own design. Instead of assigning a layout to each item by hand, you write a rule on the layout ("use me when Type is space") and every matching item adopts it automatically. Conditions only inspect the active component type's properties, so board data and card data never compete.

This is the feature that lets a 300-card set with six frame styles stay maintainable.

How resolution works

Open the Designs panel, the first tab in the Design editor's left rail. Each face (Front, Back) is listed separately, in up to three parts.

The Designs panel: two rule designs, the fallback and the Not used list

  • Rules. The layouts that carry a rule come first. Each card is checked against them top to bottom and uses the first one it matches.
  • The fallback. The one layout that catches every card no rule claimed. Its line reads Every other card.
  • Not used. Layouts that can never draw a card, each with the reason, such as a second layout with no rule.

So for the FRONT group in the example project:

  1. RPG Split: When Type equals "living" (also the fallback)
  2. Tarot Portrait: When Type equals "space"

A card with Type = living stops at 1. A space card fails 1 and matches 2. Anything else goes to the fallback, which here is RPG Split again. Co-op Art has no rule, so it sits under Not used: a layout without a rule can only draw cards as the fallback. To have it catch the leftovers, hover its row, open its ⋯ menu and choose Use for every other card.

Each row shows how many cards it draws. Reorder rules with the small up and down arrows on their rows (Check this rule earlier / later). Order is the logic; get it wrong and a broad rule higher up will swallow cards meant for a specific one below.

For the priority model on its own, see Layouts & Priority. This tutorial focuses on writing and testing the condition itself.

Writing a condition

  1. Open Design and find the layout in the Designs panel.
  2. Click Edit in the strip under its name, such as When Type equals living. To remove the rule, use Clear in the popover. On a layout under Not used, click Add rule in its amber strip (or Make default to make it the fallback instead), or choose Give it a rule… from its ⋯ menu. The rule popover opens beside the panel.
  3. Fill in the row under "Use “” for cards where", which reads as a sentence: [property] [operator] [value].
  4. Click Apply.

The rule popover for Tarot Portrait, with its card count and thumbnails

While you edit, the popover counts the rule against your real cards: "5 of 19 cards use this layout", with a bar and thumbnails of the first few cards it catches. If some matches are taken by a rule higher in the list, a line under the thumbnails says how many.

A first useful condition

Try this small example before building a larger ruleset:

  1. Make Type a Select property with options such as living and space, then give a few cards each value.
  2. Create or choose two front layouts. Make one the fallback (Use for every other card in its ⋯ menu) and leave it without a rule.
  3. On the other layout, set the row to Type is living.
  4. Select a living card in the spreadsheet. Its preview should use the conditioned layout. A space card should fall through to the fallback.

If both layouts look the same, temporarily give them visibly different backgrounds or names. That makes resolution mistakes much easier to spot while you are learning the system.

Operators

The operator list for a Select property

The condition row uses short operator labels so it reads as a sentence. Elsewhere (the Designs panel, the Why this layout? dialog, the visibility panel) the same operators are spelled out.

In the row Spelled out Matches when
is equals The property is exactly this value
is not does not equal The property is anything but this value
is any of is any of The property is one of several values
contains contains The text holds this value anywhere, ignoring case
is empty is empty No value has been entered
is not empty is not empty Any value has been entered
>, ≥, <, ≤ greater / less than (or equal) Numeric comparisons

The list you see depends on the property's type: Number properties offer the comparisons, is any of appears on Select properties, and contains on Text properties.

is any of is the one people miss. Rather than three near-identical layouts for fire, water and air, write one layout with Element is any of fire, water, air.

contains is for a free-text line that holds more than one word. A type line such as Tactic / Instant matches Type line contains tactic. Some template packs use it to send each sample card to the design it was written for, and they install with those rules already on their layouts.

Multiple conditions

Click Add another condition to stack rules; an and divider separates the rows. Every row must match. There is no OR at this level.

To express OR, either use is any of on one property, or split it into two layouts at adjacent priorities.

Don't put conditions on the fallback

The fallback row in Designs has no Edit: a rule there would filter nothing. When the design holding the fallback also carries a rule, it shows up as a rule row too, and opening that rule shows a warning:

This is the front fallback (★). It catches every card that matches no other rule, so this rule won't hide it from any card. Put the rule on another front layout instead.

The fallback is the catch-all. A condition on it can't keep any card away: cards that fail it still land there, because nothing else caught them. All the rule can still do is win matching cards at its place among the rules, ahead of the rules below it. You can see it in the example above, where the fallback RPG Split also carries a rule and shows up twice in Designs, as rule 1 and as the fallback (Every other card, and rule 1). The cleaner setup is to put specific rules on specific layouts and leave the fallback without one.

Pointing cards at a design from the sheet

Sometimes you know which cards should use a design but not the rule. In the spreadsheet, right-click a row and open Use this design (or Use this design for 6 cards when the row is part of a checkbox selection), then pick the design. With rows ticked, the same submenu is in the selection bar's ⋯ menu as Use this design for N cards.

ShuffleKit writes the rule for you. If an existing column already describes exactly those cards, it reuses it (Template is Station) and changes no card data. If none does, it adds a Design column, fills in the design's name on those cards, and gives the layout a rule that reads it. A toast confirms, for example 6 cards now use "Tarot Portrait", explains what changed, and offers Undo. This replaces any rule the design had before.

If a rule checked earlier already claims those cards, the design is moved to just above that rule in Designs so the cards really switch, and the toast says so (It now comes before "…" in the list, whose rule claimed them first.). If some cards still show another design afterwards, the toast is a warning that counts them, such as 4 of 6 cards now use "Tarot Portrait", and tells you to move the design up in Designs. Undo puts back the order, the rule and any values it filled in.

If the design you picked was the fallback, a design with no rule takes over as the fallback, so the rest of your cards don't silently keep the design you just narrowed. The toast says which one, or says the rest still fall back to the design you picked when no other design is free to take over.

The submenu only appears once the collection has at least two front designs. The design is ticked only when every card in scope already uses it, so with a mixed selection nothing is ticked. It lists fronts only, and people with view-only access don't see it. Selected rows of another component type are left alone, and the toast counts them.

Seeing conditions resolve

Once there's more than one layout, the Card Details panel tells you the outcome for whichever card is selected, under the preview:

This card uses layout RPG Split, because Type equals "living".

Select a different card and it changes:

A 'space' card resolving to the Tarot Portrait layout

Same project, same rules, different Type, and the preview switches to Tarot Portrait.

"Why this layout?"

When the outcome surprises you, click Why this layout? at the end of that line (it reads Why this card back? when the back is showing):

The Why these layouts? dialog with Front and Back sections

The dialog is titled Why these layouts? when the project has back layouts, and shows FRONT and BACK separately:

  • The layout In use, and the clauses it matched, each with a tick.
  • Why not the others: every layout that didn't win, with the reason:
    • "Needs Type to be "space", but this card's Type is living."
    • "Also matches, but RPG Split ranks higher.", with a Use this button that moves the layout above the winner.
    • "No condition: applies only as the default."
  • An Edit link next to each, to jump straight to that layout.

This is the debugger. Whenever a card renders with the wrong frame, start here rather than guessing.

Per-element conditions

Layout conditions choose the whole design. A visibility rule hides or shows a single element per card.

Show on some cards only, expanded in the Connect data panel

  1. Select the element on the canvas.
  2. Click its pill in the floating toolbar to open Connect data.
  3. Expand Show on some cards only at the bottom.
  4. Choose Show when or Hide when, then pick a property, operator and value.

Show or hide this element per item based on a property value. With no rule it always shows.

The same rule is in a layer's menu in the Layers panel, as Visibility rule….

Typical uses: a "legendary" foil bar that only appears when Legendary is true; a flavour-text box that hides when the field is empty (Flavour is empty → Hide).

For the complete visibility workflow, see Element Visibility.

This keeps your layout count down. If two designs differ by one badge, that's one layout with a conditional badge, not two layouts to maintain in parallel.

Practical guidance

  • Use Select properties for anything conditions read. Free text invites typos, and a typo silently drops a card to the fallback.
  • Order specific → general. Narrow rules high, broad rules low.
  • Keep one fallback per face, with no rule. A front always has one. A back without one leaves cards that match no back rule with no back at all.
  • Check the Not used section. A layout listed there draws nothing, whatever you design on it.
  • Test with Preview mode. Step through all cards after changing priorities: that's where a swallowed rule shows itself.

Ready to build your card game?