成就与图鉴

Definition

成就是「达成即发奖的进度对象」：定义给出判定条件（什么事件、几次、什么组合），玩家侧持有进度计数，条件满足那一刻服务端自动发奖，没有接取与交付。图鉴把同一套机制换成展示语义：条目是「见过/拥有过/击败过」的事件集合，收集度是集合覆盖率，收集度本身可以再挂属性加成或外观奖励。两者的存储口径都是「只增不减的事件集合」。

Problem

成就的坑按出现顺序：

进度不幂等：事件重复投递让计数虚高，或服务重启把计数清零——「击杀 1000 次」的成就凭空完成或永远差一次。
事件源发散：战斗、经济、社交各自埋事件，格式不一，成就层写成三条订阅管道；新增一个成就类型就要再接一条。
跨玩法事件归属：PVP 击杀与 PVE 击杀算不算同一个「击杀」成就？事件不带头衔标签，成就判定只能特判。
发奖与对账脱节：达成瞬间发奖走的是调用方直接扣加，没有凭证；玩家说没收到，运营无凭可查。

Algorithm

判定条件表：与任务同构，语义不同

成就定义同样是静态表，运行态只有计数：

text

achievement_def:
  id:          a-2001
  criteria:    [ {type: kill, key: any, need: 1000},
                 {type: reach_level, need: 60} ]   # 多条为「与」，单条即单条件
  rewards:     [ {item: title, n: 1}, {points: 10} ]
  hidden:      false        # 隐藏成就：达成前不展示条件

achievement_progress:
  player:      u1001
  achievement: a-2001
  counters:    { kill:any: 640 }
  unlocked:    false
  unlocked_at: null

与任务的差别三处：没有 prereq 与接取态（全部从 locked 直接可用）、计数只增不减、unlocked 即终态且发奖自动完成。

只增计数器：幂等与断档

事件带 event_id，进度层按 (achievement, criteria, event_id) 去重——网络重发不多计
计数写入先于发奖判定：先落计数再查是否达标，崩溃恢复后重算判定即可，不会漏发（达标是计数的纯函数）
不做「负进度」：成就没有失败态，「中断连击重计」这类需求用新事件类型（combo_broken）而非扣减计数

跨玩法事件源：标签而非分支

事件统一成 {player, type, key, n, tags}，成就条件按标签过滤：

事件	tags	用途
击杀	`pvp` / `pve`	「总击杀」不筛、「竞技击杀」筛 pvp
通关	`mode:ranked` / `mode:casual`	排位胜场与休闲胜场分开计
消费	`currency:paid` / `currency:free`	付费口径与免费口径分开计

一条订阅管道，按条件里的 tags 过滤——新增玩法只要按既有 tags 发事件，成就层零改动。

发奖：达成即提交，凭证可查

达成判定的那一刻生成奖励凭证 (player, achievement_id, rewards, unlocked_at)，走结算的幂等落库路径； Steam、Xbox 这类平台成就走平台侧上报，站内成就走自己的流水——两套别混账。

图鉴：集合覆盖率与解锁事件

图鉴条目 = 「某个事件发生过一次」的集合成员：

存储是集合而非计数：{player, codex_id, entries: set(entry_key)}，重复事件幂等由集合语义天然保证
收集度 = 已有成员数 / 全集数，实时可算或定时快照
收集度加成（收集满一档给属性）是「集合状态 → 属性重算」的订阅关系，属性侧口径见战斗数值与伤害公式族
图鉴的展示语义（图鉴页、未收集剪影）是客户端表现，服务端只保证集合的权威性

Used By

TrinityCore（开源 MMORPG 服务端套件，公开仓库与 wiki）：成就与达成条件同样做成数据表加判定条件，与任务共用事件推进机制——本页「判定条件表」的直接参照。具体表结构以项目公开文档为准。
WoW（商业 MMO）：成就系统（2008 年起）把探索、副本、PVP、收集统一进同一套成就框架并给成就点数，是「跨玩法事件源统一」的商业参照。
炉石传说（商业卡牌）：卡牌收藏与卡背奖励作为「收集进度驱动奖励」的参照；收集语义（拥有过即解锁）与本页图鉴口径一致。
阴阳师（商业手游）：图鉴收集度挂属性加成的公开设计，作为「集合状态驱动数值」的参照。

关系链：判定条件表 → 只增计数 → 事件源标签 → 自动发奖 → 图鉴集合。逐段回答「为什么需要下一个」：

条件定了才谈计数——计数是条件的运行态。
计数幂等了才敢只增——只增不减的前提是重复事件不多计。
计数准了才分事件源——标签让一条管道服务全部玩法。
事件源统一了才自动发奖——达成是计数的纯函数，发奖才能无人值守。
发奖闭环了才有图鉴——图鉴把同一套机制换成展示与收集语义。

上游：任务系统（共用的进度模型与事件格式）；下游：结算（发奖凭证）、掉落与概率设计（收集奖励的数值侧）、排行榜（成就点数可入榜但口径要分开）。

Reference

本页为机制归纳；TrinityCore 成就表结构以其公开仓库与 wiki 为准，不臆造表名。
平台成就口径（Steam/Xbox）以各自开发者文档为准；站内成就与平台成就的账目分离是本页口径，非平台要求。
术语对照：Achievement（成就）、Criteria（判定条件）、Unlock（解锁）、Collection（图鉴/收藏）、Codex（图鉴条目集）。

成就与图鉴 ​

Category ​

Definition ​

Problem ​

Algorithm ​

判定条件表：与任务同构，语义不同 ​

只增计数器：幂等与断档 ​

跨玩法事件源：标签而非分支 ​

发奖：达成即提交，凭证可查 ​

图鉴：集合覆盖率与解锁事件 ​

Used By ​

Related ​

Reference ​