Jump to content

Multiplayer time warp theory


Recommended Posts

Hey all. I wanted to see what you think of my concept here for KSP time warp in multiplayer. The one big drawback. is it would require a server with huge physical memory as well as RAM. My concept is this: similar to the "Relative Sync" method, the game keeps track of the most chronologically advanced player's save. This is the "warp ceiling". The least chronologically advanced player is important as well, and this is the "warp floor". So, each player's progress is saved as they go on, as a sort of timeline of events. This timeline is "unraveled" for any players who reach that point in time, that is, players who reach any points that the time line covers will see the past of other players at that point. Player's progress is like a printer. It "prints" it's past onto a paper, which is pushed down a line. Somewhere on that line is a scanner (another player), which has a printer attached as well. It can read the past actions of the first printer, but can also print it's own actions for other players further down the line. Time warp would be as simple as moving the printer/scanner forward on the line of paper, closer to the "ceiling".

So... is this valid, or not (and is it the same as Kessler multiplayer [was unable to tell if warp was available on Kessler])? Thanks for an feedback. Sorry if I am just mirroring Kessler without knowing it, too. :D

For those of us who think better visually, I drew this (with some sweet MS Paint skills, if I do say so):

22ljDsJ.png

Link to comment
Share on other sites

This is sound, so long as there are no collisions/docking. And it's essentially how any good MP server works. Because of network lag, everyone playing in a shooter is at a slightly different delay from the server. So when you shoot someone, how does the server know if you hit? Well, info on when and where you shot is sent to the server, and server keeps some logged data on movement of every entity. So it sees if you'd hit the enemy based on where that enemy was when you fired. And if so, it subtracts health.

Of course, in a shooter, we are talking less than a second of data being buffered this way. And if you got shot, typically, all it means is that you found out that you've been killed a fraction of a second later than it actually happened. Not a problem. even with explosions, if your position shifts slightly due to prediction miss, it's not a huge deal.

But in KSP, if you even nudge someone most gently during docking, it will shift their future location by hundreds of kilometers. If server suddenly decides to take that into account, it can mean all sorts of trouble for the player that leads the warp ceiling. You really need to figure out how to deal with these sorts of situations if you want warp to be de-synchronized.

P.S. Memory isn't an issue, by the way. So long as you only store changes of ship configuration and trajectories of individual ships, it's peanuts. You can have years worth of data stored in RAM. Which is what you want here, of course.

Link to comment
Share on other sites

Hello - I'm the developer of DarkMultiPlayer and was a dev on KerbalMultiPlayer! :)

There's a few different ways of tackling the multiplayer problem, and I have 2 major ways that offer different playstyles of solving the problem.

The first is probably the more intuitive but less useful master controlled warp, in which players can

. I find this solution lacking unless you're on voice chat and are all trying to do the same thing.

The way KMP solves the problem, and the way DMP prefers to solve the problem is by using something called subspaces, which is basically relative sync. Each player has a "timeline" (subspace) they are on, and they can warp/sync to the future players.

DMP keeps hold of the future updates, but DMPServer only holds on to the latest updates, making the CPU and RAM requirements nearly nothing.

, the spectator is actually watching events play out as their timeline crosses the future. This is probably similar to your suggestion ;)
Link to comment
Share on other sites

From the last thread on multiplayer timewarp:

Asynchronous timewarp has some problems.

Imagine two players are racing to intercept an asteroid. Player 1 plots his intercept, does his burn and goes full timewarp and intercepts. Player 2 plots a little more carefully and finds an earlier intercept, does his burn, but only warps at half the rate. Player 1 arrives first in real time and thinks he's won the race, Player 2 arrives later in real time and earlier in game time. If Player 2 adjusts the course of the asteroid, how does the game reconcile the play that Player 1 has already performed?

Or imagine two players are messing around with spaceplanes supported by a orbiting fuel depot with 1000 units of fuel. Player 1 launches, transfers to the Mun under timewarp, then returns under timewarp, and docks with the station and takes on 600 units of fuel. Player 2 spends some time flying around Kerbin, using more real time but less game time since he isn't warping. He then ascends to rendezvous with the station and attempts to take on 600 units of fuel. Should he be able to? If yes, does Player 1 lose fuel?

I've not heard yet a good solution to those types of situations. A "warp master" sidesteps sync problems, but at the cost of player boredom when they're ready to warp but the master isn't.

