Game mode
Build playable 2D and 3D games with engine-aware assets and Supabase-backed progress.
Switch to Game
Select Game in the composer, then describe the player fantasy, genre, controls, visual direction, and any leaderboard or progression you want. Game mode can edit the app and supports Undo like Build mode.
It plans before editing
Every Game run first creates a concrete plan for the core loop, inputs, engine choice, asset manifest, HTML/CSS HUD, game states, Supabase tables and RLS, performance, and verification. Its first tool pass is inspection-only before it can change source or backend, and only successful inspections unlock editing.
The right engine + native mobile shell
- Three.js handles real 3D, Phaser 4 handles most complete 2D games, and PixiJS handles bespoke 2D rendering.
- HTML and CSS render loading, HUD, pause, settings, errors, and game-over UI.
- Touch controls, keyboard preview controls, lifecycle cleanup, context-loss recovery, resizing, and drawing-buffer limits are part of the build.
- Game source must pass a deterministic contract for a pinned engine import, one engine-owned loop, required states, cleanup, Supabase idempotency, and the runtime probe before it can be saved.
- The Appify shell still owns safe areas and navigation in preview and exported native apps.
Asset production
Each blueprint includes a style bible and asset manifest. The agent builds a playable fallback first, then can generate or use uploaded images, sprites, models, and sounds; optimize them for their engine role; inspect mobile readiness; wire durable Assets URLs; and track what is ready or blocked. The manifest lives in the game feature settings and does not create another database.
Connect Pixio as a first-class asset platform
Appify's Gemini-backed image generator remains the default for raster 2D art, sprites, textures, backgrounds, icons, and interface imagery. Pixio is a separate first-class platform integration for its live model catalog: 3D models, sound effects, music, video, SVG, rigging, animation, 3D processing, image-to-3D, and specialist provider transformations. Pixio image models are used when you explicitly request one or when Gemini's image path does not provide the required operation.
Pixio is bring-your-own-key: generations and workflow runs use your Pixio account, Pixio bills any provider credits directly, and Appify deducts 0 Appify credits. Appify still shows the live Pixio estimate and asks for approval before a provider start. This does not replace or change Gemini image generation or its existing Appify credit pricing.
- Open Pixio, choose Integrations, and create an API key.
- In Appify, open your project and select the Game tab.
- Find Connect Pixio to unlock advanced Game Mode assets, paste the key beginning with
pxio_live_, and select Connect Pixio. This is a Pixio key; Gemini image generation remains managed by Appify.
Appify verifies the key and stores it as the encrypted server credential PIXIO_API_KEY. It is never included in game code, source exports, or mobile builds. After connecting, ask for an asset normally or name a model. The agent checks the live catalog and required inputs, shows the credit estimate, and waits for approval before starting paid work.
Pixio runs through Appify's first-party asynchronous job boundary. Appify fingerprints the exact request, checkpoints the returned Pixio content ID in its existing operation ledger, polls separately, and imports successful output into Appify Assets. Closing the editor does not require another paid start: a later Game Mode run can rediscover and resume the saved job. If a provider start ends ambiguously before returning an ID, Appify reconciles recent Pixio history and does not blindly resubmit it.
Model choice is live, not memorized. Game Mode reads the models visible to your Pixio account, matches the job's output type and available input media, and reads GET /api/v1/params for shortlisted models. When several models fit, it compares required inputs, capabilities, and Pixio-credit tradeoffs. Estimate and start requests are rejected server-side if they contain an unknown parameter, omit a required input, change a declared primitive type, or use an invalid returned option.
Supabase is always the backend
Game mode uses Supabase for player identity, durable progress, runs, scores, achievements, and leaderboards, with explicit RLS. Connect the publishable Supabase values plus the encrypted database URL and secret key in Backend for live provisioning and two-user policy tests. Without a connection, the agent can build the game and save the exact backend definitions as a pending resume manifest, but will mark live persistence and leaderboard behavior as blocked. Appify reuses the app's existing Supabase project and Appify database; Game mode does not create a second database or a permanent RLS probe table.
What Game mode proves
- A non-consequential browser harness tests restart, pause, resume, teardown, one-loop behavior, listener cleanup, frame time, renderer budgets, and a nonblank canvas.
- Supabase security tests use two temporary users and temporary rows in the actual game tables, then clean them up.
- A separate approval-gated interaction can prove a representative save or score bridge call and its visible result.
- Evidence is tied to the current app revision, so a later edit invalidates older Game sign-off evidence.
Good Game prompts
- “Build a one-thumb neon tunnel runner with 45-second runs, upgrades, and a weekly leaderboard.”
- “Make a cozy 3D stacking game with touch drag controls, saved unlocks, and daily challenges.”
- “Fix the jump feel and restart leak on the targeted game page without changing its art direction.”