Refresh repository documentation
Some checks failed
Deploy to Production / test (push) Failing after 33s
Some checks failed
Deploy to Production / test (push) Failing after 33s
- Rewrite AGENTS and README files to match the current app layout - Document API routes, trivia UI, and the active panel design language
This commit is contained in:
@@ -1,10 +1,32 @@
|
||||
# Quest Module
|
||||
# Quest module
|
||||
|
||||
- Quests are **event-driven**. The `handleEvent` method is called by system event listeners (not by commands directly). It matches events by exact name or prefix (e.g., trigger `ITEM_COLLECT` matches event `ITEM_COLLECT:101`), enabling both generic and specific quest triggers.
|
||||
- Max active quests is controlled by `gameSettingsService`, not hardcoded. Default is 3.
|
||||
- `assignQuest` uses `onConflictDoNothing` -- re-assigning an already-assigned quest silently no-ops. This is intentional to avoid duplicate quest entries.
|
||||
- Quest progress is a simple integer counter. The `weight` parameter in `handleEvent` allows a single event to advance progress by more than 1 (useful for bulk actions).
|
||||
- Quest completion is **automatic**: when progress >= target during `handleEvent`, `completeQuest` is called within the same transaction. There is no manual "turn in" step.
|
||||
- Rewards (xp and balance) are distributed via `economyService` and `levelingService` inside the completion transaction. The `QUEST.COMPLETED` event is emitted with `systemEvents.emit` (fire-and-forget, not async) for bot-layer notifications.
|
||||
- `requirements` and `rewards` are stored as JSON columns. Always expect `{ target: number }` for requirements and `{ xp?: number, balance?: number }` for rewards.
|
||||
- Completed quests are never deleted -- they stay in `userQuests` with a `completedAt` timestamp. `getAvailableQuests` excludes any quest the user has ever been assigned (completed or not).
|
||||
## Model
|
||||
|
||||
- quests are event-driven
|
||||
- user progress is stored in `user_quests`
|
||||
- completion is automatic once progress reaches the quest target
|
||||
|
||||
## Main methods
|
||||
|
||||
- `assignQuest()`
|
||||
- `updateProgress()`
|
||||
- `handleEvent()`
|
||||
- `completeQuest()`
|
||||
- `getUserQuests()`
|
||||
- `getAvailableQuests()`
|
||||
- `createQuest()`
|
||||
- `getAllQuests()`
|
||||
- `deleteQuest()`
|
||||
- `updateQuest()`
|
||||
|
||||
## Rules
|
||||
|
||||
- max active quests comes from `gameSettingsService`
|
||||
- `assignQuest()` uses `onConflictDoNothing()`
|
||||
- `handleEvent()` matches either exact trigger names or `trigger:` prefixes, for example `ITEM_COLLECTED:42`
|
||||
- rewards can include balance and XP and are paid inside the completion transaction
|
||||
|
||||
## Notes
|
||||
|
||||
- completed assignments remain in `user_quests`
|
||||
- `EVENTS.QUEST.COMPLETED` is emitted for the bot/UI layer after reward distribution
|
||||
|
||||
Reference in New Issue
Block a user