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

第三版来源、工具链与版本边界

“第三版总复习：从语法到完整游戏”对齐 Packt 2024 年第三版的对应章节范围，并以官方公开代码仓库和 SFML 官方文档核对本页可公开验证的工程事实。本页是独立中文重写，不复现原书正文，也不把商品页、目录或代码仓库冒充完整原版。

在“第三版总复习：从语法到完整游戏”中，第三版示例使用 SFML 2.6.1 时代 API。本页保留与本章有关的 2.6 系列合同；SFML 3 的事件、角度、时长和构造接口差异不会被静默回填。升级工具链时必须单独记录本章迁移补丁，不能把版本不匹配误判为“语言与所有权”概念错误。

• Packt：Beginning C++ Game Programming, Third Edition：在“第三版总复习：从语法到完整游戏”中，核对 2024 年第三版、C++20、SFML、四个项目、21 个正式教学章节及章节次序；不把商品页当作正文全文。
• PacktPublishing：第三版官方代码仓库：在“第三版总复习：从语法到完整游戏”中，核对 Timber、Pong、ZombieShooter、Run 四个项目的公开代码与资源组织；代码许可证不等于原书正文授权。
• SFML 2.6 官方教程：在“第三版总复习：从语法到完整游戏”中，核对本书使用的 SFML 2.6 系列 Window、Graphics、View、VertexArray、Shader 与 Audio API 语义。

正式概念与运行状态合同

语言与所有权

这个正式目录节点落在 语言与对象 边界：C++20 类型、类、引用、指针、容器与所有权。在本页中，它参与“把 21 章的语言、所有权、实时状态、资源、视图、音频与 Shader 证据串成四个可从空构建目录复现的游戏”。验收时保存四项目源码提交、依赖版本、构建日志、固定输入轨迹、状态快照、失败注入与发布清单，不能只凭最终画面判断。

实时循环与状态机

这个正式目录节点落在 实时系统 边界：输入、update、碰撞、阶段、通信与相机。在本页中，它参与“把 21 章的语言、所有权、实时状态、资源、视图、音频与 Shader 证据串成四个可从空构建目录复现的游戏”。验收时保存最终验收必须同时覆盖构建、输入、状态、所有权、资源失败、视觉输出与重启恢复，不能只演示一段录屏，不能只凭最终画面判断。

资源与视图

这个正式目录节点落在 表现与发布 边界：纹理、HUD、音频、视差、Shader 与干净构建。在本页中，它参与“把 21 章的语言、所有权、实时状态、资源、视图、音频与 Shader 证据串成四个可从空构建目录复现的游戏”。验收时保存四项目源码提交、依赖版本、构建日志、固定输入轨迹、状态快照、失败注入与发布清单，不能只凭最终画面判断。

四项目干净复现

这个正式目录节点落在 语言与对象 边界：C++20 类型、类、引用、指针、容器与所有权。在本页中，它参与“把 21 章的语言、所有权、实时状态、资源、视图、音频与 Shader 证据串成四个可从空构建目录复现的游戏”。验收时保存最终验收必须同时覆盖构建、输入、状态、所有权、资源失败、视觉输出与重启恢复，不能只演示一段录屏，不能只凭最终画面判断。

先预测，再操作三个本页实验

实验一：从源码到可见结果

先预测“全书干净复现”会怎样穿过 语言与对象 → 实时系统 → 表现与发布，再切换场景和正式概念。每次操作都必须能回到同一初始状态。

实验二：逐步执行状态轨迹

依次执行 清空构建 → 固定依赖 → 编译四项目 → 重放验收 → 归档证据。每一步只选中一个阶段，并持续检查“最终验收必须同时覆盖构建、输入、状态、所有权、资源失败、视觉输出与重启恢复，不能只演示一段录屏”。

实验三：单一故障与同输入恢复

注入“只保留已编译二进制和成功截图，删除源码构建记录、资源失败路径与输入重放数据”，定位第一项不一致；撤销后用完全相同的“单一资源故障”重放。只有中间状态和最终输出一起恢复才算修复。

易错边界与工程取舍

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

第三版 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 都是只读表现消费者
• 掌握由确定性、生命周期、状态、降级、性能和干净发布证据共同证明