Advanced Concepts

Behind the scenes, Text Animator is doing a lot of work and optimization to make sure:

  • There is 0 garbage collection during animations (there is still some when the text is set, as does TMPro and also Text Animator 2.0, but we're working on it!)

  • The asset is compatible with different Unity versions, systems and platforms

  • There is an API that is as simple as possible for you (putting the pain on us, but that's the whole point!)

  • Things work even if there is a wrong setup with null references (as humanly possible)

That said, there are some key concepts inside Text Animator for Unity that are important to know when you start writing custom scripts:


Core Library

Text Animator is divided in two main namespaces:

  • The "Febucci.TextAnimatorCore" is our core library, a runtime DLL shipped inside the package and that is foundamental to make things work.

  • The "Febucci.TextAnimatorUnity" is the Unity implementation, from Scriptable Objects to Monobehaviors and more.

You will find how to set up scripts as intended in the next pages/guides, but please be careful about what you inherit, modify or re-implement!

I'll keep updating the core library to implement new features or reorganize the structure, and it's impossible to know any kind of variation and use case people might do in C# (especially if not intended) - so please follow the guides! I'll mark things internal as much as possible anyways and I'll keep the Unity implementation as backwards compatible as possible between versions (as I always did in the past years, also including an updating guide where applicable) - but if you want to do some not-planned modification do it at your own risk!

Stateless vs Referenced elements

Most Text Animator elements, from effects, actions, playbacks and curves, are implemented in two ways. One is independent from Unity and GameObjects/ScriptableObjects in general, and the other keeps references from the game state / files and classes.

Type
Pros
Cons

Stateless

  • Better optimized (also prepared for Burst in the future, TBD)

  • No race conditions between elements

  • Some code wrappers, BUT mitigated through the asset's custom classes!

  • Can't modify animations/typewriters based on the game state

Referenced

  • Can access the game state and make things happen differently based on it

  • Possible race conditions if not implemented correctly (e.g. two typewriters accessing the same action, which has a timer or makes things happen, at the same time)

  • Can't be optimized through Burst (but should be negligible in most occasions, as built-in ones do the heavy part)

We are also investigating for a way to give you Direct elements, which mean: remove all or own implementations and just let you hook things how you want (which should accomodate like the 1% of the users, given all the other tools available, but still an important option in our opinion).

  • Pros: Do it yourself.

  • Cons: Do it yourself.

It's up to you to decide how to customize your elements.

  • Opt for stateless types when you are in performance-critical context (e.g. having many letters)