KSP Multiplayer

[razark]

4 hours ago, Enceos said:

Every object is interactive...

So, I can interact with objects that don't exist, then?

Simply put, objects that don't exist at the current time can affect the current time. 

 

Can you see the paradox in your solution now?

[Northstar1989]

14 hours ago, razark said:

So a universe full of non-interactive objects?  Hrm...

 

You warp to day 100 again.  You now launch a space station into a geostationary orbit above KSC.

I'm on day 5.  I launch a station into a geostationary orbit above KSC.

Which station exists?  I'm on day 5, do I see a station that will not exist for 95 more days?

On Day 5 you would see a shadow copy of the station where it currently is on Day 100, obviously.  You would not see where it was on Day 5 at all.

I don't get why people can't wrap their head around this- it's really not that difficult to prevent any paradoxes by only making vessels interactable in the time-frame occupied by their owner- never one before or after it.

To dock two craft, both users would have to exist in the same time-frame, and then one user would have to "transfer" ownership of their craft to the other player, or else the two users would be locked into a shared tome-warp until their craft undocked (if one user logged off or lost connection during this shared warp, ownership of any docked craft would automatically transfer to the other player).  Obviously great trust would have to be involved in anything to do with docking, as it should be.

Asteroids would need to be "claimed" by a user in order to interact with them, obviously.

Any offline user's craft would probably need to become non-interactable and disappear, or continue on as a shadow-copy at some pre-determined rate of time warp (meaning the craft would actualize at a new time and location when the user returned).

 

These rules may seem a little draconian and limiting, but would prevent any time-paradoxes.  Basically, there would be no way for two craft to interact in any way except when their owners were in the same time-frame, and asteroids would need to be "claimed" before a user could interact with them.

 

Regards,

Northstar

 

 

6 hours ago, razark said:

So, I can interact with objects that don't exist, then?

No, no you can't.  Stop trying to unnecessarily complicate things.  If you're in a different time-warp than another vessel,  it's non-interactive.  Period.  You have to sync to interact.

6 hours ago, razark said:

Simply put, objects that don't exist at the current time can affect the current time. 

No, they can't.  If an object isn't synced to your time-bubble, it can't affect you in any way.

The rules for vessels are obvious- they would belong to the player who launched them unless ownership were transferred.  Docked vessels would permanently lock two players into a shared time-warp (which would he required to dock the vessels in the furst pkace) until one player took ownership of both craft or logged off (which would automatically transfer ownership to the other player).

Offline players' vessels would disappear from the map, except surface bases.  Surface bases could leave a shadow copy when the player logged off, preventing anyone from landing another vessel in that exact spot (placing a vessel in the same spot would disable a player's time-warp, and delete their vessel if they logged off).

Asteroids would be non-interactive until "claimed" by a player (they would probably only spawn in once claimed- before that they would just appear on a list alongside size and orbital characteristics in the Tracking Station).

 

Draconian rules are the answer.  And in any ambiguous cases the game would just auto-delete offending vessels it could not figure out what to do with, and provide affected players with an error/warning message informing them of this.

 

Regards,

Northstar

[razark]

26 minutes ago, Northstar1989 said:

On Day 5 you would see a shadow copy of the station where it currently is on Day 100, obviously.

Why?  It's Day 5, and the station does not yet exist.  Why should I be able to see it?

26 minutes ago, Northstar1989 said:

You would not see where it was on Day 5 at all.

I would hope not, since it did not exist on day 5, and therefore could not have been anywhere.
 

26 minutes ago, Northstar1989 said:

I don't get why people can't wrap their head around this...

I don't get why people don't see why this is a paradox that should not be allowed to exist, and can easily be prevented.  If I can see/interact with the vessel before it exists, then the paradox occurs.

 

26 minutes ago, Northstar1989 said:

To dock two craft, both users would have to exist in the same time-frame...

Why?  Player One exists on day 5, and can dock with and interact with craft independent of what time frame player Two is in.  Locking what player One can do based on what player Two does in the "future" is a paradox.

 

26 minutes ago, Northstar1989 said:

time-frame occupied by their owner

What if a craft has no "owner"?  What time frame would it exist in then?

 

26 minutes ago, Northstar1989 said:

Any offline user's craft would probably need to become non-interactable and disappear, or continue on as a shadow-copy at some pre-determined rate of time warp (meaning the craft would actualize at a new time and location when the user returned).

Craft popping in and out of existence, or jumping from place to place based on who is logged on is not really a solution.

 

26 minutes ago, Northstar1989 said:

These rules... would prevent any time-paradoxes.

No, they explicitly don't.

 

 

 

 

10 minutes ago, Northstar1989 said:

No, no you can't.

If day 5 is affected by an object that doesn't exist until day 100, then... it's a paradox.

 

10 minutes ago, Northstar1989 said:

You have to sync to interact.

What if the object exists on day 5 and day 100?  Can I interact with the Day 5 version, or does the day 100 instance determine what is/isn't "real"?

 

10 minutes ago, Northstar1989 said:

No, they can't.  If an object isn't synced to your time-bubble, it can't affect you in any way.

So, I can place a base on day 5 in the exact same location as someone else places a base on day 100?  What happens on day 100, when the bases begin to exist in the same location?

 

This system does allow paradoxes to occur.  Arguing otherwise is simply ignoring the facts.

Edited February 21, 2017 by razark

[Northstar1989]

41 minutes ago, razark said:

Why?  It's Day 5, and the station does not yet exist.  Why should I be able to see it?

So you know where those vessels will be if you sync to them.  And in the case of surface bases, or any landed vessel, to create an active-denial zone so that you won't place another vessel in the same spot (any attempt to sync time-warp when you have vessels overlapping with a shadow copy would refuse to allow you to sync time-warps, and provide an error message telling you to move your vessels first).

41 minutes ago, razark said:

I don't get why people don't see why this is a paradox that should not be allowed to exist, and can easily be prevented.  If I can see/interact with the vessel before it exists, then the paradox occurs.

You have failed to show any paradox.  You can *see* a vessel without syncing time-warps, where it currently is for the player who owns it.  But you CANNOT interact with it, *UNLESS* you sync time-warps, and even then only so long as both your time-warps are synced.  You can never sync with offline players.

41 minutes ago, razark said:

Why?  Player One exists on day 5, and can dock with and interact with craft independent of what time frame player Two is in.  Locking what player One can do based on what player Two does in the "future" is a paradox.

No.  Player One cannot "dock with and interact with" any craft except his own, and those of a player he is actively time-synced with.  I've already stated this repeatedly.  What Player Two does on no way affects Player One, *unless* the two agree to sync/merge their time-warp bubbles.

41 minutes ago, razark said:

What if a craft has no "owner"?  What time frame would it exist in then?

That's a clearly nonsensical statement.  There is no way for a craft to not have an owner, as there is no way for a vessel to ever exist in KSP (even in single-player) without being launched by a player.  The player who launches a vessel owns it right up until the moment he/she should choose to transfer that ownership to another player.

 

41 minutes ago, razark said:

Craft popping in and out of existence, or jumping from place to place based on who is logged on is not really a solution.

It's a solution- just not one that you want to accept.  That doesn't matter, it's a workable solution, regardless of whether the prospect of (shadow-copies of) craft suddenly "appearing" when a player logs in sounds appealing to you or not.  (If it really bothers you that much,  you could disable the ability to see other player's shadow-craft until you wish to- or just not play multiplayer.)

It works fine for me- many MMO's already do this with player characters appearing or disappearing as players log in or out.  Or "warping in" when moving between "sectors" (which are really entirely independent instances, much like the time-bubbles I discussed- with the exception players don't control who enters them) in space-MMO's, such as BGO or STO.

It's also occurring all the time on the quantum level in the real world- with "virtual" particles spontaneously popping in and out of existence in any vacuum, particularly near black holes and such...

 

41 minutes ago, razark said:

No, they explicitly don't.

