How to Annotate a Color Block Jam Board Step by Step

What should each label represent?

Every label should stand for something a reader can point to on the board. Name the block group, its destination, and any obstacle that controls access to it. A label that says “hard part here” does not help anyone, while a label that says “red block, top-left exit, behind chain” tells the reader exactly what to check.

Label	What it names	What it must not claim
Block group	The color or shape and where it sits	That it is the only correct order
Destination	The exit or gate the group feeds	That the path is always open
Key or gate	Which key controls which door	A rule the board does not show
Obstacle	Chain, rope, ice, arrow, or door	A universal unlock step
Shared lane	A route more than one group needs	A guaranteed safe sequence

Rollic’s official How Do I Play Color Block Jam? article explains the core goal of matching blocks to destinations, and that relationship is what an annotation should make visible. The official Obstacles in Color Block Jam article adds the second half: arrows, ice, chains, ropes, and changing doors each have their own unlock condition, so a label should record what an obstacle needs rather than assuming one shared clearing rule.

How should arrows work in an annotation?

An arrow should mean one specific thing: this must happen before that becomes reachable. Keep that meaning consistent across the whole diagram so a reader never has to guess whether an arrow shows a move, a dependency, or a guess.

When you are unsure, do not draw a confident arrow. Mark the spot as uncertain and test it with a move you can undo. Rollic’s obstacle article is a reminder that different objects respond to different actions, so the safest annotation separates what you have seen from what you expect. If a dependency only holds for one route, say so beside the arrow instead of drawing a rule that the board does not support.

Where should you place checkpoints?

Place a checkpoint after each access change, not after every tap. A checkpoint marks a state a reader can compare against their own board, so put one wherever a gate opens, a chain changes, a key passes, or a shared lane frees up.

1. Start from a clean screenshot that shows the level number and the whole board.
2. Add labels for blocks, destinations, keys, gates, and obstacles.
3. Draw arrows only for dependencies you can see.
4. Mark a checkpoint after each access change.
5. Note the first point where your board and the source differ.

Those checkpoints do the same job as the states in the board-match workflow: they give a reader a place to pause and confirm alignment before trusting the next move.

How do you keep the annotation honest?

Keep the original image untouched and treat the drawing as an explanation, not as evidence. If you crop or edit the screenshot itself, a real board difference becomes harder to confirm, and someone re-checking your route cannot tell what you changed.

Label what you can see, and leave a visible gap where you are unsure. A clear “unknown” is more useful than a confident arrow that turns out to be wrong, because it tells the next reader where to look instead of sending them down a route that does not exist.

When is the annotation finished?

Stop when the next move and the next checkpoint are clear. A crowded diagram can hide the dependency it was meant to reveal, so the goal is a readable route, not a complete record of every tap.

Keep the untouched screenshot beside the annotated copy, and note the source you compared. Capture that clean image first using the screenshot guide, then rank the obstacles you marked with the obstacle priority method if several of them affect the same route. An annotation is a reading aid: it organizes what the board shows, and it never proves a hidden mechanism, a guaranteed order, or a universal solution.