Print

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

[alexchandel]

Now that Remote Fortress Reader exists, simultaneous multiplayer is finally possible to implement well. Specifically, you could design a client that queries a running fortress via RFR, displays the same menus/information DF displays, & submits changes back to the game with RFR.

The primary questions are how pausing works (Should it pause when either player opens a menu? Should pausing be decoupled from menus in multiplayer?), and, assuming time can pass in simultaneous multiplayer when one player's in a menu, whether the existing menu can code cope with background changes. (Does drafting a dwarf who died in the background merely have no effect? Will he be dynamically removed from the menu as he dies? Will the menu just close? Will the game crash? Will DF eat your laundry?)

A game that runs in the background while you're busy inspecting the status screen could lead to unique/unusual amounts of "fun," so I'm all for it.

Also as a side concern, one might want to pump the gamelog updates over RFR too, so remote clients can use SoundSense.

Edit:

I'm imagining a client-server model, where only one player runs the game logic. The others just connect with "viewers" that merely let them remotely view slices of the game state & manipulate it, as the real DF window does.

[wierd]

Given that dfhack can add/remove designations and flags without pausing (Many scripts use the pointer/cursor to select items in the item vector, but this is just a convenience to avoid having to somehow magically know which "green glass blocks" you are meaning to have used, etc) so theoretically you dont need to pause at all when sending it instructions.

[Grand Sage]

That WOULD change the game quite a bit though...

[alexchandel]

Given that dfhack can add/remove designations and flags without pausing (Many scripts use the pointer/cursor to select items in the item vector, but this is just a convenience to avoid having to somehow magically know which "green glass blocks" you are meaning to have used, etc) so theoretically you dont need to pause at all when sending it instructions.

Sure, I'm not worried about whether dfhack could make changes to a running game (which it possibly does with ease due to DF being single-threaded). I'm wondering how the existing menu code (e.g. a workshop screen, the military screen) will behave if the game isn't paused. For currently, DF is auto-paused whenever you open *any* menu. A simultaneous multiplayer game shouldn't automatically pause every time either player hits q or v: that would be annoying. So what happens—what does the code do—when a dwarf destroys the workshop you're viewing? Does the menu just close? Does the game crash? Do your clothes catch fire?

Effectively, what happens if you use dfhack to hack the game so it doesn't auto-pause whenever you hit q/v/i/k/view any menu/etc?

[alexchandel]

That WOULD change the game quite a bit though...

Definitely adds some new potential dynamics to it. I think it breaks into two changes:

• Adding the ability to prevent Dwarf Fortress from auto-pausing whenever you open a menu, a.k.a. "extra fun mode"
• Creating a remote client that lets someone else view and modify your game while it's running

[Starver]

It's always been the problem that play tends towards being asynchronous with game-time varying wildly from play-time. Not a problem with a solo game (complaints about depressed FPS aside, which I don't consider game-breaking anyway so long as it does still tick, however slowly) but two players meshing together is a practical problem that no mere 'recoding' can handle. It's, as said, a change in game-play, with either micromanagement allowed to throttle the freer player, or 'plot progression' potentially happening full-throttle whilst things (that need to be 'menued' in-depth) continue unhandled.

