Action handling roadmap discussions

Action management

Handling actions individually will sometimes be necessary but mostly it is much more cumbersome than necessary. Therefore we need a way to group/classify actions so that they can be dealt with in bulk.

Questions:

• Could each action have multiple groups?

Driving actions from outputs

Actions should be able to be automatically chosen and modified to fit the output of an agent. Eg. the speed of an agent should change the speed of a walk cycle. Or if the agent speeds up then blend the actions into a running animation.

Questions:

• How does the user specify which actions go with which output. Could it be done automatically? From the changes in location and rotation in the second action?

• For actions that transition out of the current state how does the user specify which is the next state if there is more than one transition out of each state.

Action synchronisation

To make an effective crowd simulator the agents need to be able to interact effectively. Currently the agents can interact at a distance be there isn't any way to synchronise actions so that they can interact by "touch". This page is here to start collecting ideas and because in doing so it may help to decide how to proceed with other work relating to the action playback system.

Goals:

• Should act within the same system used to playback all the other actions.

• Doesn't require too many nodes to use but at the same time the artist should retain control

• Agents should be able to remain "aware" of what's around them and not get locking into long sequences of predefined motions

• Deal well with large numbers of motion clips and the even larger number of combinations they can be paired in (to the point where motion capture could be used to generate 10s of different attacks for a fighting agent and a similar number of defences and it would be feasible to have these all used without the brain graph becoming impractically huge).

• Give the option to accurately align agents so important contact points are correct (eg. two agents handshaking should have their hands properly align). This could potentially be achieved with more nodes in the brain graph however it would be fiddly, time consuming and difficult to understand by someone looking at a pre-assembled brain.

• Maybe too ambitious but it would be nice if actions could be chosen and synchronised between several (ie. more than 2) agents simultaneously.

Potential solutions

(The solution is likely to be a combination of many of the ideas suggested so each suggestion can potentially address a smaller issue)

• SYNC node - Have a new state node which takes over and does all the work. Disadvantages: Very little control, does the other agent just jump into the SYNC node when another nearby agent does?

• Output to tags - Output details of the animation into tags. Disadvantage: Would lead to extremely complex brain graphs if used on it's own.

• Master/Slave vs Cooperating - Master slave could possibly be simpler but how is master chosen?

• Message passing - Possibly implemented by allowing agents to set other agents tags. Agents "tell" each other what they are about to do. Or maybe they broadcast when they want to be master but how do we deal with clashes?

Proposed solution

• The user defines pairs of actions which could include actions (what if an action and group share the same name?).

• Each action pair can have a relative offset (pos and loc) which can be used to adjust agents to properly align while performing actions.

• Sync option for Action and Action Group nodes.

• Any state that is a sync state will become active when connected to the output of the current state. When active it will "Tell" any agents passed to it's value input which action it can go to next.

• At the end of each frame the SyncManager looks at all the agents and resolves which sync actions (if any) should be moved to in the next frame.

• The SyncManager (SM) looks at each pair of agents (y, z) that have told each other actions (eg. values in "z tells y" and "y tells z"). If only one agent tells then that pair is ignored. For each action (a) told from y to z (YToZ) the SM looks up the paired action (p). If p is in what z told y (ZToY) then the values associated with a and p are multiplied. The pair of actions between y and z with the highest score are added to a list of possible actions ( (y, z), (a, b), YToZ[a] * ZToY[b] ).

• The list of possible actions is then sorted by the last value. Working from largest score to smallest the SM looks at which agents each possible action refers to. If either have already been assigned an action then this possibility is discarded. Otherwise the two agents are set to move to the given actions during the next frame and the agents are marked as having been assigned sync actions for this frame.

• For example:

    Action pairings : {"attack":"defence", "defence":"attack", "kill":"die", "die":"kill"}
  
    z tells y : {"attack":0.6, "defence":0.2, "kill":0.1, "die":0.0}
    z tells x : {"attack":0.5, "defence":0.5, "kill":0.0, "die":0.0}
    x tells z : {"attack":0.9}
    y tells z : {"attack":0.1, "defence":0.9}
  
    Possible pairs:
    ( (z, y), ("attack", "defence"), 0.54 )
    ( (x, z), ("attack", "defence"), 0.45 )
    
    ( (z, y), ("attack", "defence"), 0.02 ) was also possible pair but 0.02 < 0.54 so this one is ignored.
  
    Each action is inspected in turn:
  
    z and y haven't been seen before so "attack" is assigned to z and "defence" to y.
    z has already been seen this frame so this pair gets discarded.
  

• While sync actions are being played the SM can move the agents to properly align them? (can decide exactly how this works at a later time)