Persistence Complexity and RNG Choices

Probability Director gives a game more control over randomness than Unreal’s ordinary random helpers, but that control comes with additional persistence responsibilities.

This document explains what persistence complexity means, why Probability Director streams are more capable than a simple Unreal random stream, where that extra complexity comes from, and when a normal Unreal RNG is still the better choice.

This is an architectural comparison. It does not depend on the exact internal PRNG algorithm used by Unreal’s FRandomStream.

1. What Is Persistence Complexity?

Persistence complexity is the amount of state, identity, ordering, compatibility information, and save/load coordination required to make a system behave correctly after a game is saved and later restored.

For a simple gameplay value, persistence is easy:

Health = 73
Gold = 412
QuestState = Completed

Save the value, load the value, and the system is restored.

Randomness is different because the important state may include not only a value that already happened, but also the state that determines what happens next.

For example:

Random sequence before saving:

12, 4, 19, 7, 3, 15, ...
          ^
          game saves here

If the game loads later, should the next value be:

or should the random generator start over?

Should it generate a completely unrelated value?

Should the result depend on which other systems consumed randomness before it?

Should the same chest produce the same loot after reload?

Those are persistence-policy questions.

The more guarantees a random system provides, the more information and rules it must preserve.

That is what is meant by persistence complexity.

2. The Simple Unreal RNG Case

For many Unreal games, a normal random helper or FRandomStream is completely sufficient.

A typical deterministic stream concept is straightforward:

Create stream
    -> give it a seed
    -> request values
    -> stream advances

The developer is responsible for deciding:

who owns the stream;
where it is stored;
whether its state is saved;
how it is restored;
which gameplay systems share it;
whether a reload should reproduce the same result;
whether unrelated calls are allowed to change later results.

That simplicity is useful.

There is very little framework overhead because Unreal’s random stream does not attempt to solve the entire persistence architecture of the game.

For a local procedural task, that can be exactly what you want.

Example:

Create FRandomStream from Seed 12345

Generate:
- tree rotation
- rock scale
- grass variation

Discard the stream when finished

There is no need for a larger persistence system if those values are generated once and then stored as normal gameplay/world state.

3. Why Probability Director Is More Complex

Probability Director does more than produce the next pseudorandom number.

A Probability Director stream participates in a larger contract involving:

stable Stream IDs;
GameInstance-scoped ownership;
Fixed or Secure seed sources;
Sequential or Keyed decision behavior;
isolated streams for unrelated gameplay systems;
explicit persistence policies;
deterministic save/load restoration;
transactional RotateOnSave behavior;
persistence compatibility validation;
structured result/error reporting;
diagnostics and warnings;
sanitized Runtime Inspector information;
Blueprint and C++ APIs;
optional SaveGame Director integration.

Each feature adds rules that a simple RNG object does not need to manage.

The additional complexity is intentional: it buys the developer stronger guarantees about how randomness behaves across systems, sessions, and save/load boundaries.

4. The Core Difference

A useful way to think about the difference is:

Normal Unreal RNG

Give me random numbers.

Probability Director

Give this gameplay system a named and controlled source of randomness, define how decisions are reproduced, define how it survives saving, keep unrelated systems isolated, and make the behavior inspectable.

That is a much larger responsibility.

Probability Director is not “better” for every use case.

It is better when those additional guarantees matter.

5. Complexity Comparison

Capability	Ordinary Unreal random use	Probability Director
Generate random values	Yes	Yes
Deterministic seeded sequence	Yes, with a seeded stream	Yes
Stable named gameplay streams	Developer-managed	Built in
GameInstance-scoped stream registry	Developer-managed	Built in
Separate unrelated gameplay RNG domains	Developer convention	First-class stream design
Secure seed source	Not the purpose of a normal deterministic stream	Built in
Sequential decisions	Yes	First-class contract
Keyed decisions independent of unrelated Sequential call order	Developer must build it	Built in
Persistence policy per stream	Developer must build it	Built in
Save/load compatibility validation	Developer must build it	Built in
Transactional rotation on successful save	Developer must build it	Built in
DirectorBridge Probability.SaveGame adapter	Not required by the Probability core	Optional integration
Structured diagnostics	Minimal unless developer adds them	Built in
Runtime stream inspection	Developer must build it	Probability Director Runtime Inspector
Exact probability/dice/distribution systems	Separate problem	Integrated with Probability Director
Statistical/Monte Carlo developer tooling	Developer must build it	Integrated Labs
Raw simplicity	Excellent	Intentionally more structured

