Time warp mechanic

[mcwaffles2003]

@Master39

Your scenario works so long as the objective is always co-operative, but in the case of antagonistic play I believe it fails. I believe co-operative scenarios should be the priority of the game as that follows the ethos of the game, but I think a fair amount of players will want to experience KSP in a competitive manner as well.

[Guest]

46 minutes ago, mcwaffles2003 said:

@Master39

Your scenario works so long as the objective is always co-operative, but in the case of antagonistic play I believe it fails. I believe co-operative scenarios should be the priority of the game as that follows the ethos of the game, but I think a fair amount of players will want to experience KSP in a competitive manner as well.

In my scenario C is the competitive player, and with synced gameplay he has to wait for the whole play session without doing nothing.

It's not even that subtle that A and B could be NASA and ESA while C is China, more competitive than that there's only war and I don't want normal gameplay to be nerfed to low for a gameplay stile that's not supported by Devs and has traditionally never been since KSP original idea.

And, anyway, the game being able do manage unsynced gameplay doesn't do anything to people that want to play in sync just like the existence of time warp doesn't mean you can't play in real time.

 

[boolybooly]

Not sure if this has been mentioned, scanned the thread but not all details, nodes as bookmarks.

In KSP1  you can overshoot a maneuver node.

What KSP2 needs for SP and MP is for maneuver nodes to act as universal bookmarks and stop timewarp a few mins before a craft reaches it even if the player is piloting another craft.

In SP it means you never miss another maneuver, hooray!

In MP it means you set up your flight in real time with a maneuver node, press go for timewarp which is your vote. When everyone has pressed go the game warps to the nearest bookmark for all players at a speed matching the interval to the next node.

Player communication would be important to help things go smoothly. 

 

[Pthigrivi]

What if only players who are furthest in the future can dock? If you want to interact with a base or station someone has made you need to time warp ahead of the last person who’s docked. Each player leapfrogs the next and all collaborative acts are sequential. It would still require some player coordination as only one player could approach and dock at a time (unless two are simultaneously in the same 1x first position, for synchronized flying for instance) but once the dock was complete you could pass the baton to the next player to make their changes and so on. In the mean time everyone else can muck about in the past or even zoom ahead to the future, but to connect to anyone else’s craft you’d need to be furthest ahead and request docking precedence. 

Edited June 16, 2021 by Pthigrivi

[The Aziz]

It sounds like sync/request/invitation proposal. Someone built that station, someone owns it, it's up to them to decide who interacts with it. And of course whoever asks for docking, they do it on the most recent version of the station. If the station is at certain UT, you can't dock with at it before that time, you have to time warp to the point in time the station currently is in.

[Pthigrivi]

1 hour ago, The Aziz said:

It sounds like sync/request/invitation proposal. Someone built that station, someone owns it, it's up to them to decide who interacts with it. And of course whoever asks for docking, they do it on the most recent version of the station. If the station is at certain UT, you can't dock with at it before that time, you have to time warp to the point in time the station currently is in.

I don’t think its necessary or wise to leave it to players to keep track, but I agree on your last point. All that matters is that the changes all happen sequentially to prevent paradoxes. Say I have a station in Duna orbit and the last docking was on year 3 day 125. If you arrive in the system before that date you must time warp to year 3 day 126 to interact with it. 
 

I’d thought to prevent problems ALL changes must be sequential, but maybe you could get away with it on a per-vessel basis? Say you have a base on Duna that was last altered on year 3 day 125, but the station in orbit was last altered on year 3 day 225.   You can draw resources from the base on year 3 day 126, but you still have to circle in orbit until year 3 day 226 to offload them to the station. Does this get insanely difficult to predict? or is there a way from a player’s perspective that vessels with future interaction points appear red on the map and can’t be interacted with until the ready-date? These last-interaction dates could be measured by the last time they were an active vessel. Its a little more mind-bending but would remove need for baton passing. Players could play at the pace they liked, they’d just be inclined to timewarp ahead until most of the board was green if they wanted to get involved. If your friends had a save and were 30 years in and you joined at day zero the system would appear empty. As you time warped forward you would see their vessels all fly out and proceed to build out, but most of them would be marked red because their last-interaction date is in the future. As you got closer to their ‘present’ more and more of their vessels would become available for interaction because your timeframe would supersede the last time anyone interacted with them. 
 

