KSP 2 Multiplayer Discussion Thread

[JoeSchmuckatelli]

54 minutes ago, Pthigrivi said:

This is true if players exist on the same timeline. Thats not what's happening in the bubble-universe MP models like the one Vl3d is describing. In those models each player has their own timeline which splices into others whenever they interact with a new SOI or another player's vessel. Player A is working in and around Kerbin and Player B flies out to Jool and back. When Player B arrives back at Kerbin they synch in real-time. That means a few in-game days or hours have elapsed for Player A and 6+ in-game years have elapsed for Player B. Neither "Start time" nor "Conditions met" are fixed or comparable points in time for all players. In my example above when Team 1's mothership arrives 300 days have elapsed for one player, but zero time has elapsed for the other 3 because each of those team members exists in their own distinct timelines. Because you don't have a single, coherent reality you end up not measuring victory the way a space-race works--an actual race against a shared clock--but based entirely on how a team happens to have allocated jobs. Teams in which 3 players do nothing but design work in the VAB and one player does all the flying will always beat teams that fly and combine multiple vessels because 0 time elapses for 3/4 of the team. 

Won't one player's entire universe have to change when they splice? 

For the Jool player... All the planets and moons would be 6+ years (+/-) evolved compared to the KSOI player.  When they splice time... Won't the positions of everything have to be complementary? 

