Vibe Coding:
Day One

The idea

A first game needs a move, a goal and a limit. “Swipe the rings until every face is one colour” is a starting point. A small scope makes a working first piece easier to judge; it does not promise a finished game tonight.

Try this

Write one sentence. Underline what the player does and how they know it worked.

The idea

These recordings show Classic, Tim Howley’s original cube puzzle unrolled into nine rings. Tim describes it as made with one prompt. The exact original prompt is not on record; this is the maker’s account, not independent proof.

Try this

Watch for the repeated move, then name one behavior you would check in a first version.

The collection

Cube Rings now includes Classic, Pyramid, Shapeshifter, Orbit, Tower, Pocket, Crystal and Hexadeca. Start with Classic to try Tim’s original idea, then use the shape picker to explore the rest.

How it grew

Classic and Hexadeca came from separate Tim Howley submissions. Pyramid, Shapeshifter, Orbit, Tower, Pocket and Crystal are later Renaissance Solutions variations developed with Codex assistance. Tim’s one-prompt account applies only to Classic; the exact original prompt is not on record.

Try this

Play Classic, then try another shape. Notice what changes about the turns and the goal. Read the Game Room build account to see how the collection grew.

The idea

Keep the purpose, constraints, decisions and next play-check in SPEC.md or another plain-text project note. A note is useful only when it is kept current and the tool is asked or configured to read it. Tool-specific instruction files have different names and loading rules.

Try this

Write what must stay true, what is out of scope, and the next small piece. Ask the tool to read it before editing.

The idea

Title, play, pause, ending and play again each need a way in and a way out. A working movement mechanic does not prove that restart clears the score or that pause stops the clock.

Try this

Draw the states and the transitions. Try losing twice, restarting twice and pausing at an awkward moment.

The idea

A small fighting-game idea grows through playable pieces. Treat the build account as one maker’s experience, not a measured estimate of how long your game will take.

Try this

Watch for the repeated move, then name one behavior you would check in a first version.

The idea

A small fighting-game idea grows through playable pieces. Treat the build account as one maker’s experience, not a measured estimate of how long your game will take.

Try this

Play a short session. Notice the title, play, ending and restart states. Read the Game Room build account.

The idea

End each small piece with an observable check: “after restart the score is zero.” Keep tunable numbers together and change one at a time. The moth below is a museum teaching demo, separate from the four source games.

Try this

Change gravity, then flutter. Say what changed. Return to the defaults before comparing another setting.

The idea

A tool checkpoint, a Git commit, a backup and a deployed site protect different things. A local restore does not undo a published change or recover every file a shell command removed. Save a known working version before a risky change and test that you can restore it.

Try this

Name your last working version and where its backup lives. Before sharing, check privacy, rights and the actual hosted game.

The idea

Successive working versions grew into eight original knights. Public use of the model-based material still awaits Tim’s confirmation of the applicable Thrixel plan terms.

Try this

Watch for the repeated move, then name one behavior you would check in a first version.

The idea

Successive working versions grew into eight original knights. Public use of the model-based material still awaits Tim’s confirmation of the applicable Thrixel plan terms.

Try this

Play a short session. Notice the title, play, ending and restart states. Read the Game Room build account.

The idea

A compact premise expands into a larger game. The useful lesson is the sequence of working pieces, rather than the size of the final result.

Try this

Watch for the repeated move, then name one behavior you would check in a first version.

The idea

A compact premise expands into a larger game. The useful lesson is the sequence of working pieces, rather than the size of the final result.

Try this

Play a short session. Notice the title, play, ending and restart states. Read the Game Room build account.

The idea

A useful plan names the repeated move, the states, the settings and small pieces you can judge. Leave unknowns visible. Choosing to share publicly adds questions about rights, privacy, hosting and testing.

Try this

Use the worked example, then write your own. Export it before clearing browser data.

Moth and hedges: worked example

Tap to keep a moth flying through gaps in hedges. The loop is flutter, steer through a gap, score, repeat. States: title, play, pause, ending and restart. First piece: a moth falls and a tap lifts it. Check: one tap changes its upward movement; restart returns it to its starting position.

# My game plan
Title: [to decide]
One sentence: [to decide]
Core loop: [to decide]
States: [to decide]
Settings: [to decide]
First piece and play-check: [to decide]
Sharing and rights: [to decide]

The idea

A slash menu is command discovery, not a universal language. Names and behavior change across tools and versions.

Try this

Open the command menu and read one entry before using it.

The idea

Separate investigation and design from permission to edit. State what may change and the check that will show success.

Try this

Ask for a plan for one movement mechanic before authorizing implementation.

The idea

An Obsidian vault is a folder of notes. Neither tool automatically knows every note: provide the relevant files and protect private material.

Try this

Make an index linking the game idea, decisions and play-checks.

The idea

A skill packages a repeatable workflow. Inspect its instructions and any scripts before trusting it with your project.

Try this

Describe your playtest steps in a small skill, including when to stop.

The idea

Conversation recovery and file recovery are different. Git commits record tracked files; backups protect against losing the repository itself.

Try this

Save a working checkpoint, change something harmless, then prove recovery.

The idea

A repeated check needs a schedule, success condition and failure limit. Repeating a prompt does not establish that the result is correct.

Try this

Define what to check, when to stop and when a person must decide.

The idea

Hooks can execute code when an event occurs. Read the exact command, its trigger and access before enabling it. A hook permission is separate from approving a game design.

Try this

Inspect one proposed hook and explain what approving it would run.

The idea

Parallel work helps when tasks are separable. Shared file edits can conflict; an independent reviewer still needs context and evidence.

Try this

Ask one helper to check restart behavior and another to review instructions.

The idea

MCP and app connections expose external capabilities. Reading a ticket and changing it are different actions; connecting an account is not blanket permission to publish.

Try this

Name the data needed and the exact permitted action.

The idea

Write the game goal, constraints and first check in a project file.

Try this

Try it on a harmless change in a saved project.

The idea

Compare one bounded task before changing your whole workflow. Availability and cost depend on your account.

Try this

Try it on a harmless change in a saved project.

The idea

Ask for a concrete plan, including files and a play-check.

Try this

Try it on a harmless change in a saved project.

The idea

Read the changed files and run the play-check; a small diff can still alter behavior.

Try this

Try it on a harmless change in a saved project.

The idea

Give a reviewer the intended behavior, diff and test evidence.

Try this

Try it on a harmless change in a saved project.

The idea

Identify what will be restored and preserve anything you still need.

Try this

Try it on a harmless change in a saved project.

The idea

Use a separate Git branch or worktree for isolated file changes; a copied chat alone may share the checkout.

Try this

Try it on a harmless change in a saved project.

The idea

Keep durable decisions outside the conversation and check which files are in scope.

Try this

Try it on a harmless change in a saved project.

The idea

Save important decisions in project files before shortening a conversation.

Try this

Try it on a harmless change in a saved project.

The idea

Include the working revision, what passed and the next check.

Try this

Try it on a harmless change in a saved project.

The idea

Define a finite completion condition and inspect the result.

Try this

Try it on a harmless change in a saved project.

The idea

Use the tool’s help and official documentation when a command differs from an example.

Try this

Try it on a harmless change in a saved project.