IF System that allows for slightly complex simulations?

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.


@inventor200 Thank you for this insight. How did your orbital simulation work out?

I’m fine with fixed point math. I will take a look. There are thoughts where I could just use a bit of randomness instead of a simulation - still working on some of this.

It’s good to know with some limitatons this could be done in TADS. For myself, I was hoping to stay in one of the main system.

1 Like

So I need to preface this by saying I have severe ADHD, and my meds only do so much, so I got far enough to understand that it’s definitely possible. I approached it from a weird direction, regarding its code structure. However, I created a similar system afterward, which can handle extreme distances of thousands of kilometers pretty easily with good precision and no speed cost, but the game that uses that is still a WIP while I wrestle mental demons and life demands.

It is a module, though, so I could post what I have so far to my GitHub, if you’re interested, but again I can’t promise it’ll be actively maintained.

TADS can be a “main system” if more authors and devs see its potential and hop aboard. :grin:

1 Like

Inform 7 has built in floating point math functions. So it certainly could do any simulation you want it to do, the only question is whether it’s efficient enough. And if the performance is poor, it could be improved by dipping into I6 (calling the maths opcodes directly will be more performant than calling them via functions.)

Do you already have in mind what precise simulations you want to run? Is your model something that you’d define with equations but haven’t thought about code yet? Or would you most naturally program it in some other programming language, and converting it to an IF language is the issue? Or would you want to be using something like Box2D, and the lack of simulation libraries is the issue?

1 Like

The main idea I am playing with is around water movement and impact on items - for instance, something dropped into a stream and how something might move through the game, how it might get lodged/found/etc. So it would be more a passive/background impact on game state as the user moves along.

Something I am playing with in Python right now plus some other ideas led me to think about how this might work in a game. I could punt and do something with percentages / random. My main concern is more sticking in an existing IF system and what is possible.


If you wanted to do fluid mechanics for real, that would be both a taxing amount of computation, and a fine-grained degree of simulation that may not be the best fit for a text game where we tend to be fuzzy on things like which way people are facing and the exact relative positions of things in the same room.

How many forks are there in this stream? Through how many rooms does it run? Would the player have any better an experience with simulated fluid mechanics than with a simple-minded percentages / random scheme?

Now you’ll be spending more time with the game than any player; if you feel like doing it 'cause it sounds fun, then by all means, do it! And if you did it in Javascript or Python you’d be fine. But if you want to use Inform or (from what Joey says) TADS, you’d probably be better off with the simple scheme.


Thanks, yeah. The story I am sketching out is more important than little dynamic things like this, but was curious.


One of the things in my original thoughts was is the ability to do some simplified model to help a story along - not too compute intensive - might be also possible so long as it’s not super heavy per turn.


So I am going to throw my system, Rez, into the ring because I specifically built it to create games that were part simulation/part narrative driven.

Rez has a declarative format and uses JS functions for dynamic behaviour & layout, and is event driven.

More to the point it lets the author define “system” components that respond to (or modify) events and their response. This infrastructure is designed to run simulation elements alongside the narrative elements.

In my case it’s mainly for creating more responsive environment and NPC’s (for example, a system running actor behaviour trees).

Depending on whether this is meant to be semi-real-time you could use a timer element to fire events that drive the physics simulation system. This system can then force updates on the UI so the player sees things change.

For example: tag any object that needs to do physics with a :physics tag. Use a @timer with a 0.1s (I don’t know what’s reasonable) resolution raising an event your physics system responds to. It iterates all tagged objects and sends them a :physics_update event to update their state, then tells the UI to redraw.

Caveat #1: Is JS’s IEEE 754 floating point representation suitable for something like a physics simulation? I’ve no reason to think it isn’t but YMMV. Most JS engines are pretty well optimised at this point.

Caveat #2: Although I’ve been working on it, on and off, for about 2 years it’s still “new” and not proven. I have several games in bits but nothing finished. That said they have allowed me to test & flesh out parts of it so it’s usable. Also you are more or less guaranteed 1:1 support from the dev :slight_smile:

Edit: Thought I would see if it works and it more or less does. The challenge in the browser is that the timer events are running on the UI thread so if you run them too fast (for fun I am trying to run this at 25FPS) it blocks interaction with the UI.


I think working on a cookbook or set of examples for Inform/TADS could be an interesting one…implementing fixed point math/etc to make it easy to do so.