Seeds and repeatable randomness

Optional

A seed is a text value that makes random results repeatable. The same seed gives the same world, as long as the procedure that uses it is Fixed. A draw is one request for the next random value. A seed address names one random sequence and the place it is used, so different parts of the game draw from separate sequences. In the example below, {seed} stands for the seed of this run and {n} for the floor number.

03-content.md, where the floor generator is described

Every floor draws its layout from the seed address {seed}:floor:{n}:stream:layout. Here n counts floors from 1 at the entrance and never goes negative, and the stream's draws are consumed in room order, outward from the stairs.

So n is the floor number, starting at 1 at the entrance, and the generator takes random values room by room, starting at the stairs.

A seed contains no colon (:). Colons separate the parts of a seed address.

When you need seeds#

Seed addresses are optional, and they are a testing tool. They help when a test must get the same layout in different builds. Replaying a run inside one build is the builder's job, so you do not need to write anything for it. Players normally do not see seeds: a game shows a seed, or lets the player enter one, only when your design asks for it.

What you write#

The format defines one random algorithm for every build. The same seed and seed address give the same sequence in every build, as long as the procedure that uses them is Fixed (the builder follows it exactly). When you declare seed addresses, your chapter defines what each one means. For each one, state:

what labels such as floor and layout mean;
what each number counts, and whether counting starts at 0 or 1;
whether coordinates may be negative;
which game events request draws, and in what order.

These statements stay in your prose. There is no separate JSON file for them.

Seeds in tests#

A general acceptance test lists its seeds in its seeds field. The builder's report of the build says which general tests were sampled instead of fully checked. The Acceptance tests chapter shows a general test with seeds.

If the generating procedure is Delegated (the builder decides how it works), different builds may produce different worlds from the same seed. Keep it Fixed when every build must reproduce the same world.

Full rules: OpenGDD specification, §2a and §6.