Print

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

[JayThePro]

So this isn't as much of a suggestion as it is an idea I have.

I used to frequent these forums alot (more like lurk), and had this idea a while ago.
However, I may actually have the possibility of making it come alive.

Obviously the idea of Multi-player isn't a new one, nor is it one is isn't asked about much too often.
More often than not, good ideas of implementation are thrown around, but never fully commendable.

Well, now that I've started college to receive my degree in computer sciences, I've used my research scholarship money for a server computer, mostly to host my honey pot penetration test servers.

However, now that the semester is at an end, I am free to do with whatever I please the rack.

Link: https://system76.com/servers/jackal-pro-2u    Fully Customized Flat Rack (Jackal)

Implementation isn't something I see totally out of arms reach either.
A few buddies of mine and I were able to get a fully functional Bogue Multi-player server working.

The real-time no-pause standard wasn't really an issue.
The game functioned as normal, only with less time to react.
The only problem I see with completing this with DF would be the idea of how much source would actually be needed to implement the server correctly (proper server world generation, proper entity control).

The server runs Ubuntu Server 2016, and would have no problem handling something like this (I would assume).

What I would really want to know is if the community sees this as a good idea.
Where the server is located has Internet speeds of up to 2gb/s, so the network side seems plausible.

However, would real-time Multi-player ultimately ruin the rogue like style? For those of us who like turns, and planning out every move.

Would there have to be a cap in how fast the turns move?
Maybe a Multi-player turn acceptance game based apon world region.

Thoughts?

[NW_Kohaku]

Generally speaking, the majority of the playerbase, and Toady, himself, do not want synchronous multiplayer.  It tends to fundamentally cut against the nature of a game where you're meant to pause the game and work out massive, complex constructions before leaving the game running for 3 hours while you go do other things.  (This isn't even to start on the problems that DF has with asynchronization resulting from different game loads resulting in massively different framerates, even in Adventurer mode.  In fortress mode, some players have nanoforts they optimize to run at 1000 FPS, while others build tremendous fortresses that run at 0.25 FPS unless they pause. Then there's the whole "Adventurer Mode runs 72 times faster than Fortress Mode" thing...)

When multiplayer is used in conjunction with DF, it is more the case of asynchronous gameplay.  Succession forts are a good example, but so is sharing of fortress saves with players who want to play as adventurers. 

The best thing Toady could do for allowing asynchronous multiplayer is to add a method of playing games that take place in the same year, potentially on different computers, then having a routine "merging" point. This would mean that players could, for example, all run their own fortresses, then throw them into a single master file that merges the effects of these before generating the events the other fortresses will experience.  That idea was back when the world events ran annually, however, so it may be more complicated now than just running it every new year the way that players currently hand off succession games.  This would help enable the creation of "adventurer worlds" where players can all "simultaneously" create a bunch of fortresses at roughly the same time that are all large and detailed and filled with events for adventurers to experience.  At the furthest reaches of the possible futures, it may even allow for competitive play between fortresses as the world activation and control over outlying territories becomes possible, allowing players of elven retreats and dwarven fortresses to send sieges at one another, albeit with yearly delays between "moves".

[Dozebôm Lolumzalìs]

Keep in mind that with internets, the one year problem could be moved to a one month problem. The only issue is getting people to play, but s strong AI could fix the lazy player problem.

[Adam Mantine]

Generally speaking, the majority of the playerbase, and Toady, himself, do not want synchronous multiplayer.  It tends to fundamentally cut against the nature of a game where you're meant to pause the game and work out massive, complex constructions before leaving the game running for 3 hours while you go do other things.  (This isn't even to start on the problems that DF has with asynchronization resulting from different game loads resulting in massively different framerates, even in Adventurer mode.  In fortress mode, some players have nanoforts they optimize to run at 1000 FPS, while others build tremendous fortresses that run at 0.25 FPS unless they pause. Then there's the whole "Adventurer Mode runs 72 times faster than Fortress Mode" thing...)

I agree with being opposed to multiplayer

[Bumber]

In theory you could have synchronous multiplayer for fort mode using an external client. The players queue up their actions through the client, which are then sent to the server and processed as atomic transactions. You would have to watch out for interference, though. If a goblin siege arrives and multiple players all order the main gate lever pulled, it might not end well.

Adventure mode was attempted, but had issues with companion AI trying to constantly move to the player. It could be fixed, but you still wouldn't be able to wander too far from one another.

Quite frankly, though, it would be easier just to build a similar game from scratch.

[TheBiggerFish]

Multiplayer and Dwarf Fortress are not really compatible ideas.

[Reelya]

Maybe multiplayer single fortress, where there's a custom client based on DFHack rather than working through the regular interface. Basically make it like one of those starship command multiplayer games where each actual player has some well-defined set of duties to perform. Alternatively, there could be a number of burrows, and each player can command dwarfs and build only in their own burrow.

A shared single fortress is the most viable way of getting this off the ground, but it begs the question of persistence: What happens when someone/everyone logs off?

But the question isn't really "can we do this"? Of course we can do that, there are already DF online projects using terminal emulation and the like. The bigger question is "how is it going to play? What are the players going to do? How do they interact? What happens when everyone logs off?"

