Jump to content

Recommended Posts

41 minutes ago, Brikoleur said:

You don't need to worry about timewarp at all, you can do it at your own pace. There is no past or future state to worry about, only the present.

You can't warp back in time is not "worring about timewarp" it's just how KSP works.

 

42 minutes ago, Brikoleur said:

You can interact with all assets, including craft or installations created by other players, regardless of whether you're synced up with them at the time.

That means that you're reintroducing all the paradoxes and griefing problems that seemed to be such a big deal just 3 posts ago.

 

42 minutes ago, Brikoleur said:
  • You can build anywhere you want, including over craft or installations created by other players (although when you sync up again, you'll have to choose which version to keep, yours or theirs)

Which means that only one player can build in one place at a time, you just deal with collision manually instead of having a system that just says to you "this place is occupied, build your colony 500 meters on the left" or "sync up with player [x] and ask perms to interact with his base*".

 

*you can also manage bases and infrastructure by saving the time of the last edit done to them, at that point you can ask me to use my LKO base and, since I edited it 3 days back in my timeline but only 4h in your future, when I give you permission you only have to sync up tose 4h, not all the way up to me. As I said you can get a lot more refined with the minutiae of this system, I'm just trying to keep it as simple as possible for the sake of discussion.

 

44 minutes ago, Brikoleur said:

You can remain synced up and have simultaneous warps and real-time interaction.

Which is, as I said when starting this discussion, the default "not dealing with the problem" starting point.

 

46 minutes ago, Brikoleur said:
  • You don't have "ghost buildings," blocked-out areas where you're not allowed to build, you're not forced to warp to the latest point in time of your peers which might screw up your interplanetary/interstellar missions, you have a simple, unambiguous way to resolve conflicts, and it's simpler to implement.

A manual system to resolve conflicts that wouldn't be there if the game doesn't allow you to build multiple building in the same spot. 

 

59 minutes ago, Brikoleur said:

The only real difference with your solution is that each player's game will be set to a different in-world date (with planetary configurations to match of course). 

Which means teleporting planets or being forced to sync up, but in a weirder way, up to the closest point in which the Kerbol system configuration matches the one of the other player (I don't know how often the Kerbol system goes back to its starting configuration, and I don't want to guess the number, but I bet that's not a low one)

 

And all of that only becomes exponentially more bothersome and harder to manage for every player you add.

Maybe a good system to merge single player games as a starting point, not one that allows you for a dedicated multiplayer run with friends, if you don't want to manually solve all the conflicts every time you want to play multiplayer with friends you have to manually prevent them. 

You're basically regressing to playing mostly in single player and having the ability to merge saves to do a short "everybody follows the slower player" kind of multiplayer session, after you've manually dealt with all the possible conflicts that may arise manually.

That's barely considerable "multiplayer co-op" and more akin an automated merging system for the forums shared saves projects.

 

1 hour ago, Brikoleur said:

and it's less complicated to make.

Unless you're not interested in multiplayer at all and you're just trying to advocate to dedicate the least amount of effort to it to "save" those resources for other parts of the game (which is a moot point anyway since they have hired some dedicated devs) I assure you this is not a problem, I've had more complex code being written for a relatively small (2-300 players) Minecraft server (a heavily customized and rewritten from scratch version of towny made to work on top of Forge at a time in which most plug-ins couldn't).

Link to post
Share on other sites
1 hour ago, Master39 said:

You can't warp back in time is not "worring about timewarp" it's just how KSP works.

By "not worrying about timewarp" I meant simply that my system doesn't force you to timewarp at all, when syncing up. You can, if you want to, but you don't have to. At no time have I advocated reverse timewarp.

1 hour ago, Master39 said:

That means that you're reintroducing all the paradoxes and griefing problems that seemed to be such a big deal just 3 posts ago.

No, I'm not. Whenever you sync up, you control what gets imported. If another player built around your installation, you can simply not import that installation, or if you did, you can tear it down, and select "Use mine" the next time around. Nor are there any paradoxes: by default you import everything that's in the other person's game at the real time of import (not the in-game time). It doesn't matter what day it is in the game you're importing from.

1 hour ago, Master39 said:

A manual system to resolve conflicts that wouldn't be there if the game doesn't allow you to build multiple building in the same spot. 

And an automated system that blocks out territory against building is better, why? 

Didn't you just say a couple of messages ago that the problem is extremely unlikely to emerge in a co-op game with several entire solar systems to play in? 

1 hour ago, Master39 said:

Which means teleporting planets or being forced to sync up, but in a weirder way, up to the closest point in which the Kerbol system configuration matches the one of the other player (I don't know how often the Kerbol system goes back to its starting configuration, and I don't want to guess the number, but I bet that's not a low one)

No, it doesn't. The clock in each savegame stays where it is, and the planets stay in the configurations where they are. If you want to play a co-op mission, you decide which of the savegames you play in, and everybody participating drops in on that. When the mission ends, any modified or created assets are exported back to all participants in their respective timelines. (Of course if they want to sync their clocks, for role-play purposes or whatever other reason, they can – it would be quite easy to add a button for this purpose.)

1 hour ago, Master39 said:

That's barely considerable "multiplayer co-op" and more akin an automated merging system for the forums shared saves projects.

In what way is the gameplay materially different from the system you're proposing? Suppose you've switched on auto-import (=all assets appear in everybody's worlds as soon as they're created) and auto-clock-sync (=everybody timewarps to the fastest player's in-game clock whenever they start a co-op session). Other than conflict resolution (which you claim is a non-issue in the first place), in what way is the gameplay experience worse than in your solution?

Again, I contend that it's better because everybody can interact with everything at all times, even between the co-op sessions. No ghost buildings, no blocked-out ground, the original builder's building state take precedence over exported copies.

1 hour ago, Master39 said:

Unless you're not interested in multiplayer at all and you're just trying to advocate to dedicate the least amount of effort to it to "save" those resources for other parts of the game (which is a moot point anyway since they have hired some dedicated devs) I assure you this is not a problem, I've had more complex code being written for a relatively small (2-300 players) Minecraft server (a heavily customized and rewritten from scratch version of towny made to work on top of Forge at a time in which most plug-ins couldn't).

And I am currently working on a project in my day job, that involves syncing up thousands of assets created and modified by dozens of users each working at their own pace.

You still haven't explained in what way your solution results in better gameplay than mine. I on the other hand have demonstrated that adding a few simple switches to my solution would give a very close functional equivalent to yours – the main difference that buildings appear everywhere when they're built in real-time instead of game time and are interactable at all times (which IMO is better for gameplay than ghosts or blocks on terrain), and in conflict resolution with overlapping buildings, or modified imported buildings (which according to you is an extremely rare occurrence in the first place).

From where I'm standing, you're just advocating for added complexity with no good reason, as well as undesirable side effects like ghost buildings or blocked-out terrain. That's just bad design as far as I'm concerned.  I would also prefer that you engage with my arguments rather than my perceived motives.

Edited by Brikoleur
Link to post
Share on other sites

Let's forget sync-ups or transparent buildings or anything fancy, let's make it even simpler:

  • Player A opens a KSP2 LAN game
  • Player B joins
  • Player A builds a base
  • Player B can't build a base in the same place because there's already a base there

It's not a "terrain blocking system" it's just how playing multiplayer works.

On top of this very basic multiplayer system you can then implement a way to manage warp that can be:

  • Everybody at the slowest speed 
  • Everybody at the fastest speed
  • FMRS Style, you can branch off to do your thing and then merge later which is easy since nobody can't build in the same place (my sync up idea).

On top of this you can then add whatever system to manage craft permissions and resource sharing.

 

I don't see anything complex or exotic about it, it's just a very basic standard multiplayer, which has been my point from the start, you don't need to do much to make a KSP multiplayer, it's not a big deal at all.

Link to post
Share on other sites
41 minutes ago, Master39 said:

Let's forget sync-ups or transparent buildings or anything fancy, let's make it even simpler:

  • Player A opens a KSP2 LAN game
  • Player B joins
  • Player A builds a base
  • Player B can't build a base in the same place because there's already a base there

It's not a "terrain blocking system" it's just how playing multiplayer works.

Yes, that's what I've been proposing all along. With the twist that if any of the players go off-line, they sync up their assets whenever they rejoin. There is no "opening up a LAN game," there are only savegames that can be linked up over the Internet at any point in their history. They can remain linked, un-link and re-link, or go their separate ways.

41 minutes ago, Master39 said:

On top of this very basic multiplayer system you can then implement a way to manage warp that can be:

  • Everybody at the slowest speed 
  • Everybody at the fastest speed
  • FMRS Style, you can branch off to do your thing and then merge later which is easy since nobody can't build in the same place (my sync up idea).

On top of this you can then add whatever system to manage craft permissions and resource sharing.

Yes, exactly, also what I've been proposing all along. (Except with the distinction that in your solution buildings exist as "ghosts" or "blocked terrain" until a lagging game reaches the calendar time when it was really built, and that you can't interact with them in any way unless the owner is on-line; in my view this are unnecessary complications that make gameplay worse – just have the buildings appear immediately, regardless of calendar time, and have them behave exactly like the buildings you've built yourself, except that any conflicts in further construction are resolved as I described above.)

41 minutes ago, Master39 said:

I don't see anything complex or exotic about it, it's just a very basic standard multiplayer, which has been my point from the start, you don't need to do much to make a KSP multiplayer, it's not a big deal at all.

Indeed. I'm glad we're finally in agreement, then :)

Edited by Brikoleur
Link to post
Share on other sites
38 minutes ago, Brikoleur said:

There is no "opening up a LAN game," there are only savegames that can be linked up over the Internet at any point in their history. They can remain linked, un-link and re-link, or go their separate ways.

In most modern coop game "opening up a LAN game" (or internet) often means flipping a switch on your single player save allowing friends to join in.

Still one save with all the crafts and building there.

It's your idea of merging multiple single player saves with all their progress and manually dealing with any  conflict every time that's an exotic feature that's far from standard.

I can see uses for that, especially if players want to merge their respective single player campaigns to make one single server, but it's an additional feature, one that's not expected from most players.

 

38 minutes ago, Brikoleur said:

Except with the distinction that in your solution buildings exist as "ghosts" or "blocked terrain" until a lagging game reaches the calendar time when it was really built, and that you can't interact with them in any way unless the owner is on-line; in my view this are unnecessary complications that make gameplay worse – just have the buildings appear immediately, regardless of calendar time, and have them behave exactly like the buildings you've built yourself, except that any conflicts in further construction are resolved as I described above

That was to avoid any paradox regarding using in the past buildings from the future, admittedly you can just have everything spawn at the same time and let people deal with it, the main point is preventing future conflicts by not allowing 2 building in the same place.

Especially since I see multiplayer time-warping more like FMRS, with people remaining more or less synced up and making big jumps together, no "player X is 2 centuries ahead of the rest of the server".

38 minutes ago, Brikoleur said:

Indeed. I'm glad we're finally in agreement, then :)

