Jump to content

KSP 2 Multiplayer Discussion Thread


Recommended Posts

2 hours ago, t_v said:

However, I had a few questions about the leapfrog model which I think point out a few points of inconsistency. Here are a few hypotheticals; how would you deal with these? These problems are exacerbated with larger time differences, but they still exist with small time differences. 

Player A has a station in LKO in year 100, that has been around for a while and people have had the chance to see it. Currently, the last interaction was in year 100. Where does player B, who is in year 101, see that station? Do they see it, or does it disappear once player B warps past the point where Player A is?

Second, Player A then uses a tug to move that station into GKO. For a few minutes, that station is not able to be interacted with, but ignoring that, where does Player B see the station, from their vantage point in the future? Does it jump to the GKO orbit, adjusted for the time difference? Or was it hidden all along, so there's no harm? To be clear, hiding the station poses a problem, which is that the player that is the farthest ahead in time is effectively alone and the only way to leave that state is to wait for other players to warp ahead. 

Third, Player B has resource routes feeding their colony that pass through Player A's base. None have triggered since year 100, but now the station is in a different spot. When the next window happens, does the route just break? Or if it doesn't, what does Player B see? 

Fourth, Player A is sending the tug over to the station. The same route system is set up but is more frequent, so the last supply mission passing through was after Player A's time. Player A cannot access their station due to interaction rules so there is no risk of it changing orbit, but now they cannot dock their tug. How would this be resolved, simply making Player A warp to Player B's time? This becomes a big problem when players set up supply routes between colonies, as entire sections of critical infrastructure could get blocked off when someone goes into the future. 

Lastly, assuming that Player B in the future can see the new position of player A's station (as it is in the future), what happens when player A launches a new supply run feeding the station from the Mun? At the start, player A's trajectory is suborbital, so from player B's perspective it has already crashed into the ground and disappeared. But once in LMO, player A leaves the mission for a moment to deal with an aerobrake somewhere else. Does player B see the new craft in its orbit? What are the rules for how long something needs to be present for it to project into the future?
 

These are great. And from the outset let me say I personally like leapfrog because it makes the most sense to me, but you're absolutely right that you and I are just intuiting here and in practice the issues with cyclic may be way overblown and the issues with leapfrog might be more punishing than I think.

1) Player B sees the station where it would be if left alone for 1 year both before and after Player A warps. If there's no change to the station it stays as is, circling happily for both players. 

2) Player B would see the station's orbit change at the same rate Player A see's that change, because the game is basically assuming that at any second Player A could cut the engines and leave it exactly where it is. Once Player A completes the maneuver Player B sees the station in GKO, positioned as if 1 year had passed, and ready to be interacted with.

3) This is tricky without knowing a bit more about how supply routes work. Let's say for argument's sake they're based on dV costs with some built-in tolerance. If the station was moved outside of the route's tolerance then yes Player B would receive a notification that the route was broken. In this particular case though the route would probably not break as it takes less dV to get to GKO from a Munar colony than to get to LKO.

4) This is a good one. This might be greedy, but I think the best solution is a kind of Schrodinger's supply route. The routes are assumed to be happening in the background but they don't themselves trigger updates. If Player A visits the station in Year 100 day 100 they could dock and would see the resources accurate for 100 days of supply deliveries. I think you're right though that if Player B makes changes to a colony on that same supply route it would trigger updates along the chain. So if Player B goes into the future they won't necessarily update everything, but if they change something at a colony hub it would update anything that colony was connected to and other players would need to catch up with those endpoints. 

5a) Player B would see 1 year of accumulated resources from that new route. If they then docked and added or withdrew those resources Player A would need to catch up as normal. 

5b) Consistent with Q2 the game basically presumes that the current orbit at any moment continues indefinitely. While Player A's vessel is sub-orbital its not visible to Player B because its assumed crashed. Once its in orbit--any stable orbit--it remains there visible to both players. This could create some funny results for things like transfers viewed from the far future, because you would temporarily see the transfering vessel as it would travel without the capture burn even if it resulted in an escape trajectory. 
 

