Lesson 1.1: Install Godot and Claude Code

1.1.1 What You Are Installing and Why

Most game development tutorials start with weeks of theory before you touch anything. This course skips that. By the end of this lesson you will have two tools installed and connected. By the end of the next lesson you will have a character moving on screen.

Here is what the two tools are and what each one does.

Godot is a game engine. A game engine is software that handles all the technical machinery a game needs to run: physics, graphics, input from the keyboard, sound, and more. Think of it as the stage where your game lives. Your player character lives in Godot. Your level lives in Godot. When you press Play, Godot is what makes everything run. It is free, has no subscription fee, and is used by thousands of indie game developers worldwide.

Claude Code is an AI tool that writes code directly into your Godot project. You open it, describe what you want to build in plain English, and it writes the code files into your project folder automatically. You do not touch the code. You describe. Claude builds.

Together these two tools replace the part of game development that stops most beginners cold: writing code. You do not need to learn a programming language to finish this course. You need to learn how to describe what you want clearly and specifically. That is a skill you already have. This course sharpens it.

One important thing to understand before you install anything. Claude Code works by reading the files inside your Godot project folder on your computer. That means every time you open a new session it can see what already exists in your game and build on top of it. You are not starting from scratch every time. You are directing a developer who has already read the brief.

1.1.2 Before You Install Anything: What Is a Terminal?

Several installation steps in this lesson use something called a terminal. A terminal is a text-based way to talk to your computer. Instead of clicking icons and buttons, you type commands. The computer reads the command and does what you asked.

It looks plain. It is usually a dark window with a blinking cursor. It feels unfamiliar the first time you see it. That feeling goes away quickly.

You will use the terminal in this course to install Claude Code and to start it before each build session. That is all. You will not be writing code in the terminal. You will be typing short setup commands and then talking to Claude Code in plain English.

How to open the terminal on a Mac: Press Command and Space at the same time. A search bar appears. Type Terminal and press Enter. A window opens with a blinking cursor.

How to open the terminal on Windows: Press the Windows key. Type PowerShell in the search bar. Click Windows PowerShell. A dark window opens with a blinking cursor. On newer versions of Windows you can also search for Terminal and use the Windows Terminal app. Either one works.

When this course tells you to run a command, it means: type that command in your terminal exactly as shown and press Enter.

1.1.3 Step-by-Step Installation

Work through these steps in order. Do not skip ahead. Each step depends on the one before it.

1. Download and Install Godot 4

   Open a web browser and go to godotengine.org. Click the Download button. You will see two options:

   • Godot Engine — this is the standard version. Download this one.
   • Godot Engine .NET — this is for a different programming language called C#. Do not download this one.

   The standard version uses a language called GDScript. GDScript is what Claude Code will write throughout this course. You will never write it yourself, but knowing its name will help when Claude Code refers to it.

   Install Godot like any other app. On Mac, open the downloaded file and drag the Godot icon into your Applications folder. On Windows, unzip the downloaded file and move the Godot folder somewhere easy to find, like your Desktop or Documents folder.

   Open Godot once to confirm it launches. You will see a screen called the Project Manager. It will be empty because you have not created any projects yet. Close it for now.

   

2. Install Node.js

   Claude Code needs another piece of software called Node.js to run. Node.js is a free tool that lets programs like Claude Code run on your computer from the terminal. You only need to install it once.

   Go to nodejs.org. You will see two download buttons. One says LTS and one says Current. Download the one that says LTS.

   LTS stands for Long Term Support. It means this version is stable, well tested, and will keep working for a long time. It is the safer choice.

   Install Node.js with the default settings. After it finishes, open your terminal and type exactly this:

   node --version

   Press Enter. The terminal should show a version number like v20.11.0. The exact number does not matter. Any version number means Node.js installed correctly.

   Tip: If the terminal says "command not found" after typing node --version, close the terminal completely, open it again, and try the command one more time. Closing and reopening forces the terminal to recognize newly installed software.

3. Install Claude Code

   With Node.js installed, you can now install Claude Code. It installs through the terminal using a tool called npm. npm is a package manager, which is a program that downloads and installs other software from the internet. npm comes included with Node.js automatically.

   In your terminal, type exactly this:

   npm install -g @anthropic-ai/claude-code

   Press Enter. You will see text scroll past as it downloads and installs. Wait until it stops and gives you a blinking cursor again. Then confirm it installed correctly by typing:

   claude --version

   A version number should appear. If it does, Claude Code is installed.

4. Get Your Anthropic API Key

   Claude Code connects to Anthropic's servers to generate code. To use it, you need something called an API key. An API key is a unique password that links your Claude Code sessions to your Anthropic account and tracks usage for billing.

   Open a web browser and go to console.anthropic.com. Create a free account if you do not have one. Once you are logged in:

   1. Click API Keys in the left menu
   2. Click Create Key
   3. Give the key any name, like "Game Course"
   4. Click Create
   5. Copy the key that appears. It starts with sk-ant-
   Important: Save this key somewhere safe, like a notes app or a text file on your desktop. Anthropic will not show it to you again after you close that screen. If you lose it, you will need to create a new one.

   What does it cost? Claude Code charges a small amount per session based on how much text is sent and received. For the amount of building you will do in this course, expect to spend between $1 and $5 total. It is pay as you go with no subscription and no minimum charge.

5. Connect Claude Code to Your Account

   Open your terminal. Type exactly this:

   claude

   Press Enter. Claude Code will start and ask for your API key. Paste in the key you copied in the previous step and press Enter. Claude Code will confirm the connection.

   Type this to test it:

   Hello. Are you working?

   Claude should respond. If it does, your connection is working. Type /exit to close Claude Code for now.

