Implement devotee-delegated harvesting #241

Open
opened 2026-03-16 01:41:40 +00:00 by freemo · 0 comments
Owner

Metadata

Field Value
Parent Epic Epic: Harvesting System (#209)
Legendary Crafting & Resource Economy (#200)
Type Feature
Priority High
MoSCoW Should Have
Points 5
Branch feature/m4-devotee-delegated-harvesting
Commit Message Implement devotee-delegated harvesting (#241)

Background and Context

Devotees are NPC followers that players can command to perform tasks on their behalf. Devotee-delegated harvesting allows players to assign a devotee to continuously gather resources from a specific harvest node in the background. This provides a passive income of resources but at reduced quality.

Key design constraints:

  • Lower quality multiplier: Devotees harvest at 0.6x quality compared to personal harvesting, reflecting their lack of the player's skill and finesse.
  • No XP: The player does not gain any harvesting XP from devotee-gathered resources, incentivizing personal harvesting for skill advancement.
  • Auto-deposit: Harvested resources are automatically deposited into the player's personal storage chest, rather than the devotee's inventory.
  • Continuous background gathering: Devotees continue harvesting on a timer cycle as long as the node is not depleted and the devotee is not recalled.

Expected Behavior

When a player issues a command to assign a devotee to harvest (e.g., order <devotee> harvest <node>):

  1. The devotee is assigned to the target HarvestNode.
  2. The devotee begins a harvesting cycle on a configurable timer (e.g., every 30 seconds).
  3. Each cycle, the devotee attempts to harvest the node:
    • No skill check is performed (devotees always succeed if the node is available).
    • Quality is calculated as: base_quality * 0.6 (the 0.6x multiplier).
    • The harvested resource is deposited directly into the player's personal storage chest.
    • Node depletion is tracked normally.
  4. The player receives no XP from devotee harvesting.
  5. If the node is depleted, the devotee waits for it to respawn before resuming.
  6. The player can recall the devotee at any time with order <devotee> return.
  7. A status command (e.g., order <devotee> status) shows what the devotee is currently harvesting and how many resources have been gathered.

Acceptance Criteria

  • Players can assign a devotee to harvest a specific HarvestNode via a command.
  • Devotees harvest continuously on a configurable timer cycle.
  • Devotee-harvested resources have their quality multiplied by 0.6x.
  • The player receives no XP from devotee-delegated harvesting.
  • Harvested resources are automatically deposited into the player's personal storage chest.
  • Devotees respect node depletion and wait for respawn.
  • Players can recall a devotee from harvesting duty.
  • A status command shows the devotee's current harvesting assignment and resource count.

Subtasks

  • Implement the order <devotee> harvest <node> command to assign devotees to harvest nodes.
  • Implement the background harvesting timer cycle for devotees.
  • Implement the 0.6x quality multiplier for devotee harvesting.
  • Ensure no XP is granted to the player from devotee harvesting.
  • Implement auto-deposit of harvested resources to the player's personal storage chest.
  • Implement devotee behavior when a node is depleted (wait and resume).
  • Implement the order <devotee> return command to recall devotees.
  • Implement the order <devotee> status command to show harvesting status.
  • Docs: Update YARD comments on affected classes and methods. Update relevant Docusaurus documentation pages if applicable.
  • Tests (Cucumber): Add tests/unit/devotee_harvesting.feature covering assignment, quality multiplier, no XP, auto-deposit, depletion waiting, recall.
  • Tests (Cucumber Integration): Add integration feature in tests/integration/ for devotee-delegated harvesting end-to-end flow.
  • Tests (Profiling): Run bundle exec rake unit_profile and verify no performance regressions.
  • Quality: Verify coverage >=97% via bundle exec rake unit. If coverage is <97% then review the current unit test coverage report at build/tests/unit/coverage/ and use it to write new Cucumber based unit tests to improve code coverage. Specifically, write Cucumber/Gherkin style unit tests that are descriptively named and specifically improve coverage on whichever file has the most uncovered lines by writing tests that will target the uncovered lines in the report. Once that is done rerun bundle exec rake unit to verify all tests pass and coverage is above >=97%. Only mark this as complete once coverage is >=97%, if not repeat this task as many times as is needed until coverage reaches >=97%.
  • Quality: Run bundle exec rake (default task: unit tests with coverage) and bundle exec rake integration, fix any errors if needed ensuring both pass across entire code base, do not ignore any failure even if it seems unrelated to this commit, fix it.

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
  • The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.
## Metadata | Field | Value | |---|---| | **Parent Epic** | Epic: Harvesting System (#209) | | **Legendary** | Crafting & Resource Economy (#200) | | **Type** | Feature | | **Priority** | High | | **MoSCoW** | Should Have | | **Points** | 5 | | **Branch** | `feature/m4-devotee-delegated-harvesting` | | **Commit Message** | `Implement devotee-delegated harvesting (#241)` | ## Background and Context Devotees are NPC followers that players can command to perform tasks on their behalf. Devotee-delegated harvesting allows players to assign a devotee to continuously gather resources from a specific harvest node in the background. This provides a passive income of resources but at reduced quality. Key design constraints: - **Lower quality multiplier**: Devotees harvest at 0.6x quality compared to personal harvesting, reflecting their lack of the player's skill and finesse. - **No XP**: The player does not gain any harvesting XP from devotee-gathered resources, incentivizing personal harvesting for skill advancement. - **Auto-deposit**: Harvested resources are automatically deposited into the player's personal storage chest, rather than the devotee's inventory. - **Continuous background gathering**: Devotees continue harvesting on a timer cycle as long as the node is not depleted and the devotee is not recalled. ## Expected Behavior When a player issues a command to assign a devotee to harvest (e.g., `order <devotee> harvest <node>`): 1. The devotee is assigned to the target `HarvestNode`. 2. The devotee begins a harvesting cycle on a configurable timer (e.g., every 30 seconds). 3. Each cycle, the devotee attempts to harvest the node: - No skill check is performed (devotees always succeed if the node is available). - Quality is calculated as: `base_quality * 0.6` (the 0.6x multiplier). - The harvested resource is deposited directly into the player's personal storage chest. - Node depletion is tracked normally. 4. The player receives no XP from devotee harvesting. 5. If the node is depleted, the devotee waits for it to respawn before resuming. 6. The player can recall the devotee at any time with `order <devotee> return`. 7. A status command (e.g., `order <devotee> status`) shows what the devotee is currently harvesting and how many resources have been gathered. ## Acceptance Criteria - [ ] Players can assign a devotee to harvest a specific `HarvestNode` via a command. - [ ] Devotees harvest continuously on a configurable timer cycle. - [ ] Devotee-harvested resources have their quality multiplied by 0.6x. - [ ] The player receives no XP from devotee-delegated harvesting. - [ ] Harvested resources are automatically deposited into the player's personal storage chest. - [ ] Devotees respect node depletion and wait for respawn. - [ ] Players can recall a devotee from harvesting duty. - [ ] A status command shows the devotee's current harvesting assignment and resource count. ## Subtasks - [ ] Implement the `order <devotee> harvest <node>` command to assign devotees to harvest nodes. - [ ] Implement the background harvesting timer cycle for devotees. - [ ] Implement the 0.6x quality multiplier for devotee harvesting. - [ ] Ensure no XP is granted to the player from devotee harvesting. - [ ] Implement auto-deposit of harvested resources to the player's personal storage chest. - [ ] Implement devotee behavior when a node is depleted (wait and resume). - [ ] Implement the `order <devotee> return` command to recall devotees. - [ ] Implement the `order <devotee> status` command to show harvesting status. - [ ] Docs: Update YARD comments on affected classes and methods. Update relevant Docusaurus documentation pages if applicable. - [ ] Tests (Cucumber): Add `tests/unit/devotee_harvesting.feature` covering assignment, quality multiplier, no XP, auto-deposit, depletion waiting, recall. - [ ] Tests (Cucumber Integration): Add integration feature in `tests/integration/` for devotee-delegated harvesting end-to-end flow. - [ ] Tests (Profiling): Run `bundle exec rake unit_profile` and verify no performance regressions. - [ ] Quality: Verify coverage >=97% via `bundle exec rake unit`. If coverage is <97% then review the current unit test coverage report at `build/tests/unit/coverage/` and use it to write new Cucumber based unit tests to improve code coverage. Specifically, write Cucumber/Gherkin style unit tests that are descriptively named and specifically improve coverage on whichever file has the most uncovered lines by writing tests that will target the uncovered lines in the report. Once that is done rerun `bundle exec rake unit` to verify all tests pass and coverage is above >=97%. Only mark this as complete once coverage is >=97%, if not repeat this task as many times as is needed until coverage reaches >=97%. - [ ] Quality: Run `bundle exec rake` (default task: unit tests with coverage) and `bundle exec rake integration`, fix any errors if needed ensuring both pass across **entire** code base, do not ignore any failure even if it seems unrelated to this commit, fix it. ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done.
freemo added this to the v1.3.0 milestone 2026-03-16 01:41:40 +00:00
freemo self-assigned this 2026-03-16 01:41:41 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
Reference: aethyr/Aethyr#241
No description provided.