• 本系列博客为《游戏引擎架构》一书的阅读笔记，旨在精炼相关内容知识点，记录笔记，以及根据目前（2022年）的行业技术制作相关补充总结。
• 本书籍无硬性阅读门槛，但推荐拥有一定线性代数，高等数学以及编程基础，最好为制作过完整的小型游戏demo再来阅读。
• 本系列博客会记录知识点在书中出现的具体位置。并约定（Pa b），其中a为书籍中的页数，b为从上往下数的段落号，如有lastb字样则为从下往上数第b段。
• 本系列博客会约定用【】来区别本人所书写的与书中观点不一致或者未提及的观点，该部分观点受限于个人以及当前时代的视角所限，请谨慎阅读。
• 再次重申，请支持正版。

第2章 专业工具

2.1 版本控制

• 版本控制系统(version control system）容许多位开发者在同一组文件上工作。版本控制系统记录每个文件的历史，并且追踪文件中的每个改动，并且在需要时可以还原。版本控制系统允许多位用户同时修改文件，甚至修改同一个文件，并避免互相破坏成果。
• 版本控制的功能：1、提供中央版本库（repository），工程师们可以分享其中的代码。 2、保留每个源文件的所有更改记录。3、提供为某些版本加上标签的机制，供以后提取已加标签的版本。 4、容许代码从主生产线上建立分支(branch)。这一功能经常用来制作示范程序或是为较旧的软件版本制作补丁（patch）。
• 【目前常用版本控制软件：Git、SVN】

2.2 微软Visual Studio

• 【Unity的话也可以尝试Rider】
• 编译式语言，如C++，需要使用编译器（compiler）及链接器（linker)，把源代码转换成可执行程序。坊间有不少C++的编译器/链接器，而在微软Windows平台上，最常用的套装软件应该是微软Visual Studio。配备全副功能的Visual Studio专业版（professional)可在代理Windows软件的零售店购得。另外，Visual Studio速成版（Express)，即Visual Stu-dio的轻量级版本，可于网站免费下载。微软开发者网络(Microsoft Developer’s Network,MSDN)也提供了Visual Studio的在线文档。（P61 1）
• Visual Studio不只是编译器和链接器，更是一个集成开发环境(integrated developmentenvironment，IDE)，包含为源代码而设的高质量全能型文本编辑器(text editor)，以及强大的源代码层级(source-level)和机器层级(machine-level）调试器（debugger)。（P61 2）
• 源文件、头文件及翻译单元（P61）
• 程序库、可执行文件及动态链接库（P61）
• 显然，每位程序员都必须有调试发布生成的能力，即使这看上去并不是一件轻松的事情。减轻调试优化代码之痛，最佳办法是多练习，并且在有机会时扩展这方面的技能。以下是一些窍门：（P77 2）
  1、学习在调试器中阅读及单步执行反汇编
  2、运用寄存器去推理变量的值或地址
  3、使用地址取检查变量及对象内容
  4、利用静态和全局变量
  5、修改代码

2.3 剖析工具

• 游戏通常是高性能的实时系统。因此，游戏程序员经常要寻求加速代码的方法。有一个尽管不太科学但很有用的经验法则，称为帕累托法则(Pareto principle)。此法则指出在很多情况下，一些事件的80%后果只取决于20%的原因，所以它又称为80-20规则(80-20 rule)。计算机科学常使用此法则的变种，称为90-10规则(90-10 rule)，指任何程序的90%挂钟时间（wall clock time)消耗在运行仅10%的代码上。换句话说，优化那10%的代码，带来的总体运行速度提升达完全优化的90%。（P78 1）
• 那么，如何得知需优化的10%代码在哪里？答案就是使用剖析器(profiler)。剖析器能量度代码的执行时间，并能告之每个函数所花的时间。这些数据可引导程序员去优化占大部分执行时间的函数。（P78 2）

2.4 内存泄漏和损坏检测

• 困扰C/C++程序员的另外两个问题是内存泄漏（memory leak)和内存损坏（memorycorruption)。如果一块内存在分配后永不释放，就会产生内存泄漏。泄漏会浪费内存，最终造成致命性的内存不足（out of memory)。内存损坏则是指，程序不慎把数据写进内存的错误位置，覆盖了该位置原来的重要数据，也同时未能把数据写到应该写的位置。两个问题皆可毫不含糊地归咎于同一个语言特征——指针(pointer)。（P79）
• 【在Unity方面则请了解GC回收以及引用类型】

2.5 其他工具

• 区别工具(difference/diff tool):区别工具是用来比较一个文本文档的两个版本，找出版本之间的差异。（P80）
• 三路合并工具(three-way merge tool):当两人修改同一个文件时，就会产生两组区别。能把两组区别合并成为含二人改动的最终文件的工具，称为三路合并工具。
• 十六进制编辑器(hex editor):十六进制编辑器用于查看及修改二进制文件的内容。

第3章 游戏软件工程基础

3.1 重温C++及最佳实践

• 【C#方面可以查看：传送门，第一节课程有大纲（无需付费购买）】
• C++：类和对象，封装，继承，多重继承，多态，合成及聚合，设计模式（P83）
• 编码标准：编码标准之所以存在，有两个主因：1、一些标准使代码更易读、更易理解、更易维护。2、另一些约定能预防程序员做蠢事，自找麻烦。例如，某编码标准可能会怂恿程序员只使用编程语言中更易测试、更不易出错的一小部分功能。由于C++语言充满滥用的可能性，所以这类编码标准对使用C++来说特别重要。（P89 1）
• 书中认为，编码约定中最需要达到的事情为：1、接口为王 2、好名字促进理解及避免混淆 3、不要给命名空间添乱 4、遵从最好的C++实践 5、始终如一 6、显露错误（P89 2）

3.2 C/C++的数据、代码及内存

• 数值表达形式：数值底数-十进制、二进制；有符号及无符号整数、定点记法、浮点记法、范围和精度的取舍、基本数据类型、编译器专属特定大小类型、SIMD类型、可移植的特定大小类型、OGRE的基本数据类型、多字节值及字节序。（P90-99）
• 声明定义及链接规范（P99）
• C/C++内存布局：可执行映像、程序堆栈、动态分配的堆（P105-109）
• 成员变量（P109）
• 对象的内存布局（P111）

3.3 捕捉及处理错误

• 错误类型：所有软件项目皆有两类基本错误状况:用户错误(user error）和程序员错误(program-mer error)。用户错误，指用户做了些不正确的事情而引发的错误，例如键入无效的输入、尝试开启不存在的文件等。而程序员错误是由代码本身的bug所导致的结果。虽然程序员错误可能会因用户的某些操作而触发，但是程序员错误的本质是——若程序员不犯错，该问题是可以避免的，并且用户会合理地预期程序员应该妥善地处理该情况。（P118 2）
• 错误处理：处理这两类型错误的需求有重大差异。处理用户错误应该越妥善越好，并向用户显示有用信息，然后容许用户继续工作——若处于游戏状态下则继续玩。另一方面，程序员的错误不应采用“通知并继续”方针去处理。通常最好的处理方式是中止程序，并提供低阶调试信息，促使程序员能快速鉴定及修正问题。理想情况下，在软件发布之前，所有程序员错误都会被捕获及修正。（P118 last）
• 实现错误检测及处理：1、错误返回码（P120 3）2、异常（P120 last）3、断言（P121 last2）