6. Create Your First Godot Project

   Open Godot. In the Project Manager screen, click New Project. A dialog box appears. Fill in two things:

   • Project Name: Type MyFirstGame or any name you like
   • Project Path: Click Browse and choose a folder you can find easily. Your Documents folder is a good choice.

   Click Create and Edit. Godot opens your new empty project.

7. Get Familiar with the Godot Editor

   Take 60 seconds to find these four panels before moving on. You will use them throughout the course.

   • Scene Tree (top left): Where your game objects live. Everything you add to a scene shows up here as a list.
   • FileSystem (bottom left): Shows all the files in your project folder. Scripts, scenes, images, and sounds all appear here.
   • Viewport (center): The main canvas. Shows what your game scene looks like.
   • Inspector (right): When you click on an object in the Scene Tree, its settings appear here. You can change colors, sizes, positions, and more.

8. Open Claude Code Inside Your Project Folder

   This step connects everything together. You are going to open Claude Code inside your Godot project folder so it can read and write your project files.

   First, find your project folder path. In Godot, go to Project in the top menu and click Open Project Folder. A file browser opens showing your project files. Look at the address bar at the top of that window. That is your folder path. Copy it.

   Now open your terminal. You need to navigate to that folder using the cd command. cd stands for change directory. A directory is another word for a folder. The cd command moves your terminal session into the folder you specify.

   Type cd followed by a space and then paste your project folder path:

   cd /Users/yourname/Documents/MyFirstGame

   On Windows it looks like this:

   cd C:\Users\yourname\Documents\MyFirstGame

   Press Enter. Then type:

   claude

   Press Enter. Claude Code starts and is now reading your Godot project folder. You are fully set up.

1.1.4 Confirming Everything Works

Run these two checks before moving on. They take about two minutes.

Check 1: Claude Code can see your project

In your Claude Code terminal session, type exactly this:

Claude should respond with a list of files including project.godot. If it does, Claude Code can read your project correctly. If Claude says it cannot find any files, you are in the wrong folder. Type /exit, use cd to navigate to the correct project folder, and run claude again.

Check 2: Godot runs

Switch to Godot. Press the Play button at the top center of the screen. It looks like a triangle pointing right. A small window appears. It will probably be empty. That is fine. Close the play window by clicking the X.

If both checks pass, you are ready for Lesson 1.2.

Lesson 1.2: Your First AI-Built Game Scene

1.2.1 How to Write a Prompt That Gets Results

Claude Code is powerful but it is not a mind reader. The quality of what it builds depends almost entirely on how clearly you describe what you want. This section gives you a simple three-part formula that works every time.

Part 1: Context

Tell Claude Code what kind of game you are building and what files already exist in the project. This stops it from building something that does not fit or recreating files that already exist.

Part 2: Task

Tell Claude exactly what you want built. Be specific. Name the behavior, the controls, and the numbers. Vague descriptions produce vague results.

The difference is numbers and named actions. "Moves" tells Claude nothing useful. "Moves left and right with arrow keys at 200 pixels per second" tells Claude exactly what to build.

Part 3: Confirmation Request

End every single prompt with this sentence:

This keeps you in control. If Claude creates a file you did not expect, you will know about it before it causes problems later.

1.2.2 The Starter Prompt: Copy, Paste, Run

This is your first real build session. The prompt below is ready to use. Copy it exactly as it appears, paste it into your Claude Code terminal, and press Enter.

After you press Enter, Claude Code will work through the task. This usually takes 15 to 30 seconds.

What Claude's response should look like: Claude will tell you it created two files: Player.tscn and player.gd. It will list the nodes inside the Player scene: a CharacterBody2D at the root, with ColorRect and CollisionShape2D as children.

A scene in Godot is a reusable group of objects saved as a file. Player.tscn is your player character scene. The CharacterBody2D is the root node that Godot uses for physics-based characters that move and collide with things. The ColorRect is a colored rectangle used as a placeholder visual until you add real artwork later. The CollisionShape2D is the invisible shape Godot uses to detect when your player touches other objects.

You do not need to read or understand the script. You need to confirm the file names match what you asked for.

Adding the player to your main scene:

Claude Code created the player as a separate scene file. Now you need to place it inside your main game scene so Godot can run it.

1. Switch to Godot.
2. Look at the FileSystem panel on the bottom left. You should see Player.tscn listed there.
3. Look at the Scene Tree panel on the top left. It shows the objects currently in your scene.
4. Drag Player.tscn from the FileSystem panel up into the Scene Tree panel. Drop it there.
5. Press the Play button at the top of Godot.

Use the arrow keys. Press the spacebar. Your character moves. You built that by describing it in plain English. That is the complete workflow of this course.

1.2.3 What to Do When Something Does Not Work

Most first sessions work correctly on the first try. When they do not, the fix is almost always one short follow-up prompt. Here are the four most common problems and exactly what to do.

Problem 1: The character does not appear on screen

The Player scene exists but was not added to the main scene. In Godot, drag Player.tscn from the FileSystem panel into the Scene Tree panel. Press Play again.

Problem 2: The character falls straight through the screen with nothing to land on

There is no floor in the scene yet. That is normal. The full level environment gets built in Module 3. For now, add a temporary floor by typing this into Claude Code:

A StaticBody2D is a Godot node for objects that do not move, like floors and walls. Your player will land on it and collide with it correctly.

Problem 3: Red text appears in Godot's Output panel

The Output panel is at the bottom of the Godot editor. Red text there means an error occurred. Copy the entire red message. Switch to your Claude Code terminal. Paste the error and type:

Claude Code will read the error, find the cause in your project files, and fix it. This is called the debug loop. You will use it throughout the course.

Problem 4: The character moves but does not jump

