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.

What you write#

The format fixes the random algorithm. 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). Your chapter defines what each seed address 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.