Test Your Game Without Code: A 30-Minute Routine

You can test your game without code by playing it on purpose: follow a short script, try to break it, then watch someone else play without helping. Thirty minutes of this finds problems your AI cannot notice, because it does not sit in front of the screen.

What does the routine look like?

First 10 minutes: the script

Play from start to finish, following a written list of steps. You are not looking for fun here, only for whether each step does what it should. Your AI writes the list for you, using the prompt below.

Next 10 minutes: try to break it

Stop playing nicely and be a nuisance. Here are things that real players will do sooner or later:

• Press two keys at once, or hammer one.
• Walk backwards at the start of a level.
• Reload the page in the middle of a level.
• Resize the window, or switch to another tab and return.
• Open the menu during something important.
• Lose on purpose. Then lose again.
• Do nothing for three minutes.

To check a phone without owning several, Chrome's device mode shows your game at phone size and can slow your computer by four or six times. Chrome's docs call this a "first-order approximation", so try a real phone before release.

Last 10 minutes: the silent stranger

Hand the game to someone who has never seen it, and say nothing. No hints and no "oh, you have to press E". Sit beside them and write down what they do.

Say you are testing Snail Courier, an invented delivery game. Your tester reaches the parcel desk and stops. For forty seconds they walk around it. Then they ask, "Is this broken?"

Nothing is broken. They simply did not know you press E to pick up the parcel, and no test of the code could have told you that. The answer is one small sign above the desk.

How do you write down what you found?

Every note needs three parts, or your AI will have to guess:

• I did: walked to the desk at the start of day two.
• I expected: a way to pick up the parcel.
• What happened: nothing, and I saw no hint.

One note per problem. Sort them by how badly they stop someone from playing, and fix the top three first. Everything else can wait. The rest of the work is covered in fixing AI generated code.

Whether your AI also writes automatic tests of its own is its choice. They can catch old problems coming back, but they cannot sit next to a stranger.

Paste this to your AI

Write me a play script for testing my game by hand. I do not read code.

1. First draw every screen and game state as a Mermaid diagram, with an arrow for each way to get from one to the next, including losing, quitting and going back. Build it from what is really in the game, and mark anything you could not find.
2. Walk through the diagram and show me any state with no way out, and any arrow that nothing in the game seems to trigger.
3. Turn it into play-script.md: one step per arrow, in plain words, with the real keys and buttons, and what I should see. Do not invent steps. If you are not sure what should happen, write "not sure, please decide".
4. Add a short list of ways to break this particular game, based on what you found in it.

When I send you my notes, take them one at a time. Show me where in the drawing the game leaves what it should do, before you change anything. After each fix, describe how you tried it and what you saw.

Or skip this and connect the MCP: your AI then finds all of this by itself.Connect the MCP

How to check it worked

• Follow the script for five minutes. Do the keys and buttons in it match the real game? If one does not, your AI wrote from memory, so send it back.
• Find your own bug. Compare your break-it notes with the AI's list. Anything you found that it did not is worth a line.
• Count the hints you wanted to give. Every time you nearly spoke, that is a problem to fix.
• Run the same script after a fix. Old problems like to come back.