游戏项目开发文档规范
近期会陆续公开以前写的不再涉及企业机密的文档，也同时把 word 数据转为 mysql 数据；这些文档或写的不尽人意或未完成，于我来说只是想记录储存。
这个规范写于2011年之前，后续未在调整，现在看着并没有写的很全面详细；不过它主要针对规范管理，对很多不在意的也用不上。
| 序号 | 修改内容 | 修改时间 | 修改人 |
| 1 | 手册通用化 | 2011年11月27日 | 星铃丹 |
| 2 | 调整部分描述并去掉修改隐私部分内容 | 2024年08年21日 | 星铃丹 |
I 准备工作
1 手册说明
1.1 目的
完善开发流程和相关制度，达到资源最大化利用并使开发效率更可能的提高。
· 构建合理的项目管理体系，理顺项目管理中人、财、物的关系，明确工作责任；
· 遵循项目负责制，通过项目各个部门的努力，对特定项目及其相关可利用的资源进行计划、组织、协调、控制、以实现项目的预订目标；
· 项目按照具体的任务、成本、风险和时间管理统一以文件的形式发布，符合公司的业务规划和战略发展；
1.2 制订
通过策划部、程序部、美术部三个部门讨论制定相关流程规范，并由策划部负责相关编撰。
本手册将根据实践的发展不断充实和修订，欢迎员工和各部门提出修改意见。
2 开发工具
| 常用 | 软件 | 说明 |
| 通用 | MS OFFICE 2010 | 用于文档编撰、列表、数值计算、演示等常用办公功能，并为策划部成员必备软件。 |
| Word文档必须导出为pdf进行提交和存档。 | ||
| 公司内部邮箱，作为审批、沟通的主要方式。 | ||
| SVN | 版本管理工具，开发相关文档、文件提交之地。 | |
| 策划部 | MS VISIO 2010 | 用于策划部界面示意图、流程图的编撰。 |
| Mindjet MindManager | 思维导图。 | |
| 程序部 | Visual Studio | 程序开发用工具。 |
| 美术部 | PHOTOSHOP | 美术用工具。 |
| 3D MAX | 美术用工具。 |
3 文档和命名规范
3.1 Word文档规范
3.1.1 基本规范
· 使用Microsoft Office 2010；
· 统一样式表；
· 统一页眉页脚；
页眉如：
| 星铃丹工作室 | 文档名字 | 部门 职位 名字 |
页脚如：
| 创建文档：年月日 | 页码 | 最后修改：年月日 |
注意：需要使用标准中文语言语法；如“段落首行缩进2字符”、使用正确的标点符号等。需要压缩图片、visio等图，避免文档过大。
3.1.2 修改记录
在文档的最前面，需要有文档修改记录表，表格如下：
| 序号 | 修改内容 | 修改事件 | 修改人 |
| ... | ... | ... | ... |
说明：word文档不是开发文件，不需要版本号，序号只是对修改次数进行一个统计；修改内容必须标注清楚在哪个内容、哪个位置。
3.1.3 导出为PDF文件
文档撰写使用WORD，而文档提交到SVN上的，只能为PDF文件；这样可有效避免被误修改引起的争议。
| 文档是否提交判断标准 | 结果 |
| 以WORD格式提交到SVN | 未提交 |
| 以PDF格式提交到SVNN | 已提交 |
流程如下：
注意：需要启用“文档结构”，使保存为PDF的文档，依然有标题导航。
保存为PDF的时候有个“选项”按钮，点击后设置如下：
3.1.4 表格规范
· 绘制表格必须使用边框线；
· 修改工作表命名，使符合当前表格；
· 删掉多余工作表；
3.2 命名规范
3.2.1 策划相关命名
对于策划文档命名，只需要统一加上“《项目名》”即可；具体细节不作要求，但要求同一项目的所有文档命名统一一致。
参考格式为：
《项目名》xx系统草案.pdf
《项目名》xx系统策划案.pdf
《项目名》美术资源表.xlsx
3.2.2 美术相关命名
美术文件命名，必须安装策划提供的美术资源需求表进行命名：非最终文件可以按需求表里的中文名进行命名；最终文件的，必须按照资源表上的相关命名规范进行命名。
比如，资源表里提供如下需求：
| 归档 | 名称 | 命名 | 格式 |
| 背景图 | 古堡雪夜 | bg_01_014 | bmp |
则，线稿可以命名为：线稿_背景图_古堡雪夜.bmp
但最终完成图只能命名为：bg_01_014.bmp
4 项目组人员和职责
4.1 项目组组成
| 职位 | 职能 |
| 项目负责人 | 负责项目开发的时间点记录、把握和监控； 负责项目的质量监控； 负责推进项目进行； 负责和上级联系、沟通、反馈项目情况。 |
| 小组组长 | 负责相关项目里相关功能组（程序、美术、策划）组员的工作安排、时间进度、和质量把控。 |
| 组员 | 配合负责人和组长进行项目开发工作。 |
4.2 项目组和部门
· 项目组在部门之下，项目组内成员受部门主管辖制，必须听部门主管的安排。
· 项目负责人的工作受部门主管的监督，部门主管有义务监控自己部门下项目负责人的时间点和项目情况。
· 项目负责人和项目部门组长，有义务把项目的情况、进度和问题及时知会给部门主管。
· 项目负责人主要是负责项目时间点，但对项目具体“做什么”、“怎么做”没有决定权；决定权由部门主管行使。
4.3 会议和会议记录
· 涉及项目的各种会议和讨论，必须有对应的会议记录；
· 会议记录编撰后，需要发给相关与会人员；
· 参与会议的项目组长、项目负责、主管、CTO等，必须在收到邮件后，回邮确定会议记录是否通过；
· 在SVN项目文件夹里，需要有一个单独的文件夹保存相关的会议记录。
II 开发流程
5 立项阶段
5.1 人员与产出
5.1.1 参与人员（说明：这里仅为必须参与人员）
· CEO
· 策划部
· 市场部
· 程序部
5.1.2 相关会议
| 会议 | 参与人 | 是否一定要开 |
| 创意讨论、展示、头脑风暴 | 可全部人员 | 否 |
| 项目方向选定讨论 | CEO、CTO、负责人、部门组长 | 是 |
| 项目组成立会 | CEO、CTO、项目组成员 | 是 |
5.1.3 产出
| 类型 | 名称 | 是否一定要开 |
| 文档 | 创意说明 | 否 |
| 幻灯片 | 创意展示 | 否 |
| 文档 | 《市场调研报告》 | 是 |
| 文档 | 《立项说明书》 | 否 |
| 会议记录 | 各种会议记录 | 是 |
5.2 流程说明
· 由公司方面提出开发需求；
· 策划部按需求提出创意，可以是历史累积的一些创意，也可以是刚想出的创意；公司其他成员也有权提出创意，参与选拔；
· 由CEO在创意中选出部分觉得合适的，由创意人进行创意展示说明文档的制作；
· 进行“创意讨论”，展示创意，全公司投票选择出票数最多的几个创意；
· 由公司主管及以上人员进行讨论，敲定觉得初步合适制作的创意；
· 由策划部安排人手，市场部、程序部进行配合，对敲定的创意进行市场调研；
· 由策划部给出相关创意的《市场调研报告》，提交到CEO处，并知会其他部门主管、CTO；
· CEO阅读市场调研报告后，最终决定是否进行该项目开发；
· 项目决定开发后，由策划部牵头，联系各个部门定下项目组成员和初步时间安排；
· 由策划部安排策划给出《立项说明书》，交给CEO审批，通过后完成此阶段；
· 相关资料归档。
5.3 文档内容和参考
5.3.1 《市场调研报告》
包括内容：调研时间（年月日），调研地点，调研对象，调研平台，同类手机产品汇总和分析，市场竞争强度（各同类产品的下载数量和盈利情况）、我们产品如何趋利避害、程序技术评估开发难度、最终进行总的性价比评估，得出结论。
参考格式：
| 1、概述 调研时间：年月日~年月日 调研地点：公司 调研对象：安卓平台xx类型手机游戏 调研平台：Google Android Market，App Store，HiAPK 2、同类手机产品 2.1、某某游戏 游戏名：中文/英文 产商： 上市时间： 下载地址： 所在平台： 下载/购买量： 运营情况： 基本玩法： 游戏截图： 优点/缺点： 2.2、某某游戏 3、玩法分析 根据以上各个游戏分析，得出我们的游戏应该怎么玩，规避怎样的问题，才能得到最大的市场竞争力。 4、技术评估 由程序给出这个项目开发的技术难点和可能存在的问题。 5、结论 综合以上种种，给出调研结论：开发时间大概多久，市场胜算有多大，是否值得一做？ |
5.3.2 《立项说明书》
包括内容：项目名称、游戏类型、创意人、参考游戏、美术风格、游戏视角、项目组成员名单（名字、部门、组位置、主要负责内容）、开发时间（项目开始时间、实际完成时间）、基本玩法。
6 策划阶段
6.1 人员与产出
6.1.1 参与人员（说明：这里仅为必须参与人员）
· 策划部
· 程序部
· 美术部
6.1.2 相关会议
| 会议 | 参与人 | 是否一定要开 |
| 玩法细化讨论 | 策划部 | 是 |
| 草案讨论、评审 | 策划部、程序部、美术部 | 是 |
| 细案评审 | 策划部 | 是 |
| 风险评估讨论 | 程序部 | 否 |
| 讨论版本规划和开发需求 | 策划部、程序部 | 否 |
| 美术风格讨论 | 美术部 | 是 |
6.1.3 产出
| 类型 | 名称 | 是否一定 |
| 思维导图 | 玩法思维导图 | 是 |
| 计划 | 策划开发计划 | 是 |
| 文档（集） | 游戏草案/游戏系统草案 | 是 |
| 文档（集） | 游戏细案/游戏系统细案 | 是 |
| 文档 | 美术资源表 | 是 |
| 计划 | 程序开发计划 | 是 |
| 计划 | 美术开发计划 | 是 |
| 设计图 | 美术风格草图 | 是 |
| 会议记录 | 各种会议记录 | 是 |
6.2 流程说明
· 项目组策划组长组织策划组员和部门主管，对游戏玩法进行讨论，画出思维导图；
· 根据思维导图，项目组策划组长给出“策划开发计划”表，发项目负责人、各部门主管、CEO、CTO；
· 项目负责人根据“策划开发计划”安排策划组员进行相关草案编写工作；
· 草案出来后，需开草案讨论会，草案要通过项目负责人、策划组组长、策划部主管的讨论，评审；
· 项目策划组安排人写讨论会会议记录，并邮件知会与会人员；
· 草案讨论会后，策划组需要把草案按讨论会讨论结果进行相关修改、调整，转为PDF文件后传到SVN并邮件发出给与会人员；
· 与会人员必须全部回邮，表示通过相关草案；一旦通过，该草案的大方向设定将不得修改；
· 草案决定后，程序组和美术组要根据所确定的草案内容，进行“风险评估”、“工具准备”、美术风格确定等相关事宜；
· 策划组和程序组要对游戏开发阶段和版本进行规划；
· 程序组和美术组给出相关的开发计划表。
· 策划组根据通过的策划草案，编写策划细案；
· 策划细案要通过策划部部门内讨论、评审；
· 策划细案确定后，转为PDF发给开发各相关人员；
· 策划组根据策划细案给出相关美术资源表、音效资源表、界面资源表；邮件发送给美术组组长、美术部主管；
· 资源表上的图片尺寸等，如有需要，由策划组、美术组、程序组针对进行三方讨论，进行确定；
· 美术组组长、美术部主管需要回邮确认相关的资源表已经收到，基本没有问题，可以进行开发；
· 相关资料归档。
6.3 文档内容和参考
6.3.1 开发计划表
开发计划表由每个部门组长提供相关组的安排，再由负责人汇总记录，并且跟进。
计划表参考形式：
| 工作 | 计划开始 | 计划结束 | 计划工期 | 实际开始 | 实际结束 | 实际工期 | 完成度 | 负责人 | 时间点状态 | 备注 |
说明：
| 工作 | 具体工作事项，如画xx图片，写xx草案 |
| 计划开始 | 该项工作计划开始时间 |
| 计划结束 | 该项工作计划完成时间 |
| 计划工期 | 该项工作计划所用工期（以天数算） |
| 实际开始 | 该项工作实际开始时间 |
| 实际结束 | 该项工作实际结束时间 |
| 实际工期 | 该项工作实际所用工期（以天数算） |
| 完成度 | 当前完成了多少（百分比） |
| 负责人 | 该项工作有谁来做 |
| 时间点状态 | 该项工作最终情况：“准时完成”、“提前完成”、“延迟”、“未完成” |
6.3.2 界面UI表
界面功能标注举例：
 | ||||
