Reworking the control flow for my tactical role-playing game

[Liam McGillivray]

On Saturday, 23 March 2024 at 04:32:29 UTC, harakim wrote:
> * You should probably not do this, but it might give you some 
> ideas for later. What I would do is make a separate thread for 
> managing the UI state and push events to that thread through 
> the mailbox. I have done this once (on my third version of a 
> program) and it was by far the cleanest and something I was 
> proud of. The benefit is you can publish those same events to a 
> log and if something in your UI goes wrong, you can look at the 
> log.

I was thinking about how I can have one thread doing the 
rendering and another doing everything else, given that the 
"everything else" thread would be idle most of the time. I 
thought about giving the "everything else" thread a queue; an 
array of functions that it's tasked with going over. Every UI 
interaction would add one to the queue.

It just occurred to me that this must be what you were suggesting 
here.