Using AI to build your game

First time using AI?

“Vibe coding” means telling an AI what you want and having it write or change the code. You can start without knowing much Python. As you go, you’ll need to play the game, spot problems and ask questions about code you don’t understand.

With a chatbot, you usually copy the suggested code into your files yourself. A coding agent can edit files and run commands with your permission. Whichever you use, try the game after every change, even when the AI says it’s fixed.

Work on one change at a time

1. AskDescribe what you want
2. ReadCheck what changed
3. RunTry it yourself
4. SaveSave a working version

Get each change working before asking for another one. It’s much easier to find a mistake when you’ve only changed a few things.

Get a project running

Start by getting the project to run on your computer.

1. Get the team’s project. If someone has already set up the repository, download or clone it and open the folder in your editor.
2. Use the agreed setup. Check the organizers’ instructions for which tools and versions to install. Pygame-CE and Pygbag are proposed, but the setup hasn’t been confirmed yet.
3. Ask for help if you get stuck. Tell the AI whether you’re on Mac or Windows, share the setup instructions and paste the error. Ask what an unfamiliar command does before running it.
4. Make a small change once it runs. Try changing the background color, then run it again to check. Save a working version before moving on.

A chatbot needs you to attach the files or paste the code it should look at. Mentioning a filename alone won’t let it read the file. If you’re using an agent, check that it’s working in the right folder.

I’m new to Python and AI coding. I’m using [operating system] and [editor or tool]. Here are our organizer-approved setup instructions: [paste them].

Help me run the existing starter project. Check what is already installed before suggesting installs. Explain each command and where to run it. Don’t add game features yet. If information is missing, ask me instead of guessing.

Fill in the bracketed parts before sending a prompt. Keep passwords, API keys and other students’ private information out of chats and GitHub. You don’t need to connect the game to an AI service just because AI helped write the code.

Week 1: plan the game

Come up with the game idea as a team. Before asking AI to build anything, agree on what the player does and what they’re trying to achieve.

Write down the plan

Keep a short plan in your shared document or repository. Update it when something changes, and give it to the AI when you start a new chat.

Our idea

What the player does and how it connects to the announced theme.

One round

The action the player repeats, the challenge, and the ending or success condition.

Controls

What each joystick direction and action button does. Use up to eight buttons, without relying on a keyboard or mouse.

First version

What you need for a playable first version, and what you’ll add if there’s time.

Who does what

Who is handling each part, and who will put the pieces together.

The finished game should take about ten minutes to play, but your first version can be much shorter. Get movement, one challenge, an ending and a restart working before adding more levels.

Our team’s game idea is: [your idea]. The theme is [announced theme]. Our current project brief is [paste brief].

Help us reduce this to a small playable version in Python. List what we need first, what can wait, and the biggest technical unknowns. Break the first version into changes we can test separately. Keep our core idea. Don’t write code yet.

Ask AI which parts might take too long or be hard to build. Discuss its suggestions with your team before changing the plan.

Your plan and repository will form the Week 1 submission.

Week 2: build it

Be specific about the change you want. For example: “The player can walk through this wall. Make them stop when they reach it.” You can try that immediately and see whether it worked.

Tell the AI how you’ll test it

Show it what happens now and explain what should happen instead. Include the files it needs, and point out anything that already works and should stay the same.

The game currently has [working features]. Add only [one feature]. Relevant files: [files or code].

It should pass these checks:
1. [An action and its expected result]
2. [An edge case and its expected result]
3. Existing movement and restart still work.

Use the project’s existing approach. Explain which files changed and how I can test the result. Don’t add dependencies or redesign unrelated parts without explaining why they are needed.

After each change

• Review the diff. Ask the AI to explain unfamiliar lines. Watch for unrelated files being replaced or working features disappearing.
• Play the game. Try the new feature, including what happens if you repeat an action or press the wrong button. Check that movement and restart still work. AI can write tests for things like scoring, but you’ll need to judge how the game feels yourself.
• Save the working version. Make a commit with a name like “Add restart after game over,” then push it so your teammates can get the changes.

