Implement reputation decay system — configurable rate toward neutral per game day, stops at ±5 #217
Labels
No labels
Blocked
Duplicate
MoSCoW/Could Have
MoSCoW/Must Have
MoSCoW/Should Have
Points/1
Points/13
Points/2
Points/21
Points/3
Points/5
Points/8
Priority/Backlog
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
State/Completed
State/In progress
State/In review
State/Paused
State/Unverified
State/Verified
State/Wont Do
Type/Bug
Type/Epic
Type/Feature
Type/Legendary
Type/Task
Type/Testing
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#202 Epic: Reputation Mechanics
aethyr/Aethyr
Reference: aethyr/Aethyr#217
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Metadata
feature/m4-reputation-decay-systemImplement reputation decay system — configurable rate toward neutral per game day, stops at ±5 (#217)Background and Context
In a dynamic MUD world, reputation should not be permanent from a single action. The decay system ensures that reputation scores gradually drift toward neutral over time, encouraging players to maintain their standing through ongoing engagement rather than resting on past achievements or suffering permanently from past mistakes.
The decay system runs on each game-day tick. Every reputation score that is outside the ±5 "near-neutral" range decays by a configurable amount (default: 1 point per game day) toward 0. Once a score enters the ±5 range, decay stops — this prevents scores from oscillating around zero and provides a stable neutral zone.
The decay rate is configurable in
config.yamlto allow server operators to tune the system. A higher decay rate creates a more dynamic reputation environment, while a lower rate rewards long-term commitment.Expected Behavior
config.yamlunderreputation.decay_rate.:reputation_changedevents but tagged assource: :decay.reputation.decay_enabled: falseinconfig.yaml.Acceptance Criteria
config.yamlatreputation.decay_rate.reputation.decay_enabled: false.:reputation_changedevents tagged withsource: :decay.Subtasks
lib/aethyr/core/reputation/reputation_decay.rbwith the decay engine.reputation.decay_rateandreputation.decay_enabledconfig options.source: :decay.tests/unit/reputation_decay.featurecovering positive decay, negative decay, neutral zone exemption, configurable rate, disable toggle, event tagging, and no-propagation guard.tests/integration/for decay system running across multiple game-day ticks with various reputation scores.bundle exec rake unit_profileand verify no performance regressions.bundle exec rake unit. If coverage is <97% then review the current unit test coverage report atbuild/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 rerunbundle exec rake unitto 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%.bundle exec rake(default task: unit tests with coverage) andbundle 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:
master, reviewed, and merged before this issue is marked done.