sganggs
c1bf395207
- op-shining.js 闪灵 (医师): S1 信条; S2 自动掩护 — the next heal gives its target a 屏障 of atk_scale × ATK for duration s (every damage type) and DEF +def while one of her barriers holds (PRTS 备注: barriers add up, own timers, older first, the DEF bonus does not stack); S3 教条力场 — allies in range DEF +def %; T1 黑恶魔的庇护 (allies in range DEF +60; PHY-Y stage 3: +100, 地面 units +40 more); T2 法典 (ASPD +10; PHY-X stage 3: +15, ATK +25 % with S2, SP +0.6/s with S3); PHY-Y heals on 地面 units ×1.15, PHY-X heals on allies below 50 % ×1.15. - op-cgbird.js 夜莺 (群愈师): S1 治疗强化·γ型; S2 法术护盾 — every target of the next heal gets an arts-only 屏障 (shieldType 'arts') and RES +flat; S3 圣域 — range y-4 (data ACTIVE_RANGE), allies in it RES ×(1 + v) and arts dodge; T1 白恶魔的庇护 (RES +15; RIN-X stage 3: healing received ×1.05); RIN-X range = its module grid, RIN-Y 4 heals; T2 幻影: its own talent (30 % / RIN-Y stage 3 40 % physical dodge, 3 % max HP 流失 per second), her stock (+2 / RIN-Y stage 3 +3 per deployment, at most 3 — PRTS 备注), a fallen board 幻影 back on its tile after its redeploy time using one and its DP. - op-saga.js 嵯峨 (尖兵): S1 冲锋号令·γ型 (SP_FULL); S2 除恶 — +4 DP, up to 6 ground enemies of the x-6 cross (重伤 ones included), the ones still 重伤 0.7 s later killed by her (PRTS 备注); S3 怒目 — +1 DP/s (20), +0.5 s interval, range +1, every blocked enemy, one more attack on a target below half HP; T1 劝善 — her damage is never lethal, an enemy at ≤ 1 HP becomes 重伤 (PRTS 术语释义: move −80 %, 禁用近战, 禁疗, no regeneration, a forced 无来源 death 10 s later, none while 消失), its killer +2 SP, she never selects a 重伤 enemy (profile skipEnemy); SOL-X stage 3 +15 % damage below half HP; T2 清明 (once per deployment below 40 %: 70 % physical dodge, 生命回复速度 5 % / SOL-Y stage 3 6.5 % — its blackboard — for 15 / 18 s); SOL-X block ATK / DEF +8 %; SOL-Y's 首次部署 cost cut has no battle effect. - kits/index.js OPERATOR_KIT_FILES: the three files, one line each. Golden (diy only; every other family unchanged): diy-003…008 are new — 闪灵, 夜莺 and 嵯峨 in every form × module × skill at tiers 5 and 6; the prototype battles moved from diy-003…006 to diy-009…012 (same pieces; their seed follows the index); diy-001 / 002 (推进之王) unchanged. Tests: test/content/op_shining.test.js (9), op_cgbird.test.js (10), op_saga.test.js (15).
Golden results
The simulation is deterministic: the same seed and inputs give the same battle and the same match, bit for bit. These files record the exact outcome of a fixed corpus of seeded scenarios, so a change that alters gameplay — even one meant to be a pure refactor that only reorders random draws, hook order or iteration order — fails loudly instead of slipping through.
tools/golden.mjsbuilds the corpus fromdata/*.json(fixed order, fixed seeds) and reduces every scenario to a digest. Its header documents the families and the digest fields.test/golden/<family>.jsonhold the digests (roster,bonds,fields,matches,standins,diy).test/golden.test.jsrecomputes them and compares. On a mismatch it prints the scenario, the field and old → new.
The corpus
| family | what runs |
|---|---|
roster |
49 battles: every visible chess record (normal and elite) with every selectable skill and module (DESIGN §16), 12 operators per battle on a real stage (all 11 in turn) against the round's real wave three times over, every non-leader enemy kind of data/enemies.json as extra spawns (half of them bounties), placeable summons on the board, every equipment item, band, battle-side 机变 card and stage map card in turn, bonds from the board |
bonds |
46 battles: every bond at its activation threshold (1 layer) and at its top tier (999 layers) |
fields |
22 battles: every Final Assault / Hidden Core leader on a pair and a solo template (shared pool, 200 s cap) and the 联防 field with 1 and 2 helpers on its own map (carried HP / SP, a knocked-out operator, two leakers' enemies) |
matches |
17 matches to the end in virtual time: 16 bot-only (solo 标准 / 险境 / 绝境 / 终极 × 2 seeds, co-op 2 / 3 / 4, one server-run combat match, two runs boosted to the Hidden Core) and one co-op match whose human seat (AI 托管, offline) does not own 7 NORMAL chess — they fight as their 补位 stand-ins (its digest lists them per round, standIns) |
standins |
10 battles: every NORMAL chess record (normal and elite, 110) fielded as its 补位 stand-in (standIn: true: the stand-in's body, backup skill / module and kit — all 17 stand-ins, every skill a chess names for them), 12 per battle by strength band, laid out by the stand-in's position on a real stage, against the round's real wave three times over plus 8 ground enemy kinds (melee stand-ins always meet an enemy), an item each, bonds from the board |
diy |
6 battles of 自选 pieces (a DIY slot with its diy pick, shared/diy.js): every owned 6★ with an operator kit (kits/index.js OPERATOR_KITS — 推进之王 so far) in each form of tiers 5 and 6 (normal; elite with no module and with each module) under each skill, then every prototype pick with a kit at its locked selection, normal and elite, 12 per battle against the round's real wave; a new operator kit adds its scenarios |
Battles go through the production BattleSpec path (server/sim/spec.js, as browsers and the server's headless fields
run them); matches construct Match directly with a VirtualScheduler. Every option is explicit, so a change to a
test-harness default never moves a digest.
What a digest ignores on purpose (it does not affect gameplay): object key order, engine unit ids (snapshot ids are renumbered by first appearance, units are named by board uid or def id), board piece uids, the order of client events within a tick (they are counted, not hashed) and wall-clock time. Damage / healing sums are rounded to integers and HP to 2 decimals.
npm test runs the fast subset (the scenarios marked "fast": true: every chess record with its default loadout,
every stage and every non-leader enemy kind, every bond at its top tier, six fields, six matches, the five stand-in
battles of the normal records, the first 自选 battle of the operator kits and of the prototypes — 61 of the 150). GOLDEN_FULL=1 checks everything.
Workflow
GOLDEN_FULL=1 node --test test/golden.test.js # the whole corpus (≈ 20 s with 4 worker threads)
node --test test/golden.test.js # the fast subset
npm run golden # the same comparison from the tool (all families, a short report)
npm run golden:update # recompute and rewrite test/golden/*.json
node tools/golden.mjs --twice # determinism: the corpus twice in one process, the second pass reversed
- A refactor commit must never change these files. Run
GOLDEN_FULL=1 node --test test/golden.test.jsbefore committing it. If a digest moves, the refactor changed behaviour: find out why (the first differing value ofsnapssays when two runs parted, in 10-game-second steps) instead of updating the files. - An intended gameplay change (a fix, new content, a data rebuild): run
npm run golden:updateand commit the changed files together with the change, saying in the commit message which scenarios moved and why. - Reviewing the diff: every scenario is a block of its own and every unit / enemy / round is one line, so a diff
shows which scenarios moved and which values changed. A change confined to the scenarios that contain the touched
operator, enemy or rule is expected; a change everywhere (every
rngDraws, everysnaps) means something global moved — the RNG draw order, the tick order, a shared rule. - Adding to the corpus (a new family, more scenarios, a new digest field) changes the files by design: do it in a commit of its own, never together with a refactor.
- A new engine hook, event or chess record does not change the digests of the existing scenarios by itself — the
hook list is frozen in the tool and the corpus is regenerated only on
golden:update— but new data records do join the corpus there (the roster family enumeratesdata/chess.json).