KSP 2 Multiplayer Discussion Thread

[Habalabam]

2 minutes ago, Master39 said:

That's not "the most obvious solution" that's just not putting any effort in finding one.

It can of course be the absence of effort. It can also be, in spite of considerable effort, not finding one. It can also be because there isn't any better.

Either way, it is the one to beat. With burden of proof lies on the challenger.

 

It would be nice to have a cake and eat it too. Like I said, playing around with your fuel extraction+refinery+depot another player has a completely independent experience with time compression in another part of the solar system, but I've seen many suggestions at spheres of influence, but they run into persistence issues. 

In the previous KSP forums, I remember a "look ahead" model where the game could incorporate separate event bubbles. Meaning that if a guy was mucking around at the Mun base, then you could launch another satelite in orbit around the Mun while he was active on the mun surface at 1x time compression the whole time. However, in order to complete the mission with time compression, you jumped ahead of him on the timeline. When you had completed your mission, you could jump back to his time and the mission would unfold just like you performed it, meaning that the mission would complete itself sometime in the future. A sort of advanced mission planner that would unfold exactly as you did it unless something affects it, erasing its future timeline. But the edge cases became too many and contrived and the end result would hardly be possible to utilize.

Since we have such a beautiful time sink as the VAB, I don't think it will be a problem. 

[Guest]

@Habalabam I can't see how your timewarp system could work and be fun. Think a bit about just how much you timewarp: my sandbox where I'm tooling around Jool must be in year 60 by now. If I had spent the same amount of time tooling around the Kerbin system, I'd most likely still be in year 1. I.e. I've spent certainly less than a fraction of 1% of game time in 1 x timewarp – and most likely than 90% of my play-time in 1 x timewarp. 

I.e. your system would make any play that involves transfers that last more than a few hours effectively impossible, if there are more than a small handful of players participating.

Again: the way I see it, co-op missions are the only realistic form of multiplayer for KSP. My bet is that it's going to be Making History style missions, with players getting together for a session to play through one.  Or alternatively, a system where a host can invite guests into his game-world, and then they get together to play co-op in it.

Just within the bounds of possibility is a system where players agree to merge their games and meet up at some time and place in the spacetime continuum, no earlier than the latest player's time – although that leaves open a lot of potentially hairy situations: if KSC has different levels, whose appears in the game? If two players have overlapping installations, how do we deal with that? What happens to the other players' stuff when the session ends? Does it remain or does it just vanish back into the space-time continuum? 

I do not see how servers with a persistent world could possibly work here. The space-time paradoxes are just too messy. @Wubslin does a good job demonstrating just how messy – in his model, the player "catching up" would be seeing the other player's "ghost ships" where they were at the time he was catching up, but since everything that's happened with them has already happened, he can't interact with them in any way. Not to mention, this introduces the entirely non-trivial problem that the game would have to be able to reconstruct its world-state at any given moment in its past. I would not relish having to program something like that, and I program things that deal with entity histories for a living.

Seriously people, dial down your expectations or you're going to be majorly disappointed. There won't be a flourishing persistent galaxy of kerbals merrily exploring, sending messages, trading, or fighting wars. The timescales involved simply don't allow that, not even at the scale of the scaled-down Kerbol system, let alone interstellar distances. (Incidentally, this is much the same reason I'm not losing any sleep over the possibility of an alien invasion here on Earth.)

Edited February 22, 2021 by Guest

[Habalabam]

@Brikoleur

My post stated that I agreed with you.  Did you read the last sentence of the main paragraph?

It was a response to the notion that a simple "lowest bidder decides the global time compression" was from a lack of considering other options.

[Guest]

1 minute ago, Habalabam said:

@Brikoleur

My post stated that I agreed with you.  Did you read the last sentence of the main paragraph?

It was a response to the notion that a simple "lowest bidder decides the global time compression" was from a lack of considering other options.

I wrote my message in response to your previous one, and you posted the new one while I was writing it. So the answer is, no, I didn't, not until after I had clicked "Submit Reply." I happy to hear that we're in agreement.

[Bej Kerman]

On 2/12/2021 at 12:09 AM, BigStar Aerospace said:

yes there will have to be a war aspect

no.

[Guest]

19 minutes ago, Habalabam said:

It can of course be the absence of effort. It can also be, in spite of considerable effort, not finding one. It can also be because there isn't any better.

Either way, it is the one to beat. With burden of proof lies on the challenger.

It's the result of doing nothing, however you look at it, it's the consequence of completely ignoring the problem, not one of the possible solutions.

 

Both you and @Brikoleur are overblowing the matter, a merging system can be simply designed and most of the paradoxes can simply be solved by not allowing interaction without merging timelines first.

As for the KSC upgrades they're barely a worthwhile attition to KSP1, I can totally see them scrapping them at least for co-op games, especially since we'll be able to build fully fledged launch facilities around the system and tinker with their upgrades and design.

 

