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

Step 1: The vision is yours

I wanted a match-3 that felt like the Caribbean I am from. Not a tropical skin on a generic game, but the real thing: the fruit, the music, the places, the stories. That was the whole brief, it fit in a sentence, and it is the one contribution no model could make, because it comes from being from somewhere.

Everything below started from that sentence, and the division of labour never changed. I brought the intent and the taste. The model brought speed, structure, and the edge cases I had not thought of. And I stayed in the chair the whole way, because a model forgets the rule you set three screens ago and drifts the moment the goal goes vague.

The first thing that vision had to become was a set of rules a board could run. So the mechanics came first.

Step 2: Design the mechanics out loud

I did not ask the AI to invent my mechanics. I brought a rough idea for each one to ChatGPT, the product designer on this project, and together we worked it into something concrete: what the powers should be, how each behaves on the board, how a new player gets through the first ten levels without getting confused. Every design session started the same way, with my real documents going in before the model got a say.

Before any code, ChatGPT reads my design documents and reflects the game back to me, so we start aligned. The idea and the taste are mine; the partner helps me make them complete.

Here is what those sessions produced. I am sharing the actual rules because they help more than talking in the abstract. Every power spawns from a match during normal play, each costs a move to use, and the system was built so a player discovers it rather than reads a manual.

The table is the easy part. The hard part of a match-3 is not one power, it is all the decisions hanging off it, and this is where the AI genuinely earned its place. For each power I described roughly what I wanted, and we worked the whole decision space together:

• Balance. How strong is this power compared to that one.
• Combos. If this power combines with that one, what should the combo do, all the way up to two Solars clearing the board.
• Edges. What happens when the player fires it into a corner, into an obstacle, with no matching fruit left.
• Obstacles. How does each one clear, how much health does it have, how do the difficulties stack.

The model generated the data, the interactions, and the edge cases, so I could see the whole map of choices instead of discovering them one painful level at a time. The judgment stayed mine: which power should win a clash, what should feel fair, what to cut.

Bring the rough idea, let the model map every decision hanging off it, and keep the verdict. It can enumerate the choices. It cannot tell you which one makes the game fun.

Rules make a game work. What makes a game feel good is a different set of decisions, and those were the most personal ones in the project.

Step 3: The feel, decided one small call at a time

Two rules guided feel, and both are pure judgment:

• Satisfaction comes before beauty, which comes before feature count. I would rather ship a board that feels great with fewer features than a bloated one that feels flat.
• A hard level should make you think “I figured that out,” never “the game cheated me.” Difficulty comes from layout, limited moves, and obstacle placement, never hidden randomness.

Out of those rules came the pacing, a stack of small deliberate decisions made from everything I know about testing products and from years of playing games myself:

• Lives: you can store at most 5, and a life restores every 30 minutes, enough to invite you back without trapping you.
• Out of lives: the game gives you a clear call to action, not a dead end.
• Boosters: you can buy a power-up while playing a level, right at the moment the board is fighting you.
• Hints: suggested next moves are subtle and timely, a nudge, never the game playing itself.
• New fruit: introduced timely, one at a time, so the board never overwhelms you.
• New obstacles: introduced one family at a time, with dozens of obstacle-free levels first and instructions the first time you meet each one, so you master the board before the board fights back.
• Pets and tutorials: pets arrive when you have earned them, and guided tutorials show up exactly when a new mechanic does.

None of those decisions came from a model. They came from being a tester and a player at the same time, and they are a big part of what makes the game feel special.

The fairness rule is not left to good intentions either. It is written into the code. The function that adjusts a level at runtime takes the level’s own data and its number, and nothing else. No telemetry, no fail history, no record of anything else about you, so the game cannot quietly get harder because you lost twice. The only live tweak it is allowed is a tiny, capped safety assist, at most one extra move on a level you are stuck on, and even that follows the same rule: it sees the level, never the player.

A model can generate a thousand levels. Only a person can play one and know whether it is fair. Write the fairness into the code, then keep playing anyway.

Fair systems are worth nothing if the world they live in feels like nowhere. That was the next design job, and it was the one I refused to share.

Step 4: The world had to come from me

The world is where the soul lives. Tropic Tumble is a chain of islands, ten levels each, and I rotate the themes so two similar ones never sit side by side, because a world should feel like a journey, not a list.

Scrolling the map, island by island. Every theme, every name, and the order they unlock in is mine, because I wanted the game to feel like a specific place, not a list of levels.

The islands are not generic beaches with cute names. They are real places and real culture, ordered as a journey: it opens with a gentle tropical welcome, then moves deep into Jamaican and Caribbean identity before widening out to the rest of the world. Along the way:

• You pass a Maroon Mountain Pass and the Blue Mountain peaks where the coffee grows.
• You climb Dunn’s River Falls.
• You dance through Reggae Sumfest Shores and a Dancehall Sting arena.
• You sit in a Carriacou big-drum yard.
• You stop at a Patois Story Yard where Anancy, the Rolling Calf, and River Mumma live.

