Task Breakdown is the central design principle of the Web SDK. Rather than implementing a complex game feature as one large block, you decompose it into small, named, independently-testable pieces called emitterEvents.
The core principle
Each emitterEventHandler should do one minimal job — the job described by its type name. This is the Single Responsibility Principle applied to game events. freeSpinCounterShow should only show the component. It should not update the counter value. freeSpinCounterUpdate should only update the counter values. It should not show or hide anything.
When each handler does exactly one thing:
- It can be named precisely, making the sequence of operations readable
- Each step can be tested independently in Storybook
- Bugs are isolated to a single handler instead of buried in a large function
- Components stay focused and easy to reason about
The tumbleBoard example
tumbleBoard is a mechanically complex bookEvent. Symbols explode, disappear, new symbols fall from above, and the board settles into a new state. A naive implementation might put all of this logic in a single tumbleBoard emitterEvent.
Instead, it is broken into four atomic steps:
| emitterEvent | Responsibility |
|---|
tumbleBoardInit | Load new symbols into the board above the visible area |
tumbleBoardExplode | Play explosion animations on the winning symbols |
tumbleBoardRemoveExploded | Remove the exploded symbols from state |
tumbleBoardSlideDown | Animate remaining symbols sliding down to fill gaps |
bookEventHandler in bookEventHandlerMap.ts sequences them:
// bookEventHandlerMap.ts
tumbleBoard: async (bookEvent: BookEventOfType<'tumbleBoard'>) => {
eventEmitter.broadcast({ type: 'tumbleBoardShow' });
eventEmitter.broadcast({ type: 'tumbleBoardInit', addingBoard: bookEvent.newSymbols });
await eventEmitter.broadcastAsync({
type: 'tumbleBoardExplode',
explodingPositions: bookEvent.explodingSymbols,
});
eventEmitter.broadcast({ type: 'tumbleBoardRemoveExploded' });
await eventEmitter.broadcastAsync({ type: 'tumbleBoardSlideDown' });
eventEmitter.broadcast({
type: 'boardSettle',
board: stateGameDerived
.tumbleBoardCombined()
.map((tumbleReel) => tumbleReel.map((tumbleSymbol) => tumbleSymbol.rawSymbol)),
});
eventEmitter.broadcast({ type: 'tumbleBoardReset' });
eventEmitter.broadcast({ type: 'tumbleBoardHide' });
},
eventEmitter.broadcast() is synchronous and fire-and-forget. eventEmitter.broadcastAsync() waits for all subscribers to resolve before continuing. Use broadcastAsync for any step that involves an animation you need to wait on — like the explosion and slide-down phases above.
subscribeOnMount in TumbleBoard.svelte lists all the handlers:
<!-- TumbleBoard.svelte -->
context.eventEmitter.subscribeOnMount({
tumbleBoardShow: () => {},
tumbleBoardHide: () => {},
tumbleBoardInit: () => {},
tumbleBoardReset: () => {},
tumbleBoardExplode: () => {},
tumbleBoardRemoveExploded: () => {},
tumbleBoardSlideDown: () => {},
});
TumbleBoard.svelte to understand the sequence.
Why this matters for testing
Because every step is its own named emitterEvent, you can write a Storybook story for each one under COMPONENTS/<Game>/emitterEvent. You can test that the explosion animation works before the slide-down is even implemented. You can verify the slide-down independently if the explosion is broken.
With a monolithic approach you would have to test all or nothing.
emitterEvents can span multiple components
The emitterEvents under a single bookEvent can come from different Svelte components. A reveal bookEvent might broadcast events that are handled by Board.svelte, Sound.svelte, and Transition.svelte simultaneously.
bookEventHandler is the orchestrator. Individual Svelte components are the workers. Each component only knows about its own slice of the work.
Visually this looks like a bookEvent with coloured blocks beneath it — each colour representing a different Svelte component that handles some of the emitterEvents in that sequence.
Stateless vs stateful games
Task Breakdown applies regardless of game type, but it is especially valuable for stateless games:
-
Stateless games: A single request to the RGS produces all the data for a complete round. A slots game is a typical example — one request returns the full
book of bookEvents for a spin.
-
Stateful games: Multiple requests are needed to complete a round. A mines game (where the player reveals tiles one at a time) requires a separate RGS request for each tile reveal.
Stateless games can still be surprisingly complex — multiple game modes, free spin mechanics, global multipliers, win levels, and different spin types all need to be decomposed and tested individually.
Implementation workflow
The recommended way to build any feature is to implement it incrementally through the task breakdown:
- Define the bookEvent type
- Write the bookEventHandler with the emitterEvent sequence
- Define emitterEvent types on the Svelte component
- Implement one emitterEventHandler at a time
- Test each one in Storybook before moving to the next
This matches the steps described in the Adding a BookEvent guide. 