samedi 27 août 2011

Sharing research code

I started to set my research code public. This will allow the interested people to understand how I progress on the prototype implementation and how it relates to the ideas exposed in this blog.

The code (under the GNU GPL v3 license) can be found on: http://code.google.com/p/dramaticgames/

Prototype screenshot

The current prototype is extremely simple and primitive; it’s just a text based key/door puzzles JIT synthesizer. You can just click on buttons to do three possible actions: move to room, pickup keys and open doors. The implicit goal is to visit each room of the house. At each program execution, the doors will be locked differently. The keys’ locations also change at each run. The goal of this prototype was to grasp the first Quantum Physics inspired paradigm to create a JIT synthesizer for the game “opposition”.  I also played a bit with rules (in DramaManager) to increase the interest of the generated puzzles.

This prototype is implemented in Lua and use wxLua as a GUI. If you want to try the prototype, you will have to first install wxLua.  Then launch MainDev.lua from wxlua.exe.  To have it running, you will also have to change the gRootPath in MainDev.lua

Unfortunately, most of the sources are in a flat directory structure. This is done to be able to later use the code on Android devices with, for instance, the Corona SDK.  Actualy, Android constraints directories structure (dixit Corona documentation).  However, it’s possible to see the sources in a directory tree by using the .projet file with the Eclipse IDE.  I recommend Subversive as a way to get the project in Eclipse because other SVN integrations break the virtual folders. There are also plugins for Eclipse to get Lua support. Install Eclispe and the plugins then do an "File->Import->SVN->Project from SVN". You can also use TortoiseSVN to just checkout the sources outside of Eclipse.

In the docs directory, there is a yEd file named Classes.graphml that describes the interesting classes of the system.  The prototype being currently evolving toward most advanced concepts, some “Mind” related classes already exist but are not yet used.

Here is a list of the interesting packages of the project:


  • DevViews implement the wxLua views
  • Reality implements the base classes that use the Quantum Physics metaphor
  • Matter implements classes derived from the ones present in the Reality package to specialize them as physical objects
  • Spirit implements classes derived from the ones present in the Reality package to specialize them as spiritual objects such as Mind…
  • Drama implements the rules to bias the entity collapsing to get a more interesting experience. This is mostly about pace management.
  • Test implements the unit tests

Don’t hesitate to comment this post to ask questions and discuss about ideas.

vendredi 19 août 2011

Does the past exist yet?

Two weeks ago, I finished a first prototype of a key/door puzzles generator using some quantum physics paradigm to drive the states of keys and doors at observation time. This proved me that it was possible to synthesize (JIT) a big part of a game world while keeping it interesting and procedurally generated.

Now, I would like to extend this idea beyond simple key/door puzzles.  To achieve that, i need to add NPC and behaviors to the mix.  The big change is that NPC behaviors imply causality, that is to say: cause and effects.  Here is a causality example in the context of my crime investigation prototype: the murderer NPC wants to steal evidences on the crime scene (cause) but he is spotted by the player that just happen to be also there. The murderer flees (effect).  This simple example shows how the player can use causality reasoning to get clues on the murder and to use them progress in his investigation.  In this example, the NPC that arrives on the crime scene, and that all of a sudden flees, instantaneously becomes suspect for the player.

If we try to implement this example, we will quickly run into a big problem:  
if the murderer NPC have a standard goal oriented IA, how big are the chances that he would arrive on the crime scene to steal evidences when the player just happen to be also there ?  The chances for this coincidence are actually very low.  However, those story-pushing coincidences happen all the time in non interactive stories such as TV series and movies.
 
In regard to this problem, it’s important to define two notions:

1.       “Player Centricity” is the fact that the interesting events (the murderer fleeing the crime scene) happen when the player is there to observe them and to interact with them.  This is what happens all the time in non-interactive stories and this is what we would like to implement.

2.       “Agent Centricity” is the fact that the NPC AI acts in accordance to their own needs and goals (agency) and not in accordance to what would be the best for the player experience. In our example, chances are high that the murderer NPC would be doing something else when the player decides to quickly visit the crime scene.

Player Centricity is achieved in games by scripting. The “Call of Duty” series being one of the best example of this principle.  Unfortunately, this has to be implemented in a linear way to insure NPC behavior causality chain coherence.

In less scripted games, Agent Centricity allows NPC AI to have coherent “cause and effect” chains in a nonlinear way.  But then, the problem is that very interesting things are done by NPC AIs but are never noticed by any players because those events are not happening while the player is watching. This is one of the most frustrating issues for squad based combat AI developers ;-)

