Jump to content

Players controlling Kerbals


Recommended Posts

    In talk about multiplayer, there's been a lot of talk about how many players there will be and how extensive interactions will be between them, but not a lot of definition of what exactly a player is, in-game. 

    My take on it: kerbal nations! Essentially, instead of controlling crafts and colonies, players control a population of kerbals. This opens up the possibilities of collaboratively building and managing crafts and colonies, as well as connecting probes, in an in-game way. I think the idea of acting as the systems officer on a ship while someone else works out the trajectories, or vice versa, is engaging. 

Each player would get a population of kerbals on Kerbin that would have a minimum growth rate (to avoid failure states) and as they explore and begin creating colonies and reaching boom events, their population would grow across all of their colonies and the KSC. Whatever these kerbals control, the player controls. Here is how it would work in a few different situations:

 

Crewed Craft:

    A player controls anything their kerbals control. For example, if a kerbal is in a pod with control over the ship, the player can control that ship, but if a kerbal is in a passenger module, they cannot control the ship, only that passenger cabin, which probably just means the lights.

A Kerbal in a pod doesn't mean control over everything though. For example, the mk. 2 lander can doors only open from that part (if there are people in there), or research can only be toggled from the lab module. A single player won't have any problems with this because all seats on the ship are under their control, but multiple people will have to coordinate if they are sharing a ship. 

This can feed into other gameplay with parts that are more advanced or specialized, like a pod that can plan constant thrust trajectories or act as a probe control point. One player might be able to steer the ship but not pilot the rovers down on the surface. 


Colonies:

    The same principle applies for colonies as for crafts. Whenever there is a module that performs a specific role (think BAE, VAB, logistics module, etc.), a player needs at least one kerbal in it to perform that role or have that control. This allows for colonies where other players can put their kerbals (after a supply route for example) but not accept new trade routes or launch their ships, unless you give them access to that. 

Less important than the general idea, some things could change with more kerbals. If building things takes time, more kerbals means faster building or more simultaneous builds. This would work for a single person as well, as an understaffed VAB would operate slower. I'd also like to see building crafts done by VAB, so when you enter a VAB, you load into that workspace, and if another person is using it, you can see and add to their work. Loading in crafts would load them into that VAB specifically, and so on. 

Last thing: when the population increases, there are a few options. Either only the player that triggered the boom event has the population increase, or players would see an increase in proportion to the number of kerbals they have at the colony. The second one would invite collaboration, as people would benefit from sharing colonies with their friends and getting more boom events. 


Probes:

    Each probe has a modifiable "control point" which is the colony or craft that controls that probe. Like in KSP 1, probes will use a network to reach their control point, but they'll use only the network of a whitelisted player/players. This is to encourage people to either collaborate or develop multiple relay networks.

I'm sure you have guessed it by now, but if multiple people have access to a control point, then the probe is controllable by those people. At any time, the control point can be locked, but otherwise, any player that controls the probe can change the control point. It is probably best to lock control to a big colony so that there is no chance that someone transfers control over to their little orbiting station full of grungy hacker kerbals. However, if that player wasn't on the relay whitelist, they might lose control as well, since the player with the whitelisted relay network is no longer controlling the probe. 


Science/Data:
    I'm not settled on one method, but either each player gains the full science reward (assuming they can transmit the data), the science is split, or each player needs to bring their own set of experiments to run. I'm leaning towards each player getting the full science reward. And physical samples will either go to the person who recovered them (or took them, if there were multiple), or split once recovered. Let me know what you think!


Hijacking and Piracy:

    As has been mentioned, this system may not fit stock, but I'm leaving it in because it has applications beyond piracy (such as rescue) and avoids lots of annoyance. With that said...

Spoiler

This system is kept relatively peaceful because kerbals are a relatively peaceful (if death-defying) race. Essentially, you need a weighted majority to move someone else's kerbals. Moving kerbals is strongly balanced in the inactive player's favor, so be prepared to bring a crew of 10 to rescue 1 stranded kerbal. 

