Print

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

[rcmgames]

This is very interesting. We would need to stop thinking about time passing compared to each fortress, and just think of interactions. The only time the two fortress would need to be synced up would be when they interact. If you're sending goods to be traded, armies, etc. All other aspects of the game can happen independently. I could play for a year, and you only for a month, and there would be no problem interacting. It would be like a new fortress and a seasoned one meeting. The time difference is only noticeable by the users (we both started last night, but I played for 1 hour while you played 15min...), but the game doesn't need to know that. It only disjoints us then the next night I play 15 min, and you play 2 hours, now your fortress is way more advanced then mine, the game can easily deal with that when interaction occurs, it's just us who feel its disjointed.

The only problem would be me wanted to invade you when you're not on. That wouldn't work properly.

[Kipi]

This is very interesting. We would need to stop thinking about time passing compared to each fortress, and just think of interactions. The only time the two fortress would need to be synced up would be when they interact. If you're sending goods to be traded, armies, etc. All other aspects of the game can happen independently. I could play for a year, and you only for a month, and there would be no problem interacting. It would be like a new fortress and a seasoned one meeting. The time difference is only noticeable by the users (we both started last night, but I played for 1 hour while you played 15min...), but the game doesn't need to know that. It only disjoints us then the next night I play 15 min, and you play 2 hours, now your fortress is way more advanced then mine, the game can easily deal with that when interaction occurs, it's just us who feel its disjointed.

The only problem would be me wanted to invade you when you're not on. That wouldn't work properly.

Sorry, but to have even slightest chance to implement multiplayer to DF we need to solve the pausing problem.

So, if I understood your text correctly, the only moment the games must be synched is when sieging/trading/other interaction between players happens? Even then it would be problematic and not just something the game can "easily deal". Bellow are two examples of the problems that will occur. For the sake of my own sanity I will use A and B to refer two players and the time unit is taken from inside the game since real time doesn't actually matter that much. After all, while playing one hour I can cover more in-game time than somebody else due playing style and FPS.

• After first "session" A has advanced from year 101 to year 105 while B is still in the middle of year 103. Player A sends a caravan to player B and thus interaction occurs. The only way the game could handle this is to pass the caravan to player B when he reaches the date inside the game when the A sent it. So, year 105 arrives, player B does some trading and send the caravan back. It's still year 105 when the caravan departs. Now, what if player A has managed to reach year 110 during this time? Less than one year travel time to the destination, few months inside the depot and suddenly five years back to home? Sorry, for me this sounds just too weird.
• Same starting situation but now B sends caravan to A. It leaves at 103 and arrives to destination at 105. But suddenly B can't play that much and caravan is still in B's fort when he quits. Before B logs back in A has managed to reach year 109. Six years without 3 to 20 dwarves, some of them being soldiers? Too long IMO.

Now, these are the problems when the game only synchs during interactions. But, like I most probably have mentioned in this thread already, the game is too complicated to leave it to that. What about other civilizations? Megabeasts? What if A managed to kill a dwarven merchant after B has met him while A being still behind in game time? Or what if B kills a megabeast? If the games aren't synched all the time there could be conflicts when the megabeasts arrives to A's fort, even though B has killed it already?

If I wanted to play DF with others I would want to have shared history. A history where titan died 21st of Granite, year 1341. It wouldn't be right to have a history where the titan died 21st of Grante, year 1341, AND 6th of Obsidian, year 1420...

So no, we can't just stop thinking about pausing, as it's the core problem of multiplayer in DF...

[rcmgames]

I understand what you are saying, but the way I was thinking of it was like this: why do we need to keep accurate time between these two fortresses? And the problem you seem to bring up is mega-beast deaths, events, etc having dates of when they occurred. Also about the caravans arriving on years for player B, then sent back to player A way in the future (technically taking 5 years to get back). What I'm suggesting is why do we need to say it was 5 years. Throughout history there have been advanced and less advanced civilizations. Why should you be punished for 'playing' extra and being 5 years more advanced as me. If you send a caravan to me, if I don't respond to it, it should default come back in a years time if I'm not playing. If I'm playing and I trade, yet it I have it paused for a year after I trade and your caravan stays here, your fortress is one year more advanced then mine, when I unpause, it travels back and things keep playing out.