The jump is probably working but there is nothing to land on, so it is hard to see. Add the temporary floor using the prompt from Problem 2 above. With a floor in place, the jump will work as expected.

Lesson 2.1: The One-Page Game Design Document

2.1.1 Why You Need a Plan Before You Prompt

You already have a moving character. The next instinct is to keep building, keep prompting, keep adding things. Do not do that yet.

Here is what happens without a plan. You prompt Claude to add an enemy. Then you prompt it to add coins. Then you decide the enemy should shoot. Then you realize you never defined what winning means. Three hours later you have a collection of systems that do not fit together and no clear finish line.

A plan stops that from happening.

The plan you are going to write is called a Game Design Document, or GDD. In professional game studios a GDD can be hundreds of pages long. Yours will be one page. Six fields. Twenty minutes to complete.

The GDD does two things. First, it forces you to make decisions about your game before you start building. Second, it becomes a reference you paste into Claude Code at the start of every session so Claude always knows what game it is building.

Claude builds better when it knows the full picture. Right now Claude knows you have a player that moves. It does not know what kind of game this is, what the player is trying to do, or what happens when they succeed or fail. The GDD gives Claude that context.

2.1.2 The Six Fields You Need to Fill In

Open a notes app, a Google Doc, or a piece of paper. Fill in these six fields. Keep every answer short. Two sentences maximum per field.

2.1.3 The Scope Trap and How to Avoid It

The most common reason first games never get published is scope creep. Scope creep is when a project keeps growing because new features get added before the original ones are finished. The idea starts small. Then features get added. The finish line keeps moving. Six months later the project is abandoned.

Here is the test. Read your GDD out loud. If completing this game would take more than one sitting to play, your scope is too large. Cut something.

• If your win condition involves multiple bosses, cut it to one.
• If your lose condition involves a complex health system, cut it to one hit.
• If your scope says three levels, cut it to one.

You are not making a lesser game by cutting. You are making a game that will actually exist. A finished simple game beats an unfinished complex game every single time. You can always build a sequel.

Lesson 2.2: Turning Your GDD Into a Build Plan

2.2.1 Why Build Order Matters

Claude Code builds one system at a time. That is how it works best. If you ask Claude to build movement, enemies, scoring, and a win screen all in one prompt, the result will be messy, hard to test, and full of errors that are difficult to trace.

The right approach is to build one system, test it, confirm it works, then build the next system on top of it. This is called iterative development. Iterative development means building in small tested steps rather than all at once. Every professional game developer works this way, whether they use AI or not.

There is also a specific order that works better than any other for a simple 2D game. Each system depends on the one before it. Enemies need a level to patrol. Scoring needs a game loop to track. A win screen needs a win condition to trigger it.

The correct build order for your game is:

1. Player movement (done in Module 1)
2. Level environment
3. Enemies or obstacles
4. Scoring
5. Win and lose states
6. Art and sound
7. Polish and bug fixes
8. Publish

This course follows that order exactly. Each module from here covers one item on that list.

2.2.2 How to Write Your Seven Build Prompts

Before you start building anything in Module 3, you are going to write your prompts in advance. This takes about 15 minutes and saves hours of vague, unfocused Claude Code sessions.

Each prompt follows the same three-part formula from Module 1: context, task, and confirmation request.

The context section of every prompt starts with a two-sentence summary of your GDD. This gives Claude the full picture at the start of every session so it never builds something that does not fit your game. Here is how to write your GDD summary. Take your Game Type field and your Core Mechanic field and combine them into two sentences:

You will paste this summary at the start of every prompt from Module 3 onward.

Now write your seven prompts using the template below. Fill in the task section for each one based on your GDD. The context and confirmation request are the same every time.

2.2.3 A Completed Example

Here is what a filled-out prompt sequence looks like for a simple platformer. Use this as a reference when writing your own.

Lesson 3.1: Prompting Claude Code to Build Your Mechanic

3.1.1 Setting Up Every Claude Code Session the Right Way

You wrote your seven prompts in Module 2. Now you run the first real one. Before you paste anything into Claude Code, there are four habits that make every session work. Build these in now and the rest of the course gets easier.

Habit 1: Always start with your GDD summary. The two-sentence summary you wrote in Lesson 2.2 goes at the top of every session. Claude Code remembers the project files but not the design choices. The summary is how you keep it pointed at the right game.

Habit 2: Tell Claude what already exists before asking for something new. If you have Player.tscn already, say so. This stops Claude from rebuilding the player from scratch and overwriting your work.

Habit 3: Ask one system at a time. Do not ask for movement and enemies in the same prompt. Do not ask for a level and a score system in the same prompt. One system per session. Test it. Then move to the next.

Habit 4: End every prompt with a confirmation request. The closing line you learned in Lesson 1.2 stays on every prompt for the rest of the course: Tell me the name of every file you created or changed. If Claude touches a file you did not expect, you ask what it is before you press Play.

3.1.2 The Core Mechanic Prompt Library

You already have a moving player from Module 1. The Module 1 starter prompt covered basic platformer movement. This section gives you full prompts for three game types so you can pick the one that matches your GDD.

Pick one prompt. Run it as-is the first time. Customize after it works.

If your GDD says platformer:

Coyote time is a small grace period after the player walks off a ledge where they can still jump. It is named after a cartoon character who could run off cliffs without falling for a second. Adding 0.1 seconds of coyote time makes a platformer feel responsive instead of unfair.

If your GDD says top-down:

If your GDD says endless runner:

After Claude responds, look at the file list. It should only mention player.gd. If it created a new scene file or changed Player.tscn, ask Claude what it changed and why before pressing Play.

3.1.3 Testing the Mechanic Before Moving On

Press Play in Godot. Move the player around. Do this for a full minute before deciding if it works. First impressions of game feel are unreliable. A minute of play tells the truth.

