RFC: Quests

[wescopeland]

• Start Date: 2025-12-03
• References: Achievement Quests #667 Meta-badges / Quests / Multi-game sets #1415

Version History

Version	Date	Summary
1.0	2025-12-03	Initial RFC
1.1	2025-12-03	Clarified achievement set revision handling and progress regression policy
1.2	2025-12-03	Added developer_id and sole_developer parameters to count-based objectives
1.3	2025-12-03	Added exclude_game_tags parameter to filter out certain types of games from objectives
1.4	2025-12-10	Replaced versioning system with extension-only model based on community feedback
1.5	2025-12-13	Added additive-only modifications for published tiers based on community feedback

Summary

This RFC proposes adding Quests as a third type of "playable" to RetroAchievements, alongside Games and Events.

Quests are curated, long-form, evergreen challenges that span multiple objectives: things like "beat all Mega Man games" or "master 50 SNES games" or "beat all/N games in this hub". Like events, they support tiered badge awards. They can be extended with new tiers over time while preserving existing progress.

Motivation

The Problem
RetroAchievements currently has two types of playables:

1. Games. These are individual titles with 0 to N achievement sets.
2. Events. These are often time-limited community challenges tightly coupled to achievements.

Players have routinely expressed interest in curated, long-term goals that span multiple games (eg: "hub masteries"). Currently, there's no support for this, and users often track such goals individually and informally.

Why Quests?
"Hub masteries" are undesirable because they would tightly couple an award to core site navigation infrastructure. Hubs are very routinely updated as the site evolves. Hub masteries would constantly be undergoing "revisions".

Quests address this issue, as well as the gaps mentioned in the above problem statement, by providing structured challenges that:

• Guide users through themed experiences (master all games in a series, master N games of a console, etc).
• Reward progress with awards at multiple tiers, similar to automated events such as Achievement of the Week.
• Are always available (not time-limited like many events).
• Can be extended with new tiers over time while preserving existing progress.

Here's a detailed visualization for how Quests would differ from Games and Events:

Aspect	Games	Events	Quests
Time-bound	No	Often	No
Achievement-centric	Yes	Yes	Not necessarily
Curated	No	Yes	Yes
Allows softcore	Always	Never	Sometimes

Glossary

Term	Definition
Quest	A curated challenge with one or more tiers of objectives.
Tier	A level of completion with its own award (Bronze, Silver, etc).
Objective	A single requirement within a quest (beat game X, unlock achievement Y).
Specific-target objective	An objective targeting one or more specific entities (game, achievement, leaderboard, etc).
Count-based objective	An objective requiring N completions matching filters (eg: beat 50 SNES games).
Retired quest	A quest that is permanently ended and no longer earnable by new users. Existing badge holders keep their awards.

Detailed Design

Quests can require any combination of:

• Unlocking specific achievements (similar to events).
• Beating specific games.
• Mastering specific achievement sets (base sets or subsets).
• Achieving leaderboard minimum scores or minimum ranks.
• Completing other quests (quests are nestable).
• Earning evergreen event award tiers.
• Count-based goals (beat N games from system X, etc).

Data Model

Quest
The core quest entity. Uses self-healing URLs via the HasSelfHealingUrls trait (same pattern as Events).

