KSP2 multiplayer: a competitive space-race team-based MMO with trade and contracts

[Vl3d]

Spoiler

The main idea is that players can control either speed of time or speed of movement. Both of these are unacceptable in a multiplayer setting. So in the real time bubbles all gameplay time should be controlled by the server. Period.

So, of course, the main issue is: how do you explain the universal time jump when syncing to the multiplayer real time bubbles for all observers without using crutches like FTL? Easy, do not show Universal Time, instead focus on mission time, syncing star system configuration (everything on rails is cyclic). Time becomes an ordered sequence of actions and milestones players have reached.

The most fundamental problem is the refusal of players to give up on controlling time zoom in multiplayer. These concepts are absolutely incompatible because of paradoxes. Separate them with a journey planner and desyncing from MP when going to (deep) space and all problems are solved.

Spoiler

It's a hybrid system. Keep in mind that there would be 2 types of real-time multiplayer bubbles that can be exited at any time through time-warp and re-entered at will (choosing to sync to server):

• celestial body + atmosphere / low orbit
• custom sized (for space stations)

Let me give you a proper example. Let's say players A and B are doing a race to the Mun.

• Phase 1 - Kerbin multiplayer bubble:
  • both players set the Mun as the target.
• Phase 2 - exiting real-time multiplayer and going into enhanced single-player mode while in Kerbin SOI
  • players time zoom while on the pads to the appropriate launch window (or whenever they want)
  • players launch the rockets (each one sees the star system configuration that is correct for them - it is generally different for each player if they do not launch simultaneously)
  • players use time zoom whenever they want (because they desynced from multiplayer)