What you are checking for:

• Movement responds the moment you press a key, not half a second later
• Jumping feels predictable. The same press produces the same jump every time.
• No red error text appears in the Output panel (the bottom panel in Godot, already covered in Lesson 1.2)
• The player does not slide, drift, or get stuck on edges

If something feels off, the fix is almost always a one-sentence follow-up prompt. Examples that work:

Lesson 3.2: Building Your Level Environment

3.2.1 What a Minimal Level Needs

A working mechanic with no level to play it in is not a game. It is a tech demo. This lesson gives the player a place to be.

Your first level needs four things only. A floor so the player does not fall forever. Some platforms or walls so movement is interesting. A start point where the player spawns. An end point where the player can win. That is it.

Resist the urge to build a beautiful, complex level here. Your first level exists to test that your mechanic feels good in real space. You will replace or expand it after the rest of the systems work.

In Godot, 2D levels are built using something called a TileMap. A TileMap is a special node that lets you paint a level using a grid of small image tiles, like building with Lego blocks. Instead of placing every floor piece by hand, you select a tile and paint it onto the grid. Godot handles the spacing and the collision automatically.

The image set the TileMap pulls tiles from is called a tileset. A tileset is just a single image file with a bunch of tiles arranged in a grid. Godot ships with a default placeholder tileset built in, which is what you will use for now. Real art comes in Module 6.

3.2.2 The Level Prompt and What to Expect

Open Claude Code in your Godot project folder. Paste your standard session opener (GDD summary plus list of existing files). Then paste the level prompt below.

Claude Code will create Level.tscn and may also create or modify a level.gd script for the camera follow logic. The Camera2D node is what keeps the view centered on your player as they move. Without it, the player walks off screen and you cannot see them anymore.

Open Level.tscn in Godot. You should see a basic blocky level with a floor, two platforms, and walls on each side. It will not look pretty. That is correct.

3.2.3 Connecting the Player to the Level

You now have two scenes: Player.tscn from Module 1 and Level.tscn from this lesson. They are separate files. The level scene needs to know about the player scene before they work together. The way scenes use other scenes in Godot is called instancing.

Instancing means you take a finished scene like Player.tscn and drop a copy of it inside another scene like Level.tscn. Each copy is called an instance. You can change the player scene later and every level that uses an instance updates automatically.

Send Claude this prompt:

Open Level.tscn and press Play. The player should appear on the floor. Walk left and right. Jump onto the platforms. The camera should follow you. If anything falls flat, send the specific behavior to Claude. Do not edit the scene by hand.

Once everything works, save a backup of your project. On Mac or Windows, right-click the project folder and choose Compress. Name the compressed file game-checkpoint-1. Move it somewhere outside the project folder. If something breaks badly later, you can come back to this point.

Lesson 4.1: Choosing the Right Challenge for Your Game

4.1.1 Challenge Type Options and Which Fits Your Mechanic

Your game has a player that moves. It has a level to move through. Right now nothing stops the player from walking to the end and winning immediately. That is not a game. That is a hallway.

A challenge is anything that requires the player to do something skillfully to avoid losing. In most games the challenge is an enemy, a hazard, or an obstacle. Your first game needs exactly one. Not two. One.

Adding a second challenge type before the first one works creates a debugging nightmare. You will not know which system broke the game. Keep it to one and get it right.

There are three challenge types covered in this module. Pick the one that matches your GDD's core mechanic.

Patrol enemy — An enemy that moves back and forth between two fixed points. It reverses direction when it hits a wall or reaches the end of its path. The player must time their movement to get past it or jump over it. This fits platformers best.

Chaser enemy — An enemy that detects the player when they get close enough and then moves toward them. It has a detection radius, which is an invisible circle around the enemy. When the player steps inside that circle, the enemy starts chasing. This fits top-down games best, but also works in platformers where you want the enemy to feel reactive.

Static hazard — A spike, pit, or danger zone that does not move. The player loses on contact. The challenge is pure navigation. This fits any game type but works especially well in endless runners where the level itself moves toward the player.

Look at your GDD. Find the Core Mechanic field. Match it to the table above and pick your challenge type. If you are genuinely unsure, pick the static hazard. It is the simplest to build and the easiest to tune.

4.1.2 Describing Your Challenge to Claude

The most common mistake at this stage is describing what the challenge looks like instead of what it does. Claude Code builds behavior from code. It cannot build a feeling. It can build a specification.

The vague version requires Claude to make three or four decisions you should be making. It will make them differently every time, and the result will need multiple rounds of follow-up fixes.

The specific version gives Claude exactly what it needs. One session. One result.

Every challenge description needs three things:

1. The behavior. What does it do? Move, chase, sit still. How fast. Between which points or within which radius.
2. The trigger. What counts as a hit? Touching the enemy, entering a zone, falling into a pit.
3. The consequence. What happens when the player is hit? Restart the scene, lose one life, go to a game over screen.

The Challenge Prompt Library in the next subsection has all three built in. You do not need to write these from scratch. But understanding why those three things matter will help you write follow-up prompts when you need to tune the result.

4.1.3 The Challenge Prompt Library

Find your challenge type below. Copy the matching prompt. Paste it into Claude Code after your standard session opener (GDD summary plus list of existing files).

Run each prompt as written before changing anything. Customize after it works, not before.

Lesson 4.2: Testing and Tuning the Challenge

4.2.1 What Playable Difficulty Feels Like

Press Play. Try to reach the end of your level. Count how many attempts it takes before you get there.

If you reach the end on your first try without dying, the challenge is too easy. A player who has never seen your game will find it even easier than you do, because you built it and you know where everything is.

