hey hi, the project im working on is an incrementa...

# ballast

[abbic]

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?

[abbic]

a fixed-time loop could maybe work, but if it ever started dispatching events faster than they could be processed id be donezo

[Casey Brooks]

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.

[Casey Brooks]

Or alternatively, the pattern shown in the Gist could just be expanded out so that everything is being processed in one giant VM, which might make it a bit easier to develop (though, probably harder to read). And in fact, it might be better to start with everything in a single VM so you can get to understand how things should be processing and how the various bits of data relate to one another, and from there you can break pieces out into their own VMs and get them structured and communicating with each other as-needed per the game logic

[abbic]

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

[Casey Brooks]

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.

[abbic]

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