Working with teammates

Agree on who is changing which files, and get the latest version from GitHub before you start. If you’re working at the same time, separate branches can help; ask someone to show you how. Test the game when you combine your changes. If Git reports a conflict, ask for help rather than overwriting someone’s work.

Keep art and sound files in the project folder so everyone can use them. Agree on filenames before adding them to the game. Record who made what in your shared document, along with any credits for assets you’ve used.

Try the real setup early

Try the game in the browser and on the shared controller early. Something that works in your editor may need changes before it runs on the showcase setup. If you’re using Pygbag, follow its setup guide and ask for help if the browser version won’t run.

By Week 2, someone should be able to play a complete round of the main game, from start to finish. Push your progress to GitHub for the checkpoint.

When something breaks

Describe what you did just before the problem happened. Paste the full error if there is one; a screenshot or short recording can help with visual problems. For example:

What I did

Started a round, held right and ran into the wall.

What I expected

The player stops at the wall.

What happened

The player sometimes passes through it when moving fast.

Evidence

The movement and collision code, speed setting, and a short recording. Include the full traceback if there is one.

Steps to reproduce: [steps].
Expected result: [what should happen].
Actual result: [what happened].
Error output and relevant code: [paste, removing secrets].
Last change before this started: [change].

Explain the likely cause and how to check it. If you need a file or log, ask for it. Then suggest the smallest fix. Keep unrelated behavior unchanged and give me a test that would catch this bug again.

If the same fix keeps failing

After a few failed attempts, stop and compare the code with your last working version. Try to find which change caused the problem, or ask a teammate or teacher to look with you. Don’t let the AI delete files or reset the repository without checking what you’d lose.

If the AI keeps forgetting details, try a new chat. Share your plan, the current files and the bug you’re trying to fix.

Week 3: finish and submit

Leave the last few days for testing and fixing problems. Agree on when you’ll stop adding features so you have time to finish what’s already there.

Let someone else play

Ask someone outside the team to play without you explaining what to do. Watch where they get stuck. If they miss a control or don’t know they’ve won, improve the instructions and let them try again.

• The game starts, reaches an ending or success condition, and restarts without needing the editor.
• The joystick and assigned action buttons work. Instructions, menus and core gameplay do not rely on a keyboard or mouse.
• A complete playthrough works on the agreed Mac, browser and controller setup.
• Images, fonts and sounds load from a fresh copy of the repository. No file points to someone’s Desktop.
• Someone other than the main programmer can follow the README and run the game.
• Contribution records, relevant asset credits and the final repository are ready. Private repositories give the organizing team access.

We are preparing the final hand-in. Here are the project files, README and competition requirements: [attach or paste].

Review for launch problems, missing assets, controller assumptions and unclear run instructions. Prioritize problems that could stop a judge playing. Don’t add new features. For each finding, name the file, explain the problem and give a way to verify it. Say which checks you could not run.

Prepare the README and demonstration

Ask AI to draft a README using your project files. It should explain how to install and run the game, the controls and any known problems. Have a teammate try the instructions from a fresh download of the repository; fix any steps that don’t work.

Practise your 3–5 minute pitch and the gameplay demo. Talk about your idea, how it fits the theme and what your team did. Save a working version before making any last-minute changes.

When you’re ready, submit the repository and check that the organizers can access it.

Useful references

These may help if you get stuck:

• Competition rulesRequirements, checkpoints, judging and submissions.
• GitHub’s AI coding guidanceGiving context and checking AI-generated work. The examples use Copilot; the habits apply more broadly.
• Git and GitHub basicsRepositories, commits, branches and sharing changes.
• Pygame-CE documentationReference and examples for game code.
• Pygbag setup and packagingRunning a compatible Python game in a browser.
• Keeping credentials out of codeWhat to protect and what to do if a secret is exposed.