The Approach, and API Overloads
When a floatie is created it will pull the runtime configuration and randomize it's offset goal data within those constraints. Later, when you call it for use it will use the curves in the runtime component to blend from the provided start position to the goal position that it cached. As you pop more floaties it will appear as if they are fresh and random when really it's just a pool of them being recycled with efficient cached data.
That's the primary approach to popping floaties. This code will use all of the behavior that is defined in the runtime component.
There are a few overloads, though.
This gives you a lot of flexibility over how you want floaties to spawn, so take advantage of them to optimize your experience and your performance.
In the end, these static methods will call a method on a particular floatie and provide it with a string
value. In order to reduce garbage by formatting strings every time you pop a floatie you can take advantage of caching an array of numbers, the hardcoded value is 10000. If you're looking for highest performance then avoiding Kilo Formatting and values over the hardcoded cache number is recommended. If you don't have a performance concern because of low volume or whatever then this is a non-issue and you can use whatever you prefer.
Kilo Formatting is where input of '123000' becomes '123K'.
Basically...
Zero garbage produced: Pass int values less than cached limit, do not use kilo formatting.
More garbage produced: Kilo Formatting and lots of custom strings. Cache is unused.
Directional overloads
There is a special overload in which you can provide a velocity Vector3 and the floatie will ignore the cached random offset goals and will instead throw itself in the given direction. This is a nice option for critical hits, custom text, or just improving gameplay feedback instead of just having text popping up in semi-random directions.
Last updated