Describing a game Arcade can build

Arcade turns a description into a playable game. The clearer the description, the better the game. Here's how to ask.

Start with one idea

Games are made of a few simple parts: a player, something to catch or avoid, and a way to score. Name those and Arcade has what it needs:

A frog at the bottom of the screen moves left and right. Flies fall from the top. Catch a fly to score a point.

That's a complete game in two sentences.

Say how the player controls it

The CodeCTRL has a direction pad and A and B buttons. If it matters, say what they do:

Move with left and right. Press A to jump.

If you don't say, Arcade picks something sensible.

Add rules one at a time

Once the first version works, build it up with short follow-up requests:

• "Add three lives. Lose a life when a fly reaches the ground."
• "Make the flies faster every 10 points."
• "Show Game Over when lives run out."
• "Give the frog a bigger sprite."

Small steps work far better than one giant request — and MicroChat can explain each change as you go.

Game types that work well

• Catch – something falls, the player catches it.
• Dodge – something falls or flies at the player, who avoids it.
• Collect – the player moves around picking things up before time runs out.
• Tap – press a button at the right moment.
• Simple racing – steer to avoid obstacles.

These fit the CodeCTRL's screen and buttons and keep the code short enough to understand.

Things to keep simple

• Big multi-level games with many enemies get long and hard to follow. Start small.
• Detailed artwork isn't Arcade's strength. Ask for "a simple frog" rather than a detailed drawing; you can always edit sprites in MakeCode later (see Editing your program in MakeCode).
• Sound is limited on the CodeCTRL, so lean on visuals and score.

If the game doesn't build

Occasionally MicroChat's first try has a mistake. It usually fixes it by itself and tells you. If you see "Sorry, I was taking too long," split your idea into smaller requests.