Yep, it's an interesting topic to argue over, but the point is that it's not a big deal, as demonstrated by the fact that more or less everyone in this topic has come up with his own idea on how to "solve" the impossible multiplayer problem. 

It's just a matter of playtesting a bunch of different solutions and see what it works the best.

Link to post
Share on other sites
2 hours ago, Master39 said:

It's your idea of merging multiple single player saves with all their progress and manually dealing with any  conflict every time that's an exotic feature that's far from standard.

It's a way of dealing with divergent timelines, which is also not a concern with most multiplayer games. 

One way or another, timelines will diverge and converge. In my view it's much simpler to have every player's single-player save keep track of its timeline and merge them when needed, than to have a single multiplayer server that attempts to keep track of all of them. Most players will spend much of even most of their time in their own timeline, after all. 

(This discussion reminds me of the old debate between centralised and distributed VCS by the way. That got more or less resolved a while back. ;)

2 hours ago, Master39 said:

Yep, it's an interesting topic to argue over, but the point is that it's not a big deal, as demonstrated by the fact that more or less everyone in this topic has come up with his own idea on how to "solve" the impossible multiplayer problem. 

Quite. Also I don't think anyone here has characterised it as impossible. I've been shooting down some specific types of multiplayer which I do think are fundamentally incompatible with KSP2 and its divergent timelines – a massively multiplayer persistent server with trade, war, and what have you, for example.

