The positions we're taking
Opinions Every opinionated call slotplate makes, collected so you can decide if we're right for your team.
Many of these show up inline throughout the docs. This page exists as the one-place-to-share
version. If one of these stops you cold, slotplate is probably not for you — and that's fine,
our opinions being wrong for you doesn't make them wrong in general.
Architecture
You don't need Redux. MobX observables on a RootStore cover every slot I've shipped,
and the ceremony tax of Redux shows up in every diff. If you want time-travel debugging,
use MobX dev tools.
Never build a bespoke reel renderer. You will rebuild pooling, wrapping, anticipation,
and Spine integration — badly — and then spend a year fixing the bugs pixi-reels already fixed.
Slot games are finite state machines. Pretending otherwise produces spaghetti of
isSpinning, canStop, showingWin, awaitingResponse.
One FSM with named phases is ten times easier to read and correct by construction.
Client vs server On client-side evaluation
The client never evaluates wins. Not as a fallback. Not "for offline mode." Not
"for faster response." Two evaluators means two sources of truth, and one is wrong.
There is no RTP harness in slotplate. That's a server concern. The client's job
is fidelity of replay, not correctness of math.
Timing
Game code never calls setTimeout. Not once. Not "just this time."
Use the ticker. Future you will thank present you the first time a tester reports
a double-spin from a backgrounded tab.
GSAP is fine. It's battle-tested and its easing curves are what designers expect.
Just sync its root ticker to Pixi's — otherwise it runs on a separate clock and
all your nice invariants break.
Errors
No silent catches. An error you see on day one is cheap. A silent divergence
discovered in week four is not.
Do not fall back to a default when a config is missing. Throw with a message that
names what's missing and who should have provided it.
Scope
Three similar lines is better than a premature abstraction. Build the second case
before you build the interface.
One logical change per PR. If the description needs "and" twice, split it.
Small PRs ship; large ones get reverted.
Monorepos
Monorepos are a cost. Pay it only when you need to publish multiple packages
or have multiple apps sharing code. A single slot doesn't.
AI agents
Docs exist to be consumed. The llms.txt convention is five minutes of work and
makes your project legible to tools that will increasingly read it. There is no downside.
On committing agent rules
Commit CLAUDE.md. Commit .claude/commands/. An agent without
project-specific rules will drift; with them, it stays on-spec.
Edit this page on GitHub
docs/src/pages/docs/opinions.astro