Revision as of 14:29, 24 October 2023

rplace.tk has had a rocky development history. With such a high demand for different things, features have remained broken, scrapped or non-existent for long periods of time. Despite these issues, with the 10+ contributors to the main project, lead mostly by zekiahepic, and initially BlobKat. The site has found a relatively stable update cycle, with new features, fixes and bug improvements appearing each fortnight.

The game protocol

The site was initially coded within a day, and main development, jump started by BlobKat over three. This has had many long lasting impacts on the site, resulting in some development decisions that made sense for that short term period, but have proved very complicated and confusing in the long term. One of the biggest impacts was the choice to use "git and changes system", for syncing the canvas between the client and server, while also ensuring minimal bandwidth on the hoster's behalf. Further complicated by the introduction of the new server software, RplaceServer, which chose to use a completely new system, wherein the site is solely dependent on the monolithic server software, which handles both the socket live pixels, and hosting the canvas files directly for client consumption in a compressed form.

Packets

The site uses websocket for live client server communication. All packets are composed of an initial code byte, representing the type of the packet to be identified on the server, with all numberic packet data being formatted as big endian.

Pixel packet:

The pixel packet is one of the simplest. It is a six byte packet, the first byte being the packet code, the second to 5th bytes being position (board index) of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the colour in the palette that the pixel represents.

One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do index % canvas_width, and to get the Y position floor(index / canvas_width).

Chat history packet

The chat history packet is used to ask the server to load a certain set of messages from the database, for example, in the context of attempting to load previous chat messages from before a client connected to the game session when scrolling up in the chat history.

* (u8) packetCode = 13
* (u32 fromMessageId (if it is set to message ID 0, and you are asking for messages sent BEFORE this message ID (see next byte), it will actually just give you messages relative the most recent messageId in the channel (see last n bytes))
* (u8) message count AND before|after (last 7 bits will tell the server how many messages you want since that message id, first(most significant) bit will tell the server if you want all messages BEFORE or AFTER that message ID)
* (n bytes) name of chat channel as a UTF8 encoded string

MessageId ascends as new chat messages are sent, so greater message ID = more recent.

@@ Line 13: / Line 13: @@
 One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do '''index % canvas_width''', and to get the Y position '''floor(index / canvas_width)'''.
-=== Chat packet ===
+=== Chat history packet ===
-The chat packet is the epitome of new features being bolted onto an old system, consisting of the first byte as the packet '''code''', then the rest, UTF-8 formatted string data separated with newlines for each section of the message payload.
+The chat history packet is used to ask the server to load a certain set of messages from the database, for example, in the context of attempting to load previous chat messages from before a client connected to the game session when scrolling up in the chat history.
-This string data follows the following format as such for sending a packet from the client to the server:
+  * (u8) packetCode = 13
-  * Name*
+  * (u32 fromMessageId (if it is set to message ID 0, and you are asking for messages sent BEFORE this message ID (see next byte), it will actually just give you messages relative the most recent messageId in the channel (see last n bytes))
-  * Message*
+  * (u8) message count AND before|after (last 7 bits will tell the server how many messages you want since that message id, first(most significant) bit will tell the server if you want all messages BEFORE or AFTER that message ID)
- * Channel*
+  * (n bytes) name of chat channel as a UTF8 encoded string
- * Type ("live"|"place", optional, will default to live)
-  * X (e.g. "1234", optional, only needed if type == "place")
-  * Y (e.g. "5678", optional, only needed if type == "place", if X exists, Y must also)
-Most server softwares should reformat incomplete chat packets so that they can be correctly consumed by a client, but precautions should be taken by the client. When recieving a chat packet from the server, expect it to look like this:
+MessageId ascends as new chat messages are sent, so greater message ID = more recent.
- * Name (If a verified name system is being used, a ~ will be appended to the end of their name if using a verified name without authentication to show the client that they are likely impersonating, while a "✔" will be appended to alert the client that this is the verified owner of such name)
- * Message
- * Channel
- * Type
- * X
- * Y
- * Uid (A unique identifier for the chatter that is persistent across different usernames, etc. Most commonly based off a hash of the user's IP and used for moderation purposes)