#crew-movement

Second milestone of the ftl-shape vertical slice. Adds interactive crew: click a crew member, click a destination tile, watch them walk. Built on top of the skeleton milestone's tile grid and ship layout.

#Design

Purpose. Introduce interactive crew: 3 crew members sit on walkable tiles; player clicks a crew to select, clicks a destination tile to issue a move order; crew walks tile-by-tile along a shortest path. Foundation for combat-milestone features that require crew to be "at" a specific system.

In scope. Walkable-tile model derived from existing ship rooms; 3 named placeholder crew with distinct tints; click-to-select / click-to-move input; BFS pathfinding on the walkable tile graph; tile-by-tile movement animation; selection feedback (1-px ring around selected crew).

Out of scope. Doors / walls, crew skills, crew health, hover-tile preview, multi-select, queued orders, damage, enemy ship, combat, pause.

Chosen approach.

• Walkability. New file tiles.go: func walkableTiles(s Ship) map[[2]int]bool — union of every room's interior tiles, keyed by [x, y]. Computed once at ship construction, cached on Game. Naturally connected because rooms share tile edges in the skeleton layout.
• Crew model. New file crew.go:
  • type Crew struct { ID int; Name string; Initial rune; Color color.RGBA; TileX, TileY int; Path [][2]int; MoveT float64 } — tile position is canonical; Path is the remaining waypoints (empty = idle); MoveT is progress in [0,1) toward the next waypoint.
  • func NewStartingCrew() []Crew — Alice in Pilot, Bob in Shields, Carol in Engines.
• Pathfinding. func bfsPath(walk map[[2]int]bool, from, to [2]int) [][2]int — standard 4-neighbour BFS over the walkable set; returns waypoints excluding from and including to. Empty path means unreachable or same-tile.
• Input. Game.Update reads the mouse: left-click → convert window pixels to virtual pixels (using ebiten.WindowSize + the known Layout scale) → tile coords. If the click lands on a crew member, select that crew (store its index in selectedCrew). Otherwise, if a crew is selected and the click tile is walkable, replace that crew's Path with a fresh BFS result and reset MoveT.
• Movement tick. func updateCrew(c *Crew, dt float64) — if Path non-empty, advance MoveT += dt / tileTime (default tileTime = 0.35s). When MoveT >= 1, snap TileX, TileY to the next waypoint, pop it, reset MoveT. Rendered position is linearly interpolated between the current tile and the next waypoint.
• Rendering. drawCrew(screen *ebiten.Image, c Crew, selected bool) added to render.go. Crew is a 12 px colored circle centred on the interpolated position, plus the initial letter via ebitenutil.DebugPrintAt. Selected crew gets a 1-px white outer ring.
• Game struct growth. Game gains walk map[[2]int]bool, crew []Crew, selectedCrew int (−1 if none), lastTime time.Time. Update computes dt from wall-clock delta.
• Tile occupancy. No enforcement this milestone — two crew may overlap visually. A short comment flags the spot where a "reserve next tile" check belongs later.

Tradeoffs that settled the decisions.

• Tile-position-as-canonical (vs pixel-position + tile-on-arrival): cleaner gameplay queries ("is crew in Weapons?"), simpler save-state later; cost is one interpolation step in the renderer.
• map[[2]int]bool (vs [][]bool grid): tiny ship, map lookup is fast enough, keeps the code resolution-independent. Memory overhead is irrelevant at ~30 tiles.
• Per-crew path ownership (vs central path manager): each crew is independent at this scope; no coordination needed.

Unknowns. Mouse-pixel → virtual-pixel conversion relies on ebiten.WindowSize reporting the current window size (including after resize). Ebitengine's documented behaviour confirms this.

TDD: yes — bfsPath, walkableTiles, and the updateCrew tick are pure functions with clear inputs/outputs and meaningful branching (same-tile, unreachable, multi-room path, boundary-crossing path, tile snap on MoveT >= 1). Input handling and rendering stay manual — they need the real mouse and display.

#Invariants

• ship.go, tiles.go, and crew.go must not import Ebitengine. Pathfinding and walkability are pure.
• All drawing uses virtual-resolution coordinates (640×360). Mouse input is converted once at the boundary; crew positions are stored in tile units only.
• Crew canonical position is (TileX, TileY) — a tile coordinate. Render-time interpolation is never written back to TileX / TileY.
• bfsPath is deterministic: same walkable set + same from / to → same path, via a stable neighbour ordering.
• Single codebase builds unchanged for GOOS=js GOARCH=wasm and native targets. Mouse input works in the browser via the same API.

#Principles

• YAGNI: no doors, walls, queued orders, hover preview, or cancel animation. If the combat milestone needs it, it ships there.
• Tests cover pure functions (path, walkability, tick); rendering and input stay manual.
• Fail fast: unreachable paths return empty, not "closest-so-far". Clicking outside the ship is a no-op, not a teleport.
• Separate data from rendering and input — crew.go has no ebiten. imports; render.go never mutates crew state.
• Deterministic core: same input sequence and timestep → identical game state.