TextMesh Pro How to allow player input their name?

In this case we may encounter any character from any language. How do we setup the fallback to support this?

 

The recommended workflow is to have a primary font asset that is static that contains all the known / used characters in the project for any given language or groups of languages. Then to assign as fallback to this primary a fallback font asset that is set to dynamic and there to essential handle anything else that is not contained in the primary.

In version 1.4.1 of TMP, the TMP Essential Resources with regards to the LiberationSans SDF font asset is setup that way where it has a reference to a fallback font asset for LiberationSans that is dynamic.

BTW: During development, you could run full dynamic and then as you get further along / closer to shipping, etc. compile the list of the characters used in the project to create your static font assets and appropriate dynamic fallbacks.

 

Our game supports all languages. How is it possible to fit multiple languages into one static font asset? If we use a TTF that supports all the languages it probably will blow the package size.

 

The static font asset(s) would only contain the characters used in the project for a given language or groups of languages. By known characters, we are talking about text in the UI, menus, etc. We exclude all the text that will come from user input or other sources at runtime as those will be handled by the dynamic fallbacks.

Even very text heavy projects do not actually contain that many unique characters. The last project I looked at was available in 47 languages where the bulk of the languages were Latin based which can easily be handled by including the extended ASCII set (ie. since the # of characters for Latin is small, you can include pretty much all of then in the static font asset). Now for Chinese, this project included Simplified and Traditional and although the Chinese language contains over 70,000 potential characters, the project used a total of 477 combined.

So for Latin based languages whose character set is limited, it is easy to fit the entire Extended ASCII in a primary static font asset with perhaps one partially filled dynamic fallback that might contain Cyrillic. Then add one extra dynamic fallback that is empty to catch everything else that a user might type. Empty fallbacks have their atlas texture at size 0 so they do not take any space.

For Chinese, Japanese and Korean languages where the character set is much larger, it is advisable to have a primary font asset for each language and then a dynamic fallback.

Many users will use Asset Bundles to package these resources.

Most of the time the primary font asset or a fallback will also contains all the characters used to display the language selection menu / options. This way, each language / bundles contains all that is needed to go from one to another language.

The above suggested structure is to provide best runtime performance as most of the text that will be displayed is already in a static font asset. Then user input which is slower (since humans don't type that fast) can be handled by the dynamic system.

The above is a recommended workflow. However, the system is fully dynamic and is capable of not only adding characters and glyphs to font assets at runtime but you can also create font assets and fallback at runtime. In addition in the next release you will be able to create font assets at runtime from fonts present on the local device where you can then populate them with some characters that you know will be required and then the rest on demand.

Basically, there are a lot of ways this could be structured ranging from all static to using some dynamic fallbacks to creating everything from local fonts on devices. Static will always provide best runtime performance but requires more setup / preparation and using Asset Bundles to potentially reduce package size. At the other end of the spectrum with everything dynamic, you may end up having to use different fonts on different platforms because the font you want may not be available. You will also need to plan how / when to create these font assets to help minimize / manage the higher performance overhead.

Also in the next release, Multi Atlas texture will be supported when a font asset (dynamic) will be able to have more than (1) atlas texture. Basically as the first atlas texture gets full, another is created automatically to handle the additional characters / glyphs.

So lots of ways this could be handled.