weBumpdevelopers

LESSON 07 OF 07 · RACING TUTORIAL

Export, test and publish

Finish the integration and know what to check on real devices.

1. Export the complete game

Install export templates matching your Godot editor. Keep the demo’s single-threaded Web preset, Compatibility renderer and custom web/shell.html. Export to build/web/index.html from the editor, or run:

mkdir -p build/web
godot --headless --path . --export-release Web build/web/index.html

Use your Godot executable’s full path if godot is not on PATH. Upload all generated files together. Edit the source shell and export again; edits to generated HTML are overwritten. See Godot’s Web export guide for server and browser requirements.

Host the export at the exact FRAME_URL from lesson 3, then load your host page. Serve modules and WASM with the correct content types. Scope script, API and frame permissions to their pages; a restrictive callback page needs no game engine, API requests or third-party assets. If you change to a threaded export, reassess cross-origin isolation and callback behavior.

2. Test the connection matrix

Where you run itExpected result
Godot editorMock profile and synthetic rivals; no live OAuth.
Host page on iPhone/iPadOpen weBump → approve → generic callback → return to original tab. No matching code.
Host page on computerQR and short code → scan/compare/approve on iPhone → game connects.
Direct local or native demo exportReviewed device approval; no host callback bridge.

Test with a weBump build that supports the requested connection methods and consent controls. Browser automation can exercise the protocol and frame bridge, but it cannot prove the physical Safari → weBump → Safari handoff. Repeat it on actual target devices before release.

3. Test recovery and privacy

4. Troubleshoot one layer at a time

My phone still shows a matching code

Open the host page rather than the export directly. Check that HOST_ORIGIN, the frame URL and callback origin match, both methods are approved, and the export contains the updated shell. Direct exports use device approval intentionally. Do not disable its matching-code consent.

The callback says the original tab could not be reached

Keep the initiating tab open, use the same browser/profile, and make the host and callback share an origin. Check the exact callback path, including trailing slash or .html redirects. Start a fresh connection after correcting it. Do not try to recover codes through /oauth/pending.

No stats on the weBump profile

Approve the capsule and showcase field definitions, not only their scopes. The demo resends saved best stats when connecting. Check “Show on my profile” in Connected Games and inspect the results-card sync status for rejected writes.

No visitors or replay appears

Connect before the bump and wait for the reveal delay. Check current basic sharing, blocks and exclusions. For selected data, both players need this game; enable consent and publish before a new bump. A publication created afterward cannot fill old references.

A write returns 403, 409 or 429

For 403, check the returned error, approved scope and relevant player consent. For 409, preserve your draft and merge against fresh state. For 429, obey Retry-After and avoid parallel polling loops. Don’t repeatedly reconnect or replay a consumed refresh token to work around these errors.

5. Publish your own version

Deploy your export and host assets together, verify the live versions, and keep the callback URL stable. Update the reviewed launch URL/icon/fields if the game has changed. Publish your privacy/support pages and retain asset/code license notices. The demo’s repository license does not grant ownership of weBump branding; follow the button guidelines.

You now have the integration

A player can connect, keep private progress, meet eligible visitors and deliberately share one game-defined document. Use the API reference for endpoint details and project lifecycle guide for updates, exports, transfers and departure.