Each of those names means something to someone from here. An AI optimising for engagement would have handed me a thousand interchangeable Sunny Coves.

The fruit carry the identity too. The starters are lime, orange, passion fruit, guava, and coconut, chosen to be distinct by shape as well as colour, so a colourblind player can tell them apart by silhouette alone. That is an accessibility decision and a cultural one at once, and both are mine.

I also wrote an explicit rule for myself and the agents: anything touching culture, faith, or history is handled with respect, as something to celebrate, never as caricature. An AI will not draw that line for you, because it does not know which details are sacred and which are decoration. A person from the culture does.

The culture cannot be delegated. A model does not know which details are sacred and which are decoration, so the names, the places, and the line of respect have to come from you.

A world and a set of mechanics still only exist in documents. The player meets all of it through screens, and that is where I formed the habit that shaped the rest of the build.

Step 5: The screens: mock first, then hand over

To a player, the interface is the game. They do not see your board logic or your save system. They see a home screen, a map, a shop, a win screen, and decide in about two seconds whether this looks worth their time. The first playable board came together in a day; the interface around it took months, because the board is one screen and the game is dozens.

The entry screen, early and now. It started as a plain menu on a flat teal background and became a home hub with an avatar, a pet, an island world, and every system one tap away. The distance between those two screens is months of interface work.

The single best habit I formed was refusing to let an agent invent the layout. I designed each screen as a mock first, settled what goes where and what the one important action is, and only then handed it over to build. An agent with no target produces a plausible screen, and plausible is not designed: it gives every element the same weight and leaves you with something that works and feels like nothing. A mock turns “make a shop screen” into “build this, to these bounds,” a question an agent can answer well.

A mock covers one screen. A written standard covers all of them, so I put my interface rules into the project in plain language, the same way I write rules for any agent:

• One primary action per moment. The most important thing is the largest, the highest contrast, and sits in the natural thumb zone. If everything is loud, nothing is.
• Breathing room around that action. Never sandwich the main button against clutter.
• A fixed colour language. Teal means a positive action, coral means cancel or exit, gold means a reward. The agent does not improvise colours per screen, because consistency is what makes an interface feel like one product.

Then the most important technical lesson, the one I would tattoo on any agent: an AI building UI reaches for fixed pixel positions. It places a button at an exact x and y, it looks perfect on the one screen size it imagined, and it breaks on every other phone. Mobile is not one canvas.

The same screen-size discipline runs through the engine choices in Godot for a mobile game in 2026. And because agents cannot actually see what they build, every screen still ended with my eyes on a real phone; that whole blind spot is its own article.

The pattern that saved me most was separating the premium art from the live data. A popup or heading is a finished image, the polished shell, with a transparent layer on top where the real numbers and labels are drawn at runtime.

The shell of this level-complete popup is a finished art asset: the frame, the shell, the stars, the panel. The score, the unused moves, and the coin count are live data drawn on top. That split is what lets the interface look hand-crafted and still stay dynamic.

This has a hard rule attached: an agent must not rebuild a premium popup out of code-drawn rectangles when a real designed asset exists. Left unchecked, that is how a game slides into programmer-art, one “good enough” panel at a time.

Design the screen before the agent builds it. A mock plus a written standard turns “make a shop screen” into a question an agent can answer well, and everything else into a screen it will answer badly.

That popup pattern points at the biggest design job of all. Every shell, every icon, and every note of music had to be made, and a game does not need one good image. It needs hundreds that all behave.

Step 6: The art and music are production contracts

The first mistake people make with AI art is thinking in single images instead of asset families. Everything on a Tropic Tumble screen belongs to a family with its own job:

• Board fruit and collectibles have to read clearly at tile size and still feel tropical and playful.
• Powers and combos have to look exciting without hiding the board.
• Obstacles have to show state changes, damage, and rules at a glance.
• Treasure, events, shop, and settings have to carry the same teal, gold, shell, and pearl language across screens.
• Marketing art has to sell the real game, not a fake ad version of it.
• Music and audio have to match island moods and sit under long sessions without wearing you out.

Board fruit

Obstacle, intact then cracked

Treasure

Getting families instead of one-offs meant every generation session started from my style guide, not from a wish:

The real asset session. I hand ChatGPT my style guide and the exact rules, and it turns them into a production prompt I can run, here for the Wind Slash power-up.

Over hundreds of assets, that habit hardened into a template I wrote the same way every time, plain enough that another person, or another agent, could run it and review the output. This is the one block to copy from this article:

Create [asset type] for [product].

PRODUCT TRUTH
- What the product actually is, and what this image is allowed to communicate.
- Must match these real references: logo, current screenshots, app icon, approved asset family.
- Do not invent features, mechanics, fruit, rewards, screens, or claims.

