Generate2dmap

Generate2dmap

Overview

Build the smallest playable map bundle that satisfies the game. Start by choosing a user-facing map_mode, then map it to the lower-level pipeline axes. Do not treat a map as only one image unless the user explicitly asks for a flat visual background.

1. map_mode: tile_mode | scene_mode | side_scroll_mode | grid_mode | room_chunk_mode | baked_scene_mode
2. visual_model: baked_raster | layered_raster | tilemap | layered_tilemap | parallax_layers
3. runtime_object_model: none | separate_props | platform_objects | y_sorted_props | interactive_scene_objects | foreground_occluders | scene_hooks
4. collision_model: none | coarse_shapes | precise_shapes | tile_collision | polygon_walkmesh | trigger_zones
5. engine_target: raw_canvas | Phaser | Tiled_JSON | LDtk | Godot_TileMap | Unity_Tilemap | project-native

Use user-specified parameters when present. When the user does not specify them, infer the lightest playable pipeline from the existing game, camera, collision needs, map scale, and editing needs.

For requests that imply a playable game map, level, stage, room, prototype, or engine scene, do not ship a single baked image as the runtime map unless the user explicitly asks for a flat background only. A baked image may be a background, reference, or preview artifact, but the playable deliverable must expose gameplay geometry and objects as separate layers, props, tile/object data, collision, zones, or engine-native scene nodes.

This skill is for scenes and maps. Do not generate character, enemy, boss, projectile, NPC, player, or animation sprite assets as map deliverables. The map may include scene hooks such as player spawns, actor spawn marker metadata, patrol/encounter zones, arena entrances, gates, exits, and camera triggers, but actor artwork, projectiles, and animations belong in $generate2dsprite.

Read [references/map-strategies.md](references/map-strategies.md) when the pipeline choice is not obvious. Read [references/layered-map-contract.md](references/layered-map-contract.md) before implementing a layered raster map. Read [references/prop-pack-contract.md](references/prop-pack-contract.md) before batching generated props into a sheet.

Map Modes

Use map_mode as the first decision. It is a product-level preset that chooses the initial pipeline axes and expected deliverables:

• tile_mode: editable tile/grid maps for RPGs, monster-taming games, platformers, tactical maps, factory games, and engines/editors that already use tiles. Default axes: tilemap or layered_tilemap + interactive_scene_objects + scene_hooks + tile_collision + trigger_zones.
• scene_mode: base map plus separate props for tower defense, survivors-like arenas, cozy demos, top-down adventure scenes, and visual showcase maps. Default axes: layered_raster + separate_props or y_sorted_props + interactive_scene_objects + scene_hooks + precise_shapes + trigger_zones.
• side_scroll_mode: parallax side-scroller stages for action platformers, runners, Metroidvania rooms, side-view shooters, and beat-em-up stages. Default axes: parallax_layers + platform_objects + interactive_scene_objects + foreground_occluders + scene_hooks + precise_shapes.
• grid_mode: rule-heavy grid scenes for tactical RPGs, factory/automation games, board/card battlers, build grids, and terrain-cost maps. Default axes: layered_tilemap or tilemap + interactive_scene_objects + scene_hooks + tile_collision or grid metadata.
• room_chunk_mode: modular rooms/chunks for roguelikes, Metroidvania rooms, dungeon rooms, and procedural level assembly. Default axes: layered_tilemap or parallax_layers or layered_raster + object layers + exits/connection metadata + collision.
• baked_scene_mode: fixed battle backgrounds, title/menu screens, boss-room concept art, visual novel scenes, point-and-click backgrounds, or other explicitly flat/non-editable scenes. Default axes: baked_raster + none or coarse_shapes.

When the mode and lower-level axes disagree, the mode's playable/editable contract wins. For example, side_scroll_mode always needs separate collision and platform/object data even if it also produces a beautiful full-width preview image.

Genre Routing

When the user gives a genre instead of a technical map mode, choose the mode conservatively:

• Pokemon-like / monster-taming RPG / top-down RPG town or route -> tile_mode with optional separate props, encounter zones, exits, NPC spawn markers, and collision.
• Tower defense / Kingdom Rush-like -> scene_mode with path metadata, build slots, props, collision/blockers, spawn/exit hooks, and optional engine scene scaffold.
• Survivors-like / arena survival -> scene_mode or tile_mode depending on map scale; keep obstacles sparse, define spawn rings/zones, camera bounds, and collision separately.
• Mega Man-like / side-view action platformer / runner / Metroidvania side room -> side_scroll_mode.
• Beat-em-up / brawler -> side_scroll_mode with a walkable belt polygon instead of jump-platform geometry; use parallax/background depth plus props, enemy wave zones, and camera bounds.
• Tactical RPG / strategy grid / factory automation / board-like game -> grid_mode.
• Roguelike dungeon / modular Metroidvania / procedural room assembly -> room_chunk_mode.
• Visual novel, title screen, point-and-click, boss arena concept, or non-playable showcase -> baked_scene_mode unless gameplay/editability is requested.

