Working Multiplayer Proof of Concept with video proof [No Longer In Production]

[Pwolf]

What's next on the list?

That's actually a really good question. I've been focusing on the basics so now I think I need to write up a project plan and work towards making something people can actual use and play with. It's no fun if i'm the only one

[Blaylock1988]

Haha, multiplayer for no one but yourself.

[nubeees]

That's actually a really good question. I've been focusing on the basics so now I think I need to write up a project plan and work towards making something people can actual use and play with. It's no fun if i'm the only one

BUAUAHAHAHAHAHAHAA!! Soon I shall have a use for my research of stock missiles-

I mean

Good work, this will be fun to play with when you finish! 8D

[Captain Sierra]

You seem to have one of the toughest initial hurtles down: position, orientation (rotational), trajectory, and velocity data being shared, on top of craft file sharing. That gives the components for rendering. IS that at all remotely like what you are doing? Also, here are some hard questions. I do not expect you to have an answer to these but rather would like to put it in the back of your mind and see what you come up with several updates from now.

How will particle effects like engine thrust be handled.

How will physics be handled to enable things like collisions and docking (If this gets to the point where collaborative space stations are possible, wow, just wow).

Don't even worry about time warp yet. That can wait.

And don't feel pressured to get this done. A non-buggy release that is delayed 3 weeks is worth the wait 5 times over if it means you can kill several bugs.

[Pigbear]

So what currently happens if you try to dock?

[rentaspoon]

Just seen this. Can I say congrats on the POC.

this reminds me a lot of Multi Theft Auto where people said it wasn't possible and then proved wrong.

Can I suggest IF you get far

enough that you allow a 3rd computer to run as server

[Metapher]

[...]

How will particle effects like engine thrust be handled.

How will physics be handled to enable things like collisions and docking (If this gets to the point where collaborative space stations are possible, wow, just wow).

[...]

Since you alread answered yourself:

Because of the Craft-File-Exchange*, the other vessel should look and feel like you would play with it.

Exhaust should be there, and they should collide.

Docking will be a bit tricky...i imagine a dock-confirm-system, like in the Scifi-Movies.

If a player targets your port in a close range (100m or something), both players will get a bi-directional message in a "Master and Slave"-style.

Both players select the style of docking -> Master/Slave -> if both select the respective opposite, docking ports will open and be dockable.

P1 selects Slave: P2 will control the whole vessel e.g. attaching the new parts to P2-vessel (P1 loses control of his parts)

P1 selects Master: P1 will control the whole vessel e.g. attaching the new parts to P1-vessel (P2 loses control of his parts)

... as long as they are docked.

On undocking, the parts will be seperated to the player-IDs and everybody has their control back.

*Craft-File-Exchange:

When a player wants to push is vessel out of the VAB/SPH, it MUST be saved to a craft-file.

Then the file-sync hits and seeds the new craft-file to every other player.

Only the player who wants to start gets a loadingscreen, till every other client responds with "craft-file successfully synced".

So every player has the same file and will see the same ship during the game.

Edited September 25, 2013 by Metapher

[Pwolf]

My focus now is to try and get an accurate server<->client time synchronization. As mentioned in older posts I'm trying to maintain sync by running a game clock on the server and then trying to sync the Planetarium Universal Time on the local clients to that clock... This should be simple to fix by calculating a delta time offset when ever the client syncs with the server (and periodically during the game). Right now the latency between the client and server is enough to shift the other vessels off course by tens of meters. Since I'm running the clients on the local machine or on a LAN, I can probably fix it so its reasonable. However, this can be a much bigger issue when connecting from half way around the world. Not very good for close maneuvers. Wrote some code earlier today to try and fix this so I'll be doing some testing after work...

[Nexustrimean]

This is very impressive I hope you can continue your success so far.

[Captain Sierra]

The server clock thing may cause problems when you start to address time warp but I figure that's still a ways off. Right now, you still have way more than the community thought possible. I cannot commend you enough simply for doing what nobody else has dared to.

[Pwolf]

The server clock thing may cause problems when you start to address time warp but I figure that's still a ways off.

Once i get the clock synchronized within a more reasonable threshold I should be able to make a quick and dirty time-warp demo for everyone to see... just to finally allow the poor horse to rest in peace.

[TheCanadianVendingMachine]

What is this floating offset problem?

[pizzaoverhead]

My focus now is to try and get an accurate server<->client time synchronization. As mentioned in older posts I'm trying to maintain sync by running a game clock on the server and then trying to sync the Planetarium Universal Time on the local clients to that clock... This should be simple to fix by calculating a delta time offset when ever the client syncs with the server (and periodically during the game). Right now the latency between the client and server is enough to shift the other vessels off course by tens of meters. Since I'm running the clients on the local machine or on a LAN, I can probably fix it so its reasonable. However, this can be a much bigger issue when connecting from half way around the world. Not very good for close maneuvers. Wrote some code earlier today to try and fix this so I'll be doing some testing after work...

