Hosting & Deployment

Doodle Engine games are web applications. A production build contains static HTML, CSS, and JavaScript that can be published on a static web host, with no server-side software to run. This guide takes a finished project from build to publish. You need a project that passes validation, plus the toolchain of whichever wrapper you choose for the desktop and mobile sections.

Studio users can produce the same dist/ output with the Build button, described in Validate, Preview, and Build. Everything after the build step is identical for both workflows.

Building for Production

npm run build        # or: yarn build / pnpm build

This produces a dist/ directory containing:

• index.html: entry point
• assets/: bundled JavaScript/CSS plus copied game images, audio, and video
• api/content: game content data
• api/manifest: list of game media used by the application
• asset-manifest.json: human-readable copy of that media list
• sw.js: service worker, a browser file that caches the game for offline play

Game assets from your project root assets/ folder are copied into dist/assets/ during npm run build.

The build uses relative URLs throughout, so the same dist/ works at a domain root (https://mygame.example/) or under a folder (https://example.com/games/my-game/). No configuration is needed for either.

Offline play

sw.js caches the app, the game content, and the media the first time a player loads the game. After that first visit, the game opens and plays without a network connection. Each new build refreshes the cache the next time the player is online.

Static Hosting

The build output is fully static. Upload the dist/ folder to any static host. Most hosts need:

• Build command: npm run build
• Publish directory: dist

Desktop Packaging

Doodle Engine games can be packaged as desktop applications with a web-to-desktop wrapper.

Caution

Configure the wrapper to serve dist/ through a small local HTTP server. Opening index.html directly through a file:// address prevents the browser from loading the game’s content, so the game appears broken even though the build is fine.

Electron: runs your game in a desktop window powered by Chromium, the browser engine used by Chrome:

1. Create an Electron main process that serves the existing dist/ output from a local HTTP server and opens a window pointed at it (Electron’s protocol.handle or a small http server both work).
2. Package with electron-builder or electron-forge.

Tauri: runs your game in the operating system’s built-in webview, the component used to display web content inside an application:

1. Point Tauri’s web asset configuration at the existing dist/ directory.
2. Build with tauri build.

Mobile Packaging

The production dist/ output is a standard web application, so it can also be wrapped for mobile distribution using web-to-native tools.

Most tools in this space (such as Capacitor or Cordova-based solutions) follow a similar pattern:

1. Configure the mobile wrapper to use dist/ as its web root.
2. Build and sign for iOS or Android through the wrapper’s toolchain.

Check the documentation for whichever tool you choose, as setup steps and platform requirements vary.

Check the Build Before Uploading

Run npm run preview after building. It serves the actual dist/ folder locally, so what you see is what the host will serve, including the content and manifest endpoints. Play far enough to confirm assets load and a save works, then upload. If the hosted game misbehaves in ways the preview did not, the difference is almost always host configuration rather than the build.