Development: Difference between revisions

(4 intermediate revisions by 2 users not shown)

Line 4:

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: ===~~

Basic protocol and API documentation is made available on the rplace github at https://github.com/rplacelive/game/blob/main/PROTOCOL.md

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

~~This string data follows the following format as such for sending a packet from the client to the server~~:

~~* Name*~~

~~* Message*~~

~~* Channel*~~

* 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:

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

@@ Line 4: / Line 4: @@
 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: ===
+Basic protocol and API documentation is made available on the rplace github at https://github.com/rplacelive/game/blob/main/PROTOCOL.md
-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 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.
-This string data follows the following format as such for sending a packet from the client to the server:
- * Name*
- * Message*
- * Channel*
- * 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:
- * 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)