Obviously the game will shine as a co-op game for organised friends, not for large groups of randoms.

 

[Guest]

30 minutes ago, Master39 said:

Both you and @Brikoleur are overblowing the matter, a merging system can be simply designed and most of the paradoxes can simply be solved by not allowing interaction without merging timelines first.

Could you elaborate on this? Because it sounds to me that you're hand-waving away a whole bunch of stuff that could get genuinely messy:

(1) What if craft or installations occupy the same space?

(2) What happens to the other players' stuff after the co-op session ends? 
(a) It vanishes back into the void – fair, but in that case, what's the gameplay value of merging timelines over host/guest?
(b) It remains in each player's world – in that case, what happens if the same players merge timelines later again? Is everybody's stuff updated to its new state, or added again? What if in the interim the players have made use of, modified, or built upon the stuff the others left behind – leading to situation (1) basically? 

From where I'm standing all of this can be sidestepped with a host/guest system, for pretty much the same gameplay experience:

Player A: invites players B and C for a co-op session in his world

Players B and C: request to import craft Temeraire, Victory, Now That's What I Call A  Ship, Orbital Construction Facility Mega-1, and Mun Base Alpha.

Player A: accepts request for the craft and OCF, denies for Mun Base Alpha. The other players acknowledge, and the co-op session starts in Player A's timeline, with the craft and installations players B and C appearing there.

In this situation, it doesn't cause any problems to either keep or disappear the stuff imported at the start of the session.

[Guest]

Assumption: you can't go back in time, only the one that's behind can catch up.

Now, given that starting assumption:

1 hour ago, Brikoleur said:

What if craft or installations occupy the same space?

One of the two has to have built the installation first, you can't build were someone else's has a building or craft.

If you're in orbit you'll magically miss by a hundred meters or, even better, the craft simply doesn't spawn in your physic bubble if you're not synced.

1 hour ago, Brikoleur said:

(2) What happens to the other players' stuff after the co-op session ends? 

(a) It vanishes back into the void – fair, but in that case, what's the gameplay value of merging timelines over host/guest?
(b) It remains in each player's world – in that case, what happens if the same players merge timelines later again? Is everybody's stuff updated to its new state, or added again? What if in the interim the players have made use of, modified, or built upon the stuff the others left behind – leading to situation (1) basically? 

I said merging to make it clear that I'm excluding the silly idea of having to record every action and playing it live for the player(s) that's behind, but the game is still one so I'd say:

If the host leaves everybody is kicked out.

If a guest leaves he remains where it is, the next time he logs in he'll have a lot of catching up to do.

You can't interact with other player crafts buildings if you're not synced up  with them (there are a lot of ways to implement relatively simple permission systems to allow for use of infrastructure from different timelines but I'm keeping things as simple as possible).

 

1 hour ago, Brikoleur said:

From where I'm standing all of this can be sidestepped with a host/guest system, for pretty much the same gameplay experience:

Player A: invites players B and C for a co-op session in his world

Players B and C: request to import craft Temeraire, Victory, Now That's What I Call A  Ship, Orbital Construction Facility Mega-1, and Mun Base Alpha.

Player A: accepts request for the craft and OCF, denies for Mun Base Alpha. The other players acknowledge, and the co-op session starts in Player A's timeline, with the craft and installations players B and C appearing there.

In this situation, it doesn't cause any problems to either keep or disappear the stuff imported at the start of the session.

This is another solution tha allows for merging preexisting single player saves, I was thinking about dedicated co-op runs.

[Guest]

9 minutes ago, Master39 said:

This is another solution tha allows for merging preexisting single player saves, I was thinking about dedicated co-op runs.

It sounds like the main difference between our preferred approaches, then, is that I don't want dedicated co-op world at all. I just want single-player worlds with drop-in co-op.

Thing is, I just don't see what the entire point of a dedicated co-op world would be. It just introduces complications with no meaningful gameplay. For example, suppose you build a little tier 1 Mun base in year 5, then go off for 50 years to do interplanetary stuff. In the meantime, I, a poopy-head, notice your base and build a big tier 3 Mun base around it, completely enclosing it. When you get back, there's nothing you can do about it. If my big tier 3 base exists as an indestructible physical object in your game, I've locked you out of your base. If it doesn't and it's just a ghost, it still prevents you from expanding your base (since you're not allowed to build in space occupied by my buildings), as well as being really awkward in-game since it's just there graphically, you can just fly/drive through it.

I can't see how that would be interesting or enjoyable. Yet it means that the game would have to have systems that cause anything either of us builds to appear in both of our games when either of us builds it, syncing the worlds sort of but not really.

No @Master39, in my view it just doesn't work. It's a significant amount of added complication for negligible benefit and in my view some tangible drawbacks. It's gotta be drop-in host/guest co-op, or set-piece co-op missions. Persistent co-op worlds just aren't a good fit.

[MechBFP]

25 minutes ago, Brikoleur said:

It sounds like the main difference between our preferred approaches, then, is that I don't want dedicated co-op world at all. I just want single-player worlds with drop-in co-op.

Thing is, I just don't see what the entire point of a dedicated co-op world would be. It just introduces complications with no meaningful gameplay. For example, suppose you build a little tier 1 Mun base in year 5, then go off for 50 years to do interplanetary stuff. In the meantime, I, a poopy-head, notice your base and build a big tier 3 Mun base around it, completely enclosing it. When you get back, there's nothing you can do about it. If my big tier 3 base exists as an indestructible physical object in your game, I've locked you out of your base. If it doesn't and it's just a ghost, it still prevents you from expanding your base (since you're not allowed to build in space occupied by my buildings), as well as being really awkward in-game since it's just there graphically, you can just fly/drive through it.

I can't see how that would be interesting or enjoyable. Yet it means that the game would have to have systems that cause anything either of us builds to appear in both of our games when either of us builds it, syncing the worlds sort of but not really.

No @Master39, in my view it just doesn't work. It's a significant amount of added complication for negligible benefit and in my view some tangible drawbacks. It's gotta be drop-in host/guest co-op, or set-piece co-op missions. Persistent co-op worlds just aren't a good fit.

Reminds me of people trying to play on vanilla Minecraft servers with randoms and in about 10 minutes the entire spawning area is a giant crater down to bedrock, guaranteed.

[Guest]

21 minutes ago, Brikoleur said:

It sounds like the main difference between our preferred approaches, then, is that I don't want dedicated co-op world at all. I just want single-player worlds with drop-in co-op.

That's the co-op I'm talking about as seen from the point of view of the host.

Just like a LAN Minecraft game there's you and your 4 friends and one of you hosts the game, maybe the one that plays the most. No strangers, no poopy-heads, just you and  your friends playing and every player has his own space agency/company  and his set of crafts and colonies.
It doesn't have to be competitive and it doesn't have to be everyone on the same exact craft all the time.

 

6 minutes ago, MechBFP said:

Reminds me of people trying to play on vanilla Minecraft servers with randoms and in about 10 minutes the entire spawning area is a giant crater down to bedrock, guaranteed.

