拾响者

从战斗原型到完整游戏循环

2026 年 9 月 24 日至 10 月 28 日，项目从 Phaser 2D 战斗原型，演进为面向微信小游戏的横屏像素风 3D 动作游戏。关键工作并非只增加内容，而是反复确定不同系统各自服务的玩家决策。

主线让玩家在出征前研究武器与铭卡，检验预设 Build；覆响禁区通过局内升级与进化形成临场构筑，再以撤离兑现收益。永久武器培养、铭卡收藏与天赋则提供下一次出征的目标。早期挂机和逐房随机 Buff 已随规则演进调整，不能与当前玩法并列计算。

案例一：先校准测量方法，再谈战斗平衡

问题： 自动控制过于稳定，会低估近战风险、夸大远程命中率。只看平均 DPS，无法判断普通玩家是否真的能打出预期克制。

决策： 推动测试模型加入有限反应、瞄准误差、停步、后撤、追击与身体避让，并分别统计射击连接与弹丸命中。

历史验证： r68 共覆盖 2,160 场 Boss 和 7,200 场精英模拟。推荐克制 Boss 的成功击杀中位时间由 87.65 秒变为 58.28 秒，时长配对达标由 8/60 变为 30/60。

这些数字来自历史模拟，不是人类遥测。中位时间只统计胜场；时长达标也不等于克制优势全部成立，报告仍保留未通过组合。

案例二：把视觉升级变成可维护的资产流程

问题： 程序化块面模型适合搭建原型，但难以持续精修建筑、角色比例与攻击动作。

处理： 营地、角色与武器迁入 Blender，保留可编辑源文件，通过 GLB 导出统一脚底原点、尺寸、朝向、动画名与挂点。运行时负责实例化、材质适配和状态驱动；场景清晰度与像素 HUD 分别控制。

取舍： 同时审查造型、动画契约和运行成本。r105 记录约 53,261 三角形与约 2.38 MB 营地 GLB，这是版本成本快照，手机性能还需真机验证。

案例三：让摇杆方向与屏幕反馈一致

问题： 斜角相机使右摇杆方向与屏幕弹道产生系统偏差，界面关闭还可能穿透为开火。

处理： 通过地面投影逆变换修正瞄准映射，同时统一菜单安全区、44px 触区、关闭与暂停恢复规则，分别处理多指、取消及后台切换。

历史验证： r182 在两种模式、八方向、三种横屏尺寸下完成 48 次触控检查，约 8° 的方向偏差收敛到低于 0.4°。这是模拟触控结果，真机手感仍待复验。

案例四：让战斗收益可靠地回到营地

问题： 网络响应丢失可能造成重复结算，客户端快照也可能伪造资产或清房状态；新手引导恢复失败会阻断整个循环。

处理： 引入持久化待提交操作、幂等结算与版本检查。r179 为主线记录固定步长输入，由服务端从已确认检查点回放，再校验候选状态。r180 修复引导恢复时动作 ID 与营地入口不一致的问题，保留原有进度与资源。

交付边界： 2026 年 10 月 23 日 r179 有测试云部署及 0.1.179 上传记录；后续商店和反馈代码的完成，不代表最新云功能已经启用。弱网、双设备与真实云业务仍需补验。

我的贡献与当前完成度

我主导玩法方向、系统取舍、原型评审与实际试玩反馈，AI 工具参与方案拆解、实现、资产处理、自动化验证及文档。作品展示的是设计判断与问题闭环，以及把方案推进为可运行版本的过程。

目前已形成可玩版本与持续迭代的交付流程，处于受邀测试准备阶段。微信体验资格及最新整包尚待确认，因此本页以案例与真实运行截图展示。历史测试规模不等于本次重新验收，也没有支持留存、收入或全机型性能结论的用户数据。

资料依据：2026-10-28 项目开发复盘，交叉核对 r68 战斗平衡、r105 营地资产、r179 云结算与部署、r180 引导恢复、r182 触控映射及 r197 交付报告。截图来自项目历史实际运行包。