Describe contents and storage

Use the inventory from Measure the box and contents to describe what the insert must hold. Save the project as game.bgi.yaml. The examples below use a 220 × 160 × 45 mm box, one 60-card deck, and one token compartment. From measurements to cut files gives the overall picture.

Set the box and material

All dimensions here are millimetres. The side clearance is ordered left, right, front, back. The top reserve leaves room above the insert, for example for boards and rules.

schema_version: 1
project:
  id: my-game
  name: My Game
box:
  inner_mm: [220, 160, 45]
  side_clearance_mm: [1, 1, 1, 1]
  top_reserve_mm: 3
material:
  profile: de-mdf-3mm
  overrides:
    thickness_mm: 3
    kerf_mm: 0.16
    fit_clearance_mm: 0.10

Choose a profile for the sheet you intend to use and enter its thickness and kerf. The bundled starter profiles require both values. Prepare your material explains the settings and calibration.

Describe the contents

For each directly stored component, give a unique id and a kind. The two starter components below become storage needs that the automatic layout can place. For cards, split_counts must add up to count, and each split needs a corresponding stack measurement. The three allowance values add handling room to the card width, depth, and stack height.

components:
  - id: cards
    kind: cards
    count: 60
    card_outer_mm: [66, 91]
    stack_measurements_mm: [30]
    split_counts: [60]
    allowance_total_mm: [4, 4, 2]
    orientations: [flat_xy, flat_yx]
  - id: tokens
    kind: explicit
    clear_min_mm: [40, 50, 25]
    orientations: [xy, yx]

clear_min_mm is the inside space requested for tokens. xy and yx permit a quarter-turn of that footprint. The card orientations permit the same footprint choice while keeping the deck flat. If a card deck has two splits, BGI creates requirement IDs such as cards-1 and cards-2; a single split keeps cards.

Choose the kind that matches what you know:

Kind	Use it when	Key fields
explicit	You have decided the clear compartment size	clear_min_mm, orientations
cards	You know card size, count, and stack height	card_outer_mm, count, split_counts, stack_measurements_mm, allowance_total_mm, orientations
objects	Identical rigid pieces follow a regular arrangement	count, object_outer_mm, arrangement, object_gap_mm, allowance_total_mm, orientations
loose	Contents fill space in bulk	measured_bulk_volume_cm3 or solid_volume_cm3 with fill_fraction, plus footprints_mm, allowed_heights_mm, allowance_total_mm

These are alternative partial component entries, not additions to the starter deck and tokens:

- id: tiles
  kind: objects
  count: 12
  object_outer_mm: [30, 30, 2]
  arrangement: [2, 2, 3]
  object_gap_mm: [0, 0, 0]
  allowance_total_mm: [2, 2, 2]
  orientations: [xyz]

The arrangement reserves a 2 × 2 × 3 pattern for twelve tiles inside one storage space. It does not produce twelve shaped pockets.

- id: wooden-pieces
  kind: loose
  measured_bulk_volume_cm3: 45
  footprints_mm: [[50, 40]]
  allowed_heights_mm: [30]
  allowance_total_mm: [0, 0, 0]

If you only know solid volume, use solid_volume_cm3 and fill_fraction instead of measured_bulk_volume_cm3; label that result as an estimate in your own measurement notes.

Assign contents to an assembly

An assembly is a constructed set of compartments. Its members list names the component or storage requirement IDs that belong inside it. The starter puts the deck and tokens in one grid assembly, and asks BGI to choose the interior division:

assemblies:
  - id: insert
    kind: grid
    construction: open_grid_box
    assembly: glue_allowed
    members: [cards, tokens]
    interior:
      id: compartments
      kind: auto

Decide what shares a compartment

A group deliberately combines two or more requirements into one shared compartment before placement. Use it only when those contents should actually share space. For example, change the card deck to split_counts: [30, 30] and enter a measured height for each stack in stack_measurements_mm. BGI then creates cards-1 and cards-2. To store them side by side in one compartment, add:

groups:
  - id: shared-cards
    layout: row
    axis: x
    gap_mm: 2
    members:
      - {requirement: cards-1, orientation: flat_xy}
      - {requirement: cards-2, orientation: flat_xy}

Change the assembly to members: [shared-cards, tokens]. The cards now share one compartment; the tokens still have their own. BGI does not decide which contents should be grouped; you make that storage choice.

Keep an existing container

An existing closed container uses its outside envelope and stays separate from newly constructed compartments. A partial entry looks like this:

containers:
  - id: deck-box
    outer_mm: [80, 90, 30]
    side_clearance_mm: [2, 2, 2, 2]
    top_clearance_mm: 5
    rotations_deg: [0, 90]

Do not list the contents of that closed box again as directly stored components. Its walls cannot serve as fixed walls for adjacent loose contents. A project combining a constructed grid and an existing container uses construction_mode: local_groups; Get layout suggestions explains this choice.

Request automatic layouts

Add this block to the starter project. full_box requests one constructed grid, without existing containers. Its compartments are sized for the contents; unused box space is not automatically filled. The search budget limits how many candidates are explored, and top_k asks for up to three results.

layout:
  mode: auto
  construction_mode: full_box
  search:
    budget: 100
    top_k: 3

The box, material, original two components, assemblies, and layout blocks together form the starter game.bgi.yaml, without the optional group or container. Full example has that complete file in one block. The YAML describes requirements and allowed choices; it does not prescribe a divider pattern. If you want to keep some placements or interiors fixed, see Manual and mixed layouts. Next, request and compare automatic layouts.