Choosing Terrain vs Objects

Grid Placement supports two main 2D placement surfaces:

• Terrain painting into TileMapLayer cells.
• Scene object placement for instantiating PackedScene nodes.

Use this guide when you are deciding whether something in your game should be a tile or a placed object.

Version note: This guide is for Grid Placement 6.0.0. The beginner path is 2D TileMapLayer placement.

For the release-facing support boundary, shipped demo list, brush commit semantics, and terrain brush cell cap, see 6.0 Surface and Brush Reference.

The Decision Rule

Terrain Tiles

Terrain tiles are anonymous paint in a TileMapLayer.

Use terrain for content where neighboring cells matter more than per-piece identity:

• roads
• floors
• hedges
• fences
• walls
• connected ground areas

Terrain tiles are excellent for visuals and static collision, but they do not become separate scene instances. A painted cell has no script, no _process(), no per-instance node identity, and no object-level Manipulatable component.

Scene Objects

Scene objects are real nodes instantiated into the scene tree.

Use scene objects when the placed thing needs:

• a script
• individual state
• selection
• movement
• rotation or flipping
• object-level removal
• per-instance save/load data
• the full object placement rules pipeline

Buildings, lamps, crates, NPCs, and interactable props usually belong here.

The Fence Middle Ground

Fences are the classic confusing case.

If the fence is mostly visual/static, make it terrain. Paint fence/wall tiles into a TileMapLayer and let your TileSet handle the connected appearance.

If the fence also needs gameplay interaction, use a hybrid pattern:

TileMapLayer (Fence visuals + static collision)
Interaction overlay or per-cell dictionary (game-owned behavior)

The plugin owns terrain placement. Your game owns extra behavior such as opening a gate, tracking durability, showing state-specific visuals, or handling click selection.

Hybrid Pattern Example

For many collision-based interactions, no overlay is required. The TileMapLayer already participates in physics.

A game-side interaction can:

1. Detect the TileMapLayer.
2. Convert the world position to a cell with tile_map.local_to_map(position).
3. Query the tile with tile_map.get_cell_source_id(cell) or terrain data.
4. Track per-cell gameplay state in a game-owned dictionary.
5. Erase or replace the tile when your game decides the cell should change.

Use an overlay only when you need per-cell click events, per-segment visual effects, or scripts that run every frame.

Terrain hooks make this easier:

• pre_terrain_paint — inspect or veto a planned paint before it commits.
• post_terrain_paint — react after paint lands.
• pre_terrain_demolish — veto terrain removal.
• post_terrain_demolish / post_terrain_removed — react after removal.

Terrain Rules vs Object Rules

Objects use the object placement rules pipeline because each object is an instance the validator can reason about.

Terrain uses terrain validation, paint gates, and terrain hooks instead. This is intentional:

• A tile cell has no scene instance.
• There is no Manipulatable target for an object rule to inspect.
• Many object rules assume an object footprint, collision body, cost rule, or instance identity.

For game-specific terrain checks, connect to pre_terrain_paint or pre_terrain_demolish and veto the operation when needed.

Examples:

• Block painting while a game mode is locked.
• Require a resource or stamina cost to paint terrain.
• Reject terrain in protected zones.
• Prevent terrain removal under a placed interactable.
• Spawn or update overlays after terrain changes.

Brush Shape Rule

Brush shapes are split by whether the shape makes sense for anonymous terrain cells or for separate scene objects.

Object LINE placement is opt-in per category/profile so ordinary objects remain single-placement by default.

For exact press/drag/release and flood-fill second-confirm semantics, see 6.0 Surface and Brush Reference.

Grid Type Compatibility

Comparison Table

Practical Guidance

Use terrain tiles when

• The thing forms connected lines or areas.
• The thing's appearance depends on neighbors.
• You do not need per-piece object identity.
• You want maximum performance.
• Static collision is enough.

Use scene objects when

• Each instance needs scripts, signals, or properties.
• The player can select, move, rotate, flip, or remove the individual piece.
• The thing is a standalone entity.
• You need the object placement rule pipeline.

Use the hybrid pattern when

• The thing visually connects to neighbors and needs some per-piece interaction.
• Paint terrain for connected visuals + static collision.
• Add a game-owned overlay node or per-cell state only for the gameplay part.

Related Guides

• Placement Workflow — end-to-end object and terrain placement flow.
• 6.0 Surface and Brush Reference — support boundary, brush matrix, and terrain brush cell cap.
• Placement Rules — object validation rules.
• Refund on Demolish — object refunding.
• Architecture Overview — how the core runtime fits together.