While making Westerado we realized we needed something to smooth out the Gunversation creation. At the time we were putting in every single line of dialog in the code by hand, which of course was highly inefficient. We knew we wanted some kind of conversation tree builder, but every tool I could find that did what we needed seemed overly complex or it didn’t have actual support for some of the things we needed. This is when I decided I could create our first specialized tool, Gunversationist.
The main idea behind Gunversationist was simple. Conversations in Westerado usually go in a single direction with a branching path based on what the player wants or what the player has done before. Any choices made can have an impact on the story or gameplay and that impact would need to be specified as well. All this led to a node based tree structure, that is read from left to right, with dots representing things other characters say connected by lines that represent the player’s choices.
For the lines we needed a number of different types of interactions to be possible, which is why I decided to go with colors that defined what kind of action it is. Yellow for talking, red for drawing a gun and blue for putting the gun away.
For the dots we also needed a few different types. Green for the start of a single conversation, yellow for a regular mid-conversation line and blue for the end.
Every line and dot has 4 parts to it. A “voice” field containing the text the player sees, a “requirements” field with variables that need to have certain values for the option to be available, a “changes” field with the impact that particular choice would have and a “description” field that could be used for designer notes.
This setup was first chosen as an experiment to see if this was enough to build a solid conversation system, but turned out te be so easy to expand that we stuck with it, through 3 different versions of the tool. The “changes” and “requirements” fields were originally only used to set certain keywords that could be used by later conversations, but quickly expanded to being able to check and change pretty much anything in the game.
Over time we added some more features, but the basic functionality was never broken. An example of this was the orange line and dot combination. As I’ve explained before we originally assumed that conversations would go in one direction, mostly because it removed the interface clutter of needing arrows to show what direction something was going and made it a lot easier to “read” a tree. This led to some early conversations just stopping and needing the player to re-enter the conversation to actually progress. The solution to this was adding the orange color. As soon as you’d hit an orange dot it would try to find a matching dot, move the conversation there and then follow the first available orange line to the next dot, until it got to a regular dot that could be shown to the player. This allowed us to create things like looping conversation and conversations where you could actually ask multiple questions, one after the other. Eventually one of the designers figured out that since orange elements would never be shown to the player he could actually do some new and interesting things, which led to a couple of complex orange sections in conversations that combined multiple “changes” and “requirements” in a row to create very basic scripts.