Each part which can house kerbals has a "security multiplier", which can become very high for late-game pods and even higher for colony control modules. This multiplier makes it harder to hijack a craft. Each kerbal within each part is weighted by that multiplier, so one kerbal might count for either 0.5 or 20 kerbals, depending on the part. If a player wants to move another player's kerbals, they need an unweighted number of kerbals to match the weighted kerbals of every other player in that craft/colony combined

As an example, if someone is running an airplane service, every kerbal in the big passenger bays has a 0.5 multiplier, so if there are 100 kerbals being transported, the player needs more than 50 kerbals docked to that craft to be able to move those passengers. Add a Mk. 3 pod (4 kerbals) with a multiplier of 5, and you need 70 kerbals to move those passengers. Finishing at a colony and recovering the craft dumps all the kerbals back into the colony pool, where they can be moved and reassigned collaboratively or, if the player has majority in that colony, alone. 
 
    So, what happens when a craft is pirated? The player who has the weighted majority can move any kerbal in the ship/colony, even if it does not belong to them. However, they cannot EVA them. This way, any kerbals transferred without consent will find themselves still in a ship capable of getting to a safe colony - even if that is a pirate ship. Also, some colony modules will have very high multipliers, so a group of 20 kerbals in a secure module cannot be dislodged by 500 kerbals in the colony, allowing that player to keep the rest of their kerbals safe from others' control. 

Edited by t_v
Link to comment
Share on other sites

I agree that the piracy is a little bit out of tune with the stock experience, but why not include it in the suggestion. Still, if you find some way to make piracy more kerbal-like, it would be a pretty cool piece of gameplay to explore, and offers more than just piracy (rescue missions would get easier because you could evacuate kerbals from a stranded craft)

Edited by t_v
Link to comment
Share on other sites

    SciMan brought up a good point in Multiplayer discussion about what happens in long periods of inactivity or when a person leaves a server. Personally I think that when a player is off the server, things should happen like normal (their craft keep flying and are still controllable, their population still expands with boom events, their colonies still do supply missions) but when the player is removed from the server (by kick, ban, blacklist, or otherwise) their kerbals are distributed randomly across all other players. This will almost inevitably make all their colonies into community colonies, as all the players have full access to it, and their biggest ships will also become controllable by everyone. The other players can then choose to sort out their kerbals and kick other players' kerbals off their ships, but it is only if they feel like it. If the kerbals in the colonies undergo boom events, the new kerbals belong to the active players permanently. that way, if the banned player returns, they will find their kerbals sort of in the state that they left them, albeit maybe a bit scattered across the system. Annoying for sure, but this is just a rough sketch of an idea.

 

    Thinking again about forcibly moving kerbals, I think there is a better solution that is more in line with Stock: In colonies, you can assign seats to other players' kerbals and some kerbals in their population will fill them, so you can give other players control easily. In ships, you can shift your kerbals around and if there is an open spot in a command pod, you can get into it. To actually steal the ship however, you will need to recover the ship at a space center or colony, at which point the other players' kerbals will disembark and live in the colony (Hospitality before everything! Also, it gives the other player more population)and you can relaunch the ship with a new crew, effectively stealing it. Once again, it is a little out of tune with stock, but it is an improvement.

Link to comment
Share on other sites

It's hard to say without knowing what type of multiplayer hosting Intercept intends on using for KSP2. Most players will be playing cooperatively and it shouldn't matter who controls which Kerbals when someone is offline. People who play competitively will need different rules. I don't want to speculate on those rules as I would never play competitively. 

Link to comment
Share on other sites

On 1/18/2022 at 7:47 PM, shdwlrd said:

If you get rid of the piracy and forced take over of other people's crafts and buildings, this is a decent outline to how multiplayer could work with resource sharing and co-op builds.

Aww! I can't go full Pirates of the Carribean?

Link to comment
Share on other sites

  • 6 months later...
×
×
  • Create New...