Designing a Mobile Game With AI: Screens, Art, and Music

The workflow started with the design documents

The idea and the taste came first. I wrote the game design document, project overview, roadmap, asset naming rules, screen-effects rules, and quality checklist before I asked AI to make individual pieces.

I then gave those documents to ChatGPT and asked it to reflect the project back to me. That step was useful because I could correct its understanding before it produced a hundred assets for the wrong game. The documents gave it the Caribbean setting, the short-session loop, the island structure, the power family, and the visual rules it had to keep.

At that point the workflow was conversation-heavy. I would work through a screen or asset with ChatGPT, generate a candidate, download it, clean it, move it into the project, and ask a coding agent to wire it.

That history matters because the workflow changed. The current version is more direct:

1. The repo and its written standards tell Codex what already exists.
2. I select the screen, family, or missing asset that needs work.
3. Codex generates candidates against real references.
4. When transparency needs cleanup, Codex can drive Canva in Chrome to remove the background.
5. It saves the approved file to the right project location and wires it into the game.
6. I review the result inside the product, at its real size, on a real phone.

The agent now absorbs more of the file handling and wiring. My role did not disappear. It moved toward the decisions the automation cannot own: whether the result matches the game, respects the culture, reads at mobile size, and is good enough.

Design the mock before the screen

The first playable board came together quickly. The interface around it took far longer because a game is not one board. It is a home screen, map, level introduction, avatar picker, journal, shop, settings, rewards, win and fail states, and the paths between them.

The entry point grew from a plain menu into a home hub. That was not one prompt getting better. It was repeated design, implementation, and review.

The strongest habit I formed was refusing to let an agent invent the layout while it built the screen. I made or selected a mock first. The mock settled the hierarchy, the important action, the bounds, and the relationship between art and live data.

“Build a shop screen” leaves the agent to decide what matters. “Build this approved mock to these safe bounds, with this card family and these live fields” gives it a target it can implement and I can review.

Three screens, three jobs. Avatar selection is a decision. The journal is for browsing. The wheel is a reward moment. They should not share one hierarchy.

Four mobile-screen rules I keep

The mock solves one screen. The project rules keep the whole product from drifting.

One primary action

Every moment needs one clearest next action. It gets the strongest contrast, the largest useful size, and a position the player’s thumb can reach. A screen with five equally loud buttons does not have five priorities. It has no priority.

Containers, not fixed coordinates

AI-generated interface code often reaches for exact x and y positions because they make one screenshot look correct. A mobile screen is not one canvas. The same position can collide with the home indicator on one device and float awkwardly on another.

Structure belongs in containers that grow, shrink, align, and distribute space. Fixed coordinates still have a place inside a finished illustration or tightly controlled effect. They do not own the page layout.

Real safe areas

The top and bottom insets are not decorative padding. Camera cutouts, rounded corners, navigation bars, and the home indicator change the usable area. The insets may not be symmetrical.

I treat the safe area as input from the device, not a number guessed from the mock. The important controls stay inside it, and decorative art can extend beyond it when clipping is intentional.

Smallest phone first

I review the smallest supported phone before I celebrate the large one. A spacious screen can hide a weak hierarchy. The small phone exposes it quickly: labels wrap, cards squeeze, buttons compete, and the scroll path becomes obvious.

Decision	Weak implementation	Production rule
Main action	Several controls compete	One clear primary action
Screen structure	Fixed x and y positions	Responsive containers
Device edges	One guessed margin	Real safe-area insets
Review order	Start on a large phone	Prove the smallest phone first

The engine-specific version of this work is in Godot for a Mobile Game in 2026. This article owns the design rule, not the whole Godot layout system.

Review the flow, not only the best screenshot

A screen can look premium in isolation and still make the product harder to use. I review the path around it: where the player came from, what they believe they are doing, what happens after the primary action, and whether Back returns them somewhere sensible.

That changed how I evaluated the home hub. The question was not only whether the island art looked good. The screen had to expose the systems a player uses often, keep Play obvious, show currencies and lives without turning the top into noise, and make the bottom navigation feel stable across destinations.

