Towergirls
patreon
Unity Port: Update 2 - Dialogue
🕑 Added 2019-02-17 01:25:37 +0000 UTCDialogue is a huge, if not the most important part of our Towergirls game. Each character able to join the party has something like a minimum of five or six pages of dialogue, with Kobold Princess main dialogue code being like seventy. We've always been pushing for there to be more than moderate amounts of dialogue and narration text whenever possible. This makes for a lot of stored dialogue and content. In GMS I never made a particularly pretty or efficient dialogue system, simply using an old system that I had devised in my earlier coding days. Though functional, having the writers interface with the thing was nearly impossible, and ended up with me making a mod tool just for the writers to visually add dialogue into the game. The hideous nature of the dialogue code, the writer-unfriendliness, and being internally stored in the game are issues that I wanted to address in the porting over to Unity.
In GMS, dialogue was stored as a series of arguments (disgusting) with their parameters shoved inside each sub-argument. This took the form of a conversation 'string', or keyword forming up the main if-container, and dialogue 'integer', or number, holding the individual dialogue text and miscellaneous code. This did have some strong points- it could be rearranged and modified pretty easily, and I could quickly whip up code to interact with the game as needed. The actual handling of the dialogue text was a bit more solid, with huge-blocks-of-text automatically being split into several dialogue panels, and the parameters and arguments, and so on. When dialogue is being type-writered into the screen, it also enters a linebreak when it encounters a space, as opposed to partial words appearing and then skipping to the next line when finished, which can be a bit jarring. Terrible overall, but not entirely terrible.
Some Human Princess dialogue, from GMS.
With those short-comings in mind, I wanted to come up with a system that could address all three. Two days were spent looking online to see what dialogue stuff people had done for Unity, and what was freely available. Surprisingly there wasn't a whole lot- at most people suggested some very broad suggestions, or there was purchasable content linked to the Unity store. What dialogue systems were freely viewable were extremely simple or not suitable/resembling what we needed. While reading through a comment-chain on a help thread, some kind soul linked to a presentation a game developer gave on text-heavy games. Titled 'Adventures in Text: Innovating in Interactive Fiction', and given by Jon Ingold (Dude from Inkle Studios), it's an hour long-talk going on about games his company has made, how they handled storing and parsing dialogue, and considerations when doing so. It's a bit of a slog if you're not into game programming or writing, but it was exactly the brain-food that I needed. The guy was very clearly an expert, and it was great having insight from those that had done text-centric games for years. Link at the bottom of this post [1].
The most notable take-away point I had from the presentation, for coding, was their method of storing dialogue. Mr.Ingold's studio had gone through several iterations of dialogue systems already. They ended up just shoving dialogue into a plain-text document and having the game parse it when appropriate. The more I considered this, the more I realized it was simple, brilliant, and effective. Our Towergirls dialogue, and writing, is very much top-to-bottom in content and form- the majority of our dialogue simply has a character speak something, and then it moves on to that character saying something else (or someone else chiming in), until dialogue options and branches are reached. It isn't necessary for each of those little bits of dialogue to have a specific ID to jump to, when they're just a smaller bit of linear dialogues.
Mind helped, I got to work on making a text parser. Amusingly the first step wasn't code, but rather taking a look at existing dialogue and brainstorming a good format. The less syntax and formatting the better; the simpler it would be, the easier time writers would have screwing around with it. I opened the initial tutorial dialogue (in the tavern with Ale Knight and Wine Knight), and ripped out half a page of dialogue, over into Notepad++ (fuck yeah, Notepad++). It's then I realized that the format I was already moving the dialogue over, into the text program, was probably the simplest and most logical way to store it for the parser. From there it was just considering all the things our current dialogue does in GMS and coming up with functions/arguments that could be stored in a sensible plaintext format. Code came next.
The new dialogue [2] , prepared and ready to appear in Unity.
The new and shiny parser opens up a specified text document, then chunks every single line into an array of strings. It then removes extraneous ones, shoves lines not-separated-by-empty-space together, and stores that away. Each bit of dialogue and/or code are stored within their own Dialogue Node ScriptableObject, which is stored within the parser. When the appropriate conversation is ran it then plays these dialogue nodes from first to last, simply playing every text/function one after another until it is told to do otherwise. Every now and then a jump point, or keyword, is placed so that text can be jumped to. Simple, efficient, pretty. Everything is just plaintext with a bit of additional parsing [3].
The dialogue parser doing its thing.
But wait, Duke, you may say. If everything is stored as plaintext, does that mean all the dialogue in the game can be edited as we like?
The answer is yes*.
A mod dialogue editor is no longer necessary when you can just edit the existing dialogue to the full extent. There'll no doubt still be a bit of mod-tools just for telling Unity what new content there is, and making things easier on users, but dialogue is going to be considerably easier to mod in and change. Things worked out nicely for modding in this way, at least for dialogue. The other mod systems (new characters, overmap encounters, custom dungeons, etc. etc.) I haven't got a clue how to do in Unity, but are all definitely planned.
Bit shorter of a recap this time, but dialogue felt important enough to have its own update. Towards the end of the month we'll be taking a look at dungeons and how the progress is going on that front. Here's the updated status on the game subsystems.
Bottom Bar (dungeon and territory)
====Partially completed
Character / Enemy Stats
==== Mostly completed
Dungeons
==== Rooms mostly completed
==== Encounters partially completed
==== Transition to battle partially completed
Inventory
==== Pretty much done
Items
==== Partially completed
==== Equipment mostly functional
Abilities
==== Partially completed
Character Inspect
==== Partially figured out
Spells/Abilities Screen
==== Partially completed
Main Menu
==== Placeholder semi functional
Save/Load
Top Bar (resources and such)
Overmap Navigation
==== Camera movement completed
Territories
Dialogue
==== Data storage completed
==== Parser mostly completed
==== Display completed
Siege Stuff
==== Partially figured out
Battles
==== Partially completed
==== Initiative working
==== Attacking working
==== Camera effects working
Ser Animation
==== Pretty much done
Screenshot of the finished Inventory UI.
And a sneak peak at dungeons since Unyin is going ham on that front.
* Not possible at this exact second but I'll get there. Need to work out how to store/access files separate from the compiled Unity game.
[3] Parsing Functions and Help
Comments
You guys move to Unity and your progress instantly increases at a better pace. I am very excited to see the coming updates.
Keep up and good work)))