Also, when I said 'sync' I really meant that the games have to interact with eachother, not really the times have to be the same. Sorry if the way I'm saying things isn't making clear sense, I'm sort of just brainstorming and typing, because I'm excited about thinking of the prospect of an idea like this and things are just flowing.

I understand that it may not be logical or even possible in this game, but does anyone understand what I'm trying to say when I say that the two fortresses don't necessarily have to match up in the timeline? I know this causes problems with recording history, but I'm sure there is some logic and math that can be put into the timelines to make them 'match up' with regards to when we look back in history to when things happen...

[GreatWyrmGold]

If the two fortresses can interact, pausing and quitting will cause issues.
If they can't interact, what's the point?
Also, it would require major additions just to get the game to recognize games on different computers as being the same world, or to even be aware they exist.

[Kipi]

I understand what you are saying, but the way I was thinking of it was like this: why do we need to keep accurate time between these two fortresses? And the problem you seem to bring up is mega-beast deaths, events, etc having dates of when they occurred. Also about the caravans arriving on years for player B, then sent back to player A way in the future (technically taking 5 years to get back). What I'm suggesting is why do we need to say it was 5 years. Throughout history there have been advanced and less advanced civilizations. Why should you be punished for 'playing' extra and being 5 years more advanced as me. If you send a caravan to me, if I don't respond to it, it should default come back in a years time if I'm not playing. If I'm playing and I trade, yet it I have it paused for a year after I trade and your caravan stays here, your fortress is one year more advanced then mine, when I unpause, it travels back and things keep playing out.

Yes, that could work, but the dates are still messed up if caravan can "travel in time" (or sieges or anything). For example, how could the game handle something like when a dwarf, from other player fortress, dies? What if it died before it was born? Or how about the situation where the dwarf has already reached the adulthood in fortress A but should still be considered as child or baby in fortress B? Would the dwarf in question transform to a proper stage of age or should the game just use the age from the original fort? The same problem exists basically with every creature inside the game.

What it would mean to solve this problem in the way you are suggesting basically requires total rewrite of how dates, age and history is handled by the game.

Also, when I said 'sync' I really meant that the games have to interact with eachother, not really the times have to be the same. Sorry if the way I'm saying things isn't making clear sense, I'm sort of just brainstorming and typing, because I'm excited about thinking of the prospect of an idea like this and things are just flowing.

I understand that it may not be logical or even possible in this game, but does anyone understand what I'm trying to say when I say that the two fortresses don't necessarily have to match up in the timeline? I know this causes problems with recording history, but I'm sure there is some logic and math that can be put into the timelines to make them 'match up' with regards to when we look back in history to when things happen...

I did understand what you said. But, like GreatWyrmGold already stated, the work is too big for the actual benefits. How could the came "match up" the dates? If a dwarf is born in certain date it is born that date, there is no way it could be recalculate to fit the other history. Same goes with deaths, marriages, being cursed. The problem even exists with all the items created during the play as those items may contain pictures of events or the item may be referred inside such picture. How could those be matched up?

Before anybody manages to state this, there is a way; while the fortresses can interact with each other they are considered to be in different worlds, in other words not in the same world map. But the problem is, as it has been stated in this thread numerous times even by me, that then both worlds, and thus both fortresses, must keep up with the events of the other world as well. While the dates can be different then the game would most probably just cause the computers to explode due the sheer amount of information...

Another method could be that the game just assumes that both fortresses use the different calendar, which makes it possible to have two or more different date for everything. But again the amount of information gets unnecessarily high. But let's assume for a second that it doesn't matter. Then, if something happens in fort A it would use the date of A in fort A and date B in fort B. If either one is away at the moment then, when the player logs back in, the game calculates how much time has passed in the other fort, where the event occurred, since the even took place, and calculate the correct date of in other fort's calendar.

[rcmgames]

