From a 3D game to Google Play

1. Create a small multiplayer game

Start with one action, one object, and short rounds. Add more features after two real players can finish a round.

1. Sign in to Projects with the account that will own the game.
2. Select New Project.
3. Enter a Title.
4. Select Phaser 4 — Realtime for a game that uses the platform lobby relay.
5. Select Create Project.
6. Wait for the workspace to connect and enable its controls.
7. Describe the game in the coding box. The example below is a starting point.
8. Select Start Coding.

The current Projects page shows creation controls only to administrators. If New Project is absent, your account needs creation access.

The template starts the project. Ask the coder to use Three.js for 3D rendering and the platform client for multiplayer.

Example prompt

Select and copy this text. Change the object and game idea before you start.

Build a simple mobile-friendly 3D multiplayer game with Three.js.
Use one large DROP button. Players take turns dropping toy ducks onto a tilting tray.
Use 60-second rounds for two to six real players. Add a clear score, rematch, and share button.
Add a separate Solo practice mode that can work offline.

Use the platform lobby client for real multiplayer. Do not simulate other players.
Make one host validate moves and share the same game state with every player.
Handle late joins, disconnects, duplicate moves, and host changes.
Show the room name and connection state. Do not claim a shared link guarantees the same room.

Generate one textured yellow toy duck with request_model. Reuse an existing suitable project model if available.
For new objects, set geometry_profile: prop for simple props, standard for complex objects, or character for detailed characters.
Use sync_models to import the completed GLB. Use its returned local path.
Use import_threejs for the local Three.js files and load the GLB with GLTFLoader.
Keep the duck's materials and textures. Add its scale, placement, collision, and game behavior in code.
Do not substitute a placeholder if model generation fails. Show the error.

Keep all game assets local for a bundled Android build. Do not use runtime CDN imports.
Use large touch controls and safe screen margins. Test portrait and landscape layouts.
Use the platform lobby client's network and score methods for bundled Android support.
Do not assume that the app has a website login.

Add tests for turn order, timing, scoring, rematches, and player departures.
Keep files small and separate. Preserve working code when you make a change.
Do not add ads, purchases, chat, or tracking services.
Stop after the game is ready for review. Do not publish automatically.

The coder can need several passes. Test each pass before requesting more features.

Keep this browser workspace open while the coder runs. Wait for it to finish before editing the same files.

Local files, saved checkpoints, and publication

Apply local edit updates the browser cache. It does not create a Git commit or publish the game.

Save workspace, in the Files section, creates a private Git checkpoint. The coder also requests a checkpoint when it finishes.

Publish saves the workspace and updates the public web game. Android builds use that published version.

A lost connection stops the coder before its next tool call. Reconnect preserves unsaved local files when Git still matches their baseline.

If both copies changed, the editor reports a conflict. Use Export cached files to keep a recovery copy.

Do not clear browser storage during recovery. Resolve the reported conflict before saving or publishing.

2. Create, inspect, and import 3D objects

A generated model is an object file, not a complete game. The coder adds movement, collisions, animation, and multiplayer behavior.

Create inside a project

1. Open the project's 3D models section.
2. Enter one complete object in Describe one game object. Include its shape, colors, and materials.
3. Select a Geometry profile. Start with Prop for a simple object.
4. Select Create model.
5. Wait for completion. You can continue editing while generation runs.
6. Select View 3D. Rotate and zoom the object to check every side.
7. Select Import to put the model in the active workspace.
8. Give the displayed local path to the coder. Ask it to place the model in the scene.

Create a standalone model or reuse one

1. Open 3D Models for the standalone collection.
2. Enter a description and select a Geometry profile.
3. Select Create 3D model.
4. After completion, select View model or Download GLB.
5. Select Add to project to choose an existing project.
6. Return to that project's 3D models section and select Import.

Adding a library model to a project does not import it into the game. Import it before you publish.

The standalone collection does not include project models. Use View project models to open a project's collection.

The editor's Model library link also opens its project collection. New models created there belong to that project.

Choose the geometry and inspect the result

Pixal3D generates the 3D models. No provider selection is required.

Pixal3D mesh work is free during the beta. The reference image still uses its normal image price.

Pixal3D requests enter the normal durable queue. You can submit a batch and close the terminal.

Use --target-faces and --texture-resolution to control game delivery size.

Targets are approximate. Check the exported triangle count in the viewer. UV seams can add render vertices without adding new surface positions.

