游戏开发设计绝没有想象中的简单,假如是团队开发要策划,要程序员,要美工,要音效,要营销......假如是独立游戏设计,最主要的就是要程序师,要美工,游戏开发对编程和美工的要求都很高,编程这块除非直接使用已经有的游戏引擎,不然没有五六年实战的功底深入游戏编程很难,涉及面太多,美工也必须是触级的美工,熟悉人体结构与各种运动并且有动画制作的经验。说了这么多,好像还没达到要点,来来来,看下文:
概述
常规游戏指一般的具备网络服务器端的客户端游戏、页游、手游。开发这类游戏,一般会分以下四个阶段:
1.筹备阶段:筹建团队,确定项目的基本方向。
2.原型阶段:实现一个游戏原型,发布Alpha测试版,以验证和调整预定的方向。
3.发布阶段:发布游戏的Beta测试版本,供内部封闭测试,做上线前最后的准备。
4.迭代阶段:完成对Beta测试版的修改,上线后按迭代周期,持续开发和调优产品。
在这些阶段中,我们都必须注意开发流程中的一些重要因数:
角色:定义一些角色,规定其工作权力和责任,避免过度讨论或盲进
交付物件标准:每个角色都必须按照一定标准来交付工作成果,避免在长长的工作链条中出现很多误差。
工作方法细节:由于游戏开发是一个涉及多个专业的复杂过程,所以这个过程中有一些工作方法,是必须要遵守的,否则将会严重降低开发效率。
作为一个完整的游戏开发团队(不包含运营团队),整体的结构应该大致如下:
筹备阶段
1、角色定义
投资人:根据市场状况和投资预期,提出商业目标和项目邀约,和制作人讨论并审核确定《产品方向》,制作《投资计划》,按计划安排资金投放,并承担投资后果。
制作人:根据投资人的商业目标,整理和组织市场调查数据和《竞品资料》,制订《产品方向》。根据《投资计划》组建核心团队。在某些项目里,投资人和制作人是同一个人。
核心团队:一般由制作人和主程,主策,主美组成,有些时候还包括项目经理。在某项项目里,制作人可能由核心团队里的任何一个人兼任。
项目经理:负责制订工作计划,监督进度,安排各种资源。初期可能会有很多秘书工作需要担任。在某些项目里,项目经理可能由核心团队中任何一个人兼任。
2、交付物件
《投资计划》:由时间、金额、项目进度检查标准,这三列组成的一个表格。需要附带上修改日志和完成记录。
《产品方向》:一个具体的文档,记录了产品概念所依据的市场状况(数据)、竞品的情况(数据);也记录了项目产品的基本情况:游戏的题材、游戏的玩法、游戏收费方法的基本概念,以及市场推广、运营的基本思路。
《竞品资料》:罗列所有主要的竞争对手产品的情况,包括产品市场数据,开发方案(如能搜集到),评测资料,用户反馈等。需要由制作人持续更新关注,随时整理添加。
3、重点注意
产品概念讨论方法
针对用户特性:游戏产品形态非常丰富,细节也很多,所以在讨论任何设计的时候,都必须按照既定的用户画像来做标准判断,避免大而全或者钻牛角尖。在各种“调查报告”无效的情况下,邀请几个目标用户作直接沟通,往往能获得最真实、最有效的情报,不用过于担心“代表性”不够,因为共性往往是比较明确的部分。
针对竞品:在用户、市场情报不够充分的时候,竞争对手能提供最直接的产品信息。通过分析竞争对手的产品,特别是跟踪竞争产品的变化,就能猜出用户和市场的反馈。就算本产品的竞争对手不多,方向相似度不高,只要是目标用户群体接近,也可以通过竞争产品的用户感受来了解用户心理。切记闭门造车,不接触市场风潮。
不应该深入的部分:在筹备阶段,容易陷入头脑风暴,所以我们不应该深入讨论产品的开发过程、开发工具、开发人员。对于产品的细节,也不宜过细,但应该找出一些简单明确的概念来代替,如“经过XX修改的竞品A”这样就很好。
团队缺人对策
招聘渠道:首选熟人朋友圈,其次毕业生和培训机构,最后是网上投递简历。由于现在的培训机构一般都需要签就业协议,所以对于创业团队,小型公司来说可以作为一个比较稳定的人员来源。大型公司最好就是各种高校的招聘会了。猎头也可以考虑,但是对候选人需要仔细甄别。
选择简单的工作方法:缺人的情况下,往往是缺牛人。所以一定要选择简单的工作方法,各种高大上的流程,一定要在有IT技术保障下实施,不要直接推行而不顾实际情况,这些可能有问题的方法包括:定期汇报制度、全自动化项目管理、没有足够储备的技术开发方案等等。
培训准备:根据初期可能到职的人员,进行基础能力的培训,比如SVN的使用,BUG跟踪系统的使用,基础的开发技术、美术、策划文档标准。这些培训都是需要多次进行,所以应该先准备好培训资料,避免新成员入职措手不及。
时间控制
会议:筹备阶段大概有一半的时间是在做沟通,因此会议时间需要特别控制。要严格遵守议题议程。如果有遗留问题,应该有专人搜集整理并且跟进,而不是在会上去解决。因为会上提的方案,往往没有自己在认真思考的环境更完善。另外就是避免“挨个报告”那种没有明确议题的会议。这种沟通了解放到其他时间,少部分人沟通会更清楚。
招聘期限:根据经验,核心团队具备的情况下,要组建到项目正式启动的团队,基本需要3个月左右。假如接近3个月都没有什么进展,应该和投资人反映,并研究解决方法。一般最简单的就是提高工资和雇佣猎头。
原型(Alpha)阶段
1、角色定义
主策:提出产品原型的概念,交付《项目总体设计》,并协助原型开发,突出产品特点。
主程:选择技术方案,定义美术、策划资源的技术标准。搭建开发环境,编写产品原型。在客户端开发方面,和美术同事合作,调整原型效果以达到测试的目的。
主美:选择美术风格,在策划和技术的共同讨论下,确定各美术组件的基本技术标准,如大小、尺寸、容量。并且确定美术资源的格式。
项目经理:有些团队由制作人、或者主策兼任。此阶段在明确游戏原型后,产品、技术、美术人员都会需要各自开发一些内容,然后再整合到一起。因此项目经理应该负责组织大家共享这些信息,一起讨论和评审各阶段产品,确保各环节不脱节。
2、交付物件
《项目总体设计》:规定了游戏的题材、玩法、收费模式。确定游戏的重点乐趣和表现特点。列出游戏的长期开发计划所需要的系统、关卡、内容纲要。作为后续策划工作的总需求列表。
《美术风格指导》:以实例原画图来规定整体美术风格。
《美术资源格式标准》:对游戏原型的美术资源格式,做出标准规定,包括美术文件的格式、尺寸、精度标准、命名、SVN路径规则等。
开发环境:SVN服务器地址、BUG跟踪系统地址、IDE选择产品和版本、开发和测试的内网服务器、演示用外网服务器。
《技术方案选型方案》:开发游戏所用的客户端和服务器端引擎、框架版本;程序的基本模块代码结构;项目文件目录规范;测试和CI方案;技术难点的预设解决方案。
可运行的原型产品(DEMO):突出表现游戏核心玩法和美术风格的一个程序,可以是一个单独的游戏关卡。
3、重点注意
原型开发阶段,主要目的是验证产品的基本面问题:题材和玩法的融合是否合适,美术风格和技术实现是否能达到策划的初始目标,有没有一些难以解决的基本障碍。需要特别注意的,开发原型所需要耗费的资源制作和逻辑编写时间,因为这反应了后期游戏持续更新所需要消耗的成本。
另外,由于游戏原型的制作,也带出了个制作环节的沟通问题,所以必须注意从一开始就积累和订立各工序的交付标准,如策划案应该包含图量表、测试方案;需要预先沟通美术草图并签名;美术资源格式需要确定;游戏原型的测试环境设置。——这些标准和接口往往会变动,但是需要预先明确这些接口流程。
发布(Beta)阶段
1、角色定义
技术开发团队
客户端开发:开发和优化客户端代码和单元测试用例、文档,完善客户端程序打包、发布的CI流程。
服务器端开发:开发服务器端代码和单元测试用例、文档,维护项目数据库,安装部署测试环境。
测试开发:维护和管理CI系统,监督运行单元测试用例,开发专项测试如性能测试、自动化冒烟测试。
2、交付物件
《策划需求文档》:重点说明要达到的产品目标,使用的主要设计手段
《策划案》:产品使用流程图,GUI草图,须配置的游戏数据项目,美术图量表以及风格参考
《草图》:美术风格参考,UI构图
《技术设计方案》:代码模块命名以及职责,代码结构模式及关系,重点技术问题解决方法
《美术资源格式》:文件名和路径规则、文件格式、精度、尺寸或其他更细节内容
《游戏数据格式》:库名、表名、字段解析、字段内容结构
《Bug报告单》:策划案ID、重现步骤、现象
3、重点注意
此阶段是建立稳定完整的版本开发流程最重要的阶段。关键点是各交付件标准的严格遵守和流程监控。项目经理须组织对于流程、标准的讨论和确定,并且监督这些规定的执行。由于每个游戏都不一样,所以这些流程和标准都会有所差异,项目经理要随时应对不同的策划案,即时组织大家建立流程标准。另外需要准备发布的工作,包括宣传资料,测试环境,运维工具等工作,也需要花时间准备。——在发布前至少安排一周时间来做发布前的准备,和运营、运维、客服人员做好沟通和交接准备。
迭代阶段
1、角色定义
开发团队:依照迭代标准开发迭代所需内容。
运维团队
运营人员:负责推广、发行工作,提供技术资料给运维人员做产品部署,关注产品数据和运营情况。反馈意见给开发团队。
客服人员:辅助游戏推广,提供玩家咨询、故障报告、投诉处理、事故安抚等工作,需要运营人员和开发团队进行持续的信息共享。
运维人员:提供游戏的部署和监控工作,开发管理运维部署工具。准备硬件资源和运行环境。有些运维工作由开发团队中的服务器端程序员一起分担。
运营开发人员:开发“GM系统”给客服人员使用;开发“数据统计报表”和“活动系统”、“官网”等系统给运营人员使用;某些游戏团队由服务器端程序员兼任。
2、交付物件
《版本发布计划》:每个版本开始开发前,都需要编写此计划,列明本版本内需要开发的内容,预计时间,以及开发设计人员名单。此计划需要提交给运营人员,提早准备《运营计划》中的推广活动和安排推广资源。
《版本发布说明》:每个版本进入内测后,由开发团队编写后,提供给运营人员,包含本版本的所有在产品上的变更细节。以及这些版本内容的开发成员。供运营人员培训客服掌握,以及运营人员自己做测试,用以作为《运营计划》的材料。
《运营计划》:根据每个版本,运营人员提交此文档,包括运营活动内容和所需的推广资源和资金支持。以及需要包括此次运营预计要达到的商业效果和衡量手段。
《产品部署、升级方案》:由开发人员提供给运维人员的技术部署方案。包括如何部署安装进程,设置CDN或DNS,运行SQL或者修改配置文件。某些团队会开发自己的产品部署工具,如Chef这类软件,用以自动化处理运维工作。
《产品统计需求》:由运营人员提交给运营开发人员,定义统计报表的格式和统计周期,描述每个表头的含义。运营开发人员根据此需求文档,开发统计程序,自动定期反馈数据报表给运营人员。
3、重点注意
一般游戏的持续更新,需要遵循一个版本列车的设定:
由于开发的内容有长有短,所以开发过程中的代码必定要维护多套版本分支,这需要在SVN上做严格的定义: