joywaygamess/spellforge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
200 Commits 1 Branch 0 Tags
8680e8c0ef73298d722b03c796b3619808832048
Commit Graph
11 Commits
Author SHA1 Message Date
joywayerandClaude Opus 5 0b631a475f docs(shop): 货架 C Task 6 运行时验收 + 权威文档补录 + 计划回填 
17 条验收标准 + Task 3 遗留的回读顺序风险全部运行时实测通过（FAILS=0），
无代码改动。发现简报三处脚本不可用并替换/补充：Step 1 阳性对照改用
add_modifier 未知属性守卫；新增 Step 5b 补前序评审「磁盘往返未独立复核」；
Step 6/7 原脚本经排查为空断言，改用真实红/绿对照场景。

numerical_design.md §1.1/§1.2 补录属性购买消耗与 cast_delay_mod 的 soft
约束说明；路线图 E3 第 2 项勾除完成。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-03 12:19:09 +08:00
joywayerandClaude Opus 5 84c10725e2 docs: 订正 wand_fast 饱和点 0.05→0.0667；roadmap 关闭已决定项并澄清移速表述 
【订正】wand_fast(0.25s) 的饱和点按公式 (1/60)/0.25 = 0.0667，不是 0.05。
numerical_design:21 的标注与它自己上一句的公式直接矛盾，spec/plan 另有三处同源
错误标注——均派生自一句口头转述，实测表里记的 0.0667 一直是对的。

结论也随之改对，不只是改数字：hard=0.05 使 wand_basic(饱和 0.0333) 与
circuit_fork(0.0278) 无无效区间，但 wand_fast 仍剩 [0.05, 0.0667) 这段买不到东西
（较原 hard:0.01 的 6.7 倍缩至 1.33 倍）。仍取 0.05 的理由：饱和点 = (1/60)/法杖
基准间隔，随杖而异，不存在对所有杖都最优的单一 hard——取 0.0667 让 wand_fast 干净
会使另两把杖够不到自己的饱和点，反而制造新的不可达区间。hard 数值不变。

顺带说明实测表里 wand_fast@0.0667 读到 2 帧的原因：采样点比真实边界 1/15 高 3.3e-5
(T 上高 8.3e-6 s)，再叠加整帧倍数多花一帧的浮点余量效应，故实际 1 帧上界略低于
0.0667。数据没错，是标签错了。

【roadmap】E3-① 下的 cast_delay_mod 条目仍记为「待人定」并指向两个选项，而该决定
已在 ba7c885 关闭——roadmap 是查「E3 还剩什么」的索引，留着会把已关闭的决定重新打开。
改为已处理，并注明彻底消除需让 hard 逐杖化（挪进 cores.json），属独立立项。

【roadmap】「实测 200→300 px/s」读起来像发版移速由 200 改成 300，与同批改动里
numerical_design 的订正（发版是 200，300 是从未被读过的纸面值）直接冲突。改写为
「发版基准仍是 200；实测手段是临时挂 +50% 加成使生效值变 300」。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-31 13:36:53 +08:00
joywayerandClaude Opus 5 ba7c885291 fix(attr): cast_delay_mod 硬上限 0.01 → 0.05，消掉两把主力杖的射速无效区间 
_handle_auto_cast 用 if 而非 while，每物理帧至多施法一次，故本属性存在饱和点
= (1/60) / 法杖基准间隔：wand_basic(0.5s) ≈ 0.033、wand_fast(0.25s) ≈ 0.05。
原 hard: 0.01 在两把主力杖上都深深落在饱和区内——玩家把 cast_delay_mod 从
0.033 一路买到 0.01，射速一点没变，属"承诺了循环交付不了的东西"。

取 0.05 使 wand_fast 恰在硬上限处饱和、wand_basic 全程无无效区间。
边界实测（同一套 _physics_process 帧距扫描）：wand_fast@0.05 = 1 帧/次(60/s)、
wand_basic@0.05 = 2 帧/次(30/s)、请求 0.01 被 maxf(hard,…) 钳回 0.05 后帧距不变、
soft(0.1) 对照仍 3 帧/次(20/s)、circuit_fork@0.05 = 2 帧/次。

未加任何代码钳制：下限已由 attributes.json + AttributeFormula 的 maxf(hard,…)
强制，代码里再加一个会形成重复权威，设计师调 hard 时立刻脱同步。

spec 新增 §2.2b 收录完整实测数据集（饱和点公式与三把杖的值、soft→hard 是台阶
而非曲线、周期恒为 ceil(T×60) 且整帧倍数多花一帧故实际射速恒 ≤ 名义值）——
结论易得而数据难得，故一并留档。circuit_fork 的饱和点 0.0278 标注为公式推导。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-31 13:18:46 +08:00
joywayerandClaude Opus 5 1aeae19187 docs: 订正 move_speed 300→200 与 cpu_limit「从不读」告警；路线图 E3-① 勾除并订正现状 
move_speed 300 从未被任何代码读取，是纸面孤值；200 自 S0 沿用并已围绕它调校
20 波内容与 Boss 弹幕密度，以既成事实为准。cpu_limit 行的「代码硬编码 40×5、
从不读 cpu_limit」告警随本次接线失效，改记生效值构成（玩家基准 0 + 法杖 3–8）
与 hard(50) 作用于加总后的总值；基准值一并由 5 改为 0，否则重蹈 move_speed 的
「纸面值与实现长期脱节」。

路线图 E3 现状原写「player_stats.gd 有 resistance 等占位属性（4/5 stats 未接线）」
与事实不符——权威属性表是 11 个，armor/resistance 根本不在表内，是实现先于设计的
孤儿字段。E3-① 勾除并标注实际范围（只做框架 + 三条死数据），attunement_×4 /
luck / recharge_speed_mod 三项延后各附理由；顺带记 cast_delay_mod 的饱和区待人定。
E1 现状里「玩家侧抗性仍占位」一句同因失效，一并订正。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-31 12:54:22 +08:00
joywayerandClaude Opus 5 e651072b9b docs: 订正归航手感论证的运动学错误 + 记录定价越权与用户决策 
【spec §2.0】原论证只算转弯半径就断言「急转的敌人能甩掉」，从未拿它对照敌人
实际速度 —— 明写此错，并补上缺的那一步运动学核算：跟踪横向速度 v、距离 d 的
目标所需角速度 ω≈v/d，故跟丢条件是 d < v/ω_max（近距离判据）。代入实际数值
(敌 45~140 px/s、弹 ~350 px/s) 重列强度表，标出发版值 1.5、给出各档对最快敌人
的跟丢距离。说明中远距离不是区分点(1.5 与 3.0 余量分别近 5 倍/10 倍，都能可靠
命中)，真实失手方式是【近距离过冲】——目标坐进转弯圈内、几何上无法收敛，
而这正是 1.5 想要的手感。叠加表按 1.5 递增重列，堆到必中仍是合法 build 收益。

【spec §2.8】承认原「与 pierce/bounce 对齐」的论证绕过了权威：那两个词条本身
就不在定价表里，拿两个未定价条目互相对齐等于自建平行标准。而
numerical_design.md 确实给 homing 定过价(Tier 3 / Mana 40)，且该表是活的权威——
其 Mana 列与 spells.json 每个已实现条目精确吻合，仅 homing 一行偏离。记录用户
决策及其取舍：这个词条能卖同族价，是因为它被调到了同族强度。

【numerical_design.md】homing 行按 P6-N2/N25 同样风格标注：原行删除线保留可
追溯(不抹掉「曾判定为 Tier 3」这个记录)，表下补注说明 Homing Force 语义已废
(实现为最大转向角速度 rad/s，与 5.0 不同量纲不可比)、Mana 40 被同族标准取代、
实际发版 homing 1.5 / Mana 8 / 商店 18，并链接 spec。

【architecture_design.md】§4.2 冷数据注释的示例值 3.0 → 1.5（含转弯半径 233px）。

【plan】Task 1 Step 5/6 的 JSON 与断言期望值同步为 1.5；验收⑧(Step 6/6b)重跑
并更新为 folded=3.00 / e2e_2stack=3.000 / e2e_1stack=1.500；Step 8b 补设计器
往返与 SpinBox 格点确认输出。新增顶部醒目段落说明【机制测试①②③④⑦里的 3.0
是测试局部值、与发版值刻意解耦】——平衡调整不应导致机制测试失败，不要为了
数字一致去改它们；唯一应随发版值走的是⑧。Step 7 注明平衡调整不影响性能守卫
(强度只进转向数学，不参与决定 query_circle 频率的任何分支)，未重跑。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-07-30 18:13:58 +08:00
joywayer a3ab2aa6cd docs(mana): §4.1/§5.A 现状更新为 Mana 完整化已实现 2026-07-21 15:27:08 +08:00
joywayerandClaude Opus 4.8 eec9d52ece docs(meta): game_design §7 现状更新为碎片+解锁树已实现(MVP) 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-21 11:54:01 +08:00
joywayer 06e993bea7 docs(mana): Mana 现状 callout 更新为已实现(MVP) 2026-07-20 16:34:58 +08:00
joywayerandClaude Opus 4.8 5e3d80ad85 docs: 记录 3 个潜在 bug 的修复状态（对齐 dc05eea） 
- 审计报告 D 节 + G.2 表标注 D1/D2/D5 已修复（待运行时验收），修正 D1
  修复方案为「单选枚举 + ==」（复核发现设计器 core_tab 以下标写入 feature_tags，
  不宜改 2 的幂位标志）
- architecture_design ADR-R5-N2 与 core_wand §1 的现状 callout 同步更新为已修复

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-20 14:53:27 +08:00
joywayerandClaude Opus 4.8 ad2f4c0bc6 docs: 整理文档目录并对齐代码现状 
- 将开发过程/归档文档迁至 docs_dev/（development_plan、certification_checklist、
  已废弃的 Cocos 架构草案 archived_cocos_architecture_draft），并修正全部跨引用
- 新增根 README.md（项目介绍，暂定名 Spellforge）与 docs_dev/README.md 索引
- 新增 docs_dev/doc_code_audit_2026-07-20.md：文档 vs 代码交叉审计报告（经 6
  路对抗性复核，零证伪），含「代码更优 / 文档更优 / 中性」判定汇总
- 在 docs/ 各设计·技术·机制文档就地加「实现现状 (2026-07-20)」callout：
  追认代码更优实现（纯 JSON 数据驱动、SpatialGrid-only 碰撞、MultiMesh 单档、
  存档选最新槽等），订正陈旧/矛盾内容（.tres→JSON、Boss HP/阈值/波次、EventID、
  StatusManager.apply 签名等），标记未实现功能（C# 热路径、Mana、元进展、
  Boss 阶段/抗性、Tutorial、轨迹/连锁/催化等）与 latent bug（CoreFeatureTag 位运算、
  pierce 空操作、MAX_OPS 不读 cpu_limit）

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-07-20 14:35:55 +08:00
joywayer 7bcc0026e0 初次提交 2026-07-20 10:56:52 +08:00