Yes they do.  You've failed to find *any* exceptions or paradoxes they lead to- only "I don't like these rules, so I'm going to change them to ones I like that *do* allow paradoxes, and then say the original rules allowed paradoxes."

The rules, as I stated them, allow no paradoxes as they allow no interaction of vessels owned by different players except when two players who are online *agree* to sync time-bubbles.

If you can't interact with another vessel in another player's past or future, you can't create any paradoxes.  Anything you do to another player *necessarily* has to occur in his present moment, which he has to decide to let you enter in the first place...

Edited February 21, 2017 by Northstar1989

[Enceos]

@Northstar1989 You're my soulbuddy
I'm glad to find a person who understood all the intricacies of the MP model I described.

[Northstar1989]

44 minutes ago, Enceos said:

@Northstar1989 You're my soulbuddy
I'm glad to find a person who understood all the intricacies of the MP model I described.

What you described is basically how Dark Multiplayer works, if I understand how it works correctly- with a few minor tweaks/fixes.

Speaking of DMP, I was actually just watching some Germans play it on YouTube, in Career Mode (which I had no idea worked in DMP- though they dodn't seem to share a Space Center or budget, sadly...), and they seemed to be having no issues with it (of course, I only speak a bit of German, so I could have mussed something) except with a Mun satellite conteact failing to complete for some reason... (the bug seemed to be unrelated to DMP anyways)

Generally my only objection DMP is that it's a little-used mod few have heard of, programmed by amateurs- and since it is a mod it may stop being updated at any time.  I think SQUAD desperately needs to move on multiplayer- though I fear they've silently backed away from it, just like Gas Planet 2...

 

What I want to do with multiplayer works perfectly with the model you outlined.  I would like to split up missions into different parts with ownership transfers of vessels between...

For example carrying out a Stratolaunch style mission where one player takes the control of the rocket at stage separation while the other flies the rocket to orbit- and then another still takes control of the payload once it reaches orbit and docks it with another vessel they own, while the first player flies the upper stage back to the KSC for a propulsive landing.  I.e. cooperative play for speed and efficiency, so say a 3 hour mission can be achieved by 4 players each playing for 45 minutes, handing off vehicle ownership in between...  I have no use  for "together alone" gameplay, I believe the true function of multiplayer is cooperation.

 

Edited February 21, 2017 by Northstar1989

[Enceos]

@Northstar1989 Yeah, I also dream about such a co-op multiplayer game where we can multitask SpaceX style rocketry, Strato-launches, Motherships and other stuff.

I believe the automatic ownership transfer on stage separaion/docking/undocking can be realized through an ownership flag on each command part (Pods/Propes).

There should be a Captain [host, master] flag, which gives control and time warp of the whole vessel. And there should be an Assistant [co-pilot, dockee, client, whatevs] flag, which gives control of the vessel to a particular player after separation/undocking of that command part. The Captain will assign players to command parts. Assistant players may undock if their vessel is docked, decouplers should probably still be ruled by the Captain. KSP should detect and automatically assign the flag to all adjacent command parts (not separated by decouplers or docking ports).

During docking players should decide who's gonna have the Captain flag. Two vessels with Captain flags shouldn't be able to dock, one of them needs to choose to be an Assistant [dockee].

If Player 1 owns a vessel which is docked to a station of Player 2, Player 1 will be able to sync timeframes and switch to the station to undock his vessel.

These are the basics, this automatic ownership flags idea will need more thought.

 

P.S. My big problem with DMP is a bad data stream sync, constant vessel blinking and overall shaky behavior.

Edited February 21, 2017 by Enceos

[SpaceYorkie]

IIRC I remember reading an article about KSP having multiplayer sandbox and career modes in the future.

SOON^TM

[razark]

4 hours ago, Northstar1989 said:

And in the case of surface bases, or any landed vessel, to create an active-denial zone so that you won't place another vessel in the same spot...

To me, this sounds like a player is blocked from doing something by what a player in the "future" has done.  While I'm not docking or colliding with, or EVAing a Kerbal to, it, the fact that it will be there affects what I can do at that location "now".  I'd call that an interaction.

There's also the fact that a player cannot interact with objects that should be able to interact with, because another player has already interacted with it in the future.

 

4 hours ago, Northstar1989 said:

There is no way for a craft to not have an owner, as there is no way for a vessel to ever exist in KSP (even in single-player) without being launched by a player.

Rescue contracts.

 

4 hours ago, Northstar1989 said:

It's a solution- just not one that you want to accept.

Pardon me.  I meant that it is not a paradox-free solution.

[Enceos]

7 minutes ago, razark said:

To me, this sounds like a player is blocked from doing something by what a player in the "future" has done.  While I'm not docking or colliding with, or EVAing a Kerbal to, it, the fact that it will be there affects what I can do at that location "now".  I'd call that an interaction.

There's also the fact that a player cannot interact with objects that should be able to interact with, because another player has already interacted with it in the future.

To me this sounds like you're trying to play multiplayer alone with a strong unwillingness to sync the timeframe with another player.

9 minutes ago, razark said:

Rescue contracts.

If a player meets an unowned object, that object should become a property of that player with following consequences (existence only in this player's timeframe).

11 minutes ago, razark said:

Pardon me.  I meant that it is not a paradox-free solution.

You still haven't given a valid example.

[razark]

1 hour ago, Enceos said:

To me this sounds like you're trying to play multiplayer alone with a strong unwillingness to sync the timeframe with another player.

Nope.  My proposed idea has all players in a synced timeframe all the time.  I specifically stated that this would work because all players would be working together.

"Multiplayer alone" sounds like it more closely fits you model.

 

1 hour ago, Enceos said:

You still haven't given a valid example.

A player cannot interact with an object that should exist and be interactive in their timeframe, because a player in the future has interacted with that object.

 

 

Anyway, this discussion is going nowhere.  To-may-to/To-mah-to, Po-tay-to/Unwillingness to admit a paradox exists.

[Enceos]

@razark It's a matter of ownership, if a Player 2 warps ahead he takes all his vessels with him to the future. Player 1 has to warp to the future as well to be able to interact with vessels a Player 2 owns.

If Player 2 takes ownership of a particular asteroid on day 80 in his timeframe, Player 1 can no longer meet that asteroid at day 40. Because that asteroid was taken to the future and ceases to exist in the 1^st Players timeframe.

Paradox avoided. The time has passed and Player 1 needs to catch up, he cannot change the past of the Player 2.

[Arugela]

I still think cooperative multiplayer is the easiest to initially implement. And it can be done in a fairly seamless way.

1. Everyone works on the same team. The games originator is where the game loads from and the universe swirls around. Everyone else is added like a tree to the same person and their pc calculates from his perspective relatively. AKA they revolve around him(Of it's changed to the KSC and everyone revolves around it.). He is the KSC head hauncho per say or the team leader. Players can control multiple vehicles(one player controling a node. Nodes are any object from kerbals to drone controls etc. Only controled from here stears unless flying is made more complex) or share view from the same vehicle/Kerbal...(AKA the same view ability in every multiplayer match game. Look but no control) Maybe all things in game are directed towards a kerbal or Unmanned node.(It already is basically.) You then can go first person from the kerbal or third person(literally what exists already.) The primary reason for this is to make mutliplayer seamlessly started from single player. Then a person can open up slots in single player and then add slots for others and open it to internet connections. Maybe even during play. but any single player can be turned into/turned off from multiplayer at will. It would have a guild permission system to control things if the owner doesn't want free reign for everyone.

2: Warp simply works by checking everyone's warp status. It takes minor coordination to do properly on the players part via in game chat or indicators of other for warp status. Once all people are in warp it actually warps. Everything else is live. But you wait for warp. There can even be an ability for the owner(or anyone given permission) to force warp on others. Or even override entirely like in single player. Everyone(the whole game) would go in warp. This allows an override warp and the ability to put AFK or annoying people in warp to stop anyone from hijacking warp. Simple. In teh case of multiple warp speeds the slowest take priority. As long as their isn't massive lag everyone should be fine. And if you need to do things with lag you could wait and do it when others are offline. Again, a simple way to work around issues you already would need to. Just another part of organization needed to doing any cooperative game. As I like to call it, it's literally mission control being simulated better.

3. Mission control functions added. This is like the window for showing what ships are in space but from a time standpoint and not a where/space standpoint. This helps you see from mission control(or any tab in space.) when a new mission is comming and when you need to do it. This could go with the ability to use more waypoints that are simply for time. Add 1 hour say to a warning. You could use the physical existing path system to point and add a waypoint and say slow down here. then if you are warping and any time event happens it stops and alarms you. you can have the ability to permanently ignore objects etc to simply organize everything using the current in game functions with minor additions. Then in multiplayer you simply play a little more like you were mission control land the team in space simultaneously.

4. There can be a generic warp setting that is new that says any warp speed. AKA a ready button. this then lets the warp be controlled by whatever speed is lowest of the other warpers/players. This way accidents can't happen. Then when everyone is done everyone can warp at max speed to the next destination. Or pause and log out. All players entering the server enter at a ready state. This stops or minimized interuptions of the gameplay when players enter the game.

5. As indicated earlier any match can be made multiplayer. A single player can be opened and closed to other player. Full ban functions exist etc. So can only entering certain names(white/black lists) and passwords if desired. At any time a single player game can be opened and a multiplayer closed to single player again where it has no external connections opened in any way. Just like now. There could also be a virtually resourceless lobby system like in many games that help find game. There could be an option to set your game in an official lobby system. Maybe options for other non official lobby systems. These could be non hosted and files are shared from the host. Unless hosting only needs a single file from the head player initially or something and it's easy enough.

6. People can go to any ship/node in the game including KSC like in single player at any time. Unless the server/game owner changes this. This allows complete functionality. You just have to share warp. which if you are working together should not be hard. You just use any logistics in game to think out in a very minor sense what you are doing. Alarms systems will help automate it.

7. A controlling player can always have the ability to force others to do things for warp access or control of a node. Heck two pilots being able to control from a double cockpit can work also. Stubborn player or disconnect can be take control via the second cockpit or control of Drone control node). The head person can even give others this ability via guild like permission system in most MMO's. Any potential issues with flow of play can be dealt with via this hypothetically. Along with a little forethought on players part. In fact having to play a little more like a NASA mission headquarters could add some more fun to the game. Especially if more depth is added to what you can do once you get in space. One of the most needed things in the game.

8. Whenever two people are not in range their individual system load and process the areas separately(Albeit from the owner or KSC as center.). As the game does not need to now that I'm aware of. This should make multiplayer a very simple change to the current game. It is already mutliplayer from this perspective. But with only one person currently.

It's cooperative play. Everyone is working together to do missions. But can split up however they want to do stuff. There would be a single (or whatever files currently exist) that are updated out of range to show where it is going. Then if everyone's in range there is a more intensive update. The main file can be on the owners computer or designated system(literal server/file location control; this is needed to not kill ssds etc.) for updates. Then single and multiplayer are basically multiplayer/server like and are the same thing. Multiplayer would literally be single player but with multple people and warp being custom to the user. The waits are minimal if the players are donig stuff simultaneously. People can always be told to put one mission on standby to warp. Unless and until oxygen and lifesupport are added. But that would be part of the mission logistics to start with. And mutliplayer would make it easier to not run out.

I could imagine docking being much more pleasant in multiplayer. Unless someone is being a jerk. 8)

Edited February 21, 2017 by Arugela

[Tex_NL]

22 minutes ago, Arugela said:

I still think cooperative multiplayer is the easiest to initially implement. And it can be done in a fairly seamless way.

[snip]

I could imagine docking being much more pleasant in multiplayer. Unless someone is being a jerk. 8)

