Task.work() should take effort as a float, not ticks as an int #110

New issue

Closed

opened 2026-09-18 13:39:26 +01:00 by liamjd · 0 comments

liamjd commented

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

Owner

Part of milestone #5. Should land before #75, which will otherwise be built on the current signature.

Task.work(ctx: TaskContext, ticks: int) cannot express a pawn contributing anything other than exactly one unit of effort per tick.

Task.work_remaining is already a float, and Pawn already stubs PawnLevel {NEWBIE, SKILLED, EXPERT, LEADER}. A SKILLED builder pushing 1.5 units per tick has nowhere to go through an int parameter, so the float on one side and the int on the other will start disagreeing the moment specialisation is real (#69, #74).

Two ways to fix it:

work(ctx, effort: float) — the caller (the #75 work loop) computes 1.0 * pawn.level_multiplier and hands over the result. The task stays ignorant of how pawn skill works.
Keep ticks: int and have the task look the pawn up through ctx — requires adding pawns to TaskContext, and puts skill rules inside every task type that ever counts effort.

Prefer (1): it matches why work_remaining is a float, keeps TaskContext small, and keeps the skill rules in one place rather than one per task subclass.

Note the unit does not change — effort is still denominated in pawn-ticks, per #88. What changes is that a tick of a pawn's time is no longer required to be worth exactly one of them.

AC:

Task.work() and every override take effort: float rather than ticks: int
ConstructionTask.work() subtracts the effort given, still clamped at zero
StubTask and the existing task tests updated
The parameter is documented as pawn-ticks of effort, not elapsed ticks, since the two stop being the same number

Part of milestone #5. Should land **before #75**, which will otherwise be built on the current signature. `Task.work(ctx: TaskContext, ticks: int)` cannot express a pawn contributing anything other than exactly one unit of effort per tick. `Task.work_remaining` is already a `float`, and `Pawn` already stubs `PawnLevel {NEWBIE, SKILLED, EXPERT, LEADER}`. A SKILLED builder pushing 1.5 units per tick has nowhere to go through an `int` parameter, so the float on one side and the int on the other will start disagreeing the moment specialisation is real (#69, #74). Two ways to fix it: 1. **`work(ctx, effort: float)`** — the caller (the #75 work loop) computes `1.0 * pawn.level_multiplier` and hands over the result. The task stays ignorant of how pawn skill works. 2. Keep `ticks: int` and have the task look the pawn up through `ctx` — requires adding `pawns` to `TaskContext`, and puts skill rules inside every task type that ever counts effort. Prefer (1): it matches why `work_remaining` is a float, keeps `TaskContext` small, and keeps the skill rules in one place rather than one per task subclass. Note the unit does not change — effort is still denominated in pawn-ticks, per #88. What changes is that a tick of a pawn's time is no longer required to be worth exactly one of them. AC: - `Task.work()` and every override take `effort: float` rather than `ticks: int` - `ConstructionTask.work()` subtracts the effort given, still clamped at zero - `StubTask` and the existing task tests updated - The parameter is documented as pawn-ticks of effort, not elapsed ticks, since the two stop being the same number

liamjd added this to the Task management for pawns milestone

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

liamjd referenced this issue

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

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

liamjd referenced this issue from a commit

2026-09-18 18:02:18 +01:00

Spec effort as a float, not ticks as an int (#110)

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

2026-09-18 18:30:40 +01:00

Task.work() takes effort as a float, with the guard on the base class #115

liamjd closed this issue