Print

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

[Beyondrepair]

Communication is limited to (1) sending parties of dwarves and (2) sending items for trade. There's no reason entire worlds have to be kept in sync.

Depends on whether you want "let's exchange things between different worlds" or "let's share the same world and make an effort to make effects of other forts somehow visible". The latter would make more sense in terms of DF gameplay, but would need higher degrees of synchronization. About the former; I *guess* you can already write a program which performs loose exchange of items/dwarves/resources by editing memory or save files (I'm saying this without having inspected the capabilities current DF memhack libs).

Overall, for multiplayer, it's an idea that has potential (although in that case it's unrelated to enabling multicore computation). For singleplayer, I'm not really sure why you would like to run two forts at once given the amount of micromanagement (I end up spending most time paused anyway). Transferring (or probably just copying) items/creatures would always be useful for test scenarios however.

I'd find it amusing to be able to create an invasion force from one player run fort that appears as an AI-controlled hostile force at the fort of another player. Think of the possibilities for "play 1 year, then exchange armies"-games. But that goes quite far beyond "simple" in terms of the required amount of memory editing I guess, and therefore require Toady assistance, in order to integrate it in the game proper. In fact, did anyone ever suggest this? *need to check list*

[psychologicalshock]

For singleplayer, I'm not really sure why you would like to run two forts at once given the amount of micromanagement (I end up spending most time paused anyway).

I feel 200 are too few for me (I have 99% of them occupied at all times)  and I would like to be able to settle larger areas and make use of the unique resources in each one.

In fact if my fps didn't go down so severely I would up my migration limit to at least 400.

[Di]

Well, since currently df loads my twin core processor on 55%, I guess graphic part is already run on the other thread than game itself. Which means synchronizing or showing fortresses from different cores in the same interface is possible at least.
Even third party utilities like dfhack and therapist are capable of exchanging data with game and it seems highly likely that Toady has means of creating creatures out of thin air and removing them. Thus, occasional transporting creatures from one fort to the other is also doable.
I guess separating single embark wouldn't work since many things like pathing would require closer communication between sub-processes calculating different parts. But, when we get things like ever-running worldgen or other planes, I definitely don't want them being calculated on the same thread as my fort.
Of course, creatures won't be able to path to targets in the other worlds but, seriously, you don't go to ethereal realm to have a snack. Planeswalkers should have a serious reason to, well, planewalk, be it the information that a viable target is present on the other side (for ghosts and spirits), or a suicidal order from omnipresent overmind (for dwarves).


Conclusion (aka tldr):

One core for the dwarfs doomed to die,
Others for the worlds unseen, where fairies fly,
Third for the depth, where demons prowl,
One to rule them all.

[thisisjimmy]

I think OP is overestimating how difficult multithreading is.  Having dwarves pathfind in parallel is relatively straight-forward.  Syncing state in multiplayer is much more challenging.  You'll get conflicts when the processes try to save their changes to the world if you don't keep them properly synchronized.

If, as some suggested, the two fortresses exist in separate universes, then it would be much easier to implement, but not as interesting to play.