0→1 AI Game Development

Pac-Man exercise: from a minimal playable prototype to refined mechanics, expanded gameplay, image assets, and a complete UI.

Overview

Start with a blank COCOS 2D project. Use a short prompt to create movement, pellets, and scoring. Play the result to find problems, then ask Agent to fix movement, speed, and wall collisions. Add power pellets, ghosts, lives, and win/lose states after the foundation works. Finally, generate image assets and improve the UI.

You will continue in the same project and conversation, using Preview screenshots to report specific text, layout, or texture problems. Run and inspect the result after every change.

Stage	Goal	Agent work	What to practice
Quick start	First playable version	Create scenes, scripts, and basic gameplay; open Preview	Describe a minimal playable goal
Refine mechanics	Correct movement, stopping, speed, and collisions	Read and modify the existing project	Give explicit rules and values
Expand gameplay	Power pellets, ghosts, lives, win/lose states	Extend existing state and collision logic	Specify additions and behavior to preserve
Improve visuals	Image assets and a three-column UI	Generate assets, integrate them, and bind UI to state	Describe appearance while preserving gameplay
Continue from screenshots	Fix local visual issues	Inspect screenshots in the current context	State location, observation, and expected result

Before you start

You need PinK IDE and a blank COCOS 2D project. Create and open one with:

cocos create -j pacman-minimal -t 2d
pink pacman-minimal

Step 1: Create a minimal playable version

Start with movement, pellets, and score feedback in Preview. Leave images and complex UI for later. The first successful loop gives you a basis for deciding what to improve.

Send the prompt

Request a minimal Pac-Man prototype from PinK Agent

Create a minimal Pac-Man prototype in this blank COCOS 2D project with only three features: arrow keys move a yellow circular player through a simple maze without passing through walls; white pellets disappear when eaten and add 1 point; eating all pellets displays "YOU WIN". Use one Scene and basic COCOS graphics. Do not add ghosts, power pellets, lives, audio, images, or other gameplay. Open the preview when finished.

This describes player-visible behavior without prescribing Scene, Node, Component, or script structure.

Let Agent finish this task

Agent creates Pac-Man scenes and scripts

Agent analyzes the blank project, creates and saves scenes, scripts, and assets, and tries to build or open Preview. Wait for this task to finish before requesting ghosts, textures, or menus.

Play the preview yourself

Test the first Pac-Man prototype in Preview

Check that arrow keys move the yellow player, touching white pellets removes them and increases the score, and the game continues without blocking errors. Rough movement, unreliable collisions, or unwanted sliding are issues to refine in the next focused step. This stage establishes the first playable loop.

Step 2: Refine movement and collision

Ask Agent to work with the current implementation. Use actual playtest observations to improve movement, stopping, speed, walls, and pellet behavior.

Send the prompt

Refine movement and collisions in the existing project

Continue the current Pac-Man project without recreating it. Refine only basic movement and collision:

- Walls must block the player, who can move in four directions only along maze corridors.
- Move only while an arrow key is held. Stop immediately when it is released, without sliding.
- Set movement speed to 2 grid cells per second.
- Place pellets only in walkable areas. Each pellet disappears and scores exactly once.

Preserve the existing basic graphics, score, and win condition after all pellets are eaten. Do not add assets or other gameplay. Open the preview when finished.

Name the existing project, give measurable values such as 2 grid cells per second, and state both what to change and what to preserve.

Verify with real input

Verify movement and the YOU WIN state

• Holding an arrow key moves the player; releasing it stops immediately.
• Holding it for one second moves approximately two grid cells.
• Walls stop the player without allowing passage through them.
• Pellets appear only in corridors and score only once.
• Eating all pellets still wins the game.

A useful prompt for an existing project has four parts:

Project to continue
+ Specific behavior to correct
+ Verifiable value or boundary
+ Existing features to preserve