For DramaticGames, what I would like to implement, is a mix of both Player Centricity and Agent Centricity.  Here is how it could work:

  1. Each NPC has a special AI that generates all the simplified plausible behaviors that they can potentially have at the current moment, while they are not observed. This Potentiality-AI generates a “potentiality tree” quite similar to traditional AI goal trees.  The main difference is that all the “plausible” behavior’s branches stay active at the same time.  In our example, that means that our murderer NPC potentially does many things at the same time to vindicate oneself when he is not observed by the player.  For instance: hide, corrupt or frighten witnesses, steal evidences on the crime scene, etc…  All that, "happening" in parallel (thanks to Quantum states superposition).

  2. The DramaManager AI changes the probabilities of some potential NPC’s behaviors in accordance to the player context and to predefined dramatic rules.  In our example, the DramaManager strongly increase the probability of the murderer potential behavior that consist of stealing evidences on the crime scene when the player arrives there.

  3. When the player interact with the story world, the entity he interact with “collapse” (in the Quantum Physics way of thinking).  In our example, when the player arrive on the crime scene, the system looks at all NPC potential behaviors that involve the crime scene and “collapse” them as being the current NPC behavior or not.  The criterions to collapse a behavior depend of a statistical selection process (random driven) integrating the probability weights set by the DramaManager AI.

  4.  If a behavior collapsed as being the current one for an NPC, the NPC Potentiality-AI is temporarily mutated into a classical Reactive-AI.  This allows the NPC to interact in a regular way with the player that now observes him.  During the AI mutation, the collapsed potentiality branch is expanded as the current goal branch of the standard Reactive-AI. 

    On a side note, the mutation of potential past behaviors into a real present behavior inspired the title of this post:  ”Does the past exist yet?”.  Indeed, the described mechanism maintains all the plausible NPC simplified pasts and “chooses” one at observation time to expand it, thus defining the NPC in present time.  If we integrate the fact that the DramManager AI biased the weights of the past behavior possibilities to insure the present behavior it preferred, then this can be seen as an approximation of retro-causality.

  5. Finally, each NPC that are in Reactive-AI mode will be mutated back in Potentiality-AI mode after a given time of non-observation by the player.   So, the system must be capable to do bidirectional translations between simplified Potentiality-AI and expanded Reactive-AI.


I think that the superposition of unseen NPC behaviors creates a kind of “behavioral and causality backstage”. This allows us to implement a DramaManager that is “free” to bias NPC behaviors in the back of the player.  This allows us to mix and statistically arbitrate Player Centricity with Agent Centricity.

This seems to be an interesting paradigm to test. However, things can rapidly grow in complexity, especially when the potential behaviors involve NPC to NPC interactions and relationships.  But the good news is that now, we have a lead to reconcile player autonomy and experience intensity…

jeudi 11 août 2011

Criminal investigation tycoon

In my previous posts, I speak a lot about what I call the “story engine”.  It must be noted that this engine is just a design metaphor and have nothing to do with runtime game engines.  The story engine can be seen as what Dramatica names the “Overall Story Throughline”; or what McKee names the “Central Plot”. This is the backbone structure of the player experience. The goal is to have the player know what he has to do to push the story forward.

The best way to explain what I mean by “story engine” is to show an example diagram. In this case, the example depicts a murder investigation “dramatic game” (that will be my first implementation prototype):

It is important to notice that the story engine is an abstract model of the player experience. It doesn’t specify the name nor the number of entities (objects, characters, locations, information…) nor the order of the needed interactions.  The transformation of this abstract model into a concrete experience is done at player observation & interaction time, by the “quantum uncertainty” inspired system. This system use control rules to collapse the possibilities into a unique reality. This paradigm insure, amongst other things, the player freedom (order of actions) and the optimality of the dramatic experience (player centricity).

The story engine is a real gameplay system. The most prominent feature demonstrating that, is the “proofs points” system.  Indeed, the player has to accumulate “proofs points” from different sources to pass a given threshold where the Judge will decide to incriminate the given suspect and thus end the game in a winning condition.  It must be noted that it doesn’t exist a losing condition.  The player can continue as long as he wants to gather proofs points.  The proofs points also support the non linearity of the experience because they can be gathered in any order, and this from the source that the player will want to focus on.  

As this model mostly involve non physical entities (information, relationships, investigation states, …), it is extremely important to find a proper way to render those concepts to the player. To achieve this, I think that I will use an elaborated dashboard system that will display all the immaterial concepts.  This dashboard will include a structured notepad that will automatically log known information. It will also feature detailed and specific reports. Finally, it will include a big board that will show all the characters and objects with their respective relationships (as in real criminal investigations).

Another important problem to handle is the difficulty level of the experience. That’s why, at the beginning of the game, the player will select his desired level of difficulty.  This difficulty level will be used by the “uncertainty collapsing” mechanism to control the deepness of dependencies and the number of entities in the game.

This “crime investigation model” is quite simple but, with time, will be extended to include: victim body searching, complicities, denunciations, lies, secondary murders or kidnapping to eliminate witnesses, evasions, evidences stealing or destruction, political game, witness reversal, etc…  As TV criminal dramas show, this field is quite vast.  The story engine will also try to add a maximum of NPC behavior triggering, to leverage the information-relationship-behavior economy.

The specificity of this story engine approach is that it deeply simulates a domain specific model. It doesn’t rely on a story surface generative grammar.   Even if we can nearly feel the experience as an episode of “Law & Order” :-)   this model does not yet produce dramatically interesting experiences. To achieve that, we will have to include many other key elements, such as: interesting key characters, a “thinking villain”, some interesting conflicts, a lot of emotions and last but not least: meaning.  But now, we have a nice support for all these things…

samedi 6 août 2011

Toward a behaviors economy

One of the main challenge to tackle to achieve a dramatically interesting game is to extend the classical object economy found in games. Here is a simplified diagram that represents such an object economy:

Click to enlarge

Off course, object economies are far more elaborated in current games. They also include some information and behavior economies.

Here is what I will try to implement for my DramaticGames experiment:

Click to enlarge

The huge difference with economies found in current games is the fact that this one is generalized; this means that the DramaManager AI can manipulate it as it wants to enhance the player experience.

Another difference is the fact that relationships and the way to change them are multiple. So, the goal of the game is not finding how to get the good actuator but: what actuators will be the best ones and why?

This economy is just one part of the equation. The other part is the “thinking” villain, the dynamic opposition that will transform the experience from being a puzzle to being a competition with the game antagonist…