KSP 2 Multiplayer Discussion Thread

[Vl3d]

12 minutes ago, BowlerHatGuy2 said:

Hi I’m new to this thread, could someone explain how this theoretical multiplayer works or send me to a document?

 

10 minutes ago, Bej Kerman said:

30 people and a Dark Multiplayer session

30 players is not big multiplayer, I'm taking about at least hundreds of people planet-side and thousands of people playing in the same universe.

Edited April 9, 2022 by Vl3d

[Bej Kerman]

3 minutes ago, Vl3d said:

11 minutes ago, Bej Kerman said:

30 people and a Dark Multiplayer session

30 players is not big multiplayer, I'm taking about at least hundreds of people planet-side and thousands of people playing in the same universe.

My point stands. You're going to only have like 5 or 10 people playing if multiplayer has the catch of taking hours for simple tasks due to the absence of timewarp.

[Guest]

42 minutes ago, Vl3d said:

This is describing a single-kerbal game, right? Your game would be limited to where your character is physically, right? No managing colonies, no switching vessels, no KSP... All this because you refuse to let the server control the simulation.

Nope, with that you can playe the full SP game without changes, other than the need for a permission system and moderation if you want the server to grow past a few friends playing together, just like any other game out there.

Most cooperation in KSP wouldn't be syncronous anyway, sharing a fuel station or a colony, using the same mining outpost to gather a resource, with multiple supply runs going to different colonies, all of that doesn't need to be synced in real time, only that the player using a craft timewarps to after that last craft was loaded.

Even 2 player sharing the same mothership leaving a Mun orbital shipyard for a Jool mission could want different and independent timewarp levels when they reach Jool's orbit and one is going to explore Laythe by seaplane and the other is building a mining colony on Pol.

16 minutes ago, BowlerHatGuy2 said:

Hi I’m new to this thread, could someone explain how this theoretical multiplayer works or send me to a document?

There's no official informations on the official multiplayer, all you can read here or in any linked post is pure speculation.

Edited April 9, 2022 by Master39

[Pthigrivi]

40 minutes ago, Vl3d said:

It's somewhat understandable that players with synapses defined by years of playing thousands of hours of KSP1 would be resistant to and suspicious of change.

I feel like some people just refuse to let go of the God-like superpower of manually controlling time and solar system configuration in exchange of a cool multiplayer game. And this is why they can't change paradigm. It's normal.

This is describing a single-kerbal game, right? Your game would be limited to where your character is physically, right? No managing colonies, no switching vessels, no KSP... All this because you refuse to let the server control the simulation.

Why can't you just switch colonies / crafts and go back and forth in server controlled state / configuration, not objective time?

I'll always repeat that in orbit time is relative, except for life support. And that can be fixed by setting an individual per-player inner game time which is used to calculate resource usage and stocks. It does not impact multiplayer because other players can't look at your colony/craft remaining resources.

No, its that you still need a consistent reality where planets and moons have relative positions and movements and vessels and colonies have predictable resource values. Its easy to maintain this with several players in a shared universe and there’s really no reason to have more than that. 

[SkyFall2489]

28 minutes ago, BowlerHatGuy2 said:

Hi I’m new to this thread, could someone explain how this theoretical multiplayer works or send me to a document?

It's a mess, just look at the last 30 or so pages...

[BowlerHatGuy3]

Just now, SkyFall2489 said:

It's a mess, just look at the last 30 or so pages...

Yeah, I can’t find any post that has someone just sit down and layout all of the suggestions.

Most of the posts boils down to “When turning on time bubbles you will meet of with other players synchronized craft which will activate time warp which will cause you to pass through other players and in turn shows why real life time warp is not viable for underwater travel.”

[Bej Kerman]

16 minutes ago, BowlerHatGuy2 said:

Yeah, I can’t find any post that has someone just sit down and layout all of the suggestions.

The sore thumb is killing timewarp, and the consequence of this is making a game whose travel times are even worse than Elite Dangerous.

[t_v]

14 hours ago, BowlerHatGuy2 said:

Yeah, I can’t find any post that has someone just sit down and layout all of the suggestions.

Most of the posts boils down to “When turning on time bubbles you will meet of with other players synchronized craft which will activate time warp which will cause you to pass through other players and in turn shows why real life time warp is not viable for underwater travel.”

Here are the 3 solutions I have seen proposed, with other solutions being variations on these three. 
 

1. Each player can time warp at will, and all ships time warp when they do so. This is similar to what you would expect with a single player campaign with multiple flights in progress, or if you have played KSP 1 multiplayer mods, it is that. Basically, players can go ahead in time, and other players can warp up to that time to prevent breaking causality. This generally works because all craft warp when a player warps, so you can’t get any funkiness with orbits. 

Pros: no breaking either causality or orbital mechanics

Cons: You cannot interact with other people’s ships by default, you have to be in the same time  

2. This one I proposed, so I apologize for any bias. This is like the first solution, except not all ships warp when one player warps and there is no synchronization step, which is required to interact with other players in the fist solution. When a player warps, all their ships warp (like in single player) but other ships do not. There is one extra condition when a ship is in a stable orbit, where technically the time elapsed doesn’t matter because the orbit will repeat infinitely, so those ships warp whenever anyone warps . This is to fix a problem with rendezvous that allowed people to change their position by simply warping ahead to a point while another ship does not. 
 

Pros: Interaction is always allowed

Cons: Causality can be broken specifically with a torch ship during transfers. (Edit: actually a lot of transfer types cause causality to go out the window)
 

3. The newest solution. I don’t find waiting hours fun, so I apologize for the bias. In this solution, there is a server defined time that is always at 1x time warp around planets, moons, and big stations. There is no warp normally. When you create a maneuver or series of maneuvers which leave an SOI, you are able to time warp and leave the central server time. According to the person who proposed this, all maneuvers should be completed automatically with no manual control, but I’m ignoring that as a variation. Once you recircularize in an SOI, your ship warps forwards or backwards to the standard server time. The point of this is that the locations of all celestial bodies are the same for everyone (but you can change them when on a journey by setting the start time at any point). 
 

Pros: Auto-synchronization of time, and technically preserves causality in-game
 

Cons: the aforementioned no warp within SOI, causality is not preserved in real life (later events happen before earlier events and can impact earlier events) and a host of other things from the specific implementation. 

Edited April 10, 2022 by t_v

[Pthigrivi]

4 hours ago, BowlerHatGuy2 said:

Hi I’m new to this thread, could someone explain how this theoretical multiplayer works or send me to a document?