STYLE AND BRAND
- Approved visual family, colours, materials, and lighting.
- Must sit beside a named approved asset or screen.

RUNTIME REQUIREMENTS
- Destination: board icon, popup shell, ad, app-store image, or video first frame.
- Size or aspect ratio, background (transparent, flat colour for cutout, or locked screenshot),
  text rules, and the real display size, such as readable at 64px on a busy board.

FORBIDDEN
- The off-brand visual vocabulary, fake UI, unsupported claims, and any generated logo or text.
- Name the specific traps for the product. A model borrows from neighbouring genres unless you
  forbid them, so if I did not write no rockets, I would get rockets.

OUTPUT CHECK
- The image is only a candidate until it is reviewed in the real destination.
- Reject if it is off-brand, misleading, unreadable, has messy edges, or implies a behaviour
  the game does not have.

Every boring line is load-bearing. “Readable at 64px” matters because the file lives on a board, not in a gallery. “No text” matters because generated text is still too risky for production. “Match the asset family” matters because one beautiful oddball can make a whole screen feel cheaper. And for the marketing art the truth section matters most of all, because a beautiful fake ad is worse than no ad: it teaches the player to expect a game I did not build.

The output check is the part most people skip. A production prompt is not finished when the model returns an image; it is finished when the image passes review, and the workflow around it has more gates than the prompt itself:

The cleanup gate deserves a word, because it is where the tools changed under me mid-project. I started generating art with ChatGPT, and it was genuinely good: clean images with transparent backgrounds, ready to sit on the board. The catch was that it made them one at a time. Prompt, wait, check, download, save to the right folder, start again, for a game that needed hundreds of assets. Then Codex, the repo-aware agent from my studio setup, added image generation, and because it already knew my project it could generate in bulk against the real gaps: it knew which asset was missing, what size it needed, what to name it, and where the file belonged. The trade-off came with it. Unlike ChatGPT, Codex images arrived with backgrounds baked in, so Canva became the cleanup station where every background got removed before an asset was allowed anywhere near a screen. My job moved up from copying files to judging the output, which is the real pattern of building with AI.

The judging stayed practical. I did not approve an asset because the file looked good. I approved it when it worked in context:

• Size and silhouette: does it read at the actual size, and can I tell what it is without zooming in?
• Style and contrast: does it belong beside the other assets, on both light and dark surfaces?
• Edge quality: did background removal leave green, white, or fuzzy pixels?
• State clarity: if it has damage states, can I tell them apart?
• Phone and weight: does it still look right on a real device, and is the file too large for what it does?

Music went through the same contract thinking, and it carries more of the game’s personality than anything on screen. I generated the loops with Suno and kept clearly licensed tracks where that made more sense, and the prompt was about use, not just genre: a loop with no audible seam, no long intro, no vocals, sitting under gameplay without fighting the tap, swap, and reward sounds. I built the loops as mood families and matched them to the islands, and the Caribbean ones are the heart of it: reggae lovers rock for the easy shore islands, dancehall sound-system dub for the night arenas, Carriacou big-drum percussion for the cultural yards, then volcano hazard tension and cool crystal-snow loops further out. A festival island and a volcano island should never feel the same in your ears, and they do not.

Sound is only half of feel, so I wired light haptics to the moments that should land: a select, a satisfying clear, a reward. The review for all of it was the same in-context check as the art: does the loop have a seam, does it annoy after a few minutes, can I still hear the gameplay sounds, does the vibration land on the right beat, and is the licence clear.

A nice prompt asks for a beautiful image. A production contract says what the asset must match, what it must never invent, and who reviews it where. The contract is what turns a generation into an asset.

That contract discipline gave me almost everything I designed. Almost. The honest version of this story includes the one feature it could not give me.

Step 7: The feature I held back

The feature I most wanted, and still want, is Build My Island: a mode where you collect pieces and build your own island retreat, your own home, your own spa, your own stretch of coast. I have a working version. I have not shipped it. The game was done and launched without it, and holding it back was a choice about that one feature’s quality, not about time.

The reason is worth being straight about. AI and I are good at single screens. Build My Island is not a single screen. It is drag and drop, and it moves past flat two-dimensional art into the two-and-a-half-dimensional space where pieces have depth and have to sit together in a scene. I could generate a beautiful hut, but a beautiful hut from the wrong angle, with a background baked in or tiny people in it, is not a buildable piece. Getting a whole island of them to share one angle and read as a place you made was beyond the quality I could reach, and beyond what I yet knew how to close myself.

So I made a quality call: hold it back rather than ship it half-right. I will keep refining it and come back as the models get better at this kind of work, or as I get better at making these assets myself. That is part of designing with AI honestly: it gives you reach, and your job includes knowing where its reach ends and being willing to wait.

The idea being good is not a reason to ship it. The work has to be good and it has to work, and forcing a feature out because you love the idea is how a game gets worse.