Bali best practices for building games

Bali can help you build, edit, debug and improve your game in natural language. To get the best results, treat Bali like a game development teammate: give clear goals, describe problems carefully and work in focused steps.

This page is the short version. The full guides are Write prompts Bali can act on and Debug with Bali.

The habits that matter most

Agree on the design before Bali builds. End your first prompt by asking Bali to talk it through. See Plan the design with Bali.
Make every prompt specific. Say what “done” looks like and name the scene, asset or script involved. See Make every prompt specific.
Aim for medium-sized tasks. Big enough to matter, small enough to review. See Aim for medium-sized tasks.
Build the hardest part first. Get the core mechanic feeling right before you expand. See Start with the most complex part first.
Report bugs with steps and logs. See Be descriptive when reporting bugs.
Reset the chat when Bali goes in circles. See Reset the chat when Bali gets stuck.

Choose the right agent behavior

Bali has four behaviors: Autonomous, Collaborative, Cautious and Creative. Many creators explore with Creative or Autonomous, then switch to Cautious once the game works. Models and behavior explains when to use each one.

Test before you build too much

Test the game after each major change. A good loop is:

Ask Bali for a focused change.
Preview or run the game.
Check that the change works.
Report bugs with clear reproduction steps.
Save a new version when the result is stable.
Continue building.

This keeps your project easier to debug and improves the quality of each step.

Watch: Get a prototype working, then polish (0:33, from the workshop AI Workshop: Polishing Shortlisted Games)

Save after major changes

After Bali completes an important change and the game works, save a new version. Save after:

A first playable version
A major system starts working
A bug is fixed
A new asset pass is completed
A level layout is updated
A script change works correctly
A publish-ready version is ready

This gives you a safe checkpoint if future edits break something.

Publishing works as a restore point too. Publish whenever a feature works, and if a later change breaks the game, restoring an earlier version is often faster, and uses fewer Sparks, than debugging. Watch at 56:27, 09:16 or 39:16

Quick checklist

Before you ask Bali for a change, check:

Is the task focused and medium-sized?
Did I describe the goal clearly?
Did I mention the scene, asset, script or system involved?
If I’m reporting a bug, did I include reproduction steps?
If there are errors, did I include logs?
Which behavior do I need: Autonomous, Collaborative, Cautious or Creative?
Should I save a version before making this change?

Final tip

Bali works best when you give it clear creative direction and treat each change as a testable step. Build the hardest part first, keep tasks focused, test often, and don’t be afraid to reset the chat when the current approach isn’t working.

Where the full sections moved

This page used to hold the full guidance. Each section now lives in a focused guide:

Section	Now on
Plan the design with Bali before it builds	Write prompts
Write prompts Bali can act on	Write prompts: Make every prompt specific
Aim for medium-sized tasks	Write prompts
Start with the most complex part first	Write prompts
Ask Bali to explain before changing	Write prompts
Put lasting rules in Instructions	Write prompts
Be descriptive when reporting bugs	Debug with Bali
Reset the chat when Bali gets stuck	Debug with Bali
Autonomous, Collaborative, Cautious and Creative modes	Models and behavior
Switch as your project matures	Models and behavior