Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2 3

Author Topic: Outline for a true multiplayer control scheme for DF  (Read 7301 times)

Ter13

  • Bay Watcher
  • Oh wait... Dwarves like food, don't they?
    • View Profile
Outline for a true multiplayer control scheme for DF
« on: July 28, 2011, 11:44:01 pm »

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 Methodology

Again, 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]
« Last Edit: July 29, 2011, 01:56:17 am by Ter13 »
Logged
Murderhold - A story about a fortress closed off from the world, attempting to survive a zombie-infested wilderness.
Murderhold Discussion thread

Ter13

  • Bay Watcher
  • Oh wait... Dwarves like food, don't they?
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #1 on: July 28, 2011, 11:44:39 pm »

Method 2: Shared site only.

The pitch

This method is the most feasible method, as it would require no direct work with Toady to make it work. This method differs from the first in the way that it handles the multiplayer functionality. This world is not shared directly, but control of the site is shared amongst multiple players. If we wanted hotseat control, DFTerm would work just fine, but we want players to be creating designations, issuing military orders, and interacting with the fortress in near real time with each other. The regular client would be used to run Dwarf Fortress, but it would be played via a custom client for all players, even the host.

Players would connect to the server, this would NOT be an MMO at all, but a 2+ player collaborative effort. The custom client should essentially work alongside DFHack much like stonesense does. It would read the world data, and render it exactly like the regular client. This client would communicate with the hosting client (server), which would collect input/output from the players. Designations, construction orders, menus, etc. would all be accessible to all players, and the players all share one time stream, meaning if the lead of the server unpauses the game, all players' games are unpaused. If one of the players pauses the game, all players' games are paused. All players will be treated like trusted friends, and as such, griefing/trolling will not be considered in this plan.

The modified client will process commands and designations by taking control of the window handle of the original DF window, and actually place them on the map exactly as the players did.

Therefore, the modified client will have to keep track of what designations have been lain in it, and when the player pushes ctrl+space or something like that, it will push the designations/construction orders to the server, allowing the server to queue up the designation/construction order, and place it in the map for proper processing for the actual DF window.

Players will be able to move their views around independently of each other, and see where each of them is looking (using the minimap). This project will differentiate itself from DFTerm by not sending the actual screen data, but the world data when the players connect to the server, and will update the clients by sending them regular update on what has been done, and what has moved since the last update. Since we are only updating what has changed, and what has moved, the updates will be intense, but not unmanageably so. Regular pings over the internet are 60-250ms, meaning at 100 FPS, updates will be delivered to the clients at approximately the rate of 16FPS to 4FPS. At 1000ms ping, updates will literally be 1FPS per 100. Regular pings over the local network, however, range from 0 to 10ms, making 100FPS on a LAN possible.

Requirements

  • Need a decent understanding of Memory locations and values.
  • Write a client/server hybrid that does the following:
    • Collect world information from the server on client startup.
    • Store mob movements/actions in memory for sending to clients.
    • Negotiate network protocol with clients, and deallocate data when it has been received.
    • Recognize and handle desynchronized clients.
    • Adapt and modify packet protocol based on ping to clients.
    • Provide an exact duplicate of the Dwarf Fortress interface and graphical front-end.
    • Accept and process multi-player designations and orders.
    • Seize control of keyboard input for master DF program.

Programming Methodology

I believe the graphical code for DF is basically available to the public. It should be trivial to convert this to .Net compatible language, and hook it into a DFHack memory aggregator. The big kick for this program is network negotiation. The clients need to be synced very well in order for it to be playable for more than one person, and the client should essentially force-feed keyboard events to dwarf fortress in windowed mode so that the fortress still carries on life while out of focus. This is fairly trivial again. A simple sockets library with an internal dictionary of sent packets and updates should be able to keep the worlds synchronized, while a refresh command can force a background update from the server in case things do indeed get out of sync. Since commands are going to be added in near real time on multiple machines, the package needs to have a thread-safe method of applying these updates to the actual game, and as such, should queue these results, and apply them one after another, one at a time, so that the game itself does not become confused, and mess up the commands being filtered as though only one player were playing the game.

