Start Page » Game Development with the Drag[en]gine » Drag[en]gine Integrated Game Development Environment » Conversation Editor
The conversation editor allows to create conversation resources for your game. Conversation resources are *.deconvo files defining dynamic conversations. Complex dynamic conversation can be created with this editor.
Conversation resources compose of a list of Topic Groups. Topic groups allow to organize conversations in a conversation file by groups of related topics. The developer can name the groups whatever fits his purpose. Each topic group then contains a list of Topics.
A topic is the actual conversation script played back by the game engine. Topic groups can have any number of topics. Conversation scripts are similar to movie scripts. They compose of Conversation Actions played back one after the other. In contrary to timeline based approaches the movie script based approach allows for better control of dynamic conversations where the actual length and spacing between actions can vary. Furthermore it makes modifying conversations easier since no re-timing or re-aligning along a timeline is required.
Conversations can play back with any number of Conversation Actors attached to the conversation. Actors can be added and removed any time during the conversation. Only limitation is that an in-game actor can be only attached to one running conversation at all times. If you need to control actors from different conversation scripts use Game Command actions. Conversation actors are identified in the conversation script either using their index (first actor is actor 0, second actor is actor 1 and so forth) or using one of their names. Each conversation actor is required to have a unique name which never changes. In addition while adding a conversation actor an Alias Name can be assigned. This allows to identify a conversation actor in the conversation script by a pre-defined name no matter what actor is attached to this alias name in the end. A typical example is to add the conversation partner actor always with the alias “npc” no matter what kind of NPC the player talks too. Otherwise you would have to deal with all possible unique conversation actor names. Using alias names is recommended. Unique names is best used to identify a specific unique actor. Actor indices are not recommended.
Conversation resources are no engine resources. See the scripting language of your choice for how to load and use a conversation resource in your game.
Conversation playback is handled by a game script provided by the chosen scripting language. Before starting a conversation the user has to add Conversation Actors taking place in the conversation from the beginning. Additionally the user can set Conversation Variables. Conversation variables are integer variables the conversation actions can read and modify. This allows to modify the behaviour of conversation scripts or to check the outcome of a conversation. Once all is ready the conversation playback starts by specifying a Conversation Group and Conversation Topic. Once the playback finishes a playback callback or listener is called to allow the game scripts to take the next actions.
Conversation actions provide the basic steps in a conversation script. For details see the Conversation Actions page.
Conversation conditions provided support to evaluate a composed condition for use in branching actions. For details see the Conversation Conditions page.
Targets are used in different places in the conversation to define a point in space. They are identified using a unique identifier. Targets have a Position and Orientation relative to the target. The orientation is applied before the position. Targets are relative to a Conversation Actor or a Coordinate System.
Using an Actor Index or Actor Name (matching either Unique Name or Alias Name) the target is relative to a conversation actor. The actor has to be present in the conversation for this target to work. If the actor is missing the position is set relative to the game world. If Bone is used the target position is relative to the specified bone in the actor. The name of the bone has to match the name of a bone in the Rig used in the actor in the game world. The game scripts can though apply a different logic to the meaning of the bone parameter for example using it as a type name to target a specific area on an actor. If the bone name is not understood by the game scripts the actor location is used as if no bone has been specified.
Using a Coordinate System Identifier (matching either Identifier or Alias Identifier) the target is relative to a conversation system. The conversation system has to be present in the conversation for this target to work. The Bone parameter is ignored for coordinate system targets.
Camera shots define parameters for dynamic camera handling while active. Camera shots are identified using a unique identifier. They modify the Conversation Camera behaviour over the duration of their shot. Various camera parameters can be set. Each parameter has a Start and End value. During the camera shot the parameter is linearly interpolated between the start and end value. Once past the duration the parameters stay at the end value. The following parameters are supported:
The Camera Shot Action defines the Targets used as camera target (gives the camera mount point) and look-at target. There are some additional parameters to alter this behaviour:
Defines a look-at usable in the conversaion. Look-Ats are identified using a unique identifier. Each look-at defines the Target it is using. Different look-at can point to the same target.
Defines a face pose to use on actors. Face poses are identified using a unique identifier. Each face pose has a set of Controllers indicating the blending of different facial states.
Defines a gesture to use on actors. Gestures are identified using a unique identifier. Each gesture has an Animator Identifier to be send to the game script to pick the right animator for use by this gesture. The interpretation of the animator identifier is game specific. The optional Hold parameter can be used to hold the gesture after the duration. If not set a gesture finishes after the duration it is played over. Using hold is required to create looping gestures that can be held until another gesture blends over it.