How a game runs

Your game runs inside a sandboxed iframe on the platform's page. The page (the "parentframe") owns everything your game must not touch directly: authentication, matchmaking, the network connection to other players, and the download of your game's files. The @mugon/sdk bundled into your game is the only thing that talks to it.

The lifecycleCopy Anchor Link

1. The platform decides your role (host or client) and finds the game version to run.
2. It creates the iframe and connects to the network in parallel.
3. Your game's page loads the SDK first. Loading the SDK says hello to the platform.
4. The platform starts serving your game's files to the SDK (this is what makes big files cache well, see the file proxy).
5. Once the network is ready, the platform hands your game its context and the callback you passed to Mugon.start runs.
6. While your game loads, the platform shows a loading overlay. It closes when your game says it is playable (see loading progress).

Your callback never runs before the context exists, so there is no "wait for settings" phase: your game knows its role, its own id, the server's id and the peers already connected the moment it starts.

What your game must doCopy Anchor Link

• Bundle @mugon/sdk and load it before any other script on your page.
• Start everything from inside Mugon.start(async (ctx) => { ... }).
• Tell the platform when it is playable (ctx.progress.done()), unless your Mugon.start callback returns when the game is ready.
• Publish an index.html at the root of your distribution folder.

What you getCopy Anchor Link

• The same code path for hosts and clients: ctx.role says which one you are.
• Messaging between peers through the platform, with four delivery modes.
• Cached game files, even for hundreds of megabytes.
• A loading overlay you can feed with progress.

Start with getting started, or pick your SDK.