GameEngineArchitecture读书笔记

• Game Team
  • 国外AI和Audio程序员所占的角色还是很重要的, 而国内AI都是服务器在做, Audio基本上没有人下多少工夫
  • 美术的话TA越来越重要, 3D游戏开发不缺少
  • 另外, 项目管理也很重要, 程序员没有那么多精力去关注这些事情
• Game Engine
  • 引擎的三个特性: 数据驱动, 可复用, 可扩展
  • 流派
    • 第一人称
      • 写实效果, 对于技术要求最高. 真实渲染, 高帧率, 物理模拟, 动画和高智能AI, 多人游戏支持
    • 第三人称
      • 卡通效果, 丰富的动作, 可交互场景
    • 格斗游戏
      • 大量的动作, 打击判定, 角色渲染, 皮肤/布料/毛发渲染
    • 竞速游戏
    • 即时战略
      • 地形支持. 复杂AI
    • 多人在线
      • 服务器, 图形效果要求低
    • 其他
  • 中间件
    • 游戏开发越来越多的使用到中间件, 没有哪一个引擎能把所有的部分做到极致
    • 现在的引擎更像是一个容器, 各种第三方插件整合到一起
    • 就国内现状来说, 用商业引擎的一般会再买几个中间件, 不然功能不全; 用自研引擎的要么找开源的, 要么自己做
    • 典型的几个中间件:
      • Lighting: Beast/Enlighten
      • Physics: Havok/PhysX/Bullet
      • Animation: Granny/Havok/NaturalMotion
      • AI: Kynapse/Xaiment/Havok
      • UI: Scaleform/Awsomium/CEGUI
      • Video: Bink/Scaleform/CRI Movie
      • Audio: FMOD/XACT/Miles
      • Network: RakNet/GameSpy
  • Gameplay
    • 很多引擎是缺少这一层的, 可能OGRE的流行让大部分人觉得渲染引擎就是游戏引擎吧?
    • 除了渲染, 像对象系统, 事件系统, 脚本系统, AI等也是一个游戏引擎不可缺少的部分
  • Pipeline
    • 这才是一个引擎具有竞争力的地方, 因为它直接关系到一个游戏的开发效率
    • 对于一个引擎来说, 画面效果虽然重要, 但是pipeline比画面和效率更为重要
    • 游戏开发是个不断迭代的过程, 所以提高迭代的速度也意味着降低成本
    • 一个引擎, 不管什么都是围绕着"资源"来进行的
  • Tools
    • 版本管理
      • 最开始接触的是SVN. 当然, 不可否认这是开源免费的最佳代表, 用来管理代码还是不错的. 但是用它管理美术资源无疑是个效率很低的选择
      • Git/Hg, 相比SVN我觉得更好用一些, TortoiseGit是我现在的首选. TortoiseHg用了一段时间, 跟TortoiseSVN的操作习惯差别太大, 而且界面还是python的, 不太习惯
      • Perforce, 商业解决方案. 效率的确高(特别是美术二进制资源), 插件(VS/Max/Maya/PS)也不错. 从SVN转过来后老是对它某些细节有点不爽, 因为它不会主动对比文件差异, 这也是它为什么速度快的原因-_-
    • Profiling
      • VTune/CodyAnalyst是两上程序用的工具. 最近发现VS2010自代的也相当好用, 不做汇编级的分析的话完全够用了
      • PerfHUD/PIX/GPA: NV现在感觉对PerfHUD支持的少了. PIX如果程序写法不标准会分析不了. GPA现在是越来越好用了, 要是把PIX的一些功能也吸收过去就更好了

DLL

• 很多公司会采用完全的静态链接, 这样比较省事, 也比较安全
• 静态链接通常比较慢(编译时间影响开发效率), 而且EXE也比较大
• DLL的话如果不使用interface封装会暴露很多类定义
• 如果使用C++/CLI的话不能使用静态链接库

• Debug
  • Release能重现而Debug不能重现的BUG通常是变量没初始化
  • DMP文件可以方便地重现崩溃时的堆栈调用
• Coding
  • 代码规范是一个项目/引擎必须制定的东西, C++标准的缺乏造成每人一种风格习惯
  • CodeReview其实是统一风格习惯的一种有效措施
  • AtomString/HashString: 这东西本身是为了提高效率而出现的, 但是用不好就会成为影响效率的东西
  • Endianness: 主机平台跟Win32是不一样的, 生成二进制格式需要转换
  • 全局static变量的初始化顺序没办法控制, 不过函数里的static变量确可以在调用时初始化, 这样可以解决一部分初始化顺序问题
  • dbghelp可以通过地址反查代码行, 对付内存泄露比较方便
  • SIMD要求128bit对齐的内存, 如XNAMath
  • Exception:
    • 主机平台应该避免使用
    • 有时为了保证稳定性不得不用, 比如美术的编辑工具, 至少要让他们有保存一下的时间, 不要直接崩溃了...
  • 模块的初始化/销毁可以使用堆栈处理, 通常这两边的顺序正好相反
  • 数学库现在最好的选择是XNAMath, 自己去实现感觉吃力不讨好, 而且也不敢保证没BUG
  • 容器最好自己实现, STL的限制有很多;
    • 通用型的效率比不上针对特定问题优化过的
    • 内存占用的要多一些(主机平台很看重这个)
    • 动态分配的内存太多
    • 各平台的实现不一样, 对于平台移植有些麻烦
  • 最好不要用boost
  • 字符串
    • 尽量减少const char*的使用(个人习惯)
    • 比于比较操作频繁的, 可以使用HashString
    • 中文编码处理需要考虑
    • 最好把所有字符串做成一个表格, 游戏里通过ID使用