Vibe Coding Video Games

Lesson 1

You Are the Designer Now

Vibe coding is a new way to make software: instead of typing code line by line, you describe what you want in plain words, an AI writes the code, and you steer. The term is young and a little silly, but the shift underneath it is real. For a hundred years, making a game meant learning a programming language first. Now the first step is having an idea worth playing.

Your job in this course is the designer's job, and it is the fun job: decide what the game is, play it hard, notice what is missing, and ask for changes in clear words. Claude's job is the programmer's job: write the code, fix the bugs, and resend the whole game whenever you ask. You judge everything by playing it, never by reading code you do not know yet.

Games are the perfect first project for this, because the feedback is instant and honest. A spreadsheet can look right and be wrong. A game that is broken feels broken in three seconds, and a game that is fun makes you grin before you know why. By the end of this course you will have a finished game with your name on it, published on the internet, and Starvard will pay you a $10 bounty for it. Lesson 12 has the details.

Lesson 2

A Toolkit With Nothing to Install

Here is the whole workshop: a browser, a free account with Claude (at claude.ai), and a plain text editor, which your computer already has. That is all. No downloads, no setup weekends, no cryptic error messages about paths and environments. The classic beginner traps are simply not on this road.

The game you build will live in a single file, an HTML file, with the artwork, the rules, and the code all inside it. Claude will hand you the file's text. You copy it, paste it into your text editor, and save it with a name like mygame.html. Then you double click it, and it opens in your browser as a real, playable game. One file is also why publishing later is so easy: one file is the whole game.

One habit to start now: every time Claude sends code, ask for the complete file, never a snippet. Snippets are where beginners drown, pasting fragments into the wrong corners. The magic words are: give me the whole file, ready to save and open.

Lesson 3

One Screen, One Verb

Every failed first game dies the same death: it was too big. An open world with quests, crafting, and a dragon sounds glorious in the shower and collapses by Tuesday. The games that actually get finished by beginners share a shape: one screen, one thing the player does, one way to win or lose.

Pick your verb first, because the verb is the game. Chase: guide a catcher under falling stars. Dodge: weave a ship through rain. Bounce: keep a ball alive against a wall of bricks. Jump: hop a little knight across platforms. Each of these has been a beloved game for forty years, and each fits on one screen with rules a friend can learn in ten seconds.

In this course we will build Star Catcher together: a basket, falling stars, three lives. It is small enough to finish in an afternoon and real enough to teach you everything: movement, scoring, difficulty, sound, publishing. Your own game, the one the bounty pays for, can be any one-screen cousin of it.

Lesson 4

Your First Prompt

A good first prompt does four things: it names the game, the controls, the goal, and the look. It also asks for the technical shape you need: one complete file. Copy the prompt below into Claude exactly as written, and watch what comes back.

Save what Claude sends as star catcher.html, open it, and play. Do not be surprised if it works the first time; modern Claude is startlingly good at exactly this size of game. Also do not be surprised if one thing is off: a star that falls through the basket, a score that double counts. That is not failure. That is the next lesson.

Lesson 5

Play It Like a Player

Before you ask for a single change, play your game for two full minutes with a player's eyes, not a maker's guilt. Where did you smile? Where did you get bored? Where did something feel unfair? Write down the three strongest impressions. Feelings first, fixes second, because the feelings are the design data.

Then report problems the way a witness would: what you did, what you expected, what happened instead. "The star sometimes falls straight through the basket when it falls fast" will get you a real fix. Pasting in an error message you do not understand, or saying "it is broken," gets you a shrug in code form. You are the world's leading expert on what your game feels like. Report like it.

Ask for one change at a time, and make Claude resend the whole updated file after each fix. One change, play, next change. This feels slow for exactly ten minutes, and then you realize your game works after every single step, which is more than most big studios can say mid-project.

Lesson 6

Score, Lives, Stakes

A toy is something you poke. A game is something that can beat you. The difference is stakes, and stakes are a checklist, most of which your Star Catcher already has: a score that climbs, lives that drain, difficulty that rises, an ending that judges you, and a restart that dares you to do better.

If your game is missing any piece, the fix is one sentence to Claude. "Add a 60 second timer and end the game when it runs out." "Every 10 points, show a level banner and drop two stars at once." Each sentence is a design decision, and stringing five of them together is, not coincidentally, what game designers do all day.

While you add stakes, tune the numbers by feel. Stars too slow is a screensaver; too fast is a tantrum. Ask Claude to change speeds, sizes, and rates out loud, in plain words: "make the basket wider and the stars 20 percent slower." Numbers are design, and you are allowed to touch all of them.

