Skip to content
Myth Engine Try the free demoFree demo
Documentation

Publishing Problems

Find the first failed step between your saved project and the player’s game. Keep one accepted release for comparison, and test its complete files both locally and on the host.

Follow the Files

Myth checks the project before writing its export. A Web Folder contains the entry page, engine and game assets. Your host sends each requested file to the browser at its original path. The browser then starts the game.

This example uses My Game, starting in Main, from Publish a Web Game. Web Folder places the entry page and engine beside one another: index.html and babylon.min.js. A missing engine file stops startup, even when the entry page loads.

DiagramThe browser needs the complete release.
  1. My Game export

    Publish writes index.html, babylon.min.js and the supporting files.

  2. open

    Engine request: 404

    The host serves index.html but cannot find babylon.min.js. Main does not start.

  3. restore and reload

    Main starts

    The restored engine file returns JavaScript, and Main starts. Test input and reload.

Choose the Failing Stage

Keep the last complete export while investigating a failed replacement. Record the exact error. Then choose the matching stage below.

What happens Check Next step
Publish is unavailable Your edition and entitlement Read Licensing Terms. Playtest and Demo withhold publishing.
Run or export validation fails Read the diagnostic for the affected resource or typed connection. Repair it, then validate again.
Destination write fails Path, permissions, locks and replacement choices Read its error and Republishing.
The Web game fails after upload The first required request and its response Compare with the same complete folder served locally.
Native source appears The generated README Build through Desktop and Mobile Projects.
A built application fails Its logs, bundled files and platform requirements Repeat the smallest failing interaction in that application.

Changing a host’s files takes effect when it serves the replacement. Reload the game afterward. Changed project settings need another Publish first. Rebuild a native application after replacing its web payload.

Diagnose One Missing File

Before comparing the host, serve an unchanged copy of your complete Web Folder through local HTTP. Follow the local server instructions beside index.html. Keep that accepted output unchanged while comparing the host.

  1. Open the hosted game and its developer tools, then select the Network panel.
  2. Reload the page with Network open.
  3. Find the first required request that failed; this example reports 404 for babylon.min.js.
  4. Record its full URL, status and response type.
  5. Read Console for the matching startup error, then compare the requested path with your local release.
  6. Check exact spelling and filename case.
  7. Restore the complete release to that host, preserving folders, then reload the same address.
  8. Check that the engine request returns JavaScript. Wait for Main to start, then test input and reload once more.

The repaired example loads index.html and babylon.min.js with status 200. The engine file has a JavaScript response type. Main starts after loading finishes. Use your game’s first normal interaction, then test a complete round or level.

Upload every generated supporting file. Moving only index.html leaves the local engine behind. Separate assets and other generated files need their original paths too.

Read the Response, Then Choose a Repair

Check successful responses too. Some hosts return an HTML page for an unknown path. Inspect the response body and type.

Observation What to check Repair to verify
babylon.min.js returns 404 File presence, upload root and exact path Restore the complete release and request that path again.
That path returns 200 with HTML The host’s fallback or routing rules Serve the JavaScript file at its requested path.
Host policy blocks a request The browser’s policy error Adjust permitted sources, then retest.
Local HTTP works, hosting fails Uploaded files, paths, response types and cache state Compare the host with the accepted local output.
Both copies fail the same way Console output and the first failing game interaction Diagnose that shared failure before changing hosts.

For the HTML fallback case, the entry page can load while the engine fails. Restore the JavaScript response, then check startup again. Keep the first useful error when later messages follow it.

Check Caches and Outside Services

For an old release, compare the served entry file with your accepted output. Try a fresh browser session. Check PWA service workers and caches separately. Use the Web publishing guide for PWA choices and update checks.

Read the generated EXTERNAL-DEPENDENCIES.md and RELEASE-CHECKLIST.md when they accompany your output. Check authored remote services and custom runtime files too. CDN HTML loads its engine online; an exported server folder also needs its service running.

For silent browser audio, begin from player interaction and check the game’s Sound and volume settings. For native builds, follow the generated README’s exact toolchain error. Retest the installed application.

Where to Look Next

Publish a Web Game explains formats, complete output and local serving. Choose a Publishing Target links the target workflows. Republishing explains replacement decisions and preserved files.

Use Documentation Scope to find exact reference coverage and report a mismatch. For a complete game to compare, Weighted Maze: Finish a Route shows a repeatable route and its expected result. Use that lesson’s play checks. Keep its project separate from your release.

Myth Engine Documentation