KeronTeam / Keron

Kerbal Online
MIT License
1 stars 1 forks source link

Keron

Travis CI AppVeyor

Kerbal Online.

Enabling you to play with friends (and foes?).

Heavy inspiration from and credits to KMP.

If you are looking for a (somewhat) working product, please head over to DarkMultiPlayer.

See CHANGELOG.md for the list of comprehensive changes.

Dependencies

Building

The project dependencies are rather small and self-sufficient. Therefore, we use submodules to guarantee that we share the same version across all builds.

Get the submodules:

git submodule init
git submodule update

Get a copy of CMake 3.1, or above, and make it available in your PATH. Then run cmake with your flavor of arguments:

# Linux build
cd build
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DKSP_MANAGED_PATH=/path/to/your/ksp/Managed ..

# Windows build
cd build
cmake -G 'Visual Studio 14 2015 Win64' -DCMAKE_BUILD_TYPE=Debug -DKSP_MANAGED_PATH=C:/Path/To/KSP/Managed ..

See the CI scripts in scripts for other configurations.

or use CMake's own GUI.

Design

THIS SECTION IS OUT OF DATE. See the issues for details.

The server runs in non-authoritative fashion: clients send updates and they are broadcasted to everybody through the server.

KSC

THIS SECTION IS OUT OF DATE. See the issues for details.

The KSC launchpad and runway are viewed as shared resources: one player is allowed at a given time.

Two cylindrical corridors are defined for each shared resource. As long as there is something in the corridor (an active player, a debris, a plane, a bird, superman...), a player cannot claim the resource.

For the launchpad, it would be a corridor 100m wide and 10km tall (note: subject to change). For the runway, it would be 100m tall and 500m wide before and after the track.

Example:

If a player disconnects while in a corridor, its vessel shall be destroyed immediately.

Warp

THIS SECTION IS OUT OF DATE. See the issues for details.

Warping handling is probably the most challenging issue of networked KSP. Disabling it all together is not a valid option (who would spend months to get to Eve, or simply hours to get to the Mun?).

Same goes with a shared warp-time

Imagine:

Got to go to Eve. warping x1000. Sorry folks who were doing high-precision docking manoeuvers!

Or even:

Got to re-entry. I take the lock on the time. Sorry folks who'd like to go to Eve before retirement!

Those are simply unacceptable from a gameplay perspective.

The answer to this is simple: subspaces. Each player plays in his own timeline, and may catch up with the server. The server time is simply the highest available.

This system implies a very simple, very important rule: one cannot interact with a vessel's past or future. Ever.

Reason is that you weren't there at that time. So you shouldn't interfere with the vessel if you have not caught up with it. It's completely unlogical from a realistic perspective but we believe it to be to the gameplay's profits. And we would not have to deal with alternatives futures, which would be a mess.

Moreover a player may never go back in his own timeline (just trust the Time Lords on this).

This together means:

But what happens if a past ship is on collision course with a future ship?

Well, that's tricky. Let me put that simply: they will collide at the point and time they should collide..

Multiplayer KSP is no fairy tale.

Technicalities

THIS SECTION IS OUT OF DATE. See the issues for details.

The client is a standard KSP Plugin. Though it originally intended to leverage Unity Networking functionalities, this turned out a dead end (basically, client would have to maintain deep copies of watched objects for the network serializer to kick in).

Instead, we use Lidgren.Net.

Both the client and the server are written in C# and relies on: