Co-op Idea

[Red Iron Crown]

Just now, Alshain said:

So what?  We aren't talking about 20 player servers here, we are talking about small co-op games with 2-4 players.  There are many options to mitigate the issues and those that cant are not going to be common.  Even when they do haapen, it's just one of those quirk of KSP you would have to accept.  There are already worse incongruties in the game.  None of this is a reason that multiplayer can't happen.

Where did I say it was a reason for multiplayer not to happen? I'd appreciate it if you didn't put words in my mouth.

[Alshain]

11 minutes ago, Red Iron Crown said:

Where did I say it was a reason for multiplayer not to happen? I'd appreciate it if you didn't put words in my mouth.

Fair enough, you did say warp sync issues was an option.  But again, many of the percieved issues can be mitigated with creative design.

...But my point is all of this is something the server operator should choose.  There is another option than what you listed.  You can vote to timewarp together.  So you can still have timewarp and no sync issues.

Edited April 18, 2017 by Alshain

[razark]

2 hours ago, Alshain said:

You can vote to timewarp together.

That falls under the "wait" category.  Someone will have to wait until everyone else is ready to timewarp.

[Alshain]

15 minutes ago, razark said:

That falls under the "wait" category.  Someone will have to wait until everyone else is ready to timewarp.

Well, the "wait" category would be no timewarp at all, ever.  There are 4 distinct game mode possibilities there that a server operator could choose from.  None of them are similar enough to be under the same categories.

1. No Warp

2. Warp on vote.  My suggestion here would be to give everyone a warp to here option (or not right now option) and then warp to the closest time selected among the players.

3. Warp if the admin says so.  This is similar to 2 but with other players be damned.

4. Instancing (DMP style)

 

There are probably other modes that could be thought of.  The first 3 there would not be that hard to implement (I mean on top of the multiplayer itself).  The last one is a bit more tricky obviously.

Edited April 18, 2017 by Alshain

[razark]

5 minutes ago, Alshain said:

Well, the "wait" category would be no timewarp at all, ever.

If all players are timewarping at the same time, is there someone that will have to wait at least part of the time to do what they wish to do?

 

5 minutes ago, Alshain said:

There are 3 distinct game mode possibilities there that a server operator could choose from.

Possibly, but the point is that any of the three (or their multiple sub-types) all require either that someone waits or allows sync issues.

Edited April 18, 2017 by razark

[Alshain]

Just now, razark said:

If all players are timewarping at the same time, is there someone that will have to wait at least part of the time?

 

Possibly, but the point is that any of the three (or their multiple sub-types) all require either that someone waits or allows sync issues.

You are talking about concepts though, I'm talking about actual selectable modes that a game operator could choose.  I came up with a 4th option that isn't waiting or sync issues in my edit above.  Of course, it may not be enjoyable for some people

[razark]

1 and 2 are "wait".

4 is "sync issues".

 

3?  That's just "wait until the admin decides to warp".  (Or "wait until someone actually wants to play with this admin".)  Still falls under waiting.

 

 

8 minutes ago, Alshain said:

You are talking about concepts though, I'm talking about actual selectable modes...

Yes, because all "modes" fall under some concept.  It's a lot easier to talk about the basic concepts than to describe every possible multiplayer timewarp handling system.

[Alshain]

2 minutes ago, razark said:

Yes, because all "modes" fall under some concept.  It's a lot easier to talk about the basic concepts than to describe every possible multiplayer timewarp handling system.

Of course it's a lot easier to talk about the concepts.  You are glossing over a lot of the talk.  If you say there is just wait and sync issues then you are leaving out many possible options.

Edited April 19, 2017 by Alshain

[razark]

4 minutes ago, Alshain said:

You are glossing over a lot of the talk.

Just the parts that are completely irrelevant to the point under discussion.

[Alshain]

12 minutes ago, razark said:

Just the parts that are completely irrelevant to the point under discussion.

And the parts that don't make it sound deliberately misleading as if there were only two options.

Look, we can go back and forth on this all day long, but the real one and only truth is all the good developers quit Squad after 1.2 released so no major feature is coming to this game.  That includes multiplayer.  So the whole endless discussion of what multiplayer could be is irrelevant anyway.  Truthfully I think this whole suggestion forum has outlived its usefulness at this point and is just a remnant.

Edited April 19, 2017 by Alshain

[razark]

There's a difference between two options and two categories of options.  Do you understand at least that much?  If not, then this whole discussion has been worthless and can end here.

However, if you do, I will continue that all the options fall into one of the two categories.  Perhaps the problem is that you've been discussing the options, while I have been discussing the categories?

 

8 minutes ago, Alshain said:

...the real one and only truth is all the good developers quit Squad so no major feature is coming to this game.

I am personally waiting to see what quality the work they release has before I declare the imminent death of the game.  Only then will I be able to judge the abilities of the devs currently working for Squad.  The fact that they are making a  DLC expansion kind of points out that major features are still a possibility.

[Alshain]

The game isnt dead as long as it is playable, it's just not going to have any major development efforts.  It doesn't take developers to make models and do localizations, but they don't have the necessary dev talent to do multiplayer anymore.

[Razorforce7]

What about the following scenario. A real time universe!

Just don't have any time warp at all. Just have a single savegame with 1x normal time rate.
Basically your sharing a server with up to xx amount of players and everything you do is in real time.

Have a secondary app that you can access at all times using your smartphone with which you can track your own vessels.
It will list details about your current vessels, their orbits, speed and other ballistic properties. One of which is the time to get from where your now to your target which is i.e. the Mun's periapsis.
If it is 2 hours you know you will have to get in front of your computer before the 2 hour are up to execute a next maneuver in order to not overshoot.
Obviously you'll choose to limit yourself to the Kerbin system as you wont want to wait for longer distance travels. But I still think this is a good idea.
It could turn the Kerbin system into a cooperative and dynamic system.
And you'll have to keep logging in over the week to further progress with your buddies.
 

[Green Baron]

The only solution i see for the time warp issue is that, when a player has performed a maneuver he/she can enter a time for his next "move" at thus give the server or whatever program synchronizes the hint to what time it can warp forward. If no player plans an action, then the server may warp to next player's action in the list.

Crafts should be built offline and imported for launch.

Problems:

- One player drives a rover for hours. Everybody else then had to wait or do similar things.

- F9. Reload would lead to rollback issues for other players who for example had to perform a maneuver again.

- The server accidentally warped past a launch window because a player forgot to announce an action. Next window in 10 years.

 

If you have better ideas ... i am not a developer ...

 

... and i share @Alshain's concerns about available manpower.

 

[Alshain]

@Green Baron That's basically the voting idea, but landed vehicles wouldn't be subject to it, neither would people building.  They might get the option to vote, but they couldn't choose a spot to warp unless they switched crafts.  That way, if they had something else in progress they could make sure it wouldn't conflict.

The basic procedure would be this:

Person A decides he wants to warp his craft closer to Duna.  He chooses a spot along his trajectory to warp to.

All others get a popup letting them know the request.

Person B is building a Craft, he has nothing unstable so he clicks yes.

Person C is driving a rover, rover's don't care what time it is so he clicks yes (note: while time warping all rover controls will be momentarily suspended due to lack of physics, the rover motion must be stopped to continue)

Person D is on course for Minmus, he chooses a warp to point along his trajectory.

Person E is also building but he has a craft on course for the Mun.  He switches to that craft an chooses a "warp to" point in his trajectory.  His warp point is the closest in time so the system initiates warp and stops at his chosen location.  The others have to try again after he has completed whatever he needs to do to make his orbit stable.

 

That's a scenario with 5 people just to give the options.  Though I wouldn't expect a co-op game to have that many conflicts.  In most cases you would be doing things together.

[IllyrianTheGreat]

21 hours ago, Red Iron Crown said:

Imagine two players decide to race to catch a particular asteroid. Player 1 quickly plots a modestly fast intercept, burns, and cranks up the warp. Player 2 more carefully plots a faster intercept, burns, but warps less aggressively. In game time terms, Player 2's intercept happens sooner, but Player 1 arrives sooner in real time due to more aggressive timewarping, then claws and moves the asteroid. Under DMP's timewarp scheme, the asteroid will not be there when Player 2 gets there, because Player 1 has already interacted with it and Player 2 will need to sync up with that subspace. So, even though Player 2 plotted the better intercept and would have gotten there faster in game time terms, Player 1 wins the race through more aggressive timewarping which allowed him to get there faster in real time.

and

It doesn't have to be an explicit race, either. Imagine this scenario:

Player 1 and Player 2 are playing with spaceplanes supported by an orbiting fuel depot. Player 1 quickly ascends to orbit and decides to do a Mun flyby (using timewarp), and when returning to Kerbin docks with the depot and drains the fuel from it. Player 2 plays around sightseeing in the atmosphere before ascending to orbit, taking more real time but less game time than Player 1's flyby and docking. He then attempts to dock to the propellant depot. Is fuel available for Player 2 there? Should there be?

These sorts of issues are inherent to asynchronous warp, there's not a technical solution for it. Synchronous warp means waiting, most of the time. So we're back to my statement: Sync issues or waiting, choose one.

 

