Summary:
When working on my game for Capstone Production in the first semester, one of the features I worked on was the talksprite displays for cutscenes. We were integrating a program called Inky into our Unity prototype, which handled displaying the dialogue and going down the correct route of the dialogue tree based on what choices the player made in-scene. Inky has a great basic framework for handling these scripts and is easy to learn, with a method put into its basic functionality for adding tags to every dialogue line to imply what sort of text to display, and what talksprites to show for that screen. However, it is up to the developer to actually write the code that interprets those tags in their Unity scripts. In order to do this, I created a Talksprite Manager class.
Since our team was determined to go forward into Senior Production, I wanted to make sure that our system for talksprite display was set up so that it would be easy for team members– programmers or designers– to add additional images to the working list of talksprite images available for display, or to replace the ones currently in the build. To do this, I made my TalkspriteManager class hold a List of 2D sprite images. List<> objects in C# are easy to manipulate in comparison to collection types like arrays, and less complicated to work with than other collection types such as maps and dictionaries.
Each image being used is labeled with the same naming convention: <character name>_<emotion>. This makes it easier for the designer (or, in our case, also the producer) working on the dialogue scripts to remember how to tag each dialogue line for displaying the correct image.
This image also shows the variables “Afrodita Location and Sasha Location.” In order to be able to spawn the images into the correct part of the screen, I put two plain rectangles into each dialogue scene in-editor to show where both character’s talksprites should show up when they are being called in script. Before the game runs, the scene effectively “looks” like this:
When the program runs each new dialogue line, it only displays images that are being called, in the location that is tied to that character, and deletes any others that may be on the screen. This means that sometimes an image that appears for multiple dialogue lines is wiped and redisplayed, but this is not a significant strain on disk space and prevents bugs where images appear that are not intended to be in a given dialogue frame.
To make sure all of this runs without issues or accidental multiple TalkspriteManagers in a given dialogue scene, I also made it a singleton. Finally, so that setup of new dialogue scenes would be quick and easy, I made a TalkspriteManager empty prefab object, holding all finished talksprites. The locations for where to spawn a given character’s talksprites are set individually for each scene, but they do not need to be hooked up to the TalkspriteManager class. The script finds them by the names of the empty rectangles.
Here is a video from the week we got this working, showing one of our dialogue scenes in action.
In retrospect, if I had put more time into this, I would have the script take advantage of the talksprites' uniform naming convention and just call them by the character name and emotion, which would have made adding additional characters or emotions more seamless. As it is, though, it functions as expected.