• Phase 3 - orbital maneuvering:
  • let's say the players achieve orbit and they want to do a rendezvous for any reason (get so close that they enter each other's real-time bubble)
  • keep in mind that each of them see a different star system configuration on their local PC, meaning that also the orbital position of each player is desynced (but can be shown on-rails with orbits visible in map view of each player according to server updated orbital parameters, each player craft moving as in a locally controlled Master Warp solution where speeds are proportional to the player controlled time zoom factor as shown in OP))
  • each of them set the other players vessel as target, perform appropriate maneuvers (they are still in single-player, although they see the other person's craft in map view, it is a local rendition of the on-rails parameters, calculated according to each players local time and updated if another player changes orbit)
  • when they get sufficiently close to each other they enter their respective small real-time multiplayer bubble, at which point the star system configuration would ideally resync to one version for both players (so it's not daytime for one and nighttime for another - meaning the dependent resources like electricity sync to server controlled values)
  • players do whatever they want in multi-player (like dock or fly together)
• Phase 4 - burning for the Mun and coasting:
  • player A decides to leave, sets the correct target, departs the real-time multiplayer bubble
  • player B sees this in real-time, player A moves at normal speed because he is rendered on player B's PC using the on-rails values of player A's current orbit
  • B decides to leave also, but burn more to get to the Mun faster
  • B sets the Mun as target, plots the maneuver nodes to arrive faster than A, burns
  • remember, A and B are now in single-player mode on their journey to the Mun, each controls time zoom as they wish
• Phase 5 - arriving in Mun orbit:
  • Desynced in the real world - player A arrives at the Mun in 10 minutes of real gameplay time, player B goes AFK for 2 days and comes back to the game:
    • of course, in the real world, each player arrives whenever they want - this presents us with a paradox - if A arrives first in the real world, he should see in map that B was actually first in-game, but there is no one there to do the actual orbital insertion burn because B is AFK. So the game should know how to automatically perform the burn and insert B into a stable orbit as B planned before exiting the game.
    • A arrives and syncs to the Mun real-time multiplayer bubble, sees B is already in orbit
    • A does the landing
    • when B comes back to the game after 2 days, he sees he stayed in orbit while A landed.
  • Synced in the real world - players continue playing in the real-world, arrive at roughly the same time
    • both players sync to the Mun real-time multiplayer bubble, do a race to see who lands first

As you can see, there are problems with:

1. syncing the solar system configuration for all players when they enter a multiplayer bubble (can be hidden / playtested / maybe ignored)
2. correctly updating other players craft orbital positions in the map view rendered on the local PC when in single-player mode (but this should be calculated locally depending on the on-rails parameters for their crafts (that would be updated by the server), but is a source of trouble even if time zoom accelerates movement for all players, as AFK players should be held in a cyclic state like in orbit or landed and their crafts ghosted (unable to interact with))
3. syncing resources (should a player be able to warp to accelerate resource extraction or maybe extraction should be a continuous real-time action instead)

All these can be managed. The most important thing is that time travel paradoxes and warp-drives are avoided at all costs.

Just adding some thought experiments.

Oh, and thank you PC Gamer for caring about the idea of a persistent universe multiplayer KSP2.

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

[t_v]

14 minutes ago, Vl3d said:

persistent universe multiplayer

Everyone cares about persistent universe multiplayer. Persistent universe means that the universe is not wiped for any reason, and only a server shutting down, crashing, ending, or losing its data can end that. I want to have a persistent universe in my multiplayer, which is why my system allows for and is designed around that. So is Local Bubble, voting, and leapfrog. 
 

For the second thought experiment, problems 1 and 3 are the same issues my system has. @Pthigrivi mentioned that the biggest thing Local Bubble has is physical consistency throughout time. I agreed with that (although I had some questions about representing past craft that might be inconsistent), but I’m wondering: how would you manage syncing the solar system configuration when coming out of a Journey, and how would you manage syncing the ship back into the large multiplayer server? Just have it fade in, or something else?

[Vl3d]

41 minutes ago, t_v said:

how would you manage syncing the solar system configuration when coming out of a Journey, and how would you manage syncing the ship back into the large multiplayer server? Just have it fade in, or something else?

I wrote some ideas in the OP based on the idea that when landed / when on the launch pad / when in orbit (on-rails) are cyclical or timeless states. Maybe its as simple as a "sync to multiplayer button" or maybe going to the Space Center or another building would update the orbital configuration to be synced to the one experienced inside the celestial body multiplayer bubble.

When you think about it, you only care about a specific solar system configuration when doing map view things (like encounters). To allow you not to care about the non-continuity between missions the game can hide the Universal Time and allow you to easily warp to launch window when starting a new Journey / Mission. There are a lot of creative ways to hide the sync.

Spoiler

How do we prevent the visual shift in map view or in normal view when syncing to the real-time multiplayer bubble?

When you arrive at your target the server sets the configuration you play in and politely hides any sudden jumps using the places where events are cyclical and time is flexible: while in orbit, while on approach, while landed. Some solutions:

• in map view: getting spun around in orbit (like a reverse warp-to-transfer window)
• in map view:  limiting view of other celestial bodies by zooming in close to my craft and then zooming out
• in normal view: seeing your craft third person and correctly positioning the sun and moons during time-warp to target.
• in normal view: seeing an arrival-at-target cut-scene
• in map or normal view: if going directly into a suborbital trajectory without circularizing (entering atmosphere or landing) there might be a jump in the positions of the moons or day-time/night-time. To sync you (and only you) see an animation of some day / night cycles after landing. The players already in the multiplayer bubble see you arrive in real-time.

IMPORTANT PS: Consider that in-game Universal Time is actually irrelevant, because player actions and what is built actually change the game state and represent the progression of time. So it does not matter how fast or often you warp, what limits progression is the amount of time spent by the players designing and building (Universal Time is paused in the VAB). So a player just starting out can find himself in a universe where other players have already expanded. He will still have to go though the exploration / tech progression steps. So starting at T 0 years or T 10.000 years does not impact gameplay. Which means that you can just hide Universal Time and put an emphasis on the amount of things players have built. And hiding Universal Time allows for a lot of hidden syncs.

Edited November 17, 2022 by Vl3d

[t_v]

Right, so it is kind of a sleight of hand where time is shifting around relative to different people, similar to my system, the discontinuities are shown but made less jarring. I also don’t think it will impact gameplay that much (transfers, rendezvous, and most other operations work well, and pretty much the same as other systems) but there isn’t a way to make real-time player actions physically consistent in in-game time unless you force the difference between real time and in game time to be accounted for via time warping to synchronize. 

Edited November 17, 2022 by t_v

[Vl3d]

10 minutes ago, t_v said:

unless you force the difference between real time and in game time to be accounted for via time warping to synchronize

Well yeah, at the end of the mission / journey you can also sync. But I would give up on the idea of Universal Time. It's mission time and public server time! (pun intended)

Edited November 17, 2022 by Vl3d

[Vl3d]

So because I stumbled upon the idea to have recorded actions / milestones / events for missions (which would allow returning to the past after finishing a mission), I have now realized that the recording system would allow to have a centralized timeline for massive multiplayer. It would be available for in-space gameplay and it would allow time warping at will. Server could optimize sending you only the events that you can observe using a actions LOD system. You would see all recorded actions of other players in space as you play / warp. This combined with the hybrid multiplayer bubbles (big ones close to celestial bodies and small ones around space stations) would be a general workable solution for KSP2 multiplayer.

@Nate Simpson I thank you and the team from the bottom of my heart for the epic work on the technological foundations of KSP2. I might be wrong about this, but just thinking about the possibility of having a persistent universe where we all play and build together is amazing. Thank you!

Edited February 5, 2023 by Vl3d

[Vl3d]

So.. during the interview with Matt Lowne, Nate said that multiplayer will be: 4 agencies on Kerbin with max. 4 players each. There will be asynchronous gameplay, but also concurrent (so you can fly and drive together). Agencies will either be allies or competitors. It seems grieving will be allowed.

So, for now, the 1000+ players MMO part of my suggestion is not possible. Hope the rest of it will be fun when we get multiplayer!