Print

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

[Ter13]

I'm not a programmer, so forgive me if what you are talking about is more along the lines of how dfhack goes about things, which I believe is okay with Toady. Although, I still get a sense that he feels uneasy about even dfhack, even without him saying so, but I have no evidence of this. I believe that impression was given to me in the RPPR podcast.

First of all, I do forgive you for your jumping to conclusions based on two words, and their general connotation.
Second, Indeed. I'm an evidence guy. I don't get that impression from the same posts and talks. I get the impression that the community only tolerates the use of things like DFHack because the game is essentially broken in some way every time its released. I think your view of some of this, is actually a general impression that the community looks down at anyone who doesn't play the game their way, because they just aren't as dwarfy as they are.

The next thing that I will correct you on, is reverse engineering in the context it was used. I would never run a decompiler to figure out HOW the files are saved. Nor would I have to. One does not have to understand, in programming, how a file is saved to understand what order the data is written in. One merely has to understand the possible data types, and logically apply it in practice, then compare by observation of the game and multiple types of data file until most of everything is understood by a process of deliberately changing it to see what happens, by comparing the difference between different game saves, etc. This is doable without ever decompiling any of Toady's actual code. I don't think Toady should go open-source, but I do believe that Toady needs to do everything in his power to support the modding community, because without them, half the people here would simply never play his game. Without tools like Dwarf Therapist (Which depend on the efforts of the developers of DFHack, who had to go through a very similar process to this, his game would simply not be playable.

My point about mentioning the time travel remark is that I get the impression that the amount of work required on his end for some of your methods would be along the lines of implementing time travel, because of how detailed, intricate and extensive an untouched world history can be, let alone one that more than one player is affecting.

I have outlined a sensible method for dealing with the time-travel problem. I have considered the idea of time travel in a videogame. It is simply not doable on a certain scale in a game like DF. I would never attempt it. As such, I feel that I should mention that you have probably not seen all the way into my thought process on the matter. I have allowed for inconsistencies and anachronisms to exist, but we find a way to brute force cull them by simply saying: First fortress to be abandoned and report that it happened is where it really happened, that way the anachronisms do not present themselves as a problem for the player, only to the server, whose job is only to maintain the list of events.

The words "reverse engineer" has put me in defensive mode towards your ideas and I admit to that, but even without those words, maybe you should provide Toady with the same gesture.

File formats are not a legally defensible medium. Toady has no right to defend his data files from snooping. He does have a right to the integrity of his source code. I think, if you recall, I mentioned that I decompiled and deobfuscated Minecraft. I did so, and never released the source code out of respect to Markus Persson, someone who, as a programmer, I actually respect, and also as a developer. I've been following Notch since early in his career, while he was writing the client for Wurm Online. Personally, after stepping into his shoes over at Wurm for a short time, and modifying the JoXSI project, I don't think he's a great programmer at all, but he is rather clever with perlin noise functions.

All I want from Toady is essentially an XML file released with each version of DF that contains where, in the data files the game saves, certain statistics and in what format these statistics are stored. This will reveal almost nothing of the internal workings of his game, on the grand scope of things, but will empower the modding community. I should also mention just how little variety there is in these data files. I highly doubt that the type of data saved in the world is actually very diverse. Most of it probably is JUST data like legends, and user-modified terrain, animal populations, etc. Legends have to follow a fairly simple data serialization format, or they wouldn't be able to be saved into a file. Literally, Toady would only have to likely spend a few hours at most going through his data serialization code, and writing us a single XML snippet to give us the remainder of the information that is necessary, and he has honestly done 90% of the work for us already by implementing a legends XML dump in the first place in the existing game client.

On a lighter note and a bit off topic, I enjoyed your Murderhold story.

Indeed. I'm currently working on a new fortress of similar rules. Started it this week in DF2010. Thanks for taking the time to respond. Though we don't see eye to eye on many levels, I still respect your opinion on the matter, but I also do agree that respect to Toady's wishes are important. We just have a different memory of the things he's said in the past. It will be interesting to see it play out, and see who is correct in this matter.

[Girlinhat]

I TL;DR'd the individual ideas, but I skimmed them to get an idea.  My thoughts are that first, we Praise be to Carnes for granting us with a hotseat multiplayer DF.  It's basically Idea #2, and to me, the only realistic option.  The issue with DF is two things, which basically come down to one things.  The first is obviously pausing.  Any attempt to synch games together gets rough when one player is paused.  I could expand on that, but we're all reasonably intelligent and I assume you can figure out how this would cause a host of problems for any multiplayer attempt.  The second is FPS, because not all machines are built equally, nor are they all running the same CPU-hogging background programs.  If my FPS is 50 and yours is 100, then synching the game is going to get very hairy for one of us, if not both.  Which ultimately combines the two issues into one: Time.  DF has a variable and easily manipulated timescale, and that lends itself to great singleplayer, and hellish multiplayer.

Without major structural changes from Toady, then I think Carnes' hotseat program is pretty much the only thing that's going to work.  This also ties into the previously mentioned source-code tinkering.  I think using hacked memory to synchronize display data might be worthwhile - that's pretty much what Carnes has done in a different sense, but beyond that you're getting a little bit into "what's morally ok" and also "what's legally ok".

In other words - we have a basic MP setup, which is more than we had a month ago.  Don't expect Toady to make allowances for MP because we want it.  He'll do that when and IF he ever decides to make MP easier.  For now, as with every other modding attempt, use what you can and enjoy it.

[Ter13]

In all three I provide in-depth details of why your skimming has given you the incorrect assumption that I have not worked through these problems to find viable solutions. Please don't TL;DR. I proposed solutions to your points.

[Putnam]

In other words - we have a basic MP setup, which is more than we had a month ago.  Don't expect Toady to make allowances for MP because we want it.  He'll do that when and IF he ever decides to make MP easier.  For now, as with every other modding attempt, use what you can and enjoy it.

DFTerm has been around since march or earlier >_>

[Lectorog]

In other words - we have a basic MP setup, which is more than we had a month ago.  Don't expect Toady to make allowances for MP because we want it.  He'll do that when and IF he ever decides to make MP easier.  For now, as with every other modding attempt, use what you can and enjoy it.

DFTerm has been around since march or earlier >_>

But nobody bothered to configure it for easy and (relatively) stable multiplayer before then. People could've played multiplayer, and did in isolated sessions, but DF:MP is the first "official" multiplayer.

[Zeranamu]

In other words - we have a basic MP setup, which is more than we had a month ago.  Don't expect Toady to make allowances for MP because we want it.  He'll do that when and IF he ever decides to make MP easier.  For now, as with every other modding attempt, use what you can and enjoy it.

DFTerm has been around since march or earlier >_>

But nobody bothered to configure it for easy and (relatively) stable multiplayer before then. People could've played multiplayer, and did in isolated sessions, but DF:MP is the first "official" multiplayer.

Aye, and me and Carnes have worked on it to make it more than it was, which is saying something in and of itself. Hopefully, if all goes well, it'll morph itself into something even more fantabulous.

[Carnes]

IMO, Any tool that helps connect forts or players together makes the game multiplayer. 

My thoughts on DF as a multiplayer experience and your proposals:

Spoiler (click to show/hide)

As DF is a "story-telling" game i believe the multiplayer experience to be a social thing and not a competitive one.    So your idea of map "sharing" seems very well pointed (proposal 1).  A website or utility that lets people grab an embark and when the fort dies or is abandoned, it is saved to the global map for others to see would be amazing.. and you are right, adventurers would LOVE it.  It would instantly become a legendary app for adventurers.

Multiple players on one site sounds excellent but i believe it isn't possible yet.  Treating DF like a database/server of sorts where you just store data by writing to memory locations and fetch updates isn't going to be fast enough.  DFHack is awesome, but i think you would have to create a middle-layer anyways.. a cache of sorts, to limit all the reads/writes to DF.  Also, the client will have to replicate every menu.  Any DF menu that pauses the game (trade, military, designating, soo many) will have to be re-made in the new client.  These tasks are then written to the DF cache layer, sent to other players, and important parts written to DF memory.  That is technical stuff.  You have basically made a new game mode.  But you still don't have two forts yet.  There is only one dwarf resource pool.  You would have to burrow every dwarf and filter dwarf lists on the client end to only display and allow editing to dwarves your fort owns and not another fort.  When traders come, which trade depot do they visit?  Proposal 2 is a huge undertaking.  However!  If you want to shoot for proposal 2, try fulfilling some user requests for better UI with DF embedded inside the UI client to gain support for your larger project (which is still very ambitious!).

In summary, i think your ideas are VERY good but overly ambitious at this time.  You will get a lot more support and less skepticism/hostility if you start smaller and less aggressive. 

My plans for DFMP:

Spoiler (click to show/hide)

For example, i too have plans for a better multiplayer experience.  Though our ideas are very different.  I want to create a fun social experience.  Having only one input via DFTerm is limiting, i agree with you.  However those are the limits i will work within for now.  I want to create a whole suite of web tools for interacting with the DFTerm game.  Starting with a Dwarf Therapist like utility, i am making Analyst (as pictured below).  Next comes Personalization.. people love to dwarf themselves and share in the story.  I will ride on this.. i will create a literal avatar-like representation of your dwarf, in real-time.  It will be rendered as an image that you can embed in any website or forum.. each time the image is read the character is regenerated to it's newest state.  The image will show armor, the lack of any arms, any wounds, hair color, and all sorts of physical features that are described by toady and mostly disregarded.  Any mention of your dwarf on an engraving, artifact, or statue will be brought to your attention so you can bask in the glory of the moment.  The game itself to overly rich with content.. and so much of it goes unused because the specifics you crave to know are tedious to extract.  They need to be filtered and brought to your attention!  There isn't only one story in a game of DF.. there are almost countless! Each pointed in different directions and not all of them are interesting to everyone.  There will be more utilities after that.. a designation utility for constructions and digging (so time consuming during DFMP).

Anyways, tl;dr: Your ideas are great, but perhaps cut them down a bit and gain some support?  Lots of people are making things.  Use their ideas and help, even if it's not exactly what you are planning.  Feel free to completely disregard my advice if you'd like.. it would not offend me or anyone.  Some people can toil away on mega-projects in the dark.  I however, am not one of those people and prefer tasks that i can accomplish in a reasonable amount of time.

PS: I didn't make any single component of DFMP (Analyst will be the first big part).  However the list isn't so long that i can't name the poeple who get credit.  Toady One, Adeon(DFTerm), Elvang(ttf tilesets), LordMogra(Cootue ttf), Simon Tatham(putty), Peterix (DFHack), Zeranamu (DFMP configs).  All i did is package it up and configure things to make it easy to use/play.  That is something that anyone could have done, so though it isn't an accomplishment, it is important.

Picture of Analyst.. still a work in progress but coming along nicely!

Spoiler (click to show/hide)

[Putnam]

Spoiler (click to show/hide)

For example, i too have plans for a better multiplayer experience.  Though our ideas are very different.  I want to create a fun social experience.  Having only one input via DFTerm is limiting, i agree with you.  However those are the limits i will work within for now.  I want to create a whole suite of web tools for interacting with the DFTerm game.  Starting with a Dwarf Therapist like utility, i am making Analyst (as pictured below).  Next comes Personalization.. people love to dwarf themselves and share in the story.  I will ride on this.. i will create a literal avatar-like representation of your dwarf, in real-time.  It will be rendered as an image that you can embed in any website or forum.. each time the image is read the character is regenerated to it's newest state.  The image will show armor, the lack of any arms, any wounds, hair color, and all sorts of physical features that are described by toady and mostly disregarded.  Any mention of your dwarf on an engraving, artifact, or statue will be brought to your attention so you can bask in the glory of the moment.  The game itself to overly rich with content.. and so much of it goes unused because the specifics you crave to know are tedious to extract.  They need to be filtered and brought to your attention!  There isn't only one story in a game of DF.. there are almost countless! Each pointed in different directions and not all of them are interesting to everyone.  There will be more utilities after that.. a designation utility for constructions and digging (so time consuming during DFMP).

I fucking love you.

[Ter13]

Thanks for the input Carnes. This thread wasn't an actual attempt to outline what I was looking to do. I just hear a lot of people talking about DFMulti, and I hear a lot of banter from both camps that is factually incorrect about the feasibility of the idea. In the end, I just wanted to outline how such an idea was possible, and why such an idea would be a good one.

I think people get too distracted with the idea of true multiplayer, and wind up making the wrong sort of proposals. In this case, I'm more interested in enhancing the current gameplay. In particular, finding some way of merging peoples' fortresses and whatnot, so that we get functional worlds. Personally, I think I'm going to try to write some kind of a simple site-merger, and try to separate out the legends and whatnot at first. Then see if I can convince toady to start saving player-created legends in such a way that the worlds can utilize them based on the site. That way, when we merge the sites, legends themselves transfer... Figure I might contact Toady about that at some point.

But again, thanks Carnes. Good to see what you've done for the DFTerm project. Making it accessible is just as important a task as making it in the first place. A project with no users is effectively not a project at all. --And thanks for being one of the small number of people who get the idea that DF is already a social game. Half the fun is in sharing your creations with others and communicating about your world.

[ChaotikDwarf]

I liked a lot the 3rd idea and i really don't see why you see this as hard to do
(i'm making somes assumptions here about the game that could be false, mainly the fact that we can interrupt the main loop without problem, which would work if the game is mono-threaded, it could be more complex otherwise)

We just have to take over the main loop, and rewrite the PRNG seed in each client

You said in your post :

Get Toady to set stable/predictable PRNGs for worlds.

unless the PRNG seed is modified  by an external source (gettickcount/rdtsc/something like that)
it is by definition stable and predictable
even if the seed was changing each turn, we would just have to rewrite it with our own value
if it's changing more often, you can just redirect the offending code to your own function, and make it change each X turns(hoping it's not inlined)


my point with all of that :
i don't see where the problem is with keeping PRNG synchronized if all user input are used at the very same moment on all client
which could be easy , if we stop the main loop.

Sorry for any incorrect english up there, it's not my native language.

[Ter13]

I liked a lot the 3rd idea and i really don't see why you see this as hard to do
(i'm making somes assumptions here about the game that could be false, mainly the fact that we can interrupt the main loop without problem, which would work if the game is mono-threaded, it could be more complex otherwise)

We just have to take over the main loop, and rewrite the PRNG seed in each client

You said in your post :

Get Toady to set stable/predictable PRNGs for worlds.

unless the PRNG seed is modified  by an external source (gettickcount/rdtsc/something like that)
it is by definition stable and predictable
even if the seed was changing each turn, we would just have to rewrite it with our own value
if it's changing more often, you can just redirect the offending code to your own function, and make it change each X turns(hoping it's not inlined)


my point with all of that :
i don't see where the problem is with keeping PRNG synchronized if all user input are used at the very same moment on all client
which could be easy , if we stop the main loop.

Sorry for any incorrect english up there, it's not my native language.

The real issue is desynchronization. I have done some research into synchronized RNGs and the only programs that utilize this kind of an idea are relatively simple. The big worry is that our program being only 99.99% accurate, we end up with a big problem very quickly, because we can't "undo" what went wrong on the fly.

[Starver]

While I'm not particularly sure about certain aspects of "Going Multiplayer", can I put forward a variation on Method 2 for at least general disagreement with.

Each player is given domain over a subset of the dwarven population.  The client's interface with the "master game controller" program will only let the player alter (say, if the player is allocated just one character) a single dwarf's job allocations, only allow that dwarf to be added/removed from burrows by that player, and similar restrictions when it comes to joining a free military-unit slot, or moving into a new one in a different (existing) unit.

Squad leadership excepted... as mentioned far below.  And there is another exception of compartmentalisation when it comes to military units, in that the squad leader's controlling player has control over training/patrolling schedules and full-squad order designation (although this latter can be over-ridden by per-dwarf redesignation by the controller(s) of the subordinate members of the unit), but that's mostly due to the dependencies of actions involved when military needs are at the forefront, and there's always resignation/unit-shuffling available in the event of a disagreement by the subordinate.

Assignments such as to-be-dug tiles, furniture emplacement, etc, are free actions, as other players who have mining/furniture hauling/whatever enabled for their character(s) should be able to prevent them wandering off through burrow assignment.  To this end, there should maybe be two different styles of burrows...  "Public Domain" ones open to change (excepting dwarf membership) by anyone and "Personal" ones that once created by a given player are solely their own to change (though not to view).  This way there can be a combined effort to maintain a "This is inside"-style burrow or a "This is where the food and refectory is" one (at least as long as no-one takes the urine and forces the others to maintain their own private versions of it), but "Player2's Mining Operation" cannot be messed about with by any-one (at least not programmatically, there's always various forms of sabotage by otherwise-controlled characters).  This does not mean two different types of burrow to the "core DF program", merely that the coordinating server program is told of the distinction by the client programs, and keeps track of all that like it does everything else.  Burrow removal follows the same rules insofar as who is allowed to enact them.

A further server option could be that a pre-defined area (or, indeed, volume) of the map can be set to be dug/modified by each respective game character's player, with perhaps a form of horse-trading/mutual-consent allowing the shifting/sharing of various areas.

Other than the aforementioned tracking and partitioning of control, there's very little difference between this concept and the original Method 2.  Minimap (or other representative) tracking of each player's views and actions upon the world, basic chat (aside from the obvious idea of scrawling messages in the rock with as yet unfulfilled digging designations, to various ends from shout-outs to out-right insults, I foresee) for task coordination purposes, handling the pausing situation and a whole lot of peeking/poking by the DFHack-inspired game coordination server are the order of the day.


There are finer details to be worked out that might be necessary with regard to the potential for griefing players.  e.g. should there be a free-for-all when it comes to furniture emplacement (also forbidding, dumping or even melt-designating of items)?  Or some restriction (perhaps permission to use, by the player whose character created the artefact throne) to prevent someone claiming all the marble statues intended by another to decorate the noble's bedroom (the noble possibly being being 'controlled' by a third-party, profoundly apologetic for the demands it just made)?  Although I do wish to see it having the more optomistic approach of each player keeping an eye on their character(s) and the stock situation and asking "Has anyone been making booze recently, I've got a carpenter here who's feeling withdrawal symptoms".  Perhaps eliciting the reply "Whoops, I forgot to ask you for more barrels!"

Ditto some thought to be put into whether one player's built forge should need permissions (again applied through the client to the coordinator process, and still invisible to the main DF engine) for another player to designate the likes of metal bucket manufacture, or shuffling the jobs around within it.  "Job Manager" jobs might be interesting, and perhaps at least have some kind of pre-emptive yay-or-nay job management function assigned to the player who controls the Manager dwarf character.  Noble assignments themselves are restricted to the current expedition leader/mayor/equivalent (according to level, or indeed who is considered nominally the first in line to command of a fortress where !FUN! may have done for the obvious candidate) for all the non-military and primary military appointment, this latter then having domain over creation of new squad-leaders.  This of course requires thought as to the cooperative (or otherwise) play required at the point that the single-player version is browsing through the embark scheme.  Perhaps this would normally involve chat-style discussions of who has the best miner/military/woodworker/leader types, and then individual point assignments however each player thinks (with the ability to review, but not change, other-player-characters) although of course changes to the goods to be carried (also affecting the points available to the embarkees) would have to be negotiated in some way.  Whether that ends up with "I'm vetoing all booze until one of you two stops trying to hog the social skills!" or something a lot more civilised might indicate what kind of game this ends up starting as.

I could also foresee a "seven hermit site" being either deliberately or inadvertently pursued from the start.  And the deliberate version of this might be a mini-competition.  Such as "dig your own hole [having arranged for at least one pick each?], get your own resources, the aim is to be the first one to have ten goblin invaders on their kill-list".  The less amiable (perhaps unplanned) version might involve becoming the sole surviving dwarf after creating problems for the other hermits anywhere from 'accidental' magma-flooding of their fields to sabotage/by-passing the various defences to allow the siege to incapacitate all others.  But don't forget that the 'winner' would also have had to keep themselves fed and boozed-up sufficiently, and avoid the machinations of everyone else at the same time.


Also, at some point between appearance on the edge of the map and the point at which they lose their "flashing-X" status (usually in the meeting area), immigrants could either be shared out randomly to existing players or given out to watching-and-waiting players who until now have not been able to acquire a "controlling share" of the population.  (There's a potential for the aforementioned leader-player to dish them out, but I think random, or perhaps 'levelling', distribution would work best.)  The death of a player's last (or, indeed, only) dwarf might (by game settings and/or player consent) mean either the acquisition of the next newly available (or donated?) dwarf or Game Over, and leaving the remainder of the interested parties to deal with the future development of the fortress alone.


And, again, this is meant to use the same mechanisms (with the various stated restrictions) as Method 2, which seems to me as largely (although not completely) attainable, given a little effort.

[Ter13]

Starver, I really like the thought! I'll address each of the points in turn.

I like the idea of multi-fort sort of control within the same site. But again, I am not really sure how such a thing would work. Since Dwarf Fortress is barely moddable, a lot of this would be exceptionally difficult. However, given the assumption that we'd be creating a new interface, we could feasibly implement at least some of these features. Designations outside of boroughs, however, would be nearly impossible to manage... Another problem is the stocks. We could feasibly store which items were in which borough upon creation, and manually store fort ownership, but this would be unpredictably difficult, I believe.

I think the idea of certain areas of the map being auto-boroughed is possible, but could potentially create some terrible headaches.

Other than the aforementioned tracking and partitioning of control, there's very little difference between this concept and the original Method 2.  Minimap (or other representative) tracking of each player's views and actions upon the world, basic chat (aside from the obvious idea of scrawling messages in the rock with as yet unfulfilled digging designations, to various ends from shout-outs to out-right insults, I foresee) for task coordination purposes, handling the pausing situation and a whole lot of peeking/poking by the DFHack-inspired game coordination server are the order of the day.

I'd agree with this sentiment, and therefore, would probably write a set of hooks and dot net library loaders to allow developers to modify the existing interface easily. Meaning, no, I would not attempt this as default behavior for the client, but rather attempt to allow other developers to extend the functionality in this way.

There are finer details to be worked out that might be necessary with regard to the potential for griefing players.

I believe a portion of my post stated that griefing players are not a concern. Don't want a griefing player? Don't open your server to the public. If you want to play with someone, you should trust them. This is a private server design, not a public one, and therefore, implementation of true administration beyond passwords to connect is unnecessary.

And the deliberate version of this might be a mini-competition.

I will refer you to what Carnes stated in his post above yours. I don't view multiplayer DF as anything more than a vehicle to social gameplay, and therefore, competitive gameplay is not desirable to me. That being said, I feel this would best be left to the "developer extension" idea above.

You'd be surprised how much of the stocks-control you could potentially attain through the new interface. It wouldn't be terribly difficult, I believe.

[DuckBoy2]

Programmer as well, and I agree with your general rankings in feasibility. 

I think #3 is just a little bit too dwarven for me unfortunately, networking games by sending input and requiring all clients to be able to generate bitwise identical output requires a huge amount of design work from the start.  Matching up the PRNG is one (probably nearly impossible) thing, matching up the PRNGs on multiple platforms using different compilers between different versions, dealing with floating point rounding garbage as the result of compilers changing adds to multiplies and being unable to rewind the world to reorder inputs from multiple players, and thus forcing a lockstep input iteration (with huge lag as it gathers all input for a round), does sound dwarvenly infeasible, and not in the "just needs more magma" kind of way.  Then of course if there are multiple threads in the simulation (even if they don't share the RNG), you can toss any hope of bitwise identical output out the window.  Considering how often one bit is the difference between your legendary hero murdering a dragon and your legendary hero dodging the badger and falling off a cliff, I'm don't think approximation solutions with constant resynchronization is at all feasible.  Put another way, DF is completely non-linear, so basically any approximation is going to fail spectacularly.  You need the bitwise identical for this approach, and I'm gonna go out on a limb here and say it, it can't be done.  PROVE ME WRONG, I DARE YOU.

#2 is quite feasible, and has basically been demonstrated by DFTerm.  Attempting to sync all game data is an impossible waste of time, but sending over screen captures (or the visible 2D world data for a given camera location) is simple.  Further, queuing up input from multiple users, especially when input can only be given while the game is paused, is ridiculously simple as well, save for the one minor nuisance of 2 people giving commands to the same dwarf.  That's just a policy question, and can be resolved by whatever mechanism desired.  Grabbing the 2D world for a given camera location has been done by several of the memory readers, but even failing that, you can have the server move to the player's view, take a snapshot, send it, and move to the next player, so long as we don't really mind our 1FPS, that should be fine, and easy to improve upon.  Sadly, I've never gotten DFHack to work on my Mac, so I've never finished any of my grand plans to implement multiplayer DF.  If you can get DFHack to work on my mac, I'd even contribute a nice 3D rendering of ascii letters for your client UIs. 

#1 is in many ways the most interesting, as #3 is nothing more than attempting to apply first person shooter or RTS (more RTS if you're going lockstep) style networking to dwarf fortress, and #2 is trying to apply a somewhat customized multi person remote desktop app (check if one of these exists, would probably be faster than writing your own), but I think is unfortunately just as impossible as #3, assuming of course you actually want to generate a consistent world.  If thats the goal, you should be able to think of #1 as trying to apply database consistency rules (... ACID I think... atomicity consistency isolation fuuuhhhh.... dwarfiness?) or other multithreading primitives to dwarf fortress's PRNG.  Running an entire fortress to completion is too darn long a transaction, is not atomic with other fortresses (assuming this is actually multiplayer, not a save game repository), should be consistent in and of itself, is -mostly- isolated from other fortresses, assuming your master embark dispenser, and I've completely forgotten what durability is, so lets just say that every fortress is very dwarfy, and thus has a durability of not so much (If my game crashes, you need to stop it from crashing your master history, even if I accidentally turn all my dwarves into elves with 8 arms that breathe firebreathing badgers that can raise the dead). 

You can only have a truly consistent world if you can guarantee all four of the ACID rules, and as you noted, you can't. 
I see no solution to the isolation problem: While the history culling may be able to restore some sense of sanity after the fact, I don't think its very dwarven if the dragon that burns my fort to the ground happened to have died 8 years ago, 5 years ago, and 2 years ago, in various other fortresses, unless of course it was an undead dragon.  While the idea of guaranteeing isolation by forcing usage of different world sites would be perfect when nothing can move between sites, things can move between sites, and even if they couldn't all that would result is numerous disconnected fortresses, each exactly as playable as any save game. 

Since we can't have consistent histories without major rewrites by the history rewriter -- hereby known as The Historian -- I would propose giving up the idea of a master server with a single world altogether.  Hear me out. 

The #1 you are suggesting did not sound like an MMORPG to me, it sounded like a shared save game repository -- There are a lot of fortresses, each created by one or more people over time.  Each fortress can reference all (or at least some) other fortresses, but beyond engravings, cannot really interact with any of the other fortresses without all kinds of paradoxes for The Historian to resolve.  Even engravings would be pretty hilariously paradoxical when you embark with historical figures. 



So I would propose the following:
(--On rereading somewhere on page 2 or 3, I think you said you might be doing this already...--)

Just write The Historian.  Two world saves enter, One world save leaves.  Whether or not they have to be based off the same world to begin with is totally up to you.  The history culler by itself is enough to allow every DF forum-goer to embark in a world with capn ironblood, Cacame, and 100s of mermaid bone artifacts, with none of the ridiculous synchronization issues you would encounter trying to force atomicity and durability on DF. 

I can't speak to feasibility of The Historian, you would have to talk to Toady directly, but in terms of difficulty, it obviously reduces to solving #1, and is therefore more feasible. 

tl;dr

#3 is batshit crazy impossible.  Best of luck to you 
#2 is trivial algorithmically, and has been demonstrated by DFTerm.  It is just coding work, and most of it is work I can't do on my Mac if you intend to pass game data and render it instead of pre rendered snapshots.  However, if you can get DFHack to work on a Mac(There is no /proc, you have to copy 4 bytes of memory at a time, makes it hard to do memory fiddling), I've been dying to write a quick 3D viewer for this game. 
#1 is trying to force DF into giving shared histories in real time, but I don't believe the in real time is necessary.  A shared history generator (known as The Historian) would be a better investment of your time, as it would allow the whole history of the forum to be referenced in every DF game.  That said, its still probably impossible, but not as impossible as #3. 

[Starver]

I like the idea of multi-fort sort of control within the same site.

Not sure you got the sentiment I was trying to convey (in a post that was meant to reply to the original (or at least second) post, even though I'd read everything that came after before I did), as a "seven hermits site" was just a logical extension of the "they don't even have to interact" idea, and "seven hermits at war" just a further extension, but not a default position.

The absolute original basis to the above is that each player would be responsible for a sub-set of the population, a truly "cooperative game".  Rather than a current succession fortress where you get "Oh, I see you haven't done much with the defences, I'll add a trading airlock" or "food stocks were low when I started, so I've produced a whole lot of roasts that should keep us going a few more years", that sort of action would be (could be, should be) undertaken simultaneously across the whole board by the players controlling (ideally) the best mason or food producer, or even (much as in a single-player management of a fort) the player who has a legendary woodcrafter who has more spare time and very little spare wood to whittle away.

DF barely moddable?  Ok, I know you mean "in multiplayer ways", but the original Method 2 called for a coordinating server that collates everyone's moves, and that's the thing that works out who is allowed what action.  (Change your own dwarf's nickname?  No problem.  Not so for that of others, though!)  I've maybe been a bit free-and-easy with the fact that everything is visible to everyone else (in a truly "multiplayer deathmatch" situation, the server could even be set to impose a "fog of war" on each player), but certainly each player has natural control limited to their own agent-characters in the game, and perhaps resources that they have established.  Although, even then, a "permissions interface" in the client and server could over-ride this and leave the core DF program none-the-wiser.  (Indeed, it never need know that there were multiple people even trying to play with it, so the fact that an action by one player had been authorised by another wouldn't come into that part of the equation.)

Another problem is the stocks. We could feasibly store which items were in which borough upon creation, and manually store fort ownership, but this would be unpredictably difficult, I believe.

I skimmed over this, myself.  Either it's a free-for-all (when it comes to snaffling any particular item) or the server imposes some sort of restrictions on what each client can display in the list of thrones they can emplace in the room they are furnishing.

For food, it's probably a free-for-all.  Although maybe with a server option to "lock" the likes of dump or forbid options so that only the client of the player controlling the dwarf that is the producer of that item can normally do so.  Perhaps other clients are given a "request permission?" button/key-press which alerts the producer-client program so that the player gets a yay-or-nay answer (if not setting an auto-permission, or auto-deny, for this sort of interaction with that particular requesting player).  I foresee the default setting to be "require permission, unless rotten".  There are other ways to adversely affect stocks (setting up the food stock-pile entirely the other side of the map, and potentially cause the whole stock to be in motion), but that can be worked upon.  But food is a largely "get it when you need it" commodity, hauling excepted.  Kitchen controls (cookable/brewable settings) might or might not be considered something that a single player (designated from the start, or going by skill-levels) can control.

Furniture is directly selected, and so when attempting to place a chair you just pare-down the selection screen to items for which the player has (natural or granted) permission to use.  Or list them all as normal but with the same "get permission" schema for such sub-items as need it.

There are finer details to be worked out that might be necessary with regard to the potential for griefing players.

I believe a portion of my post stated that griefing players are not a concern.

Indeed.  I was merely suggesting ways in which, firstly, this kind of simultaneously cooperative play might be allowed to selectively restrict certain actions to certain players in accordance with "This is Player X's dwarf" and then secondly, by extension, extend to a feeling of "This is Player X's dwarf's stuff".  Whatever was implemented would be really about focussing each player on playing their own part in the Grand Scheme, with a general trust that the others were doing so, but it's so close to providing a system in which griefing (by anyone but a designated authority, such as the mayor-player or the squad-leader player, within the domain of automatic trust that they necessarily need to be granted) already has checks and balances against it that it's not much more effort to attain.

And the deliberate version of this might be a mini-competition.

I will refer you to what Carnes stated in his post above yours. I don't view multiplayer DF as anything more than a vehicle to social gameplay, and therefore, competitive gameplay is not desirable to me.

It may not be, but whether (say, frexample) Halo/Doom/Duke Nuke'Em 3D/whatever in its multiplayer mode is a deathmatch game which can also be set to be played cooperatively, or a cooperative game in which there is a deathmatch possibility, players will always want to try the other side of the coin.  And (however it is done) the whole range of actions (from locking down 'aggressive actions' between players up to it being the prime intention to actively pursue internecine hostilities) are going to be demanded as options by any player-base.

I'm not sure if I'm even the right kind of person to partake as player in whatever the end result is (far too altruistic for a deathmatch, far too micromanaging to keep up with the "get it done, whatever way" set of players), and this is not a call for what I want, just putting it out there.  Like I said, at least to be disagreed with.