Addendum/note for other software nerds.

Spoiler

 

This argument springs from my experience dealing with distributed systems and various other multi-user/multi-tenant systems where users need to share state. Things tend to get incredibly hairy if two conditions aren't met:

  1. There's an unambiguous state towards which the system converges
  2. Every entity in the system has an unambiguous way to determine entity state in case of conflicts – usual mechanisms are an origin/owner, or a timestamp, or a combination of both.

For most multiplayer games these aren't problems – there is an overall state in which all the players participate, even if they occasionally break out into temporary instanced dungeons or whatever, and in those cases the players in the instanced dungeon share the state of the instance; when they return to the main game, the instance is deleted, with their character state (=XP, status effects, inventory etc) imported back into the main game. With KSP2 however, the divergent timelines violate condition (1) -- suddenly the system has no unambiguous overall state to converge towards, and making one of the player timelines – e.g. the fastest one – the state will cause all kinds of issues for everybody else, some of which we've discussed ITT. This is not a trivial problem that can be hand-waved away with "the devs will think of something, they're professionals." 

My proposed solution moves the locus of the unambiguous system state from the shared server to each player. Or, put another way, it makes the "instanced dungeon" (=personal savegame) the default state for all players, where each instance imports state from the others. I'm no longer concerned about overall system state at all, only with each player's game state. The problem is now much simpler: how to import state from other players in a way that doesn't cause paradoxes or conflicts in my state. It doesn't matter that my game state isn't a 1:1 match for your game state: the only thing that matters is that my game state remains consistent and the merge doesn't have any undesired gameplay consequences. There's no need to determine which one is the "real" state; they're all real. Since I'm writing from Copenhagen, I'll call it the Copenhagen interpretation of the kwantum multiverse. 

