a11ce.com/gigamuru-1.html
Fictional characters have started taking actions in the real world. What are they, and how did they get out?
A simulator is defined by the shape of its state at a given time and a rule to transform any state into the next one. To run the simulation is to repeatedly apply the step rule to its own output, and to interact with it is to apply modifications to the state in between simulated steps.
For example, consider Dwarf Fortress. The simulation state includes the local terrain, items (including their states and locations), and the internal state of the dwarves. Repeatedly applying the step rule makes these dwarves move around, use items, and make decisions based on their goals and priorities. The player, who exists outside the simulated world, can issue orders, which enter the simulation state as tasks to be taken up by the dwarves.
Simulators are inherently autoregressive in that the step rule produces a new state to which the step rule may be applied again. However, the step rule does not 'know' (or care about) the actual source of the state it acts on. The state may have been produced by a previous application of the step rule, or produced and then modified, or fabricated wholesale. ¹¹For example, the initial state of the world after map generation, which could be a different simulation or a non-simulating process.
A simulated character is an actor ²²A dwarf, an animal, even an entire neighboring kingdom depending on the resolution of the simulation. within the simulation, stepped according to its own simulator-represented internal state. For example, the internal state of a dwarf includes hunger, which influences the dwarf's future actions towards eating food. Internal state is information that may affect the behavior of the character during a step, but doesn't directly affect other parts of the step computation.
Splitting out a particular dwarf (let's call him Urist) from the full simulation state around him lets us talk about characters separately from their settings. You could write a story about Urist set in your fortress, or play him in D&D. You could even recast him as a modern office worker, with no memory of his other life under the mountain. Just as an author or role-player chooses Urist's actions based on his enduring traits and some representation of his internal state, so too does a simulator. He is recognizable as Urist each time, regardless of whether his actions are described by an author, role-player, or simulator. In this way, a simulated dwarf is the same type of thing as a dwarf in a story: a fictional character.
First, consider an actuator that fires a real gun whenever Urist eats some bread. Urist's behavior now has real-world consequences, but he is not meaningfully acting in the world.
Next, switch the actuator out for a moving robot with a sword, and place the robot in a 1:1 recreation of your fortress. Urist goes about his day, with the robot following along, and when the goblins attack, the robot swings at empty air. This looks more like Urist acting in the world, but the only thing that changed was the accuracy of the mapping. Mechanically, it's still a fully external process observing the simulation and mirroring it in real life.
Finally, add feedback. Observe everything in the real-world replica, map it to a simulation state, and step, projecting Urist's actions back out onto the robot. Urist is hungry, the robot goes looking for real bread. You attack the robot, Urist feels pain and strikes you back.
Suddenly, it looks a lot like Urist just attacked you with a sword in real life.
What happened here? The simulated character is still simulated, and even the simulator can't tell that its inputs come from the real world. It is up to the surrounding system (the cameras and robot) to map the real world to the simulation state and to interpret and apply the actions of the simulated character. Urist never actually reaches up into the world, it is always the world looking down.
You can respond to this page on twitter, substack, mastodon, or bluesky.