Development
rplace.tk has had a rocky development history. With such a high demand from 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 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 code, the 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.