Order of work and limits
Two questions come up on every new game: what to build first, and what the engine will not do. This page answers both.
For how to build a particular mechanic, see Slot Features. This page is about the order you do it in.
The short version​
Decide the numbers, build the screen, wire the maths, deploy, publish.
The numbers come first as a decision. The screen comes first as work. Those are not in conflict, and getting them the wrong way round is the most common way a first build stalls.
1. Decide the maths before you build anything​
Settle these on paper, before a single node exists:
- the grid — how many reels, how many rows
- the symbol set, and which symbols are wild or scatter
- the paytable
- the target RTP and volatility
- which features exist, and what triggers each one
These are design inputs, not implementation details. The reel and column count alone propagates into four places that must agree, and every bet mode or RTP variant needs its own certified RTP run. Changing any of it later is a rebuild, not an edit.
2. Build the screen, with real art​
Put the game on screen next: background, reel frame, symbols, buttons, the HUD.
A component under the maths sheet has no instance on any page, so a project that starts with maths renders nothing. There is no way to look at it, and no way to tell whether any of it is right. Build something you can see, then make it work.
3. Wire the maths into the screen​
Now build the graph in ordinary components and connect it to what is already on screen. Preview runs it in the browser, so you can play the game before any backend exists.
Wire ISAAC Random Number Array Generator → array into every Seeds port, one seed per column. An unseeded node refuses to run — it logs the reason, empties its outputs and still fires Done. It is not a warning you can leave until later: an unseeded spin is not provably fair, and it looks identical to a fair one.
4. Move the server-side maths into Maths Components​
Where code runs is decided by location. A deployed component under the maths sheet runs on the RGS; everything else runs in the browser. There is no Compile step, and no isMath checkbox on nodes.
Move the parts a player must not be able to see or change — the RNG, the reel draw, win evaluation, feature triggers, jackpot decisions — into Maths Components, deploy them, then simulate.
Keep presentation out of them. Animation, sound, rollups and timing stay in the browser. The server returns an outcome, not a performance.
5. Publish​
Publish copies the project, swaps every instance of a deployed component for an Aggregator aimed at its live endpoint, stamps the game onto the copy, and deploys the frontend.
Two things must be true first: you are connected to XGENIA RGS, and a game is selected.
The swap is per instance. A Maths Component that is not placed anywhere in the graph is never called — it deploys, it just never runs.
The five steps at a glance​
| Step | Where the work lives | You are done when |
|---|---|---|
| 1. Decide the maths | On paper | The grid, paytable, RTP target and feature list are written down |
| 2. Build the screen | Pages and visual components | The game looks finished and does nothing |
| 3. Wire the maths | Ordinary components, seeded | It plays in Preview |
| 4. Deploy the maths | Components under the maths sheet | Simulate reports the RTP you designed for |
| 5. Publish | Publish → XGENIA tab | The published URL plays against the live endpoints |
Hard limits​
These will stop a build​
| Limit | What you will see |
|---|---|
| Reel and column counts must agree across reel-strip generation, the spin, the paytable and the visual | Weighted Reels throws — "All reel strips must have the same length" — and the reels do not render at all |
Every drawing node needs Seeds | The node refuses, empties its outputs, and fires Done anyway, so the round completes with nothing in it |
| Cascade The Reels cannot be deployed | Deploy refuses the component: the node has no server-side implementation. Move the logic to Directional Cascade or a JavaScript Function |
| A component cannot contain itself | The editor refuses to place it, rather than recursing |
| Money is in integer minor units | Fractional amounts are a maths bug, not a formatting one |
These behave differently once the game is live​
| Limit | Effect |
|---|---|
| Stateful mechanics need an identified player | A guest session replays stateless: meters, sticky symbols, locked reels and hold-and-win grids all start fresh every round |
| Each bet mode and RTP variant is its own certified run | You cannot certify one mode and ship three |
Renderer limits​
| Limit | Work around it with |
|---|---|
| Cascades animate downward only | Directional Cascade computes up, left and right correctly — use the fade cascade style for those directions |
| Cells are 1×1 | Sticky and oversized symbols are drawn by pixi.CellOverlay on top of the reel columns, which still land whole columns |
| Anticipation is off by default | Switch on Enable Anticipation on the Reel Controller. Note that a graph feeding each column's targetSymbols directly bypasses the controller, so nothing anticipates |
Tooling limits​
| Limit | Detail |
|---|---|
| PSD export writes up to 20 layers | The Aim for N layers slider caps there |
| There is no PSD import | The image editor opens png, jpg, jpeg, gif, svg and webp. Keep the layered original in Photoshop |
| The editor wants 8 GB of RAM, 16 GB for comfort | Below that the renderer runs out of memory on large projects and the editor restarts itself |