One Cocos Build, Two Distribution Routes: Interactive Movies on Web H5 and Steam via Electron
A pre-rendered interactive movie can reach both a CDN page and a Steam installer from one Cocos build, but only when the Electron shell serves web-mobile over HTTP and keeps video files out of asar. The configuration here covers both targets without maintaining a second codebase.
Interactive movie games store most of their weight in pre-rendered video, so the build step is simple but the distribution problem is wide. The setup starts with Cocos Creator 2.4.15 producing a web-mobile static directory. H5 deployment uploads that directory to a server or CDN; the Windows/Steam route hands the same directory to an Electron main process that starts a minimal HTTP server on 127.0.0.1 with a dynamic port and calls loadURL. file:// loading is ruled out because Cocos loads settings.json through fetch/XHR, and a null origin under file:// triggers CORS and a blank screen.
The trickiest part is telling Cocos which port the local server chose. A preload script exposes window.__LOCAL_BASE__, or a URL query carries the base; VideoPlayer then uses resourceType REMOTE and sets remoteURL to base + videos/ep1.mp4. On H5 the base is empty, so the relative path still resolves. Video files are kept as standalone files in web-mobile/videos and copied through electron-builder extraResources instead of the default asar archive, because asar makes large files slow to read, blocks streaming, and forces a full file replacement on every update.
The Steam half covers AppID, DepotID, branch selection, and SteamCMD uploads through per-branch app_build vdf files, wired into a single npm release script. A troubleshooting table and pre-release checklist cover autoplay policy, path differences between __dirname and process.resourcesPath, and H.264 MP4 as the codec to avoid Windows decoder mismatches.
Cocos contributes only a static web directory, so Electron is not integrated into the game at all; it acts as a web server and browser window. That is why Steam packaging and web hosting can share every gameplay code path.
The dynamic port handoff is the part likely to generalize: any web-based renderer built without a known server URL needs the packaging layer to inject runtime configuration, either through preload or through a query string.
Electron's default asar packaging is built for small JavaScript apps; a media-heavy Cocos game breaks that default in a way that no amount of streaming inside asar can fix. Loose files in extraResources are the practical remedy, at the cost of a less tidy install directory.