PR pixi-reels
All recipes

Pyramid shape with Spine

Per-reel static shape (3-5-5-5-3 pyramid) rendered with Spine skeletons. The outer 3-row reels get taller cells than the inner 5-row reels. Spine scales each rig cleanly without the texture stretching you'd see with sprites.

Loading recipe…

Same per-reel static shape as the CardSymbol pyramid, real Spine art on top. The shape is 3-5-5-5-3: outer reels are 3 rows tall, inner reels are 5 rows. Cell width is uniform across reels, but cell height differs by reel. the engine sizes each cell so the reel’s pixel column adds up to the same height. With sprite art that means the outer reels stretch their textures vertically; with Spine each rig redraws at the cell’s actual size, so the outer cells stay crisp.

The whole mechanic

import { loadGeneratedSpines, buildSpineMap } from '../../shared/generatedSpineLoader';

await loadGeneratedSpines();

const SPINE_MAP = {
  '9':  'low_a', '10': 'low_k',
  J:    'low_q', Q:    'low_j',
  K:    'mid_1', A:    'high_1',
};

new ReelSetBuilder()
  .reels(5)
  .visibleRowsPerReel([3, 5, 5, 5, 3])  // mutually exclusive with visibleRows(n)
  .reelAnchor('center')                  // 'top' | 'center' | 'bottom'
  .symbolSize(80, 80)
  .symbols((registry) => {
    const spineMap = buildSpineMap(SPINE_MAP);
    for (const id of Object.keys(SPINE_MAP)) {
      registry.register(id, SpineReelSymbol, {
        spineMap,
        autoPlayLanding: true,
      });
    }
  })
  .build();

The Spine wiring is identical to a uniform layout. SpineReelSymbol doesn’t care about per-reel geometry. The engine handles offsetY per reel, mask sizing, and cell positioning; each cell just gets a resize(width, height) call and the spine re-centers itself in the new box.

Why Spine here, specifically

Pyramid shapes amplify the per-cell-size difference: a 3-row reel inside a 5-row bounding box has each cell ~5/3 as tall as the inner reels’ cells. Pre-rendered sprites at one resolution either look soft on the bigger cells or pixelated on smaller ones. Spine skeletons are vector. every reshape redraws at the actual size.

The same point applies to MultiWays (where row count changes per spin), but the engine deliberately doesn’t allow big symbols on MultiWays. Static pyramids and big symbols are compatible, so the spine version of this recipe is the one to grab when you want both.

Animations carry across reshape

idle, landing, win, and destroy all play correctly regardless of which reel a symbol lands on. the animations are authored on bone-relative scale and translate, so the rig adapts to whatever cell box the engine hands it. The destroy animation ends at scale 1.55 / alpha 0 (intentional. the symbol is gone). Every other animation settles at scale 1 / alpha ff so symbols never get stuck invisible or oversized between plays.

Mutually exclusive with MultiWays

A static pyramid is set once at build. MultiWays changes the row count per spin. different mechanic, different builder method. See the MultiWays recipe. MultiWays is intentionally not wired up to the generated Spine bundle. the per-spin reshape pacing is delicate enough that we’d rather get it right per-game than ship a generic example.