Print

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

[TheBiggerFish]

Multiplayer and DF just really, really don't mesh.

[NW_Kohaku]

I didn't have much time to explain exactly my ideas as I was on my phone when I wrote that (still am), however the idea of Fortress Mode and Multi-player are completely incompatible.

The amount of work required to force fortress mode (especially multi player, multi level, multi size, multi complexity forts) would be completely irrational (more like complicated beyond).

My ideas were more based towards Adventure mode, which actually wouldn't be that difficult
(reference my version of Multi-player Bogue)

With the advanced complexity of Dwarf Fortress, the corrections that were made with Bogue would be much less in an edited server of DF.

I'm thinking of something along the lines of the server software that was written for Terraria.
Console based C# (with embedded Ruby for server stability)

Don't have time to debate all the ideas in this thread right now.
I might be able to later.

The problem is that Terraria has only one time scale, and is always real-time.  (Same with Minecraft.)

When the game relies upon actions that drastically alter the flow of time, such as fast-travel, you slam head-first into a wall of discordant time-scales. If you try to get rid of fast-travel, then keep in mind, sleep is a necessary feature, which relies upon that speed-up.

Dwarf Fortress is also not an MMO where everything is meant to largely remain static without the player around.  The world is designed to interact with the player, and if every player isn't logged in, what, do they just stand still and starve to death?

Seriously speaking, the closest to multiplayer DF could get was either console sharing of a single fort (where you literally just steal the keyboard from someone else), or asynchronous fortress-building, and even that concept is slipping further and further away with more interactive worlds.

[Adam Mantine]

Fortress mode multiplayer might be doable if it was highly asymmetric, perhaps even to the point of everyone but one player being a passive observer who can only look at the main screen while the other player plays.

edit:
Now that I think of it, a lot of controls that are hardcoded to autopause do not inherently require the game to be paused (afaik. Some might technically but if they do it's a quirk of the existing code). if stockpiles and zones and look and query room and items in buildings and designations could be redone to have the option to be set out with the game unpaused then one player could be given the option to access these without stopping the game. The pause function however would be at the exclusive control of whichever player's computer was acting as the server.

[Starver]

We're definitely going into MUD territory (if not MMO), the way some of this is being suggested.  Something could be jury-rigged with LPMud interacting with discrete and synchronised emulators/interovators of 'active' regions (with one or more players wandering round) and at least one taking care of background events.

It would have to have carefully throttled 'ticks' and perhaps a compromise between current keypress navigation and the command-line capabilities of the MUD system (players familiar with the SP adventure mode game could alias an appropriate 'string' to "pick up stone; throw stone north", I suppose, not much different from Macros).

But I still see the cognitive disparity between the "thinking time is a free move" of the current Adventurer and the constant paying of attention necessary in any "DFMud" implementation. It's a different game, even if it obeys the same "physics" as DF's emulated environment.

And non-trivial to develop. Unless we have any aspiring Pinkfishes out there...

[Adam Mantine]

I think it would work better without the synchronized emulators. It would need to be one player's computer acting as a server, hosting the game, and the other player(s) computer(s) acting as auxiliary input and output but with no pause option, pausing being the exclusive purview of the host/server.


Under no circumstances should it be peer to peer or use an external 3rd party server. That's just askong for problems

[Starver]

I think it would work better without the synchronized emulators.

I was actually referring to somehow having disparate active areas loaded when low-level/high-dependency diffs and deltas needed to be done, and (probably) a single load of the whole-world LOD for "meanwhile, beyond sight, the rest of the world has major events happening to it" sort of stuff.

It wasn't intended to be a distributed effort*, nor a 3rd-party server**, just a 'logical organisation' of what is effectively several single-player emulators (although with the potential for 2+ player-characters peeking and poking the data within the same (or neighbouring) world-tiles.   Parallel/pseudo-parallel emulations on one machine or farmed out intelligently*** to connected pocessors with some MIPS to spare, both scenarios need to consider how to deal with incursions from neighbouring tiles (loaded and specific or unloaded with less-specific worldly movements of armed forces and migrating populations) and yet stay managable individually as well.


Although it's already becoming a different game, even if the visual flavour and basic mechanics are forced into the same outwardly-similar groove.


* - Although it could be, perhaps with players sharing loaded 'tiles' sharing the effort by splitting their region (perhaps by some k-d method) according to the proficiency of each player's machine, and soak up the need to ensure interactions/sightlines across the split-subborder(s) are communicated in order to achieve simutaneity.

** - Again, it could be, but the primary player could take on (at least) the necessary coordination duties, and be the Server to everyone else's Clients, to whatever degree therer is (or is not) 'farming out' of effort.

*** - Imagine the 'primary' player being responsible for coordination (and perhaps the World Events calculations), perhaps off-loading some/all of her 'normal' local tile-stuff, in craftily parcelled chunks, to other players to even the load out. But with redundancy and shared status info so that her quitting from the collective seamlessly promotes a new primary, fully capable of continuing with minimum judder and even accepting the original primary back as a new subserviant client, so long as the peers don't split so much that there's no viable synchronisation kludgable together.  Which is probably a design-time decision, as to how much disruption can be tolerated without either forced-pause or something of an 'action amnesty' for the most off-script of the returning/reconnecting player machines, as they are brought back into line safely.