Go Backend Slot Game Engine Developer

The Go Backend Slot Game Engine Developer is the game-logic authority for the project. The role builds the server-side slot engine from scratch on a Go-based slot Game Development Kit (GDK) and owns it end-to-end — from the math model through integration
review, certification readiness, and live operation on the Remote Gaming Server (RGS) platform.
Scope of ownership covers the slot engine's game logic and mathematics (RTP structure, reel strips, paylines / clusters / Megaways / avalanche, win evaluation), the feature set (buy bonus, ante bet, free spins including retriggers and player-choice, max-win validation), the
paytable and reel/volatility configuration, the RTP simulation and validation harness, and the engine's conformance to the RGS integration contract — the engine lifecycle interfaces, the
spin/keep-generate/replay endpoints, RNG consumed exclusively through the SDK-injected RNG client, and SDK-compliant submission for platform integration review.
Technical Constraints
- Language: Go (1.24+).
- Transport: HTTP and gRPC
- Randomness: all RNG is delegated to the platform RNG service and consumed exclusively through the SDK-injected RNG client. Local or library randomness on game outcomes is treated as Non-Compliance.
- Configuration: reel sets, RTP and volatility externalized to configuration; simulator and runtime parameters via configurations and environment variables. No hardcoded math values in business logic.
- Version control: Git, with Go modules for dependency and version management.
- Local development: engine runs locally and connects to the development platform API via a tunnel; validated against SDK-provided mock services and simulators before submission.
- Deliverable: a compiled engine build submitted through the designated submission process, accompanied by build manifest (version, commit hash, build date), paytable configuration, and a signed SDK compliance statement.
Responsibilities
- Own the slot engine implementation: the engine lifecycle interfaces (spin generation, keep-generate for player-choice sequences, history replay / shown-state logic) and the conversion of game outcomes into the platform's wire model.
- Own the game mathematics: RTP structure, reel strips, paylines / clusters / Megaways, and win evaluation — modelled as the sole server-side authority on probability and outcome, with all probability and balance tables externalized to configuration.
- Own the feature set: buy bonus, ante bet, free spins (fixed, retriggerable, and player-choice), and max-win validation.
- Own the balance configuration tooling: a documented mechanism and config format so Game Design and math can update reel sets, RTP, volatility, and paytable values without code changes.
- Own the RTP simulation and validation harness: run the SDK simulator to prove target RTP, volatility, and max-win behavior, and attach the simulation report to each submission.
- Own SDK compliance and submission: use only documented SDK APIs, implement all required lifecycle methods, conform outgoing payloads to the published event and message schemas, stay within the supported SDK version range, and produce a signed compliance statement per build.
- Drive each build through the platform integration review: package the required submission artefacts, remediate documented review findings, and re-submit until integration is accepted.
- Author and maintain backend documentation: the math/game-logic specification, configuration format, architecture records, and a developer-readable README for the engine.
- Pair with the Game Designer and the client (frontend) team to translate design and GDD
intent into server-feasible, server-authoritative engine specifications.
- Own the engine's quality and security posture: unit-test coverage of game-logic modules, clean SAST/DAST scans, and no secrets in source, fixtures, or commit history.
- Actively use and document the use of AI tools (ChatGPT, Gemini, Claude) to accelerate scaffolding, math modelling, and documentation. Document outcomes alongside prompts so the workflow is reproducible by the team.
Requirements
The position has four hard pillars.
Pillar A — Go Service Architecture and SDK Integration
- Demonstrated ability to design a layered Go service in which the game-logic domain is unit-testable without booting the transport layer, the SDK, or any external service.
- Working knowledge of implementing engine lifecycle interfaces against a provided SDK:
spin generation, continuation (keep-generate) for multi-step sequences, and deterministic reconstruction of stored spins for history replay.
- Discipline in conforming to published event and message schemas, with consistent, well-defined error semantics across the contract.
- Versioning discipline: ability to evolve the engine and its wire payloads without breaking shipped client builds, including a documented deprecation policy, and to stay within the
SDK's supported version range without deprecated calls.
- Ability to externalize hand-tunable parameters (reel sets, RTP, volatility, paytable, limits) through configuration rather than code.
Pillar B — Slot Mathematics and Game Logic
- Demonstrated ability to model probabilistic slot mechanics where the server is the sole authority on probability, tier, and outcome.
- Probability, reel, and balance tables externalized to configuration. Hardcoded math or balance values inside business logic are treated as Non-Compliance.
- Currency and award math: integer or fixed-point arithmetic for all wager, balance, and award operations. Floating-point arithmetic on monetary values is treated as Non-Compliance.
- All randomness consumed exclusively through the SDK-injected RNG client; no local or library RNG on game outcomes.
- Working knowledge of common slot mechanics: paylines (left-to-right / right-to-left), clusters, Megaways, avalanche/cascades, free spins (fixed, retriggerable, player-choice), buy bonus, and ante bet, with max-win validation.
Pillar C — Determinism, Compliance, and Integrity
- Demonstrated ability to guarantee deterministic replay: a stored spin must reconstruct to an identical, player-visible state on history replay.
- Anti-abuse posture: idempotency for retry-prone operations, replay resistance.
- SDK compliance discipline: use of only documented APIs, no private or undocumented endpoints, correct lifecycle implementation, and a signed compliance statement per build.
- Secret-handling discipline: no secrets, signing keys, or credentials in source, fixtures, or commit history; awareness of and mitigation for common (OWASP Top 10) vulnerability categories.
Pillar D — Simulation, Performance, and Reliability
- Demonstrated ability to run large-scale spin simulation to validate statistical targets (RTP, volatility, hit rate, max-win) and to produce a reproducible simulation report.
- Working understanding of latency and throughput budgets for spin endpoints, including how serialization, allocation, and hot-path design affect them.
- Profiling expertise on a Go service: ability to localize latency or contention using application-level traces, profiling tools (e.g. pprof), and load-test evidence.
- Observability discipline: structured logs with correlation IDs across requests and metrics on the relevant endpoints.
- Testing discipline: unit-test coverage of game-logic modules with clean SAST/DAST scans.