Finally – and this might render this whole thing academic: if there's an existing ready-to-go multiplayer system they can just plug into, it might well end up easier to maintain the separate timelines on the same server... although... intuitively... I don't think so. I think it's unlikely that any existing ready-to-go multiplayer platform has considered the possibility of timelines diverging as much as they easily will in KSP, and calendar time being as important, since it determines where every celestial body is at any given time.

 

 

Edited by Brikoleur
Link to post
Share on other sites

So I said before I think we have solved ksp 2's multiplayer. The thread is called Forza Horizon 4 and how its multiplayer can fix the ksp 2 multiplayer problems (it is such a long name that it probably is called something different lol). Anyways I reccomend checking it out because it appears we have one of if not the best solutions to all the "problems" with KSP 2 and multiplayer. Of course, the discussion is open and I want to know what everyone thinks. @Nate Simpson  maybe we can get a opinion...

Link to post
Share on other sites
5 hours ago, PlutoISaPlanet said:

So I said before I think we have solved ksp 2's multiplayer. The thread is called Forza Horizon 4 and how its multiplayer can fix the ksp 2 multiplayer problems (it is such a long name that it probably is called something different lol). Anyways I reccomend checking it out because it appears we have one of if not the best solutions to all the "problems" with KSP 2 and multiplayer. Of course, the discussion is open and I want to know what everyone thinks. @Nate Simpson  maybe we can get a opinion...

Everybody can solve the "problems" of KSP multiplayer, it's a non-problem, you can just brute force it out of the game by implementing a bunch of prototypes and then throwing them at the playtesters to see what does stick and what doesn't.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...