You: "Why hello there, furry clerk of this fine shop! What provisions do you have?"
Store Clerk: "Why we have rich Corinthian leather! Can I interest you in some?"
- OPTION A: "Absolutely - ring it on up so I may reupholster my scratching post!"
- OPTION B: "What's under that tarp there labeled 'Absolutely Not For Sale'?"
>You Chose OPTION B.
Store Clerk: "Oh, That? Hah.. haha... well, I'm glad you asked... see, that has the dialog editor for A Purrtato Tail. That's not for sale..."
But... we will discuss it! Hello and greetings! This is RedVonix, the lead behind A Purrtato Tail, once again here to talk to you about one of the many systems that make this game possible. Probably one of the most important systems as well - the Dialog Editor and Conversation System. A Purrtato Tail is a game with a tremendous amount of text, as there are a lot of places where the character can converse with others, listen in on ambient dialog in the world, and have an effect on all of these based on their decisions and game progress.
In the past, when developing games like Steve Aoki's BeatBomb, our dialog was simple - it was coded into a script file that was used to manage the in-game events and displayed as needed. It realistically was a little clunky, but it got us to the finish line, and allowed us to have conversations between the famous DJ and his friends in deep space. For something with complex conversation and story however - we needed something very, very capable. It needed to tie into many other systems. It needed to know about quests. It needed to know about state flags. It needed to know about items. It needed to have seamless multi-lingual support (or else localizing the game would be a nightmare!). So we did what any standard, run of the mill insane developer would do - we dived in head-first with absolutely no plan and built it as we went along.
You're probably thinking, "Hol 'up... shouldn't you, like... plan... that?". Well, you would be right! And, to a point, we did. We were actually sitting on a graphing system we had previously developed that we called Node/Graph. We wrote this because we needed a graphing system that worked in the editor, and at runtime, but also allowed it to be 'skinned' with any code we desired. Such a system was designed to be used as a progression flow controller, UI flow controller, logic controller, or - of course - a dialog system, all based on what Skin is currently applied to it. Since we had it sitting around and ready, we opted to start writing a 'Dialog Engine Skin' for Node/Graph.
This skin started with just the most basic of elements - Dialog Nodes, which could have a character assigned to them, and have the dialog tie into our existing Multilingual System, so any text written in a Dialog Node would already be ready for export to the localization teams.
Expanding from there, we needed to know State Flag values from the State Flag system. Has the player reached a certain area? Have they toggled a specific trigger? Those can affect the way a conversation goes - so we built in support for those.
If you remember the previous DevBlog about our State Flag System, you might recognize that the State Flag Compare node is accessing the Category of 'Game Progress', and the flag inside that category of 'Tutorial_ShowPieceRotated'. This is a perfect example of why we categorized the State Flags - so that when using them in systems like this, we don't need to access a list of potentially thousands of flags - instead, just the collection that would be in a single focused category.
As production continued, so did development of the Dialog Editor - with node after node, each adding their own functionality. Node/Graph was thankfully very capable of having whatever node we wanted added with minimal effort, therefore development of any one of these nodes was a matter of minutes or hours rather than days (seriously - on average, a new node type is developed in 35 minutes). Today, the Dialog Editor has 25 different types of nodes, each performing a unique and specific action meant to make conversations more interesting, more meaningful, and more in-depth.
Some of the nodes that are more unique to our game include:
- Shake Camera - Causes the camera to shake with a defined velocity and length of time.
- Set Overhead Accent - Changes the accent over a character's head (such as the ?'s that appear over Pixel when she is confused by something or thinking about something), or the Z's over her head while sleeping.
- Change Char Anim. State - Allows us to easily change a specific character's animation in the middle of a conversation - pretty important when you want characters to react to what is being said.
- Give Quest - Gives a specific quest to the player. This allows conversations to handle quest giving when needed - which also means specific dialog paths might be the only way to get specific quests.
- Is Wearing Hat Type - Is the player wearing a specific hat? If yes, take Path A. If no, take Path B.
Here is the full list of 25 node types. And this list will almost certainly increase as game production continues and we find more we wish to add.. such as a Dialog Path Selection node, to allow the player to choose a response from a list of entries - exactly the example given at the top of this DevBlog.
That's a lot - all 25! And every single one of those nodes are already being used in the numerous conversations throughout the introduction we have shown off, and the upcoming Cantermow demo. When you look at it like this, again, it really does look like a lot and it is. But it is what allows the seamless conversations and dialog to occur. A lot goes into making a game, and even as developers we don't always realize just how much we have built until we take a step back and go "Holy bowling balls that's a lot of stuff".
Another great feature of our Node/Graph system is the ability for each node type to have its own contents, and to have its own editor panel. Which means - all 25 nodes have a unique editor panel, allowing us to configure each node as needed. Let's take a look at one of them - the single most important node type in the entire system, the Dialog Node.
This is a node from a conversation that takes place during the Cantermow demo between Pixel and 4 NPCs. Whenever a developer places a Dialog object in a Unity Scene, we select what characters in the world will be part of that specific conversation. This allows us to know what character objects to connect with dialog bubbles, what characters to have look at what other characters (ever notice that characters always look at the one who is currently speaking?), and what language files to load from the Multilingual System.
Let's break down this editor a little...
- QuestNPC - Franklin, QuestNPC - Michael, Etc. - These are the 4 characters who are taking part in this Conversation. These buttons allow us to select who will say this dialog. The system is even configured so we can change who is saying the dialog - and behind the scenes, the Multilingual System will update itself appropriately to ensure the proper localization Language File has the needed text.
- Dialog Position - This affects where the dialog bubble appears on the screen. Typically, we use Dynamic - which causes the dialog bubble to intelligently display itself between the characters in the conversation, while staying close to the one currently talking. However - there are some instances where the environment isn't quite made for that kind of a setup - perhaps there is some foreground detail that would be in the way. Since these moments of the environment getting in the way are relatively minimal, rather than expanding the logical placement system to watch for them - we just set a specific anchor position on the screen instead. We can also choose Upper Left, Upper Middle, Upper Right, etc. as alternative 'anchored' dialog placement positions.
- Tag Key - These allow us to ensure certain parts of the dialog are always formatted the same. For example - if we need to display how many times the player has viewed this dialog, we type (VIEWCOUNT) into the conversation. This then gets converted automatically to the number. Or, if we want to show the words 'Fur Static' complete with their movement and visual effects, we type (FURSTATIC) - and the text system will automatically replace that with the properly styled text. The types of Tag Keys will certainly expand as development progresses so we can ensure there is consistency throughout the game.
And finally, after all that, we have the dialog itself. Which - depending on what current Language is selected in the Multilingual System Editor - this will display in that language. Which means, yes, if you want to edit the dialog in Japanese - you can.
No, seriously... you actually can.
Overall, the Dialog Editor is one of the most important parts of A Purrtato Tail, as it is what makes it possible for us to have storytelling dialog. It is used in shops. It is used when talking to that random NPC under the bridge. It is used when bosses taunt you. It is used everywhere. And all of it comes through to the player - as Conversations.
Once again I am RedVonix, this has been another DevBlog in the world of A Purrtato Tail, and until next time... stay fluffy!
