Architecture Overview

Resonite is built on a novel engine architecture, which makes realtime networking, persistence and interoperability a solid guarantee without any extra work involved. At the core are various programming primitives, which are equivalents of variables, references, arrays, dictionaries, trees and other common building blocks, but designed so they can be automatically replicated over network or persisted. The engine itself is built from these building blocks, giving access and automatic replication to all of its core functions and components.

Currently a hosting unit is a world. Each world is a separate session to which other clients can connect to. Resonite automatically replicates the world and any changes to it in realtime to the connected users. Realtime replication uses highly efficient binary protocol, designed to save processing and memory resources as well as network bandwidth, at the cost of compatibility - it assumes that both clients have the same version of the code.

For persistence another serialization mode is used, which is designed for both forwards and backwards compatibility across Resonite versions. Any worlds or items saved in Resonite are saved in this format, which ensures that they can be safely opened with a different version of Resonite. Each world is saved to a single file, referred to by an URL, same as any other asset (texture, mesh, sound...).

At the moment the user who initially launches a world, whether it's starting a new one from template or opening a saved version, becomes the host, with other clients connecting to them. Resonite has a NAT punchthrough server to allows the clients to initially connect to each other even without a public IP and without opening ports, but all the subsequent communication is directly between the clients. There is also a packet relay server which is used as a fallback if NAT punchthrough fails.

Worlds can be saved either to local machine, when they are stored on the local harddrive or to the cloud, which synchronizes them with a corresponding "record" on Resonite' official servers and uploads the asset representing the serialized world data structure (as well as any other assets it references like textures and meshes). The assets are deduplicated, so referencing the same texture from multiple worlds only counts once against user's cloud quota and needs to be only uploaded once.

Each cloud record also has access information. By default the API server will refuse to send any information about the record unless the user is signed in and the record belongs to them. When publishing a world, the record is marked as public and can be submitted to a public listing, which makes it show up in a hub. Making it public lets other users download the asset representing the world and start a new instance of it.

Once new instance is started, any connections to that session use the realtime synchronization protocol, hosted on the person who opened the persisted world. Multiple users can start multiple instances from the same persistent copy. If the user also has write rights for the corresponding record (e.g. it belongs to them or their group), they can save the running instance and overwrite the previous persisted copy, affecting any subsequent instances open from that record. Users who do not own the world cannot overwrite it, but they can save their own copy if that's permitted by the world.

Resonite also has an asset gathering protocol, which can download assets from various sources. Assets can be stored on common http(s) and ftp servers and directly download from those by each client, or in the Resonite asset storage (resdb:// URL). When a new asset is first imported, a unique URL with local:// scheme is generated. Those are transferred completely within the session itself, without going through any Resonite servers.

When saving a world or item to any cloud location (e.g. cloud home, inventory or a message) Resonite creates a corresponding record and uploads any local:// assets to the Resonite asset database, overwriting the URL's to resdb:// in the process, so they can be downloaded by anyone without the need for the original hosting computer to be running and have an active connection.