Design Goals of Multiplayer

[nightingale]

There's been lots of discussion over the past few months about multiplayer (mainly centered around how to timewarp). But a lot of these discussions seem to be putting the capsule before the booster and make big assumptions about what the design goals of this hypothetical multiplayer is. So I figured I'd throw out a few questions to ponder how little we really know about what Squad is doing for multiplayer.

1. How many players can be involved in a multiplayer game? It would have to be at least two, otherwise it's not really multiplayer. Is that the maximum? Could there be 4? 8? 100? Will there be a fixed limit?
   
2. Does multiplayer happen synchronously? Must all players be playing at the same time? If nobody's around, does time still move forward?
   
3. Is there a dedicated server? Or is it just synced between the players participating? (The answer here can greatly change the options/answers for some of the other questions).
   
4. Can I join a game in progress? As a new player? As a replacement for an existing but not present player?
   
5. Assume ownership of any vessel belongs to the player that created it. Who owns the resulting vessel when two vessels dock? Is it shared? What happens with ownership when we undock?
   
6. Is it cooperative or competitive by nature? Does everyone have their own little KSCs (possibly at different locations), or is it all part of one space program?
   

Note that I'm not really looking for answers to these (unless any of these have been answered by Squad before).... I'm just trying to toss out the questions that I expect Squad would've had to think about before embarking on this effort. If there's other design questions that you believe are important, let's hear them!

Personally, this is what I expect to see happen, as it what would be the least effort to add to the current game is:

1. Multiplayer is not hosted, players arrange their own games. Games are limited in player numbers (2 being by far the most common and most manageable).
   
2. There is one space program that everyone partakes in. Everyone has equal access to all vessels (ie. no concept of ownership).
   
3. There is no concept of different time frames. There is global timewarp, probably with some sort of voting system.
   
4. Minimal Kerbal Alarm Clock type functionality will probably also get added so that you know when your probe is about to hit the Mun.
   
5. Going interplanetary is only done once you've gotten the okay from other players to warp ahead 3 years.
   

Beyond, that I'd expect to see features for chat/voice chat, view-only mode to see what other players are doing and that's about it. People will do their own space races, with the honor system for not messing with each other's vessels. Waiting is a thing that will happen when one person is in the middle of a launch and another in the middle of going somewhere (instead of waiting, this is the time you go design something in the VAB).

Anyway, that's what I think multiplayer's gonna look like, after thinking about the most likely answers to the above questions. All the multi-timeframe stuff just gets way complicated way too fast (both from a development standpoint and a player standpoint), and the issues it causes are worse than the issue of forced-player waiting.

[clivman]

Agree with everything here, besides the no ownership part, you should be able to choose if it's a joint mission or your mission

[TMS]

If I had to wait 20 minutes to perform an interplanetary burn, then God-knows how long to warp the transfer period... I don't think I'd ever bother.

Voting for time warps? I can see that getting very old, very quickly - especially if you're outvoted mid-ascent.

[nightingale]

Agree with everything here, besides the no ownership part, you should be able to choose if it's a joint mission or your mission

I think that would be more interesting - I just predict that it won't happen (at least in the first release we get). It's a far simpler approach to have everyone part of the same space program and cleanly sweep away all issues related to ownership. But that's just a prediction.

If I had to wait 20 minutes to perform an interplanetary burn, then God-knows how long to warp the transfer period... I don't think I'd ever bother.

Voting for time warps? I can see that getting very old, very quickly - especially if you're outvoted mid-ascent.

I probably shouldn't have said voting with the implication of majority wins - I would expect everyone would need to agree to timewarp and be able to timewarp. So it's more like the other players would be annoyed waiting for you to finish getting to orbit. Which is why I think you're going to see 2,3, and 4 player multiplayer games.... not something where you've got 100 people running 100 space programs.

[Captain Sierra]

I think we're going to see some kind of desync/instancing system like DMP where, by initiating time warp, you break the synchronous and have to reengage it later.

Squad has talked about having a server module functional, so the possibility of dedicated servers for KSP I believe is very real (I think it would be highly advantageous for all these collab projects on the forum).

I don't expect any kind of server browser. Likely it will be direct-connect with a bookmarks tab or something, much like Minecraft. Though I'm curious to see how this works from a non-server-based multiplayer perspective (which would no doubt be a huge selling point; open your game to MP for a bit to show off your station to a buddy or something). If you need to open ports and have static IP just to host a non-dedicated multiplayer session, that will be a huge detractor.

KSP, by dint of being a hard game, will likely not have many problems with trolling (smashing stations, draining fuel, etc.)

[TMS]

KSP, by dint of being a hard game, will likely not have many problems with trolling (smashing stations, draining fuel, etc.)

Are you kidding me?

First thing I'm gonna do is launch a booster into someone's ISS replica.

[nightingale]

I think we're going to see some kind of desync/instancing system like DMP where, by initiating time warp, you break the synchronous and have to reengage it later.

Squad has talked about having a server module functional, so the possibility of dedicated servers for KSP I believe is very real (I think it would be highly advantageous for all these collab projects on the forum).

Interesting - I must've missed that, it was actually just in this week's devnotes:

Ted (Ted)

Finally, I’ve been working with Max to finish working out our new server specifications with Multiplay so that all our online services are on more stable and managed servers.

I still don't think that means we'll have desync/instancing, more that using Multiplay is far simpler than having to deal with players connecting peer to peer with NAT and other network fun. But that's just my guess based on gut feel.

I don't expect any kind of server browser. Likely it will be direct-connect with a bookmarks tab or something, much like Minecraft. Though I'm curious to see how this works from a non-server-based multiplayer perspective (which would no doubt be a huge selling point; open your game to MP for a bit to show off your station to a buddy or something). If you need to open ports and have static IP just to host a non-dedicated multiplayer session, that will be a huge detractor.

Looks like multiplay does Minecraft hosting, so you may not be too far off here.

KSP, by dint of being a hard game, will likely not have many problems with trolling (smashing stations, draining fuel, etc.)

You sir, are an optimist, or have far greater faith in humanity than I.

[Frozen_Heart]

KSP, by dint of being a hard game, will likely not have many problems with trolling (smashing stations, draining fuel, etc.)

I'll keep my stations with armed fighters docked... just in case.

[WinkAllKerb'']

(my own advice about multi remain this one: try to think about multi game mechanics to avoid as much as possible the nowdays recurent "pew pew me see me grief" wich to tend to be real anoying on random server)

Aside that, nothing at all against mutlti implementation but this point remain really annoying too often and really require some brainstorming imho.