This lets Agent inspect and modify the current implementation without requiring you to describe the entire game again.

Step 3: Expand the gameplay loop

Once movement works, add related mechanics: power pellets change player state, ghosts react to that state, collisions affect lives, and running out of lives ends the game. Keep basic shapes and colors while verifying these rules.

Send the prompt

Add power pellets, ghosts, and lives

Continue the current Pac-Man project without recreating it. Preserve verified hold-to-move controls, immediate stopping on key release, speed of 2 grid cells per second, wall collision, and pellet scoring.

Expand the maze while keeping corridors connected, and add left and right tunnels. Replace the pellets in the four corners with larger power pellets. Eating one gives the player a powered state for 8 seconds, shown by a color change that ends when the state expires.

Add ghosts using red basic shapes. Normally they chase the player through corridors. While the player is powered, ghosts turn blue and flee. If touched by the powered player, a ghost returns to its spawn point and recovers. Place the ghost spawn inside an enclosed 3x3 block at the center.

The player starts with 3 lives. Touching a ghost in the normal state costs 1 life and respawns the player at the upper-left spawn point. Show "GAME OVER" at 0 lives. Eating all pellets still shows "YOU WIN".

Use basic shapes and colors for all additions. Keep only necessary status text; do not add menus, buttons, a finished HUD, animations, or audio. Open the preview when finished.

Verify state transitions

Verify GAME OVER after adding ghosts and lives

Test passage through both tunnels, the 8-second power duration and its expiry, losing a life and respawning after normal contact, and eating a ghost during the powered state. At 0 lives, confirm the red GAME OVER message. Eating all pellets must still win.

Build new mechanics on the verified baseline. Describe each rule as a trigger, state change, and result. Basic shapes make state transitions inexpensive to check. After each addition, recheck movement, collision, and scoring before adding images, UI, or sound.

Step 4: Create images and complete the UI

With gameplay stable, improve appearance. Ask Agent to generate assets and arrange a top title, left information panel, central maze, right status panel, and bottom result area.

Send the prompt

Request image assets and the complete UI layout

Continue the current Pac-Man project. Create image assets and improve the overall UI while preserving existing gameplay.

Generate a coherent set of textured 2D images for Pac-Man, the current ghosts, and maze wall tiles, and integrate them into the scene. Use transparent PNGs for Pac-Man and ghosts and seamlessly repeatable wall tiles. Include no text in the images. Keep pellets and other UI elements as basic COCOS graphics, colors, and text.

Use a black background. Center a yellow PAC-MAN title at the top. Below it, use three columns, with the central maze as the largest area:

- Left: total score, lives, normal pellet count, power pellet count, and a working start/restart button, followed immediately by brief gameplay instructions in the secondary text color.
- Center: the complete maze, preserving its structure, object positions, and collisions.
- Right: every ghost's current state and Pac-Man's special state and remaining time. Read actual runtime state, not fixed demo values.

Reserve about 1.5 lines of text height at the bottom for results. Leave it empty during normal play. Show green success text on a win and red failure text on game over.

Make the start/restart button functional. Preserve movement at 2 grid cells per second, stopping on release, wall collision, tunnels, pellet scoring, powered state, ghosts, lives, and win/lose rules. Images and layout must not change those outcomes. Open the preview when finished.

The prompt defines asset scope, layout, real data sources, and gameplay constraints without dictating a specific node or script structure.

Inspect the first visual result

Pac-Man with image characters and wall tiles

Look for the top title, left information and button panel, dominant central maze, and right status panel. The asset directory should contain images for Pac-Man, normal and frightened ghosts, and wall tiles; scene objects should use them.

Text overflow, inconsistent margins or colors, and unsuitable textures can be corrected in the same conversation with a focused follow-up.

Continue with a screenshot

Attach the current Preview screenshot and identify the location, actual problem, and desired result. In this example, text overflowed the left edges of both information panels, and the wall texture needed to change.

