Adventures: Difference between revisions

From Citizens Wiki

(Created page with "== Dialog ==")
 
No edit summary
Line 1: Line 1:
== Dialog ==
== Dialog ==
Adventures uses a modified form of the Valve dialog system outlined in [http://www.valvesoftware.com/publications/2012/GDC2012_Ruskin_Elan_DynamicDialog.pdf this presentation]. This allows very dynamic and extensible dialog to take place. A more readable explanation follows.
Concepts:
Dialog is built up of ''rules'' and ''responses''. A rule is simply a list of criteria represented as key-value pairs. For example, one criteria may be that health is above 10. The key would be 'health' and the value would be 10. Rules listen for events, such as player chatting or seeing an entity, or... anything that can be implemented, really. The events have certain facts that are combined with the NPC's facts and memory to create a query. The query finds the rule with the highest number of matching criteria.
When a rule is being executed, it calls a number of different statements. In most cases, this will be a form of response, which is defined separately. This will in turn call a number of actions like talking etc. Where it gets interesting is the 'callbacks' where you can specify what happens afterward. For example, you may trigger another event for further rules to be executed, set memory so varied rules can be matched, and so on. This makes self-branching conversation much easier - the same system was used in Left 4 Dead to create engaging character banter.
Samples:
rule RuleName {
    criteria events=onchat,onjump health=10 name="fullwall" SaidHi=false;
    response SayHi;
    remember SaidHi=true;
}
response SayHi {
    chat "Hi, fullwall!" then any onsaidhi;
}

Revision as of 15:10, 26 December 2012

Dialog

Adventures uses a modified form of the Valve dialog system outlined in this presentation. This allows very dynamic and extensible dialog to take place. A more readable explanation follows.

Concepts: Dialog is built up of rules and responses. A rule is simply a list of criteria represented as key-value pairs. For example, one criteria may be that health is above 10. The key would be 'health' and the value would be 10. Rules listen for events, such as player chatting or seeing an entity, or... anything that can be implemented, really. The events have certain facts that are combined with the NPC's facts and memory to create a query. The query finds the rule with the highest number of matching criteria.

When a rule is being executed, it calls a number of different statements. In most cases, this will be a form of response, which is defined separately. This will in turn call a number of actions like talking etc. Where it gets interesting is the 'callbacks' where you can specify what happens afterward. For example, you may trigger another event for further rules to be executed, set memory so varied rules can be matched, and so on. This makes self-branching conversation much easier - the same system was used in Left 4 Dead to create engaging character banter.

Samples:

rule RuleName {
    criteria events=onchat,onjump health=10 name="fullwall" SaidHi=false;
    response SayHi;
    remember SaidHi=true;
}

response SayHi {
    chat "Hi, fullwall!" then any onsaidhi;
}