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!

The next sample should cover a feature from one of my favourite games.

See you soon…

I’ll start by saying what I liked about the cursor, which should be very easy to guess: yup, the trail it leaves behind when it moves, and the nice border that makes it visible anywhere on the screen. So those were two goals that I set for my samples.

If I had been a good developer, I first would have started World of Goo and would have spent a couple of minutes just looking at the cursor and how it behaves, but I didn’t. I just started coding, and ended up rewriting all the sample after a while. At least I learned a good lesson: do your research first.

So the first thing I wanted to do was the trail. My first idea was to keep a list of positions where the cursor has been. The list was limited in size, which caused the oldest positions to be removed each frame. When moving the mouse, I stored the new position each frame, and removed the oldest one. Then, when drawing the cursor, for each position stored in the trail, I rendered a circle from a texture. When I ran the code, the first problems appeared: when moving the mouse too fast, gaps appeared between different circles, and instead of having one continuous trail, I had several distanced circles. This is when I decided to go back to the basics, and start up World of Goo to take a closer look at the cursor.

After spending a few minutes in the game’s menu, I took note of the following:

• The cursor is indeed made up of many circles, as I suspected, but they are kept close enough so you don’t notice them most of the time.
• The trail has a certain elasticity to it. When you move the cursor, the trail stays a little behind, and recovers with a different speed than the one you moved with
• I still haven’t finished the second world of the game.

With that new information (namely the second points), I scraped the code, and started fresh. The first thing I had to deal with was that elasticity. The knowledge on how to do that came from an unexpected place. The Chase Camera Sample found on the XNA Creator’s Club webpage deals with a chase camera that uses spring physics for nice camera movement. The documentation found in the project’s folder was especially useful, because it contained some description on how the spring for the camera was implemented.

My idea was that if I built a trail composed of a chain of nodes, tied to each other with springs that had the resting length of 0 (each node always tries to reach the position of the previous node), it would work as expected.

The result can be seen in the sample, in the UpdateTrailNodes function, where a force is computed for each node, such that it pulls the node towards the previous one in the list. Then after some trial-and-error for the values of different parameters (now settable through the sample’s interface), I obtained a pretty good approximation of the behavior. By keeping the springs stiff enough, the nodes rarely get too far apart, so the circles appear as a continuous trails.

All left to do was the border. For this, the solution is rather simple. First, I draw all the nodes using the color I want for the border (White), and scaling them to make them slightly larger than normal. After this, I go again through the list of nodes, and draw them with their normal color (Black), at their normal scale. The black nodes overlap the central area of the white ones, and thus the border is created.

After using these two techniques I was satisfied enough to release the sample into the wild, and I hope the explanations help with a better understanding of the code.

So the first sample deals with the XNA implementation of something similar to the mouse cursor encountered in World of Goo. My blog post later this week will contain more information about how I built the sample, but until then, you can try it out, and play with it.

To download it, access the sample’s page, here.

Have fun toying with the configurable parameters!

This next year-or-so, I’ll be releasing samples under a new theme: “Game Features replicator”

What this means is that new samples will be created through the following method:

• Pick an interesting feature from games I play and like.
• Analyze the feature, and see how it works. I’ll also say some words about the analysis, about how I looked at the feature, how I assumed it works, and what objectives I set for the XNA sample.
• Try to make an equivalent implementation in XNA. This is not going to work/function identical to the original feature, but I will always try to reach each point that made that certain feature interesting, and provide a satisfying equivalent.
• Release the sample so anyone can learn from it and use it in their own games.

The first of these samples will look at a mouse cursor, as it appears in World of Goo, and I will upload it to the site soon.

I hope you’ll like this series of samples, and I’ll do my best to make each one special.