Or as others have called it: "synchronized warp".
And it doesn't even have to be cooperative. Competitive works just fine too as long as warp is synchronized.

And there won't be jerks, grievers or people AFK. "Synchronized warp" only works in very small teams. If you go AFK you log out (or activate an AFK feature automatically agreeing to all warp requests). And if you misbehave in my game you get a single warning, the next time you get a size 9 suppository. You get the boot, you're out.

Edited February 21, 2017 by Tex_NL

[Sgt Doomball]

Time warp would mess up synchronization if there is a way point.

[Arugela]

If you never unsych it there is no problem with waypoints.... Therein is illuminated 99% of the problem with multiplayer!

You can also minimize the waiting to almost nothing. The flow of action would not stop warping that much of the time. Only when really needed. You have planes/rockets going to destinations that will take 100 years... You can warp through most of that unhindered. Just have to stop and do other ques earlier if you don't put in orbit. Which you already have to do potentially. It would play exactly like it does now!

Waypoint do not mess up warp if everyone is using the same warp. If you mean as an alarm system yes it would stop the warp, but that is the point! It would not desync warp however. You would only use them on things, if you are smart, that need to be done. AKA before a burn or something else important. Something you want to get your attention. It would not however desync the warp as everyone would come out of warp together. It would affect everyone at the same time. It's using the concept of a que just like it does now in a natural non purposeful sense.(AKA time progressing)

