Ditto surprise that this hasn't been Footkerchiefed. (The Multiplayer suggestion is a fairly recurring one.) [Although as this message has become quite long, I've probably been ninjaed, in this regard. So long that I've decided to Spolier-enclose the different sections]
To add insult to injury, however, I'll repeat some of the past stuff (very much from my own perspective and interpretation), while I split the "multiplayer" aspect into several possible "how it could work" explanations:
Well, we have DFTerm. But how about independent cursors, independently operating... independently. The big thing here is that there could not be pause-time (unless everyone set themselves as wishing to pause, perhaps, or by being idle/setting themselves up to auto-accept the group-pause situation... which might allow siege-time/emergency flood-control efforts to be properly managed, while normally each person gets on with micromanaging their own bit of the fortress.
It's perhaps a bit like the reverse of the bed-using bit of multiplayer Minecraft (insofar as I understand how that works, given I've never played MC in multiplayer), which I think is supposed to set the sleep-time fast-forward only when all players are bed-ridden and sleeping, to be ceased as soon as waking-up time occurs.
Beyond the pause-synchronisation, we also have the real-time synchronisation of the site-dynamic simulations (everything from fluids, 'PC' entities such as dwarves, 'NPC' entities such as pets, wildlife, wanders, invaders, general hostiles). It wouldn't make much sense for each players machine to do the same calculations (synching the PRNG, or drawing from a pool) and be slowed down to the speed of the weakest machine, so it would be perhaps conducive to hand out a proportion of the site's 'fiddling' calculations to each machine, based upon relative performance within the 'mass', sharing (and merging) the end-result. Dropped links and bad communications would have to mean re-assigning that segment of the shared processing among the 'working' network, reducing/removing the load on the offending player's machine, perhaps (after sufficient violations) throwing them off the network.
There would be additional overheads involved in this management, but it might still be as fast as the faster machine. In order to deal with cases of compromised simulation-collation, each 'tick' would probably have to wait until all machines submitted their bit (and each machine confirmed that they'd got enough information to combine everything) before the next game Tick, but it wouldn't be as disruptive as an FPS (Doom-like) that traditional has had to have each client "speculatively" and independently work out some things and 'resolve the slight differences in other-player position', when better slightly-outdated 'real-time' information comes in.
Much the same as above, in every respect, except with additional "territorial limitations". e.g. Building in the SW corner is limited to Player A, and in the NE to Player B, dynamically changing with some form of territory-control method. Entity control would be universal (for ones own units), e.g. military way-points would be unrestricted, although trap-deconstruction (excepting for perhaps by an Engineer-skilled military unit, once the trap existence is known...).
"Fog Of War"? Perhaps ambusher-style "hidden unit" on anything outside of immediate visual range, perhaps even applied to 'enemy' constructions. The distribution of simulation effort may perhaps be strictly (save for random, no-man's-land stuff) dedicated to the client of the territory, if only for logistic purposes given that they're more concerned with that, although it could be embark-wide shared similar to #1. (Also, a #1-style cooperative embark could also be equipped with "This is your work area" limitations to building/unbuilding/digging/whatever tasks, per player.)
Within the scope of option 2, add in the possibility of code-enforced alliances. Already you could play multiplayer in any 'competitive mode' to just compartmentalise a cooperative effort, but "allow Player B to build in 'my' (Player A's)" area(/volume), but not to dig through it!" options, settable and unsettable as required, perhaps even tied to player-defined Zoning for finer control (access corridors, etc, at least while the player concerned has overall control of that area).
The most basic idea suggested for multiplayer is trading. The ability to send a caravan of ones own out to another embark site (same world, different player) and trade. In many ways, one might not need to keep much synchronisation, although it does rather make it a different game if one can decided to pause the game in year 123, while another player builds up copious stocks of vital materials and eventually in their year 135, but to arrive in your much younger fort, now unpaused to accept the trade delegation, and now with loads of spiffy masterwork spoilermetal suits and edged weaponry.
Of course, there might be the limitation on how much a younger fort could trade for an older one. Not that trade-goods are currently that difficult to pile up, and one also rather assumes when it's two players, or one player with two 'games', the trading limitations would be far less strict than "Traders always need to make a profit, never a loss!", and so "an earring traded for a units-worth of masterwork breastplates" (to one player, a massive loss, to the other a massive gain, under 'single-player' rules) is a possible exploit, for those willing to attempt such.
More tightly controlled would be (especially competitive) expeditionary, miltary-arc "go visiting someone else's site" multiplayer inter-embark play. Time-wise, you'd want to try to keep people fairly synchronised. It could still be 'loose', insofar as rejigging it so that an army (or other expedition) that you sent (not in Real Time, but in the Adventure-Mode 'Travel' manner) would take time, and then you'd only need to make sure that the target site was no further ahead than the travel-time. If they were at the limit, you'd send your force and then they'd immediately be dealing with it. (If the expedition is out of the owner's control, i.e. acts as a regular visit from hostile/trading/liaisoning visitors, then their computer could handle the details, then send the results back to you, or lack of any returning information, as soon as you could be expected to receive the result. If it's a two-player thing, then you could play a Type #1 or #2 game, but you wouldn't expect the rewards/loot/traded-goods until a similar future date.)
If the target site was behind the sending-site's timeline, then things wouldn't happen until it caught up, but you'd have to be limited in your own time-advance to a point at which you'd normally expect a return. By the system of being re already limited to advancing to more than a one-way-trip's time ahead of the other player(s), so the new limit (of a return trip) shouldn't be an additional problem, or indeed need to be worked out over and above the former... And it could be a retaliative/reciprocal force sent your way, as much as returning heroes/traders/whatever.
A bigger, 'better' multiuser system might allow mobile (or reconolonising) fortress embark areas, but this probably comes under the same aegis as the (and, I think, planned for!) single-player "not just the original embark" idea. Whether of the order of sending out units to create satellite 'prospector' camps (played as a new/parallel embark, or 'simulated' with just the returning spoils seen) or going for a "mobile fortress" idea, where your embark site gains along one edge while you abandon 'tailings' along another. However this turns out, options #1..#4 could be worked into this (if, of course, #1..#4 ever come into being, and I'm not saying they will).
Probably trickiest, without losing the "take as long as you want over each turn" aspect. Would need some form of shortening combat (perhaps 'macroing' moves-and-responses to hotkey-presses, which I think is the most complex and time-consuming aspect of adventuring). Moving, and not moving, would need to happen with a ticking clock. While you're trading (or considering what to trade), the bustle of the market would continue, even while you were haggling. Day and night would come and go. And, like in #1, either there's no pause, or a sensible method for pausing everyone at once...
Of course, Toady's declined to arrange/support much of this, as is his perogative. All in all, the multiplayer-facet would make it a significantly (and, in some cases,
vastly) different game from how it is right now. I could see how people would enjoy cooperative/combative play. Certainly its an oft-suggested idea. I've tried to avoid most of the nay-saying and pitfall-indicating in the above, and stick to "how it might happen", but... the mechanisms needed to make multiplayer work (in whatever variety of multiplayer you might be interested in) are probably also the biggest stumbling block, however much they are the 'solution' to the problems inherent in that form of reimplementation.
And, of course, I did not mention (because they already exist) the "Succession Fortress" multiplaying option.
(Shadowclaimer: I did not mention central-server maintenance of game-state, I suppose because I felt that data-hand-out-and-collate method would be a far better method than having a central non-player box... Or one player who hosts
all the other's efforts, when at least some effort could be shared. But that
is a solution, I acknowledge.)
Author
Topic: Multiplayer support and Servers? (Read 1136 times)