This still leaves the problem of bases built occupying the same space at different times collapsing in on each other. In orbit you can avoid collisions by ignoring them, but on planetary surfaces you’d need all bases ghosted into the past and future to prevent them being built on top of each other. You could still build NEXT to someone’s future base, but you’d have to time-warp ahead to connect them. 

Edited June 16, 2021 by Pthigrivi

[razark]

Timewarp in multiplayer comes down to either paradox or waiting.

Either one player has to wait to do their thing, or you allow a paradox to exist.

 

Imagine A and B are going to Minmus, and C is going to Jool.

Either A and B go to Minmus, and C has to wait to go to Jool, or A and B go to Minmus, while C timewarps all to hell and back and paradoxes can occur.

 

My question is, if C wants to timewarp so far ahead and not interact with A and B in their timeline, then why the hell is C playing a multiplayer game with them?!?  A multiplayer game makes no sense if A and B are playing Monopoly, and C is playing Blackjack.  That's just multiple games with a chat feature.

[Incarnation of Chaos]

20 hours ago, Master39 said:

In my scenario C is the competitive player, and with synced gameplay he has to wait for the whole play session without doing nothing.

It's not even that subtle that A and B could be NASA and ESA while C is China, more competitive than that there's only war and I don't want normal gameplay to be nerfed to low for a gameplay stile that's not supported by Devs and has traditionally never been since KSP original idea.

And, anyway, the game being able do manage unsynced gameplay doesn't do anything to people that want to play in sync just like the existence of time warp doesn't mean you can't play in real time.

 

Synchronization is also expensive, in most 4X games the majority of the long wait between ending a turn and starting a new one is just waiting for all players to finish and their actions be synchronized at the end. After several hundred turns, after so many things are happening in the background, so many things are triggering, the sheer amount of state that has to be kept and synchronized contributes to 3-4 minute turn times....

[Guest]

1 hour ago, razark said:

Either A and B go to Minmus, and C has to wait to go to Jool, or A and B go to Minmus, while C timewarps all to hell and back and paradoxes can occur.

Which paradoxes exactly?

If A and B are going to Minmus on year 1 day 200, and C leaves his station in LKO to go to Jool on year 1 day 350, A and B must warp at least past that if they want to interact with that station. And then timewarp all the way up to whatever date C is after the Jool transfer if they want to interact in real time on something else. There are no possible paradoxes if you don't allow anyone to modify things in the past.

If nobody can warp backward or use any infrastructure before the last edit there are no paradoxes and no wait time you can't timewarp away, unless you're playing constantly half a century ahead of the others but at that point, as you said, why play multiplayer at all?

 

23 minutes ago, Incarnation of Chaos said:

Synchronization is also expensive, in most 4X games the majority of the long wait between ending a turn and starting a new one is just waiting for all players to finish and their actions be synchronized at the end. After several hundred turns, after so many things are happening in the background, so many things are triggering, the sheer amount of state that has to be kept and synchronized contributes to 3-4 minute turn times....

Yep, I'm starting to think that most people don't realize that, unless you're constantly playing the same craft or in the same physics bubble playing multiplayer in real time with synced timewarp in KSP means that you're playing a defacto turn based game.

[Pthigrivi]

@Master39 Well I think the point "paradoxes OR waiting" is correct. We're all agreeing I think that you can't allow paradoxes so it has to be waiting, but fortunately in Kerbal you can time-warp through your wait. I think we also agree all interactions have to be sequential and you should have to time-warp ahead to the last time it was docked with. What I can't figure out is if each vessel can be 'left' in its own time after each time a player interacts with it, or if there are problems created by having multiple craft with 'save' states in multiple times all over the Kerbol system (and beyond). Say one player docks with a station, drops off some resources, and leaves. Another player comes in from the near past to dock with the same station, but finding its save state in the future they decide to almost zero out relative motion and time-warp till the station is ready. But the moment they come out of time-warp they've actually slowly drifted inside the station, or inside the other players craft as it's leaving. Are these things collidable at this point? I think the station is, but the departing vessel isn't, because the player who left the station is already somewhere else in the future with it so it's ghosted?

