Implement gameplay effects — merchant price multipliers, area access restrictions, quest availability based on reputation tier #218

New issue

Open

opened 2026-03-16 01:38:23 +00:00 by freemo · 0 comments

freemo commented

2026-03-16 01:38:23 +00:00

Owner

Metadata

Field	Value
Epic	#202 — Reputation Mechanics
Legendary	#199 — Reputation & Social Standing
Type	Feature
Priority	High
Points	8
MoSCoW	Must Have
Branch	`feature/m4-reputation-gameplay-effects`
Commit Message	`Implement gameplay effects — merchant price multipliers, area access restrictions, quest availability based on reputation tier (#218)`

Background and Context

Reputation is only meaningful if it has tangible effects on gameplay. This issue implements three core gameplay systems that respond to a player's reputation tier with various entities:

Merchant price multipliers: Merchants adjust their prices based on the player's reputation with their faction or settlement. Exalted players get significant discounts, while Reviled players face massive markups — or may be refused service entirely.
Area access restrictions: Certain areas (faction headquarters, inner cities, sacred grounds) require a minimum reputation tier to enter. Players below the threshold are turned away at the door.
Quest availability: NPCs only offer certain quests to players who have achieved a minimum reputation tier. This gates content behind reputation progression and rewards players who invest in building relationships.

All thresholds and multipliers are configurable per entity, allowing world builders to create nuanced reputation-gated content.

Expected Behavior

Merchant prices: Each merchant has a faction attribute. When a player buys/sells, the price is multiplied by a factor based on their tier with that faction:
- Reviled: 3.0x buy / 0.3x sell (or refused entirely)
- Hated: 2.5x buy / 0.4x sell
- Hostile: 2.0x buy / 0.5x sell
- Unfriendly: 1.5x buy / 0.7x sell
- Neutral: 1.0x buy / 1.0x sell
- Friendly: 0.9x buy / 1.1x sell
- Respected: 0.8x buy / 1.2x sell
- Honored: 0.7x buy / 1.3x sell
- Exalted: 0.5x buy / 1.5x sell
Area access: Rooms/areas can have a min_reputation attribute specifying {entity_id: tier}. Players below the tier see a rejection message and cannot enter.
Quest availability: Quest givers check player reputation tier before offering quests. Quests have a required_reputation attribute specifying {entity_id: tier}.
All multipliers and thresholds are overridable per entity in configuration.

Acceptance Criteria

Merchant price calculation correctly applies tier-based multipliers for both buying and selling.
Merchants can refuse service to Reviled players.
Area access checks reputation tier before allowing entry.
Players receive a clear message when denied area access due to reputation.
Quest givers check reputation before offering quests.
Players receive a clear message when reputation is too low for a quest.
All multipliers and thresholds are configurable per entity.
Default multiplier table matches the specification above.
Effects update dynamically as reputation changes.

Subtasks

