Posted On: 2019-09-02
One of the simple/mundane challenges of writing for games is accounting for the physical way that the text is conveyed. Whether it's speech bubbles over characters' heads, text boxes with character portraits, or even the spoken word with text subtitles, the amount of space available is an important factor in determining what, and how much, is said. Unfortunately, the tools I currently use for writing do not have any way of communicating this information to me during the writing process, so I often find myself running dialogue in-engine to make sure that the text doesn't overflow the available space. Initially this seemed like a small inconvenience, but it eventually impaired the maintainability of the writing in my prototypes, so I've been working on a more permanent solution.
Whenever I discover that the dialogue does not fit nicely in the available space, I have to decide whether to reduce the amount of text that is displayed (rework the content) or break the dialogue up into smaller pieces (rework the pacing.) Reducing the amount of text typically results in punchier, more on-point dialogue (which is generally good) but it usually can only save one or two lines in the text box. When the dialogue content is overflowing by many lines, I often have to choose between massive cuts to the content (such as completely removing a conversation) or breaking that dialogue up into smaller pieces that are delivered to the player sequentially - with no player action other than "press A to continue."
When I wrote the Magic Training Prototype, I went in with the knowledge that I would need to break up the conversation, so during my first draft I consciously included dialogue connections using "Continue." Unfortunately, since I didn't know how much could fit in one text box at a time, most of these were still too long, so they overflowed when I ran the dialogue in-engine. Even after extensive content editing, many of these needed to be broken apart into separate conversation pieces. This resulted in many places where text was normally sequential using numbers (such as "About Clown 1" and "About Clown 2") but then that sequence was interrupted by subdivisions that did not follow the numbering system (such as "About Clown 2a.") By the time I finished with the prototype, this was significantly impacting maintainability: these convolutions in the numbering made it difficult to locate any particular line in the text, and reading a single sequence in the source script required jumping between many small fragments.
While migrating the dialogue engine from the prototype into the main project, I had the opportunity to make revisions to how it parsed dialogue content, so I decided to adjust it to make it easier to break apart chunks of content that were too long. Furthermore, I wanted to implement this in a way that did not require moving the content in the source material, that way I could easily read and modify all the content at once - regardless of how it was paced in-engine. The particular implementation I chose was a simple line break: whenever the parser discovered a line with no text on it, it ran a (new) method that would insert a "Continue" prompt. This approach makes it very simple to see at a glance how the content is structured and understand how many times a player has to hit "Continue" before they can change/exit the conversation. While I suspect this solution is a bit too simple to meet all my future needs, it seems like it will be convenient and effective, so I will likely add onto it when the need arises (rather than throwing it out and starting over, as I often do with less maintainable solutions.)
Adjusting text so that it fits into the space available is a simple, common problem that games with writing often need to address. Hopefully you have enjoyed this glimpse into how that problem has impacted my work, as well as how I'm trying to address it. As always, if you have any thoughts or feedback, please let me know.