More vertices do not guarantee sharp edges. The reference image, reconstructed shape, shading, and textures each affect the result.

A low-poly prompt alone does not set the mesh budget. Select the geometry profile too.

1. Open the model preview and rotate the object to check all sides.
2. Use Solid to check the shape without its textures.
3. Use Wireframe to see the triangle edges.
4. Check the render vertex count, triangle count, materials, and texture dimensions.
5. Open the texture and UV controls to inspect how the mesh uses each texture.

These controls inspect the file. They do not edit or simplify it. A different generation profile creates a new model.

View the Pixal3D, DINOv3, and SF3D license records.

Try a complete Asset Yard game

Voidwake: Meridian Run uses four generated Pixal3D models, music, seven sound effects, and key art.

The demo exposes its Asset Yard manifest and generation records. Use its development edition only to compare procedural assets.

What the platform stores

Uncen stores the source model in its media database and S3 storage. The GLB contains its shape, materials, and textures.

Multiplayers links the model to your library or project. Import copies the GLB and its license record into the game files.

Publish includes that copy in the web game. A bundled Android build includes the published copy.

Keep the imported license records with the game assets. See the 3D model license page for provider attribution.

Published game assets are available to players. Do not put private keys or other secrets in game files.

3. Publish and test the web game

Web publication and Google Play publication are separate actions. The project editor's Publish button updates the web game.

The editor's public switch controls the website listing. An unlisted game's link is not private access.

1. Wait for the coder to finish.
2. Check that the required models show as imported.
3. Select Publish in the project toolbar.
4. Wait for the publication confirmation.
5. Select Play to open the published game.
6. Finish a solo round, if the game includes solo mode.
7. Open the same published link on a second device or in a separate browser.
8. Join multiplayer on both devices. Check that both show the same room and the correct player count.
9. Make moves from both devices. Check that the objects, turn order, timer, and scores agree.
10. Test a rematch. Then disconnect one player and check the game's response.

Use at least three players when you test host changes. Keep two players connected after the host leaves.

In a two-player game, one departure can correctly end multiplayer instead of transferring the host.

A shared game link opens the game. It does not guarantee an exact room unless the game implements room invitations.

Give the coder a specific failure: the device, the action, the expected result, and the actual result.

Publish again after a fix. Android builds use the published game, not unpublished editor changes.

4. Build a signed APK or AAB

Open your project, then select Google Play in its toolbar. This opens Android and Google Play.

1. Wait for The host is ready for signed Android builds.
2. Check the Android package ID before the first build. It identifies this app permanently.
3. Set Artifact to Signed release APK (.apk) for your first phone test.
4. Set a Version name, such as 0.1.0-test.
5. Leave Version code empty to allocate the next code.
6. Choose the game's Orientation.
7. Set Game content to Bundle the published static game for local game files.
8. Select Build signed release.
9. Wait for succeeded in the build table.
10. Select Download beside that build.

The first signed build creates a durable upload key and fixes the package ID. Later builds use that key.

Each build attempt reserves a higher version code. Failed builds can leave gaps. Do not reuse an old code.

Choose the right content mode

Bundle the published static game makes a fixed copy. Local assets can work offline, but multiplayer still needs internet access.

Load the published game URL loads the website. It needs a connection and retains the website's login behavior.

5. Install and test the APK on your phone

Use an Android phone. An iPhone cannot install an APK. A successful build does not prove that gameplay works.

1. Open this site in Chrome on the Android phone.
2. Sign in as the project owner.
3. Open Projects, choose your game, and select Google Play.
4. Find the successful release_apk row with the intended version.
5. Select Download. Do not download the AAB for direct installation.
6. Open the downloaded APK.
7. If Android requests permission, allow installation from Chrome for this test.
8. Select Install, then Open.
9. After installation, turn off Chrome's permission to install unknown apps.

Android labels vary by device. Keep Play Protect enabled. Stop if it blocks the file and record the warning.

Google's instructions for installing apps from other sources

Phone test checklist

1. Check that the 3D objects have the expected shape, colors, and textures.
2. Check the touch controls, text, sound, screen edges, and supported orientations.
3. Complete a round and a rematch.
4. Open the published web game on another device.
5. Join multiplayer from the app and browser. Check the room, moves, scores, and results on both.
6. Test a disconnect and return. Check that the game shows the connection state correctly.
7. For a bundled build, close the app completely. Enable airplane mode. Reopen the app.
8. Test its local solo mode, if provided. Multiplayer must report that it needs a connection.
9. Turn airplane mode off and test multiplayer again.