I would only amend t_v's examples by pointing out that in option 1 you don't actually have to be in or ahead of other players timelines, only ahead of the last time a given vessel or base was interacted with. So for instance Player A could fly to Duna, set up a base, then go fly a separate mission to Dres. Player B (in Player A's past) could then build a support lander and warp to Duna and resupply the base Player A set up so long as they arrive after Player A's last interaction with it. Player B could then warp ahead and put a station above Laythe, and Player A could warp ahead of that and dock with it. If they happened to have two vessels in the same relative space they could also synch to fly planes or race rovers together. 

Edited April 10, 2022 by Pthigrivi

[BowlerHatGuy3]

3 hours ago, t_v said:

Here are the 3 solutions I have seen proposed, with other solutions being variations on these three. 
 

1. Each player can time warp at will, and all ships time warp when they do so. This is similar to what you would expect with a single player campaign with multiple flights in progress, or if you have played KSP 1 multiplayer mods, it is that. Basically, players can go ahead in time, and other players can warp up to that time to prevent breaking causality. This generally works because all craft warp when a player warps, so you can’t get any funkiness with orbits. 

Pros: no breaking either causality or orbital mechanics

Cons: You cannot interact with other people’s ships by default, you have to be in the same time  

2. This one I proposed, so I apologize for any bias. This is like the first solution, except not all ships warp when one player warps and there is no synchronization step, which is required to interact with other players in the fist solution. When a player warps, all their ships warp (like in single player) but other ships do not. There is one extra condition when a ship is in a stable orbit, where technically the time elapsed doesn’t matter because the orbit will repeat infinitely, so those ships are allowed to warp. This is to fix a problem with rendezvous that allowed people to change their position by simply warping ahead to a point while another ship does not. 
 

Pros: Interaction is always allowed

Cons: Causality can be broken specifically with a torch ship during transfers. 
 

3. The newest solution. I don’t find waiting hours fun, so I apologize for the bias. In this solution, there is a server defined time that is always at 1x time warp around planets, moons, and big stations. There is no warp normally. When you create a maneuver or series of maneuvers which leave an SOI, you are able to time warp and leave the central server time. According to the person who proposed this, all maneuvers should be completed automatically with no manual control, but I’m ignoring that as a variation. Once you recircularize in an SOI, your ship warps forwards or backwards to the standard server time. The point of this is that the locations of all celestial bodies are the same for everyone (but you can change them when on a journey by setting the start time at any point). 
 

Pros: Auto-synchronization of time, and technically preserves causality in-game
 

Cons: the aforementioned no warp within SOI, causality is not preserved in real life (later events happen before earlier events and can impact earlier events) and a host of other things from the specific implementation. 

 

55 minutes ago, Pthigrivi said:

I would only amend t_v's examples by pointing out that in option 1 you don't actually have to be in or ahead of other players timelines, only ahead of the last time a given vessel or base was interacted with. So for instance Player A could fly to Duna, set up a base, then go fly a separate mission to Dres. Player B (in Player A's past) could then build a support lander and warp to Duna and resupply the base Player A set up so long as they arrive after Player A's last interaction with it. Player B could then warp ahead and put a station above Laythe, and Player A could warp ahead of that and dock with it. If they happened to have two vessels in the same relative space they could also synch to fly planes or race rovers together. 

Thanks guys.

[darthgently]

5 hours ago, Vl3d said:

30 players is not big multiplayer, I'm taking about at least hundreds of people planet-side and thousands of people playing in the same universe.

I don't think KSP's legacy and flavor lends itself well to MMO (massively multiuser/player yada yada) but the 30 something player dark multiplayer flavor fits KSP a bit better.  Which is not to say I think your ideas on the subject are bad, just that I don't think you will see it except maybe in a mod that KSP2 doesn't really play well with because of the style of play KSP2 will be optimized for.  But who knows?  I don't

Edited April 10, 2022 by darthgently

[Vl3d]

6 hours ago, t_v said:

there is a server defined time that is always at 1x time warp around planets

That is not what I said.  There is no central / universal time. The server controls the configuration of each space-time bubble.

6 hours ago, t_v said:

Cons: the aforementioned no warp within SOI, causality is not preserved in real life

Causality is preserved. Please read the Q&A.

Please do not reinterpret or paraphrase my solution with variation, you can just easily link to it:

 

Edited April 10, 2022 by Vl3d

[t_v]

6 hours ago, Vl3d said:

That is not what I said.  There is no central / universal time. The server controls the configuration of each space-time bubble.

And that is exactly what I said. The server controls the configuration of each bubble, creating a central time. These times aren’t necessarily synchronous. 
 

6 hours ago, Vl3d said:

Causality is preserved. Please read the Q&A.

Did you read my post? Reading other peoples’ posts is a big deal for you, so please respond accordingly. Here is what I put as a Pro:

13 hours ago, t_v said:

technically preserves causality in-game

This means that within the game, events that happen ahead of time cannot affect events happening after. Causality is not broken, right? 
 

Well, actually not really. So, what do I mean it is broken “in real life”? Let’s take an example from two different solutions.

In solution 1, Player A is in the future, having done a bunch of stuff. Player B is in the past. Player B cannot interact with the stuff that Player A has interacted with in the future (thanks for the clarification @Pthigrivi) but player B can also do their own thing. Let’s say that in the future, player A has set up a station on Gilly. Then, in the past, player B drives a rover through where that station eventually will be. (I know, rovers on Gilly) Here, future events do not affect past events in-game or in real life. 
 

Ok, so now with auto-synchronization. Player A has this station set up on Gilly. Player B enters Gilly SOI and circularizes and is warped up to the server time for Gilly. Essentially, their rover has been hanging in orbit for a few years while the station was being set up. No problems with causality there, because the rover is now in the same time as the station. A short 1-hour descent later, the rover touches down and Player B begins their preplanned route to visit all the biomes. But because player A has planted a base there, they have to go around it. Events that have happened in the future by players who have gone ahead and used more time affect the actions of player who, for all intents and purposes, have not used up as much time and are “in the past”. This is what I mean by breaking causality in real life. 
 

And of course, my personal remark is that causality is overrated and I would prefer to be able to interact with other players right away (which can still be accomplished with time warp) but it is important to recognize when a solution preserves or breaks causality, and in what cases, and how. 
 

And lastly,

6 hours ago, Vl3d said:

Please do not reinterpret or paraphrase my solution with variation, you can just easily link to it:

My response was after an explicit request to have the solutions paraphrased, and I did my best to represent all solutions as they were intended, even the automatic burning which I included despite it not being important to the way time warp is managed. No variation from the original solution was proposed. 

Edited April 10, 2022 by t_v
Speeling

[PlutoISaPlanet]

Maybe bases could act as hub's. If you interact with a base, you can "merge" games with someone else. 

[Vl3d]

1 hour ago, t_v said:

Let’s say that in the future, player A has set up a station on Gilly. Then, in the past, player B drives a rover through where that station eventually will be.

What if player B in the past creates a station right where player A has the station in the future and then warps to player A time?

1 hour ago, t_v said:

Player B begins their preplanned route to visit all the biomes

If you want to have automation with pre-planned routes, you use waypoint navigation AI like in Starcraft.

1 hour ago, t_v said:

Events that have happened in the future by players who have gone ahead and used more time affect the actions of player who, for all intents and purposes, have not used up as much time and are “in the past”. This is what I mean by breaking causality in real life. 

Players on the same celestial body are always in the same real-time multiplayer bubble. First come, first serve = it's a space race. Player B that arrives later has to adapt to things already built by player A. You know, like in reality. This preserves all causality.

I emphasize again that we should stop trying to solve time travel on / in proximity of celestial bodies. It breaks immersion, causality, it desyncs players and it's very close to cheating.

As for when on the journey in deep space, warp all you want, you're outside of multiplayer.

I would also add that solar system configuration is more important than having a well defined time. And one thing about orbits is that they are somewhat cyclic. So what do you even need time for? Let the server define the celestial bodies positions for you to plan and adapt to.

As for resources: resupply loops + internal game timer for each player for remaining resources (which has no real impact on multiplayer) + lower productivity instead of killing kerbals.

Edited April 10, 2022 by Vl3d

[Pthigrivi]

36 minutes ago, Vl3d said:

What if player B in the past creates a station right where player A has the station in the future and then warps to player A time? 

This probably isn’t much of an issue for stations because of how vast space is, but it would be for bases. You probably do need to have bases from the future ghosted in and holding space. 
 

39 minutes ago, Vl3d said:

I emphasize again that we should stop trying to solve time travel on / in proximity of celestial bodies. It breaks immersion, causality, it desyncs players and it's very close to cheating.

The trouble here is rendezvous and docking. Each orbit takes 30 minutes on Kerbin and it sometimes takes a dozen or more orbits to catch up to or drop back to a station or vessel you’d like to dock to. You can’t reasonably ask players to sit and wait for hours upon hours just to dock. Honestly being able to time warp at will is a basic requirement for a playable multiplayer. 

[SkyFall2489]

This is all just getting way too confusing... If it's confusing in the planning stage, imagine how confusing it would be for the players! That's why I say to keep it simple with subspace warp - a tried and true solution that is not too far off form KSP1's timewarp. Why reinvent the wheel?

[JoeSchmuckatelli]

I may or may not be in the majority with my lack of interest in multi-player as a feature for KSP2... But I do respect that for some it is a desired thing. 

That said - if there is any single thing that could be (and perhaps should be) cut from the release, it's multi-player (to the extent that solving the problems is delaying release). 

I have zero experience in game design or the problems of making an excellent single player experience work in a multi-player setting... But the problems raised in this thread make it likely that integrated multi-player is difficult even for professionals. 

Do we have any sense of whether the design team think of multi-player as a 'must-have' feature or is it merely a 'nice-to-have'? 

[Vl3d]

32 minutes ago, Pthigrivi said:

You can’t reasonably ask players to sit and wait for hours upon hours just to dock. Honestly being able to time warp at will is a basic requirement for a playable multiplayer. 

You don't even ACTUALLY need time-warp. What you're asking for is an interface solution to represent fast-travel in map view while keeping the immersion of realistic orbital maneuvers.

That's super easy to do: you get to orbit in the real-time bubble, you select the station as a destination / target, you set-up the encounter in map view. You press GO / burn. You now exit multiplayer and arrive at your destination where you sync to the local real-time multiplayer bubble. Maybe you also have to limit map view a little to only display the local on-rails system to be easier for the player to accept the sync. EZ

The only reason I'm advocating for having real-time around the celestial body is because I want to see the huge space stations / motherships being built in low orbit from a distance.

And I also don't want to see people in low orbit disappearing suddenly - but that could just be fixed with animations of the burning away + a message that you can't interact with them anymore.

As for reappearing in high orbit.. there are solutions. Like always spawning vessels out of other players field of view or at a certain place in orbit where they can't be seen.

Edited April 10, 2022 by Vl3d

[Vl3d]

6 minutes ago, Vl3d said:

I want to see the huge space stations / motherships being built in low orbit from a distance.

Actually with the OAB they just spawn on-rails. So you could just see them rising at the horizon after they get built. The smaller stuff you only see being built when you're in that specific real-time multiplayer bubble.

So, with some basic animations to maintain immersion, from low orbit you can basically do warp journeys to anywhere. All while having the MMO experience in the specific real-time bubbles: on the ground up to low orbit / around space stations / asteroids etc.

Very, very exciting!

[Pthigrivi]

29 minutes ago, Vl3d said:

That's super easy to do: you get to orbit in the real-time bubble, you select the station as a destination / target, you set-up the encounter in map view. You press GO / burn. You now exit multiplayer and arrive at your destination where you sync to the local real-time multiplayer bubble. Maybe you also have to limit map view a little to only display the local on-rails system to be easier for the player to accept the sync. EZ

I hear you, but thats not how rendezvous work. If you’re ahead of your target you do a couple of short burns to lift your orbit and then wait several orbits till they catch up. If you’re behind you lower your orbit and catch up that way. And this isn’t limited to a body’s SOI. When Im linking up with a station over Minmus from Kerbin Im setting my Pe to match a point along the target station’s orbit, and the capture burn is timed so that I get an elliptical orbit that rendezvous with the station when I return to that point. All of that is planned before I even reach Minmus SOI. 
 

The whole system, planets and moons and rotations and vessels are like a big astrolabe. You can turn the crank and wind things forward or backward, but you cant pluck things on and off and desynch them from the timeline. Everything needs to be anchored in all 4 dimensions for transfers and intercepts to work. 

29 minutes ago, Vl3d said:

The only reason I'm advocating for having real-time around the celestial body is because I want to see the huge space stations / motherships being built in low orbit from a distance.

And I also don't want to see people in low orbit disappearing suddenly - but that could just be fixed with animations of the burning away + a message that you can't interact with them anymore.

I think you have it backwards though. In a consistent-timeline ‘last seen’ paradigm things don’t pop in and out of existence. Every vessel moves smoothly through time without jumps. Things only spawn in VABs and Orbital construction platforms. If you’re in other players’ past you can watch them construct their stations, its just that its a recording and you can only contribute after the last time they docked or undocked. 

Edited April 10, 2022 by Pthigrivi

[t_v]

2 hours ago, Vl3d said:

Players on the same celestial body are always in the same real-time multiplayer bubble. First come, first serve = it's a space race. Player B that arrives later has to adapt to things already built by player A. You know, like in reality. This preserves all causality.

Technically, your solution is second-come first serve since the player that arrived later (player A) in game gets to do their stuff first. Remember, this is only important if you care about that stuff. 
 

1 hour ago, Vl3d said:

That's super easy to do: you get to orbit in the real-time bubble, you select the station as a destination / target, you set-up the encounter in map view. You press GO / burn. You now exit multiplayer and arrive at your destination where you sync to the local real-time multiplayer bubble. Maybe you also have to limit map view a little to only display the local on-rails system to be easier for the player to accept the sync. EZ

So this is just timewarping whenever you have a maneuver. How is this any different from my solution? Other than having to see a specific position of celestial bodies, which is still dumb because waiting real-life years for a Duna transfer window is dumb, and if you can just warp to the window as part of a Journey, then this is literally the exact same as my solution. 

39 minutes ago, Pthigrivi said:

I think you have it backwards though. In a consistent-timeline ‘last seen’ paradigm things don’t pop in and out of existence. Every vessel moves smoothly through time without jumps. Things only spawn in VABs and Orbital construction platforms. If you’re in other players’ past you can watch them construct their stations, its just that its a recording and you can only contribute after the last time they docked or undocked. 

This is exactly it- with the first solution, there would be complete immersion as well as complete freedom, because all craft would behave at 1x warp, even on interplanetary transfers, from the perspective of someone watching. And, when that person warps, other craft also warp consistently, not breaking immersion. In contrast, the journey system, no matter how well you animate it, will always have people completing journeys that should take years in under an hour, and you will see their ships leaving and arriving in such a short time even at 1x warp. So, this system preserves neither causality or immersion, and in my opinion now that you have implemented time warp in almost all circumstances (basically just removed physical time warp) it’s only major flaws are that it is not acknowledging that it is breaking these things. 

[Guest]

1 hour ago, JoeSchmuckatelli said:

I have zero experience in game design or the problems of making an excellent single player experience work in a multi-player setting...

Most SP experiences work well without any significant modification as a 2-10 coop game, F76 gets a lot of flak for how buggy it was (and for being multiplayer) but it's a good example of that, it's the answer to the question "what would be to play Skyrim or Fallout but in coop?".

 

2 hours ago, JoeSchmuckatelli said:

But the problems raised in this thread make it likely that integrated multi-player is difficult even for professionals. 

Professionals don't need the wheel to be explained to them every two pages or so, at least a third of all the discussion here is on how to deal with things like trolling, permission systems and other equally simple multiplayer quirks that are already solved by literally hundreds of games.

In this few days alone, during this last argument I had to explain that yes, there are moddable multiplayer games with DRM and yes, there are multiplayer games with complex resource systems and the problem of  depleting resources with maps way smaller than multiple star systems.

Also, and here's the big difference, professional actually playtest their proposals, there's a lot of prototyping and in-game testing and demonstrating points.

An example, this last few pages talking about no timewarp in a planet SOI?  A practical demonstration of someone building a 3 modules space station at 1000 kms with and without timewarp, the argument would die before the end of the first no-timewarp rendezvous.

This thread is all theory, speculation without any of the vital testing and experimentation. In a game studio with some playtesting I'm pretty sure they can came up with a definitive "solution" within a few weeks of work, most of that being the time need to implement and playtest the prototypes.

[JoeSchmuckatelli]

2 minutes ago, Master39 said:

In a game studio with some playtesting I'm pretty sure they can came up with a definitive "solution" within a few weeks of work, most of that being the time need to implement and playtest the prototypes

Interesting.  I figured it would be a more lengthy process 

[Bej Kerman]

8 minutes ago, Master39 said:

An example, this last few pages talking about no timewarp in a planet SOI?  A practical demonstration of someone building a 3 modules space station at 1000 kms with and without timewarp, the argument would die before the end of the first no-timewarp rendezvous.

Won't someone please think of the immersion?