But, if everyone can freely move around everyone can go to the ship being stopped. Or sit and wait while they do something else. it's a matter of choice.

Or as others have called it: "synchronized warp".
And it doesn't even have to be cooperative. Competitive works just fine too as long as warp is synchronized.

And there won't be jerks, grievers or people AFK. "Synchronized warp" only works in very small teams. If you go AFK you log out (or activate an AFK feature automatically agreeing to all warp requests). And if you misbehave in my game you get a single warning, the next time you get a size 9 suppository. You get the boot, you're out.

 

This is why I don't understand whey they have not done synchronized multiplayer yet... It would be easy in theory to implement in a basic sense to get out the window. And do a lot of what people would want. You can still hypothetically race and do most competitive things in a cooperative setup. I wonder if they have worked on it that much or if there is another technical issue they ran into.

Edited February 21, 2017 by Arugela

[Tex_NL]

16 minutes ago, Arugela said:

This is why I don't understand whey they have not done synchronized multiplayer yet...

Because it is not a priority.
And I must say I am GLAD it is not a priority. There are MUCH more important issues to fix first.

[Arugela]

50 minutes ago, Tex_NL said:

Because it is not a priority.
And I must say I am GLAD it is not a priority. There are MUCH more important issues to fix first.

 

Maybe it would draw in more players and get them more money to hire more people. would it be that hard to test when they have extra time. Aren't there a lot of tools out there they can use to get it up in a basic sense? Maybe even free ones.

