vendredi 9 septembre 2011

Entanglement and retro-causality

I would like to (try) to explain you the most difficult concept I have recently wrestled with in the context of DramaticGames. That is to say: Entanglement, or keeping causally dependent non-collapsed entities and behaviors in synch.
A definition of entanglement can be found here, but it can be summarized as the link that keeps in synch two non collapsed particles that have potentially interacted with each others. For instance, a non collapsed electron (superposed at multiple places) that potentially have collided and bounced from another non collapsed electron (also in states superposition).  As the two electrons are entangled, when one will collapse by being observed, the other electron will also collapse in a position that, some time, will be influenced by the potential collision that virtually occurred.  Actually, it’s collapsing post synchronization, or a form of retro-causality. This phenomenon is proven experimentally.

To explain entanglement in the context of DramaticGames, we first need to explain what a behavior is. We will take the example of the behavior of the murderer (the Perpetrator) in the context of our previous criminal investigation game example. This behavior could be represented by a classical goal tree as follow:


We see that the murder has a dynamic behavior to “oppose” to the player that investigate the criminal case. This is what I previously named the “Thinking Villain”. This mechanism insures that the game is a dynamic interactive experience and not a static puzzle.

This goal tree example shows a classical reactive behavior, with goals and sub goal triggered by conditions to be matched against the current beliefs of the Perpetrator.  This is the classical way of doing AI.  However, what we want to achieve is completely different; we want to do retro-causality as explained is my previous post: “Does the past exist yet?”.  To do so, we need to implement what I call a “Potential-Goal trees”. Here is the previous reactive-goal tree restated as a potential-goal tree:

Click to enlarge, then save the image for a better viewing experience in an external image viewer


You will notice three changes:
  1. The conditions are now named causes
  2. The leaf goals are named effectors and have an effect definition
  3. Most sub goals have been defined as “generic” goals using goal variables definition. This is not related to retro-causality because, for the sake of generic representation, this is also done in reactive goal trees.


Now, the difficult part is explaining how it all works J
Here is the same potential-goals tree but with a retro-causality process example:

Click to enlarge, then save the image for a better viewing experience in an external image viewer


This is quite difficult to grasp because it is counter intuitive.  The good news is that entanglement seems enough to avoid the many world interpretation of Quantum physics that would have been cumbersome to implement in a story world.  It must also be noted that things can get even more complicated when we consider that different potential-goals tree can be entangled together, to represent “joint intentions”, when one character potentially interact with another one.

Before getting to this complexity level, let’s try to implement basic entanglement and retro-causality in a prototype…

2 commentaires:

  1. Hello nice stuff!
    So far my comment was really about having details about the structure and the scope.

    I'm designing something similar for infinite but dynamic world outside the event horizon of the player with two difference: "hammerspace (inside the fog of war)" and "event demon" to reduce complexity. I didn't expect you to go that simulationist unless I misunderstand.

    Basically I skip evaluating the other concurrent branch, I only evaluate based on "drama target" the current event and evaluate the return path to the root when necessary (event is selected for spawning), the return path is then check for "plausability" (based on current event and some stored fact based on event framing) and node with low plausability run through "event demon" to help them happen. Basically An event demon create cause and explanation necessary to the drama when request (for example a taxi driver strike to slow down a main character). It don't explain everything, only thing that are crucial to the player. And also the more the world is implied outside the player agency the easier for the system to work (the player might assume that in a city people use taxi to travel, in movie it is implied through ellipse who don't show mundane act and allow leap of knowledge too). Of course even when the explanation is not found the path is not necessary invalidate (the drama manager decide) leaving a plot hole. Story are full of plot hole and deus ex machina, the less they are direct, the more the story feel consistant and the less deadlock the author have to create a meaningful emotional ride.

    However two thing I found missing while running my model and is a bit tricky with such tricks, good story rely a lot on forewarning, obviously forewarning exist when the future actually already exist, but when the future is not decide yet how do we deal with that? In game terms it would be a feedback system (a tell) that lead to an event we need to deal with, but in story it can be cryptic and only an emotional device to set a future change of tone or event.

    RépondreSupprimer
  2. Hi Timmy,

    Thanks for your nice comment.

    I go to the simulationist way to keep coherence between NPC behaviors, especially for the relationship economy gameplay. That’s said, I relax the coherence constraint when the retro-time is increasing (rerto-causaly created events that are further in the past). That why, in my schema, I introduce the notion of “functional distance” when I check the entanglements of entities and goal effects.

    I could also decide to give priorities to DramaManager Intentions to relax even more the entanglement constraints to create Deus Ex Machina when it is “suitable”.

    About foreshadowing, you raise a very good point that I never thought about. I suppose that the DramaManager must also do Intention speculative planning in addition to pace management and dramatization (conflict tracking…)? I will have to think about that :-)

    RépondreSupprimer