3 hours ago, Bej Kerman said:

Why not have many servers ran by players where some are safe and others let you grief?

Not just that but sandbox servers, progression servers, servers with different difficulty settings and mod suites, etc.
 

Edited by Pthigrivi
Link to comment
Share on other sites

6 hours ago, mcwaffles2003 said:
8 hours ago, Zaffre said:

Glad to know that competitive and cooperative modes are coming. I had assumed it was going to be all competitive.

Funny cause I thought it all was going to be cooperative

funny cause I thought it would just be two indipendent players choosing to cooperate or compete.

Link to comment
Share on other sites

14 hours ago, Vl3d said:

The game simulates a multi-light year universe with sub-millimeter precision and you're worried about some rinky-dink contraptions floating around Kerbin? 

I absolutely am.    I have had at least one collision and a number of near misses during launch to LKO.    Now add hundreds of other users launching into the same orbit, and again, it’s a game I don’t want to play. 

12 hours ago, Rutabaga22 said:

Idk, it could be an option.

3 options for griefing:

Off 

On

Only abandoned structures

The idea of having an option to turn griefing  off is cute.  Players will figure out a way to get around it. 

Link to comment
Share on other sites

14 hours ago, Vl3d said:

Colonies would not clutter up the surface. They would just be a way to let players add the requested cities feature. Buildings have enough room on the celestial bodies.

If you're worried about seeing too many moving objects - I'm sure you could select only specific players (agencies) to view and/or interact with in map view. And the rest of the clutter could be hidden by only viewing active missions in the planets' real-time multiplayer bubble.

Your issue can be easily fixed with filters.

But the game  would  still need to keep track of everyone's 'junk' even if not actually displaying it, just as it does with your own 'filtered out' stuff.  So all of the calculations still need to happen  in the background slowing the game down.

Link to comment
Share on other sites

36 minutes ago, Vl3d said:

The server just doesn't send you the filtered info.

This, now you might want to view junk, or anything technological outside Kerbin SOI is very valuable. 
An true pirate spaceship is build of stolen parts. 

Link to comment
Share on other sites

I understand what @Vl3d is suggesting (I think).. 

A persistent MMO server, where each player can select/filter which other players they can interact with.  Which would also allow that selection to be changed more or less at will.

Presumably the other players would need to be active at the same time and also give permission, to prevent one from interacting without the other's knowledge.

Interesting idea, but I'm not convinced it's practical.

Link to comment
Share on other sites

On 11/17/2022 at 9:25 PM, Pthigrivi said:

1) Player B sees the station where it would be if left alone for 1 year both before and after Player A warps. If there's no change to the station it stays as is, circling happily for both players. 

Alright, that helps to clarify things. It might be a bit harder to hide the desync as a result, but since there are considerations for physical consistency, visual incoherentness might not matter. 

On 11/17/2022 at 9:25 PM, Pthigrivi said:

2) Player B would see the station's orbit change at the same rate Player A see's that change, because the game is basically assuming that at any second Player A could cut the engines and leave it exactly where it is. Once Player A completes the maneuver Player B sees the station in GKO, positioned as if 1 year had passed, and ready to be interacted with.

This is what I was envisioning, and in the cyclic model, you just see the craft at its current point in the orbit, adjusted for the less than 1 orbit time delay. So it would remain mostly in the same spot but increase in altitude in two separate kicks, one from the periapsis and one from the apoapsis. However, in the leapfrog model, you are accounting for the elapsed time, so as the craft begins to increase its apophasis or periapsis, the orbital period lengthens, which means that the craft has made less orbits in that time, so from Player B's perspective, Player A's craft suddenly starts moving retrograde really fast, at hundreds of orbits a second, until player A stops burning. Similarly, dropping down would appear to another player as if someone had hit an intense fast forwards on the craft's trajectory. 

