Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Put world generation on a separate thread (gen multiple worlds at once!).  (Read 1665 times)

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile

So this idea is to put worldgen as a whole on a separate thread; that is, all the logic to do with generating a single world, on its own thread separate from the rest of the UI and the game.

To be clear by the way; in general, multithreading Dwarf Fortress for performance reasons is difficult because Tarn would have to separate out game (or worldgen) logic that is all tangled up in other parts, but I'm not saying to try and split up the worldgen logic (which would be hard indeed), just to split worldgen as a whole from the interface, and rendering is already on a different thread to the rest of the game anyway (so it's not like Tarn hasn't used threading before).

So, with some UI changes/new options, putting worldgen on a thread could have some great benefits:

1a. You could generate multiple worlds at once, so if you tend to be picky about the worlds you like, or even if you want multiple worlds and to keep/use them all; instead of creating 1, and then another after that's done, and another, you could instead do several at a time (depending on how many cores you have). This would apply for both regular and advanced worldgen, and you could generate batches of worlds with the same settings, or worlds with different settings.

2. You could leave the worldgen screen while it's generating, and play in an already generated world as you wait (maybe you could even get a popup notification ingame telling you when a world is finished).

3a. You could possibly more easily pause worldgen than now as the interface could be more responsive.

3b. Currently you can only look around the world map while worldgen is paused, but this would potentially allow you to do that without pausing.

3c. It would facilitate implementing a "baby legends mode" for world gen; Tarn has brought this up in a FoTF reply before (http://www.bay12forums.com/smf/index.php?topic=169696.msg8148050;topicseen#msg8148050), and with the other benefits of threading above, this definitely seems like the best way to do it (rather than the mentioned alternative of splitting up the worldgen logic to check for inputs more often, which seems like it would also slow down worldgen).

DwarfStar

  • Bay Watcher
    • View Profile

Seems like you could do this with a third party utility easily enough. You could set up world gen jobs in virtual machines and run them wherever you want. Separate processors locally, a server, or even the cloud. In fact you don’t need a utility, just the know-how...but it could probably be wrapped up in a nifty GUI. In fact I bet someone has already done it, but I googled for ten seconds and didn’t find it yet.
Logged

Starver

  • Bay Watcher
    • View Profile

How often does everykne worldgen? How much of everyone's time would it actually save?

(I may be biased. I always used to enjoy running a worldgen overnight/while I was out at work and then looking forward to having a usable game when I came back to the machine, maybe then making a pre-Embark/pre-Adventure copy just in case I wanted to quickly go from the start again due to early bad Embark/Adventuring decisions or fortunes.)

That said, I also think you can already run a side-copy (or multiple ones) purely for worldgenning whilst also playing on a primary one, then drag any satisfactory starter-saves into your primary save directory.

It'd be roughly as resource-intensive as forking out to multiple threads from a single MCP, although lack inter-fork communication so that your active game could conceivably signal "Hold on, bretheren... I've got a magmaflood going on, could you throttle back on your histories for a short time while I personally deal with a lot of temperatures and fluids? Cheers!" ;)
Logged

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile

Seems like you could do this with a third party utility easily enough. You could set up world gen jobs in virtual machines and run them wherever you want. Separate processors locally, a server, or even the cloud. In fact you don’t need a utility, just the know-how...but it could probably be wrapped up in a nifty GUI. In fact I bet someone has already done it, but I googled for ten seconds and didn’t find it yet.

You could do the 1st and 2nd points for sure (I've seen someone on Reddit just resort to running multiple DF processes at once I think), but 3 is something Tarn has expressed interest in doing before, with 2 alternative methods to accomplish (multithreading, and checking for inputs more often than once per year of worldgen), and I think the 1st and 2nd points becoming a vanilla function (which inherently makes it more accessible to people than a utility) is good reason to vastly favor the threading option.

How often does everykne worldgen? How much of everyone's time would it actually save?

(I may be biased. I always used to enjoy running a worldgen overnight/while I was out at work and then looking forward to having a usable game when I came back to the machine, maybe then making a pre-Embark/pre-Adventure copy just in case I wanted to quickly go from the start again due to early bad Embark/Adventuring decisions or fortunes.)

That said, I also think you can already run a side-copy (or multiple ones) purely for worldgenning whilst also playing on a primary one, then drag any satisfactory starter-saves into your primary save directory.

It'd be roughly as resource-intensive as forking out to multiple threads from a single MCP, although lack inter-fork communication so that your active game could conceivably signal "Hold on, bretheren... I've got a magmaflood going on, could you throttle back on your histories for a short time while I personally deal with a lot of temperatures and fluids? Cheers!" ;)

It can be done with side copies ATM I think, but as said to DwarfStar, saving time isn't the only benefit/factor, and having such features built into the game is also good UX (which going forward from the Steam update, is something Toady cares about/prioritizes higher than before).

DwarfStar

  • Bay Watcher
    • View Profile

It's a valid point that running the world gen on a thread in game would make the interface more responsive.

But, it's also a valid point that maybe it's not the most valuable change we could ask for. In fact, it's definitely not the most valuable multithreading change we could ask for. Running the path finding, fluid, or temperature updates to another (or multiple) threads would have a huge impact on the user experience of the game itself. Of course each of those are individually huge rewrites. But the benefits would be enormous. I wonder if you could simulate a fortress with 1000 citizens?

Another in-between idea would be to move the user interface to another thread whether you're doing world gen or playing the game. That would in theory allow scrolling and clicking (and cancelling world gen) to remain as responsive regardless of the update FPS of the game.
Logged

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile

It's a valid point that running the world gen on a thread in game would make the interface more responsive.

But, it's also a valid point that maybe it's not the most valuable change we could ask for. In fact, it's definitely not the most valuable multithreading change we could ask for. Running the path finding, fluid, or temperature updates to another (or multiple) threads would have a huge impact on the user experience of the game itself. Of course each of those are individually huge rewrites. But the benefits would be enormous. I wonder if you could simulate a fortress with 1000 citizens?

True, those multithreading improvements for the actual game would be more important and given the choice I'd pick them over this, but as you note, those would be big rewrites, whereas this is a much lower hanging fruit since it doesn't involve splitting up entangled functions.

Another in-between idea would be to move the user interface to another thread whether you're doing world gen or playing the game. That would in theory allow scrolling and clicking (and cancelling world gen) to remain as responsive regardless of the update FPS of the game.

Actually, yeah, this is probably a better/more generalized idea. Ideally then, the game itself, the interface, and worldgen, would all be on separate threads (though even more ideally as you note, the game itself would be multiple threads).

Shonai_Dweller

  • Bay Watcher
    • View Profile

Come Mythgen, I can see having an interactive interface to browse the world and especially the Mythgen output while worldgen gets on with churning out history quite valuable. Think Toady mentioned it himself some time back.
Logged