6. Where the Extra Persistence Complexity Comes From

6.1 Stream identity

A local Unreal random stream can simply live in a variable.

Probability Director gives streams stable identities such as:

Combat.Damage
Combat.Critical
Loot.DropTable
World.Encounters

That lets the game separate unrelated random domains.

But now persistence must know which saved state belongs to which stream.

6.2 Stream configuration

A persisted stream is not only random state.

Its configuration matters.

Examples include:

seed source;
decision mode;
persistence policy;
versioned deterministic contracts.

Restoring saved random state into a stream configured differently could produce incorrect behavior.

Probability Director therefore validates persistence compatibility instead of silently pretending that two different stream configurations are equivalent.

That is extra complexity, but it protects deterministic behavior.

6.3 Sequential progression

A Sequential stream means:

Give me the next result.

That means previous consumption matters.

If a save is restored, the stream must continue from the correct saved state.

Otherwise:

Before save:
A B C [SAVE] D E F

Incorrect reload:
A B C ...

Correct persisted reload:
D E F ...

A simple RNG can support this if the developer manually saves and restores its state correctly.

Probability Director makes the persistence policy part of the stream architecture.

6.4 Keyed decisions

Keyed decisions introduce a different persistence model.

A Keyed decision conceptually means:

Resolve this semantic decision from stable identity.

For example:

Namespace: Loot
Stable Subject ID: Chest.0042
Decision: Contents
Occurrence: 0

The result does not need to depend on how many unrelated Sequential calls occurred elsewhere.

That makes Keyed decisions extremely useful for stable procedural outcomes, but it requires:

stable Decision Keys;
canonical encoding;
deterministic derivation rules;
persistent campaign/stream identity;
version compatibility.

This is more sophisticated than asking a local stream for RandRange().

6.5 Fixed versus Secure identity

A Fixed stream can use a known reproducible seed.

A Secure stream uses protected random material intended to remain internal to Probability Director.

Persistence therefore has to preserve enough protected state to restore the Secure stream correctly without turning secret generator material into ordinary Blueprint data or diagnostics.

That adds a security boundary that a normal gameplay random stream does not normally need.

6.6 Save transaction coordination

Most RNG persistence can be described as:

Capture state
Save state
Restore state

RotateOnSave is more complicated because the save itself changes the committed random-generation boundary.

The correct workflow is transactional:

Prepare candidate
    -> storage succeeds
        -> Commit candidate

    -> storage fails/cancels
        -> Discard candidate

This prevents the running game from advancing to a random generation that was never successfully stored.

That is a real persistence guarantee and therefore a real source of additional complexity.

See Anti-Save-Scumming for the gameplay reasons to use PersistState, RotateOnSave, or Keyed decisions.

7. Why Probability Director Can Be Better for Gameplay Systems

7.1 Isolation

Suppose one shared RNG drives all of these systems:

combat
loot
ambient audio
particles
AI variation
encounters

Adding one new random particle call can shift the future sequence used by combat or loot.

Probability Director encourages separate streams:

Combat.Damage
Loot.DropTable
World.Encounters
Cosmetics.Particles

Now cosmetic random calls do not silently move the combat sequence.

This makes a large project easier to reason about and test.

7.2 Semantic decisions with Keyed mode

A Sequential RNG answers:

What comes next?

A Keyed Probability Director decision can answer:

What is the deterministic result for this specific decision?

That distinction is valuable.

For example, a procedural NPC trait can be tied to:

NPC.PersistentID + Trait.Personality

instead of depending on how many unrelated RNG calls happened before the NPC was initialized.

This can make procedural systems much more resilient to future code changes.

7.3 Save/load behavior is explicit