If the station is then ready to be interacted with, there needs to be a timer where that station is non-physical, especially while burning, as that station is traveling at significant portions of c while the engine accounts for the time difference, and since it is sweeping across its orbit so fast, it has a pretty good chance of hitting something and causing massive amounts of damage. 

Just in case the visualization didn't make sense, imagine that in one year, Player A's station makes exactly 1000 orbits. As they raise the apoapsis in one game update, their orbital period gets just 0.01% longer, so they have only made 999.9 orbits, which means that the new position is 30 degrees behind the one that was previously displayed. And this happens in just one game update. Within a short time, the orbital period is now 0.1% longer, so the craft has made one orbit less one year in the future. It continues spinning backwards along its orbit very, very fast until the burn stops and everything stabilizes. 

On 11/17/2022 at 9:25 PM, Pthigrivi said:

3) This is tricky without knowing a bit more about how supply routes work. Let's say for argument's sake they're based on dV costs with some built-in tolerance. If the station was moved outside of the route's tolerance then yes Player B would receive a notification that the route was broken. In this particular case though the route would probably not break as it takes less dV to get to GKO from a Munar colony than to get to LKO.

Right, and this is also a question of how supply routes should be visualized. I was wondering if the route would end up in the old station position or the new one, which I guess doesn't have to do much with how the time system works. 

On 11/17/2022 at 9:25 PM, Pthigrivi said:

4) This is a good one. This might be greedy, but I think the best solution is a kind of Schrodinger's supply route. The routes are assumed to be happening in the background but they don't themselves trigger updates. If Player A visits the station in Year 100 day 100 they could dock and would see the resources accurate for 100 days of supply deliveries. I think you're right though that if Player B makes changes to a colony on that same supply route it would trigger updates along the chain. So if Player B goes into the future they won't necessarily update everything, but if they change something at a colony hub it would update anything that colony was connected to and other players would need to catch up with those endpoints. 

This makes sense. The problem I think I have with it, that required the previous scenario to be answered is what if Player A breaks Player B's supply routes in between? If Player A can interact with the station even though supply routes have passed through it, and player A decides to deorbit it for whatever reason, does Player B lose those materials, or do we suddenly have a duplication problem? Assume that Player B didn't interact with anything but those supply routes were needed to make other routes run, breaking those routes could cause dozens of hours of re-done gameplay as Player B has to go back in time, re-connect the route, and then re-do everything that they did since the break, using resources that they used to have. 

On 11/17/2022 at 9:25 PM, Pthigrivi said:

5b) Consistent with Q2 the game basically presumes that the current orbit at any moment continues indefinitely. While Player A's vessel is sub-orbital its not visible to Player B because its assumed crashed. Once its in orbit--any stable orbit--it remains there visible to both players. This could create some funny results for things like transfers viewed from the far future, because you would temporarily see the transfering vessel as it would travel without the capture burn even if it resulted in an escape trajectory. 

Yeah, this is a concern. The thing that I got from this is that the leapfrog system also has its own fair share of visual nonsense, from ships going crazy in their orbits to transfers behaving very weirdly. As someone closes in on the desired periapsis for their transfer, the player in the future would see a more and more aggressive slingshot, so the ship would appear to be speeding really close to the star or on a trajectory away from the star. 

 

On 11/17/2022 at 9:25 PM, Pthigrivi said:

These are great. And from the outset let me say I personally like leapfrog because it makes the most sense to me, but you're absolutely right that you and I are just intuiting here and in practice the issues with cyclic may be way overblown and the issues with leapfrog might be more punishing than I think.

Honestly, we are both intuiting, and the issues we have brought up with both systems show that probably, neither of us have a good understanding of whether issues are better or worse than we think. This sort of thing can really only be resolved with some work put into implementing the solutions so we can have a concrete example to refer to instead of trying to explain it using words, and also play testing to see what comes up more often, and what ends up being ignorable or annoying. I'd be fine with ships going wild on their trajectories, the cyclic model has some of that with transferring ships, but I'm not too sure about the interactivity restrictions. It could be that I don't find any problems with it (which I'd be very happy about), but we'll have to see when the first mods or official implementations of multiplayer come out. 

Link to comment
Share on other sites

3 minutes ago, t_v said:

Alright, that helps to clarify things. It might be a bit harder to hide the desync as a result, but since there are considerations for physical consistency, visual incoherentness might not matter. 

This is what I was envisioning, and in the cyclic model, you just see the craft at its current point in the orbit, adjusted for the less than 1 orbit time delay. So it would remain mostly in the same spot but increase in altitude in two separate kicks, one from the periapsis and one from the apoapsis. However, in the leapfrog model, you are accounting for the elapsed time, so as the craft begins to increase its apophasis or periapsis, the orbital period lengthens, which means that the craft has made less orbits in that time, so from Player B's perspective, Player A's craft suddenly starts moving retrograde really fast, at hundreds of orbits a second, until player A stops burning. Similarly, dropping down would appear to another player as if someone had hit an intense fast forwards on the craft's trajectory. 

If the station is then ready to be interacted with, there needs to be a timer where that station is non-physical, especially while burning, as that station is traveling at significant portions of c while the engine accounts for the time difference, and since it is sweeping across its orbit so fast, it has a pretty good chance of hitting something and causing massive amounts of damage. 

Just in case the visualization didn't make sense, imagine that in one year, Player A's station makes exactly 1000 orbits. As they raise the apoapsis in one game update, their orbital period gets just 0.01% longer, so they have only made 999.9 orbits, which means that the new position is 30 degrees behind the one that was previously displayed. And this happens in just one game update. Within a short time, the orbital period is now 0.1% longer, so the craft has made one orbit less one year in the future. It continues spinning backwards along its orbit very, very fast until the burn stops and everything stabilizes. 

Right, and this is also a question of how supply routes should be visualized. I was wondering if the route would end up in the old station position or the new one, which I guess doesn't have to do much with how the time system works. 

This makes sense. The problem I think I have with it, that required the previous scenario to be answered is what if Player A breaks Player B's supply routes in between? If Player A can interact with the station even though supply routes have passed through it, and player A decides to deorbit it for whatever reason, does Player B lose those materials, or do we suddenly have a duplication problem? Assume that Player B didn't interact with anything but those supply routes were needed to make other routes run, breaking those routes could cause dozens of hours of re-done gameplay as Player B has to go back in time, re-connect the route, and then re-do everything that they did since the break, using resources that they used to have. 

Yeah, this is a concern. The thing that I got from this is that the leapfrog system also has its own fair share of visual nonsense, from ships going crazy in their orbits to transfers behaving very weirdly. As someone closes in on the desired periapsis for their transfer, the player in the future would see a more and more aggressive slingshot, so the ship would appear to be speeding really close to the star or on a trajectory away from the star. 

 

Honestly, we are both intuiting, and the issues we have brought up with both systems show that probably, neither of us have a good understanding of whether issues are better or worse than we think. This sort of thing can really only be resolved with some work put into implementing the solutions so we can have a concrete example to refer to instead of trying to explain it using words, and also play testing to see what comes up more often, and what ends up being ignorable or annoying. I'd be fine with ships going wild on their trajectories, the cyclic model has some of that with transferring ships, but I'm not too sure about the interactivity restrictions. It could be that I don't find any problems with it (which I'd be very happy about), but we'll have to see when the first mods or official implementations of multiplayer come out. 

I still say leapfrog or encounter. Leapfrog has been implemented before, and it's worked great. I doubt any of us have the coding experience necessary to actually implement any of these systems, but leapfrog/subspace has been implemented before. Encounters can't be too hard, as the time is the same for everyone.