For each screen, I capture a small state set:

• the ordinary loaded state;
• the smallest-phone state;
• empty, locked, or unavailable content;
• the state after the primary action;
• a long-label or large-number case where live data can stretch;
• the route back to the previous screen.

That set stops one polished screenshot from becoming false confidence. The avatar picker can look excellent with the default selection and still fail when a longer name wraps. A reward popup can look balanced at score 120 and crowd its frame at 125,000. A journal can look clean when every entry exists and collapse when a tab is empty.

Mock-first does not mean mock-only. The mock is the target. The state set proves the implementation can keep the target when real data and real devices apply pressure.

Separate premium art from live data

One pattern saved me from choosing between a hand-crafted screen and dynamic information. I use a finished art shell for the premium frame, then place the real values in a transparent runtime layer.

That split gives the popup a real visual identity without baking changing numbers into an image. It also creates a clear implementation contract:

• the artwork owns shape, texture, lighting, and decoration;
• the layout owns safe bounds and scaling;
• the code owns values, states, localization-ready labels, and interaction;
• the human review checks that the layers still read as one screen.

If a real popup shell exists, the agent must not quietly rebuild it with generic rectangles because that is easier to code. That is how a polished game turns into a set of unrelated developer panels.

Build asset families, not one-off pictures

A mobile game needs hundreds of pieces that have to sit together. One beautiful image does not solve that. A useful asset belongs to a family with shared lighting, outline weight, gloss, scale, and runtime behaviour.

Board fruit

Obstacle states

Treasure

The starter fruit also needed to differ by silhouette, not only colour. Lime, orange, passion fruit, guava, and coconut do not collapse into five recoloured circles. A player who cannot distinguish a colour should still have shape as evidence.

The production prompt therefore has to carry more than style:

Create a production-ready [asset type] for Tropic Tumble.

PRODUCT TRUTH
- Match the attached real screenshots and approved asset family.
- Do not invent powers, fruit, rewards, screens, text, or features.

STYLE
- Premium tropical casual game art.
- Top-left soft light, shared gloss, outline weight, and saturation.
- Clean silhouette that remains readable at the real display size.

RUNTIME
- Destination and exact size:
- Transparent background, or flat chroma background for cleanup:
- No text, logo, watermark, background clutter, or shadow outside the object.

REVIEW
- Reject if it is off-family, misleading, unreadable, or has messy edges.
- Approve only inside the real product.

The forbidden list is not pessimism. Generative models borrow from neighbouring games. If I do not say no rockets, generic bombs, candy tiles, or fake interface text, those familiar shapes can arrive even though Tropic Tumble does not use them.

The current art pipeline

The early process was one image at a time in ChatGPT. I downloaded it, opened Canva, removed the background, resized it, compressed it, moved it, and then asked an agent to wire it into the scene.

The current Codex workflow is more complete because the agent is aware of the repository. It can see the missing asset, its target path, the naming standard, the screen that consumes it, and the tests or captures used for review. It generates the candidate and wires it into the project.

Transparency still needs care. A faint grey box or a rough green fringe may be invisible at full export size and obvious on a bright phone background. When needed, Codex drives Canva in Chrome for the background-removal step, returns the cleaned file to the repo, and continues the integration.

That automation saves real manual handling. It does not make the output final. I still inspect:

• silhouette at the actual display size;
• consistency beside approved family members;
• alpha edges on light and dark backgrounds;
• damage or selected states;
• file dimensions and weight;
• the real screen on the smallest phone;
• whether the piece implies a feature the product does not have.

A generated image is a candidate. The asset becomes production art only after it works in the product.

I keep the source and the production result distinct. The source may be a high-resolution generation on a chroma background. The production result may be a compressed transparent file with a precise name and a smaller footprint. I do not overwrite the only source while experimenting with cleanup.

That makes iteration safer. If the cutout loses part of a vine or soft highlight, I can return to the source instead of asking a model to redraw the whole piece and hoping the style stays consistent. It also gives another agent enough evidence to tell whether a file is an approved asset, a candidate, or an intermediate cleanup step.