Create lib/aethyr/core/reputation/reputation_effects.rb with the effects engine.
Implement merchant price multiplier system with tier-based lookup table.
Implement buy/sell multiplier application in merchant transaction flow.
Implement service refusal for Reviled tier.
Implement area access restriction checking on room entry.
Implement rejection message for insufficient reputation on area entry.
Implement quest availability check on quest offer.
Implement rejection message for insufficient reputation on quest offer.
Add per-entity override configuration support.
Integrate effects with existing merchant, room, and quest systems.
Docs: Update YARD comments on affected classes and methods. Update relevant Docusaurus documentation pages if applicable.
Tests (Cucumber): Add tests/unit/reputation_effects.feature covering all price multiplier tiers, area access checks, quest availability checks, service refusal, rejection messages, and per-entity overrides.
Tests (Cucumber Integration): Add integration feature in tests/integration/ for end-to-end gameplay effects with merchant transactions, room entry, and quest interactions.
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 | |-------|-------| | **Epic** | #202 — Reputation Mechanics | | **Legendary** | #199 — Reputation & Social Standing | | **Type** | Feature | | **Priority** | High | | **Points** | 8 | | **MoSCoW** | Must Have | | **Branch** | `feature/m4-reputation-gameplay-effects` | | **Commit Message** | `Implement gameplay effects — merchant price multipliers, area access restrictions, quest availability based on reputation tier (#218)` | ## Background and Context Reputation is only meaningful if it has tangible effects on gameplay. This issue implements three core gameplay systems that respond to a player's reputation tier with various entities: 1. **Merchant price multipliers**: Merchants adjust their prices based on the player's reputation with their faction or settlement. Exalted players get significant discounts, while Reviled players face massive markups — or may be refused service entirely. 2. **Area access restrictions**: Certain areas (faction headquarters, inner cities, sacred grounds) require a minimum reputation tier to enter. Players below the threshold are turned away at the door. 3. **Quest availability**: NPCs only offer certain quests to players who have achieved a minimum reputation tier. This gates content behind reputation progression and rewards players who invest in building relationships. All thresholds and multipliers are configurable per entity, allowing world builders to create nuanced reputation-gated content. ## Expected Behavior 1. **Merchant prices**: Each merchant has a `faction` attribute. When a player buys/sells, the price is multiplied by a factor based on their tier with that faction: - Reviled: 3.0x buy / 0.3x sell (or refused entirely) - Hated: 2.5x buy / 0.4x sell - Hostile: 2.0x buy / 0.5x sell - Unfriendly: 1.5x buy / 0.7x sell - Neutral: 1.0x buy / 1.0x sell - Friendly: 0.9x buy / 1.1x sell - Respected: 0.8x buy / 1.2x sell - Honored: 0.7x buy / 1.3x sell - Exalted: 0.5x buy / 1.5x sell 2. **Area access**: Rooms/areas can have a `min_reputation` attribute specifying `{entity_id: tier}`. Players below the tier see a rejection message and cannot enter. 3. **Quest availability**: Quest givers check player reputation tier before offering quests. Quests have a `required_reputation` attribute specifying `{entity_id: tier}`. 4. All multipliers and thresholds are overridable per entity in configuration. ## Acceptance Criteria - [ ] Merchant price calculation correctly applies tier-based multipliers for both buying and selling. - [ ] Merchants can refuse service to Reviled players. - [ ] Area access checks reputation tier before allowing entry. - [ ] Players receive a clear message when denied area access due to reputation. - [ ] Quest givers check reputation before offering quests. - [ ] Players receive a clear message when reputation is too low for a quest. - [ ] All multipliers and thresholds are configurable per entity. - [ ] Default multiplier table matches the specification above. - [ ] Effects update dynamically as reputation changes. ## Subtasks - [ ] Create `lib/aethyr/core/reputation/reputation_effects.rb` with the effects engine. - [ ] Implement merchant price multiplier system with tier-based lookup table. - [ ] Implement buy/sell multiplier application in merchant transaction flow. - [ ] Implement service refusal for Reviled tier. - [ ] Implement area access restriction checking on room entry. - [ ] Implement rejection message for insufficient reputation on area entry. - [ ] Implement quest availability check on quest offer. - [ ] Implement rejection message for insufficient reputation on quest offer. - [ ] Add per-entity override configuration support. - [ ] Integrate effects with existing merchant, room, and quest systems. - [ ] Docs: Update YARD comments on affected classes and methods. Update relevant Docusaurus documentation pages if applicable. - [ ] Tests (Cucumber): Add `tests/unit/reputation_effects.feature` covering all price multiplier tiers, area access checks, quest availability checks, service refusal, rejection messages, and per-entity overrides. - [ ] Tests (Cucumber Integration): Add integration feature in `tests/integration/` for end-to-end gameplay effects with merchant transactions, room entry, and quest interactions. - [ ] 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.