And what about quicksaves? Say I accidentally plow into a station and knock off its solar arrays but then I pause the game and go make dinner. While Im eating another player comes along and doesn't notice the arrays are gone and docks with it. When I come back from dinner can I load the quicksave? Also what does my vessel look like to other players while Im paused?

Edited June 16, 2021 by Pthigrivi

[Bej Kerman]

On 6/15/2021 at 5:58 AM, Master39 said:

My proposal:

Each player can play on their own, no coordination, management or maintenance required from any of them.

If a player needs another player infrastructure they have to require and obtain permission from them (and to timewarp past said structure last edit) a 2 button interface.

Whenever two or more players have to directly interact in real time they just need to know that the ones behind have to timewarp ahead to reach the one furthest in the future. They also have a convenient "warp to player X" button to do that.

But isn't this what Dark Multiplayer has always done?

[Pthigrivi]

22 minutes ago, Bej Kerman said:

But isn't this what Dark Multiplayer has always done?

Word? How does it deal with quicksaves? I've heard its buggy but maybe that doesn't have to do with the fundamental logic puzzle?

Edited June 16, 2021 by Pthigrivi

[Bej Kerman]

Just now, Pthigrivi said:

22 minutes ago, Bej Kerman said:

But isn't this what Dark Multiplayer has always done?

Word? How does it deal with quicksaves?

I don't know, but DMP works flawlessly.

[Guest]

39 minutes ago, Pthigrivi said:

What I can't figure out is if each vessel can be 'left' in its own time after each time a player interacts with it, or if there are problems created by having multiple craft with 'save' states in multiple times all over the Kerbol system (and beyond).

You don't have to have multiple save states of anything, just a single line with the timestamp of the last event happening to a craft to have the date the player has to warp after.

 

39 minutes ago, Pthigrivi said:

Another player comes in from the near past to dock with the same station, but finding its save state in the future they decide to almost zero out relative motion and time-warp till the station is ready.

Probably the system works better if you get your permission and sync up to the station/base before deorbiting/rendezvousing.

In the grand scheme of explaining a player how to do a rendez-vous or a pinpoint landing telling him to sync up before doing it it's not that much additional information to remember.

 

39 minutes ago, Pthigrivi said:

Another player comes in from the near past to dock with the same station, but finding its save state in the future they decide to almost zero out relative motion and time-warp till the station is ready. But the moment they come out of time-warp they've actually slowly drifted inside the station, or inside the other players craft as it's leaving. Are these things collidable at this point? I think the station is, but the departing vessel isn't, because the player who left the station is already somewhere else in the future with it so it's ghosted?

If the other player is actually interacting at the same IRL timeframe as you you'd be already synced up and actively communicating, otherwise there's no reason to record every move of every player to replay them to other players coming after them later, it complicates everything beyond reason without any good gain beside some marginal increase in immersion.

Even then slowly translating is mostly due to game errors or gameplay mechanics laking the required precisions, there's no shame if the game cheats around those problems by teleporting the player 50 meters away (or even a km or 2).

 

39 minutes ago, Pthigrivi said:

And what about quicksaves? Say I accidentally plow into a station and knock off its solar arrays but then I pause the game and go make dinner. While Im eating another player comes along and doesn't notice the arrays are gone and docks with it. When I come back from dinner can I load the quicksave? Also what does my vessel look like to other players while Im paused?

There no such thing as a pause in multiplayer games, you put your vessel in a safe position (just like when you go back to the space center) and log off/go to the space center, permissions and server settings deal with what happens to your things when you're not online, like in any other game.

