I have an idea about a framework/modelling being a...

# random

[mcpiroman]

I have an idea about a framework/modelling being an alternative to the traditional progression of state through the tick() or update() method called each frame, especially in logic heavy games.
The thing is, (if it's even possible to implement), it's bound to be already known, have it's own name, etc. Maybe you've heard of it, maybe just have some thoughts about it? It's not kotlin related, though, it should work very nicely with kotlin.
Description in 🧵

[mcpiroman]

The main problem with tick-based approach is that as you progress, the state is partially updated and partially stale. You have to order and constrain the updates as so not to use some part of the old state with the new one where the invariants might be broken. Secondly, you may end up with a frame that is not invariant (this may be visible if you can pause the game - e.g. a character is dead but it still occupies a slot or gives a bonus to the team, because that check happened before the one which dealt him damage).

My idea is to instead of the tick methods have a set of 'transformer' functions. They are similar to tick but more gradual. They aren't called manually, instead, whenever some of the state's variables they read (input) changes, they are automatically invoked. Then, based on the input they change some other variables (output), making a chain of reactions. The framework knows how to dispatch that because every write and read from a variable is tracked - say they are delegated properties with custom write and read methods. It can deduce the input of a given transformer based on what it has read previously - in the exact same way as derivedStateOf in Compose. Even with frames - you just increase the currentTime variable each frame and everything that depends on the time will be recalculated.

The thing is - the input tracking is the easy part, I know it will work. But it's not the root of the algorithm, just a (very important) optimization. You could just call every transformer each time and the result will be the same - if none of the inputs changed the output will be the same. The hard part is that because you can't run everything at the same time, when some state changes, there has to be a queue of transformers that depend on it, they have to be called in some order, and they may overwrite what the previous ones have written. Worst, there may not even be the ideal order - if an entity takes a critical damage and is healed in the same frame, will it live or not? So the framework would need to, based on individual reads and writes, determine how to call all the transformers in such a way to automatically avoid broken invariants, possibly undoing or suspending them (suspend functions intensify).

I hope this makes any sense. I know the idea sounds crazy but it looks like it can be achieved (it's more complicated than I have wrote though), I've even started writing a prototype. If you know of any resource about something like that (I don't even know how to start searching) or have any thoughts, pleas let me know!