Lesson 7

Juice: The Cheap Magic

Game designers have a word, juice, for everything that makes a simple game feel alive: the little pop when you catch a star, the sparkle trail, the thud when you miss, the screen's tiny shake. Juice costs almost nothing to add and changes everything about how a game feels. Players cannot name it, but they can always feel its absence.

Ask for juice one piece at a time, after the game works. "When I catch a star, make a small burst of gold sparkles and play a soft happy beep." "When a star hits the ground, shake the screen a little and play a low thud." Claude can make simple sounds out of pure code, no audio files needed, which still feels like a magic trick the tenth time it works.

The order matters: working game first, juice second, always. Juice on a broken game is frosting on a brick. But once the bones are sound, an afternoon of juice is the difference between a homework exercise and the link your friends actually pass around.

Lesson 8

A New Costume Is a New Game

Here is a secret the whole industry runs on: the same game in a new costume is a new game. Star Catcher with pumpkins and a witch's hat is a Halloween game. With snowflakes and a sled, it is a winter game. With raindrops and a bucket, it is a rainy day game for a completely different crowd. The code barely changes. The feeling changes completely.

Ask Claude to reskin your game and watch how much moves: colors, shapes, the falling things, the catcher, the words on the game over screen. Emoji make wonderful free sprites at this size, one star becomes one pumpkin with a single word changed. Theme is also where your taste becomes visible: two students can finish this course with the same bones and games that feel like different people made them.

One more trick while you are here: ask Claude to put the changeable things, colors, speeds, and lives, in a clearly marked settings block at the top of the file, with comments in plain English. Then, carefully, change one number yourself and reload. Congratulations: you have now edited code, on purpose, and the sky did not fall.

Lesson 9

More Game, Carefully

Your game works, it sparkles, it has a costume. Now you want more: a golden star worth five points, a bomb you must not catch, a wide basket power-up, a second level where everything speeds up. Good. Wanting more game is the correct disease. The cure for the damage it can do is procedure.

The one change rule from Lesson 5 now becomes law. Add one feature, play the game, confirm the old game still lives inside the new one, then add the next. The moment a change breaks something, you have exactly one suspect, the change you just made, and Claude can fix it or you can roll back. Add three features at once and a breakage has three suspects and no witnesses.

Keep a list as you go: what you asked for, whether it worked, what it changed. Designers call this a changelog, and yours doubles as proof of work if a friend asks the eternal question: wait, you actually made this?

Lesson 10

Save Every Version That Plays

There is one copy of your game that is sacred: the last one that worked. Never overwrite it. When Claude sends an improved file, save it as a new version: star catcher v2.html, v3, v4. Disk space is free. Working games are priceless. Every professional you will ever meet has a scar from overwriting the good version; you get to skip that scar by learning their lesson secondhand.

Versions turn disasters into detours. New feature broke the stars? Open the last good version, and ask Claude for a smaller version of the change. You are never more than one file away from a game that plays, which means you can afford to be brave with every request.

Keep the folder tidy: the game files, your notes, your changelog. It is a studio. A tiny, one person, no budget studio, but the folder does not know that, and neither does the work.

Lesson 11

Put It On the Internet

A game on your laptop is a hobby. A game at a link is a published work, and the distance between the two is about ten minutes. Your game is one file, so almost any host will take it. The friendliest door is itch.io, a free site built exactly for small games by small makers: make an account, create a project, upload your file (name it index.html if the site asks), set it to public, and you have a page with your game's name on it.

GitHub Pages and Netlify Drop work too, and Claude can walk you through any of them step by step; "walk me through publishing this file on itch.io like I have never done it" is a perfectly good prompt. Whichever door you choose, the moment that matters is the same: a link that opens your game on somebody else's screen.

Then do the brave part: send the link to three humans. Watch them play if you can. Their confusion is a free design review, their grin is your first review score, and their "send me that link again" is the sound of a game designer being born.

Lesson 12

The $10 Bounty and Your Next Game

Now make it yours. Everything above was practice on a shared game; the bounty is for your game: your verb, your theme, your name on it. It does not need to be big. It needs to be finished, playable from start to game over, and live at a public link.

And after the bounty? You are standing at a trailhead, not a finish line. Make a second game with a verb you have not tried. Ask Claude to explain, in plain English, how your favorite part of your game works, and you will be shocked how much code you can suddenly read. When you are ready for heavier tools, the game engines (Godot is free and beloved) run on the same loop you learned here: describe, play, steer. The loop is the skill. Everything else is wardrobe.