一个VR游戏DEMO的开发历程是怎样的？_网易科技
一个VR游戏DEMO的开发历程是怎样的？
用微信扫码二维码
分享至好友和朋友圈
VR现在似乎是个火热的话题，但在国内又毫无意外成了个看不清的迷局，就像充满极客精神的比特币来到这片神奇的土地就成了个投机工具。在一片觥筹交错中，真正在开发VR内容的团队其实是挺屈指可数的，这期间有钱有实力的大公司可能在观望、等摘果。我觉得这是个正确的选择，你让大公司创作可能还真创作不出什么东西来。具备技术实力的游戏公司在专注于如何卖更多的装备。项目型的中小三维技术公司苦于应付各种客户，维持捉襟见肘的现金流，所以能出来一个还算有点样子的VR内容真的比较稀罕，一问干嘛呢，大家都说在做VR，就是没有出来东西。但是能够理解的是，毕竟是一个新事物，大家的起点和时间都差不多，这个时期一起沟通和学习就成了个正事。为了和做内容开发的同好们分享一下我们最近的进度，先放出一个参加CHINAJOY展会的送审资料片（点击视频观看），抛砖引玉，分享学习，一起围观。我们不妨来一起来看看一个VR DEMO的开发历程究竟是怎样的。先来看几张前期的美术设定图：美术设定无论在影片、游戏还是VR里都是在脚本后的技术执行流程中的第一环节，为后续的环节提供视觉指导。下面把大家可能会关心的开发环节简单介绍一下：1、关于开发一个具有一定体量的VR DEMO需要的时间60天前在我们的会议室的桌子上摆了一本叫《UNITY从入门到精通的书》，我们也搞不清楚这个开发时间是不是好事，是否容易被人认为是另一种“中国速度”搞出来的玩意。后来我们换成了UE引擎，当然UE有可能会挺高兴的，你看我们的引擎多高效，效果多好，蓝图多么便捷，商城资源多么的好用……另外需要指出的是其实这60天的时间不是零基础开始的，我们这个团队岁数偏大，基本都30+了，都有十年的基础三维美术经验积累，并且长期扮演乙方角色，导致在技术落地和时间观念上比较好。加上这个是自己在创作东西，大家投入的状态比较彻底。所以我说这是一段奇特而幸福的时光，当然付出的代价也是很大的，这期间我们没有接任何新的业务单子。2、关于开发VR用什么引擎其实用什么真的不重要，之前也看到知乎上面大神们的各种机灵文章探讨VR开发是用UE还是UNITY，意见几乎是一边倒的倾向于UNITY，类似用UE就会掉坑里……但我们研究了一阵觉得我们还是适合用UE，然后现在也还相对幸福地活着，《小马过河》的故事都读过吗？我回忆了一下我们之前用的工具：MAX和MAYA。这俩都好，看你干什么用，如果是做建筑动画，就用MAX，因为快；做角色为主的动画电影，就用MAYA，动作模块好用，利于团队协同。另外其实现在UE已经特别用心在做，看他的官方教程，商城一看就是下了很大的功夫，而且蓝图这个工具也特别合适偏视觉的团队去使用。但看UE官方的公众号每次的阅读量都少得感人，与国内这么火热的VR题材形成有趣的反差，真不知道都在关注什么号。还有个比较大的问题就是UE会的人比较少，我们只能花时间自己去摸索，现成的人不好找，这种方式叫死磕。3、CG团队开发VR的优势和劣势我觉得我们的优势还是在视觉设计上，比如我们认为不同的场景，作为交互工具的Vive手柄也应该有不同的主题，于是就出现了各种漂亮的手柄，我觉得都可以上官方商城了。现在国内做VR内容开发的出身我觉得可以分成几种：第一种是技术门槛相对较低的全景视频&，这个大部分出身是之前搞实拍的，之前的名头一般是导演。第二种是游戏公司，优势是在程序以及工作流程上和VR比较类似，容易在技术上转型，但尴尬的是如果想追求视觉效果的话最好是做次世代游戏的，但国内现在基本上都是移动端的网游路数，做次世代又以外包加工为主业。第三种是之前CG行业的，就是我们这种，优势是对视觉比较有追求，国外有一些现在做得还挺好的团队之前也都是这个路子，但需要在技术上做一定的升级和转型，但好在底层的原理是类似的，一说都能明白。第四种是程序猿团队，优势是能开发出来比较牛X的代码，写自己想要的shader，弄出来自己想要的功能，需要使劲的地方是怎么把东西弄好看了。最后还有一种是说自己是做VR的。4、UE引擎的蓝图蓝图是UE专门为了提高工作效率开发的一个可视化模块编程，这个东西对我们的帮助很大，没有它我们的DEMO出不来。举一个栗子：DEMO后半程出现的你的双臂变成了翅膀，你挥动翅膀飞向苍穹，来到一片水天一色的盐湖，翅膀化为漫天飘散的羽毛……好浪漫的场景。实现这个东西就需要借助蓝图的帮助，当然我们这个标注非常接地气，能看懂的一定能看懂。是不是有点像这个：每个人连的节点风格也各异，这是飘逸风格的。总之，这是个全蓝图的DEMO，没有写一行代码，听起来不够高大上？其实UE开发蓝图是为什么呢，不就是让你把精力放到对最终效果帮助更大的事上吗，适合你团队的流程就是对的流程。5、另一个技术点：PBR流程PBR流程说起来还是游戏行业借鉴了CG行业引入的，但惭愧的是我们在CG行业后期因为项目类型的原因连UV都很少去展。PBR材质系统可以让物体在引擎中表现出更加真实的质感与丰富的细节，这也是这一世代游戏引擎的通用材质系统，美术师在工作时以更符合现实世界光照原理的逻辑绘制贴图，调节材质。基于这一系统的Substance Tools系列工具软件将贴图、材质、shader等系统由原本的多软件工具协作整合成一个完整的系统，同时灵活的工作流极大地节省了制作时间，方便系列化贴图材质的迭代与更新，让材质贴图工作环节更直观，高效。使用软件Substance painter，这个流程比我们早年PS和MAX展平贴图之间来回倒腾好了很多。6、更多的技术类干货：因为在文章里没法写太多的技术玩意，要不就成教程了……后续我们会放出一个有干货，非花絮的纪录片，时间长达半个小时可能，里面完整的记录了整个开发过程，今天先有个预告片（点击视频观看），风格比较诡异，是个刑侦范，但正片没准又会换成文艺清新……以下是艺术创作部分技术很重要，但面对一个新的视听体验方式，创作Very重要，更是VR体验设计的难点。7、关于VR体验的选题我们选的这个其实是个比较冷门的题材，现在能看到的大部分VR是打枪题材，我觉得我们好像对文化题材更感兴趣，再加上我们有几位同事都是航空迷，就选了这个题材。我们注意到在STEAM上有个国外团队做的阿波罗登月的体验，就下载下来学习了一下，但我们认为他给我们的是一些错误的经验，这个团队我认为是一帮闷瓜工程师，太闷了，受不了。文化输出是个我们比较擅长的东西，这可能和之前的工作经历有点关系，而且应该用新的技术做点有意义的东西吧，打怪必须要有，但要是都打怪就不对了。我自己的总结是，题材最好是你自己喜欢的，有深入研究的，然后又是适合VR表达的就是好的题材。8、VR的叙事语言会和之前有什么不同从创作角度来说，之前导演手里攥着摄像机，让你看哪就看哪，还有蒙太奇什么的逗你琢磨；但在VR的世界里，你就是临场参与者，导演需要引导你去看他希望你看的、参与的。从2008年开始我们参与策划执行了好些现场活动，我觉得这个经验其实和VR是有相通之处的，在一个很大的空间中，在哪闹动静，哪给光，如何引导视线，推动情节发展，都是个有讲究、好玩的事情。所以我觉得VR的视觉语言不是影片路子，而是个现场活动或表演的路数。从技术流程上来说，原来的合成和剪辑岗位退休了，但是呢，又没有全退，还在但只是换了个平台，UE里居然加了非线编辑，也可以有后期滤镜什么的，真是有趣。9、关于流程和分工前后大致有20个左右的人参与，大部分的人员会集中在三维美术素材这个岗位，和游戏开发的人员分布类似。有一位导演，我们正直的朴岸老师来统筹整个事，在艺术上做把握，然后我和其他同事会一起配合从技术流程上往前推。10、总结一些坑
从根上说，可能开始这个选题有点大了，好处是对整个试听语言的探讨会更充分和深入，坏处就是导致要做的资源特别多，虽然我们在过去的十年中是个特别擅长做大体量，贩卖伟大的团队。但在有限的时间内会导致有些资源精度做得还是不够到位，如果时间再多点就会更好。 预计有可能爬不出来的坑居然很幸运的没遇到，总是逢凶化吉，比如开始觉得这么多物件最后肯定会卡成翔，但通过合理的加载和隐藏居然在帧率上还好，就是其实引擎的承载力比我们想象的要好。小经验：先用一般的显卡调，因为考虑到要发布到STEAM，你不可能要求所有人的显卡都很好，我们这普配的是GTX960、970，需要调到大部分关卡都很流畅，最后展示机上再上个GTX 1080，效果就更好了，我这写的虽然糙，但都是好用的。小提醒：自己做东西的话把版权的事情处理好，别瞎用，该买的音乐买，如果不是商用的最好招呼也都打到，不要学CCAV……
本文来源：雷锋网
责任编辑：丁广胜_NT1941
用微信扫码二维码
分享至好友和朋友圈
加载更多新闻
热门产品:　　　
:　　　　　　　　
:　　　　　　　　　
热门影院：
阅读下一篇
用微信扫描二维码
分享至好友和朋友圈【演讲纪实】日本开发者：引擎和语言技术并不会教你怎么把游戏做的有趣
编辑：小蜂
发布时间： 20:51
在今天（10月28日）进行的Cocos 2014开发者大会下午的议程中，集中了来自史克威尔艾尼克斯、Aiming、gumi三家日本公司的技术代表登台演讲。
　　在今天（10月28日）进行的Cocos 2014开发者大会下午的议程中，集中了来自史克威尔艾尼克斯、Aiming、gumi三家日本公司的技术代表登台演讲。日本开发者以自家产品的开发经验带出对Cocos系列引擎的看法与建议，在许多地方有较高的一致性，本文一并为您报道。SE畑圭辅：运营中不怎么动的部分一次性做好　　首先登场的是来自史克威尔艾尼克斯第9分部的经理/技术总监畑圭辅。这是一位从PS时代开始游戏开发的老兵，拥有11年的游戏开发经验。他带来的产品是《勇者斗恶龙怪兽SUPER LIGHT》（以下简写为DQMSL），借助国民RPG的强力IP，本作当前在日本表现良好，他介绍了其开发过程中的几个经验要点：　　1.界面使用CocosBuilder来做。界面在运营过程中基本不会动，所以就算复杂，也可以一次性做好。　　2.将纹理贴图都做成SpriteFrame，可以在不大幅增加容量的前提下，丰富游戏的表现力。（龙虎豹注：这一点是日本开发者普遍惯于采用的）　　3.运营过程中，将游戏内容分成动静两边。程序是尽量不去动的静态那一边，因为这涉及到游戏的提交和再审核问题；而角色数据、活动数据则可以从服务上下载，是动态的一边，游戏的更新就用这边来做。　　4.自制了一款基于浏览器的地图编辑器，大大方便了设计与策划人员的工作。　　介绍完游戏开发经验，话题就来到了对Cocos2d-X引擎的评价上。畑圭辅认为该引擎拥有很多技术文档、免费开源、可从Cocos2d-iPhone引擎移植、支持Win/Mac/Linux多种开发平台等优点。但他也指出该引擎的一些缺点，比如日本开发者十分喜欢Sprite功能已停止技术支持，所以在开发过程中遇到什么问题的话也没法解决；此外存在内存泄漏的问题；还有就是对安卓设备的支持还不够好，特别是在应对各种机型不同的分辨率这一点上。　　对于这些问题的，他给出了自己的建议。他希望之后Cocos引擎能支持Android L和最新的硬件。另外当前引擎的XCode Warning实在太多，影响开发者心态，希望以后能减少甚至做到看不到，这一条在会场内获得不小共鸣，据说与会的开发者说多的时候一下能有几千条，确实让人泄气。还有就是希望将来能有iOS和Android平台通用的纹理格式。　　最后话题回到了基于Cocos 3.x引擎的升级，DQMSL游戏将来会做的升级。首先用到3.x之后，将会采用C++第11版来简化代码；其次会使用3.x的纹理自动匹配功能，提高效率；第三，将会抛弃以往性能低下的自制卷轴视窗和单位栏位，使用CCTableView这一功能；最后一点，将绑定Lua语言，借其简易性，许多内容可以直接让策划人员来写。当然Lua语言的导入存在风险，非技术人员的策划容易写错是一点，另外也容易被外界篡改。对于后者，畑圭辅表示将把关键性机能都留在服务器端，校验操作的合理性，对非法数据进行排除。Aiming：活用资源，页游变手游　　Aiming公司派出两位演讲者，分别从开发理念和具体技术两个方面进行分享。宣扬开发理念的是该公司的CTO小林俊仁，这也是一位有着十年以上网游研发经验的老兵。他先介绍了Aiming这家专注于网游的公司，该公司具备从策划、开发、制作到运营的全线能力，产品全面覆盖PC、手机、平板等各种平台，员工近400人，主要业务在东亚到东南亚地区展开。这家公司又一个理念很让人佩服，他们认为“核心网游在手机上也是可能的！”还大方的分享了日本游戏的盈利水平，如下图：　　小林先生介绍了Aiming公司的游戏开发方法：首先他们会去推测1年后的流行潮流是什么，来进行立项；其次不纸上谈兵，调少数人开始做核心功能的开发，不断以“这么做是否有趣”为标准检验开发的方向性，这一过程中遵循PDCA循环；当确定立项之后，才将更多开发人员调拨进来，该公司会为项目定一个发布时间点，只有在第二个验证环节大幅拖延做不完的情况下，才会提前加人手进来；最后在iOS和Android平台两边共同发布。　　接下来他以公司当前的热门产品《剑与魔法的境界》为例，具化了上面说到的方法。这部作品原本是以FLASH制作的PC端页游，他们对其做了减法，保留1.可见遇敌、团队战斗；2.角色动画系统；3.即时聊天等核心趣味点，试图将其手游化。但做的过程中发现工作量接近重做一款新游戏，于是就按一贯的方法做了一个核心原型，简化战斗、合成系统，缩短任务时间，都是在这个原型上调试出来的，这一原型还能帮助尽早发现BUG和问题，及早调试。这样不断试错的开发方法可以降低学习成本，让新人来了也能迅速派上用场。　　之后同一公司的技术主管神部公辅登场，他是《剑与魔法的境界》的开发者，并且从2006年本作还是PC页游时就一直做过来。他着重讲了该作品的角色动画技术。　　神部表示，《剑》作从特效、角色、敌人到开始界面为止的各种动画全都封装到了Animation Asset的统一格式中。这是因为其动画资源都是从PC版直接拿过来的FLASH动画，约有1000多项。而当前最新的智能手机都不支持FLASH，所以他们要转换格式后再重新封装。为此他们做了个格式转化器，从FLA格式转换过来。之所以用FLA而不用swf，是因为后者想要获取其Linkage比较困难，而FLA只是简单压缩，获取其中的xml文件简单得多。　　格式转换过来之后，使用Cocos2d::Action来进行播放。他们在其中实现了很多功能，并独创了Skew和从FLASH中提取关键帧这样重要的功能，当然也放弃了一些FLASH就是用不了的动作。　　最后他还提到，将在Cocos引擎升级到3.x之后，在游戏中加入具有3D风格的效果，这将如何实现，最终效果如何，值得关注。gumi田村佑树：好游戏不是靠引擎和语言做出来的　　gumi的社长曾经来中国的大学深造，并在中国旅行，故而这是一家很有国际风范的企业，分支机构遍布全球，当然大陆台湾都有。登台演讲的是该公司的CTO田村佑树，2010年进入gumi，此前已经有12年的游戏开发经验。他作为实例的是该公司的《Dragon Genesis》，这和前面Aiming的《剑与魔法的境界》一样，也是一款使用FLASH素材转化而来，加以Lua语言做成的产品。其后他的演讲也一直cocos2d-X+Lua这一话题进行。　　首先田村评价了Cocos和Lua的各自的优劣。他认为Cocos苹果安卓平台通吃，善于开发2D游戏，开源且免费。但也存在自身各版本间不兼容、缺乏视频播放功能、开发《Dragon Genesis》时尚没有UI制作工具等缺点。　　至于Lua的优点，田村认为这种语言轻量化、文件小、编写速度快，而且能在iPhone模拟器上直接测试，想要测试下一版更新内容时，直接将模拟器的DLC文件夹练到更新DLC文件夹即可，能够做到立刻响应。不用做内存管理，有GC机制，可避免报错崩溃。当然他也提出了Lua语言的一些问题，比如想用Lua就必须构建模组系统，而且Lua中常见的全局变量在任何情况下都是很危险的，必须要做GC机制的设定而非可选项。另外这一语言非常简单，想在其中实现类的功能，对原型的理解就有比较高的要求。gumi所用开发语言　　其后他略黑了一下Unity和C++。他认为Unity是黑箱操作、繁琐不够轻量化，而且这一引擎不熟悉主机游戏的开发，对日本有经验的开发者来说不够友好。至于C++，众所周知这种语言需要不断的调试和除错，但偏偏它编译时等待的时间又非常长，工时浪费很大。必须要做代码检查，不然就容易出现内存溢出、崩坏、挂起等问题。这样，当Lua和C++互相之间很容易进行配合时，选择这两种开发语言互补就成了必然。gumi的开发环境　　最后来到了田村先生全篇演讲的精华，他先表示希望能在Cocos 3.x中能加入DEBUG的功能，现有的调试几乎都在使用厂商自行开发的手段（这一点在之前的演讲中也有中方嘉宾提到）。之后他分享了做新游戏时的4点注意：注重趣味性、讲求平衡、注意网速和载入速度、在意收入。田村先生表示，引擎不是全能上帝，它只能解决游戏开发的技术问题，而不能解决游戏要怎么做的问题。游戏开发者应该更多地注重游戏性，把好的开发工具节省下来的时间用在考虑游戏性之上，龙虎豹对此表示非常的赞同。
由中国手游和大宇资讯联合研制的《新仙剑奇侠传》3D手游于4月9日11点正式开启内测，首日流水突破千万大关。.
2014ChinaJoy导游指南大全
18梦境异闻录超好玩礼包
剑侠世界豪侠礼包
三英逗曹操首发媒体礼包
蛮荒幻想封测畅玩礼包
(C) Copyright (C)
超好玩 All Rights Reserved&& / && 新手入门必读：一款手游的开发流程是怎样的？
新手入门必读：一款手游的开发流程是怎样的？
点击分享本文：&
手游行业的爆发，让很多人对这个高流水的捞金行业趋之若鹜，其中有刚毕业的小青年，也有半路出家转行进来的，不论怎样对于手游行业来说他们都是“新人”，所以基础知识就变得尤为重要了。本文将介绍游戏的一般开发流程，包括筹备、原型、发布和迭代。
1.筹备阶段：筹建团队，确定项目的基本方向。
2.原型阶段：实现一个游戏原型，发布Alpha测试版，以验证和调整预定的方向。
3.发布阶段：发布游戏的Beta测试版本，供内部封闭测试，做上线前最后的准备。
4.迭代阶段：完成对Beta测试版的修改，上线后按迭代周期，持续开发和调优产品。
在这些阶段中，我们都必须注意开发流程中的一些重要因数：
角色：定义一些角色，规定其工作权力和责任，避免过度讨论或盲进
交付物件标准：每个角色都必须按照一定标准来交付工作成果，避免在长长的工作链条中出现很多误差。
工作方法细节：由于游戏开发是一个涉及多个专业的复杂过程，所以这个过程中有一些工作方法，是必须要遵守的，否则将会严重降低开发效率。
作为一个完整的游戏开发团队（不包含运营团队），整体的结构应该大致如下：
投资人：根据市场状况和投资预期，提出商业目标和项目邀约，和制作人讨论并审核确定《产品方向》，制作《投资计划》，按计划安排资金投放，并承担投资后果。
制作人：根据投资人的商业目标，整理和组织市场调查数据和《竞品资料》，制订《产品方向》。根据《投资计划》组建核心团队。在某些项目里，投资人和制作人是同一个人。
核心团队：一般由制作人和主程，主策，主美组成，有些时候还包括项目经理。在某项项目里，制作人可能由核心团队里的任何一个人兼任。
项目经理：负责制订工作计划，监督进度，安排各种资源。初期可能会有很多秘书工作需要担任。在某些项目里，项目经理可能由核心团队中任何一个人兼任。
《投资计划》：由时间、金额、项目进度检查标准，这三列组成的一个表格。需要附带上修改日志和完成记录。
《产品方向》：一个具体的文档，记录了产品概念所依据的市场状况（数据）、竞品的情况（数据）；也记录了项目产品的基本情况：游戏的题材、游戏的玩法、游戏收费方法的基本概念，以及市场推广、运营的基本思路。
《竞品资料》：罗列所有主要的竞争对手产品的情况，包括产品市场数据，开发方案（如能搜集到），评测资料，用户反馈等。需要由制作人持续更新关注，随时整理添加。
产品概念讨论方法
针对用户特性：游戏产品形态非常丰富，细节也很多，所以在讨论任何设计的时候，都必须按照既定的用户画像来做标准判断，避免大而全或者钻牛角尖。在各种“调查报告”无效的情况下，邀请几个目标用户作直接沟通，往往能获得最真实、最有效的情报，不用过于担心“代表性”不够，因为共性往往是比较明确的部分。
针对竞品：在用户、市场情报不够充分的时候，竞争对手能提供最直接的产品信息。通过分析竞争对手的产品，特别是跟踪竞争产品的变化，就能猜出用户和市场的反馈。就算本产品的竞争对手不多，方向相似度不高，只要是目标用户群体接近，也可以通过竞争产品的用户感受来了解用户心理。切记闭门造车，不接触市场风潮。
不应该深入的部分：在筹备阶段，容易陷入头脑风暴，所以我们不应该深入讨论产品的开发过程、开发工具、开发人员。对于产品的细节，也不宜过细，但应该找出一些简单明确的概念来代替，如“经过XX修改的竞品A”这样就很好。
团队缺人对策
招聘渠道：首选熟人朋友圈，其次毕业生和培训机构，最后是网上投递简历。由于现在的培训机构一般都需要签就业协议，所以对于创业团队，小型公司来说可以作为一个比较稳定的人员来源。大型公司最好就是各种高校的招聘会了。猎头也可以考虑，但是对候选人需要仔细甄别。
选择简单的工作方法：缺人的情况下，往往是缺牛人。所以一定要选择简单的工作方法，各种高大上的流程，一定要在有IT技术保障下实施，不要直接推行而不顾实际情况，这些可能有问题的方法包括：定期汇报制度、全自动化项目管理、没有足够储备的技术开发方案等等。
培训准备：根据初期可能到职的人员，进行基础能力的培训，比如SVN的使用，BUG跟踪系统的使用，基础的开发技术、美术、策划文档标准。这些培训都是需要多次进行，所以应该先准备好培训资料，避免新成员入职措手不及。时间控制
会议：筹备阶段大概有一半的时间是在做沟通，因此会议时间需要特别控制。要严格遵守议题议程。如果有遗留问题，应该有专人搜集整理并且跟进，而不是在会上去解决。因为会上提的方案，往往没有自己在认真思考的环境更完善。另外就是避免“挨个报告”那种没有明确议题的会议。这种沟通了解放到其他时间，少部分人沟通会更清楚。
招聘期限：根据经验，核心团队具备的情况下，要组建到项目正式启动的团队，基本需要3个月左右。假如接近3个月都没有什么进展，应该和投资人反映，并研究解决方法。一般最简单的就是提高工资和雇佣猎头。
原型(Alpha)阶段
主策：提出产品原型的概念，交付《项目总体设计》，并协助原型开发，突出产品特点。
主程：选择技术方案，定义美术、策划资源的技术标准。搭建开发环境，编写产品原型。在客户端开发方面，和美术同事合作，调整原型效果以达到测试的目的。
主美：选择美术风格，在策划和技术的共同讨论下，确定各美术组件的基本技术标准，如大小、尺寸、容量。并且确定美术资源的格式。
项目经理：有些团队由制作人、或者主策兼任。此阶段在明确游戏原型后，产品、技术、美术人员都会需要各自开发一些内容，然后再整合到一起。因此项目经理应该负责组织大家共享这些信息，一起讨论和评审各阶段产品，确保各环节不脱节。
《项目总体设计》：规定了游戏的题材、玩法、收费模式。确定游戏的重点乐趣和表现特点。列出游戏的长期开发计划所需要的系统、关卡、内容纲要。作为后续策划工作的总需求列表。
《美术风格指导》：以实例原画图来规定整体美术风格。
《美术资源格式标准》：对游戏原型的美术资源格式，做出标准规定，包括美术文件的格式、尺寸、精度标准、命名、SVN路径规则等。
开发环境：SVN服务器地址、BUG跟踪系统地址、IDE选择产品和版本、开发和测试的内网服务器、演示用外网服务器。
《技术方案选型方案》：开发游戏所用的客户端和服务器端引擎、框架版本；程序的基本模块代码结构；项目文件目录规范；测试和CI方案；技术难点的预设解决方案。
可运行的原型产品（DEMO）：突出表现游戏核心玩法和美术风格的一个程序，可以是一个单独的游戏关卡。
原型开发阶段，主要目的是验证产品的基本面问题：题材和玩法的融合是否合适，美术风格和技术实现是否能达到策划的初始目标，有没有一些难以解决的基本障碍。需要特别注意的，开发原型所需要耗费的资源制作和逻辑编写时间，因为这反应了后期游戏持续更新所需要消耗的成本。
另外，由于游戏原型的制作，也带出了个制作环节的沟通问题，所以必须注意从一开始就积累和订立各工序的交付标准，如策划案应该包含图量表、测试方案；需要预先沟通美术草图并签名；美术资源格式需要确定；游戏原型的测试环境设置。——这些标准和接口往往会变动，但是需要预先明确这些接口流程。
发布(Beta)阶段
技术开发团队：
客户端开发：开发和优化客户端代码和单元测试用例、文档，完善客户端程序打包、发布的CI流程
服务器端开发：开发服务器端代码和单元测试用例、文档，维护项目数据库，安装部署测试环境
测试开发：维护和管理CI系统，监督运行单元测试用例，开发专项测试如性能测试、自动化冒烟测试。
《策划需求文档》：重点说明要达到的产品目标，使用的主要设计手段
《策划案》：产品使用流程图，GUI草图，须配置的游戏数据项目，美术图量表以及风格参考
《草图》：美术风格参考，UI构图
《技术设计方案》：代码模块命名以及职责，代码结构模式及关系，重点技术问题解决方法
《美术资源格式》：文件名和路径规则、文件格式、精度、尺寸或其他更细节内容
《游戏数据格式》：库名、表名、字段解析、字段内容结构
《Bug报告单》：策划案ID、重现步骤、现象
此阶段是建立稳定完整的版本开发流程最重要的阶段。关键点是各交付件标准的严格遵守和流程监控。项目经理须组织对于流程、标准的讨论和确定，并且监督这些规定的执行。由于每个游戏都不一样，所以这些流程和标准都会有所差异，项目经理要随时应对不同的策划案，即时组织大家建立流程标准。另外需要准备发布的工作，包括宣传资料，测试环境，运维工具等工作，也需要花时间准备。——在发布前至少安排一周时间来做发布前的准备，和运营、运维、客服人员做好沟通和交接准备。
1）开发团队：依照迭代标准开发迭代所需内容。
2）运维团队：
运营人员：负责推广、发行工作，提供技术资料给运维人员做产品部署，关注产品数据和运营情况。反馈意见给开发团队。
客服人员：辅助游戏推广，提供玩家咨询、故障报告、投诉处理、事故安抚等工作，需要运营人员和开发团队进行持续的信息共享。
运维人员：提供游戏的部署和监控工作，开发管理运维部署工具。准备硬件资源和运行环境。有些运维工作由开发团队中的服务器端程序员一起分担。
运营开发人员：开发“GM系统”给客服人员使用；开发“数据统计报表”和“活动系统”、“官网”等系统给运营人员使用；某些游戏团队由服务器端程序员兼任。
《版本发布计划》：每个版本开始开发前，都需要编写此计划，列明本版本内需要开发的内容，预计时间，以及开发设计人员名单。此计划需要提交给运营人员，提早准备《运营计划》中的推广活动和安排推广资源。
《版本发布说明》：每个版本进入内测后，由开发团队编写后，提供给运营人员，包含本版本的所有在产品上的变更细节。以及这些版本内容的开发成员。供运营人员培训客服掌握，以及运营人员自己做测试，用以作为《运营计划》的材料。
《运营计划》：根据每个版本，运营人员提交此文档，包括运营活动内容和所需的推广资源和资金支持。以及需要包括此次运营预计要达到的商业效果和衡量手段。
《产品部署、升级方案》：由开发人员提供给运维人员的技术部署方案。包括如何部署安装进程，设置CDN或DNS，运行SQL或者修改配置文件。某些团队会开发自己的产品部署工具，如Chef这类软件，用以自动化处理运维工作。
《产品统计需求》：由运营人员提交给运营开发人员，定义统计报表的格式和统计周期，描述每个表头的含义。运营开发人员根据此需求文档，开发统计程序，自动定期反馈数据报表给运营人员。
一般游戏的持续更新，需要遵循一个版本列车的设定：
由于开发的内容有长有短，所以开发过程中的代码必定要维护多套版本分支，这需要在SVN上做严格的定义：
【扫描游戏陀螺微信二维码，获取更多干货爆料】
有事没事说两句...
图片正在上传，请稍后...
未输入评论内容
“封杀”盒子后的产业变局
客厅落入牌照方
同行成“冤家”
冒充发行骗取CP测试包，目
VR内容平台：内容审核流程、支付解决
在中国游戏圈消失的一百万种方式
完美世界对外宣部获得CS:GO国服代理权
分众传媒领投
应书岭的英雄体育完成6.4亿
上半年48起融资案例分析
近百亿资金流向这
【西游】海外创意游戏之旅
鸿儒会上忆青春：10多位行业领袖共话游戏
电视人的新旅程：错过跑男？走，让大明星}