(The better multiplayer systems suggested, IMO, are parallel forts that are never allowed to get further apart in local time than can be put down to travel time between.separate forts¹ The faster-playing player (or the one on the better FPS machine) might be asked to hold on whilst the other finishes the trader-trading, then instantly receive the wagon (in the state it left the first) the moment as much of the whole entourage has safely left the first site as last minute happenings might allow. In this version, extend that to the process of raiding parties (never so far into the future that a raiding party 'should have already arrived', or an existing one thence can have returned (or not).  But same-site-sharing clearly cuts this allowable bi-directional buffering to zero.)

There are no actual technical issues (that can't already be cobbled together, right this moment, from 3rd-party (DF community) and 3rdier-party (OS-level) add-ons), only logistical alterations necessary to add compromise play-modes that are going to be far from universally agreed-to.



¹ Or current best-travel timings for an Adventurer when one or more player is in that mode of play. Two (or more)  Adventurers at varyinh (including negligible) distances from each other. Or from the simu-playing Fortress Mode players, if that inherently differently tick-passing play method is allowed to co-exist.

[stingpie]

The way I would interpret this working, is the two players agree to an fps range, and if one of the computers exits that range, the other will dedicate some resources. It would certainly take a very fast connection, but that's the only way I feel a processing power difference could be solved. they would have to control different fortresses with some sort of fps magic to slow down ticks on one computer, if the other one was paused. If all else fails, there would be a counter for the ticks in a (virtual) day, and force one of the players to wait that long, at the end of a day.

[Starver]

FPS-drift is one thing ('cloud-Forting' could be a thing, assign elements like pathing, liquid flows, temperature calculations -
 even the worldgen work might be packetised!  - across multiple machines, simple 3d arrays get sent betwixt partner nodes and the complex bits happen upon a single assigned machine before passing the results onwards... perhaps blockchain it and double-up on the work for added verification fun!) but FPS isn't an issue if (say) I'm painting new stockpiles and spending half an hour adjusting which seeds go where, what quality and material of floodgates are accepted in various places, rearranging the Depot-proximate stockpiles to accept the latest batch of more premium goods we just had an agreement to supply, and then additionally reassigning the next accommodation layer from my prior Marker Only planning to Standard (with a variety of carefully-tuned priorities to speed up whole-room commissioning) for exactly the number of immigrants that I've just seen arrive.

While I'm doing that, zero ticks are passing (cannot, or at least should not, pass), and my fellow player(s) may take over part of the task (say the mining redesignation, which could perhaps be usefully done in parallel, so long as we can agree that they can do it without messing it up what they wanted my expertise to be responsible for) or they may instead be themselves more interested in wanting to keeping an eye on a Moody dorf's fetch'n'carry (a very important job, but reliant upon time passing and pausing/querying in a completely different manner) and yet stymied by what I'm doing.

Forcing me to relinquish the pause after a certain passage of realtime is an answer, but stops me doing what I want to do as badly as the above situation of forcing others to hang on (or worse, because it leaves stuff not done in the traditional time of "instantly", and thus everything is in a mismsnaged mess while I wait for my next opportunity).


And it definitely becomes a different game, even though it might have superficial similarities.

[wierd]

The concept I had in mind was more Client-Server relationship.

The DF process is too timing critical to be distributed (sanely). Instead, it runs on big iron. Since DF already uses abstracted graphics, this is not a problem-- DF in curses mode is already daemon-friendly, aside from being single user.

Instead, the DF process is run by a multi-user daemon, which has local process access (EG, it can hook the DF process and memory, and poke around in it like dfhack does), and provides the 'server' portion of the combo. Multiple users can log into this daemon, it collects data from the active DF instance, (and keeps the game UNPAUSED, or at least, has options to allow unpausing from any user) then delivers data on demand to/from any connected clients for their local viewport.

The game changer is the client.  The client is "dumb", it has no idea about the internals of the DF process. It does not need to. It reimplements a gui, has code to fetch data, and has a presentation layer. That's about it.  A user using the client can have the data presented in any number of local tilesets, (due to the already abstracted graphics system used by DF, a highly compressed text data stream can then be rendered using graphical tiles, 3d primitives, whatever.)  and can interact with the running fortress in near realtime (latency and flutter being issues, but no worse than most MMOs already have)  All the client does is present a slice of the DF world to the player (which it requests from the server), provide local surrogates for the menu system (which wont pause the world!!), and communicate with the server daemon to make the user's desired changes get implemented on the server-hosted fortress.

The big issue is going to be resource allocation (No, I mean inside a fortress-- remember the infamous beekeeper bug? That was a resource allocation issue) eg, What happens when player A allocates 200 green glass blocks, while player B allocates another 200 green glass blocks, (since there is no pausing!), but there are only 300 green glass blocks free--   The game already has a bit of code to handle "Lost building material" (EG, you create a job designation that tasks an item, then you immediately atom-smash the item that is tasked. Urist still wanders up to the last known site of the item, then you get a "Urist cancels X, Job item lost or destroyed" message, and the task is canceled.) but i dont know how robust it is.  Thankfully, the game already has some local compartmentalization that we can utilize--- BURROWS.  This way the green glass blocks in Player A's burrow is already semi-discrete from the green glass blocks in player B's burrow, and the server can report this number reliably to a connected client, and that client can have a reasonable assumption that it can make a designation operation with those resources without having the other player cabbage them out from under them. (It would also make inter-burrow minecart systems more useful, as inter--player cooperation to make resources available to other players through dump zones inside burrows would be a new and useful dynamic built on top of existing systems.)

Yes, fortress mode with simultaneous players would be a different experience.  Last I checked, that was kinda the whole point.

[Bumber]

The big issue is going to be resource allocation (No, I mean inside a fortress-- remember the infamous beekeeper bug? That was a resource allocation issue) eg, What happens when player A allocates 200 green glass blocks, while player B allocates another 200 green glass blocks, (since there is no pausing!), but there are only 300 green glass blocks free--

In this instance, the server should report a failure to whichever client had their request processed second. The custom GUI could accommodate this on the client end. The server needs to check the availability of green blocks before processing a client's request/transaction. Burrows work for separately run forts, but cooperation on a single fort is also another way to play.

I think the main issue is a lack of developers with the required skill and time. Warmist has done great work on his multiplayer arena, but even he has other projects, like the rendermax plugin.

[alexchandel]

…
(The better multiplayer systems suggested, IMO, are parallel forts that are never allowed to get further apart in local time than can be put down to travel time between.separate forts¹ The faster-playing player (or the one on the better FPS machine) might be asked to hold on whilst the other finishes the trader-trading, then instantly receive the wagon (in the state it left the first) the moment as much of the whole entourage has safely left the first site as last minute happenings might allow. In this version, extend that to the process of raiding parties (never so far into the future that a raiding party 'should have already arrived', or an existing one thence can have returned (or not).  But same-site-sharing clearly cuts this allowable bi-directional buffering to zero.)

There are no actual technical issues (that can't already be cobbled together, right this moment, from 3rd-party (DF community) and 3rdier-party (OS-level) add-ons), only logistical alterations necessary to add compromise play-modes that are going to be far from universally agreed-to.



¹ Or current Most Unexceptional-travel timings for an Adventurer when one or more player is in that mode of play. Two (or more)  Adventurers at varyinh (including negligible) distances from each other. Or from the simu-playing Fortress Mode players, if that inherently differently tick-passing play method is allowed to co-exist.

An orthogonal type of simultaneous multiplayer, where multiple forts on the same map evolve? If fortress-evolution calculations are sufficiently isolated from background-world-evolution (specifically, if they're not interleaved), it might even be possible to run each fort on a separate thread, assuming you stick to a client-server model (which seems far, far easier than coordinating servers' world synchronization).

You could even have same-fortress multiplayer and cross-fortress multiplayer in the same game (e.g. 2 players on one fort, one player on another, exchanging raiding parties).

It's always been the problem that play tends towards being asynchronous with game-time varying wildly from play-time. Not a problem with a solo game (complaints about depressed FPS aside, which I don't consider game-breaking anyway so long as it does still tick, however slowly) but two players meshing together is a practical problem that no mere 'recoding' can handle. It's, as said, a change in game-play, with either micromanagement allowed to throttle the freer player, or 'plot progression' potentially happening full-throttle whilst things (that need to be 'menued' in-depth) continue unhandled.
…

See I'm thinking 'plot progression' could happen full-throttle, unless explicitly paused by either player (e.g. bind pause to the backtick/"`" key on every screen). One could still attempt to 'menu' things as deeply as possible real-time, explicitly pausing when it wasn't possible.

It's worth hacking this feature into the current (single player) game, to see how it plays. From a technical point, the only potentially problematic question is "what does the current menu code do when a menu should've changed?" As long as the answer isn't any variation of "the game crashes" or "the game gets corrupted," it's fine.

[alexchandel]

Edit: typo, accidentally quoted instead of modified (ლ‸－)(－‸ლ)

[alexchandel]

The way I would interpret this working, is the two players agree to an fps range, and if one of the computers exits that range, the other will dedicate some resources. It would certainly take a very fast connection, but that's the only way I feel a processing power difference could be solved. they would have to control different fortresses with some sort of fps magic to slow down ticks on one computer, if the other one was paused. If all else fails, there would be a counter for the ticks in a (virtual) day, and force one of the players to wait that long, at the end of a day.

I'm imagining more of a client-server model, where only one process runs the fortress-evolution & world-evolution. Other players have a thin client that connects to the main DF process/computer (over a network, via the DFHack plugin RemoteFortressReader), shows a screen of tiles, & sends modification requests back to the main DF process whenever the other player does something (e.g. designates an area, renames a burrow, adds a task).

Pausing would have to be coordinated, as I mentioned here:

…

It's always been the problem that play tends towards being asynchronous with game-time varying wildly from play-time. Not a problem with a solo game (complaints about depressed FPS aside, which I don't consider game-breaking anyway so long as it does still tick, however slowly) but two players meshing together is a practical problem that no mere 'recoding' can handle. It's, as said, a change in game-play, with either micromanagement allowed to throttle the freer player, or 'plot progression' potentially happening full-throttle whilst things (that need to be 'menued' in-depth) continue unhandled.
…

See I'm thinking 'plot progression' could happen full-throttle, unless explicitly paused by either player (e.g. bind pause to the backtick/"`" key on every screen). One could still attempt to 'menu' things as deeply as possible real-time, explicitly pausing when it wasn't possible.

It's worth hacking this feature into the current (single player) game, to see how it plays. From a technical point, the only potentially problematic question is "what does the current menu code do when a menu should've changed?" As long as the answer isn't any variation of "the game crashes" or "the game gets corrupted," it's fine.

But since there's only 1 fortress (and thus no additional game computations happening), this type of simultaneous multiplayer wouldn't even hit FPS that much.

[Urlance Woolsbane]

The primary questions are how pausing works (Should it pause when either player opens a menu? Should pausing be decoupled from menus in multiplayer?)

Almost certainly the latter, unless you're going for a turn-based system.

assuming time can pass in simultaneous multiplayer when one player's in a menu, whether the existing menu can code cope with background changes. (Does drafting a dwarf who died in the background merely have no effect? Will he be dynamically removed from the menu as he dies? Will the menu just close? Will the game crash? Will DF eat your laundry?)

Presumably the server code would check whether a given dwarf was a valid recruit, and respond with an error message if necessary. Of course, I see no reason why the client couldn't update the list of eligible dwarves on the fly, but there will always be exceptions.


A lot of the logistics hinge on the exact implementation, natch. There are several plausible models for multiplayer:

1) Turn-based multiplayer, in which a different player takes control at a given interval. This would be the easiest form to implement, being essentially a staggered form of single-player.

2) Space-based multiplayer, in which every player controls a different segment of the map. This would be a somewhat clumsy system, but would, like #1, avoid such pitfalls as conflicting orders. Much of the burrow-functionality could be appropriated for this.

