游戏项目开发文档规范
近期会陆续公开以前写的不再涉及企业机密的文档,也同时把 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。
(未完,一般不续……)