Link to comment
Share on other sites

Some problems..

Isn't being in the past a way to kill other players at no defense?

Let's say you had an interplanetary generic fuel tank that was going to magically leave kerbin orbit in 2 yrs. Player BD decides to time warp 2 years into the future to cause it to leave, leaving players U, V, and N in the past. What if player N smashed the thaumic accelerator on the generic fuel tank in orbit around kerbin while player BD's present fuel tank is in orbit around the sun? Would the future have to override the past? Would any alterations made in the past destroy the future completely?

Player N isn't an observer. He plays in the past along with U and V because going into the future would screw things up for V, and N wants to do things like build a base with U. What can player N do if BD goes into the future and makes a burn using N's warhead? If the future were to override the past, player N's warhead would probably blow up or something.

Edited by Tery215
Link to comment
Share on other sites

This system might work only if you assume ghost-mode. Meaning: Players cannot interact with each other unless they're at exactly same point of time - any attempt to do anything with a ships owned by another player will cause clipping with no interaction what so ever.

But even then - this system is flawed because it requires game to transfer and store quite a large amounts of data, data that isn't collected right now (otherwise we'd have a reply mode), so it'd require tons of work that only adds on top of what is necessary for the multiplayer.

TBH: If anything I'd prefer wrap master over an idea from original poster. Even if it could be implemented in some reasonable time window.

Edited by Sky_walker
Link to comment
Share on other sites

I thought this was settled? Each player/ship is in their own time zone, in order to interact with another object you have to be synced with them (in the same time zone), this could be done though the map view with a button that says sync with. Ships can only be moved forward in time to prevent funny things with time travel, so to dock with a fuel depo that is behind you chronologically you have to bring it forward in time by hitting the sync with button. If you are behind it chronologically you have to sync forward to be able to interact with it.

If you are infront of an object you would see a ghost of where it would be if it was synced with you and ditto if you where behind it, a ghost of where it was.

This prevents paradoxes as only one true instance of an object ever exists at one time. To prevent griefing a set a permissions could be created to determine who could bring an object through time or who could control it; white list, black list, private, puclic, friends, admin only ect ect.

The only issue would be ghosts jumping around madly in the future when a ship is accelerating in the past.

Link to comment
Share on other sites

You can't ghost into the future.

I believe the goal of the OP is to make the game feel like other players are there (to make the game feel more populated and alive) even if you're not synched with them, and suggets a method by which you see where they were (in their past) at your current present. But yes, they would have to be non-interactable (ghosts) and it would, as you say, require the exactly same kind of functionality as a replay feature.

Link to comment
Share on other sites

Why can't you ghost into the future? If I'm in orbit around duna at 100 km by 120 km, the game can calculate where I would be in x amount of time, that's what it has to do then just display a ghosted version of the ship (slightly transparent maybe) at that time and place. Honestly it's exactually what KMP does, or did more accuratly. It's been done.

Link to comment
Share on other sites

Ships can only be moved forward in time to prevent funny things with time travel, so to dock with a fuel depo that is behind you chronologically you have to bring it forward in time by hitting the sync with button.

How would rendezvous work? Say I want to use a fuel depot, so I rendezvous with it only to discover I have to timewarp ahead (either ship or depot) a bunch. That timewarp will ruin the rendezvous because it's impossible to perfectly match the orbits.

Link to comment
Share on other sites

Sync with the depo before you rendezvous, or perhaps the feature from the mod Burn Together where ships can remain locked together during time warp could be implemented.

Edit: Here is the Burn Together mod.

Link to comment
Share on other sites

i don't understand why this is a theory. KMP already does something a little like this. Someone should just test all these paradoxes on KMP and see what happens.

Either everything will be smoothed out using only in game time or a new kraken will be born.

THE TIME KRAKEN! :)

Link to comment
Share on other sites

Another solution for the multiplayer problem:

Disable time warp completely and add some kind of warpdrive into the game. Finish. All problems solved.

Edit: The warpdrive should only be capable of accelerating your current flight direction, so that you can not save dV requirements with it. Basically same as timewarp without actually tampering with the time only travelling speed.

Edited by gpisic
Link to comment
Share on other sites

What I'd actually love is a 'hard mode' multiplayer with no timewarp AND no warp drive, that lets you set SMS and email / chat notifications to your smartphone. Have "control" determined by an avatar character, so if you want to make sure SOMEONE is around to execute the next maneuver node, either install a probe core with autopilot capabilities, or have multiple crewmembers on the ship that are each controlled by a different player, so that SOMEONE will be awake and not at work to take control of the ship after getting the SMS.