As for quick saves for them to work at least to some extent you have to have unsynced gameplay, an universal rule across any multiplayer game is that everyone hates to have half of their evening session rollback away due to someone not wanting to do an EVA to fix a couple of broken solar panels.

 

26 minutes ago, Bej Kerman said:

But isn't this what Dark Multiplayer has always done?

I never played any multiplayer mod, but that proves my point that there's no real "timewarp problem", there's some complexity involved in programming in a good multiplayer and choose exactly how to deal with some quirks and edge cases but nothing that a competent team and some good playtesting to iron out things and help choosing between the few options can't solve.

Edited June 16, 2021 by Master39

[Bej Kerman]

6 minutes ago, Master39 said:

I never played any multiplayer mod, but that proves my point that there's no real "timewarp problem", there's some complexity involved in programming in a good multiplayer and choose exactly how to deal with some quirks and edge cases but nothing that a competent team and some good playtesting to iron out things and help choosing between the few options can't solve.

If you ask me, there's no choosing. Having to co-operate with several others between massive timescales wouldn't be fun at all and the warp-to-X model has been proven to work in DMP.

[The Aziz]

I think I failed to explain how I see the time working in multiplayer in the sync proposal.

So basically there are few kinds of time. Server time, let's call it SUT, it's the time that matches the UT of the player who is the furthest in the future. For server, it's the present, there's nothing beyond because it didn't happen yet. The past can be changed then, as the players behind that SUT will be doing things, but it won't affect the present.

Then there's CUT, Client time, it's the one your game follows exactly as in singleplayer. It's debatable if quicksaving/loading could be available in multi, as they usually aren't. If they are in other games, they usually save the game state for all players, kinda impossible here.

And there's LUT, Local time, used for interactions between players and their vessels. More of a technical thing rather than something we use. To interact, player's CUTs have to match, (so, one has to warp to the CUT of other player's ship) otherwise interaction isn't possible, and temporary LUT is created. It's the one that keeps all players in local physics bubble or whatever in sync. They can warp, but only together. Once the players leave their joined space, or just decides to undock and warp away (as in, fire the engines for a sec to get a little boost to fly away, warping in close proximity to someone's craft with relative velocity >0 shouldn't be allowed for safety reasons, unless it's physwarp) LUT is released.

I think that won't allow paradoxes to happen, but hey, I could've not think of something important.

[razark]

8 hours ago, Master39 said:

Which paradoxes exactly?

Well, for example:

8 hours ago, Master39 said:

A and B must warp at least past that if they want to interact with that station.

You end up with things that exist in the universe that cannot be interacted with by players.  If A and B go to build a Munbase while C is off playing at Jool, but D timewarps 10,000 years ahead of them and lands a craft where A and B want to build their base, they will not be able to, because something that won't exist for one hundred centuries is blocking it.

Not to mention this leaves the question of docking to a docking port that is occupied in the future.  Of course, I can't dock to the station anyway, because it's now is in my future, so even though the station will be there, it isn't there, but it should be there because it was when my now was it's past.

 

But none of this answers the question of "why bother to play multiplayer, if it's just a big chat room that people can import other craft from other people's games"?

[Guest]

5 minutes ago, razark said:

You end up with things that exist in the universe that cannot be interacted with by players.  If A and B go to build a Munbase while C is off playing at Jool, but D timewarps 10,000 years ahead of them and lands a craft where A and B want to build their base, they will not be able to, because something that won't exist for one hundred centuries is blocking it.

1) I suspect that D won't last long, if not in that group of friends at least in that server.

2) it's not a paradox, you're just watching it from the wrong frame, IRL there's only one map and every player is playing together, the first that claim a spot has it.

3) I don't think lack of space will be a problem in Kerbal Space Program 2.

 

7 minutes ago, razark said:

Not to mention this leaves the question of docking to a docking port that is occupied in the future.  Of course, I can't dock to the station anyway, because it's now is in my future, so even though the station will be there, it isn't there, but it should be there because it was when my now was it's past.