The world has to sound and look like somewhere

The islands are not generic beaches with cheerful names. They move through a Caribbean journey: Maroon Mountain Pass, the Blue Mountain peaks, Dunn’s River Falls, Reggae Sumfest Shores, a Dancehall Sting arena, a Carriacou big-drum yard, and a Patois Story Yard where Anancy, the Rolling Calf, and River Mumma live.

Those references carry meaning. My rule for culture, faith, and history is clear: celebrate them with respect and never turn them into caricature. AI can produce tropical decoration. It cannot decide which detail is sacred, which is playful, and which becomes disrespectful when flattened into a prop.

The same applies to music. I did not want one background loop stretched across every island. The soundtrack is routed as families:

The music router chooses a family for the island instead of treating one favourite track as the whole soundtrack. Within a family, a usable loop needs no long intro, no distracting vocal, a clean seam, and enough space for swaps, clears, rewards, and haptics.

The first island loop is still the one I love most. It has the gentle reggae and lovers-rock feeling I wanted for the early shores.

My approval pass is practical: can I hear the seam, does the loop wear me down after a few minutes, can I still hear the game effects, and does the track fit the island rather than only fitting a genre label?

Build My Island is the feature I held back

Build My Island is a mode where the player would collect pieces and build a retreat, home, spa, and stretch of coast. I still love the idea. I have not shipped it.

Single screens were within reach. Build My Island was not a single screen. It needed drag and drop, consistent two-and-a-half-dimensional perspective, pieces that shared light and scale, and an island that still read as one place after the player rearranged it.

I could generate a beautiful hut. That did not make it a buildable asset. The angle might be wrong, the background baked in, the base impossible to place, or tiny people included in the scene. Separately generated terrain tiles forgot what their neighbours looked like.

The idea being good was not a reason to ship it. The art and interaction were not good enough, so I held the feature back. I can return when the tools or my own ability can meet the quality bar.

The production asset contract

This is the artifact I would give another solo builder before generating a family:

Contract field	Decision
Product truth	What the game really contains and what must never be invented
Approved references	Exact screenshots, icons, family members, and visual baseline
Destination	Screen, board, popup, store image, video, or marketing
Display size	The real in-product size, not only export dimensions
Family rules	Light, gloss, outline, materials, palette, and silhouette
Runtime boundary	What is baked art and what remains live code or data
Forbidden content	Fake UI, text, mechanics, claims, logos, or off-brand objects
Cleanup	Alpha, crop, compression, naming, and file location
Evidence	Product capture at smallest phone and representative larger device
Approver	The person who decides whether it ships

And this is my final approval checklist:

• It matches the real product and does not invent a feature.
• It belongs beside the approved family.
• Its silhouette reads at the actual display size.
• Text and live values are not baked in unless that is intentional.
• Transparent edges are clean on light and dark backgrounds.
• The file is named, sized, compressed, and wired correctly.
• The smallest phone keeps the hierarchy and safe areas.
• Music loops cleanly and leaves room for effects.
• Cultural details are specific, respectful, and not caricature.
• I reviewed it in the real screen, not only in the generator.

The visual testing details remain in what AI could not see when I built my game. Here, the important part is the production boundary: generation creates options; the contract and the in-product review decide which option becomes part of the game.

Make the system before you make the pile

If I were starting again, I would begin with a strong asset pack or a designer for more of the base system. Making every piece yourself can look cheaper on paper while costing months in generation, cleanup, integration, and rework.

When the work does need to be yours, define the family before you generate the members. Design the mock before the screen. Keep live data out of fixed art. Prove the smallest phone. Route music by mood. Hold a feature when the pieces cannot yet carry it.

AI gave me the reach of a small studio. It did not give me the taste, the cultural judgment, or the final eye. Those are not the leftover tasks. They are the work that makes the generated output belong to one real game.

Tropic Tumble is live on iPhone and Android, built by JPott Studios. The production system is still evolving, but the rule stays steady: make the tool work against the truth of the product, then look at the result where the player will actually meet it.