TextMesh Pro Dynamic Text from Player Inputs

So I've been trying out TextMeshPro for our upcoming project. One of the requirements is that we need to display other player names (which they key in themselves) in different localizations. For example, I might be playing in English but I can see player names that are Chinese, Korean, Japanese, etc...

And so there are 2 solutions :
1. Use Dynamic Fonts in the newest release of TMP. Downside is I need to include the font file in the game. The game is a mobile game and we would like to keep the download size as small as possible. For reference, Arial Unicode MS takes about 22MB.
2. Use Unity's UI Text with system font. This doesn't take up more file space (I think?), but I lose all the features in TMP. And it looks ugly.

So I'm wondering, are these the only options? Does anyone have other solutions?

 

One of the new features that I am working on that related to the Dynamic SDF system is the ability to create font assets at runtime (already available) from local fonts on devices (new feature). This process will require querying the local device for a list / path of those OS fonts and then creating a new font asset using one of these. From there, it is business as usual with TMP where you can pre-populate the font with a set of characters (those you know ahead of time you will need [recommended]) vs just run full dynamic, etc.

The challenge with the above is the fact that most platforms / OS include different lists of fonts which makes for inconsistent visual / designs on those devices / platforms.

Since Arial Unicode is a font that requires special licensing, you might want to look at some other potential fonts. Noto Sans could be an alternative as it is included on several platforms. In those cases, you could use the local version.

Having said that, you could pick a series of fonts for the specific languages you are targeting instead of a single font to try to cover all. This would result in smaller fonts / resources needed for languages / regions. In addition, it is pretty common for designers to like the design of the Latin characters of a given font but not the CJK design for instance or vice-a-versa. Using different smaller fonts allows you to mix and match to achieve whatever visual design / uniformity you seek.

So when using different fonts for potential regions and languages, you would create a primary static font asset that include the known character used in the project for the given language or group of languages + the few characters needed to display the language selection / menu text in other languages. Then based on language selection, you could via AssetBundles, fetch the new font assets and resources for the newly selected language thus allowing you to break up all of this into smaller pieces.

For each of these language sets, you would have a primary that is static with a dynamic fallback to handle user input.

Using the above strategy would enable you to have better control and consistency across all platforms and to reduce to size of each package as they only need the resources to handle specific languages / regions.

With the static font assets, the font files would be excluded unless you had a fallback using this font set to dynamic mode. Since user input tends to be less stylized, it might be ok (design wise) to create a dynamic fallback from a local font on the device. This would ensure all your known text / menus / dialogues / etc.. all use the same static font assets for best performance and design quality control but uses whatever other local font for user input where design might not be as much of an issue.

These are just suggestions on potential ways to structure this. The above as been used by several studios. With the new Dynamic system, there are more options now available thus giving flexibility to mix and match all these things.

 

Good to hear on the new feature! I'll be looking forward to it!

Indeed we've been planning to use Dynamic Fonts for player input only. The rest of the known texts will definitely come from static font assets for performance reasons, and of course that includes the texts in the language selection screen.

We've been trying to avoid AssetBundles for localization purpose (game ships in English, other languages in DLC) because we want the game to be easily accessible for all languages supported (the game starts in the same language as the player's device language, if the game supports the language). However, I guess we can consider this approach if the DLC is only there to allow players to be able to see other player's input correctly, and appears as an option that is not required before the player starts the game. And, in the future when system fonts can be used, players will only need to download the extra content if their phones does not have the appropriate fonts. This sounds like a good solution for us.

Thanks for the feedback!