Another method could be that the game just assumes that both fortresses use the different calendar, which makes it possible to have two or more different date for everything. But again the amount of information gets unnecessarily high. But let's assume for a second that it doesn't matter. Then, if something happens in fort A it would use the date of A in fort A and date B in fort B. If either one is away at the moment then, when the player logs back in, the game calculates how much time has passed in the other fort, where the event occurred, since the even took place, and calculate the correct date of in other fort's calendar.

This is what I was trying to explain, lol.

[Sprin]

NEVER GOING TO HAPPEN!!!

[NRN_R_Sumo1]

Why doesn't someone just program a game similar to DF and make it multiplayer?
Clearly if these threads keep popping up, there is a market for it.

[Starver]

Logically, and bluntly, those who are suggesting it should happen should try to make it happen.

I highly suspect that whatever comes out of such efforts will not be the same game as DF is, but in the attempt we may end up with a) some people more experienced with programming and game design (rarely a bad thing), and b) an interesting new game or three (ditto).



(Here, I admit to being cowardly.  I've got my own ideas, as previously posted all over the place in similar threads, but the fact that it wouldn't be DF stops me from making any strong insistence that "I have the solution".  And I've also got my own game-concepts, but I've actively tried to prevent myself from 'cloning' DF in any significant way, and even shifted the focus of 'projects' that pre-existed my knowledge of DF.)

[avatarandrij]

There is only one way to make normal multiplayer in DF.
1)Client - server system
2)No pausing.
3)slower time

But game is awful without pausing. It`s imposible to survive than.
I think that only way to solve this problem is graphic and gui to control Dwarf very quickly.

when player leave server it`s fortress become invisible and unreachable in 2 minutes, or smth like that, but time and history flowing doesn`t stop.

I believe,that DF become than very popular RTS game.

P.s. I`m not so god in English.

[Wellincolin]

There won't be multiplayer DF.

This has numberous reasons. DF's programming isn't the world's 8th wonder. He is a genius and probably ridiculously good at math, but he admitted that he is an average programmer. It has a lot of flaws that could be solved, but we all know too that Toady works by himself, not even his brother has access to the source. It is his life project and he said he plans to work on it for at least 10 more years, and the source will only be released upon the event of his death. So he won't be getting any help soon.
Afaik, Toady makes his living from DF, and that's the reason he won't release it. We all know that, should he at least tried to implement a kind of multiplayer, even the most vague resemblance of it (like highscores or even spectate only with a chat, like some rogulikes do, i.e. http://tiles.crawl.develz.org) it would raise, probably double the amount of donations. When Toady released Adventure Mode donations doubled, and they never went down again. DF became much more popular and has a kind of religious cult.


tl;dr he can't do multiplayer by himself without crucial losses, that's the reason he wont. And yes the community doesn't mean much, it's all up to ONE single person and he said he won't, so it's not a thread that is changing his mind, not the 100 that has been made and the 1000 to come.

[rcmgames]

We all know that, should he at least tried to implement a kind of multiplayer, even the most vague resemblance of it (like highscores or even spectate only with a chat, like some rogulikes do, i.e. http://tiles.crawl.develz.org) it would raise, probably double the amount of donations.

DFTerm! I just got into it and I LOVE it. And that's how the process goes; if the community wants something (a gui interface for managing dwarves->DT, a multiplayer set-up->DFTerm, 3d visualizer->stonesense, better music->soundsense, etc.) then the community is going to make it.

[Starver]

But DFTerm is a "simuplayer"[1] solution, at best, not an actual multiplayer one.

I'm happy if you're happy, but it's not going to give the multiplayer experience that other people appear to crave.  (Which, as already said, would seem to be doomed to be an unfulfilled craving for the foreseeable future.)



[1] I just made that word up.  Which is not to say that someone else didn't also, without me knowing, but I don't want to blame anyone else for its existence, at least in the context of what I tried to summarise by that term.  F.Y.I., I thought "Simultiplayer" sounded misleading and "Simultaniplayer" unwieldy, but I'm sure there's a better portmanteaux to be had.