Edited February 21, 2017 by Arugela

[Tex_NL]

Just now, Arugela said:

 

Maybe it would draw in more players and get them more money to hire more people.

Or somebody screws up and things get implemented incorrectly or work not as expected. As a result people will hate it and generate a lot of bad press.
It has happened before. We're still seeing the negative backlash from a failed console port.

[Wjolcz]

14 hours ago, natsirt721 said:

War Thunder has you there.

It doesn't. No vehicle editor and inability to fly all over the planets and many, many more things including FMs being all over the place, pay2win and the effing dumb research system.

Edited February 21, 2017 by Veeltch

[Northstar1989]

On 2/21/2017 at 6:55 AM, razark said:

To me, this sounds like a player is blocked from doing something by what a player in the "future" has done.  While I'm not docking or colliding with, or EVAing a Kerbal to, it, the fact that it will be there affects what I can do at that location "now".  I'd call that an interaction.

That's not an interaction- not in the physics or timeflow sense anyways.  It's trchnically a restriction on a player's behavior outside of physics, just like time-warping does not actually affect the laws of nature, only speeds them up.

So it's not a paradox, just possibly annoying.  Think of it as the other player havong filed a property purchase on that offworld territory years ahead of actually arriving there if you will.  Yes, you can't leave a vessel clipping througj another player's base and then sync time-warps, but this is a restriction that is consistent with time-flow and creates no paradoxes.

On 2/21/2017 at 6:55 AM, razark said:

There's also the fact that a player cannot interact with objects that should be able to interact with, because another player has already interacted with it in the future.

