游戏开发与制作小记（9章）
第九章 技术设计文档
技术文档的目的：技术设计文档是开发团队中的工程师在开发游戏时所参照的实际图。理想的技术设计文档不仅能项工程师说明要开发什么，还能够详细说明如何去实现。
软件架构（即用头文件定义，接口定义，需类定义，的类与类的关系体系机构，类之间的框架结构）是十分重要的。而技术设计文档的范围要比软件架构计划的范围要广，但内容没有那么详细。设计文档必须涵盖软件需求，能够为软件测试计划提供参考，能够向项目经理提供必须的开发者，任务与开发者之间的关系的信息。
统一软件开过程工作流：
需求
分析
设计
实现
测试
统一软件开发过程不可能清晰的界定各个工作流，统一软件开发过程是一个迭代和增量的工作流方法，项目开发每一个阶段可以分为起步、细化、构建和转化阶段。
起草时间
技术设计文档应该在预生产阶段与游戏设计文档一起或者比游戏设计文档晚一点、根据其内容起草技术设计文档需要在进度表和项目计划完成之前考虑游戏的开发计划和时间预算。游戏发生任何变化都要在相应的的开发实施之前，迅速的进行修改技术设计文档。今后的开发设计文档是需要不断改进的。
技术设计文档内容
技术设计文档相当于实现游戏需求的一个计划——一个关于谁，什么时候，怎么实现这些需求的计划。它包括需求获取，需求分析，高级架构，中级软件设计，部署设计，测试计划以及实现计划。每一个阶段都有很多文档、图表、时间预算来完成这些描述的任务。
需求获取
需求获取是确定游戏所有需求的过程，需求包括：游戏需求、性能需求。这一阶段是需求获取，不要进行任何的需求筛选、区分优先级、分析需求或者作出任何决定。这一阶段只是广泛获得尽量多的需求。早期需求分析会使开发进程停顿，作出任何决定都会让需求减少，影响以后的选择。
在这个文档中应该包含游戏的界面设计，游戏实现机制，艺术设计，任务，游戏级别etc
在统一建模语言中用例图是十分重要的工具。
与大多数的软件不同，游戏注重与玩家交互，应为每一个外部菜单作一个用例，大部分都不需要说明。
用Photoshop等画图程序简单绘制每一个界面，考虑和搜集其中的玩家交互活动和需求。从各种各样的用例中提取出游戏最通常的功能和行为，用单独的用例图表述，并对用例进行说明。不要在意怎样去实现它，只要弄清楚是什么样的交互活动。
需求分析
分析模型是在需求获取阶段和详细设计阶段之间，表述一系列图、文字和设计内容。分析模型需要不停地迭代，深入设计，创建更加具体的架构。目的就是在游戏的设计和架构阶段以一些UML图避免一些软件缺陷。
在需求分析阶段应该完成的任务是：从用例图中提取有价值的信息，根据用例的共同活动将用例分组，分析出主要类以及一系列的基本事件。将一些用例的共同的部分转化为类。这时的类图并不是最终类图，这一部分的分析隔一段时间就要迭代一次，并完善类图。
类图
类图是设计文档中很大的一部分内容。不管是编码还是维护都需要类图为参照。在类图中注释是必不可少的，一些执行方面的需求是需要写在注释里的。
（一些类图设计问题不再赘述）
其他类型的UML图
对象图：用于描述对象的图。
包图：用于组织类图。
Etc
架构图：对于大型游戏来说部署图是十分重要的。
不要忘了，使用Rose等建模工具向前或向后进行代码生成将是十分方便的。
解决游戏在如时间问题
重构——《重构——改善既有程序的设计》
封装——《大规模C++程序设计》
测试计划
模块测试和白盒测试
模块测试是最基本的测试步骤。最好的形式是自动测试。
黑盒测试
一些不了解内部机制的人模拟玩家进行一些非常规操作。
Beta测试
由一些游戏爱好者实际试玩进行测试。
测试用例
用例图中的用力就是测试用例，依照用例图中的用例进行黑盒和Beta测试。