id
title
description
slug (URL-friendly, used in self-healing URLs like /quest/123-slug)
state (QuestState enum value)
mode (QuestMode enum value)
published_at (nullable, locks the quest structure once it's set)
retired_at (nullable, set when the quest is permanently ended)
created_by (FK to user id)
quest_series_id (nullable FK to a quest series)
series_order_column (nullable, order within series)
created_at
updated_at

QuestAwardTier
Award tiers within a quest. Each tier has its own concretely-defined requirements. Note: the quest's display image is derived from the highest tier's award_type_meta.image_asset_path. While the system supports independent tiers, quest authors should design tiers as cumulative goals (eg: Silver builds on Bronze requirements). New tiers can be added to published quests, but existing tiers cannot be modified.

id
quest_id (FK to quest)
tier_index (0, 1, 2, ... - lower = easier)
label ("Bronze", "Silver", "Journeyman", etc)
award_type (QuestTierAwardType enum value)
award_type_meta (JSON, eg {image_asset_path: "..."}. the idea is awards may not always be badges)
requirement_type: 'all' | 'any_n'
required_count (nullable, used for 'any_n' requirement type)
created_at
updated_at

QuestObjective
Individual requirements within a QuestAwardTier. If the user completes these requirements, they receive the award.

id
quest_award_tier_id (FK to QuestAwardTier)
type (QuestObjectiveType enum value)
target_ids (nullable JSON array - game ids, achievement ids, etc. Objective is satisfied when ANY target is completed.)
parameters (JSON - filters, thresholds, counts)
order_column (order the objective appears on the quest page in the front-end)
created_at
updated_at

Objective Alternatives
Some objectives may be satisfied by completing any one of several alternatives. For example, "Beat Final Fantasy I" could be satisfied by beating the NES, GBA, PSP, or WonderSwan version. To support this, target_ids is a JSON array. For specific-target objectives, the objective is complete when ANY target in the array is satisfied. For count-based objectives, target_ids is null.

Examples:

• Single target: target_ids: [1234]
• Multiple alternatives: target_ids: [1234, 5678, 9012] (complete when any one is done)

PlayerQuest
Tracks a user's overall progress on a given quest. This is analogous to player_games or player_achievement_sets in the database. Note: both completed_at and completed_hardcore_at are tracked because users may toggle between softcore and hardcore modes during their playthrough.

id
user_id (FK)
quest_id (FK)
highest_tier_achieved (nullable)
completed_at (nullable)
completed_hardcore_at (nullable)
created_at
updated_at

PlayerQuestObjective
Tracks a user's completion of individual quest objectives. This is analogous to player_achievements in the database.

id
user_id (FK)
quest_objective_id (FK)
completed_at
completed_hardcore_at
created_at
updated_at

QuestSeries
Optional grouping for related quests (eg: "1980 Greatest Hits", "1981 Greatest Hits", "1982 Greatest Hits", etc). This is very similar to hubs, but exclusive to quests and may have a much different UI treatment.

id
title
description
image_asset_path
order_column
created_at
updated_at

QuestEvent
A lightweight queue table for tracking platform actions that may affect quest progress. Processed by a periodic batch job that would run every 10 minutes. Once the job is done, all the rows in the table are deleted.

id
user_id (FK)
action_type ('game_beaten', 'achievement_unlocked', 'leaderboard_score', etc)
target_id (game_id, achievement_id, leaderboard_id, etc)
system_id (for efficient filtering on count-based objectives)
created_at

Enum Values

QuestState

enum QuestState: string {
    /** Not visible to players, still being created by some team. */
    case Draft = 'draft';

    /** Live and completable. */
    case Active = 'active';

    /** Permanently ended, no longer earnable by new users. */
    case Retired = 'retired';
}

Note on deletion: Only quests in Draft state can be soft deleted. Once a quest is published (state becomes Active), it can only be Retired (permanently ended), never deleted. This preserves integrity of any user progress or awards. Users who earned badges from retired quests keep them, displayed with a subtle "retired" indicator. This is similar to awards for ~Z~'d games.

QuestMode

enum QuestMode: string {
    /** Only hardcore objective completions count. */
    case Hardcore = 'hardcore';

    /** Either softcore or hardcore objective completions count. */
    case Softcore = 'softcore';
}

QuestObjectiveType
This RFC includes 10 objective types, split into two categories:

• Specific target types (require QuestObjective.target_ids, satisfied when ANY target is completed):

  • GameBeaten: user has beaten a specific game.
  • AchievementSetCompleted: user has completed or mastered a specific achievement set.
  • AchievementUnlocked: user has unlocked a specific achievement.
  • LeaderboardScore: user has achieved a minimum score on a leaderboard (be sure to account for LowerIsBetter).
  • LeaderboardRank: user has achieved a minimum rank on a leaderboard
  • QuestAwardTierEarned: user has earned a specific award tier in another quest (enables quest nesting)
  • EventAwardTierEarned: user has earned a specific award tier in an event (should be an evergreen event)

• Count-based types (target_ids is null, optional filters defined in QuestObjective.parameters):

  • GamesBeatenCount: user has beaten N games matching prescribed filters
  • SetsMasteredCount: user has mastered N achievement sets matching prescribed filters
  • SetsWithAchievementsCount: user has unlocked achievements from N different achievement sets (think: "World Tour")

Objective Parameters Reference

Type	target_ids	parameters
GameBeaten	[game_id, ...]	{}
AchievementSetCompleted	[achievement_set_id, ...]	{}
AchievementUnlocked	[achievement_id, ...]	{}
LeaderboardScore	[leaderboard_id, ...]	{min_score: int}
LeaderboardRank	[leaderboard_id, ...]	{min_rank: int}
QuestAwardTierEarned	[quest_id, ...]	{min_tier: int}
EventAwardTierEarned	[event_id, ...]	{min_tier: int}
GamesBeatenCount	null	{count: int, system_id?: int, hub_id?: int, developer_id?: int, sole_developer?: bool, exclude_game_tags?: string[]}
SetsMasteredCount	null	{count: int, system_id?: int, hub_id?: int, developer_id?: int, sole_developer?: bool, exclude_game_tags?: string[]}
SetsWithAchievementsCount	null	{count: int, system_id?: int, hub_id?: int, developer_id?: int, sole_developer?: bool, exclude_game_tags?: string[]}

Developer Filtering for Count-Based Objectives
The developer_id and sole_developer parameters allow quests to target content developed by specific achievement developers:

• developer_id: Filter to games where this user has user_id on achievements in the game's achievement sets.
• sole_developer (default: false): When false, a game qualifies if the developer authored any published achievement. When true, a game qualifies only if the developer authored all published achievements.

The scope of "achievement sets" varies by objective type:

• GamesBeatenCount: Looks at the base achievement set only (since beaten status is determined by progression/win condition achievements, which are only in base sets).
• SetsMasteredCount: Looks at all achievement sets (base and subsets).
• SetsWithAchievementsCount: Looks at all achievement sets.

Game Tag Filtering for Count-Based Objectives
The exclude_game_tags parameter filters out games by their tags. Valid values: demo, hack, homebrew, prototype, test_kit, unlicensed.

Games are tagged via the ~Tag~ pattern in titles (eg: "~Hack~ Super Mario 64"). "Retail" is not a tag - it's the absence of several of these tags. To restrict an objective to retail games only, exclude all tags except unlicensed.

Note: Subsets inherit their parent game's tags, so excluding hack will also exclude subsets of hack games.

Extension Model

Quests are designed to be stable, long-term goals. However, they can be extended with new tiers over time (eg: a new game is added to a series, unlocking a higher tier).

Design Philosophy:
Quests should be cautiously & judiciously designed. Once published, existing tiers are largely immutable, with very limited exceptions for strictly additive changes. This forces quest authors to design carefully upfront and prevents the FOMO that would result from constantly-changing requirements.

Why allow additive changes?
Strict immutability creates problems for real-world scenarios where the platform evolves:

• A quest requires "Beat Twilight Princess" with a GameCube target_id. Later, Wii support is added. Without additive changes, players who beat the Wii version can never satisfy this objective.
• A quest like "Achievement of the Week Veteran" uses any_n to let players earn credit from any 2 of 3 AOTW years. Without additive changes, a future year's AOTW can never be added as an option.
• A "Console Conqueror" quest lets players complete its Bronze tier from any 3 console quests. When DOS or 3DS support arrives, those new console quests can't be added as options.

Additive-only changes solve these problems while preserving the core immutability principle: quests never get harder for existing players.

What can be changed after publication:

• New tiers can be added (with tier_index higher than existing tiers).
• New objectives can be added to any_n requirement type tiers (adds options, never makes tier harder).
• New target_ids can be added to specific-target objectives (eg: new console ports become available).
• Quest metadata (title, description) can be updated.

What cannot be changed after publication:

• Existing tier labels, requirement_type, or required_count.
• Removing existing objectives or adding objectives to all requirement type tiers.
• Modifying existing objective parameters (removal of target_ids is not allowed).
• Count thresholds or filter parameters in count-based objectives.

Backfill on Additive Changes:
When new target_ids are added to an objective, a backfill job is dispatched to credit users who already completed the newly-added targets. The original completion timestamp from platform data is used, ensuring users get proper credit for work they've already done.

When should a quest be retired?
If a quest's premise is fundamentally broken (eg: references content that will never be restored), the quest should be retired. Retirement is intentionally heavy-handed to discourage casual changes:

• Retired quests are no longer earnable by new users.
• Users who earned badges keep them, displayed with a subtle "retired" indicator similar to ~Z~'d game badges.
• If similar functionality is needed, create a new quest.

Quests should be designed such that quest retirement is an exceptionally rare last resort to preserve the integrity of the quests system itself.

Underlying Data Changes
Quest objectives are initially evaluated against current platform completion state. Once a PlayerQuestObjective is marked complete (completed_at / completed_hardcore_at is set), it becomes a durable record. However, certain platform changes can cause a player's quest progress to regress.

Cause	Regress Progress?	Rationale
Developer wipes leaderboard entry	Yes	Leaderboard was bugged or this was a punitive action
Game's beaten condition changes	Yes	Platform requirements changed
Set is revised, objective not yet completed	Yes	User should meet the new requirements
Set is revised, objective already completed	No	User earned it under the rules at the time
Set is demoted	No	Players keep credit; new players wait for restoration
User resets their own achievements	No	User may want to reset profile but keep quest credit

Data Sources for Quest Objectives:

Objective Type	Data Source	Fields
GameBeaten	player_games	beaten_at, beaten_hardcore_at
AchievementSetCompleted	player_achievement_sets	completed_at, completed_hardcore_at
AchievementUnlocked	player_achievements	unlocked_at, unlocked_hardcore_at
LeaderboardScore	leaderboard_entries	score (compared against min_score parameter)
LeaderboardRank	leaderboard_entries	Calculated rank on leaderboard
QuestCompleted	player_quests	completed_at, completed_hardcore_at
EventAwardTierEarned	player_badges	AwardType, AwardData, AwardDataExtra
GamesBeatenCount	player_stats	Pre-calculated beaten counts by system/type
SetsMasteredCount	player_stats	Pre-calculated mastery counts by system/type
SetsWithAchievementsCount	player_achievements	COUNT(DISTINCT achievement_set_id) calculated on the fly

Progress Evaluation

Quest progress is calculated automatically for all users based on their normal activity on RA. Users can browse quests and immediately see their current progress.

To ensure server health is unaffected, quest progress is determined via queue-based batch processing, not too dissimilar from search updates (Laravel Scout) for games and achievements.

Triggering Events
The following platform events will insert rows into quest_events:

• PlayerBeatenGamesStatsUpdated - for game beaten objectives and count-based beaten objectives
• PlayerBadgeAwarded - for mastery/completion objectives and event award tier objectives
• PlayerAchievementUnlocked - for achievement unlock objectives
• Leaderboard entry events - for leaderboard score/rank objectives

An example flow would be:

1. Player beats a game.
2. UpdatePlayerBeatenGamesStatsAction fires (this already happens today).
3. player_stats is updated, and PlayerBeatenGamesStatsUpdated is dispatched.
4. QuestProgressListener picks up this dispatched event.
5. A row is inserted to quest_events, which acts as a queue.
6. A batch job processes the quest_events queue every 10 minutes, updating the affected PlayerQuestObjective records.

The quests_events table acts like a queue, with a periodic background batch job processing events. When an event is processed, matching quest objectives are found, and PlayerQuestObjective records get updated.

It may be desirable to give impatient players a "manual refresh" option on the quest page. If implemented, this should be rate limited (eg: once per minute per user).

PlayerStatType Extensions
Count-based objectives will leverage the existing player_stats table rather than recalculating counts on the fly. This requires extending PlayerStatType with new stat types:

• Softcore beaten counts (by game type: retail, hacks, homebrew, etc)
• Mastered and completed counts (by game type)

Note: SetsWithAchievementsCount objectives should be calculated on the fly via COUNT(DISTINCT achievement_set_id) queries rather than maintaining a dedicated stat, since these "World Tour" style objectives are likely to be relatively rare.

Tags

Quests shall use spatie/laravel-tags with a "quest" namespace. We can have some starting tags that are system-based ("nes", "snes", etc), type-based ("series", "beginner", "expert"), and theme-based ("rpg", "platformer").

Awards

Quests shall integrate with the existing PlayerBadge (SiteAwards table) system:

// new AwardType constant
const Quest = 10;

// PlayerBadge fields for quest awards:
// AwardType = 10 (Quest)
// AwardData = quest_id
// AwardDataExtra = tier_index

Access Control

Quest creation and editing will be restricted to either the admin team or an as-of-yet unformed "Quest Team" role. All published quests are visible to all users.

Example Quest Definitions

Series Quest: Mega Man NES

Quest:
  title: "Mega Man NES Quest"
  mode: softcore # both hardcore and softcore are allowed

AwardTiers:
  - tier_index: 0
     label: "Beat them all"
     requirement_type: "all"
     objectives:
       - type: game_beaten, target_ids: [{mega man 1 game id}]
       - type: game_beaten, target_ids: [{mega man 2 game id}]
       - type: game_beaten, target_ids: [{mega man 3 game id}]
       - type: game_beaten, target_ids: [{mega man 4 game id}]
       - type: game_beaten, target_ids: [{mega man 5 game id}]
       - type: game_beaten, target_ids: [{mega man 6 game id}]

  - tier_index: 1
     label: "Master them all"
     requirement_type: "all"
     objectives:
       - type: achievement_set_completed, target_ids: [{mega man 1 base set id}]
       - type: achievement_set_completed, target_ids: [{mega man 2 base set id}]
       - type: achievement_set_completed, target_ids: [{mega man 3 base set id}]
       - type: achievement_set_completed, target_ids: [{mega man 4 base set id}]
       - type: achievement_set_completed, target_ids: [{mega man 5 base set id}]
       - type: achievement_set_completed, target_ids: [{mega man 6 base set id}]

Beat All Final Fantasy Games Quest (with alternatives)
This example shows how target_ids supports alternative targets. Each FF game has multiple versions, and beating ANY version satisfies the objective.

Quest:
  title: "Beat All Final Fantasy Games"
  mode: softcore

AwardTiers:
  - tier_index: 0
    label: "Beat All Final Fantasy Games"
    requirement_type: "all"
    objectives:
      # Beat any version of FF1 (NES, GBA, PSP, WonderSwan, etc)
      - type: game_beaten, target_ids: [{ff1_nes}, {ff1_gba}, {ff1_psp}, {ff1_ws}]
      # Beat any version of FF2
      - type: game_beaten, target_ids: [{ff2_nes}, {ff2_gba}, {ff2_psp}, {ff2_ws}]
      # Beat any version of FF3
      - type: game_beaten, target_ids: [{ff3_nes}, {ff3_ds}]
      # ... and so on ...

Beat Some Retail SNES Games Quest
This quest has objectives which specifically exclude games with tags.

Quest:
  title: "Beat Some Retail SNES Games"
  mode: softcore # both hardcore and softcore are allowed

AwardTiers:
  - tier_index: 0
    label: "SNES Novice"
    objectives:
      - type: games_beaten_count
        parameters:
          system_id: 3
          count: 25
          exclude_game_tags: [demo, hack, homebrew, prototype, test_kit]

  - tier_index: 1
    label: "SNES Enthusiast"
    objectives:
      - type: games_beaten_count
        parameters:
          system_id: 3
          count: 50
          exclude_game_tags: [demo, hack, homebrew, prototype, test_kit]

  # ... even more tiers ...

Donkey Kong Million Point Club Quest (leaderboard scores)
This example shows how quests can require achieving minimum scores on leaderboards via LeaderboardScore.

Quest:
  title: "Donkey Kong Million Point Club"
  mode: hardcore # leaderboards only support hardcore mode

AwardTiers:
  - tier_index: 0
    label: "Million Point Club"
    requirement_type: all
    objectives:
      - type: leaderboard_score
        target_ids: [{dk_arcade_leaderboard}]
        parameters: {min_score: 1000000}
      - type: leaderboard_score
        target_ids: [{dk_jr_arcade_leaderboard}]
        parameters: {min_score: 1000000}
      - type: leaderboard_score
        target_ids: [{dk3_arcade_leaderboard}]
        parameters: {min_score: 1000000}

Beat Any 3 of These 5 Games Quest

Quest:
  title: "Beat Any 3 of These 5 Games"
  mode: softcore # both hardcore and softcore are allowed

AwardTiers:
  - tier_index: 0
    label: "Platformer Fan"
    requirement_type: "any_n"
    required_count: 3
    objectives:
      - type: game_beaten, target_ids: [{Super Mario Bros game id}]
      - type: game_beaten, target_ids: [{Sonic the Hedgehog game id}]
      - type: game_beaten, target_ids: [{Mega Man 2 game id}]
      - type: game_beaten, target_ids: [{Castlevania game id}]
      - type: game_beaten, target_ids: [{Contra game id}]

Console Conqueror Quest (quest nesting)
This example shows how quests can require completion of other quests via QuestAwardTierEarned.

Quest:
  title: "Console Conqueror"
  mode: softcore # both hardcore and softcore are allowed

AwardTiers:
  - tier_index: 0
    label: "Multi-Console Beginner"
    requirement_type: all
    objectives:
      # Earn the Bronze tier award on multiple console quests
      - type: quest_award_tier_earned, target_ids: [{nes_quest_id}], parameters: {min_tier: 0}
      - type: quest_award_tier_earned, target_ids: [{snes_quest_id}], parameters: {min_tier: 0}
      - type: quest_award_tier_earned, target_ids: [{genesis_quest_id}], parameters: {min_tier: 0}

  - tier_index: 1
    label: "Console Master"
    requirement_type: all
    objectives:
      # Earn the Gold tier award on multiple console quests
      - type: quest_award_tier_earned, target_ids: [{nes_quest_id}], parameters: {min_tier: 2}
      - type: quest_award_tier_earned, target_ids: [{snes_quest_id}], parameters: {min_tier: 2}
      - type: quest_award_tier_earned, target_ids: [{genesis_quest_id}], parameters: {min_tier: 2}

Achievement of the Week Veteran Quest (event tiers)
This example shows how quests can require earning tiers across multiple evergreen events via EventAwardTierEarned.

Quest:
  title: "Achievement of the Week Veteran"
  mode: hardcore # AOTW is hardcore-only

AwardTiers:
  - tier_index: 0
    label: "AOTW Fan"
    requirement_type: any_n
    required_count: 2
    objectives:
      # Earn at least Bronze in a minimum of two AOTW years
      - type: event_award_tier_earned, target_ids: [{aotw_2023_event_id}], parameters: {min_tier: 0}
      - type: event_award_tier_earned, target_ids: [{aotw_2024_event_id}], parameters: {min_tier: 0}
      - type: event_award_tier_earned, target_ids: [{aotw_2025_event_id}], parameters: {min_tier: 0}

  - tier_index: 1
    label: "AOTW Expert"
    requirement_type: any_n
    required_count: 3
    objectives:
      # Earn at least Silver across 3 different AOTW years
      - type: event_award_tier_earned, target_ids: [{aotw_2023_event_id}], parameters: {min_tier: 1}
      - type: event_award_tier_earned, target_ids: [{aotw_2024_event_id}], parameters: {min_tier: 1}
      - type: event_award_tier_earned, target_ids: [{aotw_2025_event_id}], parameters: {min_tier: 1}

  - tier_index: 2
    label: "AOTW Legend"
    requirement_type: all
    objectives:
      # Earn Gold in 3 different AOTW years
      - type: event_award_tier_earned, target_ids: [{aotw_2023_event_id}], parameters: {min_tier: 2}
      - type: event_award_tier_earned, target_ids: [{aotw_2024_event_id}], parameters: {min_tier: 2}
      - type: event_award_tier_earned, target_ids: [{aotw_2025_event_id}], parameters: {min_tier: 2}

Developer Appreciation Quest
This example shows how quests can celebrate prolific developers by requiring players to beat or master sets they've worked on.

Quest:
  title: "Developer Appreciation: SnowPin"
  mode: softcore

AwardTiers:
  - tier_index: 0
    label: "Mild SnowPin Fan"
    requirement_type: all
    objectives:
      # Beat 10 games that SnowPin contributed to (solo or collab)
      - type: games_beaten_count
        parameters: {count: 10, developer_id: {snowpin_user_id}, sole_developer: false}

  - tier_index: 1
    label: "Moderate SnowPin Fan"
    requirement_type: all
    objectives:
      # Beat 10 games that SnowPin solo contributed to
      - type: games_beaten_count
        parameters: {count: 10, developer_id: {snowpin_user_id}, sole_developer: true}

  - tier_index: 2
    label: "Big SnowPin Fan"
    requirement_type: all
    objectives:
      # Master 10 sets that SnowPin solo contributed to
      - type: sets_mastered_count
        parameters: {count: 10, developer_id: {snowpin_user_id}, sole_developer: true}

  - tier_index: 3
    label: "Ultimate SnowPin Fan"
    requirement_type: all
    objectives:
      # Master 18 sets that SnowPin solo contributed to
      - type: sets_mastered_count
        parameters: {count: 18, developer_id: {snowpin_user_id}, sole_developer: true}

[redwizard42]

It isn't immediately clear if I could specify a set of games for a counter objective. Like if an objective is "beat any version of Ultima III" I'd expect it to be a counted objective with a target of 1 with parameters being a set of game IDs that is basically ever Ultima III release that has a set.

[redwizard42]

And now I see an example with target IDs and know this is doable with this proposal. Great!

[wescopeland]

Yep, the current design should be able to handle this 🙂

This is currently covered by a GameBeaten objective with multiple target_ids:

- type: game_beaten, target_ids: [{ultima3_nes}, {ultima3_snes}, {ultima3_dos}, ...]

The single objective would be satisfied when any one target is completed.

[sutarionRA]

Can you share more information on your vision for how legacy awards would work?
Evergreen events have been incredibly popular thanks to a combination always being available and automated tracking, both things that quests will be offering based on this proposal. However, I'm concerned about the idea of certain versions of the quests no longer being
available after a new version is released.

Some folks already feel overwhelmed trying to earn all the event badges because they are time-limited in nature. However, I think those same people with a fear of missing out will feel the need to tackle any new quest immediately for fear that a new version could lock them out of a badge. This goes against the intent of the quest system as proposed.

Suppose a newly supported console requires an addition of new Super Mario games to the "Beat all SMB Games" quest (for example, Super Mario Galaxy 1 + 2 with the release of Wii). If new assets are being created for this new version of the event, could the new tier be added on top of the existing quest while still allowing players to earn both as they clear the requirements? Xionx recommended allowing players that have earned multiple tiers to choose which version of the quest badge to display.

The downside to this is that some players may choose to only go for the lowest tier of the quest (Pre-Wii Mario) and ignore the Galaxy games entirely, and going against the intent of the quest to beat all Mario games. However, this could avoid ire towards quest revisions by allowing a quest to change while also preserving the initial quest design.

[LuneDeCuivre]

I could see replace being needed for quests that have a more nebulous, loose-fitting credentials, such as "NES classics" or something like that. But I don't see why you'd want those to be changed if the goal is to keep quests difficult to change.

I'm personally up for the quests to be like current mastery badge behavior with set revisions: if a quest is changed, those that already achieved it still have credit, but the icon does not change.

If a wildly different take on a quest is suggested, it might be worth making that a second quest anyways and keeping the first.

[rholliday]

I'm personally up for the quests to be like current mastery badge behavior with set revisions: if a quest is changed, those that already achieved it still have credit, but the icon does not change.

If a wildly different take on a quest is suggested, it might be worth making that a second quest anyways and keeping the first.

This is my thought too, if people aren't locked out of masteries I wouldn't see why they'd need to be locked out of quest completion. There could be a sort of asterisked display like older mastery counts show up now.

There could perhaps be special cases where a quest has to be completely reworked for some reason but I would think that would be the exception more than a regular occurrence. Beta quests for volunteer testing to avoid this issue?

[wescopeland]

Hey @sutarionRA @Chew @LuneDeCuivre @rholliday @oddgoo! Thanks for all the healthy feedback.

After reviewing it all, I've published version 1.4 of the RFC. The full diff is viewable in the RFC's edit history.

I've reflected and agree with most of the feedback given here, so the back-end design is going to take an updated direction. Quests are now extension-only, with no versioning support.

What this means:

1. Published tiers are immutable. Once a quest tier is published, its requirements can never be modified.
2. New tiers can still be added later. This handles additive cases elegantly (new games in a series, new system support, etc).
3. There's no longer any concept of earlier version awards. Since tiers don't change, there shouldn't be any FOMO about missing "V1" badges.
4. Quests can still be retired. If a quest is fundamentally broken in some way, it can be retired as a last resort. This is only an escape hatch. Quests should be designed such that this rarely, if ever, happens, but it's still critical for the back-end to support that last resort option.

I think these changes should address the feedback here.

• Players can now complete quests at their own pace without the mentioned fear of lockout/FOMO.
• The quest team is further incentivized to design stuff carefully up front.
• The back-end implementation details are actually simpler.
• The design is now consistent with how masteries work.

Thanks especially to @Chew for the "design for extension" insights and @LuneDeCuivre & @rholliday for the mastery badge parallel illustration.

[Kaiserlucas]

Thanks!
I think the extension-only approach makes a lot of sense for the reasons that have been listed already.
That said, I still have some worries about the immutability requirement for published tiers. While it does provide tangible benefits, it may be a bit too heavy-handed for some specific use cases.
My thinking is that having a mechanism for non-destructive extensions to published tiers could still be helpful to have.

Two concrete examples from the list of example quests in the RFC are Console Conqueror and Achievement of the Week Veteran:

For Console Conqueror, I like the idea of immutable tiers in principle, since it guarantees that a published tier never becomes harder over time. This also incentivizes better tier design up front, for example, using any_n across console families instead of an all requirement, so new console support only adds options rather than invalidating progress.

The issue I see is that a strict immutability rule limits how useful any_n can be in practice. If the set of valid objectives for a published tier can never change, then adding new consoles like DOS or 3DS as additional options would be impossible, even though doing so would be non-destructive to existing progress. Players would be permanently locked to the options available at the time the quest was created. The same issue applies to the Achievement of the Week Veteran example quest, where a new season should be added as an option every year but published tiers being immutable would make this not possible as far as I understand.

And if we ever had "hub mastery-like" quests, the ability to add more games to published tiers over time would also be important I feel. Intuitively, players would assume that if the quest is to beat 10 mainline Mario games, and we get 3DS support with a Super Mario 3D Land achievement set, it would be a valid option even if that tier was published a few years ago.

Another feature where I could see this coming into play is the game_beaten objective type with multiple target IDs. Let's say for instance that we have a quest requiring specifically a beat for The Legend of Zelda: Twilight Princess. Would the Wii U port need to be linked as a valid targetID at the time of quest creation in order to future-proof the quest? And while this is still a long way into the future before we support the systems for this to matter, new versions of old games are still being released. A recent example would be the HD-2D version of Dragon Quest 3 on the Switch. Even if due dilligence was practiced to add every single unsupported game as an option to future-proof, these are things we could not anticipate.

I realize the tradeoffs and the desire for active quests to not be majorly redefined after they launch, but I wonder if at least some controlled changes could be made to existing tiers that would not be destructive to players' progress while giving a bit more flexibility in what a quest can be. I don't know how messy an approach this granular would get from a backend perspective, but what I am thinking is:

What I would keep the same

• Requirement types and required counts should remain immutable. How many objectives need to be completed should never change.
• Objectives should never be removable, as that would invalidate existing player progress.
• If the requirement type is "all", no new objectives should be able to be added.

Where I think slightly more flexibility could be useful

• If the requirement type is any_n, quest tiers should be open to have new objectives added as additional options, but still never removed.
• Maybe objectives with multiple possible target IDs should have an option to add new target IDs at a later point, once again with no option of removal. It would be purely additive to be non-destructive to existing progress.

[wescopeland]

I think I can be bendable on this. v1.5 is up with a few changes which I think should help:

Design Philosophy:
Quests should be cautiously & judiciously designed. Once published, existing tiers are largely immutable, with very limited exceptions for strictly additive changes. This forces quest authors to design carefully upfront and prevents the FOMO that would result from constantly-changing requirements.

Why allow additive changes?
Strict immutability creates problems for real-world scenarios where the platform evolves:

• A quest requires "Beat Twilight Princess" with a GameCube target_id. Later, Wii support is added. Without additive changes, players who beat the Wii version can never satisfy this objective.
• A quest like "Achievement of the Week Veteran" uses any_n to let players earn credit from any 2 of 3 AOTW years. Without additive changes, a future year's AOTW can never be added as an option.
• A "Console Conqueror" quest lets players complete its Bronze tier from any 3 console quests. When DOS or 3DS support arrives, those new console quests can't be added as options.

Additive-only changes solve these problems while preserving the core immutability principle: quests never get harder for existing players.

What can be changed after publication:

• New tiers can be added (with tier_index higher than existing tiers).
• New objectives can be added to any_n requirement type tiers (adds options, never makes tier harder).
• New target_ids can be added to specific-target objectives (eg: new console ports become available).
• Quest metadata (title, description) can be updated.

What cannot be changed after publication:

• Existing tier labels, requirement_type, or required_count.
• Removing existing objectives or adding objectives to all requirement type tiers.
• Modifying existing objective parameters (removal of target_ids is not allowed).
• Count thresholds or filter parameters in count-based objectives.

Backfill on Additive Changes:
When new target_ids are added to an objective, a backfill job is dispatched to credit users who already completed the newly-added targets. The original completion timestamp from platform data is used, ensuring users get proper credit for work they've already done.

[sutarionRA]

A few scenarios based on experience with events that should be considered:
What happens when a Set/Achievement featured in a quest is demoted?

• Is quest made easier until this comes back
• Is it temporarily unavailable until the set returns?

If a revision changes the beat requirements of a set, how does that affect the quest requirement?

• Will the user need to go back and rebeat it under the new conditions or is quest credit unlocked when they originally beat it?
• Will prior masteries in 2015 grant credit even if a revision in 2025 made the set more difficult?

[wescopeland]

This is the current blurb for these scenarios:

Underlying Data Changes
If platform data referenced by a quest objective changes (eg: achievement set demoted for repair, leaderboard deleted, hub games modified), the quest and existing player progress remain unaffected. It is the responsibility of quest authors to publish a new version of the quest if needed.

In other words: let's say a quest requires players to master Star Fox 64 as one of its objectives. If Star Fox 64 is demoted for repair, the quest will not automatically adjust to reflect that. Players who have already mastered Star Fox 64 can still finish the quest, but if a player hasn't yet mastered Star Fox 64, they're out of luck until the set is repromoted.

This means the quest authors are not liable for whatever happens with the underlying quest assets.

If a revision changes the beat requirements of a set, how does that affect the quest requirement?

Under the current design outlined for the back-end, if a player loses their beaten award, their quest progress wouldn't be automatically recalculated. But it probably should be. I'll work that into the next update of the RFC.

Will prior masteries in 2015 grant credit even if a revision in 2025 made the set more difficult?

In my opinion, they shouldn't. The clock on mastering an achievement set should begin when a set quest is published. I will also work this into the next version of the RFC.

[wescopeland]

I've just updated the RFC to version 1.1. This update should address this feedback. Changes were made to the "underlying data changes" section:

---

Underlying Data Changes
Quest objectives are initially evaluated against current platform completion state. Once a PlayerQuestObjective is marked complete (completed_at / completed_hardcore_at is set), it becomes a durable record. However, certain platform changes can cause a player's quest progress to regress.

Cause	Regress Progress?	Rationale
Developer wipes leaderboard entry	Yes	Leaderboard was bugged or this was a punitive action
Game's beaten condition changes	Yes	Platform requirements changed
Set is revised, objective not yet completed	Yes	User should meet the new requirements
Set is revised, objective already completed	No	User earned it under the rules at the time
Set is demoted	No	Players keep credit; new players wait for restoration
User resets their own achievements	No	User may want to reset profile but keep quest credit

---

Will prior masteries in 2015 grant credit even if a revision in 2025 made the set more difficult?

For this feedback specifically, this is actually already handled in the design in a subtle way via the "Data Sources for Quest Objectives" table:

| AchievementSetCompleted | player_achievement_sets | completed_at, completed_hardcore_at |

player_achievement_sets is what we use in the database to track a player's true achievement set progress. It is always accurate with their current 0-100% completion status, even if they got the badge from an earlier version of the set. Because quests will use this table as a data source, old mastery badges will not count for quest progress, unless the user masters the achievement set while the quest is already running.

[Kaiserlucas]

One more use case I could think of that would be nice to see supported is specifying a certain amount of beats or masteries needed not just for a system or hub, but also for specific developers. I see the parameters are currently defined as this.

Type	target_ids	parameters
GamesBeatenCount	null	{count: int, system_id?: int, hub_id?: int}
GamesMasteredCount	null	{count: int, system_id?: int, hub_id?: int}
GamesWithAchievementsCount	null	{count: int, system_id?: int, hub_id?: int}

We have a lot of developers on the site who have worked on a great number of sets. Highlighting some of the most prolific developers with their own quest could be a nice way to show appreciation for their hard work. Adding another parameter option here could give some additional flexibility to support things like these.

[wescopeland]

Good idea. This could be another parameter added to the list of optional parameters, probably user_id. I'll work this into the next version of the RFC.

[wescopeland]

One challenge to figure out would be how to configure sole authorship vs collab authorship.

[wescopeland]

This is now addressed in the latest version of the RFC (1.2). The OP's edit history should be viewable. Here's the changes:

• GamesMasteredCount has been renamed to SetsMasteredCount.
• GamesWithAchievementsCount has been renamed to SetsWithAchievementsCount.
• developer_id and sole_developer params are now documented for GamesBeatenCount, SetsMasteredCount, and SetsWithAchievementsCount in the "Objective Parameters Reference" section.
• A new example quest definition has been added: "Developer Appreciation: SnowPin".

[Kaiserlucas]

After thinking through some of the given quest examples some more, I believe that the addition of way to restrict certain sets from being eligible for a quest based on their characteristics could be useful to have.

---

To give a concrete use case to illustrate

We may have a quest asking people to master 50 Gameboy games for completion, which is a reasonably challenging number to reach if you follow the intent of the quest and explore the breadth of the Gameboy library. However, the system also has a plethora of small homebrews, which oftentimes take less than half an hour to master. The bottom 50 sets on the GB in terms of points are all below 40 points and consist almost entirely of homebrews and very tiny hacks.

In this scenario, I think that the quest would be better at fulfilling its intent of getting people to interact with the library if we could in some way restrict the elegibility of sets. We already use similar low effort rules for some of the more freeform tasks in events like Challenge League, and I think having the option to add some for quests too would be useful.

---

Ways the restriction could work

The easiest way I could think of is being able to specify eligible set types (e.g. Retail only) in addition to the system or hub to use, and I think this would already cover the majority of use cases.

Another approach that we have taken in Challenge League is restricting sets under a certain total point threshold. I'm not sure if this would also be needed in addition to set type filtering, but it might be an idea worth considering.

[wescopeland]

That's a really good point. The RFC is now at version 1.3, which includes changes to facilitate this sort of filtering.

GamesBeatenCount, SetsMasteredCount, and SetsWithAchievementsCount objectives now support an exclude_game_tags optional parameter:

---

Game Tag Filtering for Count-Based Objectives
The exclude_game_tags parameter filters out games by their tags. Valid values: demo, hack, homebrew, prototype, test_kit, unlicensed.

Games are tagged via the ~Tag~ pattern in titles (eg: "~Hack~ Super Mario 64"). "Retail" is not a tag - it's the absence of several of these tags. To restrict an objective to retail games only, exclude all tags except unlicensed.

Note: Subsets inherit their parent game's tags, so excluding hack will also exclude subsets of hack games.

---

Additionally, one of the example quest definitions has been updated so its objectives now only consider retail games:

Quest:
  title: "Beat Some Retail SNES Games"
  mode: softcore # both hardcore and softcore are allowed

AwardTiers:
  - tier_index: 0
    label: "SNES Novice"
    objectives:
      - type: games_beaten_count
        parameters:
          system_id: 3
          count: 25
          exclude_game_tags: [demo, hack, homebrew, prototype, test_kit]

  - tier_index: 1
    label: "SNES Enthusiast"
    objectives:
      - type: games_beaten_count
        parameters:
          system_id: 3
          count: 50
          exclude_game_tags: [demo, hack, homebrew, prototype, test_kit]

  # ... even more tiers ...

I didn't include a set point threshold as a configurable parameter at this time. Ideally, tag-based exclusion filtering is sufficient.

[Jackcool476]

Could the LeaderboardScore source be expanded to include time-based leaderboards, and some sort of combined time for multiple of them in one quest? (technically this could also be done for score-based leaderboards but I couldn't think of a usecase as one game could potentially be played infinitely and make no need for playing the others, the proposal's DK Million Points club is a much better idea as you are required to get a minimum in each game)

For example, a quest to achieve the community challenge of the Super MariHour by beating 1 to 64 Any% in less than an hour, or something like a tiered quest for beating all 6 NES Mega Man games in under 6 hours, then 4 then 2 etc. It could even be tiered underneath the first tier of beating them in the first place.

As cool as this would be, I have two concerns with this idea. The first would be whether there would be a major performance cost on the server calculating the total time for every single quest any time a leaderboard entry is made. I assume it wouldn't be much for a small number of quests, but if they can be freely user-submitted it may be taxing with hypothetical hundreds of them linked to a single game.

My other concern would be some way to game the system. Say in the Mega Man example, the requirement for the first tier was having all 6 games beaten AND your total leaderboard entries under 6 hours. If you beat all six games legitimately, then submit a glitched leaderboard entry, you could speed to the final tier of the quest very quickly. The proposal mentions regressing progress if a leaderboard entry is removed, but this would also heavily reduce the combined time, so a way to ensure that each linked leaderboard has a valid entry before completing the quest would be necessary. (I started writing this assuming there was a way for a user to remove their entry manually, but as far as I can tell there isn't, so it wouldn't be as common of a problem as I thought but still potentially an issue)

A minor consideration for something like the MariHour is that it doesn't follow the leaderboard rules of the whole run having to be played in one sitting, which RA has no way to track so the quest requirement would just be a combination of your best times. However, I don't see this as a real concern as speedrunning is not the main focus of RA and a badge would be more of a cool bonus on your profile that you are technically able to do it, rather than competing directly with other users over your best time. (presuming that your combined time is not visible as a seperate leaderboard, and even if it were it still isn't that big of a deal imo)

[wescopeland]

Hey @Jackcool476 👋

Thanks for writing your detailed thoughts on this! I think it sounds like you're proposing an aggregate leaderboard objective - something like "sum of best times across leaderboards X, Y, and Z must be under N." This sounds cool.

My fear is it's a fundamentally new type of objective not supported anywhere else on the platform - X, Y, and Z leaderboards would effectively need some way to talk to each other. It's a new evaluation model entirely.

For V1, quests can kinda approximate this with multiple LeaderboardScore objectives using per-game thresholds (eg: beat SMB1 under 5 minutes, beat SMB2 under N minutes, beat SMB3 under N minutes, etc). Granted, this means I can do run X today, run Y tomorrow, and run Z the next day, and that's ultimately much less elegant than a true combined time across the games in a single cohesive sitting.

To be honest, I'm not sure quests are the right fit for this puzzle (I'm not sure what the right solution is). This almost sounds better-served as a single "resumable" leaderboard attached to multiple games that has different logic based on the hash that the player has loaded.

[wescopeland]

To further clarify, under the current RFC, speedrun leaderboards are valid as LeaderboardScore objectives.

score is the name of the column we use in the database for all types of leaderboards, whether it's a hi-score leaderboard or a speedrun leaderboard (in that case, score is the player's time).