Without a framework, every gameplay system must decide independently whether and how its random stream survives saving.

Probability Director makes that decision explicit through persistence policy.

A developer can look at the stream and know whether it is intended to be:

Ephemeral;
persisted normally;
rotated at successful save boundaries.

That makes save behavior reviewable instead of accidental.

7.4 Better debugging

Random bugs are notoriously difficult to reproduce.

Probability Director provides structured diagnostics and the Probability Director Runtime Inspector so developers can inspect:

Stream ID;
seed source;
decision mode;
persistence policy;
operation metadata;
sanitized Keyed Decision Key information;
result status;
Sequential state effect;
deterministic algorithm/version information.

It deliberately does not expose secret Secure material or raw RNG state.

A normal RNG stream can absolutely be debugged, but the developer has to build the surrounding diagnostic infrastructure.

7.5 Stronger separation between random state and gameplay state

Probability Director helps enforce an important persistence rule:

Randomness decides gameplay state; it does not replace gameplay state.

If a chest already contains:

Sword
Potion
32 Gold

save those items.

Do not rely on regenerating them every load just because the RNG can be deterministic.

Probability Director preserves the random state required for future decisions while the save system preserves gameplay consequences that have already occurred.

8. Why Probability Director Is Not Always Better

The additional framework has a cost.

For simple uses, Probability Director may be unnecessary.

Use an ordinary Unreal random helper or local FRandomStream when:

the result is temporary;
the value is generated once and immediately stored;
save/load continuity does not matter;
no cross-system deterministic contract is required;
secure randomness is unnecessary;
no diagnostic stream identity is useful;
the feature is small enough that local ownership is clearer.

Examples:

Random editor preview color
Temporary particle variation
One-off decorative prop rotation
Nonpersistent menu animation
A procedural construction script whose final result is already serialized

Adding a named persistent Probability Director stream for each of those could create complexity without meaningful benefit.

9. When Probability Director Is the Better Choice

Probability Director becomes valuable when one or more of these are true:

the game uses many independent random gameplay systems;
deterministic save/load behavior matters;
reload-to-reroll behavior must be controlled;
unrelated RNG calls must not influence a decision;
a procedural outcome should be tied to stable semantic identity;
Secure randomness is desired;
deterministic reproduction is important for debugging;
Blueprint and C++ systems need the same random contract;
random behavior needs diagnostics;
designers need Probability Director Labs;
Dice, distributions, probability bias, Markov, or name generation use the same controlled RNG architecture;
SaveGame Director should orchestrate Probability Director persistence.

10. A Practical Example

Imagine an RPG using:

Combat.Damage
Combat.Critical
Loot.Chests
World.Encounters
Cosmetic.Variation

With one ordinary shared random stream

The game can work perfectly well.

But the developer must ensure:

the stream state is saved correctly;
cosmetic calls do not unexpectedly affect combat;
a chest cannot be rerolled unintentionally;
the same save restores the right RNG position;
future code changes do not change important procedural outcomes;
debugging records enough information to reproduce problems.

All of that is possible.

The game team owns the architecture.

With Probability Director

The design can instead be explicit:

Combat.Damage       Sequential + PersistState
Combat.Critical     Sequential + PersistState
Loot.Chests         Keyed + PersistState
World.Encounters    Sequential + RotateOnSave
Cosmetic.Variation  Ephemeral

Now each subsystem states its intended random and persistence behavior directly.

Probability Director owns the random-state contract.

The host SaveGame system still owns the actual saved gameplay data and storage.

11. Normal SaveGame Integration

Probability Director does not replace Unreal SaveGame.

A normal save still stores gameplay state such as:

inventory;
quests;
player position;
attributes;
world changes;
resolved loot;
mission progress.

Probability Director persistence is simply another piece of the save transaction.

Conceptually:

SAVE

Gameplay Save Data
    +
Probability Director Persistence Data
    |
    v
Save Slot / Storage

On load:

LOAD

Save Slot / Storage
    |
    +--> Restore gameplay state
    |
    +--> Restore Probability Director persistent state

The important goal is coherence: the gameplay state and the random state should represent the same saved moment.