That's not a paradox- just a game restriction, no different than anti-griefing rulesin Minecraft or property clsim flags on ECO or 7 Days to Die, really, to cite some common examples.  Only instead of being necessary to stop somebody from destroying your house, it's necessary to prevent a physics paradox of diverging timelines that would make multiplayer impossible.

On 2/21/2017 at 6:55 AM, razark said:

Rescue contracts.

Would be treated the same as asteroids.  They could not be interacted with, perhaps would not even appear in the game, until a player had "claimed" them.  With a contract this is particularly easy- the vessel would just be auto-assigned to whoever accepted the Rescue Contract.

Actually, this is already how Dark Multiplayer ALREADY handles Rescue contracts- one of the German players I watched the other night actually carried one out, and it spawned the vessel in as "his" vessel.

 

On 2/21/2017 at 6:55 AM, razark said:

Pardon me.  I meant that it is not a paradox-free solution.

Pardon me, but you clearly don't understand what constitutes a paradox here.  A paradox is any course of action that would break physics- that would lead to a pair of diverging timelines where a vessel is no longer in place for a player to interact with after he has already interacted with it at some future point, for instance.  It is NOT some annoying game restriction, like being unable to interact with a vessel until you have synced tome-bubbles with the owner, or only being able to sync by mutual player agreement...

As such, no paradoxes are possible under a scheme where all interactibe objects belong to a player, and no onject can be interacted with except when synced to the sametime-bubble as the owning player.  I don't CARE if you like the game restrictions this implies, that is not, and was never, the point.  The point is it's possible to have a physically and chronologically-consistent multiplayer in which players can time-warp at will.  It doesn't matter a bit whether you *LIKE* the game rules that make this possible, just like a board game doesn't care if you like its rules- you simply have to accept them.

 

On 2/21/2017 at 8:29 AM, razark said:

A player cannot interact with an object that should exist and be interactive in their timeframe, because a player in the future has interacted with that object.

 

 

Anyway, this discussion is going nowhere.  To-may-to/To-mah-to, Po-tay-to/Unwillingness to admit a paradox exists.

Your notion of "should" is based on reality, rather than what makes for an enjoyable game.  Just like in real life, there's no law of physics that stops you from burning a person's house down- but in Minecraft, anti-griefing protections will simply stop you from lighting a fire on another player's property...

None of these game rules are paradoxes.  They are simply restrictions on behavior that allow for an enjoyable multiplayer experience, the same as anti-griefing protections in Minecraft.

Frankly, it doesn't matter whether you like these rules, they are the only way to create a functioning multiplayer mode free of paradoxes.

I am also left to ask- have you ever PLAYED a serious board game?  (Something more involved than Monopoly)  ALL games have rules you cannot break in order to allow for an enjoyable multiplayer experience, or to make the game possible in the first place- even if reality does not always have these rules.

It is simply part of the limitations of the medium of a game- if you don't like it then don't play the game.  They are NOT PARADOXES.  You already accept many such rules when you play KSP whether you know it or not...

 

 

Razark, your entire concept of a "synchronized multiplayer" already exists as a simple variant of the system me and Enceos outlined above.

Ifa al players in a server were to sync their time-bubbles into one, and then by mutual agreement (or a server setting preventing it) none of them were to BREAK that time-sync for any reason, but instead advance the time-bubble together at all times, then you have a synchronized multiplayer right there.

The only difference between the system you propose, and the one myself and Enceos outlined, is that players are not FORCED to share a single time-bubble in most cases.  This allows players to either play more independently, ot to branch off of a single mission and perform different components if it at different rates.

So, for instance, if one player is landing a lander on Laythe and exploring it while the other performs a series of gravity-assists around Jool's moons to prepare for the return-voyage back to Kerbin, the players don't have to perform these actions in the same time-bubble.  They can just perform them in different time-bubbles, but sync them back up at some pre-determined departure date to make a return to Kerbin...

 

On 2/21/2017 at 11:12 AM, Tex_NL said:

