liamjd/UntitledColonyBuilder

Fork 0

Task.assignee is single-valued, but build_days promises multi-pawn construction #111

New issue

Closed

opened 2026-09-18 13:39:49 +01:00 by liamjd · 2 comments

liamjd commented

2026-09-18 13:39:49 +01:00

Owner

Part of milestone #5. The data model and the documentation currently contradict each other.

BuildingType.build_days documents pawn-days with a worked example:

a 10 pawn-day mine takes 10 days with one pawn and 3.3 with three

But Task.assignee is a single int, and TaskManager.claim(id, pawn_id) overwrites it. One task can only ever be worked by one pawn, so the three-pawn case in that docstring is unreachable — a second pawn claiming the task would silently displace the first.

The pawn-day unit itself is fine and worth keeping: it falls straight out of a work loop where each assigned pawn contributes one unit per tick (see #110). The question is only whether a task can hold more than one assignee.

Options:

assignees: Array[int] with claim() appending and release(id, pawn_id) removing one. next_for() needs a cap so a task is not claimable without limit — probably a max_workers on the task, defaulting to 1.
Defer multi-pawn work. Keep one assignee, and correct BuildingType's docstring so it stops promising something the model cannot do. Revisit when there is a reason for two pawns to share a site.

(2) is the smaller change and is probably right for now — with ~10 pawns in a colony, parallel construction is a nice-to-have rather than a core loop. But the docstring must not keep claiming otherwise.

Whichever way it goes, #75's work loop needs to know, because "the pawns working this task" is a lookup it performs every tick.

AC:

A decision recorded here and in the PR
If deferring: BuildingType.build_days docstring corrected, and a note on Task.assignee saying single-assignee is deliberate
If not: claim/release/next_for updated with tests for two pawns on one task, and one pawn not displacing another

Part of milestone #5. The data model and the documentation currently contradict each other. `BuildingType.build_days` documents pawn-days with a worked example: > a 10 pawn-day mine takes 10 days with one pawn and 3.3 with three But `Task.assignee` is a single `int`, and `TaskManager.claim(id, pawn_id)` overwrites it. One task can only ever be worked by one pawn, so the three-pawn case in that docstring is unreachable — a second pawn claiming the task would silently displace the first. The pawn-day unit itself is fine and worth keeping: it falls straight out of a work loop where each assigned pawn contributes one unit per tick (see #110). The question is only whether a task can hold more than one assignee. Options: 1. **`assignees: Array[int]`** with `claim()` appending and `release(id, pawn_id)` removing one. `next_for()` needs a cap so a task is not claimable without limit — probably a `max_workers` on the task, defaulting to 1. 2. **Defer multi-pawn work.** Keep one assignee, and correct `BuildingType`'s docstring so it stops promising something the model cannot do. Revisit when there is a reason for two pawns to share a site. (2) is the smaller change and is probably right for now — with ~10 pawns in a colony, parallel construction is a nice-to-have rather than a core loop. But the docstring must not keep claiming otherwise. Whichever way it goes, #75's work loop needs to know, because "the pawns working this task" is a lookup it performs every tick. AC: - A decision recorded here and in the PR - If deferring: `BuildingType.build_days` docstring corrected, and a note on `Task.assignee` saying single-assignee is deliberate - If not: `claim`/`release`/`next_for` updated with tests for two pawns on one task, and one pawn not displacing another

liamjd added this to the Task management for pawns milestone

2026-09-18 13:39:49 +01:00

liamjd referenced this issue

2026-09-19 08:13:33 +01:00

Pawn needs to know which task it is walking to #112

liamjd referenced this issue

2026-09-19 09:42:11 +01:00

Pawn knows which task it is walking to #116

liamjd referenced this issue

2026-09-19 09:59:04 +01:00

Multi-pawn work slots, opted into per site #117

liamjd commented

2026-09-19 09:59:15 +01:00

Author

Owner

Decision: option 2, defer. Single assignee stays for now.

Multi-pawn work is wanted, and the design is settled enough to write down, but it is not what #75 needs to get a pawn onto a building site. Filed as #117: each task type caps the workers it allows (construction 3, hauling 1), a new task opens one slot, and the player opens the rest deliberately by selecting the site. That last part is the reason it cannot land now — it needs #78's selection to hang the UI off, and #75's work loop has to exist before there is anything to parallelise.

So for #75 the lookup is unambiguous: one task, at most one assignee, claim() overwrites.

Remaining AC here, both documentation:

BuildingType.build_days — the worked example promises "3.3 days with three pawns", which the model cannot do. Reword to state the pawn-day unit and that elapsed time equals the authored figure while a task takes one worker, pointing at #117 for the rest.
Task.assignee — note that single-assignee is a deliberate deferral, not an oversight, and link #117.

**Decision: option 2, defer.** Single assignee stays for now. Multi-pawn work is wanted, and the design is settled enough to write down, but it is not what #75 needs to get a pawn onto a building site. Filed as #117: each task *type* caps the workers it allows (construction 3, hauling 1), a new task opens one slot, and the player opens the rest deliberately by selecting the site. That last part is the reason it cannot land now — it needs #78's selection to hang the UI off, and #75's work loop has to exist before there is anything to parallelise. So for #75 the lookup is unambiguous: one task, at most one assignee, `claim()` overwrites. Remaining AC here, both documentation: - `BuildingType.build_days` — the worked example promises "3.3 days with three pawns", which the model cannot do. Reword to state the pawn-day unit and that elapsed time equals the authored figure while a task takes one worker, pointing at #117 for the rest. - `Task.assignee` — note that single-assignee is a deliberate deferral, not an oversight, and link #117.

liamjd referenced this issue

2026-09-19 14:02:41 +01:00

Pawn work loop: claim, navigate, work, complete #120

liamjd referenced this issue

2026-09-28 06:06:09 +01:00

Multi-pawn work slots, opted into per site #117

liamjd commented

2026-09-28 06:06:17 +01:00

Author

Owner

#117's spec (2026-09-28) takes multi-pawn work on now, which makes build_days' "3.3 days with three pawns" true once the player opens three slots. #117's PR updates that docstring to say so, and will close this issue.

#117's spec (2026-09-28) takes multi-pawn work on now, which makes `build_days`' "3.3 days with three pawns" true once the player opens three slots. #117's PR updates that docstring to say so, and will close this issue.

liamjd referenced this issue from a commit

2026-09-29 18:56:15 +01:00

Let several pawns work one task, opted into per site (#117)

liamjd referenced this issue from a pull request that will close it,

2026-09-29 18:56:30 +01:00

Multi-pawn work slots, opted into per site (#117) #137

liamjd closed this issue

2026-09-29 19:19:48 +01:00