If you die ten times in a row without making meaningful progress, the challenge is too hard. Players quit games that feel unfair. They do not assume they will eventually win. They assume the game is broken.

The target for your first game is two to four attempts to complete. That range is not a design opinion. It is the window where a new player feels challenged but not cheated. Below two attempts and the game is forgettable. Above four and most players will not finish.

Play your level ten times in a row. Track how many runs end in a win versus a death. If you win more than eight out of ten, the challenge needs to get harder. If you win fewer than two out of ten, it needs to get easier. You are the only person who can make this judgment. Claude cannot play your game.

4.2.2 Follow-Up Prompts for Tuning

Every tuning change is a one-sentence prompt. Short and specific. One variable at a time.

After each change, press Play and test again before sending the next prompt. If you send three tuning requests at once, you will not know which one made things better or worse.

If the patrol enemy is too fast or too slow:

If the patrol enemy's patrol range is wrong:

If the chaser enemy detects the player too early or too late:

If the chaser enemy moves too fast once it detects the player:

If the static hazard placement is wrong:

If the hit response is wrong:

4.2.3 Fixing the Restart Loop

Before you move to Module 5, the death and restart loop needs to work cleanly every single time. This is a requirement, not a suggestion.

A scene reload is what happens when get_tree().reload_current_scene() runs. Godot destroys the current level and loads it fresh from the saved file. The player returns to their starting position. Enemies reset to their starting positions. The score resets if you have one. Everything goes back to zero.

Test the restart loop like this:

1. Press Play.
2. Walk into your challenge on purpose.
3. Confirm the scene reloads and the player spawns at the start.
4. Walk into the challenge again immediately.
5. Confirm it reloads cleanly a second time.
6. Play through to the end of the level.
7. Die once more after that.
8. Confirm the reload still works.

If the scene does not reload, or if it reloads but the player spawns in the wrong place, or if the enemies do not reset to their starting positions, send Claude this prompt:

Fill in the bracket with what you actually observe. "The enemy does not reset" is a description. "The enemy teleports to the corner of the screen" is more useful. The more specific you are, the faster Claude fixes it.

4.2.4 Saving Checkpoint 2

Once the challenge is in, the difficulty feels right across ten test runs, and the restart loop works every time, save a backup.

Right-click your Godot project folder. Choose Compress (Mac) or Send to Compressed Folder (Windows). Name the compressed file game-checkpoint-2. Move it somewhere outside the project folder, the same place you stored game-checkpoint-1.

If something breaks badly in Module 5 and the fix takes longer than three Claude Code sessions, you can come back to this checkpoint. You lose only the Module 5 work, not everything. Checkpoints are cheap insurance.

Lesson 5.1: Building the Score System

5.1.1 How Scoring Works in Godot

A score system has three parts. Every score system, in every game, has exactly these three parts.

The first part is a score variable. A variable is a named container that holds a number. The score variable stores the current score as the player plays. It starts at zero when the level loads. It goes up each time the player does the right thing.

The second part is a trigger. A trigger is the event that causes the score to increase. It could be collecting a coin, defeating an enemy, reaching a checkpoint, or surviving a set amount of time. The trigger depends on your GDD's win condition. Check your Core Mechanic and Win Condition fields now and identify what should add to the score.

The third part is a display label. A Label is a Godot node that shows text on screen. The label reads the score variable and updates every time the variable changes. This is what the player sees.

Claude Code generates all three in one prompt. You just need to tell it what your trigger is.

The label sits inside something called a CanvasLayer. A CanvasLayer is a special Godot node that keeps its children fixed on screen regardless of where the camera moves. Without a CanvasLayer, the score label would scroll with the level and disappear off screen as the player moves. With a CanvasLayer, the score stays pinned to the corner of the screen at all times.

5.1.2 The Score Prompt and UI Placement

Open Claude Code with your standard session opener. Then paste the Score System Prompt below. Fill in the trigger line based on your game.

Replace the bracket at the end of the task with your actual trigger. Keep it to one sentence. Specific beats long every time.

After Claude responds, check the file list. It should mention Level.tscn and at least one new script file for the score manager. If it also created or changed your player or enemy files, ask Claude what it changed in those files before pressing Play.

5.1.3 Testing the Score Loop

Press Play. Test each of these in order before moving on.

1. Trigger one score event. Does the number on screen increase? If not, the signal is not connected. Tell Claude: The score does not increase when [trigger]. Fix the signal connection between the trigger and the score variable.
2. Trigger the score event five more times. Does the number keep going up consistently? If it skips or resets unexpectedly, describe exactly what you see and send it to Claude.
3. Die and let the scene reload. Does the score reset to zero? If it carries the old score into the new run, tell Claude: The score does not reset to zero when the scene reloads. Fix the score reset logic.
4. Reach a high score through normal play. Does the label stay in the corner without overlapping enemies, platforms, or other UI? If it overlaps something, move it with a follow-up prompt.

A signal is how Godot objects tell each other that something happened. When the player touches a coin, the coin sends a signal. The score manager listens for that signal and adds a point. If the score is not increasing, the signal is either not being sent or not being received. You do not need to understand how signals work in code. You need to describe the symptom and let Claude diagnose it.

Lesson 5.2: Building Win and Game Over States

5.2.1 What a Complete Game Loop Requires

Right now your game has no finish line. The player can walk to the win condition and nothing happens. They can die and the scene restarts, but there is no screen acknowledging it. The game feels unfinished because it is unfinished.

A complete game loop has four states. The player moves through all four during a normal run.

State one is Playing. The player is in the level, moving, and trying to reach the win condition.

State two is Win Screen. The player met the win condition. A screen appears confirming it and showing their score. A button lets them play again.

State three is Game Over Screen. The player hit the lose condition. A screen appears and a button lets them try again.

