Create games with AI: a first playable project you can explain

AI can help you turn a game idea into a prototype, especially when you can describe exactly what the player should be able to do. It can also produce a large project that looks convincing and fails on the second round. A small, tested game is a better first finish line than a long feature list.

This guide is for adult beginners and educators supporting older students. Choose an eligible account setup and a device you already have. You will make an original one-screen delivery game, practice reading its rules and keep evidence that it works.

1. Choose an engine for the learning goal

For this first AI-assisted build, we recommend GDevelop because the resulting visual events can be inspected directly. It is our choice for this exercise, not a universal ranking. Check current AI credits, plan limits and education options before committing. Use the core event editor when AI is unavailable.

2. Write a brief that can be tested

Project: Star Courier, an original one-screen 2D game.
Player: a pilot controlled by arrow keys.
Goal: collect five stars, then touch the base to win.
State: StarsCollected starts at 0; Delivered starts false.
Feedback: visible star count and a clear delivery message.
After winning: stop movement; R restarts a fresh round.
Scope: one scene, simple original shapes, no timer or enemies.
Keep the player inside the screen. No account system or purchases.
Build only the next behavior I approve and explain its events.

Write three acceptance checks before generating anything: a star counts once, the base does not trigger an early win, and restart restores all five stars. These checks turn a vague request into an engineering task. Keep them visible while you build.

3. Establish a working scene

Create a blank 2D project with one scene, Delivery. Draw a Pilot, a Star and a Base as Sprite objects. Place one pilot, five spaced star instances and one base. Add ScoreText and MessageText text objects. Create the two scene variables from your brief. Give Pilot a Top-Down Movement behavior and preview the arrow controls.

Save this version before using AI. If movement already fails, fix it now. Testing several new systems at once makes errors harder to isolate. Ask the assistant for a plan before accepting changes, and use the current Ask AI controls documented by GDevelop to review its proposed work.

4. Request one mechanic at a time

Start with collecting. A Pilot–Star collision should increase StarsCollected by one and delete that star instance. Update the display from the same variable. Next, add delivery: reaching Base with five stars and Delivered still false sets Delivered true, shows the win message and stops movement. Finally add restart and screen boundaries.

Implement only star collection in Delivery.
Use Pilot, Star, ScoreText and StarsCollected as already defined.
Each collided star adds exactly one point and disappears.
Do not change movement or create another score variable.
Explain which events you changed and how I can verify the result.

After each request, inspect the events before making another. Name the condition, the action and the variable involved. AI-assisted development does not mean the game itself uses machine learning: this collector follows rules you define.

5. Debug with a reproducible example

Suppose collecting one star adds two points. First check for two overlapping stars or duplicate collision events. Record the actual result and the smallest relevant event group. Ask the assistant to explain possible causes, then test one change. Keep the previous working copy until the new behavior passes.

Expected: touching one star adds one point.
Actual: [describe the observed result and when it happens].
Relevant events: [small excerpt or permitted screenshot].
List the most likely causes, then propose one small change.
Explain why it should work and give me a repeatable test.
Do not rewrite unrelated parts of the project.

If an assistant refers to a missing action or old API, compare its answer with the current engine documentation. Repeatedly regenerating the whole project hides the cause and can remove your own improvements.

6. Test a full round, then a second round

• Hold each direction at all four boundaries; the player stays visible.
• Touch the base with zero and four stars; the game continues.
• Collect one star and wait; the count increases only once.
• Collect five and return to base; victory appears once.
• After victory, movement and collection stop.
• Restart resets the score, player, stars and messages.
• Repeat the complete sequence to catch stale state.

Keep a simple table of expected result, actual result and repair. Have somebody else try the game without coaching. A short controls label and clear feedback often improve a first prototype more than another visual effect. Add touch controls only if mobile play is part of your chosen scope, then test on an actual touch device.

7. Make it yours and share deliberately

Choose one personal contribution: a new delivery rule, an original setting or a different level layout. Explain how it changes play and retest the affected rules. Record the assets you made or have permission to use and where AI helped. Review the project before sharing publicly, and follow the platform’s current account and publishing requirements.

For the complete student-facing build, use CodeTeachers’ GDevelop tutorial. Explore a new design with our game mashup workshop. If you already own an editable GameMaker game, the GM2Godot tutorial covers migration, reports and comparison testing as a separate next project.