Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[voliol]

In the last devlog, you pondered whether some legends should be browsable by clicking the events shown in the world generation screen. If browsable legends during world gen make it in, they should not pause the world generation when used.
It would turn browsing from something stalling your worldgen causing it to take longer, to a way to kill time while you are waiting. And as you are fun, the time passes even faster.

[kontako]

Great idea.

I do imagine some difficulty navigating through a list that's receiving tens to hundreds of updates a second though. But that may just a problem in my imagination.

Related to that same point, judging by the last sentence in the devlog, world generation might need to be paused to enable timely player interaction (in the mythy-much-later update).
That's probably remedied with a pause and play button, with pause on by default.

[Mr Crabman]

Related to that same point, judging by the last sentence in the devlog, world generation might need to be paused to enable timely player interaction (in the mythy-much-later update).

This sounds like a case where multithreading would be quite helpful and also not a massive ordeal (unlike the usual multithreading suggestions). You wouldn't be trying to separate individual events in a tangled web of cause and effect (like in fort mode), you'd just be making a browsing window in a separate thread to worldgen. Incidentally, this approach would also come with potential benefits other than just responsive windows for legends browsing, such as being able to generate multiple worlds at a time, each on its own CPU core, or even playing in an already created world while you generate a new one.

Worldgen would need to be paused occasionally to an extent if you wanted to pipe more information from the "worldgen thread" to the "legends browser thread", but this pausing could be done far less often than you would need to if you were trying to pause enough to keep a browser responsive (once every second or few seconds, vs the dozen times a second to make a browser responsive, and probably still feeling clunky).

You could also conceivably not update the legend browser automatically and just have a button to "update legends" with the new information.

[Quietust]

Related to that same point, judging by the last sentence in the devlog, world generation might need to be paused to enable timely player interaction (in the mythy-much-later update).

This sounds like a case where multithreading would be quite helpful and also not a massive ordeal (unlike the usual multithreading suggestions). You wouldn't be trying to separate individual events in a tangled web of cause and effect (like in fort mode), you'd just be making a browsing window in a separate thread to worldgen. Incidentally, this approach would also come with potential benefits other than just responsive windows for legends browsing, such as being able to generate multiple worlds at a time, each on its own CPU core, or even playing in an already created world while you generate a new one.

Worldgen would need to be paused occasionally to an extent if you wanted to pipe more information from the "worldgen thread" to the "legends browser thread", but this pausing could be done far less often than you would need to if you were trying to pause enough to keep a browser responsive (once every second or few seconds, vs the dozen times a second to make a browser responsive, and probably still feeling clunky).

You could also conceivably not update the legend browser automatically and just have a button to "update legends" with the new information.

One thing which never came up in your original thread is that before you could consider generating multiple worlds in multiple threads, the game would first need to be modified in order to allow multiple worlds to be loaded simultaneously, and that would actually require some very significant changes and likely result in a performance loss when playing with just one world (because everything would need to know which world it was looking at).

On the other hand, putting the UI on a separate thread from the actual world generation process (while still keeping it "one world at a time") would still require the addition of synchronization logic in many different places - otherwise, adding a new record to a list (e.g. a new civilization, site, historical figure, or just a history event) is likely to be non-atomic, and if the code that updates the list is interrupted by another thread, the list could very briefly end up in an inconsistent state where trying to access its contents could cause the game to crash, and even worse things could happen if worldgen tried to remove something while the UI was trying to display it (e.g. if a world got Rejected and it had to start over from scratch).

[Mr Crabman]

One thing which never came up in your original thread is that before you could consider generating multiple worlds in multiple threads, the game would first need to be modified in order to allow multiple worlds to be loaded simultaneously, and that would actually require some very significant changes and likely result in a performance loss when playing with just one world (because everything would need to know which world it was looking at).

I'm not convinced that having multiple worlds loaded at once would either be especially difficult or require "very" significant changes, or that having to know which world it's looking at would have any kind of performance hit.

Sure, there would be a slowdown of some amount if you have another world open at the same time, but certainly not if you only have one world loaded/generating, and doing multiple would sure be faster than generating the worlds one at a time (some people have actually done this by running more than one `Dwarf Fortress.exe` at a time), and as for playing in a world while others generate, this would indeed be slower both for playing and generating, but the idea is that you wouldn't just be staring at the screen (well, the new legends browsing info would make it less boring, but still).

And the performance hit while there are multiple loaded/active would have nothing at all to do with "everything needing to know which world it's looking at", it would be from bottlenecks caused by sharing the cache and RAM data channels with other worlds. I can't even tell what you mean by everything "needing to know which world it's looking at".

On the other hand, putting the UI on a separate thread from the actual world generation process (while still keeping it "one world at a time") would still require the addition of synchronization logic in many different places - otherwise, adding a new record to a list (e.g. a new civilization, site, historical figure, or just a history event) is likely to be non-atomic, and if the code that updates the list is interrupted by another thread, the list could very briefly end up in an inconsistent state where trying to access its contents could cause the game to crash, and even worse things could happen if worldgen tried to remove something while the UI was trying to display it (e.g. if a world got Rejected and it had to start over from scratch).

Well obviously synchronization logic would be needed, but I don't see why it would be in "many different places"; there's a very limited and specific set of data that needs to be sent to the UI, and it doesn't need to be sent continuously.

[Putnam]

One thing which never came up in your original thread is that before you could consider generating multiple worlds in multiple threads, the game would first need to be modified in order to allow multiple worlds to be loaded simultaneously, and that would actually require some very significant changes and likely result in a performance loss when playing with just one world (because everything would need to know which world it was looking at).

I'm not convinced that having multiple worlds loaded at once would either be especially difficult or require "very" significant changes, or that having to know which world it's looking at would have any kind of performance hit.

It would only require the `world` structure to be replaced with a pointer to `worlds[0]` or, if worlds is itself a vector of pointers, a copy of `worlds[0]`, and that would only require every single `world.` in the code to be replaced with `world->`, which surely wouldn't be horrible! In the absolute best case scenario! And actually it would probably be horrible!

Sure, there would be a slowdown of some amount if you have another world open at the same time, but certainly not if you only have one world loaded/generating, and doing multiple would sure be faster than generating the worlds one at a time (some people have actually done this by running more than one `Dwarf Fortress.exe` at a time), and as for playing in a world while others generate, this would indeed be slower both for playing and generating, but the idea is that you wouldn't just be staring at the screen (well, the new legends browsing info would make it less boring, but still).

Well, see, that's the thing, just running multiple Dwarf Fortress.exe windows at a time is an option, and even a good one, since there's command-line options to generate worlds.

Well obviously synchronization logic would be needed, but I don't see why it would be in "many different places"; there's a very limited and specific set of data that needs to be sent to the UI, and it doesn't need to be sent continuously.

You're going to need a read-writer lock for the events vector, more than likely, which severely reduces the potential gain from the threading, since you're going to want a read lock while getting the data. Of course, you probably don't actually need that and can instead send every potentially-relevant event to a channel... which apparently you have to roll your own for C++, ow.