[Urlance Woolsbane]

Let's see...

Fortress Mode
Single Fortress
Eliminating the pause feature, at least as it stands, seems necessary. Doing so would certainly make things harder, but this is Dwarf Fortress we're talking about. The players would have to think on their feet more, but that's not necessarily a bad thing.

Perhaps actions like building or designating could pause the game for a minute tops, with a half-minute cooldown, or somesuch? This would eliminate the problem of a player having to leave the computer suddenly whilst the game is paused, while still allowing the players time to plan.


Then there's the issue of player-control. Presumably, each overseer would have a different set of duties, which might cycle from player to player occasionally. The specifics of this would hopefully be customizable. Or, if we go the no-pause route, control could be divided by zone.

Additionally, the squad or burrow features might be hacked to give each player his own set of dwarves.


Now for the biggie, i.e. time-delay. It seems that someone will need to discover how to suspend certain vital routines and replace their data with that of a master DF on the server-computer. This in itself seems hard enough. Then there's issue of performance discrepancy between computers. Do we set an FPS-cap based on worst computer in a given game (assuming this is possible) or do we come up with some sort of quick-correct system for when a computer falls behind (again of dubious possibility)?

Multi-Fortress
This seems considerably simpler. The time-delay problems still apply, but not to such a great extent. The biggest issue would probably be interaction between the players.

Forts being able to send merchants or sieges to each other would be quite cool.

Adventure Mode
This one, by virtue of being turn-based, requires a major overhaul.

Quick-travel would need to be synced with regular travel, making the players much faster. Perhaps the day could be sped up to compensate?

Then there's combat, which I'm not at all sure about. I can see it working, provided each move has a time limit, but I can also see it being incredibly tedious. Perhaps players could be required to prepare macros for fighting?

Conversation presents yet another difficulty. It wouldn't do for a player to be cut down just because he was distracted looking for the right rumor to spread. I think the presence of a hostile onscreen would need to instantly abort combat. This would make yielding, etc, impossible, though. Perhaps those actions could be assigned to macros?

Then there's the issue of game speed... Yeah, perhaps Adventure Mode is better left untouched.

[Reelya]

For a single shared fortress, running local copies would just make the overheads worse. This would need a custom client and run only a single version on a powerful server.

For pause, the game could go into pause mode whenever there is nobody logged in.

Have the client code allow the crafting of designations and the like. The best way would be that players could plan out constructions and designations. Have the actual commands hacked in via DFhack, or by injecting recorded DF macros (which would only cause a slight hiccup in the frame rate).

[Dozebôm Lolumzalìs]

Let's see...

Fortress Mode
Single Fortress
Eliminating the pause feature, at least as it stands, seems necessary. Doing so would certainly make things harder, but this is Dwarf Fortress we're talking about. The players would have to think on their feet more, but that's not necessarily a bad thing.

No. Just no. Dwarf Fortress relies on the pause feature. See below.

Perhaps actions like building or designating could pause the game for a minute tops, with a half-minute cooldown, or somesuch? This would eliminate the problem of a player having to leave the computer suddenly whilst the game is paused, while still allowing the players time to plan.

This seems better, but still seems "kludgy". In addition, larger constructions can take well over ten minutes to even designate, let alone plan. How would those be dealt with?

Then there's the issue of player-control. Presumably, each overseer would have a different set of duties, which might cycle from player to player occasionally. The specifics of this would hopefully be customizable. Or, if we go the no-pause route, control could be divided by zone.

I think that having players cycle through could maybe work, at the expense of long-term planning - it'd be different people every hour!

Additionally, the squad or burrow features might be hacked to give each player his own set of dwarves.

...that would be incredibly hard. Each player would need to only be able to alter their own dwarves' orders - but what about designations? What about every single screen, like military, relationships, etc, that involves every dwarf in the fortress?

Now for the biggie, i.e. time-delay. It seems that someone will need to discover how to suspend certain vital routines and replace their data with that of a master DF on the server-computer. This in itself seems hard enough. Then there's issue of performance discrepancy between computers. Do we set an FPS-cap based on worst computer in a given game (assuming this is possible) or do we come up with some sort of quick-correct system for when a computer falls behind (again of dubious possibility)?

I don't understand what you're saying. Vital routines? Data replacement? Master DF?

Multi-Fortress
This seems considerably simpler. The time-delay problems still apply, but not to such a great extent. The biggest issue would probably be interaction between the players.

Forts being able to send merchants or sieges to each other would be quite cool.

This would work, and will probably be the only multiplayer DF - if such a thing is ever made. Many posts have been written about the logistics of this. I think maybe NW_Kohaku did something on this?

Adventure Mode
This one, by virtue of being turn-based, requires a major overhaul.

Quick-travel would need to be synced with regular travel, making the players much faster. Perhaps the day could be sped up to compensate?

Then there's combat, which I'm not at all sure about. I can see it working, provided each move has a time limit, but I can also see it being incredibly tedious. Perhaps players could be required to prepare macros for fighting?

