当产品立项通过以后，开发团队的人员到位需要一定的时间和准备。在这个过程中还有更重要的事情要做，就是将如何制作的前提条件和版本计划梳理清楚。
框架玩法：立项的时候，游戏的核心玩法已经确定了，Demo预演也证明了玩法的可行性。但游戏最重要的是好玩，好玩是一个体验过程，所以任何核心玩法都是需要进一步丰富和包装的，并且围绕核心玩法搭建起来一系列的行为模块。比如角色要如何成长，引导和支撑玩家行为的内容有哪些，游戏产出什么消耗什么等等都是需要考虑。这些内容一般都是由游戏策划来完成，而设计这些功能内容的策划，一般称之为系统策划。
风格规范：这里的风格规范主要包括的内容有游戏故事背景的设定，这决定着游戏的题材使用的是玄幻、魔幻、武侠、科幻，美术风格是用写实、Q版、3D还是2D，然后进一步决定着游戏世界里的角色构成，背景架构，故事脉络等等。光这些还不算完，涉及到具体实现的话，美术还需要进一步确定场景、角色、界面、音乐音效这些资源的表现方式，以及制作尺寸。比如场景和角色要限制在多少面数以内，界面主要用多大等等，这些还需要程序参与进来，结合使用的技术方案和引擎框架一起进行评估，甚至在这个过程中就需要开始进行一些测试来验证结论了……”
flyingtiger的文章动辄就是长篇大论。
除了介绍游戏立项规划中的内容之外，还不厌其烦的科普了很多游戏设计开发以及游戏上线有关的诸多内容：
“设计开发是游戏开发中最核心最关键的地方了。
这个环节的任务那就是真枪实弹、一点一滴地将产品做出来。
这个环节有如下几个步骤。
首先是方案设计，也就是明确需求，这种需求可不能停留在“我要一个XXX”这样的描述水平上。一定要对XXX的构成，使用方式，规则流程有着明确详细的说明才行。
比如这个XXX是做什么用的，包含哪几个功能模块，使用流程图是怎样的；然后进一步细化每个模块是做什么用的，是否还有细分模块，流程是怎样的，依次往下……
有经验的策划，应该要站在玩家用户的角度上，模拟玩家是怎样操作的，页面是怎样跳转的，这个也就是Page-Flow。
当然，也可以有更专职做界面设计的策划负责设计Page-Flow，同时给出页面大小、布局还有素材要求，这样给到界面需求，美术就能更方便地制作出来了。美术资源的需求除了界面，可能还包括有场景、角色，还有一些图标icon、音乐等，也都是在策划设计阶段制定出来，如果策划自己比较难理清楚，也可以找相关的制作帮忙一起设计。
在这个阶段，测试已经可以开始开展相关的工作内容了，也就是参与到“需求评审”中来。这个一般由策划发起，程序、美术、测试甚至运营参与，以小组会议的方式开展。目标是审查设计逻辑，评估工作量，制定具体的开发计划。
程序编码，美术绘图。当需求确认了，开发计划也排好了，就要动手开始制作了。这里最主要负责的就是程序和美术了，编码和绘图这两个过程一般是同时进行的，所以放在一起说。先说程序，除了单机游戏，目前几乎所有的游戏都是要联网的，也就是程序开发至少要分为客户端、服务端两大模块，俗称前端和后端。前端主要负责表现，后端主要负责计算。当然，也有一些游戏也会放在前端进行计算，后端会收到计算过程和结果进行复验。如果你的游戏只有前端计算，那么很容易被破解，被外挂利用刷奖励等，极大影响了游戏寿命。点击介绍游戏制作的构成。美术制作过程也比较漫长，尤其是3D资源，要先画原画，再建模，这就需要至少两个美术。所以美术资源也会大量外包，包括音乐、动画、图标等这些内容。外包的时候一定要注意，除了说明美术需求以外，还要明确制作和验收标准，甚至还要有一些商业保密协议，不然对方交付后不满意，来回的沟通扯皮，这功夫还不如自己画呢。
在这个时候，测试也要同时开始自己的工作准备了，分析文档，写测试用例，具体的做法请参考如何写测试用例。当程序开发完成后，可以先开始验收测试（一般也称之为单服测试）。目标是验收程序开发的完成度，确保需求的实现。单服测试可以有很多种，可以程序自测，也可以叫策划或测试进行验收*。大部分情况下，验收程序开发的时候，美术资源还没完成，这个时候最好有一些临时资源进行替代，而不是要等到美术资源到位了才去验收。因为单服验收后，程序代码必然会有调整，甚至要进行二次开发。测试在单服验收的时候，也可以与自己写的测试用例进行对照，根据程序的实现方式，修改测试用例中不一致的地方。
配置联调。当程序编码已经完善了，美术资源也制作好了，策划的需求都基本得以实现了，这个时候还不能称之为完成，因为还没有将这些素材良好地组织起来。这就需要策划以配置表或配置文件的方式，将美术资源在游戏中安排好，比如什么场景里要放置什么NPC和怪物，还要填充大量的文本对话、说明文字和数值公式等。当策划完成所有的配置后，这个功能才算有了一个基础完整的可玩性了，然后就会通知到测试。功能测试中最重要也是工作量最大的工作内容要展开了：集成测试。
首先测试要跟策划和程序确认好要进行测试的内容所处于版本环境，然后对照着之前写好的测试用例，一条条地进行执行，记录过程和结果，并提交发现的问题，具体做法可以查看测试的工作流程。目标是全面验证功能逻辑的正确性，检查细节实现，以及与其他系统功能之间的影响性。发现问题后，要描述清楚，提交给相关的策划和程序进行修复，修复后再进行回归测试。点击查看如何记录和提交bug。
上线发布。当版本中所有的功能都差不多完成了的时候，就可以上线跟玩家见面了。这里先慢着，还有一些事情没做完：首先，运营要体验下这个游戏，然后提出一些建议和运营活动的需求。其次，手机游戏上线是需要渠道App进行推广的，比如Appstore、应用宝、微信等，这就需要接入这些渠道的SDK，这样游戏内才能使用苹果账号、QQ、微信等进行登录、充/值甚至加好友。如果你的游戏要所有渠道都发行的话，那么每个渠道的SDK都要接，这样最终打包出来的游戏App其实就是每个渠道至少1个（有些渠道还有细分领域，所以不止1个），这些我们统称为渠道包，渠道包彼此之间是不同的，因为接入的账号系统，充值流程都是不同的，甚至还有些要换图标icon，加渠道logo等等要求。而且即便上线之后，产品也很难免不出一点问题，有些问题玩家说明的很模糊，需要确认和在内网重现。这所有的一切，我们都先将其归结到发布测试当中来。
发布测试包含的内容不少，比如要做渠道包Checklist，要跟进外网问题，甚至还可以召集项目组里所有人，大家一起来体验游戏，查缺补漏，搞一次bug-rush比赛。目标是验证上线前修改的内容，最后整体快速地验证一遍游戏，并实时跟进线上问题，做好应对突发问题的准备……”
整篇文章科普的不可谓是不详细。
涉及到游戏开发的全部流程模块罗列出来也不过如此了。
能清楚这些游戏开发中的模块和环节的话，如果将来遇到了项目问题，产品没能成功上线。
在清楚全部流程的同时开发者可以整体地去思考问题。
分析究竟是哪个环节、哪些工作没有做好？
是产品方向有问题？是立项时没有严格审查？是市场调研不足？
是开发阶段有问题？是具体的开发人员能力不足？还是做版本计划的时候版本目标不清楚，工作量预估偏差过大？
如果是线上问题多，是开发阶段的质量把控不到位？还是后期调整太随意？
总之这样的文章在林灰看来还是有用的。
多一些这样的文章人们或许也会对程序猿的世界多一些好奇。
不过林灰看了一下flyingtiger这篇文章的数据，也只是收获了寥寥几百个的浏览量而已。
这数据其中是否有水分还不得而知。
额，果然硬核科普是姥姥不疼舅舅不爱啊。
这个flyiingtiger似乎也对此十分清楚。
虽然此人论坛中没少发那种长篇大论的硬核科普。
不过林灰感觉此人还是更喜欢发一些分析类的文章。
林灰大致看了几篇，不得不说此人这些分析文章也都蛮专业的而且很有深度，给林灰的观感还算不错。