If I dock to a station 100 hundred years in your game future and I find it exactly how I left it 100 years back it automatically means that nobody visited it in the last century, so you, playing 100 years back, can't interact with it before you catch up it's not a paradox, the paradox would be if you can actively change my past.

 

9 minutes ago, razark said:

But none of this answers the question of "why bother to play multiplayer, if it's just a big chat room that people can import other craft from other people's games"?

It's a shared campaign, some people want to play as Collins, Aldrind and Armstrong some other people wants to play like NASA, ESA and Roscosmos and without the ability to independently warp you're basically forced to play only the first scenario and the player doing Collins can log off and go to sleep 5 minutes into the play session.

Every system would break apart if a player just wants to warp 10000 years in the future, a minimum of coordination is always required, that's why I used my example with the Duna rover and sample return, because that's 3 players that are playing together in a realistic way and it becomes a chore for all of them if they have to wait their turn to play instead of being able to only sync up when needed.

 

Without unsynced play only a subset of players (most often one) can play at any given time and all the others have to wait for their turn with the controller in hand.

 

And again, whatever system we're talking about it's just a tool like time warp itself, you're not forced to use it and it doesn't replace the possibility of playing the game with every player always synced up to all the others.

[razark]

8 minutes ago, Master39 said:

... the first that claim a spot has it.

Except the "first" could be years after someone else.  To me, this makes no sense, and should not happen.

 

I think the only conclusion these repeated multiplayer/timewarp discussions are going to reach is that some players fundamentally disagree on what we expect or want out of multiplayer.  

[Guest]

19 minutes ago, razark said:

Except the "first" could be years after someone else.  To me, this makes no sense, and should not happen.

That example is the same exact thing of the station docking one, if someone, 100000 years in the future, finds a spot just as pristine and untouched as he left it 1000000 years back it means that nobody else has touched it during those years and since you can't change the past, if you're not up in sync with that player you can't modify his building spot.

You can sum up everything said up until now with "you can't change the past of any player".

 