The biggest is question is thus: How far to compartmentalize the fortress? The militia could easily be split into various squads, but what of the nobility? I assume that elections, for instance, would remain fortress-wide.

3) Responsibility-based multiplayer, in which each player controls a different function, possibly through a corresponding noble. One would manage the militia, the other labor, another trade, and so on and so forth. Again, there is the issue of compartmentalization.

4) Guild-based multiplayer, in which each player controls a different industry.

5) Citizen-based multiplayer, in which player #X has control over every Xth dwarf. This would also run up against the issue of nobility. Perhaps it would be best for the first player to be designated as the prime overseer, with control over ever matter that cannot be particularized (e.g. diplomacy.)

6) Free-for-all multiplayer, which entails a good deal of chaos. Mind you, that sort of !!FUN!! is part and parcel with Dwarf Fortress, but it could try the patience of some.

[wierd]

The way I envisioned it, it would be a combination of free for all, and space based administration. (nobles are just eye-candy in my opinion. Aside from the book keeper, they dont really have an administrational role aside from figurative ones.)

The idea being that the game defaults into free for all mode, but the players can designate burrows using "magic" names (eg, the client responds to keywords in the burrow name field), which the clients pick up, and then process. Any player can add, modify, or delete a burrow, so there is still room for player-player conflict on who owns what section of the fortress... but adversity is the spice of life.

This would allow the "space" portion to be any arbitrary size/shape, and fully dynamic. It would also make it fully optional.  Other modes of play could still be implemented, since fortress layouts are almost always done by industry or resource type anyway.  (EG, player 4 gets the caverns, and deals with collecting ore-- Player 3 deals with ore processing and armoring, player 2 deals with food and clothing, while player 1 deals with surface attacks, diplomacy, trade, and woodcutting--- etc...) the same mechanics (user definable/editable burrows defining player control area exclusivity) would allow "multifort in fortress mode" as well, with wholly isolated populations under different player's control. 

etc.