Text in GAME INFO and LIVE STATUS overflows the left border. Adjust layout, alignment, and padding so all text fits inside the panels. Also change the walls to a red-brick texture.

Fix only these visual issues. Preserve the existing three-column layout, image characters, and all gameplay. Reopen the preview when finished.

Corrected panel text and red-brick walls

The resulting screenshot shows red-brick walls and corrected panel text, with the three-column layout and gameplay retained.

Screenshot feedback template

Continue the current project and inspect the attached Preview screenshot. Change only:

- Location: <area of the screen>
- Observation: <what is currently visible>
- Expected result: <how it should look>

Preserve: <existing results that must not be reverted or recreated>.
Open Preview again and provide a screenshot of the result.

Use this for overflow, overlap, alignment, spacing, size, hierarchy, image style, colors, and UI errors in specific states. For behavior or logic bugs, also provide input steps and expected and actual results.

Final acceptance

Gameplay

• Holding an arrow key moves the player; releasing it stops movement.
• Speed remains 2 grid cells per second.
• Walls block movement and tunnels work.
• Normal and power pellet counts reflect gameplay.
• Special states and their remaining time update correctly.
• Ghost states match their behavior.
• Lives and win/lose rules still work.
• Start/restart is functional.

Visuals

• Pac-Man, ghost, and wall images load correctly.
• Character backgrounds are transparent without rectangular artifacts.
• Panel text fits without clipping or overlap.
• The maze remains the main visual area.
• Success text is green and failure text is red.
• UI values come from real game state.
• The Console has no new errors or asset-loading warnings.

A successful build, saved script, or Agent completion message alone does not verify the game. Use actual input and visible results in Preview.

Apply this workflow to another game

Practice five skills: creating from a minimal goal, correcting local behavior, adding connected mechanics incrementally, improving visuals while preserving gameplay, and continuing from screenshot feedback.

Define a minimal playable mechanic
→ Ask Agent to create it and open Preview
→ Play it and identify problems
→ Correct them with explicit values and boundaries
→ Add one related group of mechanics
→ Add images and UI after gameplay is stable
→ Report visual problems with screenshots
→ Recheck existing behavior after every change

Before sending a prompt, confirm the project to continue, the current stage's goal, measurable behaviors, preserved features, the preview to open, and how you will verify it. For visual feedback, include a screenshot, location, observation, and expected result. You can practice this workflow from a blank project without first becoming a COCOS engineering expert.

Agent capability boundaries

Pink Agent can help you understand requirements, modify a project, and iterate on a game. Whether it can complete a task also depends on the available tools, the project environment, and the information you provide. Keep the following in mind:

• Available tools and permissions limit what Agent can do. Being able to modify the current COCOS project does not mean it can control any application, access other projects, or manage external services. When a task extends beyond the current scope, ask Agent to explain which tools, environment, and permissions it needs, and which parts it can complete now.
• Provide context explicitly. Do not assume Agent can see the screen you are viewing, your playtest, or another conversation. When continuing work, identify the current project and the results to preserve. When reporting a problem, include screenshots, reproduction steps, or error messages.
• Break complex goals into steps. This tutorial demonstrates a development workflow for one small game. It does not mean a game of any size or type can be generated in a single attempt. When adding complex mechanics or integrating an unfamiliar system, validate a minimal example first, then expand it gradually.
• Code and assets may need rework. Agent may misunderstand rules, miss states, or generate images with incorrect details or an unsuitable style. Give specific feedback and continue refining. If attempts repeatedly fail, narrow the problem and ask Agent to explain what it has tried and what is blocking progress.
• Preview results have limits. A game running in the current Preview does not guarantee the same behavior on every device, or mean packaging, deployment, or publishing is complete. Validate other platforms and external services in their respective environments.

If Agent cannot complete a request yet, continue with:

Explain the current limitations, what conditions are still missing, and the smallest step you can complete now.