Oh, it's easy! You make a randomizer for a game, because you're doing any% development, you set up the seed file format such that each line of the file defines an event listener for a value change of an uberstate (which is an entry of the game's built-in serialization system for arbitrary data that should persiste when saved).
You do this because it's a fast hack that lets you trigger pickup grants on item finds, since each item find always will correspond with an uberstate change. This works great! You smile happily and move on.
There's a small but dedicated subgroup of users who like using your randomizer as a canvas! They make what are called "plandomizer seeds" ("plandos" for short), which are seed files that have been hand-written specifically to give anyone playing them a specific curated set of experiences, instead of something random. These have a long history in your community, in part because you threw them a few bones when developing your last randomizer, and they are eager to see what they can do in this brave new world.
A thing they pick up on quickly is that there are uberstates for lots more things than just item finds! They can make it so that you find double jump when you break a specific wall, or even when you go into an area for the first time and the big splash text plays. Everyone agrees that this is neat.
It is in large part for the plando authors' sake that you allow multiple line entries for the same uberstate that specify different actions - you have the actions run in order. This was a feature that was hacked into the last randomizer you built later, so you're glad to be supporting it at a lower level. They love it! It lets them put multiple items at individual locations. You smile and move on.
Over time, you add more action types besides just item grants! Printing out messages to your players is a great one for plando authors, and is again a feature you had last time. At some point you add a bunch for interacting with player health and energy, because it'd be easy. An action that teleports the player to a specific place. An action that equips a skill to the player's active skill bar. An action that removes a skill or ability.
Then, you get the brilliant idea that it'd be great if actions could modify uberstates directly. Uberstates control lots of things! What if breaking door 1 caused door 2 to break, so you didn't have to open both up at once? What if breaking door 2 caused door 1 to respawn, and vice versa, so you could only go through 1 at a time? Wouldn't that be wonderful? You test this change in some simple cases, and deploy it without expecting people to do too much with it.
Your plando authors quickly realize that when actions modify uberstates, the changes they make can trigger other actions, as long as there are lines in their files that listen for those. This excites them, and seems basically fine to you, though you do as an afterthought add an optional parameter to your uberstate modification action that can be used to suppress the uberstate change detector, since some cases don't actually want that behavior.
(At some point during all of this, the plando authors start hunting through the base game and cataloging unused uberstates, to be used as arbitrary variables for their nefarious purposes. You weren't expecting that! Rather than making them hunt down and use a bunch of random uberstates for data storage, you sigh and add a bunch of explicitly-unused ones for them to play with instead.)
Then, your most arcane plando magician posts a guide on how to use the existing systems to set up control flow. It leverages the fact that setting an uberstate to a value it already has does not trigger the event listener for that uberstate, so execution can branch based on whether or not a state has been set to a specific value or not!
Filled with a confused mixture of pride and fear, you decide that maybe you should provide some kind of native control flow structure that isn't that? And because you're doing a lot of this development underslept and a bit past your personal Balmer peak, the first idea that you have and implement is conditional stops, which are actions that halt processing of a multiple-action-chain if an uberstate is [less than, equal to, greater than] a given value.
The next day, you realize that your seed specification format now can, while executing an action chain, read from memory, write to memory, branch based on what it finds in memory, and loop. It can simulate a turing machine, using the uberstates as tape. You set out to create a format by which your seed generator could talk to your client mod, and have ended up with a turing complete programming language. You laugh, and laugh, and laugh.