| 位置 | 类型 | 资源名称 | 内含文字 | 说明 |
| 背景图 | 背景图 | - | 界面背景图 | |
| 1 | 按钮 | 返回按钮 | - | 点击返回按钮可以返回游戏上一级菜单。 |
| 2 | 按钮 | 选关按钮（未按） | 阿拉伯数字 | 点击选关按钮可以进行大关卡的选择，选择后进入小关的选择界面。 |
| 选关按钮（按下） | ||||
| 3 | 图标 | 星星图标 | - | 星星图形表示了该关卡所搜集到的星星数量，以此衡量是否打开下一关卡。 |
界面尺寸标注：
 | |||||||
| 位置 | 资源名称 | 800×480（屏幕尺寸） | |||||
| 实际大小（mm） | 像素大小（mm） | 物件坐标（px） | |||||
| 长 | 宽 | 长 | 宽 | X | Y | ||
| 1 | 返回按钮 | 6 | 6 | 44 | 44 | 5 | 273 |
| 2 | 重生按钮 | 6 | 6 | 44 | 44 | 54 | 273 |
| 3 | 关卡提示 | 6 | 4 | 48 | 28 | 424 | 289 |
| 4 | 星星图标 | 6 | 2 | 48 | 14 | 424 | 273 |
| 5 | 道具按钮 | 8 | 8 | 60 | 60 | 8 | 8 |
| 6 | 提示文字 | 29 | 14 | 220 | 102 | 150 | 220 |
6.3.3 特效、音效资源表
一般用excel制作。
特效：
| 序号 | 特效名称 | 位置 | 大小 | 描述 | 文件命名 | 特效时间 | 参考资源 |
| 1 | 切换画面特效 | 游戏切换画面时 | 全屏 | 类似拍照的瞬间效果 | tx_01 | 0.5s |
音效：
| 序号 | 音效名称 | 音效作用 | 音效描述 | 时间长度 | 音效文件命名 | 参考资源 |
| 1 | 背景音乐 | 游戏的背景音乐 | 希望可以能使用参考音乐 | 1min-2min | yx_00_01 | erasure唱的Always |
7 开发阶段
7.1 人员与产出
7.1.1 参与人员
（说明：这里仅为必须参与人员）
· 策划部
· 程序部
· 美术部
7.1.2 相关会议
| 会议 | 参与人 | 是否一定 |
| 策划剧情设计评审 | 策划部 | 否 |
| 策划任务设计评审 | 策划部 | 否 |
| 策划关卡设计评审 | 策划部 | 否 |
| 策划数值计算评审 | 策划部 | 否 |
| 美术资源评审 | 美术部、策划部、程序部 | 是 |
7.1.3 产出
| 类型 | 名称 | 是否一定 |
| 文档 | 剧情设计案 | 否 |
| 文档 | 任务设计案 | 否 |
| 文档 | 关卡设计案 | 否 |
| 表格 | 数值计算表 | 否 |
| 美术资源 | 界面 | 是 |
| 美术资源 | 人物、场景、动作 | 是 |
| 美术资源 | 音效 | 是 |
| 产品 | 游戏测试版 | 是 |
7.2 流程说明
· 策划组按计划安排制作相关剧情、任务、关卡、数值等的设计和计算；
· 程序组按计划进行游戏具体开发；
· 美术组进行资源制作；
· 在程序、美术进行开发和制作的时候，策划组组长必须安排人手每天更近程序、美术的制作，以保证他们的制作符合设计需求，避免返工；
· 美术资源的命名，必须按照美术资源表上的相关命名规定进行命名；
· 美术资源制作好后，必须发给策划组、程序组进行评审，以邮件形式确定是否通过；
· 相关资料归档。
8 测试阶段
8.1 人员与产出
8.1.1 参与人员
（说明：这里仅为必须参与人员）
· CEO
· 策划部
· 程序部
· 美术部
· 市场部
8.1.2 产出
| 类型 | 名称 | 是否一定 |
| 文档 | 剧情设计案 | 否 |
| 文档 | 任务设计案 | 否 |
| 文档 | 关卡设计案 | 否 |
| 表格 | 数值计算表 | 否 |
| 美术资源 | 界面 | 是 |
| 美术资源 | 人物、场景、动作 | 是 |
| 美术资源 | 音效 | 是 |
| 产品 | 游戏测试版 | 是 |
8.2 流程说明
· 策划组组织详细对程序提供的“游戏测试版”进行测试；
· 策划组通过Mantis Bug Tracker向程序提交BUG和建议；
· 程序针对BUG和修改建议进行回复、调整和修改，直到负责人觉得游戏已经可以拿出进行内部测试；
· 有项目负责人联系各部门主管在全公司范围里安排内部测试人员，规定测试时间，进行测试；
· 测试人员需要提交测试报告文档，由项目负责人安排人员进行汇总提交给主管和CEO等；
· 由项目负责人觉得游戏不需要再修改，已经可以上市的时候，把相关产品文件文件提交给CEO进行审批；
· CEO审批产品通过，项目开发结束；
· 相关资料归档。
8.3 文档内容和参考
8.3.1 测试报告
包括的内容：测试时间、测试项目、手机型号、优点、缺点、BUG。
（未完，一般不续……）
评论已关闭