Building Slot Siege as a Telemetry-Informed Multiplayer Game

Slot Siege is a top-down action roguelike built around slot-machine outcomes, resource gathering, building, combat, and escalating night waves. I co-lead development as one of four developers, with specific ownership of telemetry and ML plus broad gameplay and integration work.

The game has to feel good moment to moment, but a small team also needs a repeatable way to learn which nights, enemies, systems, and difficulty settings are actually working. That changed the development problem. We were not only building gameplay. We were also building the feedback loop around the gameplay so playtests could produce structured evidence for the next product decision.

The current Godot architecture uses host-authoritative gameplay. The host owns durable world facts, while clients request actions through a network boundary and receive synchronized state. The game includes version checks, late-join snapshots, multiplayer spawning, shared world state, and regression coverage for synchronization failures.

Performance is treated as a product constraint rather than cleanup work. The project includes single- and multiplayer stress scenes, profiler capture, staged visual prewarming, and dedicated performance interpretation documentation. That matters because instrumentation is only useful if collecting it does not make the game feel worse.

The telemetry system records gameplay balance evidence, builds run and night summaries, and can upload completed bundles when the player has enabled telemetry. Authoritative gameplay facts are collected from the host path where possible, while local UI events can remain client-side.

The system intentionally excludes raw Steam IDs, display names, lobby codes, IP addresses, and chat text. Upload work is budgeted so it does not block gameplay, oversized event families are bounded or sampled, and local data is deleted only after the server confirms a successful commit.

Current summaries preserve evidence such as clear time, challenge mode, player feedback, enemy spawn and kill counts by level, and whether debug commands contaminated part of a run. That gives later analysis a way to distinguish useful playtest evidence from data that should be excluded.

An offline night balance recommender consumes telemetry exports and the current authored balance state. It filters invalid evidence, accounts for challenge and player-count differences, lowers confidence when samples are mixed, and produces review artifacts rather than editing game resources automatically.

That boundary is deliberate. The goal is to make balancing faster and more evidence-driven without allowing an analysis tool to silently rewrite the live game. Future ML-assisted balancing can build on this pipeline, but it is not presented here as a shipped autonomous system.

A separate Slot Siege intelligence codebase contains a web application and API for telemetry analysis. It uses a modern TypeScript stack with Next.js, Supabase, tests, and deployment tooling. Keeping that surface separate lets the game remain focused on runtime performance while analysis can evolve as its own product surface.

The game creates the experience, telemetry records what happened, and the analysis layer helps the team decide what to change. The output is not "the model says so." It is evidence that can be reviewed alongside design intent and playtester feedback.

The repository contains a Steam release-evidence process that checks build identity, CI, multiplayer validation, exported artifacts, runtime staging, store readiness, cost review, rollback, and support. Importantly, that process explicitly does not create or publish a Steam store page and still requires founder approval before a first public production release.

This case study does not claim a public Steam release. The stronger story today is the delivery machinery being built before release: gameplay, multiplayer reliability, telemetry, performance evidence, balance analysis, and explicit release gates.

• Shipping across gameplay, multiplayer, performance, telemetry, and analytical tooling in one product.
• Designing instrumentation around privacy and runtime constraints rather than adding analytics later.
• Keeping automated recommendations reviewable and separated from direct production changes.
• Using explicit evidence gates to separate release preparation from a public release claim.
• Building a feedback loop that can support increasingly data-informed balancing over time.