[Jackcool476]

(i fear i have no idea what im talking about so please bear with me)

If it's already stored in the same data source, would the leaderboards even need to talk to each other? If the Quest is able to gather the data across each leaderboard of X milliseconds (i presume its stored like that) as LeaderboardScore, wouldn't the object be able to perform the equation in the backend to calculate the total time?

The idea of performing each run sequentially I understand is wayyy out of scope, and it was only an offhand comment that I assume actual speedrunners could chime in with that "you didn't complete the actual challenge so you shouldn't get rewarded for doing it", personally I think that it is a really cool idea for way off in the future (i would much rather have multiset first lol) and that its just a badge and would be a cool way to acknowledge the effort you put in anyway without stepping on their turf.

I brought up the MariHour specifically because of a reply I made to a multiset discussion about a year ago that proposed a "Titles" system, (very similar to these Quests actually) that proposed using the Mastery badges for the pre-existing Speedrun subsets on games like SMB1 and adding the ones together that would be less than an hour. This was very janky and doesn't allow room for saving time in individual games, so I saw the oppurtunity to use the LeaderboardScore you proposed as a much more precise version of this.

I'm much more attached to the NES Mega Man type of quest myself, and think it could be a good way to add tiers to hardcore-exclusive badges as leaderboards require you to be using hardcore mode anyway. This could make for a nice addition to the example you made as something like this:

