How to publish a place

When building a place in the editor, scene data, scripts, and assets live on the local machine. Publishing serializes the place binary, uploads assets to content storage, and registers an immutable version record for dedicated servers.

Pipeline stages#

Publishing compiles, packages, and deploys place data:

The local tree holds entities, scripts, and assets. Serializing walks the hierarchy into a single place payload, which references bulk data by asset identifier. Cooking prepares every referenced asset and uploads only the ones that are not already in storage. The result is recorded as a numbered version (v14, for example), and matchmaking is pointed at that version, so fresh dedicated servers boot it. A joining client downloads the place snapshot and fetches any asset it is missing straight from the content storage CDN.

1. Serializing entity state#

First, the editor walks the live entity hierarchy and serializes the complete place data into a compact binary format. This serialization pass encodes:

• The hierarchical tree topology (every instance’s parent-child relationship).
• All component properties: 3D spatial transforms (Position, Rotation, Scale), physical properties (Anchored, mass, velocity thresholds, collision groups), and visual materials (Color, Transparency, Material).
• Attached Luau script source code and compiled bytecode.
• Entity tags and custom attribute tables.

2. Cooking assets and uploading to content storage#

Entities often reference external bulk binary data: 2D texture maps, 3D mesh geometries, sound audio buffers, and animation clips.

During publication, the asset pipeline scans all asset identifiers referenced throughout the entity tree. The cooker bakes assets into immutable packages and identifies each baked payload by its content hash (SHA-256), so two identical assets are stored once. The editor then queries Luduvo’s content storage to determine which hashes are already present:

• Assets that already exist in storage are reused without re-uploading.
• New or modified assets are compressed and uploaded directly to global content storage (CDN).

3. Generating an immutable place version#

Once the cooker stores all assets and uploads the binary place data, Luduvo’s backend creates a new immutable place version (e.g., Version 1, 2, 3…).

Place versions are strictly append-only and immutable: once published, the data for that version number can never be modified or overwritten. This immutability guarantees simulation stability and networking consistency:

• Every server spun up for Version 5 executes the exact same initial state and the exact same bytecode.
• Connected clients and servers never suffer from mismatched asset files or desynced script logic.

4. Updating server routing and matchmaking#

Finally, the deployment manifest for the place updates to point to the new immutable version:

• The matchmaking and orchestration system begins allocating new game server instances running the new version.
• When a player clicks Play, the routing service directs their client to a server running this latest version.
• Before the client enters the simulation, it downloads the serialized place snapshot and fetches any missing content-addressed assets directly from the content storage CDN.

Publishing from the editor#

To publish a place from the editor:

1. Open the place in the Luduvo Editor.
2. Open the File menu and select Publish to Luduvo.
3. In the publish dialog, provide a Name and Description for the place. If this is an existing place, the dialog confirms release of the next version.
4. Click Publish. The editor displays the progress of asset hashing, binary serialization, and network upload. Once complete, the new version is live.

Updating a published place#

To update a place, apply changes in the editor and publish again using the same workflow. The backend generates the next monotonic version number.

Running game servers will not abruptly kick active players; existing servers continue running their current version until the server shuts down or players leave. New game servers boot with the newly published version, and joining players load the update.

Testing before publishing#

Because publishing pushes changes to real players, always test locally first:

• Single-Player Test: Press Play in the toolbar to test player controls, mechanics, and camera behavior in a local 60 Hz loop.
• Multiplayer Test: Use the editor’s multi-client testing mode (under the Test tab) to spin up a local server and two or more simulated client windows. This verifies that your scripts properly respect server authority and that EventTables replicate data correctly across the network before you commit to a public release.

Where to go next#

With the place published and distributed across dedicated servers:

• Explore the API Reference for the complete specification of every engine service, class, and component type.
• Review Instances and Events to expand game mechanics with server authority.