A server specifically build for that maybe, most Vanilla servers if decently managed are way better than that (if they're not just search for another one). I've managed mostly vanilla servers (plug-ins to allow for towns and some light modding to add our custom physical coin system) with up to 2-300 players and even with PVP active I've seen players collaborating to build huge cities and other projects.

But anyway I'm not talking about playing with random people, just a normal game but in co-op with friends instead of everybody in his own single player.

[PlutoISaPlanet]

5 hours ago, Habalabam said:

To me, the multiplayer scenarios are:

• Mayhem. Let's take the designs and go crazy. Be it flying, racing, fighting etc. I believe the spaceports should have a little distance, but not so much that meeting up with land or sea faring vehicles is impractical.
• Dual campaign. We play in parallel, but we interact. Separate tech trees, separate spaceports, separate installations. You can dock with my stuff, but I still need to activate my valves before you get any fuel. Or I need to grant your kerbals permission to enter.
• Co-op campaign. My favorite. PVE. We co-operate. We can even work on the same design simultaneously (co-op in editor) if we so choose.

I think the most obvious solution to time warp is that the person with the desire for the lowest time compression decides. So, if I desire a 100x time compression, but my buddy desires 1x, then we go with 1x until he ramps it up or surrenders control to me.

The problem then is, what do you do with time consuming stuff such as driving a rover or flying a plane? Must everybody else wait while somebody does that?  I think the simplest answer is "yes".
I think that an alarm clock system is necessary, so I can set the my rocket to give an alarm and go to 1x time compression when my rocket reaches Mun. This leaves me free to play around in the VAB or something in the meantime until my event comes up.

I agree that there can be situations where it would make sense that a person could muck about on the Mun surface at 1x speed and not caring that day suddenly turned into night because someone else needed time compression on the interplanetary scale, but I don't see how this would be practical. This is simply the price to pay for multiplayer. 

And, of course, I want to undertake a mission as a kerbal, maybe even first person perspective only for the hardcore players, with my buddy sitting next to me while we together. With only access to the controls that my kerbal is operating from his/her IVA seat. And we can reenact the Apollo 11 mission.

This is most realistic 

[MechBFP]

54 minutes ago, Master39 said:

But anyway I'm not talking about playing with random people, just a normal game but in co-op with friends instead of everybody in his own single player.

While that is great, people except to be able to play with other random people when it comes to multiplayer, coop or otherwise. So if it is subject to griefing its not a good system, and that means adding layers of control on top, such as restricting building areas within a certain radius and turning off damage within that radius.

[Dr. Kerbal]

27 minutes ago, MechBFP said:

While that is great, people except to be able to play with other random people when it comes to multiplayer, coop or otherwise. So if it is subject to griefing its not a good system, and that means adding layers of control on top, such as restricting building areas within a certain radius and turning off damage within that radius.

what about servers?

[Guest]

1 hour ago, Master39 said:

That's the co-op I'm talking about as seen from the point of view of the host.

Just like a LAN Minecraft game there's you and your 4 friends and one of you hosts the game, maybe the one that plays the most. No strangers, no poopy-heads, just you and  your friends playing and every player has his own space agency/company  and his set of crafts and colonies.
It doesn't have to be competitive and it doesn't have to be everyone on the same exact craft all the time.

I must have misunderstood you, because I thought you were advocating for a persistent server with peers who merge timelines for co-op sessions, rather than host/guest drop-in.

For example, your ”no building on occupied ground” rule implies that whenever someone builds something somewhere, that space is immediately blocked for building to everyone on the same server, regardless of the current date in their timeline. Could you elaborate?

(In case it wasn’t clear, my host/guest drop-in solution would certainly allow for players to be on different craft, and even to import craft and other assets from their games, subject to consent by the host; even exporting stuff back would be feasible. It’s just that the only world state affected directly by the co-op session would be the host’s, and any conflicts or paradoxes would be solved prior to import of any assets.)

[Guest]

19 minutes ago, Brikoleur said:

I must have misunderstood you, because I thought you were advocating for a persistent server with peers who merge timelines for co-op sessions, rather than host/guest drop-in.

Just like in Factorio or Minecraft there's a host that can be either your single player game (and you invite other people) or a dedicated runtime that's the server.

Within the server every player plays at his own pace, if you want to directly interact with someone else the one that's behind has to warp up to the other player.

Nobody ever goes back in time, only forward and some simple rules (like the "exclusion zones" around buildings) are in place. That should be enough to prevent any possible paradox.

 

1 hour ago, Brikoleur said:

For example, your ”no building on occupied ground” rule implies that whenever someone builds something somewhere, that space is immediately blocked for building to everyone on the same server, regardless of the current date in their timeline. Could you elaborate?

When you build something an "exclusion zone" is created around it, other people have to be synced up with you to build there, you could also link this to a direct permission system.

The other craft could also simply not spawn (or spawn as a ghost) if you're not synced or don't have the permission to interact.

To allow for interaction without syncing you transfer the "ownership" of a craft to another player (it can be a lot more refined and detailed, even to the point of managing single docking ports, landing pads or facilities to be transferred to other players).

 

Players have literally a solar system worth of space to play in, I don't think that overlapping bases or ships will be a huge problem.

 

 

 

 

[Guest]

38 minutes ago, Master39 said:

When you build something an "exclusion zone" is created around it, other people have to be synced up with you to build there, you could also link this to a direct permission system.

How big are the exclusion zones? Are there any mechanisms for stopping someone from seizing all the best real estate? Suppose you played an hour or two a day, but timewarped relatively little, and got a colonisation mission for Eve going in year 10. By the time you arrived, you discover that the peak you wanted to colonise was already claimed by me last week in real time, who’s been playing non-stop but timewarping a lot, and built a colony there in the year 121 in my timeline. How would you feel in that situation? I know that if the boot was on the other leg, I’d probably ragequit and go back to single-player.

38 minutes ago, Master39 said:

Players have literally a solar system worth of space to play in, I don't think that overlapping bases or ships will be a huge problem.

I beg to differ. The solar system is big, yes, and some bodies certainly have lots of room – but others don’t. For example, there really aren’t many spots  on Laythe that are (1) equatorial and (2) flat, and fewer still that have nice views of Jool. On Eve the best spot for a base is on a high peak near the equator: how many are there?  Minmus is pretty small and close by; how long do you think it’d take before all the space on equatorial flats is claimed?  Since resource extraction plays a significant part in the game too, I’d imagine that further reduces the amount of desirable real estate. My idea of fun in KSP2 multiplayer is not a real-estate rush. (And then there are all the niggly little details — for example, can you park craft in the construction exclusion zones? If not, how do you enforce the ban? Is there an invisible wall that prevents you from driving there, or the Kraken that magically moves the craft out of it, or a pop-up that prevents you from tabbing out of the craft if it’s the zone, or some other solution? If yes, what happens when a building appears where the craft is parked?)

Finally, I’m not claiming that any of these issues are insuperable. I am claiming that they are real and  need addressing, which adds complexity that could be avoided simply by going with host/guest drop-in co-op with asset import/export through mutual consent. I also don’t see how your proposed persistent world where players agree to sync their timelines to co-operate would offer meaningfully better gameplay, whereas I believe the gameplay effects will be demonstrably and materially worse in some cases, such as the one I outlined above.

I.e. I see no or extremely limited upside, a significant cost, and a significant downside to your proposed solutions compared to mine. Unless you can demonstrate some compelling gameplay value that I haven’t considered, I really don’t see the point.

Edited February 22, 2021 by Guest

[Guest]

1 hour ago, Brikoleur said:

How big are the exclusion zones? Are there any mechanisms for stopping someone from seizing all the best real estate? Suppose you played an hour or two a day, but timewarped relatively little, and got a colonisation mission for Eve going in year 10. By the time you arrived, you discover that the peak you wanted to colonise was already claimed by me last week in real time, who’s been playing non-stop but timewarping a lot, and built a colony there in the year 121 in my timeline. How would you feel in that situation? I know that if the boot was on the other leg, I’d probably ragequit and go back to single-player.

That's a lot more competitive and disorganized that what I have in mind, doesn't seems like those 2 player would go very far in any co-op game, it's not a KSP2 exclusive problem.

 

1 hour ago, Brikoleur said:

On Eve the best spot for a base is on a high peak near the equator: how many are there?  Minmus is pretty small and close by; how long do you think it’d take before all the space on equatorial flats is claimed?  Since resource extraction plays a significant part in the game too, I’d imagine that further reduces the amount of desirable real estate. My idea of fun in KSP2 multiplayer is not a real-estate rush.

How many players are you planning to play with? Because I can't see the game being designed for groups larger than 2-10 organized friends (the standard for co-op games seems to be around 4-5 players), maybe allowing for bigger servers but certainly not designed around 20-50 people public ones.

And if that answer is "less than 5", my question becomes: How many bases you plan to build? One every 2 km covering the whole (equatorial) surface of every planet? I can see Laythe as a desirable place with little space to build on, but not certainly many other places. 

And all of that is while keeping the system as simple as possible, there are plenty of solutions to allow for easy sharing of big bases and infrastructure across players instead of having them building duplicates all over the place.

 

1 hour ago, Brikoleur said:

for example, can you park craft in the construction exclusion zones? If not, how do you enforce the ban? Is there an invisible wall that prevents you from driving there, or the Kraken that magically moves the craft out of it, or a pop-up that prevents you from tabbing out of the craft if it’s the zone, or some other solution? If yes, what happens when a building appears where the craft is parked?

Think about when in KSP1 you're landing at a base and, approaching it, it loads and spawns in your physics bubble.

The same, but the base/craft you see is semitransparent and you cant interact with it. A screen message asks you to exit the exclusion zone and informs you that that's not a safe spot and, just like when you're falling near the surface, you can't save there and if you leave the game reverts to the last saved safe orbit.

To interact with the base you have to sync up first or ask ownership to the other player (or some lower level of control if you allow the system to be just a little more complex).

 

1 hour ago, Brikoleur said:

I am claiming that they are real and  need addressing, which adds complexity

My compromises are what I (not a game designer) can think of on the spot while I'm writing them, I'm pretty sure a team of professional people, with an opening for a "multiplayer engineer", can easily get a little more complex than that as their default "easy solution", and then cobble together a bunch of prototypes to playtest.

 

1 hour ago, Brikoleur said:

I.e. I see no or extremely limited upside, a significant cost, and a significant downside to your proposed solutions compared to mine. Unless you can demonstrate some compelling gameplay value that I haven’t considered, I really don’t see the point.

In  my case you're playing CO-OP with other players in one dedicated save together, in yours you can temporarily merge multiple single player saves, at most to make a shared mission, allow someone to add a module to your base/station or show him your save and or a specific craft.

I love Factorio, I also never finished a game alone, I usually play with friends. What's the added gameplay value? I love doing the chemical plant and railway portion of the game and, in my friend group there's someone that almost solely works on the energy generation part, someone ho loves optimizing the production and another one that builds defenses and weapon and munition crafting lines. I can totally see the same happening in Kerbal with different players focusing on different areas of the game and sharing the results.

 

To add to things as far as I know Factorio doesn't have any kind of way to avoid griefing or competitiveness to ruin a game (we certainly never needed them and never wondered if they exists), you can totally mess with other people buildings, destroy them and kill the players. A well placed nuke can delete a hundred of hours of game time if targeted well, but that was never a problem in over 150 hours I played mostly exclusively multiplayer, and the same goes for Minecraft when I play with my usual group, we regularly have mods that could literally destroy the whole save if used with ill intent but we never even needed to add any kind of saveguards.

[Wubslin]

To everybody who hasn't bothered to read my poorly-communicated chart for how I think a "separate ships" multiplayer could work, I wanted to address some potential problems Brikoleur has been bringing up about the system:

16 hours ago, Brikoleur said:

(1) What if craft or installations occupy the same space?

Every player flying a ship is in their own "present" located somewhere in the game time. If you're tooling around in orbit on Kerbin day 2 and come upon the ghost of some player who was there at the time but is now flying around on day 3, you'll see just that - a ghost of their ship that can be seen but not interacted with like in the Forza Horizon games. If you (maliciously or otherwise) line yourself up to be coincident with a player's ghosted ship and spam the time warp button until you catch up with their present, depending on how the game is designed one or both of you will be telefragged. To prevent griefing it'll probably be the warper who gets telefragged when they chrono-crash into the more up-to-date player, but being able to change that setting in your game as the host could make for some wacky hijinks. Also should be noted, if you and the other player are both warping (say you at 10x, and your "target" at 4x) you'll both be ghosted to each other and no collision will result.

(In this image you would be the blue car, and you would be on the ground or on-orbit next to someone who was here but is now in your future somewhere.)

16 hours ago, Brikoleur said:

(2) What happens to the other players' stuff after the co-op session ends? 
(a) It vanishes back into the void – fair, but in that case, what's the gameplay value of merging timelines over host/guest?
(b) It remains in each player's world – in that case, what happens if the same players merge timelines later again? Is everybody's stuff updated to its new state, or added again? What if in the interim the players have made use of, modified, or built upon the stuff the others left behind – leading to situation (1) basically? 

If you are playing on your friend's game (and they're hosting), and you log off, you vanish from the game in time and space. If someone was floating next to your ship while you logged off, they would see you blink out of existence. If someone later on was playing at that point in the game clock and was watching your ghost, they would also see it blink out of existence. You the logged out player now have a ship at that point in time and space, and if you log back in the next day you'll find your ship still in that time and place, the planets right where they were when you logged off. Your buddy who saw you disappear earlier, has now advanced their local present forward and the moment you log in you'll get to see their ghost floating there (in fact you'll be seeing your buddy as they blinked and stared at the empty spot, and you'll likely see their ghost turn around and move on to do other things.)

15 hours ago, Master39 said:

If the host leaves everybody is kicked out.

This would be the case. It's like a hosted game of 7 Days to Die or something. Normally this model of multiplayer game is best for a few friends to play and will not be conducive to lots and lots of randoson a persistent server, but if the developers ever do release a server then people would be able to download it in order to run such persistent games.

14 hours ago, Master39 said:

Just like a LAN Minecraft game there's you and your 4 friends and one of you hosts the game, maybe the one that plays the most. No strangers, no poopy-heads, just you and  your friends playing and every player has his own space agency/company  and his set of crafts and colonies.
It doesn't have to be competitive and it doesn't have to be everyone on the same exact craft all the time.

By default this would be the case, but you could enable an option that lets randos join in on you.

Anyway, the model I was trying to come up with for how this works is that every player has a "present", and the only people you can interact with are those who are also in your present. In order to catch up with someone in the future, you need to use time warp. Depending on your settings and the number of people in the game, you will automatically exit timewarp and go to 1x speed as you overtake people. If there are fewer than 10 people in a game, this won't be much of a nuisance and would allow people to easily catch up to each other without having to worry about overshooting.

Edited February 23, 2021 by Wubslin

[PlutoISaPlanet]

I feel like it would be like Forza too!

[Guest]

8 hours ago, Master39 said:

The same, but the base/craft you see is semitransparent and you cant interact with it. A screen message asks you to exit the exclusion zone and informs you that that's not a safe spot and, just like when you're falling near the surface, you can't save there and if you leave the game reverts to the last saved safe orbit.

To interact with the base you have to sync up first or ask ownership to the other player (or some lower level of control if you allow the system to be just a little more complex).

Would you think that’s fun, or jarring? Especially if the owner of the base isn’t online at the time.

8 hours ago, Master39 said:

I love Factorio, I also never finished a game alone, I usually play with friends. What's the added gameplay value? I love doing the chemical plant and railway portion of the game and, in my friend group there's someone that almost solely works on the energy generation part, someone ho loves optimizing the production and another one that builds defenses and weapon and munition crafting lines. I can totally see the same happening in Kerbal with different players focusing on different areas of the game and sharing the results.

But KSP isn’t Factorio. You can’t really cooperate on infrastructure if you’re spending most of your time in diverged timelines and therefore can’t use each other’s infrastructure.  Instead you’d be interacting with a bunch of ghost architecture – or, alternatively, stuff that’s spread way across the universe that it might as well exist in separate games. From where I’m standing the former is jarring, not fun, and doesn’t work, and the latter isn’t any different than drop-in co-op where players are allowed to import and export assets (and I think we’ve already established that that’s clearly easier.) And the third alternative which would allow the shared assets to ”really exist” in each player’s timeline would lead to paradoxes, as you realise. None of these options are very attractive.

8 hours ago, Master39 said:

My compromises are what I (not a game designer) can think of on the spot while I'm writing them, I'm pretty sure a team of professional people, with an opening for a "multiplayer engineer", can easily get a little more complex than that as their default "easy solution", and then cobble together a bunch of prototypes to playtest