State four is Restart. The player clicks the retry button. The level reloads and the loop begins again from state one.

Both end screens can be visually simple. A background color, two lines of text, and a button. That is all a first game needs. You can add more later. Ship first, polish second.

5.2.2 The Win and Game Over Prompt

This prompt generates both end screens in one session. Run it after the score system is working.

Fill in the win condition bracket with the exact trigger from your GDD. If your win condition is reaching a door, write that. If it is collecting ten coins, write that. The more specific, the fewer follow-up prompts you will need.

5.2.3 Testing the Full Loop

This is the most important test in the entire course. Run it completely before calling Module 5 done.

1. Press Play. Play normally until you reach the win condition. Does the win screen appear? If not, the win trigger is not connected. Send Claude: The win screen does not appear when [win condition]. Fix the trigger connection to load WinScreen.tscn.
2. On the win screen, confirm your final score is displayed. If the score shows zero or the wrong number, send Claude: The win screen shows the wrong score. Fix the score value passed to WinScreen.tscn.
3. Click Play Again on the win screen. Does Level.tscn reload cleanly? Does the score reset to zero?
4. Play again. This time die on purpose. Does the game over screen appear, or does the level just restart silently? Either is acceptable depending on your choice above — confirm it behaves the way you intended.
5. Click Try Again. Does the level reload? Does the score reset?
6. Check that enemies reset to their starting positions after every restart. If a patrol enemy spawns in the wrong place after a retry, send Claude: After reloading Level.tscn via the retry button, the enemy does not reset to its starting position. Fix the scene reload so all nodes reinitialize correctly.

Lesson 6.1: Finding and Adding Free Art Assets

6.1.1 The Two Asset Sources Worth Your Time

Your game is built with colored rectangles right now. A blue rectangle is the player. A red rectangle is the enemy. That was correct for building. It is not correct for shipping.

A sprite is a 2D image used as a visual for a game character or object. Replacing your placeholder rectangles with sprites is what makes a game look like a game.

You need free sprites that you can use without legal risk. There are two sources worth your time and nothing else.

Kenney.nl is the first stop. Kenney makes professional-quality game art packs and gives them away for free. No account required. No attribution required. No license to track. Download and use. The packs are organized by genre — platformer, top-down, space, racing, puzzle. Each pack contains sprites, tilesets, and UI elements that all match visually.

OpenGameArt.org is the second stop. It has a larger and more varied library. Before downloading anything from OpenGameArt, check the license on the asset page. Filter your searches to show only CC0 assets. CC0 stands for Creative Commons Zero. It means the creator has placed the work in the public domain. You can use it in any game, for free, without attribution, without restriction. Any license other than CC0 has conditions you need to read and follow.

Choose one Kenney pack that matches your game's visual style field from your GDD. Download the whole pack. Use only that pack. One pack used consistently looks intentional. Two packs mixed together look unfinished, even if both packs are good individually.

6.1.2 Replacing Placeholder Assets with Claude's Help

Once you have downloaded a Kenney pack, add the files to your Godot project. Do this before opening Claude Code.

1. Unzip the downloaded Kenney pack on your computer.
2. Inside the unzipped folder, find the folder named PNG or Sprites. These are the individual sprite files.
3. In your Godot project folder on your computer, create a new folder called assets.
4. Copy the sprite files you want to use into that assets folder.
5. Switch to Godot. Look at the FileSystem panel. You should see the new assets folder and its contents listed there. Godot automatically detects new files added to the project folder.

Now open Claude Code with your standard session opener. Paste the asset replacement prompt below.

A Sprite2D is the Godot node that displays a 2D image in the game. Claude will swap your ColorRect nodes for Sprite2D nodes and point each one at the correct image file from your assets folder.

After Claude responds, open Godot and press Play. Check three things.

1. Does the art appear? If a scene still shows a colored rectangle, Claude used the wrong file path. Send: The player still shows a colored rectangle instead of the sprite. Check the Sprite2D texture path in Player.tscn and correct it to point to the right file in the assets folder.
2. Is the art the right size? A tile size is the pixel dimension of one tile in a set — most Kenney packs use 16x16 or 32x32 pixels. If your player sprite appears too large or too small relative to the level tiles, send: The player sprite appears at the wrong scale. The tileset uses 32x32 pixel tiles. Scale the player Sprite2D to match.
3. Do collisions still work? Run into a wall. Jump on a platform. Touch an enemy. If anything stopped working after the sprite swap, the collision shapes may have shifted. Send: After replacing the sprites, [describe what broke]. Fix the collision shapes to match the new sprite positions.

6.1.3 Keeping Art Simple and Consistent

Two rules that prevent the most common art problems at this stage.

Rule 1: One tile size throughout the level. If your Kenney pack uses 16x16 tiles, every tile in your TileMap should be 16x16. Mixing tile sizes in one level creates gaps, overlaps, and collision mismatches that are tedious to fix. Check the pack's documentation or the sprite file dimensions before you build with them.

Rule 2: Skip the background art for now. A solid color background is fine. It takes ten seconds to set in Godot and it will not compete visually with your sprites. You can add a background image after the game ships. Every hour you spend on background art before shipping is an hour the game did not get published.

Lesson 6.2: Adding Sound in Two Prompts

6.2.1 Where to Get Free Game Audio

Sound makes a bigger difference than most first-time developers expect. A game with no audio feels unfinished even when the art looks good. Background music sets the mood. A single sound effect at the right moment makes actions feel satisfying. Both together make the game feel real.

You need three audio files. One background music loop. One sound effect for your main action, such as a jump, a collect, or a hit. One sound effect for the win or game over moment. That is the minimum. Do not chase more than that before shipping.

