News Some thoughts on multiplayer...

[Kurt M. Weber]

So I've been working on a multiplayer system off-and-on for a couple of years now, and here are my design thoughts for you to chew on, hopefully to get some input as I pick back up on it.

Time acceleration: there is an SDK function that can set the time acceleration level. Every frame, the current acceleration level is checked and reset to 1 if it is not.

Time sync: The server maintains an internal clock, and upon connecting sends the client its internal MJD (which may or may not be the server's system time--it's configurable indepdently). An algorithm similar to what NTP uses is then used to correct for the delay in propagating the message from the server to the client.

Vehicle state: Rather than continuously update a vehicle's position in space, updates are only sent and propagated to other connected clients when a vehicle's orbital parameters (other than mean anomaly, of course) have changed by more than a certain amount from the last time they were updated.

Thoughts?

 

[Kaito]

Its GREAT that you're working on a multi-player function. While I like the Time Sync function, I have different views on how time acceleration and vehicle position should work.

Time Acceleration: When someone wants to time accelerate, they send in a request to the server. The server, in turn, sends out a message to all other players saying "So and so wants to time accelerate for [time] for [purpose]. Time accelerate?" If everyone else (or some percentage) agrees, the then server time accelerates for the designated amount of time. The purpose is only there so people will understand if someone wants to go to the moon, they don't want to sit around for 3 days just to get there.

Vehicle Position: Progressive. Every Vehicle within X distance of the ship gets updated every frame. But the second it leaves the distance, it isn't updated anymore.

Other Mulit-player things I would like to see, tho unlikely:
Mission Control: Just a place where people can check on all the positions of ships, live video feeds, and just talking with everybody.

"Docking Request": Just send a message to a vessel saying "Hey, can I dock with you for a reason?" (The reason would be stated). Just an official request.

Real fuel transfer: FuelMFD does this. Just have it be the ONLY way.

Things do real stuff: I am PERFECTLY fine with imagination (I like it), but if we were to do multi-player, I feel it should have some sort of passive goal. Like, earn money to do something, or mission control could give you missions. Also, equipment actually does something. As in the DGIV: Long Range Antenna: It would have to be deployed before you could communicate with Mission Control from, say, the moon. Now, I realize that not all ships have that. Lets say they have it internally.

IF we had more then one server: I'm a big fan of this idea, although I'm sure not to many people like it. I'm just throwing it out there: Re-supply. The ISS and Moon Base need to be re-supplied every now and then. Maybe on a seperate server, these could be modeled. Just have a "warning" call sent to Mission Control saying "We need supplies. Please send a ship as soon as you can".


Thats it for Multi-player ideas. Good luck with this!

 

[unknown_orbiter]

Why not have time-acceleration independent of the client? Because everyone doesn't want to time accelerate in the middle of an ISS rendezvous so some random guy can get to the moon faster. No that would be turned down by everyone on the server.

 

[Kurt M. Weber]

Well, there are no "official" moon-bases or anything of the sort.

The world is entirely open-ended. I hate multiplayer systems that attempt to enforce some of game structure--even if it's something as simple as an official in-game currency.

One feature of my multiplayer system is persistence, which means that when you sign off, your vehicles and whatnot are maintained in their current state while you're gone, unless you tell it to destroy your session.

If you have a moon-base add-on, then you put it on the moon and you (and anyone else who cares) can land on it an do whatever. If the add-on includes supply economy, then you can take care of that.


-----Post Added-----

Why not have time-acceleration independent of the client? Because everyone doesn't want to time accelerate in the middle of an ISS rendezvous so some random guy can get to the moon faster. No that would be turned down by everyone on the server.

There is no time-acceleration period.

As I explained already, a conforming client implementation checks the time-acceleration every frame, and resets it to 1 if it's been changed.

Anything else would break the consistency of the server's world.

 

[Kaito]

Understandable. No currency.
About the time warp thing: you would'nt have to say yes. Maybe if you caught EVERYONE at a good time, then it'd work.

I like that idea of keeping the vehicle state. But, heres the problem: You just did a burn to the moon. 3 days to interception. Then your family tells you you're going to stay with your Aunt on the opposite side of the state for a week. You come back, and you are WAY past the moon. How would you fix that?

 

[Quick_Nick]

OMP checks how far off of server time the client is and uses small amounts of time acceleration to correct. OMP is so far the most complete multiplayer for Orbiter.

 

[James.Denholm]

Anything else would break the consistency of the server's world.

What about a sort of "slowest requested" thing? If anyone here has played DEFCON multiplayer, you might know what I mean. The server checks to see who is requesting what time accel, and goes with that.

That said, I do like the vote thing, though maybe it could be used in conjuction with the slowest requested idea. As in, the server defaults to the slowest requested speed, though this can be changed for a certain amount of real-world time, so that it automaticly reverts back to the slowest when this time is up. That way, if someone's playing catchup with the ISS, they won't overshoot the rendevous time, as it will automaticly pop back to their time after so many seconds, which is what they requested as the "acceleration decay" time. Meh, don't mind me, I'm rambling again...

But, heres the problem: You just did a burn to the moon. 3 days to interception. Then your family tells you you're going to stay with your Aunt on the opposite side of the state for a week. You come back, and you are WAY past the moon. How would you fix that?

I see four options: One, drag your Aunt, kicking and screaming, over to your place instead. Two, don't go. Three, take your computer with you, and hack into someone's wireless connection during your stay.

But it's the fourth one that works, as always: Get someone else to do it for you. Work out someone who will be awake during that time, like TS, who never sleeps anyway, and get him to chuck you into a parking orbit while you're at your Aunts! Done and flustered! And If you winged back across the state real fast, I recon you might just be able to land the bird with O2 to spare.

 

[Hielor]

Any kind of global time compression cannot scale to a larger, persistent server. You'd need instead to have some kind of a "speed boost" on a single client, or use far sci-fi ships for longer trips like that.

 

[Face]

So I've been working on a multiplayer system off-and-on for a couple of years now, and here are my design thoughts for you to chew on, hopefully to get some input as I pick back up on it.

Time acceleration: there is an SDK function that can set the time acceleration level. Every frame, the current acceleration level is checked and reset to 1 if it is not.

Time sync: The server maintains an internal clock, and upon connecting sends the client its internal MJD (which may or may not be the server's system time--it's configurable indepdently). An algorithm similar to what NTP uses is then used to correct for the delay in propagating the message from the server to the client.

Vehicle state: Rather than continuously update a vehicle's position in space, updates are only sent and propagated to other connected clients when a vehicle's orbital parameters (other than mean anomaly, of course) have changed by more than a certain amount from the last time they were updated.

Thoughts?

Good ideas, Kurt. Been there, done that.

Any kind of global time compression cannot scale to a larger, persistent server. You'd need instead to have some kind of a "speed boost" on a single client, or use far sci-fi ships for longer trips like that.

Or you can track spacetime instead of space alone... My idea in this regard is to allow clients to decouple from each other into separate spacetimes in order to do time-accelerated operations. Of course they won't see each other if they are seperated. I can imagine that time travel in the real world wouldn't look different (ZAPP... of you go ...ZAPP... there you are) .
If someone wants to meet others in different spacetimes, he can tell the server to join the spacetime they are in. The client will be synced to this time again and if synced enough will appear on the other's screens again.

Not really different to having multiple servers for each spacetime. Just additionally allows switching between them.

regards,
Face