Mega Man NES Quest:

1. Beat 1 NES Mega Man game
2. Beat 3 NES Mega Man games
3. Beat all 6 NES Mega Man games

Hardcore Mega Man NES Quest:

1. Beat all 6 NES Mega Man games in hardcore mode
2. Beat all 6 NES Mega Man games in hardcore mode and in less than 6 hours total
3. Beat all 6 NES Mega Man games in hardcore mode and in less than 3 hours total

(those are very much guesses i'm not good enough to play classic Mega Man so idk how long they take to beat lol)

These could also work well additively, as in the unlikely event that a new major glitch is discovered and major time saved, a new tier could be added like less than 2 hours after the fact and the badges get glitchier and have vague hints towards the new skips I'm getting really out of scope for a technical proposal-

Essentially, I think this would be a really good way to add to the tools Quest developers would have, and could make for some very unique ideas especially for older games with very established challenges and speedrun communities. This could also promote more leaderboards with unique restrictions and tracking, especially if you use them more as a way to scrape and record data about a user's play session without affecting a set rather than a direct competition between users. (and they are much less prominent on game pages than achievements so it wouldn't clutter things too much I think)

All that being said, even as they are proposed right now I think they would be an awesome addition to RA and I really appreciate you taking the time to hear my idea. Keep up the good work!