Record the phone model, Android version, app version, and exact failure. Include a screenshot when possible.

Later, repeat these tests with the Google Play installation. Play can use a different signing key than the direct APK.

6. Set up the app in Google Play Console

Complete the first setup in your own Google Play developer account. The upload API cannot create the app or accept agreements.

1. After the APK test passes, return to the project's Google Play page.
2. Build Signed Android App Bundle (.aab) with the same package ID.
3. Download the successful release_aab build.
4. Open Google Play Console.
5. Select the Google account that owns your developer account.
6. Select Home → Create app.
7. Enter the app name, default language, and support email.
8. Select Game and your intended free or paid distribution.
9. Review the required declarations and signing terms. Accept them only if you agree.
10. Select Create app.
11. Open Test and release → Testing → Internal testing and create the first release.
12. Set up Play App Signing and upload the downloaded AAB.
13. Complete the release details and resolve the errors that Play Console reports.
14. Configure your testers and start the internal test.

You can start an internal test before completing the full store setup. Google limits internal tests to 100 testers.

Create and set up your app · First-upload API limits · Google's internal testing instructions · Play App Signing

You can keep uploading AABs manually in Play Console. Connecting an account below is optional for that manual workflow.

7. Connect your account for later uploads

This connection lets Multiplayers upload verified bundles to your app. Your Google password is not the connection key.

1. Select or create your Google Cloud project.
2. Enable the Google Play Android Developer API in that project.
3. Create a service account for this publishing workflow.
4. In Play Console, open Users and permissions and enter the service account's email.
5. Use App permissions → Add app to select only the intended app.
6. For testing, select View app information (read-only) and Release apps to testing tracks.
7. Grant production release permission only when you intend to submit public releases.
8. Select Invite user to save the access.
9. In Google Cloud, open the service account's Keys tab.
10. Select Add key → Create new key.
11. Choose JSON and select Create. Keep the downloaded key private.
12. Return to your project's Google Play page.
13. Under Connect your Google Play account, enter an Account label.
14. Optionally enter your Play developer ID. This ID does not grant access.
15. Select the file in Service account JSON key.
16. Select Save account connection.
17. After the first Console upload, select Check Play access.

Do not grant administrator or financial access for this workflow. Use Google's permission descriptions to select the required release permissions.

Linking the developer account to the Cloud project is no longer required. Manage tester lists yourself in Play Console.

The server encrypts the JSON key and does not return it to the page. This connection serves your projects on this site.

Do not paste the key into the coding prompt, game source, or a support message.

If your organization blocks key creation, ask its administrator. You can still use the manual Console upload steps.

The access check creates and discards a temporary Play edit. Avoid other editing tools for this app during the check or upload.

An access check verifies app access. It does not prove that every policy or production requirement is complete.

Google's API and service account setup · Play Console permission definitions · Create a service account key

8. Upload a later build to internal testers

Use internal testing before a public release. The app must already exist in Play Console with its first AAB uploaded.

1. Publish and test the latest web game.
2. Build a new signed AAB with a higher version code.
3. On the project's Google Play page, find Upload, test, or submit for public release.
4. Select that AAB under Verified bundle.
5. Set Action to Release to internal testers.
6. Enter the Release notes (English).
7. Type the exact package ID under Type the package ID to confirm.
8. Read and select the upload authorization checkbox.
9. Select Upload to Google Play and confirm the action.
10. Check the release history and Play Console for the result.

Save an internal-track draft uploads without rollout. Release to internal testers can replace the current internal test release.

Install through Google Play

1. In Play Console, add your testers to the app's internal test.
2. Copy the test's opt-in link and send it to those testers.
3. On the phone, open that link with an eligible tester's Google account.
4. Join the test and install the game from Google Play.
5. Repeat the phone test checklist.

Testers need the opt-in link. A draft has no usable opt-in link. An internal test is not a normal public store listing.

Tester setup and opt-in instructions

9. Submit for public review and release

Google controls production access and review. A working APK, an internal test, or a successful upload does not guarantee approval.

1. Complete the store listing, app icon, screenshots, and required contact details in Play Console.
2. Provide a public privacy policy that matches the actual app and its services.
3. Complete Data safety, content rating, app access, target audience, and all other required declarations.
4. Check every SDK, permission, network service, and data use before answering the declarations.
5. Provide working review instructions or review credentials if any game feature requires them.
6. Complete any required closed test and request production access.
7. Resolve the warnings and errors in Play Console.
8. Test the intended release from Google Play before submitting it for production.

