Print

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

[OldManNeck]

The best way to start in my opinion is an optional connection, that would allow other players forts to appear. If conditions, such as date and location are set right, other players forts would be placed in those spots, kind of like Spore. Maybe a fort could be updated based on the player's status. That way there would be some kind of connection to start out with, which could be sort of beach-head for more in-depth player interaction later.

[NRN_R_Sumo1]

DF Multiplayer would require its own seperate client based off the games sourcecode.. which I doubt will be released for some fair time, as toady hasnt even told us what all the personality skills do yet.


I'm no expert programmer or anything, but I Do have my hand in it now and then. The console would have to control a diff civ than the regular which would be patched to act as the games server, controlling all the placement of the units on the grid most likely through memory editing, as I do not believe npc's can as yet be designated to do tasks.. but in the case they are that would make it even easier. as you'd only have to mirror the designations and commands. 
Designations would be client side of course, as server side would cause jumbles of dwarves fighting kobolds for building walls, resulting in spam job cancellations.

[Slappy Moose]

Once the new version is over I believe it would take a week at most to make it multiplayer capable.

WhaaaaaaaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT!?!??!

[Dabi]

TROLL.

[NRN_R_Sumo1]

TROLL.

I'll say.

[immibis]

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..

I see a better solution. Just scale the slower player's time so that, if the slower player is say 50% of the faster player's speed, one day is 600 ticks instead of 1200. That solves all the problems relating to multiplayer. The slower player wouldn't be able to build as fast, but there doesn't seem to be any easy solution for that.

[Dasleah]

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..

I see a better solution. Just scale the slower player's time so that, if the slower player is say 50% of the faster player's speed, one day is 600 ticks instead of 1200. That solves all the problems relating to multiplayer. The slower player wouldn't be able to build as fast, but there doesn't seem to be any easy solution for that.

I see an even better solution.

Just zip and email the save file.

[RaidSoft]

Even better, use dropbox so that every time you save your save file it updates automatically to whoever is connected to that dropbox folder! Although this could be a problem if multiple people play on the same save file at the same time ;P Hell dropbox even allows you to revert the file to a previous version so you could revert it if someone messed it up

[Imofexios]

Forget the pausing and let the game roll freely and slow it slight to limit fps to all in 50pfs.
Problem is here how to get both to interact on same local as individual.

[Shades]

Forget the pausing and let the game roll freely and slow it slight to limit fps to all in 50pfs.
Problem is here how to get both to interact on same local as individual.

For a co-operative fortress, very simple. Anything else (as far as I can see) would required Toady to do some work on it.

[MrWiggles]

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

No, unlike other rogue likes, adventure mode isn't turn based on the player movements. It is turn base for combat, though if player can live without selection choice real time combat from fortress mode could be used somehow.

[catsplosion]

Adventure mode is either tick based, with a priority queue, or turn based with very short turns -- what we lovingly call frames in fortress mode but know aren't being drawn.  Either way it blocks on input from each creature as soon as its initiative gives it a move.  It's not the turns that'll drive you mad in co-op: it's the unpredictable blocking.

(This is why cage traps hang adventure mode.  The player character never gets another move.  Screen refresh and keyboard input are handled on the player's turn.  Adventure mode really is the same as fortress mode except that overland time passes at a different rate, nighttime is rendered, and the game blocks on player turns.)

[Dabi]

TROLL.

I'll say.
...

It's so true...-_- I want to cry each time i read a new post on this thread

[HungryHobo]

This is just a tought from another (game) developer.

Assuming you're a programmer this hits many....many of the same problems that trying to add threading would.
plus a whole load more....

You may want to have a bit of a think about how complex DF is.
1 week?
I'd be stunned if someone could put together anything more than a crappy hack for this is 1 year.

[Thexor]

Assuming we're all still talking about multiplayer games... I think you guys need to take a quick look on the main forum page.

In particular, you might be interested in this thread, which appears to provide a (semi-)realistic way to deal with multiplayer syncing issues.



The concept is simple: trying to sync multiple computers is physically impossible. Even a few milliseconds of lag could cause desync issues, since the order of operations is critically important to DF. Even if you had two identical machines operating on a LAN, you'd still have enough lag that any attempt for direct multiplayer would eventually desync and fail.


Dfterm, however, uses a remote terminal to view and interact with a remote computer. Think about it: what if you could modify this system to support multiple inputs? It'd be more like a standard server-client architecture. The server would be the only machine actually running DF - everybody else would pass instructions through Dfterm.

You'd still have a few issues (if one person opens a designation window, nobody else can interact with the system until they've finished), but that could be sorted out once Toady decouples the UI from the underlying game (if he ever does, obviously). Fundamentally, you'd only have one game of DF running, just with multiple people trying to control it.