Look at us, we have blog posts coming out the wazoo! It’s almost like we know what we’re doing. In this update, I’m going to talk about one of the tools developed for Sure Footing: the TextToSprite system.
Early in the development of Sure Footing, we used font/style sheets to dictate the look of the text. It didn’t look great. So, shortly before the last GameCity (GameCity9), we moved to a sprite sheet model. At first, Matt designed a font, I split the sprites up and then used a dictionary to access the sprites. So, every time text needed to be written to the screen, we’d have sprite objects ready and simply grab the corresponding sprite for the letter/number from the dictionary and apply it to the object.
They were dark times. Not because we used sprites to represent the font, but because of the way we accessed the sprites. Each time we needed text on the screen, a script was attached to a sprite object which would get the sprite at run-time and set it. If there were updating sprites (such as the score) it would grab the sprite and overwrite the previous one at every frame.
I learned from the issues and mistakes of the previous system, though, and during the refactoring period of this summer I redeveloped the font system as the new and improved TextToSprite system. The dictionary is still there, because it makes the most sense as a data structure for connecting a sprite and a string. However, instead of needing a GameObject in the scene and a script attached in order to set individual letters, methods dynamically create everything.
Let’s take an example: the biographies. In the image below, you’ll see Pete’s bio, which is actually written using the TextToSprite system.
In the old system, each letter would need to be manually placed and then accessed through the script. See what I mean about dark times? Thankfully, we never did that, because that would be stupid. Now, the bio is produced from the following line:
This calls the ‘GenerateComplexText’ method in the TextToSprite system, which handles all of the writing of the text. This method (which is currently one of three) is the brains behind this operation. Taking a collection of parameters including the text it needs to write, a parent object and a max width, the method start instantiating game objects. Starting at the position of the parent object, we create a GameObject for each element of the text and set it’s sprite by grabbing it from the dictionary. We then set the scale of the GameObject and position it next to our last element. If the current element is a space, then we need to check if the next word will fit before we hit our max width. If so, we add an offset to our position for the next element to make a space and, if the word won’t fit, we move onto the next line by increasing the Y value of future elements’ positions. The other two methods act in a similar way, except one ignores spaces and the other adds tabs in for writing to the leaderboard.
However, there is currently an issue with the system that I aim to fix after the GameCity festival: the scaling of the elements. Currently, all elements are scaled uniformly, resulting in one of two issues: either the letter ‘i’ (for example) is the same width as the letter ‘m’ (resulting in a fat looking ‘i’) or there are gaps either side of the ‘i’ that make reading difficult. As you can see from the previous image of the bio, I chose to have gaps rather than fat lettering.
To solve this issue, I’ll be modifying the system to have a dictionary of objects, rather than sprites. The objects themselves will contain the sprite, as well as scaling information and any other information we need further down the line.
Hope you enjoyed this info dump! Keep an eye out for further dev blogs from the team in the coming weeks.