Image Generation First

This skill is image-generation-first for visual assets. Use built-in image_gen as the default creative art source for base maps, in-world reference mockups, dressed references, stage references, prop sheets, prop sprites, tileset art, parallax layers, battle backgrounds, and other visible map assets.

The agent must write the creative image prompts itself. Do not use scripts to generate creative prompts or to procedurally draw final visual art. Scripts may assemble, slice, chroma-key, crop, validate, compose previews, emit JSON metadata, and wire image-generated assets into engine-native files such as Godot .tscn scenes.

Save every manually written image-generation prompt next to the generated asset as .prompt.txt or in an explicit manifest field. Do not leave accepted generated assets with empty prompt metadata when the run creates new visual assets.

Only use procedural drawing or scripted placeholder art when the user explicitly asks for placeholders, test fixtures, debug maps, or engine scaffolding without final art. If using an engine target such as Godot_TileMap, generate or reuse the visual tileset art first, then use scripts/code only to build tile layers, collision, zones, and scene wiring.

Visual Reference Handoff

When generating an in-world reference mockup from an existing generated base/background, the prior image must be treated as an active visual reference, not just a file path or loose style hint:

1. Save the base/background image first.
2. Immediately before the next image_gen call, make that exact image visible in conversation context. If it is a local file, call view_image on the saved file.
3. In the next image_gen prompt, explicitly say to use the visible image immediately above as the visual reference.
4. Describe concrete features from the viewed image that must be preserved, such as camera framing, horizon, road or water shapes, terrain boundaries, entrance/exit direction, major silhouettes, empty pads, and landmark positions.
5. Generate an in-world reference mockup, not an annotated diagram. Do not draw circles, arrows, outlines, labels, numbers, UI callouts, text, captions, legends, highlighted boxes, highlighted zones, measurement lines, or explanatory overlays.
6. Render proposed visible gameplay objects as natural game-world objects or subtle in-world blockout geometry. Do not draw non-visual metadata such as spawn points, triggers, camera bounds, or patrol hints; write those later as structured scene-hook metadata.
7. Keep reference mockups sparse enough to drive final asset production. Unless the user explicitly asks for a dense concept sheet, include at most 9 distinct visible runtime prop/object candidates in the mockup. Repeated instances of the same platform, lamp, crate, hazard, pickup, or gate count as one candidate and can be repeated later in placement metadata.

Do not rely on a path string, filename, or generic wording like "based on the map" as the reference handoff. If the base/background is not visible in context, stop and make it visible before generating the dressed reference or stage reference.

Layer Separation Contract

For any playable or editable layered map, the first generated base/background/foundation image must not bake in objects that the runtime should control separately. This applies across perspectives and styles: top-down RPG maps, monster-taming maps, tactical arenas, tower-defense lanes, side-view platformers, parallax stages, tile/editor workflows, clean HD, pixel-inspired, and retro pixel art.

The base/background/foundation layer may contain only stable non-interactive foundation art:

• top-down or 3/4 maps: ground material, paths, roads, water, cliffs, low terrain markings, floor patterns, and terrain boundaries
• tactical or tower-defense maps: ground, lanes, roads, build pads, lane markings, terrain zones, and non-interactive floor detail
• side-view stages: sky, far/mid scenery, distant buildings, distant terrain silhouettes, atmosphere, and non-colliding depth
• tilemaps: tileset art and tile layers arranged as editable engine data, not a flattened full-scene background

The base/background/foundation layer must not contain runtime-controlled objects unless the user explicitly asked for a single baked image:

• tall props, buildings, trees, rocks, crates, signs, doors, gates, pickups, chests, checkpoints, hazards, traps, turrets, tower objects, ladders, foreground occluders, destructibles, actors, enemies, NPCs, bosses, player characters, UI, labels, or any object that needs collision, interaction, replacement, reuse, y-sorting, animation, engine editing, or independent render order

If a generated base/background already contains those runtime objects, do not use it as the runtime base. Regenerate a cleaner foundation-only base or demote that image to a concept/reference artifact. The next in-world reference mockup is where proposed objects may appear, and the final runtime must still use separate generated props, platform objects, object layers, tile layers, collision, zones, and scene-hook metadata as appropriate.

Parameter Contract

User-facing parameters may be stated in natural language:

• map_mode: tilemode | scenemode | sidescrollmode | gridmode | roomchunkmode | bakedscene_mode
• map_kind: overworld | town | dungeon | shrine | arena | battlebg | sidescroller | sideviewaction | platformer | metroidvania | brawler | towerdefense | survivorslike | tactical | factory | cardboard | roomchunk
• visual_model: baked raster | layered raster | tilemap | layered tilemap | parallax
• size: pixel dimensions, tile dimensions, or camera-relative size
• stage_canvas: exact pixel dimensions and aspect ratio for side-scroll/parallax layers, references, and previews
• perspective: top-down | 3/4 top-down | side-view | isometric-like
• art_style: cleanhd | pixelinspired | retropixel | handpainted | project-native
• visual_asset_source: imagegen | existingassets | procedural_placeholder
• collision_precision: none | coarse | precise | tile | walkmesh
• prop_generation: none | onebyone | proppack2x2 | proppack3x3 | proppack4x4 | platformstrip1x3 | platformstrip1x4 | customwidepack
• output_format: PNG only | layered preview | manifest JSON | engine-native map data

When unspecified:

• Use image_gen as the visual asset source.
• Infer map_mode from genre and editing needs before selecting lower-level axes.
• Use tile_mode for Pokemon-like, top-down RPG, monster-taming, editor/grid-perfect, or tilemap requests.
• Use scene_mode for tower defense, survivors-like, cozy/top-down showcase maps, and base-map-plus-props requests.
• Use side_scroll_mode for side-scrollers, platformers, runners, side-view action, brawlers, Metroidvania side rooms, Mega Man-like, Castlevania-like, Contra-like, and parallax background requests.
• For side_scroll_mode, choose a canonical stage_canvas before image generation. Use the project camera/viewport aspect when available; otherwise default to a 16:9 side-scroller canvas such as 1536x864. All primary parallax plates, stage references, and previews must preserve this same size/aspect.
• Use grid_mode for tactical RPGs, factory/automation maps, board/card battlers, build grids, and terrain-cost maps.
• Use room_chunk_mode for modular rooms, roguelike rooms, procedural room assembly, or Metroidvania room-chunk planning.
• Use baked_scene_mode only for non-playable visual scenes or explicitly flat images.
• Use baked_raster + coarse_shapes only for battle backgrounds, title/menu scenes, cutscenes, decorative backdrops, non-playable previews, or when the user explicitly asks for a single flat image.
• Use layered_raster + y_sorted_props + precise_shapes for top-down RPG exploration with tall props, occlusion, interactables, or reusable props; the base must be foundation-only and the props/interactables must remain separate.
• Use tilemap or layered_tilemap only when the engine/editor already uses tiles or the user asks for editable tiles; do not flatten gameplay objects into one background image.
• Use parallax_layers + platform_objects + interactive_scene_objects + scene_hooks + precise_shapes for playable side-view scrolling stages, platformers, runners, shooters, and horizontal action scenes; the parallax/background image is scenery-only and is not the runtime map by itself.
• Use square prop packs only when 4 or more compact small/medium static props share one style and fit comfortably inside equal square cells.
• Use one-by-one, platform strips, tile/object layers, or custom wide packs for hero props, buildings, gates, irregular large props, wide/tall props, platforms, terrain chunks, bridges, walls, ladders, long hazards, animated props, or props needing strong identity or collision alignment.
• Use clean_hd for generated exploration maps unless the project or user asks for pixel art. This means clean hand-painted top-down 2D RPG game map, HD game asset style, sharp readable terrain shapes, low texture noise, and no chunky pixels.
• Use pixel_inspired only when the user wants a pixel-adjacent look without retro chunkiness.
• Use retro_pixel only when the user explicitly asks for 16-bit, retro JRPG, or classic pixel-art maps.

Workflow

1. Inspect the target game.

• Find camera size, map dimensions, coordinate system, render order, asset loading, collision support, zone data, and existing map formats.
• Preserve the engine's existing style and data contracts.

1. Choose the pipeline axes.

• Choose map_mode first. Use the genre routing table when the user describes a game type instead of a technical map format.
• Select visual_model, runtime_object_model, collision_model, and engine_target.
• If the request is for a playable map, stage, level, room, prototype, or game scene, choose a pipeline with explicit runtime objects. Do not downgrade to baked_raster unless the user asked for a background-only image.
• If the request implies a playable side-view scrolling/action stage, such as a side-scroller, platformer, runner, shooter, brawler, scrolling combat stage, Megaman-like stage, Castlevania-like stage, or Contra-like stage, lock the map pipeline to parallax_layers + platform_objects + interactive_scene_objects + scene_hooks + precise_shapes unless the engine already r

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: 0x0funky
• Source: 0x0funky/agent-sprite-forge
• License: MIT

Install and usage instructions live in the source repository linked above.