[Jurbadis]

The GameBeaten objective with multiple targetIds is a great idea to give players free choice on which version of a game to beat. However, with the current proposal, it restricts possible options to standalone releases while leaving out releases within game collections. Examples like Final Fantasy I & II: Dawn of Souls, The Legend of Zelda: Collector's Edition and the various Sonic collections come to mind. This is because currently those collections usually require earning all progression achievements on all games in the collection to award a Beaten status.
I think it would be valuable to also give players the option to beat a game within a collection to complete said objective within a quest.

I can think of two possible solutions:

1. Allow targetIds to also include specific achievement ids (or possibly put them in a separate list), so that the win conditions for a given game within a collection can be included as options. This does create a limitation though, in that regular progression achievements would be ignored, which in turn could prove challenging for quest designers when trying to choose one particular win condition for games which have multiple (Example: a game that allows multiple characters for a given playthrough and each of those characters has a separate win condition).
2. Expand the Beaten Status framework to allow games within collections to be beaten independently of each other by having separate progression and win condition achievements for each of the games included therein. I understand that this would be a sizeable change that would have ramifications well beyond the scope of this RFC, but it does sound like the more robust long-term solution.

[Jamiras]

Achievement grouping: #745

[suspect15]

Currently, I don't see much use for beaten status within compilation games outside of quests, but grouping does seem to have potential utility from a QA perspective. With it, we can improve description writing by allowing achievements to be grouped by restriction and allow safe removal of repetitive restrictions from individual achievement descriptions - such as grouping achievements by required difficulty, etc.

