# Step 1 Map Design And Object Container Guide

## Purpose

The Step 1 page is the creative reference for a game map and its reusable object vocabulary. It should show what the map feels like, how it is divided into zones, where the player starts, where danger increases, what visual language belongs to each area, and which objects must become independent assets later.

This page is not the final Godot tile pack and it is not a giant runtime background. It is the visual and gameplay blueprint that Step 2B converts into object-free terrain tiles, map composition metadata, collision, navigation, zones, spawns, and exits. Objects are only inventoried here; they are generated separately in Step 2A one at a time.

## Production-Ready Handoff Rule

Step 1 must be requested and reviewed as a production handoff, not as loose concept art. A pretty map page is not enough if Step 2 would still have to guess how to separate objects, rebuild terrain, size paths, or preserve the approved composition.

Approve Step 1 only when it gives Step 2 concrete instructions for:

- what the playable map/chunk is
- which visual elements are terrain/background versus independent runtime objects
- which objects must become production sprites later, without requiring Step 2B to generate them
- how wide paths, chokepoints, exits, and combat spaces are
- where collisions, zones, spawns, pickups, object placements, and foreground occlusion should go
- what the object-free runtime map must preserve from the design

If Step 1 cannot provide a ground/object separation plan and actual overlay/export requirements, stop and repair Step 1 before asking for Step 2B or Step 2A.

## Visual Quality Targets

Step 1 should define the quality bar that Step 2B and Step 2A must preserve. Without explicit visual targets, later steps tend to collapse into generic repeated grass, sparse blocker rows, and placeholder-looking objects.

The design page should state:

- terrain density target: sparse, medium, lush, overgrown, rocky, ruined, wet, dry, snowy, etc.
- path personality: soft dirt trail, worn village road, mossy stone path, muddy rut, snow track, cracked floor, etc.
- blocked-edge language: dense forest, cliffs, rocks, walls, fences, water, darkness, ruins, hedges, or other readable boundaries
- palette and value range for ground, paths, boundaries, and future objects
- brush/detail style: painterly, crisp pixel-ish, soft hand-painted, inked, clean cartoon, etc.
- acceptable repetition level at gameplay zoom
- minimum landmark/detail density per screen so the map does not feel empty before objects are added
- which terrain details are safe to bake into the map, such as pebbles, moss, flowers, grass tufts, dirt scuffs, leaves, floor cracks, water ripples, and flat shadows
- which visual elements must remain future Step 2A objects, such as trees, rocks, signs, pickups, fences, gates, chests, shrines, houses, canopies, and interactables

Step 1 should include a small gameplay-scale crop or viewport mockup. The full map can be pretty, but the crop proves whether players will read the route, edge blockers, and terrain mood at the actual camera distance.

## Image Size Strategy

Do not ask ChatGPT or any image model to generate the final 4096x4096 runtime map as one image. Treat 4096x4096 as the Godot world size, not the image-generation target.

Step 1 should ask for:

- a design-page/reference image at a supported image-generation size
- a readable top-down map concept
- an object container showing important objects separately
- tile and material examples
- object placement intent
- overlays or overlay sketches that Step 2 can convert into metadata

The final 4096x4096 map should be composed in Step 3 from tiles and sprites. If Step 1 includes a full-map concept image, that image is only an art direction/reference, not the runtime source of truth.

## Recommended Page Contents

Create one reference page that includes:

- map name
- top-down full-map concept
- zone labels
- player start area
- intended player navigation direction and main progression path
- optional side paths, loops, shortcuts, or locked/gated routes
- danger gradient
- important landmarks
- visual guidance objects that help the player understand where to go, what is safe, what is blocked, what can be picked up, and what can be interacted with
- enemy families by zone
- prize/object themes by zone
- color palette
- tile/material examples
- prop examples
- object container cards for reusable gameplay objects
- mood notes
- gameplay notes

## Object Container

The object container is a required Step 1 section. It lets the generator create or describe the important map objects separately before Step 2 turns them into transparent sprites and atlas metadata.

In the current workflow, the Step 1 object container is an object inventory and art-direction guide, not a request to place final objects into Step 2B. It should identify what objects exist and where they eventually belong, while Step 2B still builds the map without those objects.

Include one object card or mini-sheet entry for each important object family, such as:

- houses, doors, roofs, awnings, tents, or huts
- trees, trunks, stumps, bushes, canopies, and brambles
- fences, gates, bridges, walls, cliffs, rocks, and barriers
- signs, chests, shrines, vendors, NPC markers, and readable objects
- pickups, prizes, keys, coins, food, powerups, and rare rewards
- landmarks that help the player remember where they are

