第三版总复习：从语法到完整游戏

从“完成四个项目后真正掌握了什么”开始

第三版 21 章的价值不在于留下四份能运行的代码，而在于建立一套可迁移的实时系统思维：状态由谁拥有，时间在哪推进，对象如何安全协作，事实何时提交，表现如何只读消费，以及资源或能力失败时系统如何降级。

Timber 的变量在 Pong 中成为类成员，在 Zombie Arena 中成为对象群状态，在 Run! 中进一步分成 GameObject、行为组件、命令、事件和快照。

让新增平台、火球或 shader 时不需要改坏主循环。

Timber：把 C++ 放入持续时间

第 1 至 5 章把变量、运算符、分支、循环、数组、函数与枚举放进 Timber。最重要的迁移是从“程序从上到下跑完”转向“状态每帧演化”。实时按键适合持续移动，事件边沿适合一次动作，声音与 GameOver 由状态变化触发。

poll events -> sample input -> update(dt) -> collide -> draw -> display

若每帧把“当前为真”当成“刚刚发生”，声音、得分和重启都会重复。

Pong：对象拥有状态，碰撞提交结果

第 6 至 7 章让 Ball 和 Bat 拥有位置、速度与行为。AABB 只回答是否接触，物理解算还要修正位置、速度和反弹方向。

Pong 提醒我们：检测是观察，解算才是状态提交。这个区别延伸到 Zombie 的伤害和 Run! 的扫掠火球。

Zombie Arena：对象群、资源与多视图

第 8 至 14 章加入 Zombie、Bullet、Pickup、horde、TextureHolder、world/HUD Views、声音、文件与波次。对象数量放大后，长期裸指针、遍历中删除和重复资源加载开始成为真实故障。

TextureHolder 证明“资源缓存”首先是所有权问题。Bullet/Pickup 证明增删对象需要提交边界。HUD 证明显示值不是真实玩法值。

World state -> GameSnapshot -> HUD text/shapes
World state -> world View    -> sprites/effects
File input  -> parse/validate -> committed high score

文件保存也采用同样思想：读取候选、完整解析、验证、再提交；临时文件写成功后才替换正式存档。

Run!：从对象到协作协议

第 15 章用 Factory 构造完整对象，用继承多态表达行为接口；第 16 章让 Player、SoundEngine 与世界通过稳定 id、事件、命令和查询协作。

与

方向不同：命令可能被拒绝，事件已经发生。Factory 只负责构造，不成为运行期万能服务。

一次完整帧的事实链

完整顺序如下：InputMapper 产生 PlayerIntent；GameObject 行为按受限 dt 计算候选运动；碰撞确认落地、伤害或命中；WorldCommand 在安全点提交；系统发布 GameEvent 与 RenderSnapshot；SoundEngine、HUD、Animator、CameraGraphics 和 Renderer 只读消费。

Intent intent = input.sample(events);
world.update(intent, fixedDt, commands, candidateEvents);
world.resolveCollisions(commands, candidateEvents);
CommitResult result = world.commit(commands, candidateEvents);
presentation.consume(result.events, result.snapshot);
renderer.draw(result.snapshot);

保证 draw 不推进 Animator、HUD 不扣血、SoundEngine 不重新检测碰撞。

Camera、Animator 与表现时间

第 17 至 19 章把 main/radar View、timer text、平台、Player controls、animation frames、交互菜单和雨效放入阶段协议。暂停时逻辑时间冻结，菜单事件和冻结快照仍工作；恢复前清输入边沿并重启帧时钟。

先预测：Paused 十秒后恢复，Player、雨滴和 elapsed 应保持不变，首帧 dt 应接近正常值。任何不符都说明某系统绕过阶段所有权。

火球与空间音频共享世界事实

第 20 章让火球命中生成 DamageCommand、FireballHit 与销毁请求。事件携带命中世界位置，SoundEngine 无需查询已销毁对象。

AudioSpace 统一把像素换成音频单位；voice 池复用时完整重置 relative、position、minimum distance、attenuation、volume 和 loop。

视差、shader 与表现降级

第 21 章由 CameraGraphics 从绝对相机中心计算层偏移，避免逐帧累计漂移。SFML 在 OpenGL context 中运行 GLSL shader，uniform 明确名称、类型、单位和更新时间。

固定回放在 shader 开关前后必须产生相同规则事件。

所有权复盘

World 独占 GameObject，GameObject 独占行为，TextureHolder/SoundEngine 拥有资源，Sprite/Sound 只借用。事件携带值与稳定 id，不携带跨帧裸引用。Factory 在局部完成组装，失败自动清理，不向 World 发布半对象。

Application
  owns World, Renderer, SoundEngine, AssetCatalog
World
  owns GameObject -> UpdateBehavior + GraphicsBehavior
AssetCatalog
  owns Texture, SoundBuffer, Font, Shader
Snapshots/Events
  own values, never borrowed object addresses

这是指针、STL、Factory、文件 I/O 和 shader 加载共同的工程主线。

完成门禁：如何证明掌握

比单次通关更强。它能比较对象存储顺序变化、渲染帧率变化、shader 开关和音频降级是否污染规则。

覆盖 Home、Start、移动、跳跃、平台、火球、Pause/Resume、GameOver、Restart、Quit；注入纹理、声音、shader 与存档失败；记录对象、粒子、draw calls、voice 与阶段耗时。

故障定位方法

跨章节 bug 不从“哪段代码看起来可疑”开始，而从事实第一次偏离预期的位置开始。每条日志带固定步、phase、对象 id、intent、command、event 和 snapshot 摘要。

Player 画面跳了但无声音：比较 PlayerJumped 是否发布、SoundEngine 是否映射、voice 是否配置。暂停恢复瞬移：比较 phase 是否阻止 update、clock 是否重启。HUD 生命错误：比较 World 生命、PlayerSnapshot 与 HUD 投影，不能在界面中修补真实值。

下一步：保留边界，升级实现

完成本书后可继续现代 C++、数据导向 ECS、物理引擎、场景图、多线程资源流送和底层图形 API。升级时保留已证明的边界：明确所有权、固定时间协议、安全提交、事件与快照、失败降级和可重复门禁。

从组件对象迁移 ECS 前先保留固定回放；从 SFML 迁移底层渲染前保留 RenderSnapshot 与视觉基线。没有证据的重写只是重新引入未知错误。

小结

• Timber 建立时间驱动状态，Pong 建立对象与碰撞解算
• Zombie Arena 放大对象群、资源、View、HUD、文件与波次管理
• Run! 用 Factory、GameEvent、WorldCommand 和快照建立对象协作协议
• Camera、Animator、SoundEngine、HUD、雨效和 shader 都是只读表现消费者
• 掌握由确定性、生命周期、状态、降级、性能和干净发布证据共同证明