Finally, the dialogue system sample is here.

In this sample, I tried to replicate the dialogue system as seen in Bioware’s Mass Effect. The main aspects that I intended to implement were:

• Dialogue Wheel, showing short previews of what the Player Character will say. You don’t see the whole answer before you choose it. Only after you choose it, you see it spoken by the player’s character.
• Investigate branch. In a dialogue “hub” (a place where the player can make choices), there may be one or more topics which do not count as “choices”, but rather as information gathering. They are accessible through an “Investigate” option on the Dialogue Wheel
• Choice on the right side of the wheel almost always have a certain meaning. The Top-Right choice is usually a good choice, the Center-Right is a neutral choice, and the Lower-Right is a renegade choice
• Besides these two features which are defining for Mass Effect, the normal functionality you would expect from a dialogue system in an RPG.

One thing I wanted to do, but didn’t get to is a more detailed handling of the preconditions and consequences of a choice. As you can read in the sample’s page, each dialogue branch has these associated, as collection of Key-Value pairs. I decided to simply shows the consequences on the screen. In a game, these would be handled by some other module of the game, such as a scripting system, or quest system, or something like that. Thus, some choices could be unavailable (based on the precondition) and some choices may lead to very different results, affecting immediate events, or events later in the game (using Consequences to set flags). This is really game-specific, so an thorough exemplification of what can be done with them is hard to do in a sample.

To develop the class hierarchy (shortly described on the sample’s page), I first began by playing a few dialogues in Mass Effect, and carefully analyzing what was happening as a developer, not as a player. So I decided that I’ll need some class to represent a line delivered by a character. This includes the sound and subtitles, and I named it a SpeechLine. My class also contains some ID that should represent the character’s ID. In a more evolved system, a SpeechLine would also contains stuff like camera position, camera target, character animations, etc. If all these were available, cutscenes could be created as a sequence of SpeechLines. This is somehow outside the scope of this sample, but by looking at dialogue this way, you can see the need for a DialogueBranch, which in my code is a sequence of SpeechLines.

So player choices are tied together using DialogueBranches. But how do you represent a player choice? For this, I used the class DialogueHub, which contains the IDs of the DialogueBranches which are options available to the player in that hub. One such DialogueBranch would carry the conversation to another hub, thus advancing the dialogue according the the player’s choices. To handle the Investigate topics, I simply added them as DialogueBranches which don’t lead to another hub, but rather return to the hub that they were called from. To make this visible, the “Investigate” sub-hub is available to players.

All information related to a dialogue is held in the Dialogue class, directly loadable from an XML file using the Content Pipeline. In a real game, you would probably want to load this using a separate ContentManager, so you can unload all the dialogue resources once you’re done with them. After loading a Dialogue, you can start playing it with the DialoguePlayer class. I split the functionality of this class in two main classes, the BranchPlayer, and the HubPlayer. For drawing the dialogue interface, the DialogueWheel class is used. Simply modifying this class would cause the user interface to look different.

The sample’s page can be found here. Have fun!