Each object card should include:

- object id and display name
- gameplay role: blocking, decorative, soft-block, pickup, interactable, gate, transition, landmark, or foreground-only
- expected sprite footprint in tiles
- expected collision footprint in tiles or pixels
- Y-sort base point, usually at the bottom contact point
- foreground/occluder need, such as roof, tree canopy, wall top, cliff lip, or arch
- interaction side and trigger idea, such as door front, sign face, chest front, or gate center
- notes about variants, such as damaged fence, large tree, small tree, locked gate, open gate
- gameplay readability notes: what the player should expect from the object at a glance, and whether it should guide attention toward a path, pickup, exit, landmark, danger boundary, or interaction point
- style notes so Step 2 assets match the map art

The object container can be on the same design page or delivered as a companion image named something like `object_container.png`. It should be clear enough that Step 2B can reserve object slots and Step 2A can later generate each object's sprite, collision, occlusion, interaction, and placement metadata without guessing.

## Technical Readiness Requirements

Before a design page can become a technical tile pack, it must include enough production information for Godot implementation. Add these items to the map page or provide them as a companion overlay sheet:

- scope label declaring whether the page is the full playable map or one map chunk/zone that connects to other chunks
- connection notes for any exits to future zones, including which edge/gate leads to the next map section
- navigation overlay showing the main path, optional paths, loops, chokepoints, gates, shortcuts, dead ends, and locked routes
- map dimensions, tile size, and grid size, such as 4096x4096 px, 64x64 tiles, and a 64x64 tile grid
- intended viewport, such as 1280x720, so camera limits and encounter spacing can be planned
- zone boundaries drawn as practical polygon regions, not only decorative outlines
- collision rules for each object family, such as trees block, buildings block, fences block, shrine props block, rocks block, and stairs/path tiles remain walkable
- path width notes, especially for combat routes; main paths should usually be 4-6 tiles wide so the player and enemies do not get stuck
- object spacing and road clearance notes, including the minimum walkable gap between blockers, props, walls, tree clusters, fences, pickups, and road/path edges
- map boundary language that makes it obvious where the player cannot leave the playable area, using cliffs, fences, water, dense forest, walls, gates, darkness, or other readable blockers instead of invisible walls
- spawn and pickup intent by zone, including safe-zone rules, tutorial enemy zones, prize clusters, rare prize areas, and enemy-free areas
- object readability and guidance intent, including which props should visually communicate blocked edges, safe paths, pickups, exits, landmarks, danger boundaries, and interactable objects
- visual quality targets for Step 2B and Step 2A, including desired terrain density, palette, brush style, acceptable tile repetition, and gameplay-scale readability
- scale references showing collision footprints for player, small enemy, large enemy, pickup, and object footprint; sprite art may be taller than the collision footprint
- separation between blocking props, decorative props, and optional soft-block/destructible props
- a ground-only/background map export with no buildings, trees, fences, gates, cliffs, walls, chests, signs, or other tall gameplay objects baked into it
- an object-composite preview showing the same map with objects placed, used only for art approval and placement reference; this is not Step 2B runtime art
- a clean full-map/reference version without labels, plus labeled overlay versions for zones, navigation, collision, spawns, pickups, and object placement; do not only list these as checkboxes
- an object separation plan that says which visual elements must become independent sprites in Step 2, especially houses, trees, fences, gates, cliffs, signs, shrines, chests, bridges, and landmarks
- an object container with each major object drawn or specified separately, including role, footprint, collision, Y-sort base point, foreground/occlusion needs, and interaction side
- a playable-map aspect ratio that matches the declared dimensions; if the page layout is portrait, the playable map itself should still match the stated world shape
- rough spawn and pickup markers or regions on the actual map, not only text descriptions in the side panel
- chokepoint width notes for each intended narrow gate or passage

Do not approve a Step 1 page for Step 2 if the only beautiful version is a flat painting with houses, trees, fences, gates, and tall objects baked permanently into the background. That can work as concept art, but it will fight Godot's collision, Y-sort, occlusion, interaction, and reuse systems.

Do not hardcode a required zone list. Each design page must declare its own scope and zone set. A page can describe one village, one cave floor, one arena, one dungeon room chain, one forest chunk, one town hub, or a full multi-zone map.

When useful, include an example zone progression for the specific map being designed. Treat examples as placeholders, not requirements:

- Zone A: role, danger level, teaching goal, prizes, and spawn intent
- Zone B: role, danger level, teaching goal, prizes, and spawn intent
- Zone C: role, danger level, teaching goal, prizes, and spawn intent

