One of the last major systems that still needs to get added to Echodream are text boxes and dialogue trees. As always, I want to make a flexible, polymorphic system that can be used for any 8-bit/16-bit style 2D game, not specialized text boxes that fit a specific use case. So, first I need to think about what a text box fundamentally is.

 

1. Text boxes contain blocks of text

​

That’s the most obvious property. Character interactions are broken up into blocks of text (strings), typically with one string displayed at a time. Often, one character at a time is revealed until the whole string is displayed. So, the boxes will have to load sets of strings for character interactions, and it will have to have some sort of display string that loads characters from the set of strings.

​

The strings are not unordered, nor are they ordered in a sequential list. Character interactions can have branching. They could probably be stored in a tree, because you generally only go forward (and occasionally backwards) through the dialogue, and a tree would satisfy those requirements. But I’m actually going to be using the engine’s menu system to implement text boxes for reasons I’ll get into later. The underlying data structure in the menu system is a map, which is probably overkill, but it will work, and I’ll hide it from the client anyway.

​

The blocks of text that comprise character interactions cannot be stored as simple strings, however, because as we’ve already established there can be branching, so at the very least you need some way to allow the player to choose branches. This is one of the reasons I am reusing the engine’s menu system to implement text boxes – the menu system is really just a polymorphic state machine.

​

It contains a small amount of specialized menu code, but fundamentally the menus are just a maps of menu nodes. The menu nodes contain vectors of base class behavior pointers and “interactions” (pair of callback functions – if the first function returns true, call the second function), so they can use the menus for any kind of state machine, and character dialogue can be done as a state machine.

​

2. Text boxes contain images

​

That’s where the word “box” comes from – There’s usually something behind/around the text (like a box) when character dialogue appears on-screen. So, a text box has to be able to render textures. Usually, the textures don’t change in the middle of an interaction. In fact, a lot of old games used the same text box for all character dialogue. So, the text box should store image data separate from the text block data. There should still probably be a way to add images to individual text blocks just in case, but in the vast majority of cases you can just use one set of image data for a character interaction (and maybe even an entire game).

​

Another thing to consider is that the text box images might not be static – they might animate. So, the system is going to have to handle animations, even though it’s probably an uncommon case. And I think that pretty much covers everything I need for a flexible text box system. It’ll have branching text blocks with polymorphic interactive behavior and any number of textures with the option to animate. Anything that doesn’t cover is probably too complex/specialized to be covered by a generic text box system.