Native Web Quickstart

Summary: Building for Buncha Games

Get set up: request or activate developer access, then choose Developer Dashboard upload or create a Buncha Games CLI token if you are using CLI.
Add @bunchagames/sdk when you want player identity, analytics, Buncha Credits, wallet/IAP, entitlements, ads, or sandbox test flows. Deployment can proceed without SDK hooks.
Build a static browser output folder from your web project, then test the output with a local static server before zipping, then check package size and first-load assets.
Prepare listing media and metadata: title, descriptions, controls, thumbnail, hero image, screenshots or video, and any connected services.
Upload the ZIP through the Developer Dashboard or Buncha Games CLI after index.html and bundled runtime assets are at the ZIP root.
Manage the game after upload: preview Sandbox, fix validation issues, update media/info, submit for review, and check analytics after the game is live.

For Phaser, Three.js, Vite, and similar stacks

Most native web projects produce a static output folder such as dist or build. Test that folder over HTTP, then zip its contents.

npm run build
npm run preview

# Then zip the contents of dist/ or build/ so index.html is at ZIP root.

Vite asset paths

If a Vite build works locally but assets disappear after upload, make the build use relative paths before rebuilding.

// vite.config.js
export default {
  base: "./"
};

Optimization check

Use /developers/docs/optimizing-for-web before upload if the build ships large images, audio, source assets, all of public/, or a very large first JavaScript chunk.
For Phaser, keep preload scopes tight, use Scale Manager intentionally, and avoid loading match-only assets before the first menu or playable moment.
For Three.js, use instancing for repeated objects, cap renderer pixel ratio, dispose old resources, and avoid expensive postprocessing on low-end devices.
For Vite, use production builds, relative asset paths when needed, and an explicit runtime asset allowlist instead of copying source/reference assets wholesale.

SDK install

The web SDK package gives TypeScript types, local mocks, and a safe facade that delegates to window.buncha on Buncha Games.

npm install @bunchagames/sdk

import { buncha, installLocalBunchaMock } from "@bunchagames/sdk";

What to package

Common output folders are dist, build, public, out, or export.
Keep index.html, bundled JavaScript, CSS, WASM, data, and assets together.
Use relative asset paths or a Vite base setting that works when the game is hosted inside the Buncha Games play wrapper.
Verify the canvas, audio unlock, fullscreen/orientation behavior, and asset URLs from the local static-server preview.
Do not upload source folders, .env files, node_modules, secrets, local caches, or server-only files.
Disclose external domains before review if the game calls APIs, multiplayer, storage, analytics, or other services.

Final pre-upload check

The production output loads from a local static server.
Browser dev tools show no missing scripts, textures, audio, fonts, WASM, or JSON assets.
The ZIP root contains index.html at the first level.
The ZIP is under 200 MB.
The ZIP does not include source folders, node_modules, .env files, secrets, or server-only files.
Any external APIs, multiplayer hosts, storage, analytics, or CDN asset hosts are ready to disclose.

Upload choices

Doing it yourself: build the static browser output, test it locally, ZIP the output contents, then upload through the Developer Dashboard.
Using repeatable commands: use /developers/docs/cli after your exported ZIP and listing media are ready.
Using an AI coding agent: start from /developers/docs with the AI workflow selected so you get the right prompt library.

Native Web agent prompt

You are preparing my native web browser game for Buncha Games.

Read:
- https://bunchagames.com/developers/docs/native-web-quickstart
- https://bunchagames.com/developers/docs/uploading-games
- https://bunchagames.com/developers/docs/sdk

Tasks:
- Inspect this repo to identify the stack, package manager, and production build command.
- Run the normal production web build.
- Test the static output folder from a local static server.
- Create a ZIP from the output contents so index.html is at the ZIP root.
- Exclude source folders, node_modules, .env files, secrets, server files, caches, and unrelated files.
- If I ask for SDK integration, install @bunchagames/sdk and keep SDK calls fail-soft.

Return commands run, output folder, ZIP path, top-level ZIP tree, local smoke result, and any blockers.

All docs Request invite

Summary: Building for Buncha Games

Get set up: request or activate developer access, then choose Developer Dashboard upload or create a Buncha Games CLI token if you are using CLI.

Add @bunchagames/sdk when you want player identity, analytics, Buncha Credits, wallet/IAP, entitlements, ads, or sandbox test flows. Deployment can proceed without SDK hooks.

Build a static browser output folder from your web project, then test the output with a local static server before zipping, then check package size and first-load assets.

Prepare listing media and metadata: title, descriptions, controls, thumbnail, hero image, screenshots or video, and any connected services.

Upload the ZIP through the Developer Dashboard or Buncha Games CLI after index.html and bundled runtime assets are at the ZIP root.

Manage the game after upload: preview Sandbox, fix validation issues, update media/info, submit for review, and check analytics after the game is live.

Optimization check

Use /developers/docs/optimizing-for-web before upload if the build ships large images, audio, source assets, all of public/, or a very large first JavaScript chunk.

For Phaser, keep preload scopes tight, use Scale Manager intentionally, and avoid loading match-only assets before the first menu or playable moment.

For Three.js, use instancing for repeated objects, cap renderer pixel ratio, dispose old resources, and avoid expensive postprocessing on low-end devices.

For Vite, use production builds, relative asset paths when needed, and an explicit runtime asset allowlist instead of copying source/reference assets wholesale.

What to package

Common output folders are dist, build, public, out, or export.

Keep index.html, bundled JavaScript, CSS, WASM, data, and assets together.

Use relative asset paths or a Vite base setting that works when the game is hosted inside the Buncha Games play wrapper.

Verify the canvas, audio unlock, fullscreen/orientation behavior, and asset URLs from the local static-server preview.

Do not upload source folders, .env files, node_modules, secrets, local caches, or server-only files.

Disclose external domains before review if the game calls APIs, multiplayer, storage, analytics, or other services.

Final pre-upload check

The production output loads from a local static server.

Browser dev tools show no missing scripts, textures, audio, fonts, WASM, or JSON assets.

The ZIP root contains index.html at the first level.

The ZIP is under 200 MB.

The ZIP does not include source folders, node_modules, .env files, secrets, or server-only files.

Any external APIs, multiplayer hosts, storage, analytics, or CDN asset hosts are ready to disclose.

Upload choices

Doing it yourself: build the static browser output, test it locally, ZIP the output contents, then upload through the Developer Dashboard.

Using repeatable commands: use /developers/docs/cli after your exported ZIP and listing media are ready.

Using an AI coding agent: start from /developers/docs with the AI workflow selected so you get the right prompt library.

Native Web agent prompt

You are preparing my native web browser game for Buncha Games. Read: - https://bunchagames.com/developers/docs/native-web-quickstart - https://bunchagames.com/developers/docs/uploading-games - https://bunchagames.com/developers/docs/sdk Tasks: - Inspect this repo to identify the stack, package manager, and production build command. - Run the normal production web build. - Test the static output folder from a local static server. - Create a ZIP from the output contents so index.html is at the ZIP root. - Exclude source folders, node_modules, .env files, secrets, server files, caches, and unrelated files. - If I ask for SDK integration, install @bunchagames/sdk and keep SDK calls fail-soft. Return commands run, output folder, ZIP path, top-level ZIP tree, local smoke result, and any blockers.