Ok, those are interesting scenarios, but  I have some ideas that could work (but I have no idea how unity works and that it would be possible in this game engine).

1. Asteroid scenario.
If game engine predicts player 1 should be near asteroid sooner in game time than player 2, then game can create player owned sphere of influence and all objects (resources, asteroids or whatever will be added in future features) would have locked owner for this player 1.
Lock should work only during player 1 travel, when he arrive to that location owner lock is gone and everybody can grab for example that asteroid.
As result it would work as real life travel, if you can find faster trajectory to capture asteroid then nobody can get there faster than you do and take your resources.

2. Space station with fuel
Same mechanics as in first scenario can be used. With player made stations/bases game can have ownership and you can dock only to crafts you are allowed to, so two "hostile" players won't be able to steal resources from each other.

3. What if people would want to break my space station with some cheap craft?
Multiplayer should have reputation assigned to our global accounts hosted on official servers. In one thread I wrote some idea for multiplayer career mode. Where we would be able to start as new space agency and play until we ran out of funds, game would need monthly fee for kerbals and life support to drain funds.
Once we lost all our funds we start new agency (with inherited reputation) with new budget and zero science points. Many interactions between players can be solved same as in eve online, for example resupplying space stations can be solved by putting contracts with giver order, reward and deadline. Once player 2 fulfil contract he gets reward (funds) plus reputation.

It would be pure space race mode, with other people, for more funds, more science and faster and cheaper exploration with possibility of failure.

 

 

 

[Wjolcz]

The only co-op I could see working in KSP is everyone sitting in one ship as crew members. The commander/pilot warps and flies, the engineer does the engineering (for example boost the signal for additional EC demand) and the scientist does whatever scientists do (like, I don't know, actual experiments and useful measurements for example?). Everyone would be able to leave the ship but EVA'd crew members would mean no warping can be done unless they are all in one ship again.

Edited April 19, 2017 by Veeltch

[monstah]

On 18/04/2017 at 8:37 PM, Alshain said:

My suggestion here would be to give everyone a warp to here option (or not right now option) and then warp to the closest time selected among the players.

I would play under these restrictions.

[Toriatrix]

I see only one proper solution.

Agreed warp like paradox games has.

Player A wants to warp forward in time, and presses the time warp button. Player B finishes whatever he's doing and also presses the time warp button. And we have time warp x2. 

Any player should be able to cancel time warp at any given time. And any player could do all functions at base like research, upgrades, shipdesign and so on regardless of what time warp is Active.

The instances thing does create all sorts of time paradoxes..  and that means No reverting also..

Also an option for Coop mode and competitive mode would be fun. Where in Coop mode, you could share research, reputation,  kerbals, ships and base buildings, ect. But in competitive mode you would have different of base location and not shared reseach, rep, kerbals,  ships, ect. You could infact sabotage your friendly neighbours launchpad..  anyone see a cold war becomming hot? Space race? Star wars?!! 

 

Make this a 20usd DLC and i would buy a 10 pack for my friends!  

Edited April 21, 2017 by Toriatrix
Addon.

[Alshain]

1 hour ago, Toriatrix said:

Make this a 20usd DLC and i would buy a 10 pack for my friends!  

Make it a DLC and it will be crap.  It's nothing to do with the cost either, Multiplayer has to be integrated into the core code.  That's really why DMP is so buggy, it doesn't have access to what it really needs to make things run smoothly and as a mod likely never will (FYI, this isn't the so called 'sync' issues I'm referring to, which are logical issues in the system, What I'm talking about is the ability to keep two clients in sync properly without duplicating craft and causing incorrect explosions). 

The problem is, if it's integrated into the core code, it really can't be sold separately like an addon could.

Edited April 21, 2017 by Alshain

[Red Iron Crown]

3 hours ago, Alshain said:

The problem is, if it's integrated into the core code, it really can't be sold separately like an addon could.

Not that I particularly endorse this approach, but there have been games with zero day dlc that is included in the main game download and merely unlocked by purchase. 

Or similarly, the core code of KSP supports plug in mods but the free demo of it does not. 

[Alshain]

17 minutes ago, Red Iron Crown said:

Not that I particularly endorse this approach, but there have been games with zero day dlc that is included in the main game download and merely unlocked by purchase. 

Or similarly, the core code of KSP supports plug in mods but the free demo of it does not. 

True, but those games have DRM.  I doubt there is a way to control a separate purchase like that without it.

[razark]

5 hours ago, Alshain said:

The problem is, if it's integrated into the core code, it really can't be sold separately like an addon could.

If the DLC includes a new executable with the needed code to replace the one in the standard game, why not?