Why is combat tedious? Either move or say A - b - e - g - enter. I can do that in a few seconds.

Conversation presents yet another difficulty. It wouldn't do for a player to be cut down just because he was distracted looking for the right rumor to spread. I think the presence of a hostile onscreen would need to instantly abort combat. This would make yielding, etc, impossible, though. Perhaps those actions could be assigned to macros?

...what. This would be turn-based. So unlike in other games, you couldn't be killed because you were looking away. Each turn takes one turn, and you'd be notified if you're being attacked, just like in normal adv mode. And I'm pretty sure you meant conversation, not combat, in the bolded word.

Then there's the issue of game speed... Yeah, perhaps Adventure Mode is better left untouched.

Agreed.

[Reelya]

Now for the biggie, i.e. time-delay. It seems that someone will need to discover how to suspend certain vital routines and replace their data with that of a master DF on the server-computer. This in itself seems hard enough. Then there's issue of performance discrepancy between computers. Do we set an FPS-cap based on worst computer in a given game (assuming this is possible) or do we come up with some sort of quick-correct system for when a computer falls behind (again of dubious possibility)?

I don't understand what you're saying. Vital routines? Data replacement? Master DF?

I think he's talking about the idea that everyone runs their own copy of DF with the same game on it, and we hack that data all together into a master copy that's on some server. Personally I think this is the least practical thing to implement.

My own interpretation of an achievable multi-player single Fortress involves just one running copy of the game on a server, and a custom client where the players can designate stuff and give orders, with all actual commands injected and data retrieved via DFhack. The middleware level would ensure that each player only receives appropriate inputs and outputs.

What would be cool is a 3D client, and some way to manually order dwarves around using DFhack, based on player inputs: a 3D "be a dwarf" game with persistence. Maybe we need to stop thinking as if it's going to be literally the same game, just multiplayer. It's not, it's more likely to be a completely different game, just leveraging DF as the server tech.

[JayThePro]

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.

[Bumber]

No. Just no. Dwarf Fortress relies on the pause feature. See below.

I don't think you ever fully addressed this. I've heard many people keep their games paused as little as they can once their FPS drops. It might be a little difficult to respond to threats in time, but not impossible. It gets easier if you have a player dedicated to defense. A custom client can allow checking menu data while viewing the fort, or targeting enemies easier.

This seems better, but still seems "kludgy". In addition, larger constructions can take well over ten minutes to even designate, let alone plan. How would those be dealt with?

They could be done little by little, or scaled down (in ambition) to fit the fast pace of a multiplayer game. You could cap FPS if you wanted no pausing and didn't mind a slower-paced game. There's also the possibility of using the new adv mode planning to speed things up.

...that would be incredibly hard. Each player would need to only be able to alter their own dwarves' orders - but what about designations? What about every single screen, like military, relationships, etc, that involves every dwarf in the fortress?

This could be handled by our custom client and DFHack, possibly made easier if some sort of official fort factions are added (i.e., no free-for-all loyalty cascades, groups owning locations.) If we can hack allegiances, we can have squads hostile with one another without repercussions (assuming DFHack can erase the crime, knowing the involved parties.) We can keep track of which client controls which dwarves, and players needn't see or touch the actual screens, with DFHack handling it under the hood. Burrows already control designations, I think, but we could also hack to intercept job assignment.

Adventure Mode
This one, by virtue of being turn-based, requires a major overhaul.

Quick-travel would need to be synced with regular travel, making the players much faster. Perhaps the day could be sped up to compensate?

Then there's combat, which I'm not at all sure about. I can see it working, provided each move has a time limit, but I can also see it being incredibly tedious. Perhaps players could be required to prepare macros for fighting?

Why is combat tedious? Either move or say A - b - e - g - enter. I can do that in a few seconds.

Adventure mode has the problem that players aren't constrained to fixed areas. This means that multiple separate copies of the game running is the only option.

Moving one tile is a fast action. Combat can be moderately fast, depending on circumstances. Talking and managing inventory is slow. Quick travel / sleep is excruciatingly slow at real time, yet intended to be extremely fast. Not only do you have to solve this discrepancy, but you have to enforce it. All clients must be on the same turn, which means synchronizing several copies of DF (which was never meant to be synched) across the internet because we can't host a world of adventurers on a single computer.

What it boils down to is 86400 ticks per adv mode day, at several seconds per tick. Your only solace is that pretty much everyone wants to skip the entire night (at least until Toady decides to add night stuff to towns.)

Then there's the issue of game speed... Yeah, perhaps Adventure Mode is better left untouched.

Agreed.

Exactly. I think the best we could hope for is companion co-op.

[Dozebôm Lolumzalìs]

Well, the pause function is needed because DF's playstyle is dependent (for most people) on the ability to stop, look at things, see your stocks, order your military around in fine detail, try things and wait a tick to see if they work, and designate things while nothing else happens. It's what separates the turn-based games from FPS with bad graphics.

Am I somewhat elitist? Perhaps. But you must admit that nopause would cause problems with large_screens like military, stocks, z-screen, etc.

[Adam Mantine]

Plus there's more than enough multiplayer games out there already