It can also significantly help organize sets like: https://retroachievements.org/game/14512 and https://retroachievements.org/game/3169 where the game itself is broken into several different independent sections/campaign that each have unique achievements. Instead of having 200-300 achievements listed on a page at once, they could be grouped accordingly.

While cosmetic in nature, I do think there's real value in grouping.

There would need to be grouping guidance put out before this tool was available for developers to use as I have concerns that some creative liberties might be taken that could harm overall library standardization and make perusing various game pages an inconsistent experience.

[wescopeland]

#4260 implements achievement grouping.

[rholliday]

@wescopeland That was quick work! I like the look. Also love the icon autoselection. Can editors manually pick one if they choose also?

[wescopeland]

For the time being, it will use an automated fallback. We may make it manually selectable though if that turns out to indeed be an in-demand feature.

[Jayvee202]

Not sure if such thing would be feasible or hard to implement, but besides all the straightforward ideas like beating entire series and etc, how about some more diverse Quests in terms of group of cheevos of the same kind spread across games? Examples:

Master of the Robots: Completed no damage for all Mega Man robot masters in the mainline games; (Gathering all cheevos of that kind for each game)
Default guy: Completed all Contra mainline games without using special weapons. (Gathering all default-gun cheevos from each game)
Speedrunner: A curated list of speedrun cheevos across different games chosen by the quest dev.

