Print

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

[Retro]

In theory I agree that's possible. In practice I think it's unworkable. Being forced to be paused while someone else does something will slow the game down more than any FPS hit, and imagine having four people playing at once. As patient as people can be, it would grate the nerves just with the pausing alone.

You're assuming it would still pause whenever someone did anything.

Since synchronized time is only needed in player vs. player combat players could freely play and pause their games at their own pace (read: FPS). Once every few minutes, 30 minutes, 1 hour, or any (configurable) time the game could be paused in turn from the most advanced (in time) player to the last player so everyone can catch up. The paused players can take this time to do whatever management they want but could not unpause the game.

Pausing isn't 'quick' in DF. I've played an RL week without unpausing before, just marking designations and placing buildings. Even in less extreme cases, the average DF player pauses a lot because to do just about everything in the game, pausing is required. The slower players will see it as just playing normally, but for even the second-slowest player the pause to resync will take a while. The fastest player might as well go make dinner while the slowest's game is syncing.

I admit this is a negative view of the entire thing, but I also feel it's realistic. In a mostly-paused game like DF I simply fail to see how multiplayer would work in any sort of cooperative manner without changing the nature of the game's programming. I could see it working maybe whenever Toady gets around to working on the real-time designating stuff, but until then I'm highly skeptical.

[Shades]

Being forced to be paused while someone else does something will slow the game down more than any FPS hit, and imagine having four people playing at once.

so could ignore pausing for the most part

As in the system would only pause briefly to issue the commands the players would not need to pause otherwise due to the decoupling. And yes I'm assuming a few things about the amount of control there is in the render system, I've not looked through the code on that or the code from the various people that have developed remote layers already.

It would of course limit you to co-operative fortresses and probably not be much fun, but anything more complex will require significant work.

[Thief^]

The game would have to be able to be played without pausing before multiplayer could be done, that's for sure.

Designations aren't too bad, neither is looking at units. One problem screen is the "choose items to use in construction" one, especially for stone it stalls quite badly, and updating it in realtime...

[Jiri Petru]

What would be the difference between "multiplayer" DF and singleplayer DF? 

[Thief^]

Coop fortress play would be great for teaching new players, or just generally playing coop. Coop adventure mode would be pretty nice too.

[zwei]

 

The game would have to be able to be played without pausing before multiplayer could be done, that's for sure.

Designations aren't too bad, neither is looking at units. One problem screen is the "choose items to use in construction" one, especially for stone it stalls quite badly, and updating it in realtime...

Also, currently game could make use of pauses to run expensive optimalizations without hurting FPS (i.e. to recalculate TSKed items in order to TSK closest one or to precompute various )

I would also note that not-pausing during constructions would have huge benefits because complext designations can take a lot of player time. It would be great to have miners actually dig rooms as you designate them rather than spending 10 minutes deisgnating floor and then wait 10 more till it is dug. Same will walls or furniture.

[Firehound]

Of course, you run the issue of Some guy keeling dah elves/ flooding the world with magma. Though If you ran from a rather good server, that handles the world and several fortresses, You can lose Player A having Deep Blue as their desktop, and Player B running on a Commodore 64. Also, if the game pregenerates up to a season ahead, and just auto unpause after the threshold has been reached, as well as making the Units, Military, Manager, and Orders tabs running unpaused will allow the game to run in sync.

[Hakar]

The only thing I'd like to see is a single caravan visiting different forts, so you could import someone else's food, crafts and weapons.

[Exponent]

Then obviously those two players don't play together. I have seen this in other games, too..

In game world time passes in fortress mode.   If some player is even a few in game days behind another player, then you run into all sorts of problems unless they are always 100% in sync.   This is one of the main problems with having a multiplayer fort.

Yes, world time passes as fortress time passes, but I doubt world calculations are done every single tick of fortress time.  Some things might happen once a day or so (for example, calculating weather across the world), but since player actions typically cannot affect these things, sync isn't a problem, as they can remain fully deterministic.  (And if not fully deterministic, then the server can store a buffer of upcoming changes to the world that it has already calculated for the faster clients, and that slower clients will need in the near future.)

Designed appropriately, things which are affected by player actions can be introduced to the world level mechanics only once every game month, or game season even.  This way, sync only needs to happen at this relatively infrequent time.  So you sent an army to attack your neighbor (who is possibly a human player).  The server doesn't process the army until the end of the month, at sync time, at which point it decides if it has reached its destination yet or not.  If so, then during the next month, your neighbor will have to deal with your army (over which you would have no direct control, nor would you know the results until the next sync time at the earliest).  Same with sending out merchant caravans, affecting the animal population, or if world interaction got really ambitious in the future, affecting things like water flow (e.g., damming a river will dry up everything downstream).

[vooood]

EACH FORT is simulated on IT'S OWN PC.
ONE SERVER simulates ONLY OVERLAND ARMY/CARAVAN movement.
SYNCING can happen once per season, once per 30 minutes, or whatever the players decide.
IF your opponent is too slow find another one - a simple solution that is working and is used in ALL turn based games.

I see only one issue here and it's related to combat - my army versus your army - simulation of this should happen only on one PC and pausing should be somewhat limited (like 2 pauses per 10 minutes for example) so it's a nice experience for both players.

I hope that now everyone understands what I'm talking about. Pausing in my approach is somewhat like in the Heroes of Might&Magic games. You play your turn fast and then wait 20 minutes for the other 4 players to complete their turns. This could be also somewhat managed. Look at the following example:

Two players are playing. Each is playing his own for and they are not attacking each other, just sending caravans. Let's say DF calculates caravan positions once per month. So we have a faster FPS player complete a month earlier than the slower one. The game is paused for the faster player. Pausing is now somewhat limited to (for example) 2 minutes per 10 minutes of playing so the faster player is not waiting too much. So the faster player takes a toilet break and the slower player manages to finish the month in the following 5 minutes. The "server" calculates caravan positions and other world entities and the game is synced and unpased for both players just to repeat the same thing next (ingame) month.

In case of PvP the FPS would simply be synced and pausing also limited, but combat is not happening ALL the time but I suppose once a year or maybe even less frequent..

[Shades]

EACH FORT is simulated on IT'S OWN PC.
ONE SERVER simulates ONLY OVERLAND ARMY/CARAVAN movement.
SYNCING can happen once per season, once per 30 minutes, or whatever the players decide.
IF your opponent is too slow find another one - a simple solution that is working and is used in ALL turn based games.

This is not a sensible way to do it, and is _NOT_ used in any turn based game I can think of, certainly not anything vaguely recent. I can't even think of many (any?) play by email games that work this way, most at least use a host for this.

[Aachen]

Anyone about ever play (rather, try (or just have incredible patience)) MoO2 multiplayer?

[catsplosion]

There's always the more practical possibility of letting more than one player mark designations on the same fortress, with the understanding that they're probably sitting in the same room trying to make each others' dwarves pull levers attached to supports or atom smashers.  The game itself needs no rule changes for that, and it doesn't need to distinguish ownership or designations from one player to the other -- they're just two cursors into the same god, as far as the game need care.

(The notion of "each others' dwarves" would exist, of course, solely in their fleshy human minds.)

[Schilcote]

Multiplayer adventure mode would be interesting, and possibly less problematic than fortress mode (since you don't need to do any pausing, and the player is a distinct entity). Just have the players be in an adventuring squad similar to what NPCs do when joining the player now.

[catsplosion]

Multiplayer adventure mode would be a nightmare!  You'd have to wait for the other player's every keypress.