Building footprints need an entrance #55

New issue

Closed

opened 2026-08-30 19:43:17 +01:00 by liamjd · 0 comments

liamjd commented

2026-08-30 19:43:17 +01:00

Owner

Buildings need an entrance, defined in the footprint. The entrance must be adjacent to/pointing at a single cell in the footprint. There must only be one entrance to a building.

As an arrow on the shape string:

@x
x<
x.

xx@xx
xx^xx

>xx
.x@

Positives: easy to read in the shape string; easy to parse when building the cells array. Negatives: requires more spacing .s.

Arrows are the ASCII < > ^ v (case-insensitive, so V works too). Draw the shape with the arrow in mind; rotation handles the rest.

Once the shape has been parsed, the entrance is not part of the cell array, but is stored privately on BuildingFootprint:

doorstep(steps) - the arrow's cell, anchor-relative, rotated by steps. It is the tile a pawn stands on to enter, and is never in cells().
entrance_direction(steps) - the unit vector the arrow points in, rotated by steps.
doorstep(s) + entrance_direction(s) is always a cell in rotated(s).

Decisions

The entrance is mandatory. A shape with no arrow is rejected, the same way as a shape with no @. All authored footprint .tres files carry one.
Direction is stored as a Vector2i, not an N/E/S/W integer, and rotates through the same rotate_offset() as the cells, so there is one rotation implementation rather than two that must agree.
Rejected at parse time, with a single push_error and cells() left empty: no arrow, more than one arrow, arrow pointing at an empty tile, arrow pointing off the grid.
Rows are padded at the end only, so an arrow at the start of a row must be matched with a . on every other row or the shape skews. Prefer replacing an existing . or appending to a row.

Rendering

Split out to #61.

Buildings need an entrance, defined in the footprint. The entrance must be adjacent to/pointing at a single cell in the footprint. There must only be one entrance to a building. ### As an arrow on the shape string: ``` @x x< x. ``` or ``` xx@xx xx^xx ``` or ``` >xx .x@ ``` Positives: easy to read in the shape string; easy to parse when building the cells array. Negatives: requires more spacing `.`s. Arrows are the ASCII `< > ^ v` (case-insensitive, so `V` works too). Draw the shape with the arrow in mind; rotation handles the rest. Once the shape has been parsed, the entrance is not part of the cell array, but is stored privately on `BuildingFootprint`: - `doorstep(steps)` - the arrow's cell, anchor-relative, rotated by `steps`. It is the tile a pawn stands on to enter, and is never in `cells()`. - `entrance_direction(steps)` - the unit vector the arrow points in, rotated by `steps`. - `doorstep(s) + entrance_direction(s)` is always a cell in `rotated(s)`. ### Decisions - **The entrance is mandatory.** A shape with no arrow is rejected, the same way as a shape with no `@`. All authored footprint `.tres` files carry one. - **Direction is stored as a `Vector2i`, not an N/E/S/W integer**, and rotates through the same `rotate_offset()` as the cells, so there is one rotation implementation rather than two that must agree. - **Rejected at parse time**, with a single `push_error` and `cells()` left empty: no arrow, more than one arrow, arrow pointing at an empty tile, arrow pointing off the grid. - Rows are padded at the end only, so an arrow at the *start* of a row must be matched with a `.` on every other row or the shape skews. Prefer replacing an existing `.` or appending to a row. ### Rendering Split out to #61.

liamjd added the

enhancement

label

2026-08-30 19:43:23 +01:00

liamjd added this to the Building placement milestone

2026-08-30 19:43:26 +01:00

liamjd added this to the Untitled Colony Builder project

2026-08-30 19:43:28 +01:00

liamjd referenced this issue

2026-08-31 09:52:49 +01:00

Placed buildings must block pathfinding #56

liamjd referenced this issue