A reminder of my encounters idea:

Spoiler

Encounters is a multiplayer system for a small number of players, maybe just you and your friends.

How it works:

Two players, each in their single player saves, agree on a time to begin the encounter, an SOI, and select which ships to bring.

Both must warp to that time, and whichever of each player's selected ships are in the SOI at the time are transported into a single-SOI "Encounter" universe.

In the encounter, warp of all players is linked, and they are at the exact same time. Warp will either be master controlled, removed, or maybe controlled by all users (if anyone presses the warp button everyone will get a prompt asking whether they want to warp, if all players accept then time warps).

At any point, a player can leave the encounter, selecting any ships in the encounter to bring back with them. They are removed from the encounter universe, and brought to that player's home save. Also, that player's save will be warped forward by however much time has passed in the encounter.

Once there is only one player left in the encounter, they are automatically transported to their home save with whatever ships remain in the encounter universe.

 

So, encounters are only for people you trust, and small friend groups, but completely solves warp time sync issues.

 

Link to comment
Share on other sites

9 minutes ago, SkyFall2489 said:

I still say leapfrog or encounter. Leapfrog has been implemented before, and it's worked great. I doubt any of us have the coding experience necessary to actually implement any of these systems, but leapfrog/subspace has been implemented before. Encounters can't be too hard, as the time is the same for everyone.

A reminder of my encounters idea:

  Hide contents

Encounters is a multiplayer system for a small number of players, maybe just you and your friends.

How it works:

Two players, each in their single player saves, agree on a time to begin the encounter, an SOI, and select which ships to bring.

Both must warp to that time, and whichever of each player's selected ships are in the SOI at the time are transported into a single-SOI "Encounter" universe.

In the encounter, warp of all players is linked, and they are at the exact same time. Warp will either be master controlled, removed, or maybe controlled by all users (if anyone presses the warp button everyone will get a prompt asking whether they want to warp, if all players accept then time warps).

At any point, a player can leave the encounter, selecting any ships in the encounter to bring back with them. They are removed from the encounter universe, and brought to that player's home save. Also, that player's save will be warped forward by however much time has passed in the encounter.

Once there is only one player left in the encounter, they are automatically transported to their home save with whatever ships remain in the encounter universe.

 

So, encounters are only for people you trust, and small friend groups, but completely solves warp time sync issues.

 

Yep, encounters seems pretty consistent. There are probably some edge cases and cheese, but since you are in your own single player world most of the time, you don't have to deal with representing other players' craft with all the weird time warping, and the only time you are interacting, time is perfectly consistent. However, the whole reason I am sticking with a system that makes compromises and inaccuracies is because I'd like for the world to feel very multi player when it is multi player. Even leap frog or Local Bubble has special considerations that make things potentially inconsistent just to always at least be able to see the ships that other players have. It comes down to a matter of preference how people want to play the game, and in my opinion, something that allows for the most types of play is probably going to be the best to include as the Stock multiplayer solution. 

Link to comment
Share on other sites

Just now, t_v said:

Yep, encounters seems pretty consistent. There are probably some edge cases and cheese, but since you are in your own single player world most of the time, you don't have to deal with representing other players' craft with all the weird time warping, and the only time you are interacting, time is perfectly consistent. However, the whole reason I am sticking with a system that makes compromises and inaccuracies is because I'd like for the world to feel very multi player when it is multi player. Even leap frog or Local Bubble has special considerations that make things potentially inconsistent just to always at least be able to see the ships that other players have. It comes down to a matter of preference how people want to play the game, and in my opinion, something that allows for the most types of play is probably going to be the best to include as the Stock multiplayer solution. 

Yeah, it's all about what the players want. As for preference, what would be REALLY nice is if mods could implement their own multiplayer systems, and experienced coders could get KSP multiplayer in any variation that is implementable. However, if there are too many systems, then the big servers on any one system that supports it would have less players comapred to if less systems were available.