Kenney has audio packs alongside the art packs. Go back to kenney.nl and look for the Interface Sounds pack and the Music Jingles pack. Both are free, no attribution required, and ready to drop into Godot.

If you need something more specific, go to freesound.org. Search for the sound you want. Before downloading anything, click the sound and check the license. Filter to show only CC0 sounds. Search terms that work well: "jump game", "coin collect", "8bit win", "game over jingle", "platformer music loop".

Godot works best with audio in .ogg format. OGG is an open audio file format that Godot can import and play without any extra setup. Most Kenney audio packs include OGG versions. On freesound.org, look for the OGG download option when available. If a file only comes as MP3 or WAV, use a free online converter to convert it before adding it to your project. Search "convert mp3 to ogg free" and use any of the top results.

6.2.2 The Audio Setup Prompt

Add your audio files to your project before opening Claude Code. Create a folder called sounds inside your Godot project folder. Put all three audio files in there. Name them something clear: music.ogg, jump.ogg, win.ogg. Simple names make the prompt easier to write and easier to debug.

Open Claude Code with your standard session opener. Then paste the Audio Setup Prompt below.

An AudioStreamPlayer is the Godot node that plays audio files. Claude will add one to Level.tscn for the music, one to Player.tscn for the jump sound, and one to WinScreen.tscn for the win sound. The volume_db property controls how loud each AudioStreamPlayer is in decibels. Setting music to -10 db keeps it clearly audible but quieter than the sound effects, which is the right balance for a simple game.

Press Play after Claude responds. Walk around the level. Jump. Listen. Then confirm three things.

1. Does music play on level load? If not, the AudioStreamPlayer is not set to Autoplay. Send: The background music does not play automatically when the level loads. Set the music AudioStreamPlayer to Autoplay in Level.tscn.
2. Does the jump sound play? Jump five times in a row. If you hear nothing, the signal connecting the jump action to the AudioStreamPlayer is not wired correctly. Send: The jump sound does not play when the player jumps. Fix the connection between the jump action and the jump AudioStreamPlayer in player.gd.
3. Does the win sound play on the win screen? Play to your win condition and listen when the win screen loads. If it is silent, send: The win sound does not play when WinScreen.tscn loads. Add an AudioStreamPlayer set to Autoplay in WinScreen.tscn using sounds/win.ogg.

6.2.3 Volume and Overlap Issues

Two audio problems come up almost every time. Both have one-sentence fixes.

Music is too loud relative to sound effects:

Jump sound overlaps itself when jumping rapidly:

No sound at all after the prompt: The file path is wrong. Godot is looking for the audio file in a location it does not exist. Send Claude the exact path of your audio files and ask it to check the AudioStream property of each AudioStreamPlayer. Example: There is no sound at all. My audio files are at sounds/music.ogg, sounds/jump.ogg, and sounds/win.ogg inside the project folder. Check that each AudioStreamPlayer points to the correct file path.

Good audio at low volume is better than perfect audio at the wrong volume. If everything is working but the mix feels off, spend five minutes on volume and move on. You can refine audio after the game ships. What matters now is that the game sounds like something, not that it sounds perfect.

Lesson 7.1: The Finish Your Game Checklist

7.1.1 What Finished Actually Means

Finished does not mean polished. It does not mean professional. It does not mean bug-free.

Finished means a stranger can open your game, play it from start to end or game over, and understand what happened without any help from you. No explanation. No context. No "if you press this first then that." They open it. They play it. They get it.

That is the bar. Everything in this module is about reaching that bar before you publish.

Most first games get abandoned at this stage because the creator keeps adding features instead of checking completeness. A new mechanic sounds more exciting than testing the restart loop one more time. A new level sounds more interesting than writing two sentences of instructions. That instinct is what keeps games from shipping.

The checklist below stops that pattern. Go through it item by item. Every unchecked item is a Claude Code prompt. Fix them in the order listed. Then move to Module 8.

7.1.2 The Checklist Items

7.1.3 Fix Priority Order

If multiple items are unchecked, fix them in this order. Do not jump around.

1. Crashes first. A game that crashes is unplayable. Nothing else matters until the game runs reliably.
2. Missing UI second. A player with no main menu, no controls label, and no win screen cannot enjoy the game even if everything else works.
3. Completability third. If a stranger cannot reach the win condition, the game has no finish line.
4. Polish last. Volume balance, label fonts, background color — these are last because they do not block the player from finishing the game.

Lesson 7.2: Bug Fixing with AI

7.2.1 The Three-Step Debug Process

A bug is anything your game does that you did not intend. The player falls through the floor when you expected them to land. The score carries over between runs when you expected it to reset. The enemy walks off the platform edge when you expected it to reverse. Bugs are normal. Every game has them before launch. The question is how fast you fix them.

The three-step process below fixes most bugs in one or two Claude Code sessions. Do not skip steps. Do not guess at the cause. Do not open the script file and try to read the code. Describe and delegate.

Step 1: Reproduce the bug consistently. Before you describe a bug, confirm you can trigger it on purpose. Click the exact sequence of actions that causes the problem three times in a row. If the bug happens every time you do X, it is reproducible. Reproducible bugs are fixable. Bugs that happen randomly and cannot be triggered on purpose are much harder to fix — set those aside and focus on reproducible ones first.

Step 2: Describe what you expected and what actually happened. Do not describe the cause. You do not know the cause — that is Claude's job. Describe the symptom. "When I collect the coin the score should increase but it stays at zero" is a symptom. "The signal is not connected" is a guess at a cause. Send the symptom. Let Claude find the cause.

Step 3: Paste the description plus any error text into Claude Code and say fix this. If the Output panel shows red text, copy it and include it in your message. Red text is Godot's error log — it tells Claude exactly where to look. If there is no red text, tell Claude which scene and which action the problem involves.

