Slay the Spire 2 Seed and RNG Mechanics
In Slay the Spire 2, a seed is best understood as the random starting point for a run. It influences map layout, rewards, shops, shuffles, monster behavior, and many other systems, but it is not a complete script for the entire run.
For players, the useful takeaway is simple: a seed helps reproduce the broad shape of a run, but final outcomes still depend on character, path, choices, deck state, relics, game version, mods, and multiplayer player identity.
What Players Actually See
The same seed often helps reproduce:
- The broad map layout, paths, and room distribution.
- Reward tendencies when route and choices are the same.
- Some shop, treasure, event, and reward outcomes.
- Combat shuffles, random generation, and random monster branches.
But later outcomes may change if you change what happens during the run:
- A different route changes rooms and reward pools.
- A different event choice changes later state and candidates.
- Adding or removing one card can change later shuffles and random card selection.
- Different mods can change card pools, relic pools, events, or logic hooks.
- In multiplayer, some player-specific results may be derived separately per player.
So “same seed, same run” really means: many random results can be reproduced when version, mods, character, path, choices, and key game state are also close enough.
Why a Seed Alone Does Not Reveal Everything
A seed defines where a random sequence starts. It does not define what the game is choosing from.
For example, reward cards are not decided by seed alone. The game first builds a candidate pool from character, unlocks, mode, multiplayer constraints, relics, mods, and other filters. Then it randomly chooses from that pool. If the pool changes, the visible result can change even if the random position is the same.
The same applies to shuffling. The same random order applied to a different deck produces a different visible draw pile. If you removed or added one card earlier, later shuffles may no longer look identical.
How to Reproduce a Run More Reliably
If you want to reproduce a situation, record more than the seed:
- Game version.
- Mod list and mod versions.
- Character, ascension, and game mode.
- Route and major room choices.
- Important reward choices, removes, transforms, and shop purchases.
- Multiplayer player position or player id, if relevant.
For debugging or mod development, also keep the save file, logs, or RNG state when possible. Most players do not need that extra layer.
How God Mod Can Use This Information
Player-friendly features could include:
| Feature | What it helps with | Risk |
|---|---|---|
| Seed viewer / copy | Share the current run, record a test case | Read-only, low risk |
| Current act map seed info | Help reproduce one act map | Read-only, low risk |
| Reproduction export | Collect seed, character, mods, route, and key context into a report | Read-only, useful for bug reports |
| Safe preview | Preview next shuffle, unknown room, reward, or shop tendency | Must be implemented carefully so it does not change real RNG state |
Advanced features like resetting, fast-forwarding, or replacing RNG streams directly affect future outcomes and may break multiplayer sync. They belong in expert/debug tooling, not the normal player path.
Implementation Details
This section is about code-level implementation. If you only care about what seeds mean for normal play, you can skip it; the sections above are enough.
At the implementation level, STS2 does not drive every system from one global random stream. It derives multiple RNG streams from the same string seed. Each stream has its own seed and counter. Every random number, shuffle, or random selection advances the relevant stream counter.
The code-level layers are:
| Layer | Mechanism | Typical use |
|---|---|---|
| String seed | Stored as StringSeed, then converted into a stable numeric seed | Sharing, reproduction, derived RNG streams |
Rng | Each stream stores Seed and Counter; every random call advances the counter | Save, load, fast-forward, and reproduce one stream |
RunRngSet | Derives run-level streams from the run seed | Map, shuffle, unknown rooms, combat generation, monster AI, treasure relics |
PlayerRngSet | Derives player-level streams from run seed plus player NetId | Rewards, shops, transformations |
| Map RNG | Each act map derives from the run seed with an act_N_map name | Act map layout, paths, and room type distribution |
Common run-level streams include:
Shuffle: initial combat shuffle, discard-to-draw shuffle, and some random card positions.UnknownMapPoint: unknown room type rolls and related odds.CombatCardGeneration: random cards generated during combat.CombatPotionGeneration: random potions generated during combat.CombatCardSelection: random selection from existing cards during combat.CombatEnergyCosts,CombatTargets,CombatOrbs: random combat costs, targets, or orb-related results.MonsterAi: random monster move branches.TreasureRoomRelics: shared treasure room relic synchronization.UpFront: early setup, room pools, relic pools, and ancient-related setup.Niche: miscellaneous stable random choices.
Player-level streams are fewer but important:
Rewards: reward cards, reward relic rarity, and some event rewards.Shops: shop cards, potions, relics, and price variance.Transformations: card transformations.
Why Future Preview Must Clone RNG
If a tool wants to preview the future, it should not call the live game RNG directly. It should copy the current stream's Seed + Counter and simulate the next result on a temporary clone.
The reason is simple: every real RNG call advances the counter. If preview code consumes the real stream, the act of previewing changes the future it was trying to show.
A safe preview flow is:
- Read the live RNG seed and counter.
- Create a temporary RNG clone with the same state.
- Simulate reward, shuffle, unknown room, or shop results on the clone.
- Show the preview.
- Discard the clone and leave real game state untouched.