This page shows a minimal but realistic .cub file and explains why it is
accepted by the parser instead of merely pasting raw map text.
Valid map
A valid `.cub` example is a contract between headers, map topology, and spawn rules
The point is not just to show one file that happens to work. A good example exposes why parsing succeeds: complete headers, valid RGB values, one spawn, and a closed map body that later passes BFS validation.
01
Annotated file layout
The example is split into the same logical blocks the parser expects: texture headers, color headers, one separator line, then the map body.
map.cub
1NOtextures/mandatory/no.xpm
2SOtextures/mandatory/so.xpm
3WEtextures/mandatory/we.xpm
4EAtextures/mandatory/ea.xpm
5F80,80,80
6C120,180,255
7·empty separator line
8·111111
9·100001
10·10N001
11·100001
12·111111
02
2D map preview
The preview is static on purpose. It documents structure and semantics rather than reproducing browser-side canvas behavior.
Each success condition corresponds to a real parser or validator expectation before MLX initialization can begin.
✓all 6 required headers are present exactly once
✓texture paths use `.xpm` values
✓RGB components stay within `0..255`
✓exactly one spawn marker exists: `N`
✓map characters belong to the mandatory alphabet
✓the playable area is enclosed before runtime starts
✓
Post-parse state
Once this file passes parsing, the engine has enough information to initialize runtime state.
Texture paths are resolved, floor and ceiling colors are parsed, the grid is stored, and the player can be initialized from the single spawn marker at row 3, column 3.
What makes this example valid is the combination of complete headers, valid
RGB syntax, one spawn marker, accepted map symbols, and an enclosed playable
area.