and so on... there would be tons of options and ideas, obviously the list would be curated and decided by the ones developing those quests, so no pression with stuff about "who determines this or that", we would just have cool lists based on common themes when it makes sense, and new ones added if applicable.

I think these kind of stuff would instigate users more and more to put value into individual cheevos rather than full masteries like it happens today, and more dev work is enjoyed since we are attracting people that would not mastery those games, but would take on specific challenges like these, or like the name says, quests.

[Kaiserlucas]

One feature of event achievements that I find very helpful, is the ability to set decorators to give additional context to players. We're getting a lot of use out of this feature, with it finding an application in the majority of auto-tracked events nowadays.
Some of our our events that have many similarities to quests, such as RAD or memorial events (simple rules, auto-tracking, instantly Evergreen), also frequently make use of this feature to add flavor and let players know what the reason for inclusion for each of the tasks is.

Given that many quests might follow a similar structure to memorial events or RAD, by being a curated and guided experience through a selection of games, I think that having a similar option to assign a label to objectives might be a nice optional feature to have. Like a quest to beat best selling games for each year, or a quest to accomplish a task / beat a game related to every character in the Smash Bros roster.

This could also help with making objectives containing multiple targetIDs more legible at a glance. For instance, "Beat any version of Super Mario Bros. 2" is instantly understandable to people, even if they are not aware that Super Mario Advance is a remake of SMB2. If we simply listed both games, this may not be as immediately apparent to players less familiar with the series.