7.2.2 The AI Debug Prompt Guide

Use this format for every bug report you send to Claude:

The ten most common first-game bugs and their pre-written descriptions:

7.2.3 When to Stop Fixing and Ship

There is a bug that has now taken three Claude Code sessions and is still not fixed. What do you do?

You ship anyway.

If the bug does not prevent the player from completing the game — if it is a visual glitch, a minor audio issue, or something that only appears in an unusual edge case — add it to a known issues list and publish the game. Every published game has known issues. The ones that succeeded shipped with them.

If the bug does prevent completion — a crash on the win screen, a broken retry button — then it needs to be fixed. Add one more detail to your description, change the phrase "Fix this" to "Try a different approach," and send it again. If a fourth session does not resolve it, ask Claude to work around it rather than fix it directly.

Your goal is a published game. Not a perfect game. Perfect games do not exist. Move to Module 8.

Lesson 8.1: Exporting Your Game from Godot

8.1.1 Why Web Export Is the Right Choice

You have two options when publishing a game. You can export it as a downloadable file that players install on their computer. Or you can export it as a web build — a set of files that runs inside a browser with no download required.

For your first game, web export is the right choice. Every time.

A downloadable file requires the player to trust you enough to install software from an unknown developer. Most won't. A web build requires nothing. The player clicks your link, the game loads in their browser in ten seconds, and they are playing. The difference in how many people actually try your game is enormous.

itch.io supports web games natively. It shows them in an embedded player directly on your game page — a window on the page that runs the game without leaving the site. No separate app. No download prompt. The player sees your game page, clicks Play, and the game starts.

Web export in Godot is free. It requires no paid license, no developer account, and no extra software beyond what you already have installed.

8.1.2 Installing the Web Export Template and Exporting

Godot needs an export template before it can build your game for the web. An export template is an extra component that Godot downloads once and uses every time you export to a specific platform. You install it once and it stays installed.

Follow these steps exactly.

1. Open Godot with your project loaded.
2. In the top menu, click Editor. Then click Manage Export Templates. A window opens.
3. Click Download and Install. Godot downloads the export templates for all platforms including web. This takes one to three minutes depending on your connection. Wait for it to finish.
4. Close the Export Templates window when the download completes.
5. In the top menu, click Project. Then click Export. The Export window opens.
6. Click Add at the top of the Export window. A list of platforms appears. Click Web.
7. Look at the Export Path field. Click the folder icon next to it and create a new folder inside your project called web-export. Set the export path to end with index.html inside that folder. The full path should look like: res://web-export/index.html
8. Click Export Project. A dialog appears. Make sure Export With Debug is unchecked. Click Save. Godot generates the web build files inside your web-export folder.

After the export finishes, open your project folder on your computer. Open the web-export folder. You should see several files inside, including one called index.html. The HTML file is what the browser opens to run your game. The other files in the folder support it — do not move or rename any of them.

8.1.3 Testing the Web Build

Open the index.html file in Chrome or Firefox. Do not use Safari for local web game testing — Safari blocks certain features that Godot web builds need, and the game may not load. Chrome or Firefox only for this step.

Play the full game in the browser. Main menu to win or game over. Test everything.

• Controls respond: Arrow keys, spacebar, all inputs work the same as in the Godot editor.
• Audio plays: Music starts on the level. Sound effects trigger. Win sound fires.
• Win and game over screens load: Reach the win condition. Trigger a death. Both screens appear and the retry buttons work.
• No black screen on load: If the game shows a black screen instead of the main menu, right-click anywhere in the page and look for a console option in your browser. Any red text there is a loading error. Copy it and send it to Claude Code with: The web build shows a black screen when opened locally in Chrome. Here is the browser console error: [paste]. Fix the export so the game loads correctly.

If the game runs slower in the browser than it did in the Godot editor, that is also normal. A small amount of performance difference between the editor and a web build is expected. If the game is unplayably slow, send Claude: The web build runs too slowly in the browser. Optimize the project to reduce the physics process load.

Lesson 8.2: Publishing on itch.io

8.2.1 Setting Up Your itch.io Page

itch.io is a platform for independent game developers to publish and sell games. It is free to use, requires no approval process, and lets you publish a game in under ten minutes. Thousands of players browse it every day looking for games exactly like the one you just built.

Work through the itch.io Publishing Checklist below in order.

8.2.2 Writing a Game Page Description That Gets Clicks

Your description answers three questions. What kind of game is it. What does the player do. How long does one run take. Two to four sentences. Nothing more.

The specific version tells a player in ten seconds whether this game is for them. The vague version tells them nothing useful and signals that the game might not be worth their time.

List the controls on the page below the description. One line. "Arrow keys to move. Space to jump." Players who cannot figure out the controls in five seconds will close the tab.

8.2.3 Sharing Your Game and What Comes Next

Copy your itch.io link the moment the page goes live. Share it the same day. Momentum matters more than waiting for a perfect page. A game shared on launch day gets more plays than the same game shared a week later.

Three places to share that work well for first games:

• Reddit: Post to r/indiegaming or r/gamedev with the link and two sentences about what makes your game worth trying. Read each community's rules before posting — most welcome first-game posts.
• Discord: Game development servers have showcase channels. Search for "game dev Discord" and look for servers with an active #showcase or #share-your-game channel.
• itch.io itself: The platform has community boards where developers share new releases. Post in the "Release Announcements" board.

Read every comment you get. Players will find things you missed and tell you exactly what confused them. That feedback is free design research for your next game.

Your second game will be faster to build. The skills compound quickly. You now know how to take a game idea from zero to published using Claude Code. The first game is always the hardest one. You finished it.