Dialog Tutorial: Difference between revisions
No edit summary |
No edit summary |
||
Line 5: | Line 5: | ||
The answer is pretty simple: think of an event as a series of facts, such as a player who was involved, their name, and so on. Each fact has a name or ''key'', and a value eg. the player's name might have a key of "name" and a value of "fullwall". An event is simply a whole lot of facts about what happened. This makes it much easier to reason about in text. | The answer is pretty simple: think of an event as a series of facts, such as a player who was involved, their name, and so on. Each fact has a name or ''key'', and a value eg. the player's name might have a key of "name" and a value of "fullwall". An event is simply a whole lot of facts about what happened. This makes it much easier to reason about in text. | ||
This approach also makes it easy to associate more facts with an event; this group of facts is known as a ''query''. A query can also have information about the world state, any memory that the NPC has picked up, and more. | |||
Now we have a nice collection of facts - what do we do with them all? Time to introduce two new concepts: ''rules'' and ''responses''. The final flow looks like this: event -> NPC -> generate facts -> dialog system -> rules. | |||
==Rules== | |||
A rule takes in a query and checks it against a list of criteria. If it matches, it does something. For example in a chat event, it may check if the player's name is "fullwall", and then say "Hello, fullwall!" to the player. Rules are simple, yet can be combined to create complex interactions. | |||
==Responses== | |||
A response is basically a list of commands; it has no criteria, but can be called from many different kinds of rules. |
Revision as of 09:39, 30 January 2013
In this tutorial, you will learn the basics of the dialog system syntax, and the concepts involved.
Overview
First, let's look at the basic flow of a dialog program. The world of Minecraft can be broken up into a series of events. These are things like talking, combat, block breaks, and so on. The general flow looks kind of like this: event -> listener. This isn't easy to represent in text. How do we make a nice system out of this?
The answer is pretty simple: think of an event as a series of facts, such as a player who was involved, their name, and so on. Each fact has a name or key, and a value eg. the player's name might have a key of "name" and a value of "fullwall". An event is simply a whole lot of facts about what happened. This makes it much easier to reason about in text.
This approach also makes it easy to associate more facts with an event; this group of facts is known as a query. A query can also have information about the world state, any memory that the NPC has picked up, and more.
Now we have a nice collection of facts - what do we do with them all? Time to introduce two new concepts: rules and responses. The final flow looks like this: event -> NPC -> generate facts -> dialog system -> rules.
Rules
A rule takes in a query and checks it against a list of criteria. If it matches, it does something. For example in a chat event, it may check if the player's name is "fullwall", and then say "Hello, fullwall!" to the player. Rules are simple, yet can be combined to create complex interactions.
Responses
A response is basically a list of commands; it has no criteria, but can be called from many different kinds of rules.