[Hexadigital]

I think this looks good, the only thing I have a question about is the Quest's mode parameter - I feel like setting/storing that is unnecessary, given that it can be determined by the quest requirements (if there's any leaderboard requirement, it is hardcore only).

Leaving this requirement out of the spec, and having it inferred by the quest contents, would also help the system expand to future applications - for example, both Devember and the new Community Events allow for softcore players, even if those softcore players are unlocking hardcore event badges - so a quest like "earn 3 event badges" would be achievable by softcore players and erroneously marked as exclusive to hardcore players.

This also eliminates potential confusion if a quest like "beat all of the classic Mega Man games" is created with a hardcore requirement but "beat all of the Pokemon games" isn't, unless there's some reason that quests should be able to explicitly require hardcore outside of hardcore-only features.

[christianlegge]

I understand how much has to be different on the backend here as compared to the current state of auto-tracked Events, but solely from a user perspective, I think this is a confusing distinction.

New users will not intuitively understand the difference between Quests and Events, and per the current proposal, it cannot be explained simply. Quests are not time-gated, unlike Events, except for Evergreen events which also aren't. But Quests are auto-tracked, unlike some Events, but some Events also are, but not when they include things like leaderboard scores, which Quests can do. I see the comparison table in the proposal and it's understandable to someone who's familiar with the site as it is, but I don't think it translates well to the new user experience at all; new users are already quite confused about how Events work with the time gating, evergreen and prior credit, and things like that. This wouldn't help.

I would suggest one of two things, at least for the user-facing side:

1. Make this distinction dependent on time gating. Events are strictly time-gated, Quests are strictly not. Current evergreen events are renamed Quests. This is relatively easy to understand, and is more in line with how these terms are used in other gaming circles and even everyday speech. "Event" already implies a limited time. OR
2. Build this off of the current Event system entirely. Quests are just a new type of evergreen Event. The badges live in the same userbox, the "quest" listings are in the current evergreen event forum, etc. The term "Quest" is used in the title of the event only, if at all, and is not presented as a separate type of challenge. Many evergreen events are already quite long-term, difficult projects, so they would fit in quite well.

All of this may just come down to presentation and be up to the event team more than the implementation, but I think it's still worth discussing at this stage.

[Kaiserlucas]

My personal view is that Evergreen and Quests, while they have some overlap, are fundamentally meant to be fairly different concepts. I can see where you are coming from though, and the earlier we think about the differences between Evergreen and Quests and make them explicit, the better. I would conceptualize the difference like this if I had to explain it to a user:

---

Events are time limited chances to complete tasks for a badge, and Evergreen Events are extensions of said events. They are not time limited, but still strongly connected to an existing event in terms of mechanics and content.

Tasks in events are typically less thematically coherent, as they are oftentimes either semi-random (e.g. events like Achievement of the Week, RARoulette, Leaderboard of the Month) or largely driven by event mechanics and balancing/variety concerns (e.g. Challenge League, Unwanted, Bounty Hunters)

Quests in comparison differentiate themselves by being highly curated longer term goals, that were designed to be permanent from the ground up. Because they are standalone and not constrained by live-event structure, they can support concepts that wouldn’t work well as time-limited Events (such as Franchise Quests for beating all Final Fantasy games), but that players would still enjoy tracking and progressing toward over time. I think these kinds of goals are fundamentally quite different in style to what a current Evergreen event is.

I would understand these much more as "meta-achievements" for Retroachievements as a website, or very strongly thematically curated experiences that are simply too specific to work as events in terms of variety. As such, I think it makes sense to separate them to their own framework on the site, away from the events framework.

---

Merging the concepts of Evergreen and Quest would dilute the strong coupling that Events and Evergreen Events are meant to have. I don't think we should split the regular and Evergreen versions of events to live in different systems on the site, nor do I think should Quests that serve more as meta-achievements be added into the existing event framework, by living under the Evergreen umbrella. Separating them seems conceptually justifiable based on my current understanding of what these frameworks intend to offer.

That said, I agree that these sorts of design questions regarding the conceptual differences between Evergreen and Quests need to be made more explicit once a Quest team is established.

For instance, we already have one event format in particular, that is admittedly straddling the line between Evergreen and Quest according to my own definition of Quests; those being Memorial Events. They are instantly Evergreen, autotracked with simple rules, and highly curated thematic experiences. In a world where the Quest system had already existed at the time Memorial Events were introduced, I could see them having been added as Quests instead of being labelled as an Evergreen event format.

It and "On the Horizon" are the only Evergreen concepts we have that never had a live component of any kind. Should things like these be Quests rather than Events in the future, with Evergreen being purely restricted to extending live events? Or is there some room in which a themed set of challenges can still be an Evergreen event despite not having had a live component?

This is something that I think we will need to figure out as the feature develops more. Right now, there are still many different avenues that Quest design guidelines could take once that team is established.

[Kinglink]

Some thoughts on this.

1. We have developer ids, but is there a way to just say "Any game in the horror genre" or "any game that is about historical fiction" I guess those are technically hubs, so they're covered.

I'm thinking of CL 2024, and wondering could we automate all of it into a quest. Not to actually convert that specific event into a quest (or maybe we should?) , but more considering do we have the functionality here to do so?

But beyond that, could we also do "Beat X games released in X year" or "X month"?

2. Also do we have a block on the Hubs? We have excluded game tags (Which is a start) but we also should expect that we need to block "Free game point hub" This might be done across the entire quests, rather than just specific lines.

3. In addition we might also want to block quick beats/mastery. Maybe have it configurable, so for one quest it might be "All games must be 20 minutes average beat to be counted" where as another might be 2 hour Plus games.

4. Prior mastery... I know you talk about it above but we should have the ability to say it's allowed or not. "Beat all Mega Man games"... well I already did that, so can I not get that achievement? do I have to reset one achievement, get it again just so I can earn it? Some Quests should allow prior credit, some should not.

(Also do we have a way to mark someone as having done something, let's say we say "Beat 5 new X mega man games" but I've beat all but 3 of them and the quest is to beat 5 of them... Admin probably should have the ability to give me credit for that one step)

5. Finally Count-based types. What about Achievements? Unlock X achievements from X platform, or unlock X achievements from X type of games. Might be something to consider.

PS. If there's a quest team I'd be interested in assisting with this.