So, in brief, TADS allows you a while amount of precision for math and the ability to completely modify everything down to core functions lets you basically make whatever kind of game you want, and leverage the math for it.

There is a problem, though.

In what I suspect was an effort to make TADS deterministic and cross-platform on a lot of older computer systems, the language does not do non-integer math directly in the CPU, and does not seem to insist on a specific IEEE standard for computation.

As a result, all non-integer (or *floating-point*) math is done further away from the CPU and deeper inside the TADS runner. Every time a new floating point number is created/calculated/used, a brand-new object is created. This means a lot of objects being thrown into garbage collection. Additionally, the precision of floating point in TADS is absolutely insane sometimes, so computations are laborious under the hood.

All of this means that if you are using non-integer math quit a lot in a single turn, a modern, C+±based TADS interpreter on a beefy computer will be delaying about 5 seconds before the upcoming text prints, and this gets more extreme on other configs.

So what needs to happen is you gotta decide what precision you would like to use for your numbers, and use some **fixed-point math tricks with integers** to handle your stuff (like they use in *Doom*), because math performed using integer data is lightning-fast. You basically shift your integer to the right by something like 8 bits, do the math, and then shift it left by 8 bits when you need to simulate a rounding operation.

If you just need the occasional floating-point calculation, it’s fine. But if you’re running maybe a hundred of them in a turn, you’re gonna see slowdown. Fixed-point math using integers will save you.

TADS, overall, has a lot of power and execution tricks for deep simulation, if that’s what you’re looking for.