Multiplayer Protocol

[Rammelkast]

Hi,

Is there any way i can see the multiplayer 'protocol' which explains how the OpenRCT2 multiplayer packets are built?

 

[Broxzier]

Yes, by checking the source. Why do you want to know that?

[imlegos]

Like how the Multiplayer works? Because if it's that, then it works by sending command strings, based on user actions, too the host. and other players', games.

[Rammelkast]

Just now, Broxzier said:

Yes, by checking the source. Why do you want to know that?

I'm thinking about writing my own server implementation in Java (multithreaded) which allows plugins, but i'm not really a C/C++ pro
Is there any way you can tell me how the packes are build, and do you use id's?

[Broxzier]

Then I suggest reading up about that, instead of checking the source code of projects.

[imlegos]

Suddenly Bukkit for RCT2!

[Rammelkast]

5 minutes ago, Broxzier said:

Then I suggest reading up about that, instead of checking the source code of projects.

That still doesn't really answer my question :P, how do you identify packets, with ID's, or..? And in what order is the packet data (for example: 1. uint ID 2. byte[] data, etc)

Edited April 22, 2016 by Rammelkast

[Broxzier]

We're using UDP TCP, so there's no need for keeping track of IDs. Packets are guaranteed to arrive in the same order they are sent. From the code it looks like each packet has a size (number of bytes), a data array (vector of bytes), and keeps track of how many bytes are transferred and read.

https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/network/network.h#L119-L153

Edited April 22, 2016 by Broxzier
Was confusing UDP with TCP.

[X7123M3-256]

14 minutes ago, Broxzier said:

We're using UDP, so there's no need for keeping track of IDs. Packets are guaranteed to arrive in the same order they are sent

I'm confused. UDP doesn't guarantee that packets arrive in order - it doesn't even guarantee they will arrive at all.

[janisozaur]

There's some confusion in here. Let me clear all that up.

No, we do not use UDP, we use TCP only. See https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/network/network.cpp#L660

The packets are simply game commands, a function that alters game's logic state. See https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/game.c#L439

The only way you could do a server in Java* is by implementing full logic of the game (i.e. full and exact recreation of 0.0.4 bar the actual UI stuff) as this is what we sync right now over the wire, along with the tick, across all connected parties. See https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/network/network.cpp#L1824-L1891

*which is insane and ill-conceived idea. Certainly possible and doable, but I would bet almost any money you won't pull through.

[Broxzier]

Whoops my bad, I'm always confused between the two. TCP guarantees the order and that they arrive.

[Rammelkast]

12 hours ago, janisozaur said:

There's some confusion in here. Let me clear all that up.

No, we do not use UDP, we use TCP only. See https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/network/network.cpp#L660

The packets are simply game commands, a function that alters game's logic state. See https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/game.c#L439

The only way you could do a server in Java* is by implementing full logic of the game (i.e. full and exact recreation of 0.0.4 bar the actual UI stuff) as this is what we sync right now over the wire, along with the tick, across all connected parties. See https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/network/network.cpp#L1824-L1891

*which is insane and ill-conceived idea. Certainly possible and doable, but I would bet almost any money you won't pull through.

Okay, thanks.

[IntelOrca]

I have already written a C# library for connecting to multiplayer servers.

https://github.com/OpenRCT2/OpenRCT2net/tree/develop/src/OpenRCT2.Network

[zsilencer]

It is really simple,

2 bytes for packet size, 4 byte uint32 for command type, and the rest depends on the command.  Also, everything is converted to network byte order (big endian).