Why do this?

Because single player is fun. But the more the merrier. Since Toady would need not become involved in this project at all, there is no reason that his concerns about multiplayer should even be given a passing thought. Let's face it, Dwarf Fortress as a varied community, and we obviously like playing together, given the fact that dfterm and succession games even exist. Plus, the entertainment need not come solely from reading combat logs themselves, but rather, from the disasters fun of more than one player attempting to get a settlement off the ground, and the poor planning collaboration that is inevitable from multiple cooks stirring the pot.
« Last Edit: July 29, 2011, 01:20:21 am by Ter13 »
Logged
Murderhold - A story about a fortress closed off from the world, attempting to survive a zombie-infested wilderness.
Murderhold Discussion thread

Ter13

  • Bay Watcher
  • Oh wait... Dwarves like food, don't they?
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #2 on: July 28, 2011, 11:45:24 pm »

Lastly, I bring you to the final proposal of this short series of treatise on Multiplayer in Dwarf Fortress, and the possibilities for community realization of this goal. The most complicated and unbelievably difficult of them all. One that is currently not possible without toady changing a single aspect of the RNG. Hard-coded seeds. Delay-synchronized gameplay.

The Dwarvenly Insane Delay-synchronized Gameplay Method.

The pitch

This method would require Toady to at the very least set an option in the PRNG to make it so that fortresses do not change their pseudo-random seed on world load, making every random roll of the dice predictable and reproducible if made in the same order. So long as player input is made at the exact same time, the worlds will remain synchronized. For this to work, the server and client will have to be almost exactly the same as in method #2. Except, instead of relying on networked data to render the game data, they will rely on a local DFHack memory reader/editor to exact their changes. All inputs that are made must be negotiated with the server, then negotiated with each client, then agreed upon. Then, they must each schedule a time in the future (ahead of the latency buffer) to process these actions. Each of the worlds also must be capped at exactly the same frame-rate, and any time the clients desynchronize, even in the slightest bit due to CPU stalling, etc. Each client must be slowed down to the slowest machine accordingly. All input will be queued similarly with method #2, but the synchronization will ensure that everything will happen at the exact same millisecond on each client. The command queue needs to be very lag-conscious.

Requirements

  • Get Toady to set stable/predictable PRNGs for worlds.
  • Need a decent understanding of Memory locations and values.
  • Write a client/server hybrid that does the following:
    • Synchronize all player-driven events and commands to the millisecond.
    • Negotiate, and renegotiate desynchronizations in frame-progression.
    • Recognize and handle desynchronized clients.
    • Adapt and modify packet protocol based on ping to clients.
    • Provide an exact duplicate of the Dwarf Fortress interface and graphical front-end.
    • Accept and process multi-player designations and orders.
    • Seize control of the keyboard input for local DF program.

Programming Methodology

This program would be tricky at best. It may well not be entirely possible given certain irregularities about network negotiation, but in theory, it should be entirely possible, though exceptionally difficult. Again, though, everything but synchronization and network negotiation is absolutely identical to the second method I mentioned above. The other major difference, is what kind of data is going to be sent back and forth across the network. There will be no memory dumps at the beginning to a game session, and instead, the memory will be read entirely from the local instance of DF.

Why do this?

This is probably the hardest way to achieve the goal of a multiplayer DF, but there is a reason for this approach. One, massive bandwidth savings over method #1/2. Two, massive framerate improvements over method #2. There are some downsides, though, individual modification of the world using tools like DFHack or other external tools will permanently break synchronization completely.
« Last Edit: July 29, 2011, 01:55:43 am by Ter13 »
Logged
Murderhold - A story about a fortress closed off from the world, attempting to survive a zombie-infested wilderness.
Murderhold Discussion thread

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #3 on: July 29, 2011, 12:11:11 am »

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.


Method #2 is incoming. Reserved post below.

Method #3 is incoming, Reserved post below.


This is possible, though time-consuming, right now, to have such collaborative worlds. Just pass around a world until it feels worth exploring.

Sounds like an interesting succession game, really. Each player gets a WHOLE FORT before passing it on. No traps allowed, military only :P

Anyway, after reading, it sounds interesting. I like this topic already, as it's actually well-thought out. Also, sorry if you get a "NEW REPLIES PLEASE LOOK BEFORE POSTING" screen :P

Lectorog

  • Bay Watcher
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #4 on: July 29, 2011, 12:31:02 am »

Read through the first one; understood most of what you were proposing (though I'm no programmer). I really like the idea you're putting out. A world full of player-created fortresses. Definitely a lot more interesting for adventuring. However, this would take a lot of work. More problematically, a lot of work outside of what Toady's going for. This would require direct collaboration with him (or, knowing his policies, all work being from him), and he doesn't want to make an MMO of any type any time in the forseeable future, so I'm afraid that idea's not feasible, as you said yourself. It does offer up a potential type of succession fortress (succession world), but likely can't go much further. The work required is simply not worth the gain.

Looking forward to your next two. They should be interesting, based off what I've seen so far. Good ideas! :)

*EDIT* I like the other two. Great ideas, as expected. The second might actually be able to work, in the near future. That would be a definite improvement over DFTerm, which is a relatively simple program, especially when put in perspective with something like this. This could be an actual DF multiplayer game. I'm looking forward to seeing where this goes.

As for the third... I have some doubts. That sounds insanely (or inanely) difficult. If it could actually work, that would be great. I'm not expecting it to happen.

Overall, great ideas! This has definitely contributed to the community as a whole, even if it doesn't work. I'm assuming you're arranging to or already speaking with Toady about this. While it wouldn't be much work on his part, he still has stuff he needs to do; multiplayer has alway been low on his list of priorites. Various policies and all that could also be obstacles. All the same, I hope at least one of these (probably and preferably the second) is created sometime soon. Until then, it's DFTerm for your multiplayer purposes! (Which doesn't do a bad job considering DF is a single player game throughout.)

Thanks!
« Last Edit: July 29, 2011, 02:32:02 am by Lectorog »
Logged

dragonshardz

  • Bay Watcher
  • [ETHIC:PONY:ACCEPTABLE]
    • View Profile
    • Steam Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #5 on: July 29, 2011, 12:40:02 am »

Read the first, looking forward to the second and third. Sounds like an interesting idea, even if Toady totally shoots it down.

Ter13

  • Bay Watcher
  • Oh wait... Dwarves like food, don't they?
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #6 on: July 29, 2011, 01:57:58 am »

Second and third methods are up. Note that all suggestions that I have given would require very very little actual work from Toady, in one method, he would only have to provide us with information. In another, he'd only have to provide us with a single modification of the PRNG initialization code.
Logged
Murderhold - A story about a fortress closed off from the world, attempting to survive a zombie-infested wilderness.
Murderhold Discussion thread

Pan

  • Bay Watcher
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #7 on: July 29, 2011, 02:44:29 am »

No time to read atm, but it seems you really have put a significant amount of thought and effort in the post. Maybe suggesting this to Toady or something?
Logged

Lectorog

  • Bay Watcher
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #8 on: July 29, 2011, 03:10:22 am »

No time to read atm, but it seems you really have put a significant amount of thought and effort in the post. Maybe suggesting this to Toady or something?
If you TL;DR this, or just read the title, please don't reply.
The answer should be pretty obvious, anyway.

By the way, to avoid any confusion, I edited my first post to include your second and third.
Logged

Ter13

  • Bay Watcher
  • Oh wait... Dwarves like food, don't they?
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #9 on: July 29, 2011, 05:03:05 am »

