tilemap-data-format — Claude Code skill: map format and setup
This skill guides the design of JSON tilemaps with layers and gameplay metadata. Use it when maps live in source code or need walkability data alongside visuals.
npx skills add 0xheycat/isometric-game-skills --skill tilemap-data-format -a claude-codeWhat tilemap-data-format does
The skill separates map data from rendering. It proposes a JSON grid with layers for ground, transitions, and objects, plus a distinct walkability layer. Tiles should refer to an atlas name or index rather than pixel coordinates.
Tile metadata can include type, walkability, and cost. The format uses a version field for migrations, while the loader checks map dimensions and whether tile indices fall within range. Those checks matter: invalid map data can otherwise pass through loading.
This is a design guide, not a ready-made loader. Its example uses version, w, h, layers, and meta; keeping the format as plain JSON makes it suitable for Git diffs and loading in different environments.
What it helps with
- move tilemaps from source code into data files
- split maps into ground, transition, and object layers
- store walkability apart from visual tile data
- add a format version for migrations
- validate map dimensions and tile indices on load
Example prompts for the agent
- Design a JSON tilemap format with separate ground, transition, and object layers.
- Suggest a way to store tile walkability separately from visuals.
- Add format versioning and loader checks for map dimensions and tile indices.
How to install tilemap-data-format
1Skills CLI (Vercel)
npx skills add 0xheycat/isometric-game-skills --skill tilemap-data-format -a claude-code2Manually: put the files in place
~/.claude/skills/tilemap-data-format/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/tilemap-data-format/
1Skills CLI (Vercel)
npx skills add 0xheycat/isometric-game-skills --skill tilemap-data-format -a codex2Manually: put the files in place
.agents/skills/tilemap-data-format/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add 0xheycat/isometric-game-skills --skill tilemap-data-format -a cursor2Manually: put the files in place
.cursor/skills/tilemap-data-format/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install 0xheycat/isometric-game-skills tilemap-data-format2Manually: put the files in place
.github/skills/tilemap-data-format/SKILL.md1Skills CLI (Vercel)
npx skills add 0xheycat/isometric-game-skills --skill tilemap-data-format -a gemini-cli2Platform CLI
gemini skills install https://github.com/0xheycat/isometric-game-skills --path skills/tilemap-data-formatManually: put the files in place
.devin/skills/tilemap-data-format/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add 0xheycat/isometric-game-skills --skill tilemap-data-format -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about tilemap-data-format
How do I install tilemap-data-format in Claude Code?
Run npx skills add 0xheycat/isometric-game-skills --skill tilemap-data-format -a claude-code. The skill file is at ~/.claude/skills/tilemap-data-format/SKILL.md.
What does tilemap-data-format do?
It guides the design of a JSON tilemap format with separate layers and per-tile metadata. It also recommends format versioning and validation when maps load.
How does the skill handle tile walkability?
It recommends a separate walkability layer, with gameplay metadata kept apart from visuals. The listed metadata examples include type, walkability, and cost.
Source text
SKILL.md · MIT
---
name: tilemap-data-format
description: Use when designing the map data format (layers, tiles, objects, metadata) so maps are editable, versionable, and engine-agnostic.
license: MIT
---
# Tilemap Data Format
## Overview
A good map format separates data from rendering. This skill defines a JSON tilemap with layers (ground, transitions, objects) and per-tile metadata (walkable, type) so designers and the engine share one source of truth.
## When to Use
- You are deciding how maps are stored.
- Maps are hard-coded in source instead of data files.
- You need walkability/metadata alongside visuals.
## Process
1. Separate layers: ground, transitions, objects, and a collision/walkable layer.
2. Store the grid as width/height + arrays of tile indices per layer.
3. Reference tiles by atlas name or index, never by raw pixel coords.
4. Attach per-tile metadata (type, walkable, cost) for gameplay systems.
5. Keep it pure JSON so it diffs cleanly in git and loads anywhere.
6. Version the format with a `version` field for migrations.
7. Validate maps on load (dimensions, indices in range).
```json
{ "version": 1, "w": 32, "h": 32,
"layers": { "ground": [/*...*/], "objects": [/*...*/] },
"meta": { "walkable": [/*...*/] } }
```
## Rationalizations (Stop Lying to Yourself)
| Excuse | Reality |
|---|---|
| "I will hard-code the map in code" | Then designers cannot touch it and diffs are unreadable. Use data files. |
| "One flat array is enough" | Gameplay needs a separate walkable layer. Separate concerns. |
## Red Flags - STOP if you catch yourself:
- Maps embedded in source instead of data files.
- No walkable/collision layer.
- Tiles referenced by pixel coordinates.
## Verification
You are NOT done until every box is checked:
- [ ] Map is pure JSON with separated layers.
- [ ] Per-tile gameplay metadata exists (walkable, type).
- [ ] Loader validates dimensions and tile indices.
© 0xheycat · MIT · 0xheycat/isometric-game-skills