How do you *accidentally* make a programming language?

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.

accidentally sent an ask early, I was almost finished but it ended mid-sentence. I was talking about one of my OCs, Theo. He has sensory issues with the fit of things texture, foods and fabrics. I’m thinking things being tight might freak him out so I wanted to know what kind of hairstyle I should give him that would realistically not bother someone with sensory issues.

sorry the previous ask probably sounds a little choppy bc I hadn’t read it over yet so you can just ignore it if you like

See, I'm about to do it- im about to suggest having a short afro! It can't touch your neck if it never reaches it! No need to put on headbands to push it back when it can't grow that long to touch your forehead (and you're not using it for fashion)!

Plus, there's all sorts of cool hairstyles and cuts you can get with a regular fro.

Now, as for how he'll care for his head when he's averse to most fabrics, if he doesn't like satin or cloth for bonnets, he could do durags- he'd just have to fluff his hair out when he takes it off, which is fine if that's something he has time or wants to do.