Link to comment
Share on other sites

The only issue would be ghosts jumping around madly in the future when a ship is accelerating in the past.

Which is a huge problem. Ok, so lets say that any two players trying to dock together are always concurrent and on voice-chat. Trying to dock up with another player without comms is a suicide pact anyways. So accelerating ghosts won't matter there. But what of stations?

Suppose, I want to dock to a station that another player is docking to at the same time, but his game time is several hours into the future. Any bump I make against the station during docking will send it tens of kilometers off course. But it gets worse. Suppose, another player docks to a station first, but in the future compared to my timeline. I dock to station and bump it off course. Should it move the station along with docked ship? Probably. According to game logic, they are one ship now, anyways. But what if the ship that docked to the station also gets interacted with in its past timeline? Who gets moved where? Technically, docking wouldn't even have happened.

Honestly, this is a royal mess. Ghosting offers a lot of advantages, but it's far from paradox-free.

Link to comment
Share on other sites

But you aren't able to bump the station if it is several hours ahead. You have to sync with it in order to physically interact with it, which would bring you into the same time reference as your buddy. If you are not in the same time reference as a ship you can't interact with it, that's how it prevents paradoxes, it only looks like the station is there in the past, but you can only interact with it in the present.

Man that got confusing fast.

Link to comment
Share on other sites

Hm. Good point. That still doesn't exclude problems with two people trying to dock to it at the same time, though. Say, the time ordering is (station, ship 1, ship 2). Both ships want to dock to station. Naturally, if ship 1 fast-forwards the station to own time, it will start throwing things off for ship 2 who is trying to approach for docking. Or if ship 2 starts fast-forwarding station to own time while you are trying to dock with it. Of course, it's a fairly minor issue compared to everything else. And it results in inconvenience, rather than hard sync issues.

Link to comment
Share on other sites

Hm. Good point. That still doesn't exclude problems with two people trying to dock to it at the same time, though.

If they're actually at the same TIME, as in the same subspace, there are no problems whatsoever- aside from the obvious ones of players working out between each other who gets to dock to what docking port and how much fuel they can take, etc. No problems with causality or continuity, though.

Say, the time ordering is (station, ship 1, ship 2). Both ships want to dock to station.

But a station is just another vessel, as KSP sees it. Naturally, only one of the players actually OWNS the station- the other is just using it on configurable permission (or perhaps a third players owns it and is allowing both to use it).

Naturally, if ship 1 fast-forwards the station to own time, it will start throwing things off for ship 2 who is trying to approach for docking

You miss the fundamental impossibility of the problem you are bringing up- Player 2 cannot approach for docking in the first place, as he is not in sync with the station.

Even if Player 2 could see a ghost of where the ship was predicted to be, based on its orbit in the past, he would have to know that due to floating-point errors, etc (which we already deal with in single-player when trying to plan a rendezvous- which is why you ALWAYS have to adjust your rendezvous as you get closer...) it would be impossible to know precisely where the station would be anyways.

Or if ship 2 starts fast-forwarding station to own time while you are trying to dock with it.

That's more an issue of control- namely, who is in control of the Station. If both players had somehow ended up sharing permission for time-warp, it would be their own stupid fault if they couldn't work out an agreement so Player 1 could finish his docking/refueling before Player 2 synced the station up with himself to allow docking/rendezvous.

Of course, it's a fairly minor issue compared to everything else. And it results in inconvenience, rather than hard sync issues.

Pretty much. The issues with multiplayer you described are mostly inconveniences of players working out between themselves who gets to control the time-warp of shared vessels (the warp-master solution is just taking this to the extreme, where one player controls the time-warp for ALL vessels). It's not like other multiplayer games don't already have similar issues- the allocation of a limited amount of ammo/medkits between players in many FPS games, for instance. One selfish player can ruin everybody else's experience.

Regards,

Northstar

Link to comment
Share on other sites

You miss the fundamental impossibility of the problem you are bringing up- Player 2 cannot approach for docking in the first place, as he is not in sync with the station.

He can approach the ghost. Naturally, you'd first get yourself into "mostly" right place, then fast-forward the station. Otherwise, you are just denying it to a bunch of people who could have used it at a different time.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...