Print

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

[Mikademus]

I just had this amazing idea. DF is such a great idea, and so is Super Mario World and Galaxy. So what would make DF evan bettah is if we could make add 3D platforming action to it! We could collect stars that give health back to the dwarves and discover secrets and stuff! And what if this was multiplayer, so we could race each other? Like Sonic and Banjo Kazooie multiplayer racing in DF! That'd be AWESOME! And since GTA is da bestest game EVAR we should be able to hijack each others racing camels and stuff! This is what is missing from making DF really good! Add this and I promise I'll donate!

[Dr. Melon]

Haha, nice joke.

What we do need is multiplayer fortress mode (because it's not turn-based like adventure mode) which would rock awesome.

[Capntastic]

Actually fort mode is turn based it's just that the turns go very fact, depending on your processor, and would make synching up impossible, considering how much data is being processed and memorized.

[Kanil]

"Alright man, whatever you do, don't touch this lever, 'kay?"

"Got it, man."

*A section of the caverns has collapsed!*

"What the hell was that for?"

"Uh... ... I felt like it?"

[Deon]

This is another example why do we need moderators.
As long as it's a joke (with intentional bad grammar which I hate) it sits in the suggestions forum. And Toady spends his time reading these forums trying to find something useful in the mess we want. And constantly is disturbed by stupid suggestions and jokes. To the Various Nonsense next time with the thing like this, please.

[ June 14, 2008: Message edited by: Deon ]

[Andir]

quote:Originally posted by Capntastic:
<STRONG>Actually fort mode is turn based it's just that the turns go very fact, depending on your processor, and would make synching up impossible, considering how much data is being processed and memorized.</STRONG>

The simple solution is something I've already posted several times.  You have an executable server that processes the game.  The interface is something akin to an MMO client where you log into the server and you are sent information regarding only the information needed to populate your screen.  We are talking VERY little bandwidth.  You could have as many clients as the server has bandwidth.  This could also be a way to open source part of the game (the interface) to allow other people to make whatever flashy interfaces they want and allow Toady the ability to work on the core components without worrying about graphic representation.

[Fishersalwaysdie]

Seconded.

[Arbitrary Value]

quote:Originally posted by Andir:
<STRONG>
The simple solution is something I've already posted several times.  You have an executable server that processes the game.  The interface is something akin to an MMO client where you log into the server and you are sent information regarding only the information needed to populate your screen.  We are talking VERY little bandwidth.  You could have as many clients as the server has bandwidth.  This could also be a way to open source part of the game (the interface) to allow other people to make whatever flashy interfaces they want and allow Toady the ability to work on the core components without worrying about graphic representation.</STRONG>

I am using this design for a turn-based game that I am making, and it is working very well for me.  However, I don't think that it can work for Dwarf Fortress.

The problem is not bandwidth but rather latency.  It's easy for me to transfer a gigabyte of data to you over a fast connection.  However, it is much less easy for me to transfer one hundred thousand ten-kilobyte chunks of that data and make sure that those chunks all arrive, are all in order, and are all evenly-spaced in real time.

My game is turn-based, so I only need to send the state of the world to players several times a minute (whenever everyone ends their turn).  I can use TCP to do this, and while TCP is slow, it is easy to use and reliable.

Dwarf Fortress would need to send the state of the world to players many times a second.  I can't think of a way to do that effectively with a purely dumb-terminal design.  (MMOs and first-person shooters are not dumb-terminals.)

[Andir]

quote:Originally posted by Arbitrary Value:
<STRONG>

I am using this design for a turn-based game that I am making, and it is working very well for me.  However, I don't think that it can work for Dwarf Fortress.

The problem is not bandwidth but rather latency.  It's easy for me to transfer a gigabyte of data to you over a fast connection.  However, it is much less easy for me to transfer one hundred thousand ten-kilobyte chunks of that data and make sure that those chunks all arrive, are all in order, and are all evenly-spaced in real time.

My game is turn-based, so I only need to send the state of the world to players several times a minute (whenever everyone ends their turn).  I can use TCP to do this, and while TCP is slow, it is easy to use and reliable.

Dwarf Fortress would need to send the state of the world to players many times a second.  I can't think of a way to do that effectively with a purely dumb-terminal design.  (MMOs and first-person shooters are not dumb-terminals.)</STRONG>

You don't need to send the whole world.  You only send the current visible screen.  When the person queues up a command (mine, build, etc.) you send those commands to the server and the server relays those commands to the clients in visible range.  If the command cannot be carried out on the server because someone already did something to that tile, you kick back the job to the client saying that it could not be completed.  Whenever the server obtains a job (mining, building, etc.) you alert the clients who are in the area of the job so they can update their screen.

Never would you send the whole world.  That's highly inefficient.

[Draco18s]

The issue comes in when one person designating mining and everyone else isn't:

At what speed does the world run?

[Andir]

The issue comes in when one person designating mining and everyone else isn't:

At what speed does the world run?

Why should it matter if one person designates mining and others don't?  When you designate a mining location, you send that to the server, the server then notifies all the people that happen to be looking at that area that a new designation is applied to one of the tiles.

The world would run at a constant speed, set by the host.  If you really wanted to allow players to pause, you could also do so, but it would pause everyone's game.  Again, server would send a broadcast: "Paused by Andir..."

[Zemat]

A Spore-like MMO system would work best for DF.

Everyone who logs into the server gets a copy of the most recent state of the world and the player can play either fortress or adventure mode on his own. And only once every logon or something the world status updates with all changes in the world done by others since the last logon. When the player logs out his changes are uploaded to the server. Discrepancies like two different adventurers killing the same enemy at the same time could be resolved simply by giving the killing title to the one who did it first before the world synch. But the other player won't lose stats or quest rewards for not doing it first.

Every adventurer would have to retire in town (and disappear temporally) before leaving the game so that his character won't be killed during the off-time. Player fortresses would stay on a semi-static mode (nothing changes but dwarves react to adventurers) during off-time. But players would have to create good defenses to prevent population decline due to "invading" adventurers. Starting fortresses could get a invulnerability period where no adventurers can arrive while their population is low or before x amount of seasons pass.

On the other hand, time would be something that is handled server-side but at a much slower rate that in the single player mode. Something like a single season per day or week. Certain amount of food would be consumed and produced abstractly for each day the player doesn't logs in. Every other activity or order would stay on hold until the player logs again. Siegers, traders, and migrants that arrive offline would wait until the player logs in before interacting with the fortress. And no other group of the same type is sent to the fortress until the player handles the previous group.

[Okenido]

Why just why?

[Draco18s]

The world would run at a constant speed, set by the host.  If you really wanted to allow players to pause, you could also do so, but it would pause everyone's game.  Again, server would send a broadcast: "Paused by Andir..."

That is almost certainly doomed for failure.  The more people you have connected the more it'll be paused as people take time to designate new mining areas, queue up work orders, check for trapped masons, etc.

DF
Does
Not
Do
Multiplayer.

[Andir]

The world would run at a constant speed, set by the host.  If you really wanted to allow players to pause, you could also do so, but it would pause everyone's game.  Again, server would send a broadcast: "Paused by Andir..."

That is almost certainly doomed for failure.  The more people you have connected the more it'll be paused as people take time to designate new mining areas, queue up work orders, check for trapped masons, etc.

DF
Does
Not
Do
Multiplayer.

Then you don't allow pausing.  Jeeze.  Of course the game wouldhave to have a better interface first so you didn't have to kill a baby calf to gain access to the appropriate window to see that someone might be stuck.  Just because YOU don't WANT multiplayer doesn't mean it's not possible.