If you're running an internet game, why not synchronise the time over the internet via NTP? That way you have a common reference point for all entities which takes network delay into account. The accuracy looks like it's in the region of 1-50 ms. Is that accurate enough for this task? There's some discussion on the matter here.

[Pwolf]

If you're running an internet game, why not synchronise the time over the internet via NTP? That way you have a common reference point for all entities which takes network delay into account. The accuracy looks like it's in the region of 1-50 ms. Is that accurate enough for this task? There's some discussion on the matter here.

Unfortunately the immediate issue I see with NTP is that if a client is blocking the protocol (network firewall), it wont be able to sync. I'll give NTP a more thorough look though, thanks.

Edited September 26, 2013 by Pwolf
Had to leave for work so I'm adding some more text...

[Eric S]

Unfortunately the immediate issue I see with NTP is that if a client is blocking the protocol (network firewall), it wont be able to sync. I'll give NTP a more thorough look though, thanks.

I think a bigger issue is that if any of the computers are running slower than real time due to physics calculations, they should all slow down, at which point what NTP is providing isn't relevant except as a baseline, so you might as well focus on what will be relevant.

[UbioZur]

Docking will be a bit tricky...i imagine a dock-confirm-system, like in the Scifi-Movies.

If a player targets your port in a close range (100m or something), both players will get a bi-directional message in a "Master and Slave"-style.

Both players select the style of docking -> Master/Slave -> if both select the respective opposite, docking ports will open and be dockable.

P1 selects Slave: P2 will control the whole vessel e.g. attaching the new parts to P2-vessel (P1 loses control of his parts)

P1 selects Master: P1 will control the whole vessel e.g. attaching the new parts to P1-vessel (P2 loses control of his parts)

... as long as they are docked.

On undocking, the parts will be seperated to the player-IDs and everybody has their control back.

Maybe you could try to use the docking port ID.

If per server each player have an unique ID, they could have a unique Docking port ID that every player could set on their ships (to allow only some player to dock at some ports)

http://forum.kerbalspaceprogram.com/threads/35225-Some-lesser-known-bits-of-info-for-addon-developers

[pizzaoverhead]

I think a bigger issue is that if any of the computers are running slower than real time due to physics calculations, they should all slow down, at which point what NTP is providing isn't relevant except as a baseline, so you might as well focus on what will be relevant.

That means you're synchronising time to an unpredictably moving target. You could force the Max Physics Delta Time to change to cause frame drops instead of slowdown. I have no idea to what extent that would help however.

[Max80well80]

So, any progress with this? I'd love to see some communication between this project and the LOG project!

[Pwolf]

I've been pretty busy with work but I'm currently working on spawning in vessels as they connect to the server.

[Leyvin]

The issue with Multiplayer isn't so much the Server-Client ability to communicate, heck by the very definition all you need to really do is setup the Server as a "Dedicated" Server... this way for each player you merely shift to the 'current vehicle' in use, when people are in the SPH/VAB they can then be ignored from the update loop.

Although this will lend issues, firstly that there is only a single SPH/VAB on Kerbin (so perhaps a creative solution to add another per player might be a good idea, Kerbin Town seems to be a good start for that) but the biggest issue really comes in the form of the "Time Dilation" ... as you can't have 1 Player Time Warping when the others aren't.

A viable (but I guess arguable unrealistic) would be to disable Time Warp and instead create a /Hyper-Space/ Style Device that would effectively transport that player /near/ instantly along the Orbital Path they were on. This is relatively easily done, but balancing it so it isn't an "I win" movement or that trips would take too long would be quite difficult to do.

Again there are some mods that have delved in to this, but don't recall seeing any that weren't just OP; which as I said would be the major tricky part.

The final aspect that likely will prevent this from being particularly usable though is the games performance, sadly (and I feel this is likely more a problem with Unity as it is not exactly amazingly optimised tbh) is actually pretty terrible. I mean have you ever had a Space Station in Orbit that has like 1,000 Parts when put together? The game starts to hit single digit framerates even on high-end machines.

Unfortunately there just isn't a way around that without Kerbal moving from PhysX (built-in and OMG piss poorly implemented) to something like Bullet Physics or Open Dynamics Engine... which isn't a bad idea to be honest, as it would provide better opportunity for optimisation, multi-core and OpenCL (GPU) support - but they aren't the easiest thing to implement.

-|-

This said, and consider this for a second... if instead of focusing on making an asynchronous multiplayer (traditional Server-Client, everyone playing at the same time) instead you looked at perhaps something that simply allowed players to Collaborate... i.e. Aerospace Manufacturer(s) [sPH] ... Launch Vehicle Manufacturer(s) [VAB] ... Mission Control (Provides Missions / Objectives / Budgets) and Pilot(s) (who actually Fly the Missions)

