hey hi, the project im working on is an incremental game (think cookie clicker) so theres going to be a fair amount of time based logic, like production of resources per second on an update loop. the way ballast has me set up im struggling to conceptualise any kind of classic game loop where i have delta time between updates, because there are so many suspend functions and indirect Event dispatching, potentially across multiple repos, it would for example be hard for me to figure out when a state-wide update has been successfully completed. any idea how to tame this kind of logic?

On the contrary, I think Ballast can actually help make the game logic clearer without having the traditional “game loop”. I tend to enjoy playing these kinds of games, and have though about making one myself (I’m just not creative enough to make one that’s actually fun 😜). Ballast probably wouldn’t work well with most games, but I think incremental/clicker games, and point-and-click adventure games would both work very well modeled in Ballast rather than with traditional game logic. I threw together a Gist that might help you see how this might work. The idea would be that each component that is auto-clicking would have its own ViewModel and can run on its own timer (or be synchronized from an external Flow, for example). https://gist.github.com/cjbrooks12/f54e9f0ff10f8c6c9d7d553b5e8e9ce7 From there, it’s a problem of modeling which VMs are talking to the others, and using the Repository Pattern the same as a traditional app might be a way to manage that kind of communication.

thank you! i'll have to get my hands dirty a bit and try build up an intuition. funnily enough i was on an incremental dev discord and apparently there theyd had a discussion about redux and vue, and overall they had dismissed the approaches dues to incremental games needing way more state changes than your traditional business app. but my initial intuition was indeed that using ballast would help me avoid bugs and reason about game logic in a helpful manner

It’s entirely possible that this approach doesn’t pan out in the long-term, as I haven’t made one and I don’t know how well Ballast/Coroutines will hold up to the scale needed for these games. But my intuition is that it should work fine, especially if you apply more traditional software-development principles rather than game-dev principles. There’s nothing saying the UI needs to be perfectly synchronized with the auto-update logic, it should be totally fine to have a 60FPS UI that’s just reading StateFlows, which may update much less frequently to optimize the whole app’s memory, CPU, etc.

tbh despite my concerns it should be a long time before performance ever becomes a real issue