Ads and in-app purchases in a game built from a prompt: AdMob banners, interstitials and Play Billing

Say where an ad belongs and what a purchase unlocks; the agent adds the AdMob slots and the Play Billing products with test ids, shows them as simulated in the preview, and uses your real ids in the installed build. Digital goods must go through Play Billing, never a card gateway.

Two kinds of money

A small game earns in two ways and they are wired differently. Ads come from AdMob: a banner that sits at the edge of a screen, an interstitial that fills the screen at a break, a rewarded video the player chooses to watch. Purchases come from Google Play Billing: a coin pack, a "remove ads" unlock, a season of levels. Both are native features, so they exist fully only in the installed APK; the emulator preview shows them as simulated placeholders so you can see the layout without serving ads to yourself or buying your own coins.

One rule shapes everything else: Google Play requires Play Billing for anything digital that is used inside the game. A payment gateway is fine for a game that sells T-shirts or event tickets, not for coins. The agent follows this rule and will say so if a request mixes them up.

Where ads fit — and where they kill a game

Players forgive ads at breaks and punish ads that interrupt. The pattern that works for most small games:

• Banner on the title screen and the leaderboard, never on the play screen of an action game where it steals thumb space.
• Interstitial after game over or after a level, with a cap such as "at most one every three runs". The end of a level is the only moment a full-screen ad feels fair — the level data from the levels guide gives you that moment for free.
• Rewarded when the player wants something: continue after a crash, double the coins of this run, skip a hard level once.

Say the placement in the request and the agent writes exactly that:

In the chat the agent adds the ads package to the project and tells you which ids it still needs. The preview reloads with labelled "simulated" boxes where the banner and interstitial will be; tapping the rewarded button in the preview grants the reward so you can test the revive flow.

Giving the game your AdMob ids

Until you provide an AdMob app id, the build uses Google's test app id and test ad units, which is what you want while you develop — real ads on a test device can get an AdMob account limited. When you are ready:

The agent stores the app id in the Android configuration of the build and the unit ids in the game's settings file, then confirms what changed. Build a new test APK and install it: the banner now shows a real ad. The preview keeps showing simulated boxes, which is correct.

Purchases through Play Billing

A purchase has two halves: a product that exists in Play Console (id, price, type) and code in the game that offers it, verifies the purchase and unlocks something. The agent writes the second half; you create the first in Play Console once the app listing exists. A good first request:

The agent adds the billing package, the shop screen, the purchase flow and the unlock logic, and the build gains the store flavour Play requires. In the emulator preview the shop shows simulated products and a "buy" button that applies the unlock so you can test what "remove ads" actually hides. Real purchases need a signed build installed from Play's internal testing track with a tester account; the agent reminds you of that step when you ask for the signed build.

What to sell in a small game

Keep it to things players already want by the time they see the shop:

• Remove ads — the single most-bought item in small games, and the one that makes an interstitial acceptable in the first place.
• A continue or extra lives, priced below a coffee.
• A cosmetic: a skin for the player, a theme for the board. Pure vanity sells better than power in a casual game.
• A level pack, if the game has a real second world.

Avoid pay-to-win items in a game with a leaderboard; they make the board meaningless, and the board's server-side caps would have to account for them.

Testing the whole thing

1. In the preview: every ad slot shows a simulated box in the right place, the rewarded button grants the reward, the shop unlocks what it promises.
2. Test APK on your phone: test ads render (Google's test creatives say "Test Ad"), the frequency cap holds across runs.
3. With your ids: a fresh test APK shows real ads on the title screen. Do not tap your own ads.
4. Signed build on the internal testing track: a tester account buys "remove_ads", restarts the game, and sees no ads. Then buys coins and sees the balance change.

If anything in step 3 or 4 fails, paste the exact error from the phone into the chat; the agent reads the build log and the configuration it wrote and fixes the id or the flavour.

Kids' games have extra rules

If the game is for children, say so in the request: the agent configures the ads for child-directed treatment and keeps rewarded ads out of the main loop. Play's family policy also expects a privacy policy link and no personalised ads; mention both when you ask for the signed build so the listing and the game agree. For a children's game a one-time "remove ads" purchase is usually the only purchase worth having.

Checklist

• Ads only at breaks, with a frequency cap written into the request.
• Test ids while developing; real ids only in a build you will not tap yourself.
• Digital goods through Play Billing; a gateway only for physical goods.
• "Remove ads" first, cosmetics second, nothing that beats the leaderboard.
• Internal testing track with a tester account before the public release — the same signed build the published games here use.

Frequently asked