We're talking about a game that will work best with 5-10 people per server at most and it's going to have several star systems worth of Space, I've seen (and managed) 500 players play in a 5km square Minecraft map without arguing for base building spots (well, cities in my case), I'm pretty sure that most people won't encounter that problem and the alternative of not dealing with unsynced timewarp at all wouldn't allow for servers bigger than 3-4 active players at most (I wouldn't even play multiplayer without unsynced warp).

[The Aziz]

1 hour ago, Master39 said:

That example is the same exact thing of the station docking one, if someone, 100000 years in the future, finds a spot just as pristine and untouched as he left it 1000000 years back it means that nobody else has touched it during those years and since you can't change the past, if you're not up in sync with that player you can't modify his building spot.

You can sum up everything said up until now with "you can't change the past of any player".

He's got a point though. Yes you can't change someone's past, but we're talking about two timelines here. Real and ingame. So let's switch back to less ridiculous time gaps and look at the example. 

It's year one in game, hour one IRL. Player A starts their normal game, while player B speedruns the game. At IRL hour 15, ingame year 6 player B lands on Duna and sets up a base. Player B did a lot of timewarping to get there, maybe some gravity assists or whatever, it took time. At IRL hour 18, ingame year 4 the slower (but somehow faster) player A lands on Duna in that spot. What does he find?

Will player A have to warp two years into the future to be able to land in a spot that looks empty in his current time?

I think the problem here lies with situation where the object you'd normally sync with still doesn't exist at the time (UT) you get where it's supposed to be.

The only solution to that I can think of is a message "Player B has already reserved the place on these coordinates".

Edited June 16, 2021 by The Aziz

[SOXBLOX]

I wonder if we're reading too much into this? Maybe it's not as complex as we think...

[Pthigrivi]

3 hours ago, Master39 said:

Every system would break apart if a player just wants to warp 10000 years in the future, a minimum of coordination is always required, that's why I used my example with the Duna rover and sample return, because that's 3 players that are playing together in a realistic way and it becomes a chore for all of them if they have to wait their turn to play instead of being able to only sync up when needed.

I think any official multiplayer has to be able to handle both. Whether its 10,000 years or a day doesn't really matter, you're going to have combinations of players in the future, in the past, and sharing physics bubbles at 1x. Im sure you will have people synched to each other from time to time, but if we don't want to force players to wait while other players do something most of the time players will be in their own slice of time interacting with their own creations and the creations of others. 
 

3 hours ago, Master39 said:

You don't have to have multiple save states of anything, just a single line with the timestamp of the last event happening to a craft to have the date the player has to warp after.

Exactly, not multiple save files, but multiple non-active vessels sharing the same world at different times. Say player 1 is at day 300 and player 2 is at day 200. If the last time player 1 interacted with a station was on day 250, player 2 should have to time warp to day 251, not day 300. Over time most of the stuff floating about will be in the state of that station, its last-altered state saved to the date of its last interaction. 
 

3 hours ago, Master39 said:

If the other player is actually interacting at the same IRL timeframe as you you'd be already synced up and actively communicating, otherwise there's no reason to record every move of every player to replay them to other players coming after them later, it complicates everything beyond reason without any good gain beside some marginal increase in immersion.

I think you have to record the position, vector, and orientation of every vessel all the time anyway. If Im in the past relative to other players I should see their vessels in map mode as they existed in my present. You're going to have at a given time lots of vessels in transit that aren't in a stable orbit. There are times when you may even want to dock to one, say, as it buzzed by on a gravity assist. The only way to understand that vessel's position and path would be for it to appear as it did at your present time. 
 

3 hours ago, Master39 said:

There no such thing as a pause in multiplayer games, you put your vessel in a safe position (just like when you go back to the space center) and log off/go to the space center, permissions and server settings deal with what happens to your things when you're not online, like in any other game.

As for quick saves for them to work at least to some extent you have to have unsynced gameplay, an universal rule across any multiplayer game is that everyone hates to have half of their evening session rollback away due to someone not wanting to do an EVA to fix a couple of broken solar panels.

Again because I suspect most players will be playing un-synched most of the time there's no particular reason why they couldn't pause. In fact I think you need to be able to. Same goes for quicksaves. It's often not as simple as replacing solar panels, someone could miss their landing and destroy half a base that took months to build. Im pretty good at landing precisely but every once in a while I biff it. If you spent hours building something and transporting it to Val it would be pretty frustrating to have to go all the way back because the lander tipped over. And any time that you're not synched this shouldn't be a problem. In fact even if you are synched a revert would just have your vessel disappear from the other players view. 

Edited June 16, 2021 by Pthigrivi

[Guest]

9 minutes ago, The Aziz said:

It's year one in game, hour one IRL. Player A starts their normal game, while player B speedruns the game. At IRL hour 15, ingame year 6 player B lands on Duna and sets up a base. Player B did a lot of timewarping to get there, maybe some gravity assists or whatever, it took time. At IRL hour 18, ingame year 4 the slower (but somehow faster) player A lands on Duna in that spot. What does he find?

Will player A have to warp two years into the future to be able to land in a spot that looks empty in his current time?

Think about it, you have to be able to see future crafts, bases and stations, otherwise you wouldn't be able to catch up and interact with them.

At that point is a matter of why you landed in the same spot.

You see it, at least on the map view, you know you can't interact with it if you don't sync before deorbiting, and you can deter someone driving or flying there with visual warnings.

The only remaining reason to do it anyway is if you're intentionally trying to break the system but the only way to have an unbreakable system is to not have that system at all.

 

And yes there's still the possibility of having someone flying in and see the warning just in time to reach the date of the last edit and having the Duna version of Isengard spawn right in your face, but at that point you're likely the unluckiest person alive.

[shdwlrd]

20 minutes ago, SOXBLOX said:

I wonder if we're reading too much into this? Maybe it's not as complex as we think...

You know how this forum can be. If not explained, people will throw out ideas and try to justify them. If explained, people will complain that it's not how they invisioned it.