Publishing a game#

Publishing puts your game on Moud, where anyone can find it. It gets a page in the Moud home and on the website, with your pictures, a description and a Play button. A player who presses Play lands on one of your servers, and their game downloads what it needs on the way in, so they install nothing.

You publish from the editor with File > Publish. The first publish makes the game's page. Each later one sends a new version of the same game, and players move to it once it is accepted.

A version is not public as soon as you send it. It waits in a review queue until a Moud moderator accepts it, or refuses it with a reason. Until the first version of a game is accepted, only you can see the game.

Before you publish#

You need two things.

The first is your Minecraft account, which you already have. The editor signs in with the account Minecraft is running, the same way joining a server does, so there is no password to type. The first time you publish, this makes a Moud account for you.

The second is somewhere for the game to run. A game on Moud runs on your own machine, with moud fleet. The fleet needs the game's fleet key, and the key only exists once the game does, so the order is:

1. Publish the game.
2. Copy the fleet key from the game's settings page on the website.
3. Start the fleet with that key.

Players can press Play once a version is accepted and the fleet is running.

The game's page#

What players see on the game's page comes from File > Project Settings. The general fields at the top hold the name and how many players fit on a server, and the Page section holds the rest:

Write the description for someone deciding whether to play: what the game is and what you do in it. Pick a cover that shows the game being played, since it is what players see in the lists before they open the page.

The fields are saved in place.toml, the page ones in a [page] section:

1
2
3
4
5
6
7

name = "Lanternfall"
maxPlayers = 12

[page]
description = "Cross the village at night before the lanterns go out."
genre = "Survival"
pictures = ["res://page/cover.png", "res://page/street.png"]

A picture you choose from outside the place is copied into the place's page/ folder first, so it travels with the place. Each publish sends the page again, so a changed description or a new picture reaches the website with the next version you send.

Publishing#

Open File > Publish. Before anything is sent, the dialog runs the same checks as Export:

• the entry scripts and the start scene exist,
• every res:// path in scripts and scenes points at a file,
• every addon the place uses is installed.

A problem is listed in the dialog and stops the publish until you fix it. When everything passes, press Publish. The editor then:

1. compiles the players' scripts and builds the server bundle,
2. sends the pictures, the players' files and the server bundle to Moud, skipping every file Moud already has,
3. sends the version for review.

A script that does not compile stops the publish, with the file and the line, since players would only get a broken copy of it.

The second time you publish, only what changed goes up. A game whose music and pictures stayed the same sends a few scripts and is done.

The version shows in the dialog as waiting for review, see Review.

What players download#

A game has scripts that must stay secret. The server scripts decide who wins, how many coins a player gets and what a remote is allowed to do. A player who could read them could cheat, and a player who could change them on their own machine would change nothing, because the server runs its own copy. So Publish splits the game in two.

The players' files are what the player's game needs to show the game: client/, shared/, the scenes, the terrain and the assets of every place of the game. Server scripts are taken out. server/ is left out, the server entry script and the generation script are left out wherever they live, and the code of Script instances is removed from the scenes.

The server bundle holds everything, as you wrote it. Only your fleet, you and the moderators can download it.

Keep a module only the server needs under server/, so it stays out of the players' files. A module under shared/ or client/ reaches every player.

Both have one folder per place, named by its id, which is the layout a fleet runs:

1
2
3
4

lobby/place.toml
lobby/client/main.luau
arena/place.toml
arena/client/main.luau

What players get first#

Players do not wait for the whole game. Moud keeps each of the players' files on its own, and a player who presses Play downloads only what the game needs to start, then joins while the rest follows.

What comes first is every script, scene and data file, every file of 256 KB or less, and the pictures the start scene or the loading screen names. Sounds, videos and bigger pictures come after, a few at a time, while the player is already in. The loading screen only counts what comes first, so a game with an hour of music still starts in seconds.

A file the game asks for before it has arrived goes to the front of the queue. A sound you play starts as soon as its file is in, and isLoaded stays false until then. A picture stays blank and appears. A video starts once it has its file. files.read waits for the file, see Reading files.

When something must be there from the first frame, such as the pictures of your main menu, list it under preload in [loading], see Files players get first.

Compiled scripts#

Players get your client and shared scripts compiled to Luau bytecode, not as the text you wrote. The game runs the same, and an error still names the file and the line, as in client/main.luau:480: attempt to index nil, but the names of your local variables are gone and there is no source to open. files.read on one of your own scripts gives back the bytecode, not the text.

The server bundle keeps the source, so the moderators who review the game read what you wrote.

What this protects#

On a player's machine every file of the game is kept locked. Moud locks each one with a key that only the catalog can make, and hands a player the keys when they join, for as long as they play. A folder of game files copied to another computer, or opened while Moud is closed, is noise.

This is there to stop casual copying: someone grabbing your music, your art or your scripts out of their game folder. It does not stop a determined cheater. A player's machine has to hold the keys and the decoded files to run the game at all, and anyone patient enough can take them from memory, the same way they could from any game they play. So anything that matters stays on the server: who wins, what a purchase gives, what a remote accepts. Never trust what a client tells the server without checking it.

A game of several places#

A game of several places, such as a lobby and an arena, is published as one game from any of its places. The [game] section of place.toml lists the places, and the editor finds each one in the folder next to the open one, as described in Servers and games. Every place goes into both bundles.

Review#

The Publish dialog lists every version you sent, newest first, with the day you sent it. Each one is in one of three states:

• Waiting for review: a moderator has not looked at it yet.
• Accepted: players get this version. Your fleet hears of it within ten seconds and starts its new servers on it.
• Refused, with the reason the moderator gave. Fix what it says and publish again.

To help them decide, moderators see what the automatic checks found in the version: whether any server script would reach players, whether the game holds Java code, whether every file is there, and which websites its scripts talk to.

Players never see a version number. They see the game, and the game is whatever was accepted last.

Sending an update#

To update the game, change it and publish again. Players keep playing the accepted version while the new one waits for review, so a version that gets refused never reaches them.

Once the new version is accepted, the fleet starts new servers on it. Servers already running keep their version until their players leave, so nobody is thrown out of a match by an update. See Updating the game.

Once the game is live#

Next to Settings, your game's page on the website links to two more pages only you and the moderators see, Badges and Analytics. They are also tabs of the settings page.

Badges is where you make the game's badges, each with a name, a description and a picture. A badge does nothing until a server script hands it out with game.badges:award, and players then see it on the game's page and their profile. Make the badges before you publish the version whose scripts award them, since awarding a badge that does not exist yet fails. See Badges.

Analytics shows how the game is doing over the past day, week or month: visits, unique and new players, how many play at once, how long they stay, how many come back the next day and a week later, where they found the game, and how many of your servers crashed. Moud counts those by itself from the moment the game is public. Below them is a table of the custom events your server scripts send with analytics.event, and the funnels you build with analytics.step. Every number there is a total; you never see what one player did. See Analytics.

Which game a place publishes to#

The editor remembers which game the place was published as, in .moud/catalog.json inside the place. That is how the second publish knows to send a new version of the same game instead of making a new one. Keep that file, and copy it along if you move the place to another computer. Without it, the next publish makes a new game with a new page.