## Playable Layout Metrics

Step 1 should define enough playable-space metrics that Step 2 does not have to guess whether the map is fun to move through. Treat these as starting metrics that can be adjusted after playtesting, not as universal laws.

Recommended baseline for a 64 px tile top-down RPG:

- player collision footprint: about 0.5-0.75 tile wide, even if the sprite is taller
- small enemy footprint: about 0.5-0.75 tile wide
- large enemy footprint: about 1-1.5 tiles wide
- main road or combat route: usually 4-6 clear tiles wide
- quiet walking path or village lane: usually 3-4 clear tiles wide
- optional side path: usually 2-3 clear tiles wide
- intentional chokepoint, doorway, bridge, or gate: usually 2 clear tiles minimum for player-only movement, 3+ clear tiles if enemies should chase through it
- open combat pocket: usually at least 8x8 clear tiles, larger when multiple enemies can spawn
- pickup clearance: keep at least 1 clear tile around ordinary pickups and 2 clear tiles around important pickups, chests, signs, exits, and tutorial objects
- object-to-road buffer: keep decorative props at least 1 clear tile away from the main route unless they intentionally form a readable border
- blocker-to-blocker gap: do not leave accidental 1-tile cracks between trees, rocks, fences, walls, or buildings unless the crack is deliberately marked as blocked or deliberately designed as a squeeze path
- edge buffer: the outer map boundary should have a continuous readable blocking language; do not rely on an invisible rectangular wall at the edge of a painted scene

Step 1 should mark:

- the centerline or flow arrow of the main route
- the minimum clear width of each major path
- every intended chokepoint width
- any place where enemies can chase the player
- any place where enemies should not enter
- every blocked edge and why it reads as blocked
- any decorative object cluster that must be non-blocking or soft-blocking

Use a simple clearance overlay if possible: green for comfortably walkable, yellow for intentional narrow/chokepoint, red for blocked, blue for exits or transitions. The overlay is for production only; it should not appear in the clean runtime preview.

## Map Structure

Define the map structure from the current creative goal. Do not reuse old map names unless they are actually part of the current map.

Useful structure patterns:

- Single zone/chunk: one playable section with exits to future maps
- Linear multi-zone map: safe start -> tutorial pressure -> first danger -> reward or exit
- Hub map: central safe area with several exits, services, and optional encounters
- Dungeon map: room chain, gates, keys, loops, locked shortcuts, treasure rooms
- Arena map: one or more combat spaces with spawn lanes, hazards, and reward points
- Open exploration map: multiple routes, optional landmarks, variable danger pockets, hidden rewards

## Map Page Prompt Template

Use this prompt when generating or commissioning the Step 1 map design and object container:

```text
Create a polished top-down fantasy survival RPG Step 1 design page for a Godot 2D game.

The game is about a player wandering a large map while monsters try to kill them. The player collects prizes, earns score and XP, and levels Power, Agility, and Intelligence.

Important production constraint:
- Do not create the final 4096x4096 runtime map as one giant image.
- Treat the large map size as the Godot world size.
- Create a design/reference page plus an object container that Step 2 can turn into tiles, sprites, atlases, and metadata.
- Any full-map concept is reference only, not the runtime source of truth.
- This is a production handoff, not loose concept art. Include enough exact visual, layout, object, and metadata guidance that Step 2 can create production-ready assets without inventing or downgrading the design.
- Separate map and objects completely: Step 2B will generate the tileset and map composition without objects, and Step 2A will generate each object separately later.

The page should include:
- one full top-down map concept with a larger-than-screen world
- one gameplay-scale viewport crop showing how route readability, terrain density, and blocked edges should look during play
- clearly labeled zones/chunks using names that belong to this specific map
- player start marker
- intended navigation flow, including whether progression moves upward, outward, clockwise, deeper underground, etc.
- main route, optional branches, chokepoints, and any gates/locks that control progression
- map dimensions and tile plan, for example 4096x4096 px, 64x64 tiles, 64x64 grid, 1280x720 viewport
- zone boundary polygons that can later become Godot Area2D regions
- collision notes for blockers and walkable areas
- path width notes, with main combat paths around 4-6 tiles wide
- playable layout metrics: player footprint, enemy footprint, main route width, side path width, chokepoint width, pickup clearance, object-to-road buffer, and edge-blocking language
- minimum spacing notes between blockers and roads so trees, rocks, fences, houses, signs, pickups, and decorations do not accidentally trap the player or enemies
- readable world edges that clearly show where the player cannot leave the map, using in-world blockers instead of invisible walls
- spawn and pickup intent for each zone, with rough markers or regions on the map
- object readability and guidance notes, so obstacles, pickups, signs, exits, and landmarks clearly communicate what the player should expect and where the player should move next
- scale references for player, small enemy, large enemy, pickup, and blocking object collision footprint
- clear separation of decorative props, blocking props, and optional soft-block/destructible props
- visual map shape that matches the declared dimensions
- scope and connection notes, for example "single-zone chunk; north gate exits to a future map"
- width notes for chokepoints and gates
- danger gradient appropriate to this map's purpose
- visual examples of ground tiles, obstacles, props, prizes, and landmarks that match this map theme
- visual quality targets for Step 2B/Step 2A: terrain density, path style, blocked-edge language, palette, brush/detail style, acceptable repetition at gameplay zoom, and minimum landmark/detail density per screen
- an object container section with separate object cards or mini-sheets for the important reusable objects
- for each object card: object id, role, visible sprite footprint, collision footprint, Y-sort base point, foreground/occluder need, interaction side/trigger, player expectation/readability note, navigation/guidance purpose, and variants
- small enemy-family callouts for each zone
- palette swatches for each zone
- short gameplay notes for what each zone teaches or threatens

Also produce or describe companion exports:
- ground-only/background map with no tall gameplay objects baked in
- object-composite preview with all houses, trees, fences, gates, cliffs, signs, chests, shrines, pickups, and landmarks shown in their intended positions
- object_container.png showing houses, trees, fences, gates, cliffs, rocks, signs, chests, pickups, landmarks, and other gameplay objects separately with ids and footprint notes
- clean full-map/reference image with no labels
- labeled design page
- navigation overlay
- zone polygon overlay
- collision overlay
- clearance overlay showing comfortable walkable space, intentional narrow spaces, blocked space, and exits
- spawn and pickup overlay
- object placement overlay showing each independent object id and approximate footprint

The companion exports should be actual separate images or clearly specified deliverables. A checkbox list saying they are needed is not enough for Step 2.

Acceptance rule:
- If the page cannot support production Step 2A and Step 2B generation without guessing, say `production_ready: false` and list the missing repairs.
- Do not claim approval just because the design is attractive. Approval requires visual quality plus technical separability.
- The ground-only/background export is the source reference for Step 2B. The object-composite preview and object container are references for later one-object-at-a-time Step 2A work.

Use a readable, game-art production sheet layout. Keep the map top-down and practical for tile-based Godot implementation. The concept can be painterly, but the technical follow-up must separate into an object-free tileset/map pack first and one-object-at-a-time sprite/metadata work later. The object container should guide Step 2A object generation instead of forcing any step to crop objects out of a painted map.
```

## Approval Checklist

Before converting the design page into a technical pack, confirm:

- zones are readable
- scope is clear: full map or one map chunk/zone
- exits and connections to adjacent/future zones are labeled
- start area is obvious
- intended player navigation direction is explicit
- main progression route and optional branches are marked separately
- map dimensions, tile size, grid size, and viewport are declared
- playable map aspect ratio matches those dimensions
- zone boundaries can be converted into polygons
- collision rules are stated for blocking and walkable object families
- main combat paths are wide enough for player and enemy movement
- chokepoint widths are marked when gates or narrow passages are intentional
- object-to-object and object-to-road spacing is declared enough to prevent accidental snags, unreachable pickups, and enemy pathing traps
- map edges are visually blocked by readable world objects or terrain, not only invisible collision
- a clearance overlay exists or the equivalent spacing notes are explicit
- spawn and pickup intent is clear for each zone and marked on the map
- scale references make player, enemy, pickup, and object collision footprints readable
- decorative props, blocking props, and soft-block/destructible props are separated
- ground-only background, object-composite preview, clean reference map, and labeled/technical overlay versions are actual deliverables, not only planned checkboxes
- houses, trees, fences, gates, cliffs, walls, signs, chests, shrines, pickups, and landmarks are planned as independent Step 2A assets unless explicitly marked decorative/background-only
- object container cards identify major object ids, roles, footprints, collision rules, Y-sort base points, foreground/occluder needs, and interaction sides
- object cards explain what the player should understand from the object at a glance, such as blocked edge, safe route, pickup, readable landmark, exit, danger boundary, or interaction point
- dangerous areas are visually distinct
- landmarks are memorable
- paths have room for player/enemy movement
- obstacles can become collision shapes
- terrain tiles and later object sprites can be separated into reusable assets