The OpenRCT2 Forums have been archived. Registrations and posting has been disabled. Jump to content

Multiplayer Protocol


Recommended Posts

Posted

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.

Posted
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?

Posted (edited)
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 by Rammelkast
Posted (edited)

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 by Broxzier
Was confusing UDP with TCP.
Posted
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.

Posted

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.

Posted
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.

  • 2 weeks later...
Posted

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).

×
×
  • Create New...