I would suggest you think about this a bit more. What is the overall objective for gameplay you want to achieve? What are the gameplay implications of your proposed solutions, both positive and negative? What kind of stuff do they need under the hood to work? How much playtesting and tuning do they need to work? 

If I’m parsing you correctly, the overall objective you want to pursue is a Factorio-like experience where a small number of friends collaborate on and share infrastructure. I contend that this is not achievable in a game where players spend most of their time in divergent timelines, and making it work at all (avoiding collisions and paradoxes) is a non-trivial amount of work at all levels (design, implementation, playtesting, QA). It just doesn’t add up. KSP2 isn’t Factorio, and it shouldn’t try to be.

Conversely, drop-in co-op with asset import/export would actually get closer to your Factorio-like experience. Each player could do the thing they specialise in in their world, then drop in on each other’s games to import the stuff they’ve made, where it remains and can be used and extended. If you like, you could agree on further co-op sessions where the original builder of an asset visits to update or extend it; the game could support this by allowing a re-import that overwrites whatever was there before, regardless of its state in the target world. 

Edited February 23, 2021 by Guest

[Guest]

Okay, in light of the previous discussion, here's Brikoleur's proposal for multiplayer in KSP2.

Gameplay objective: Allow small numbers of players (2-10) to cooperate on missions, craft, or infrastructure construction.

Basis: Separate savegames and asset import with drop-in co-op.

Assumption: Every asset (=ship, base, colony, etc) has a unique and persistent root identifier, and is flagged with the ID of the savegame where it was created.

How it plays: 

Soona, Edgar, and Joyce decide to start on a collaborative game of KSP2. Soona will concentrate on comms, Edgar on logistics, and Joyce on resource extraction. Each of them starts off on Y1D1. They agree to sync up on Sunday afternoons. 

On Sundays, they meet up on a server and link up their games. They hit the "Merge worlds" button. All of the assets each of them has created appear in each of their games, in the orbits and positions they occupied in the world of origin, but on the importing game's game date. There is no syncing of timelines, only merging assets. (There's also an "Advanced..." button that lets them choose which assets to merge, if they don't want to merge everything, and a "Merge automatically" toggle that will, from now on, import any assets created by anyone in the group into all of their games as soon as they're built.)

• Any craft in transit between bodies will be imported on a standard low orbit at their starting body (because transfer windows will be lost). 
• The game remembers who created each asset. When re-merging worlds on subsequent merges, each player will only export their own creations, and when these are re-imported, the new version will overwrite the previous one. If the host has modified an imported asset, she will be presented with "Use mine / Use theirs" options.

Following last Sunday's session, Edgar and Joyce decide to do an actual co-op mission together, extracting uranium and setting up a supply line for it. Edgar invites Joyce into his game world. They fly the mission together. In this situation, timewarp is by mutual consent – whenever either of them wants to warp, a flag goes up in the other player's UI; she needs to acknowledge it for the time warp to start. At the end of the session, any changed assets are automatically synced between both worlds.

So summa summarum: each player has their own savegame and timeline, but there's an easy way for them to collaborate on infrastructure by merging the assets they've created between the savegames. They can also drop in on each other's worlds to play co-op missions in real time, with mutually agreed timewarp.

Edited February 23, 2021 by Guest

[Guest]

43 minutes ago, Brikoleur said:

Would you think that’s fun, or jarring? Especially if the owner of the base isn’t online at the time.

It's working, a simple and stupid solution that just works, and you can consistently play with others in a shared saves. It obviously requires organisation and communication between players to interact, but that's just a requirement of playing multiplayer.

 

47 minutes ago, Brikoleur said:

But KSP isn’t Factorio. You can’t really cooperate on infrastructure if you’re spending most of your time in diverged timelines and therefore can’t use each other’s infrastructure.  Instead you’d be interacting with a bunch of ghost architecture – or, alternatively, stuff that’s spread way across the universe that it might as well exist in separate games. From where I’m standing the former is jarring, not fun, and doesn’t work, and the latter isn’t any different than drop-in co-op where players are allowed to import and export assets (and I think we’ve already established that that’s clearly easier.) And the third alternative which would allow the shared assets to ”really exist” in each player’s timeline would lead to paradoxes, as you realise. None of these options are very attractive.

If you're spending most of the time in diverged timelines then why play multiplayer? And again, I said that you can use each other infrastructure, you just have to sync-up and the idea is that the players would spend most of the time synced up and collaborating in real-time on something and then move on together. If someone wants to do a long term mission they can either wait out the transfer time doing other things (a thing that slightly less than a half of KSP players I know already does in single player, myself included) or the player can talk and decide together when sync up again.

If in a group of player there's a veteran that just warps ahead to do Jool missions while his friends are still trying to achieve first orbit he's the amazing person, I'm basing my example on people that want to play together and cooperatively, if you just want to mess with each other you're not going very far in any multiplayer co-op game, in most of them you wouldn't even be able to finish the tutorial.

Factorio works without any kind of protection, and the organization required to manage the factory and make different players lines work at the same speed without draining too much electricity or resources is way more difficult than managing timewarp and syncing up.

And, again, you can get a lot more complex than that (while maintaining an intuitive approach) by implementing a permission system to allow shared use of ground bases from different timelines, something that can get as granular as allowing only for specific docking port permissions or only for some resources to transfer.

 

1 hour ago, Brikoleur said:

I would suggest you think about this a bit more. What is the overall objective for gameplay you want to achieve? What are the gameplay implications of your proposed solutions, both positive and negative? What kind of stuff do they need under the hood to work? How much playtesting and tuning do they need to work? 

If I’m parsing you correctly, the overall objective you want to pursue is a Factorio-like experience where a small number of friends collaborate on and share infrastructure. I contend that this is not achievable in a game where players spend most of their time in divergent timelines, and making it work at all (avoiding collisions and paradoxes) is a non-trivial amount of work at all levels (design, implementation, playtesting, QA). It just doesn’t add up. KSP2 isn’t Factorio, and it shouldn’t try to be.

Factorio is just a easy example of how a co-op game works, Factorio-like is not the right definition, the right one is "Co-op multiplayer", I don't want KSP2 working like Factorio, I want KSP work as a co-op game, and being able to play the game from start to finish with friends is pretty much the starting point of a co-op game.

"You can't build where another player has already build something without syncing up" Is barely a requirement worth mentioning and it's not the huge problem you're trying to picture. Replace "syncing up" with "asking for permission" and you have the system by which most if not  all building co-op games in the last 10 years or so work with. 

A friend invites you to play co-op on a (public) Minecraft server with him, if you log in when he's not there you most likely won't be able to interact with his buildings without being given permission by him first. That doesn't make Minecraft multiplayer pointless or too difficult to implement (these safeguards are mostly implemented by third party modders).

 

So, to recap:

• You can't go back in time, only timewarp ahead.
• You can't interact with another player craft if you're not synced up
• You can't build were another player has already build (IRL timeline).
• You can remain synced up and have simultaneous warps and real-time interaction.

These are at a modder level of complexity to implement (provided that you already have the multiplayer portion working), if you want to go a little fancier you can add a permission system to manage ownership of ship and bases, but that's not strictly required to work if we're talking about a group of friends playing together in an organized manner.

[Wubslin]

15 minutes ago, Master39 said:

So, to recap:

• You can't go back in time, only timewarp ahead.
• You can't interact with another player craft if you're not synced up
• You can't build were another player has already build (IRL timeline).
• You can remain synced up and have simultaneous warps and real-time interaction.

This. Anything else like hosting, the number of players, griefing rules etc. is just the minutiae. If there's going to be a "let's both fly ships" type of KSP then it's going to be at its core like this, with the "each person has their own present" situation I've described and the use of ghosting when players encounter the pasts of other players currently in the future.

1 hour ago, Brikoleur said:

here's Brikoleur's proposal

But doctor, I am Pagliacci!

[Guest]

34 minutes ago, Master39 said:

So, to recap:

• You can't go back in time, only timewarp ahead.
• You can't interact with another player craft if you're not synced up
• You can't build were another player has already build (IRL timeline).
• You can remain synced up and have simultaneous warps and real-time interaction.

These are at a modder level of complexity to implement (provided that you already have the multiplayer portion working), if you want to go a little fancier you can add a permission system to manage ownership of ship and bases, but that's not strictly required to work if we're talking about a group of friends playing together in an organized manner.

Whereas in my solution:

• You don't need to worry about timewarp at all, you can do it at your own pace. There is no past or future state to worry about, only the present.
• You can interact with all assets, including craft or installations created by other players, regardless of whether you're synced up with them at the time.
• You can build anywhere you want, including over craft or installations created by other players (although when you sync up again, you'll have to choose which version to keep, yours or theirs)
• You can remain synced up and have simultaneous warps and real-time interaction.
• You don't have "ghost buildings," blocked-out areas where you're not allowed to build, you're not forced to warp to the latest point in time of your peers which might screw up your interplanetary/interstellar missions, you have a simple, unambiguous way to resolve conflicts, and it's simpler to implement.

There's nothing to prevent you from playing a game together from start to finish: just enable auto-sync and go wild, dropping in on each other's world whenever you feel like it. The only real difference with your solution is that each player's game will be set to a different in-world date (with planetary configurations to match of course). 

What is the advantage to forcing all players to sync up to the same date? After all they can still do that in my solution if they want to. There could even be a button in the sync UI to do that, if that's something players want – this effectively ends up in exactly the same place as your proposed solution, without much of the complexity.

I contend that my solution is just plain better. It'll give you a better gameplay experience, more flexibility, and it's less complicated to make.

Edited February 23, 2021 by Guest