> For the complete documentation index, see [llms.txt](https://wiki.playgama.com/playgama/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.playgama.com/playgama/guides/game-development/building-with-ai-agents.md).

# Building with an AI agent

Connecting the agent to Playgama, preparing assets, making the game easy to change and test, and checking before and after the upload.

AI coding agents can build and publish a Playgama game end to end, but they repeat the same mistakes when left to guess: generated sound, a template-looking interface, a layout checked at one window size. This guide is the working setup that avoids them. Why the visual and design side still needs a person is covered in the article [Use AI Right](/playgama/articles/use-ai-right.md).

## Connect the agent to Playgama

* Connect the [MCP server](/playgama/mcp.md). The agent then reads the [Game Requirements](/playgama/game-requirements.md) and the [SDK required steps](/playgama/bridge-sdk/api.md#required-steps) itself, uploads builds and reads the automatic build check.
* Ask the agent to read the requirements and the SDK required steps at the start of the work, not just before the upload: layout, sound and saving are decided when the game is first written.
* Before every upload, have it go through the [Game self-check](/playgama/game-requirements/game-self-check.md) and tell you which items it could not verify.

## Prepare assets before you start

* Download the assets before the agent starts — free CC0 libraries for graphics, ready-made sound and music packs — and put them in the project. An agent asked to "find assets" along the way wastes time and tends to fall back to generating them.
* Never let the agent synthesize sound or music in code: it is not accepted (item 3.3.2). See [Sound](/playgama/guides/game-development/sound.md).
* Prefer asset packs drawn in one style and from one palette: they look consistent and batch well (see [Performance & Optimization](/playgama/guides/performance-and-optimization.md#assets)).
* Ask for one script that builds and compresses all assets, so the agent does not optimize files by hand every time.

## Make the game easy to change

* Describe the world as data rather than as content: a level map of a few lines, one character per block type, is edited with a single character. An agent will rewrite it twenty times in a session — it will never hand-place hundreds of objects once.
* Keep tunable values — speeds, prices, rewards, difficulty steps — in one configuration file, so balancing does not mean searching the code.

## Give the agent eyes

* Add a few debug hooks on a global object, so a headless browser can drive the game: start a level, skip to a screen, switch quality presets, and report FPS, draw calls and triangles. An agent that only reads code guesses; one that can play the game measures.
* Have the agent take screenshots of every screen at the fixed size matrix from [Responsive layout](/playgama/guides/game-development/responsive-layout.md#test-with-a-fixed-matrix), and look at the screenshots yourself before calling a check passed.
* Ask for numbers, not adjectives: frame time, initial download size, memory. "It runs smoothly" is not a measurement.
* Run the game in the Bridge environment before uploading: the MCP server gives the agent a QA Tool link for a game served locally (`get_local_game_qa_tool_link`).

## After the upload

* Read the result of the automatic build check and fix what it reports before publishing.
* Open the published game and check that it works there the same way as locally — with the platform's own interface, ads and sizes.
* Once players arrive, use the telemetry tools of the MCP server to find where they stop or where the game slows down, and iterate on that.