See SaveGame Integration for the persistence workflow.

12. SaveGame Director Integration

When SaveGame Director is present, the owner boundaries remain:

Probability Director owns RNG algorithms, streams, decision keys, stream state, probability mechanics, and its persistence payload semantics.
SaveGame Director owns save/restore orchestration, contributor lifecycle, and required/optional contributor policy.
DirectorBridge provides optional registration and adaptation between the owners through Probability.SaveGame.

Probability Director remains usable without either integration plugin. DirectorBridge calls the Probability persistence APIs and does not implement serialization or stream-state behavior.

See SaveGame Director Integration and Migration.

13. Does More Complexity Mean More Runtime Cost?

Not necessarily.

Persistence complexity is primarily architectural complexity, not “every random call is expensive.”

The extra complexity mostly exists in:

stream ownership;
validation;
save/load;
diagnostics;
decision semantics;
compatibility;
tooling.

The actual cost of generating a random result is a separate performance question.

A simple non-cryptographic PRNG can be faster than a cryptographic PRNG, and a local RNG object can have less framework overhead than a managed subsystem.

That does not automatically make one design better.

Choose based on the guarantees the gameplay system needs.

Probability Director V1.1’s planned Stream/RNG analysis tools are intended to make algorithm and system-performance comparisons visible rather than relying on assumptions.

14. Does More Complexity Mean Better Randomness?

Also no.

Persistence architecture and statistical quality are different topics.

A perfectly saved weak PRNG is still a weak PRNG.

A statistically strong PRNG can still be integrated badly into gameplay.

Probability Director’s advantages come from combining:

a defined RNG implementation;
stream isolation;
deterministic contracts;
persistence semantics;
Keyed decisions;
Secure seed handling;
diagnostics;
probability systems;
developer tooling.

The architecture is the product advantage, not simply “more code around RNG.”

15. A Useful Complexity Ladder

Level 1 — Temporary randomness

Need:
"Give me a random cosmetic value."

Use ordinary Unreal randomness.

Level 2 — Reproducible local procedure

Need:
"Generate this procedural object the same way from Seed 123."

A local FRandomStream is often ideal.

Level 3 — Persistent gameplay sequence

Need:
"Combat randomness must continue correctly after save/load."

Probability Director PersistState becomes useful.

Level 4 — Stable semantic decisions

Need:
"This chest should have the same result regardless of unrelated RNG calls."

Use Probability Director Keyed decisions.

Level 5 — Save-boundary random policy

Need:
"A successful checkpoint must establish a new committed RNG generation."

Use Probability Director RotateOnSave.

Level 6 — Large project-wide random architecture

Need:
"Many gameplay systems, Blueprint/C++, diagnostics, persistence,
secure streams, exact probability systems, Labs, and save integration
must all share one controlled randomness contract."

This is the problem Probability Director is designed to solve.

16. Decision Guide

Requirement	Recommended tool
Quick temporary random number	Unreal random helper
Local reproducible generation from a seed	`FRandomStream`
Final generated result is immediately serialized and RNG continuity is irrelevant	Usually `FRandomStream`
Named independent gameplay RNG domains	Probability Director
Random sequence must resume after save/load	Probability Director `PersistState`
Same semantic decision must survive unrelated call-order changes	Probability Director Keyed decision
Successful saves should rotate a committed random generation	Probability Director `RotateOnSave`
Secure runtime randomness	Probability Director Secure stream
Random behavior must be inspected/debugged centrally	Probability Director
Integrated Dice/Probability/Distribution/Markov/Name systems	Probability Director
SaveGame Director orchestration	SaveGame Director plus optional DirectorBridge Probability.SaveGame

17. Recommended Rule of Thumb

Do not replace every Unreal RNG call merely because Probability Director exists.

Use the smallest tool that provides the guarantees the gameplay feature actually needs.

A useful rule is:

Use ordinary Unreal randomness for local, disposable randomness. Use Probability Director when randomness becomes part of the game’s deterministic, persistent, inspectable gameplay architecture.

That distinction keeps simple systems simple while giving important gameplay systems stronger guarantees where they matter.