If you TL;DR this, or just read the title, please don't reply.It's rude, and it's always off topic.This is not your usual, "DF MMO" post. There is significant thought behind this one. I'm a programmer, this unique method of handling it is completely possible.All we need is some information about how the game saves data.I was reading a bit about DFTerm in a related post today, and being a programmer myself, I thought I'd toss my respective hat into the arena of discussion of a proper multiplayer implementation for DF.
Method 1: Same world, multiple sites concurrently, one player per site.
The pitch (tl;dr version)This method is pretty much the least feasible method, as it would require working alongside Toady. Essentially, what it would require, is that the world itself is hosted on a machine. The "Server" world never actually runs the world in question. This is essentially a master world. Players will select sites to "check out", and upon checkout, these sites are marked, and disallowed by a third-party program. This third party program will not allow any users to actually use this site for upload via the client control program. As players save (seasonally), a program like DFHack will comb through the data files for that world, purge nonsense history raws, and insert history made by the players during their time online with the client control program. The client control program really just scums the memory and savefiles of the world, and dump them to the server. This however, will create certain inconsistencies within the world, such as megabeast X appearing at two sites semi-simultaneously as the players progress their version of the world. The player will play until the end of his fortress, or until X amount of time has passed (30 days from last dial-home from the client, etc). When this event occurs, if the fortress was abandoned, it will contact the server and update the histories that occurred in that fortress, eventually sending the entire site's region data to the server, and allowing the third-party server program to forcibly merge the data into the legends, and into the map data itself. Any nonsensical histories, such as goblins civilization populations being disproportionate because they happened to be launching themselves at five different fortresses at once, legendary figures being killed by multiple players at the same time, etc, should be culled somehow, or marked as anachronisms... This could be potentially problematic, and more so the more regions have been checked out/the longer players play the fortress.
Requirements
- Need in-depth understanding of saved world data on the hard drive.
- Write a server program that does the following:
- Aggregate in-depth world information from abandoned fortresses
- Keep track of zones that have been checked out by other players.
- Serve copies of the changes to the world that have occurred.
- Create and change properties of the world completely without ever really running the world
- Merge and deconflict anachronisms and errors.
- Write a cohesive and useful world history, and map a useful and cohesive geography.
- Keep track of client online status, and cull clients idle greater than 30 days.
- Write a client program that does the following:
- Disallow players from embarking in locked/checked out zones, or at least refuse to sync with server if one of these zones is being played.
- Keep contact with the server while active and while in contact with a running dwarf fortress application.
- Ensure all Modifications are within compliance of the server's modification list.
- Ensure version is up to date.
- Keep track of legends data while in-game, and keep track of historical figures
- Keep track of created items, exported wealth, etc. etc. as well as DF normally does
- Upload legends data, historical figures, modified world geography, etc. Upon abandoning the fortress.
- Possibly: allow connected players to chat. =D
- Possibly: Update client historical figures manually concurrently with other players on the server.
- Possibly: Upload Legends data each season.
- Possibly: Be resistant to severe DFHacking for malicious destruction of the gameworld...
Programming MethodologyAgain, I'm a programmer, so I'm pretty sure outlining the code for this would be simple, given the very first requirement on the list being fulfilled, access to information from Toady himself.
The server program is the most complex. It essentially will have to take a pre-generated world, and cut it up into manageable sections of data, legends, geography, etc. would all have to be sifted and separated for easy editing and uploading/downloading. It will have to have a socket layer, which is trivial, and a data queue, queueing/managing asynchronous data and sorting it from the context of time in the game world, and not time in real life. It should also be able to backtrack, and undo changes it has previously made as players abandon fortresses that lasted for a long time, for instance, as such, it will never truly be able to merge all of this data with the actual Dwarf Fortress world, but will instead keep a totally separate set of data that isn't part of Dwarf Fortress's game data. It will, in addition, probably have to keep data similarly to how SVN keeps data, making for a very interesting and efficient server.
The client program itself will approach matters a little differently, it will download data from the server upon request, and will then write the sorted and separated legends and figures for the world into the data file. The world will be generated up to the end year of regular world generation that occurred on the server, using the same seed, ensuring that the world itself is exactly the same at the time of the first player starting on the server. Then, it will move on to data downloaded from the server. It will then take on some properties from DFHack, and some properties of a savefile editor, and begin to rewrite the history as time moves forward. The client will then start storing and sending new data periodically to the server, but will not send live versions of the geography of the fortress (the bulk of the data) until the fortress is abandoned completely. Obviously, the client will need to be able to communicate with the server through a socket layer. It will have to be a data editor, and as such, we would need detailed information about world generation/legends information from Toady. After that, it's all about simply overwriting data within the savefiles, and reading data from the savefiles to commit to the server (like an SVN)
Why do this?Because by and large, Adventurer mode is disappointing, but has real potential. No matter how much work Toady puts into the random world generators, it will never truly be entertaining. One man can only spend so much time exploring a world that is randomly generating, before he's seen the extend of the RNG's probabilities for him to explore. After that, it's same-looking mountain, same-looking town, same-looking meaningless dungeon with the occasional, OMG wow.
Where adventurer mode could really shine, though, is in collaborative worlds, where dozens, maybe even hundreds of players have put their time, energy, and focus into carving out fabulous fortresses, creating deadly dungeons, treacherous tombs, and additional alliterations. This kind of a world would really stand out, and shine as a world of rich history, of incredible detail, and fascinating diversity. With a few other modifications to the engine, Toady could actually contend for one of the best single-player RPGs in the world, in a gamemode that honestly is the least-often tried, least-appreciated part of his extensive efforts.[/list]