Or as others have called it: "synchronized warp".
And it doesn't even have to be cooperative. Competitive works just fine too as long as warp is synchronized.

And there won't be jerks, grievers or people AFK. "Synchronized warp" only works in very small teams. If you go AFK you log out (or activate an AFK feature automatically agreeing to all warp requests). And if you misbehave in my game you get a single warning, the next time you get a size 9 suppository. You get the boot, you're out.

Synchronized multiplayer would already exist as a subset of the independent time-bubble concept.

In fact it would probably just be a matter of ticking a checkbox when setting up a server- so that instead of each player starting at Day 1 and having the ability to sync up their time-warp with the other players as they so wish, ALL player start in the same time-bubble (new players might join starting at Day 45, for instance) and are not allowed to leave the shared time-bubble at any time.

Your option rigidly restricts player's actions, mine gives them freedom and flexibility.  But within the subset of cases where all players on a server have synced up to a single time-bubble, functionally they are the same.

On 2/21/2017 at 11:42 AM, Sgt Doomball said:

Time warp would mess up synchronization if there is a way point.

Your statement is nonsensical.  "If there is a way point"- what is that supposed to mean?

There is no way to mess up the system described by myself and Enceos, plain and simple.

Players sharing a time-bubble would time-warp together, along with all of their vessels.  Players in different time-bubbles would be unable to interact until they had sync'd time-bubbles with the player(s) they wished to interact with.  In no cases are there physics-breaking paradoxes due to the system of vessel ownership and restrictions preventing interactions with any vessel in another time-bubble.

 

 

On 2/21/2017 at 11:43 AM, Arugela said:

This is why I don't understand whey they have not done synchronized multiplayer yet... It would be easy in theory to implement in a basic sense to get out the window. And do a lot of what people would want. You can still hypothetically race and do most competitive things in a cooperative setup. I wonder if they have worked on it that much or if there is another technical issue they ran into.

Dark Multiplayer already exists as a more-or-less functional multiplayer.  The main problems with it are low-quality data-syncing for players sharing a time-warp, on a level that would be completely unacceptable, say, for an FPS, even though once you remove all difficulties associated with time-warp (because the players are already synced) the data-management challenges are basically the same...

Thus it's likely, knowing SQUAD, that they took the "There's already a mod for that!" altitude, even though multiplayer really is a basic functionality that should have been integrated into the game ages ago- the same way that some KER/MechJeb functionalities like the ability to display the available Delta-V for a craft really should have been integrated into the base game ages ago- and the devs hinted at doing so, then just abandoned the idea...

The truth is, SQUAD is often a rather unfocused game-development company that doesn't really seem to know what they are doing well enough most of the time- which is unsurprising, considering they were originally an advertising firm with no experience in game-development.

Edited February 21, 2017 by Northstar1989

[Sgt Doomball]

Squad did start as a marketing company.

[natsirt721]

3 hours ago, Veeltch said:

It doesn't. No vehicle editor and inability to fly all over the planets and many, many more things including FMs being all over the place, pay2win and the effing dumb research system.

Touche.

[Northstar1989]

5 hours ago, Tex_NL said:

Or somebody screws up and things get implemented incorrectly or work not as expected. As a result people will hate it and generate a lot of bad press.
It has happened before. We're still seeing the negative backlash from a failed console port.

If you never attempt anything great, you will never achieve it.

The reality is, KSP is already slowly fading away from the public consciousness, DESPITE its console ports rather than because of them.  The only way they are going to get the game more attention, and more sales, is by doing something fundamentally transformative like implementing multiplayer.

Localization and console ports expand their *potential* market, but they will never acctually sell to that potential until they get more media attention.  That being said, if they set up localization and console-ports first and THEN add multiplayer, they're likely to bring in more media attention and sales in the long run- as the media blitz adding multiplayer will generate is kind of likely to only be a one-time thing...

6 minutes ago, Sgt Doomball said:

Squad did start as a marketing company.

Exactly.

Edited February 21, 2017 by Northstar1989

[CaptainTrebor]

The problem with multiplayer is that whatever solution people may think up, there will always be a compromise.