Read through the first one; understood most of what you were proposing (though I'm no programmer). I really like the idea you're putting out. A world full of player-created fortresses. Definitely a lot more interesting for adventuring. However, this would take a lot of work. More problematically, a lot of work outside of what Toady's going for. This would require direct collaboration with him (or, knowing his policies, all work being from him), and he doesn't want to make an MMO of any type any time in the forseeable future, so I'm afraid that idea's not feasible, as you said yourself. It does offer up a potential type of succession fortress (succession world), but likely can't go much further. The work required is simply not worth the gain.

In the end, I think #1 is the most likely candidate. I'm willing to do a lot of the work myself, if I can deconstruct how legends and world data works. I've got a fair bit of the data figured out, and I think I can insert abandoned sites into the world manually. I've got to see if it will work. I'm pretty good at reverse engineering and deobfuscation, one thing I did a long time ago, was decompile Minecraft and deobfuscate it back before modding was even considered possible.

Reverse engineering a data structure should be trivial, but time consuming. The problem is, every time Toady updates, it's going to take time and effort to reverse engineer it again.

I like the other two. Great ideas, as expected. The second might actually be able to work, in the near future. That would be a definite improvement over DFTerm, which is a relatively simple program, especially when put in perspective with something like this. This could be an actual DF multiplayer game. I'm looking forward to seeing where this goes.

Thanks. I just hope someone more dedicated than myself reads this thread and decides to do something about it.

As for the third... I have some doubts. That sounds insanely (or inanely) difficult. If it could actually work, that would be great. I'm not expecting it to happen.

AFAIK, fully synchronized PRNGs have never been done. This could potentially be either a world first, were it to be done, or it could simply be impossible on conventional computing hardware, and I could be an idiot for even considering it. Looking around the web, I see a lot of other people talking about it, and I personally came up with the idea about seven years ago. I just didn't think it was possible, because of the awful internet connections in America. Over a LAN, this would be easily doable.

I'm assuming you're arranging to or already speaking with Toady about this. While it wouldn't be much work on his part, he still has stuff he needs to do; multiplayer has alway been low on his list of priorites. Various policies and all that could also be obstacles. All the same, I hope at least one of these (probably and preferably the second) is created sometime soon.

Maybe once I get a proper proposal together. Until then, I want to see what the community thinks, and we seem to have a lot of know-it-all programmers around here, so I figure letting the gods piss on my ideas for a while can only help, right? Thanks for actually reading through it all. I know the wordwall is an obstacle for most. I agree with you that option #2 is probably the most feasible, as all the tools are already in place. My main concern, though, is the sheer bandwidth and ping restrictions. Plus, I like the idea of concurrent fortresses so much more than the idea of five guys making magma-spewing dongs in the same fortress.

Thanks!
Logged
Murderhold - A story about a fortress closed off from the world, attempting to survive a zombie-infested wilderness.
Murderhold Discussion thread

Vattic

  • Bay Watcher
  • bibo ergo sum
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #10 on: July 29, 2011, 05:56:39 am »

Out of the three I can see myself using the second one if it were ever made. The only problem I can see with the other two that you haven't mentioned is what might happen when we can send armies out and similar.
Logged
6 out of 7 dwarves aren't Happy.
How To Generate Small Islands

burned

  • Bay Watcher
    • View Profile
    • burnedFX
Re: Outline for a true multiplayer control scheme for DF
« Reply #11 on: July 29, 2011, 06:36:49 am »

I don't post that often on these forums.
I didn't even sign up for the forums until a year after discovering the game.
I do, however, play dwarf fortress a lot and have followed Toady's dev log, read all his interviews, listened to all the podcasts, from his interview at RPPR to the current Dwarf Talk and I am always checking his profile to click on "Show posts".

There is a point to mentioning all of this.
It's not to declare that I am dwarf fortress' biggest fanboi, but I will admit to feeling extremely defensive when you start talking about reverse engineering his game.

Granted, not only having read your posts here, but looking over your post history, I wouldn't jump to the conclusion that you are coming from a bad place to purposely harm Toady or his work and that you too, just love dwarf fortress.

Your post begins with an all red caps message of how one shouldn't TL;DR your post.
I feel I have given your words time to digest in my system and I would like to offer my thoughts.

Your red text also includes, "All we need is some information about how the game saves data" and you later bring up reverse engineering the game. Based on those two things alone, you're headed down the wrong direction with this thread's ideas and possibly with Toady, although I am just representing myself here. However, the only time I recall him being extremely upset and angry in the four years I have been "following him" was when some individual did just that, try and reverse engineer his code.

If you gave the same courtesy, that you are requesting, to Toady and took the time to look over his interviews, from dwarf talk to other podcasts, to his reddit responses (which I saw recently from a link in the current thread Viewing Source Code), to even the latest NY Times article, you'll see that he will not sacrifice his livelihood by giving out save data structure or the things you seem to need in order to realize any of these ideas.

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, but I haven't listened to that one since 2009.

Even without that impression, the first question on the reddit interview states his views on sharing any more than he has and the time travel comment, believe it or not, would actually be more likely to happen first than method 1 or 3. I know he has talked about time travel somewhere else, I just can't recall where, but it was definitely more extensive than the quick remark he makes on the reddit interview.

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.

Again, I am not saying this from a programming perspective, but just as another player of dwarf fortress, who is always impressed with the legendary artifact that Toady has created.

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 and not TL;DR Toady's thoughts before you post.

I can guarantee that you have the answers without having to present Toady with anything.



On a lighter note and a bit off topic, I enjoyed your Murderhold story.
Logged
DFMA Profile | burnedfx Graphic Set

The process of delving into the black abyss is to me the keenest form of fascination. - H. P. Lovecraft
The Delvers
. . .the middle ground between light and shadow . . . - Rod Serling
The Delvers' Podcast

Zeranamu

  • Bay Watcher
  • I am Z
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #12 on: July 29, 2011, 06:52:07 am »

You bring up an interesting point, and I do agree to a certain extent. This is probably also why the DFTerm/PuTTy MP setup is the only one going on at this time - reverse engineering any part of the game that isn't supposed to be is wrong, and we shouldn't even consider that a viable option. That being said, I do like all three ideas, and if it were possible to get Toady involved, then it wouldn't even be a problem - but I believe if that were going to happen, it would be far, far, far down the road.
Logged

Excedion

  • Bay Watcher
    • View Profile
Re: Outline for a true multiplayer control scheme for DF
« Reply #13 on: July 29, 2011, 07:49:26 am »

Out of the three I can't really see the first one working too well. There's a lot of things that can and will go wrong there. The second one though is one i'd definitely use though, I've been looking forward to something like this for a while as I'm reluctant to play succession forts and DFterm.

Anyway it's great to see so much thought being put into these suggestions instead of the usual "this is what i want" and never lists how they suppose it could be accomplished.
Logged
If adamantine is perfectly rigid, as shown by having 0 strain at fracture in the raw files, then the speed of sound in the metal approaches the speed of light. Adamantine musical instruments would produce ultrasonic vibrations, and cut off the fingers of the musician.

Sphalerite

  • Bay Watcher
    • View Profile
    • Drew's Robots and stuff
Re: Outline for a true multiplayer control scheme for DF
« Reply #14 on: July 29, 2011, 08:38:48 am »

The first one is an idea that I've considered and that I would like to see implemented someday.  I can't see it being done without a very good understanding of the structure of the DF save game files.  I've taken some look at decoding the save files, but haven't made much headway into the actual site structure.  I expect that you'd need detailed information from Toady into the save game structure to make this work, and I don't expect that to happen.
Logged
Any intelligent fool can make things bigger and more complex... It takes a touch of genius --- and a lot of courage to move in the opposite direction.
Pages: [1] 2 3