The Dynamic Response System (DRS) is a modern approach to create realistic sounding dialog based on the current state of a dynamic game environment. Dialog lines are not hard-coded by a programmer or content integrator but defined by narrative designers as responses to specific events in the game. Each response can check a variety of conditions to figure out the best fitting dialog line for the specific situation. This decoupling of game logic and dialog logic also allows editing the dialog independent from the actual game logic.
Pic1: Opening the Dynamic Response System widget in CRYENGINE.
For more information on DRS usage, please refer here.
Dialog Line Database
The Dialog Line Editor has several buttons and a Search bar at the top:
|Save||Saves the contents of the Dialog Line Database manually.|
|AutoSave||Saves to disk whenever you edit any field in the Dialog Line Database.|
|Import .tsv||Import a *.tsv file.|
|Export .tsv||Exports the contents of the Dialog Line Database as a *.tsv file which can then be opened and edited in other programs, like Excel.|
Deletes all IDs from the Dialog Line Database.
|Search||This Search bar lets you search by ID name in the Dialog Line Database.|
The Dialog Line Database contains lines of dialog (conversations) and related information that can be assigned to an actor in the game mode. In order to add a new line to the database, you need to select the Dialog Line Database tab in the Dynamic Response System widget. The database holds all information for a dialog line such as subtitle, audio assets, and animations. This really helps in grouping the actual data together, instead of splitting it into several actions.
Pic2: Accessing Dialog Line Database in the DRS widget.
|ID||Specifies the ID of the dialog line which is used to reference the line from within the responses.|
|Priority||Specifies the priority of the line. The lines with more importance will cancel the existing lines when started via a SpeakLine action. The lines with less importance will just be skipped. The behavior of lines with the same priority can be configured with the CVar drs_dialogsSamePriorityCancels (default 1).|
|Selection Mode||Only used when the line contains several variations. Defines when a random variation should be picked, or specifies a fixed order in which the variations should be picked.|
|Line Start Trigger||Starts an audio trigger when the specified line is started.|
|Line Interrupted Trigger||Starts an audio trigger when the line is interrupted (by a more important line or through a cancel action). If no interruption trigger is specified, then a hard cut will be executed by default.|
|Subtitle||Displays the subtitle while the line is being spoken.|
|Lipsync animation||Enables the animation to be played when the line is started. |
Note: Looping animations will be stopped, when the line is executed (so the audio asset has been executed or the timeout has been reached), non-looping animations will be played to the end and therefore will delay the next line. The fadeIn/fadeOut time can be configured with the CVar drs_dialogsLipsyncTransitionTime (default 0.25). The talk-animation layer can be configured with drs_dialogsLipsyncAnimationLayer (default 11).
|Standalone file||Specifies the name of a standalone *.mp3 file that should be started when the line is spoken. The path is relative to current project folder/localization/current language.|
You can right-click on the empty space and select Insert Line to create a new line. The ID of the new line needs to be the same as the one that you reference in the SpeakLine action and it needs to be unique. For your example, you can go with li_my_test_line.
A single line can have multiple variations, which means even if you execute the same SpeakLine action twice, the actual line that is spoken can be different. This is a fast way to add (slight) variation on a line.
For example, you can simply add three variations, by right-clicking the line and select Add Line Variation option. Note that the first variation is already stored in the within line, so you need to add two more. There are different properties that you can define for each line, for example you can add the text to be displayed in the game under the column Subtitle.
There is one more interesting option in the right-click context menu, called Run Script.
Pic3: Run Script
This will execute a batch file on each selected dialog line. This can for example be used to automatically generate text-to-speech placeholders for all of your dialog lines. The batch file must be located in your game folder and must be called "linescript.bat".
Here is a simple example of how such a text-to-speech generation script file could look like (using the free tool eSpeak, which needs to be installed):
This example script passes the text stored in the 'SUBTITLE' variable to the command line version of the eSpeak tool, which writes the generated wave file to a file named LINE_ID + ".wav".
For more information on dialog Line Database, please refer here.
Dialog Line History
The Dialog Line History lets you view the signals that have been processed through the DRS system. You can use this information to debug a response signal when it fails to appear in game mode.
Pic4: Viewing dialog line history in DRS.
|Time||Displays the time when the line was spoken. |
Note: The current DRS time can be checked under the Variables tab.
|LineID||Displays the ID of the line that was spoken.|
|Speaker||Specifies the speaker who spoke the line.|
|Status||Displays the status of the line. For example, is the line still running, has it ended, or could it not be started (probably because the actor was already speaking).|
|Desc||Displays detailed information about the current status.|
|LineText||Displays the subtitles associated with the line.|
|Source||Displays a system (if available) which enabled this line to be spoken (for example Flow Graph, code or another response).|
|Clear (Button)||Clears the current history.|
The Response tab lets you add responses to your signals.
On the left side of this panel is an overview of all responses (It`s actually an overview of all *.response files, but since each *.response file contains exactly one response, this is practically the same).
Pic5: Accessing response files in DRS.
You can view the recent signals by selecting the Recent button on the top-left corner of the window. Now the window displays a list of all signals sent by the game so far. If this list is empty make sure the game is running. If the list has not updated automatically, you need to press the Update button at the bottom of the window.
Pic6: Viewing recently sent signals in DRS.
|Signals||Provides an overview of all defined signals.|
|Response||Displays the currently selected signal(s). Lets you to edit the responses here.|
|Execution Info||Displays the history for the currently selected signal(s). Here you can see the output of the last execution of the response. This information is useful for debugging a signal.|
For more information on creating a response, please refer here.
This section provides you an overview of the response files and response signals utilized in the game. You can also create a response file using the Create new button in the bottom of this panel. You can select the response file in the overview section and edit its properties in the Response panel.
Pic7: Viewing the Signals panel under the Response tab.
|Files (Tab)||Displays a list with all *.response files|
|Recent (Tab)||Displays a list with all the signals that were recently sent in the game.|
|Signal (Column)||Displays the name of the signal|
|Count||Displays how often the signal was executed.|
|Signals without Response (Button)||Filters the Recent signals view to only contain signals which don't have a response associated.|
|Signal with Response (Button)||Filters the Recent signals view to only contain signals which do have a response associated.|
|Create new (Button)||Creates a new response for the signal name that was entered in the edit-box.|
|Create response for signal (Button)||Creates a new response for the selected signal.|
|Update (Button)||Updates the Recent signals list to show the latest signals.|
|Show all||Updates the Execution info tab to display the history for all sent signals so far.|
For more information on adding a response to a signal, please refer here.
This section lets you modify a response signal as desired. A response can contain several conditions and actions. Based on the different conditions, different Actions are executed.
You can add a condition or an action to a response, for example, a Random condition which only has one property (Probability). This property defines the chances of the condition to be met. When you specify 50 in the Probability field, the condition will only be met half the time, which allows the SpeakLine action to be called only every second time when a signal is sent. This allows you to understand how conditions influence the outcome of a response.
You can also execute the signal directly without being in the game mode using the Send Signal on Actor button on top right corner of this section. You can specify the exact signal to execute and the desired actor on which the signal should be executed.
Pic8: Viewing the Response panel under the Responses tab.
|1. Save current response (Ctrl+S)||Saves the current response to disk.|
|2. Reload from File (Ctrl+L)||Reverts all changes, and reloads the response from file.|
|3. Show Actions and Conditions (Ctrl+h)||Toggles the view to display/not display conditions and actions. Sometimes useful for very large responses to get a quick overview.|
|4. Evaluate Condition (Ctrl+e)||Displays an indicator in front of each condition for the current state of the game.|
|5. Collapse all (Ctrl+1)||Collapses all the conditions, actions and follow-up responses.|
|6. Collapse one level (Ctrl+2)||Collapses one level of conditions, actions and follow-up responses.|
|7. Collapse to default depth (Ctrl+3)||Displays the actions and conditions of the base responses and the collapsed follow-up responses.|
|8. Expand one level (Ctrl+4)||Expands one level of conditions, actions and follow-up responses.|
|9. Expand all (Ctrl+5)||Expands all the conditions, actions and follow-up responses.|
|10. Reset DRS||Resets all variables and execution-counter, will also stop all running responses.|
|11. Send||Specifies the signal that will be executed on a player.|
|12. On||Specifies the player on which the signal will be executed.|
|13. Send Signal on Actor (Ctrl+B)||The signal specified in the field to the left of the button will be send to the actor with the name specified in the on field to the left.|
|14. Response Tree for Signal|
Displays the entire response tree assigned to a signal.
This section lets you check the history of the signals that have been executed. You can also specify the number of records to be displayed, for example, if you specify 1, you will only see the most recent response to the signal.
Pic9: Viewing the Execution Info panel under the Response tab.
|Auto Update||If checked, updates the list with the latest events from the game.|
|Save current log to JSON||Saves the current history to your project name\Libs\DynamicResponseSystem\DebugData\recentresponses.json (make sure that you have already created the directory).|
|Clear History||Clears the entire history of the signal.|
|Max elements||Specifies how many elements should be displayed at maximum. Removes the older entries first. Enter 1 to only show the latest.|
|History for signal||Shows for which signal(s) the history is currently displayed, normally the signal selected on the left side of the widget (in the recent signals view or the response-files view)|
For more information on Execution Info, please refer here.
You can use the Variables tab to view the variables specified in the signal. A variable can be a name or a value that describes the state of the game. It can be created or updated by the game logic and by the DRS. These variables can then be used in conditions to find the best fitting dialog to an event.
Pic10: Viewing the variables used in a signal under the Variables tab.
|Variable Collections||Displays a group of related variables. Every variable is part of a collection, within a collection each variable name needs to be unique. You can distinguish between three different types of collections:|
At the bottom of the collections overview there is one special collection called "ResponseStates", which shows the ExecutionCounter and the execution timestamps for each response that was started so far. These values are used internally for the "ExecutionLimit" and the "TimeSinceResponse" condition. But this information might also be useful to you to check how often a response was already executed.
|Variable Changes||Lists the history of changes that were made to the DRS variables. If this list is empty, you can use the Auto Update button to update the history. You can also use the Clear button to remove the entire history.|
For more detailed explanation on DRS function, please refer to the Dynamic Response System topic.