Then that might be a far more interesting form of Multiplayer that doesn't require any real alteration of how KSP works at all.

Instead you could then have a group of friends who are basically playing together doing each of the individual components, then sharing what they come up with.

For example someone working on an Space Plane, would be considered to be in a 'Simulated Environment' once they're done they would then hit the "Ship to Space Agency Button" that then makes it available to Mission Control for actual Missions they want to set the Pilots. Best part would be that it could all be backed up to an SQL/WebServer so they don't even have to be playing at the same time to be playing and 'sharing' the experience.

When there are launched then have it so any of the /other/ players outside of the Pilots could then get a "Live Feed", for what is going on.

It also kinda keeps well to the /spirit/ of KSP being the whole peaceful, yet often disaster ridden exploration of Space.

I mean after all most of us have different things we like about KSP, I for one have never really made it past the Mun; instead I prefer to spend most of my time messing about in the SPH making interesting Air/Space Craft. If you have what you have above for say up to 3 Kerman capable of being controlled by individual players; could be cool to see them doing close operations or performance actual Apollo Style missions and such where they're all relatively still close to each other.

[Faark]

A) Timewarp is solvable and not an issue. We had that discussion earlier in this thread as well as in a bunch of others, so please let us not start this again.

Physics is not an issue. You can MP with smaller crafts, use part-reducing mods and Squad has to optimize this anyway. Anyway, crashing ships with ten thousands of part into each other is not was KSP is made for, no matter if you consider it in an MP context or just as SP.

C) I like your idea of Multi-VAB/SPH. Never considered it, before. Not talking about sharing craft files, since that would be no challenge. But it would be a nice feature for a real MP server... having a list of players currently building stuff and you can join them and watch or even build with them.

[Pwolf]

The issue with Multiplayer isn't so much the Server-Client ability to communicate, heck by the very definition all you need to really do is setup the Server as a "Dedicated" Server... this way for each player you merely shift to the 'current vehicle' in use, when people are in the SPH/VAB they can then be ignored from the update loop.

This is more or less what I'm doing now. I have dedicated server software which acts as a middle man, relaying data to all the clients that are connected.

This said, and consider this for a second... if instead of focusing on making an asynchronous multiplayer (traditional Server-Client, everyone playing at the same time) instead you looked at perhaps something that simply allowed players to Collaborate... i.e. Aerospace Manufacturer(s) [sPH] ... Launch Vehicle Manufacturer(s) [VAB] ... Mission Control (Provides Missions / Objectives / Budgets) and Pilot(s) (who actually Fly the Missions)

Then that might be a far more interesting form of Multiplayer that doesn't require any real alteration of how KSP works at all.

Instead you could then have a group of friends who are basically playing together doing each of the individual components, then sharing what they come up with.

For example someone working on an Space Plane, would be considered to be in a 'Simulated Environment' once they're done they would then hit the "Ship to Space Agency Button" that then makes it available to Mission Control for actual Missions they want to set the Pilots. Best part would be that it could all be backed up to an SQL/WebServer so they don't even have to be playing at the same time to be playing and 'sharing' the experience.

When there are launched then have it so any of the /other/ players outside of the Pilots could then get a "Live Feed", for what is going on.

It also kinda keeps well to the /spirit/ of KSP being the whole peaceful, yet often disaster ridden exploration of Space.

I really like this idea. Might be something I would be interested in after I get this proof of concept in a semi-playabe state. Which it is, just need to work out a little issue and I should be able to show off two or more players flying around each other.

[DaRocketCat]

But..but..I wanna ram 1000 part planes into 10k part rockets ;(

[Ghost13]

One of the approach that multiplayer could be in smaller area for exploration\interaction such as Kerbin, Moon, Minmus with real time for everybody. It still will be a lot of fun especially if it allow more ingame interaction become available. There is so many completely unsed space in the game it will work perfectly fine. Some alarm clock and sort of simple autopilot shuld still be there in case you need to sleep\work\do other things during some of the maneuvers. But still MP without time wrap at all is perfectly fine if the scale is smaller. As for the Jool or Eeloo yep it would take years of real-time to get there but why not?

[ZingidyZongxxx]

This said, and consider this for a second... if instead of focusing on making an asynchronous multiplayer (traditional Server-Client, everyone playing at the same time) instead you looked at perhaps something that simply allowed players to Collaborate... i.e. Aerospace Manufacturer(s) [sPH] ... Launch Vehicle Manufacturer(s) [VAB] ... Mission Control (Provides Missions / Objectives / Budgets) and Pilot(s) (who actually Fly the Missions)

I like this idea. I would love to have both, but this would be much easier. Simply letting players work together in building something would be really cool.