Link to comment
Share on other sites

10 hours ago, pandaman said:

I understand what @Vl3d is suggesting (I think).. 

A persistent MMO server, where each player can select/filter which other players they can interact with.  Which would also allow that selection to be changed more or less at will.

Presumably the other players would need to be active at the same time and also give permission, to prevent one from interacting without the other's knowledge.

Interesting idea, but I'm not convinced it's practical.

It would be far more practical to just have small isolated servers hosted by players and dedicated hosts.

Link to comment
Share on other sites

Also, one other thing to consider:

A while ago, players did space battles in KSP by setting up a complex turn based system and exchanging save files. While this has serious limitations, maybe we could do a very simple "time is the same for everyone, and use the encounters consensus based warp control system"? We don't need to over complicate anything.

Link to comment
Share on other sites

3 minutes ago, SkyFall2489 said:

Also, one other thing to consider:

A while ago, players did space battles in KSP by setting up a complex turn based system and exchanging save files. While this has serious limitations, maybe we could do a very simple "time is the same for everyone, and use the encounters consensus based warp control system"? We don't need to over complicate anything.

Is this different from the vote-to-warp system? If it is, could you clarify the difference?

A system where everyone warps at the same time has been proposed by many, and it would be sort of turn based, as when one player wants to do something that takes a long time and another wants to hop around the atmosphere, the player waiting isn't able to do their mission but is able to manage their bases and also do things that don't require warp.

People have had issues with this as puttering around bases isn't something fun when you are forced to do it, and important missions might take a long time to complete IRL as everyone else fills the intervening time with smaller missions.

Link to comment
Share on other sites

18 minutes ago, t_v said:

Is this different from the vote-to-warp system? If it is, could you clarify the difference?

A system where everyone warps at the same time has been proposed by many, and it would be sort of turn based, as when one player wants to do something that takes a long time and another wants to hop around the atmosphere, the player waiting isn't able to do their mission but is able to manage their bases and also do things that don't require warp.

People have had issues with this as puttering around bases isn't something fun when you are forced to do it, and important missions might take a long time to complete IRL as everyone else fills the intervening time with smaller missions.

It's very similar to vote to warp. I don't know the exact sequnce of actions in vote to warp, but it falls under that category.

Yeah, vote to warp is better for things like encounters and small worlds with a few players.

Link to comment
Share on other sites

17 hours ago, Bej Kerman said:

It would be far more practical to just have small isolated servers hosted by players and dedicated hosts.

I completely agree.  

I understand, and respect, that some like the idea of MMO style KSP, but I just don't think it would work for this particular game.

Link to comment
Share on other sites

Reminder - the PCG call-out about that a player-predicted MP implementation might be correct is not the same as Nate actually saying which of the many predictions are correct

PCG speculated that @Vl3dgot it right.  He's speculated about a LOT of things vis MP.   Only one line of his speculation posts is MMO-style. Clearly he wants a MMO style of MP - but that is the least likely implementation in my book.

Nate said that there are 4 launch pads at KSC (in a different reveal). Nate said that MP introduced 'Agencies' with both cooperative and competitive play available:

"Multiplayer introduces the concept of agencies, so you can work alongside friends within a single agency contributing to a single space program in a way that's cooperative," Simpson says. You can also play competitively between agencies, each of which is located at a different location on Kerbin. With multi-agency play you can have space races. We're excited to see all the new types of gameplay that emerge from multiplayer."

The real 'new' news is that Agencies will get different locations around Kerbin to operate from.* 

That's all we know. 

Reread what PCG speculated:

It's tantalizing to speculate, but it sounds like Kerbal forum member Vl3d—who wrote a post in April that envisioned KSP 2 multiplayer as "a competitive space-race team-based persistent-world MMO with inter-agency contracts and trade"—may be getting their dream for "the greatest game ever made."

https://www.pcgamer.com/kerbal-space-program-2-is-going-to-let-you-have-competitive-multiplayer-space-races/

