Design and polish your game

Bali can build almost anything you describe, so the quality of your game comes down to design: what the player does, why it’s fun, and how clearly the game communicates. This guide collects the advice that comes up again and again in Jabali’s masterclasses and in the team’s feedback on game-jam entries. Each tip links to the moment in the video where it’s explained.

For how to work with Bali day to day, see Bali best practices.

Settle the core of your game first

From the masterclass Designing Game Systems That Feel Good. Settle these before you ask Bali to build, and make sure they end up in your game design document.

Write down the core loop. In one short sequence, describe what the player does most of the time. In the masterclass example: arrive, explore, find clues, solve puzzles, earn a reward, return to the map, repeat. Watch at 10:33
Name the reward. Decide what keeps players going, such as story reveals, new abilities or higher scores, and tell Bali. Without it, Bali fills the gap with guesses. Watch at 05:16
Spend your detail on what makes the game unique. If your game stands out for its story, art or sound, that’s where your prompts should be most specific. Watch at 06:59
Decide the structure early. For example, how many minor and major challenges each area has. The fuller your design doc, the more control you keep. Watch at 08:22
Decide what players can and can’t choose. For example, whether areas unlock in order or can be visited freely. Watch at 09:50
Use game-design vocabulary. Terms like progression, feedback, risk and reward or parallax carry a lot of meaning, and Bali knows them. You can also ask Bali to review your game against them. Watch at 40:31

Design levels that teach

From the masterclass Prototype to full 3D level with a runtime level editor.

Watch: Place the goal first and keep it visible (0:44)

Place the start and the goal first. Put the spawn point and the end goal down before anything else, and make the goal visible from the start. Filling the space between them is easier than facing a blank level. Watch at 04:58
Leave a trail. Coins placed low, then high, then low show players where to go and that they should jump. Lighting can do the same job. Watch at 08:14
Put a checkpoint before every deadly challenge. An early, low-stakes death also teaches players how checkpoints work. Watch at 09:04
Build the level from stations. Like rides in a theme park, give each area one job: a platforming challenge, a fight, or something to explore. Watch at 10:39
Let enemies explain themselves. An enemy’s look can tell players how to beat it. Spikes on the sides and a flat top suggest jumping on it. Watch at 13:23
Start narrow, then branch out. Begin with one clear path, and open up once players know the basics. Reward detours with collectibles or a secret area. Watch at 20:02
Don’t show everything at once. Blocking parts of the view makes a small level feel bigger and more mysterious. Watch at 28:43
Keep your visual language consistent. If trees mean “you can’t go here”, use them that way everywhere, and you won’t need invisible walls. Watch at 34:31
Play it through many times. Both obvious and subtle problems turn up every time. Watch at 46:02

Polish: what playtesters notice

From the AI Workshop: Polishing Shortlisted Games, where the Jabali team gave feedback on game-jam finalists.

Explain your systems. If your game has more than simple controls, walk players through each interaction and the main loop with a short tutorial, some dialogue, or a first level that teaches. Watch at 08:44
Clean up the HUD. A game with many systems needs a tidy, consistent interface that organizes the information well. Watch at 08:22
Keep things in proportion. Props like rocks and trees should be to scale with the player character. Watch at 09:00
Keep 3D games smooth. Hide faraway objects with fog or simpler stand-ins, and remove objects once they’re behind the player. Test on a machine that isn’t built for gaming. Watch at 13:41
Add effects that suit your art style. Particles, explosions and screen effects that build with speed make a game feel more exciting. Watch at 14:55
Give the game a hook. One idea from the session: time obstacles to the beat of the music, turning a runner into a rhythm game. Watch at 15:31

Place things precisely

Describing positions in words is slow. These approaches give you and Bali a shared way to talk about where things go.

Sketch a wireframe. Draw roughly where UI elements should go, add the image to your project or attach it, and ask Bali to follow it. Watch at 09:49
Ask for a coordinate grid. Have Bali draw a numbered grid or show x and y coordinates on screen, then refer to those numbers in your requests. Watch at 10:48 or 32:16
Have Bali build you a level editor. If you keep spelling out positions, ask Bali to build an in-game editor instead, and say how it should hand the layout back, such as JSON you paste into the chat. Watch at 21:27 or 22:31
Ask for a lock and an undo. When Bali builds you an editor, ask for a way to lock the base terrain so you don’t move it by accident, and make sure undo works. Watch at 16:31

Keep content in data files

Ask Bali to keep levels, items and other content in data files, such as one JSON file per level that the game reads at start.

Changing data is quicker and uses fewer Sparks than having Bali rewrite game code for every new level. Watch at 43:40
Layered data, such as decorations stored separately from base tiles, also makes drawing-order bugs easier to fix. Watch at 35:15
The web game tutorial shows this in practice: the game’s elements and recipes live in a JSON file, so the content grows from 15 to more than 50 elements without touching the game logic.

Prototype first, then polish

Build the hardest mechanic first. Use placeholder shapes until it feels right. There’s no fixed number of prompts a game needs: one system might take 15 and the rest two. Watch at 29:36
Polish once you see the potential. A working prototype you’re happy with comes quickly. When it’s worth it, that’s the time to invest days or weeks in polish. Watch at 50:03