Personal account testing requirements · Prepare an app for review

Submit from this site

1. Open the project's Google Play page.
2. Select the tested AAB under Verified bundle.
3. Set Action to Submit for public review and release.
4. Enter the release notes and exact package ID.
5. Select the upload authorization checkbox.
6. Read and select the separate public-release confirmation.
7. Select Upload to Google Play and confirm.
8. Open Play Console to check review and publishing status.

10. Update the same game

1. Open the existing project. Do not create a replacement project for an app update.
2. Ask the coder for a focused change. Preserve the working multiplayer and model paths.
3. Publish and repeat the web tests.
4. Build and test a new APK when the change needs device checks.
5. Build an AAB with the same package ID and upload key, plus a higher version code.
6. Release to internal testers first.
7. After testing, submit the intended AAB for production when you are ready.

The version name is a readable label. The version code must increase. The project keeps the signing identity across builds.

Bundled installs do not receive web changes automatically. Distribute a new APK or Play release to update those files.

Republish and distribute a new bundled build before its one-year lobby token expires.

Do not delete signing records to fix an error. A signing mismatch needs a deliberate recovery plan.

Troubleshooting

New Project or the build controls are missing

Check that you signed in with the project owner's account. The current Projects page shows creation controls only to administrators.

Build controls can also report missing server setup. Record that message. Changing the game prompt cannot repair server configuration.

The coder stopped before the game was complete

Check the last status and the saved files. A stopped run does not mean that it discarded all work.

Ask it to continue the unfinished parts and preserve the working code. Include the specific error or missing feature.

The model is pending or does not appear in the game

Check its status in 3D models. A generation can continue after the coder's wait ends.

After completion, use View 3D, then Import. Check the returned local path and publish again.

If the viewer works but the game does not, ask the coder to check loading, scale, lighting, camera, and placement.

Do not request duplicate models just because a wait ended. Record a failed request's message before trying again.

The two devices do not share the same game

Check the published link, room name, player count, connection state, and app version.

A bundled app can contain older code than the website. Publish, rebuild, and retest the intended version.

A shared game link alone does not guarantee the same room. Ask the coder for explicit invitations if the game needs them.

The browser works, but the bundled app cannot connect

Check the phone's connection and the bundled token's age.

Ask the coder to use the platform lobby client for network and score requests. Website-relative API requests can address the app's local origin.

Do not expect the bundled guest identity to use a website login or account-linked save.

The APK will not install, or Play reports a signing conflict

Confirm that the file is an APK from a successful build. Record Android's exact error.

A direct APK and a Play installation can use different signing keys. An older version code can also prevent installation.

Do not disable Play Protect or delete signing records. Do not uninstall blindly: removal can erase local progress and guest identity.

Use a separate test device or plan the data loss before replacing an installation.

A build request timed out

Return to the project's Google Play page and inspect the saved build status. The build might still be running.

Do not start another build until its status is clear. A failed build can consume a version code.

Play Console shows registration, or Check Play access fails

Select the Google account that owns the developer account. Select the intended app.

Check that its first AAB exists in Play Console. Confirm the service account has access to that exact app.

Check the enabled API, package ID, and release permissions. A developer ID alone does not grant access.

A tester cannot find or install the internal release

Check the tester list, release status, opt-in link, and Google account on the phone.

Use the test link instead of searching the public store. Check for a direct-APK signing conflict before replacing an installation.

The upload failed or has an uncertain result

Read the release history and Play Console before retrying. An interrupted response can follow a completed upload.

For commit_unknown, stop and request operator review. Do not submit repeated uploads or assume the release failed.

Do not use another publishing tool for the same app during an active upload.

Google accepted the upload, but the game is not public

Check the selected track, review status, production access, and managed publishing in Play Console.

A draft does not roll out. An internal release reaches eligible testers. Submitted does not mean live.

Before you call the release ready

• The published game loads the real 3D models and their textures.
• Two real devices agree on the room, moves, scores, results, and rematch.
• The game handles late joins, disconnects, and any supported host changes.
• The intended APK passes a phone test.
• The intended AAB uses the correct package ID, signing identity, and version code.
• Eligible testers can install and play through Google Play.
• The store listing and declarations match the actual app.
• Play Console confirms the intended release status.

This guide describes the workflow. Each game still needs its own tests and release review.