That, friends, is hype - not confirmation

 

 

 

 

 

* This should reduce griefing (but not eliminate ICBM / Plane PVP elements, entirely).  Who knows what limits will be placed - but players in competition being scattered around the planet eliminates the 'easy' griefing. 

 

 

Edited by JoeSchmuckatelli
Link to comment
Share on other sites

25 minutes ago, JoeSchmuckatelli said:

Reminder - the PCG call-out about that a player-predicted MP implementation might be correct is not the same as Nate actually saying which of the many predictions are correct

PCG speculated that @Vl3dgot it right.  He's speculated about a LOT of things vis MP.   Only one line of his speculation posts is MMO-style. Clearly he wants a MMO style of MP - but that is the least likely implementation in my book.

Nate said that there are 4 launch pads at KSC (in a different reveal). Nate said that MP introduced 'Agencies' with both cooperative and competitive play available:

"Multiplayer introduces the concept of agencies, so you can work alongside friends within a single agency contributing to a single space program in a way that's cooperative," Simpson says. You can also play competitively between agencies, each of which is located at a different location on Kerbin. With multi-agency play you can have space races. We're excited to see all the new types of gameplay that emerge from multiplayer."

The real 'new' news is that Agencies will get different locations around Kerbin to operate from.* 

That's all we know. 

Reread what PCG speculated:

It's tantalizing to speculate, but it sounds like Kerbal forum member Vl3d—who wrote a post in April that envisioned KSP 2 multiplayer as "a competitive space-race team-based persistent-world MMO with inter-agency contracts and trade"—may be getting their dream for "the greatest game ever made."

https://www.pcgamer.com/kerbal-space-program-2-is-going-to-let-you-have-competitive-multiplayer-space-races/

That, friends, is hype - not confirmation

 

 

 

 

 

* This should reduce griefing (but not eliminate ICBM / Plane PVP elements, entirely).  Who knows what limits will be placed - but players in competition being scattered around the planet eliminates the 'easy' griefing. 

 

 

Well, if we take out the hype, here's what we know for sure:

1. "agencies" - players belong to them, each agency has its own launch pad (i'm thinking maybe teams or factions?)

2. multiplayer will be there

3. some form of time is implemented, so players can "race" - meaning that they compete to achieve some predetermined goal before their competitors do. 

4. rocket science. after all, it's KSP, but 2.

 

Right?

Or are there other things that we know that I haven't heard of?

 

Now, more speculation:

Vl3D's MMO idea might work, but personally I feel it still breaks some realism to keep everything synced.

Note the use of "friends" in the quote from simpson - small scale multiplayer will be supported, not sure about larger scale.

It sounds like a multiplayer save will be its own world, so looks like Encounters will NOT be the system implemented.

To me, it'll either be vote to warp, subspace/leapfrog, or MMO. I expect subspace because it's been implemented before and seems to work just fine, while still functioning at larger scales than vote to warp.

Link to comment
Share on other sites

5 minutes ago, SkyFall2489 said:

Note the use of "friends" in the quote from simpson

I see that as key. 

Likely to be a limited number of people on any MP game.  Unlikely to be a free for all. But that is my guesswork as well. 

I'm envisioning that with Agencies a few KSC clones will be dropped around the planet.  Emphasis on 'a few'.  If players are cooperative they can all use the same launch facility, but different pads.  If players are competing - they have to use their own particular KSC.  Likely to be equatorially placed.  Maybe each gets a KSC and a different place to use for Polar launching - like we get in SP. 

But to take Nate's words and envision a MMO?  How many KSC facilities would be sprinkled across the planet?  

Minecraft realms allows a 10 player limit.  That seems like a reasonable upper limit to MP in KSP2.  No way we get shooter levels of players (64 or more) vying for space on Kerbin. 

/speculation 

Link to comment
Share on other sites

×
×
  • Create New...