This might not be a problem for two players who each have only one mission running at a time (and don't get me started on what this might mean for science that gathers over time) - but what if each player has a 'side' mission going? 

Edited November 30, 2022 by JoeSchmuckatelli

[Pthigrivi]

11 minutes ago, JoeSchmuckatelli said:

When they splice time... Won't the positions of everything have to be complementary? 

Well this is kind of what I've been saying--they don't, but they should. In the bubble MP versions that have been discussed you keep your own timeline and pull other players's vessels into it temporarily so you can rendezvous, and then when you dock your vessel is instantly transported to wherever the other player sees it. This saves you the work of actually making up the difference in time by fast-forwarding your whole universe to align with theirs. You also don't have to worry about paradoxes because interactions are in real-time. But it does create a host of not-so-obvious down sides. 

[t_v]

41 minutes ago, Pthigrivi said:

and then when you dock your vessel is instantly transported to wherever the other player sees it.

not exactly, the idea is that you warp forwards, but not all the way to the other player's time, only to a point which is comparable to their time within that specific frame of reference. Instead of projecting forwards, you are projecting backwards and finding a suitable time where the backwards projection lines up exactly with the current state. If you end up warping forwards to the other player's time, then great! It functions just like Leapfrog. But if you dock to something in the past, it doesn't necessarily warp you all the way to the present, just to the earliest point that avoids spatial discrepancies. 

As for racing, I'm not sure there will even be official racing, but you can measure total in-game time and find the largest difference from start to finish. It doesn't matter if players spent their time in the VAB if the mission still took five months to complete the transfer. 

Oh, and I saw something I wanted to respond to, but I didn't want to interrupt the racing discussion. @Pthigrivi, you made a point that you don't know whether a ship is at the periapsis or apoapsis of its orbit in the cyclical system. I wanted to say that this is also the case for Leapfrog. You are in the past, so you can't tell whether a ship is at its apoapsis or periapsis, or even what SOI it is orbiting in. However, both models give you some consistent behavior so that you can rendezvous to that ship, and then the main advantage of Leapfrog is that if you can dock, there is no time warp required to synchronize things. Both systems hide the true position of the craft, but one compensates by disallowing interaction in situations where that matters and the other compensates by forcing a short warp in situations where that matters. 

1 hour ago, JoeSchmuckatelli said:

For the Jool player... All the planets and moons would be 6+ years (+/-) evolved compared to the KSOI player.  When they splice time... Won't the positions of everything have to be complementary? 

The idea is that if you are docking to a station orbiting Jool, you care about synchronizing whether it is on the day or night side, whether it is at Apopasis or Periapsis, but not much else. So if the moons are in different positions, specifically for docking to that station, that wouldn't matter. If you wanted to dock to a ship that is transferring to or between moons, instead of warping 6+ years, you would warp a few days or weeks until the exact same transfer window appears. There are innacuracies in the transfer windows that I still need to think about, but that is the concept. 

[Vl3d]

2 hours ago, Pthigrivi said:

Player A is working in and around Kerbin and Player B flies out to Jool and back. When Player B arrives back at Kerbin they synch in real-time. That means a few in-game days or hours have elapsed for Player A and 6+ in-game years have elapsed for Player B.

These are things you don't have to worry about if you just hide the universal time like I proposed.

[darthgently]

3 hours ago, Pthigrivi said:

This is true if players exist on the same timeline. Thats not what's happening in the bubble-universe MP models like the one Vl3d is describing. In those models each player has their own timeline which splices into others whenever they interact with a new SOI or another player's vessel. Player A is working in and around Kerbin and Player B flies out to Jool and back. When Player B arrives back at Kerbin they synch in real-time. That means a few in-game days or hours have elapsed for Player A and 6+ in-game years have elapsed for Player B. Neither "Start time" nor "Conditions met" are fixed or comparable points in time for all players. In my example above when Team 1's mothership arrives 300 days have elapsed for one player, but zero time has elapsed for the other 3 because each of those team members exists in their own distinct timelines. Because you don't have a single, coherent reality you end up not measuring victory the way a space-race works--an actual race against a shared clock--but based entirely on how a team happens to have allocated jobs. Teams in which 3 players do nothing but design work in the VAB and one player does all the flying will always beat teams that fly and combine multiple vessels because 0 time elapses for 3/4 of the team. 

Idk.  It still seems simple to me.  You just need only deal with the span of game time played, regardless of absolute game time, and ignore time shifts due from syncing.  A simple mod could keep track probably

[Pthigrivi]

1 hour ago, t_v said:

not exactly, the idea is that you warp forwards, but not all the way to the other player's time, only to a point which is comparable to their time within that specific frame of reference. Instead of projecting forwards, you are projecting backwards and finding a suitable time where the backwards projection lines up exactly with the current state. If you end up warping forwards to the other player's time, then great! It functions just like Leapfrog. But if you dock to something in the past, it doesn't necessarily warp you all the way to the present, just to the earliest point that avoids spatial discrepancies. 

As for racing, I'm not sure there will even be official racing, but you can measure total in-game time and find the largest difference from start to finish. It doesn't matter if players spent their time in the VAB if the mission still took five months to complete the transfer. 

Thanks for the clarification. So this would be measuring victory by the shortest in-game elapsed time for the player with the longest elapsed time on each team, which sounds good, but is also easily gameable. A team could for instance transfer control of the vessel from player to player as it transferred breaking it into small pieces so the elapsed time for the longest player was only 1/4 the total transfer time. And all of this is much worse if this is a real progression-based space race where you're not just racing through a fast but inefficient transfer in sandbox but collectively teching up through multiple missions before reaching the ultimate goal. In that case a team would certainly lose by having 3 players doing design work while one flew all the missions because all of the elapsed time is heaped on one player. Each method of determining the victor selects not "who won the space race" but for a particular dynamic of job allotment within teams. Once again, the issue is that players aren't sharing the same timeline, so instead of measuring what happened in a 'real' world you have all these disconnected and foreshortened realities that are difficult to compare in an apples to apples way.  
 

31 minutes ago, darthgently said:

Idk.  It still seems simple to me.  You just need only deal with the span of game time played, regardless of absolute game time, and ignore time shifts due from syncing.  A simple mod could keep track probably

The shifts aren't due to synching, they're due to players living in their own disconnected universes. For players who are just doing design work the span of elapsed in-game time is zero. This doesn't happen if players share a timeline. In that case the team who arrives on Duna on the earliest in-game calendar date is the team that wins no matter how they got there. 

Edited November 30, 2022 by Pthigrivi

[Kerbart]

4 minutes ago, Pthigrivi said:

... So this would be measuring victory by the shortest in-game elapsed time for the player with the longest elapsed time on each team, which sounds good, but is also easily gameable. ...

This sounds way too complicated for my little old tired brain.

Why don't we measure the distance traveled by a vessel? Let's call it a "vessel run." No wait, since it's ksp, let's call it a Kessel Run. And since we're into Science™ we measure distance in parsecs, not lightyears (like amateurs do). As we're going for efficiency, the shortest distance matters. So the objective becomes:

Who can complete the Kessel Run in the least amount of parsecs?

(Sorry, couldn't resist...)

 

[darthgently]

17 minutes ago, Pthigrivi said:

Thanks for the clarification. So this would be measuring victory by the shortest in-game elapsed time for the player with the longest elapsed time on each team, which sounds good, but is also easily gameable. A team could for instance transfer control of the vessel from player to player as it transferred breaking it into small pieces so the elapsed time for the longest player was only 1/4 the total transfer time. And all of this is much worse if this is a real progression-based space race where you're not just racing through a fast but inefficient transfer in sandbox but collectively teching up through multiple missions before reaching the ultimate goal. In that case a team would certainly lose by having 3 players doing design work while one flew all the missions because all of the elapsed time is heaped on one player. Each method of determining the victor selects not "who won the space race" but for a particular dynamic of job allotment within teams. Once again, the issue is that players aren't sharing the same timeline, so instead of measuring what happened in a 'real' world you have all these disconnected and foreshortened realities that are difficult to compare in an apples to apples way.  
 

The shifts aren't due to synching, they're due to players living in their own disconnected universes. For players who are just doing design work the span of elapsed in-game time is zero. This doesn't happen if players share a timeline. In that case the team who arrives on Duna on the earliest in-game calendar date is the team that wins no matter how they got there. 

But game time span is game time span, regardless of bubbles.  If you are talking about teams collaborating on one mission and one craft, then that is an entirely different thing.  In that case I can't see how individual scores would even matter.   I would assume design and build time in the editor  wouldn't be part of most competition scoring just as it isn't for auto racing

What the heck am I missing?

 

[t_v]

18 minutes ago, Pthigrivi said:

Thanks for the clarification. So this would be measuring victory by the shortest in-game elapsed time for the player with the longest elapsed time on each team, which sounds good, but is also easily gameable. A team could for instance transfer control of the vessel from player to player as it transferred breaking it into small pieces so the elapsed time for the longest player was only 1/4 the total transfer time. And all of this is much worse if this is a real progression-based space race where you're not just racing through a fast but inefficient transfer in sandbox but collectively teching up through multiple missions before reaching the ultimate goal. In that case a team would certainly lose by having 3 players doing design work while one flew all the missions because all of the elapsed time is heaped on one player. Each method of determining the victor selects not "who won the space race" but for a particular dynamic of job allotment within teams. Once again, the issue is that players aren't sharing the same timeline, so instead of measuring what happened in a 'real' world you have all these disconnected and foreshortened realities that are difficult to compare in an apples to apples way.  

This is why I didn't really want to participate in the racing discussion, as I don't really care for racing against other server members, even in competitive scenarios. Either I am further progressed or the other team is, and the amount of in-game time that took is not what is important to me. It seems that if players try hard enough to game the system, there will be loopholes. Maybe not the one that you pointed out, as you can easily add logic that adds up the elapsed times when overlap is ruled out (as in, several players performing orbital assembly "simultaneously" doesn't count for extra time, but several players completing one transfer with one ship does), but there is sure to be some way to exploit the system for determined individuals. Again, I don't really care for space racing, but I think that most players wouldn't try to exploit the system so harshly against their friends, and in those situations where you truly hate your server mates, moderation tools are there, and of course you can always decide as a group who really won the race. 

[Pthigrivi]

3 hours ago, darthgently said:

But game time span is game time span, regardless of bubbles.  If you are talking about teams collaborating on one mission and one craft, then that is an entirely different thing.  In that case I can't see how individual scores would even matter.   I would assume design and build time in the editor  wouldn't be part of most competition scoring just as it isn't for auto racing

What the heck am I missing?

 

Im talking about teams collaborating on any number of modules, deliveries, group motherships, separate missions that combine at the destination, colonies and support mining bases, etc--anything that goes into the collective effort of putting a big mission to Duna or Jool or Debdeb together. In auto racing everyone exists in the same world, and the same amount of time goes by for all players. Thats a very important part of what makes races work. The last few pages are just parsing out that conducting a team vs team multiplayer space race is very easy to do if you have a shared timeline and much more difficult if you don't. 
 

3 hours ago, t_v said:

Maybe not the one that you pointed out, as you can easily add logic that adds up the elapsed times when overlap is ruled out (as in, several players performing orbital assembly "simultaneously" doesn't count for extra time, but several players completing one transfer with one ship does), but there is sure to be some way to exploit the system for determined individuals. Again, I don't really care for space racing, but I think that most players wouldn't try to exploit the system so harshly against their friends, and in those situations where you truly hate your server mates, moderation tools are there, and of course you can always decide as a group who really won the race. 

I don't even think malicious exploits are the worst problem. Accidental exploits would be much more common, as players fail to realize that this or that way of breaking up missions between different players halved or doubled the assessed collective score. If they're all living in different timelines they may not understand what "simultaneously" even means.

And again, I don't think this is an absolute dealbreaker for this method of putting multiplayer together and the advantages still might outweigh some of the these kinds of disadvantages. Its just one of the cons. 

Edit: And to be more fair let me point out one of the stranger cons for leapfrog: pooled science and progression.  If Player A is in year 1 and Player B is in year 2, do they have access to the same parts? Does Player A have to time-warp to the point where Player B unlocked parts in the past? If Player A generates a bunch of science exploring Gilly in year one does that translate into the future and instantly unlock a bunch of things for Player B in the future? This could get weird especially if science is one of those things thats generated in labs over time...
 

Edited December 1, 2022 by Pthigrivi

[SciMan]

You know, I see all this discussion and all I see is "no two people want the same thing from multiplayer".

That's fine, but we're not making a game for each individual person. No possible amount of "options" of any kind could account for all the different ways people want multiplayer to work.

All that that tells me is that there's gonna be a lot of upset or just dissatisfied people no matter what way they implement multiplayer (especially if it's implemented in a way that's "none of the above" to any of the ideas seen on any page in this whole thread, or if they just throw their hands up again and say "Nope, not gonna happen" which since the game's going into EA and not full release could still entirely happen, as much as that would be "breaking" a "promise" that they "made" (quotes used to indicate that you shouldn't treat any hints of features in an upcoming game as "promises", even if (and especially if) they say "we promise").

I don't have a dog in this fight, I don't think I'll be playing that much multiplayer in any case. As I've stated before, all I see out of it is broken bases and stations drained of resources when I need them for whatever improbably large creation I want to launch next.

[Ericwi]

On 12/2/2022 at 1:39 PM, SciMan said:

You know, I see all this discussion and all I see is "no two people want the same thing from multiplayer".

That's fine, but we're not making a game for each individual person. No possible amount of "options" of any kind could account for all the different ways people want multiplayer to work.

All that that tells me is that there's gonna be a lot of upset or just dissatisfied people no matter what way they implement multiplayer (especially if it's implemented in a way that's "none of the above" to any of the ideas seen on any page in this whole thread, or if they just throw their hands up again and say "Nope, not gonna happen" which since the game's going into EA and not full release could still entirely happen, as much as that would be "breaking" a "promise" that they "made" (quotes used to indicate that you shouldn't treat any hints of features in an upcoming game as "promises", even if (and especially if) they say "we promise").

I don't have a dog in this fight, I don't think I'll be playing that much multiplayer in any case. As I've stated before, all I see out of it is broken bases and stations drained of resources when I need them for whatever improbably large creation I want to launch next.

I think the main issue is how to deal with time in multi player. 

[Vl3d]

This video has a fun multiplayer feel.

 

[JoeSchmuckatelli]

31 minutes ago, Vl3d said:

This video has a fun multiplayer feel.

 

That was fun - and likely to be the only way I'd enjoy KSP2 MP; tooling around with people in wacky vehicles. 

But it also showcases the 'ground has no friction' thing I hope they've addressed. 

[SciMan]

... It's also KSP 1 not KSP 2.

[Scrubster]

I was chatting with my friends about the new multiplayer for KSP2 and someone mentioned a space race, and that immediately sparked some idea's I think people would love to see in the game. Alongside having a standard multiplayer experience, whatever that may be for KSP 2 such as a multi career mode, I was thinking of a mode called space race, two teams of players race to be the first to space, or to go to a planet, or do certain tasks, and not talking short term I'm talking make it to one of the harder planets like Eve and making it through the tech tree, something that would be a multi session game mode, and ofcourse you could have your short term modes for space race aswell, but the main idea is for players to compete. I'd feel like this would spice up the already creative nature of the game, but I wanna hear from you guys and maybe the dev's.

[Gargamel]

Overlapping threads have been merged

[Drakenred65]

thank you! I thought I was going nuts when looking up a post but it was here all along lol!

 

[Lettuce]

6 hours ago, Scrubster said:

I was chatting with my friends about the new multiplayer for KSP2 and someone mentioned a space race, and that immediately sparked some idea's I think people would love to see in the game. Alongside having a standard multiplayer experience, whatever that may be for KSP 2 such as a multi career mode, I was thinking of a mode called space race, two teams of players race to be the first to space, or to go to a planet, or do certain tasks, and not talking short term I'm talking make it to one of the harder planets like Eve and making it through the tech tree, something that would be a multi session game mode, and ofcourse you could have your short term modes for space race aswell, but the main idea is for players to compete. I'd feel like this would spice up the already creative nature of the game, but I wanna hear from you guys and maybe the dev's.

If I'm not mistaken they confirmed this with agencies?  You'll be able to work in the same agency with your friends or have separate agencies and compete with each other.

[tstein]

On 12/12/2022 at 10:03 AM, Vl3d said:

This video has a fun multiplayer feel.

 

It seems what you want is Space Engineers but with psycotropics and better engine performance.

[Missingno200]

13 hours ago, tstein said:

It seems what you want is Space Engineers but with psycotropics and better engine performance.

I may be wrong but I'm fairly certain that bike's got some Attack Bike vibes to it so... tack on Command and Conquer I guess.

[adriantheflash]

I’m so happy for this multiplayer mechanic

I remember needing the darkmultiplayer mod and it was so laggy

[Gargamel]

Overlapping threads have been merged.   

[rahulvattya]

I guess a server thing might be created. Maybe there will be a space-race mode where you can play against someone else and try to beat them to the Moon or another moon or planet.

[Vl3d]

I updated the main thread with the new ideas related to how multiplayer would work while allowing time warp in space. Basically the ideas are simple and the servers can handle it automatically without bothering the player for input:

• real-time multiplayer gameplay on celestial bodies or while flying close to the ground (in the atmosphere)
• recorded actions / events for missions in space placed on a common timeline - is the basis for implementing the delivery routes system
• small real-time bubbles around space stations or when doing rendezvous with syncing done when in proximity

How would space races work in multiplayer?

If there's only one timeline common to all players then events recorded during missions get placed on it at the appropriate future time coordinate. So if Player A that's playing right now (real-life time) lands on the Mun, he would have that event recorded and placed on the timeline. If Player B that's playing some days later (real-life time) is faster (relative to in-game time), then that Player B event recording would be placed before the Player A recording on the common timeline. All other players would be notified of milestones when the in-game time hits a recorded event. So the one that wins the "land on the Mun" space race is the one that created the earliest recording of the event (real life time does not really matter, but there should be rules so someone does not lag behind for a year in real life just to win the race).

Edited February 5, 2023 by Vl3d