萌新小白，如何学会游戏开发和策划
萌新小白，如何学会游戏开发和策划
首先，你必须清楚地知道游戏策划的工作涵盖了多少内容。打个比方，假设你现在是在玩一款名为游戏策划的游戏，首先你必须找到你的技能树，并且看清楚，这课树的枝桠分向了哪几个方向，进一步确定你的额技能点到底应该怎么点（我本人做过文案策划和系统策划，所以这两方面讲的相对清楚一些）。
1.文案策划（RPG类游戏均需要的专业性人才）
简介：只要是RPG类的游戏，不管是mmo还是卡牌，只要这个游戏拥有剧情，它都需要至少一个文案策划。这一类策划负责游戏的剧情设计，角色设计、世界观设计、对白撰写、文本撰写、道具描述撰写、装备描述撰写、活动包装等等等等。简而言之，就是游戏之中所有与文字及ip相关的事宜，都是由文案策划负责。
必备技能：
（1）文字表达能力
最起码要做到逻辑清楚，表达准确。
进阶阶段就是要语言优美，文笔流畅。
再递进的阶段就是博览群书，言之有物，不管是引经据典，还是自写诗词样样精通。烛龙在招收文案策划的时候一般都会加上一句，中文系毕业最佳。
（2）设计能力
最基础地是要能够设计出一个体量较小的完整故事，也就相当于是网络游戏里的支线任务水平。这其中包含了角色性格设计、情节逻辑设计及最基础的部分玩法设计。支线任务这种程度，不可能有专门的玩法组来配合，只能依靠自己。
进阶阶段是要能够独立设计出至少100环的主线任务故事。在这一阶段，必须要做到设计出的人物不能走形，任务逻辑清楚有趣。但其实它本质上还是人物设计，并没有想象的那么困难。
再递进的阶段就是ip、世界观设计。牵扯到游戏历史、背景，包括游戏世界到底是怎么出现的，是如何一步一步衍化成如今这个面貌，涉及到多少势力、种族，这些势力、种族之间的关系如何，每个势力、种族经历过什么样的历史，有哪些英雄人物等等等等。
（3）看图说话能力
简而言之就是包装，不是所有游戏都能做到文案先行的，很多时候都是其他策划做好了装备、道具交给文案策划包装，也就是这东西到底叫什么，为什么叫这个。他们会提供的只有这个装备or道具到底是干什么使的，以及它到底长个啥样子。也就没有啥进阶能力，反正你只要包得足够靠谱就ok。
2.系统策划（是个游戏就需要的专业性人才）
简介：要了解这个工种，首先要知道什么是游戏系统。用比较学术的说法就是，具有某种功能性的整体，即为系统。用比较玄学的说法就是，你在游戏过程中，能通过感观体验到的所有内容都属于系统。做任务，有任务系统，打副本，有战斗系统，就算脱离了rpg游戏的壳子，玩儿个王者农药，你以为就没有系统了？那个蛋疼的符文，也是系统。不客气的讲，一个合格的系统策划，构建了游戏的底层逻辑。
在说到必备技能之前，首先必须看清楚一个系统都由哪些部分构成，请看下图。
这四大块共同构成了系统。一个完整的系统体验是什么样的？以windows窗口来举例。首先，用户先点击窗口右上角的小红叉，这之后程序后台在用户看不见的地方进行代码运算，最终得出关闭窗口的指令，并切实地在用户屏幕之上体现出来。这，就算是一个完整的系统操作体验。接下来我们将以上区块按部就班地一个个来分析一下。
ui界面，即用户界面，在游戏当中就是玩家所有可以被操作覆盖的地方。这项工作并不需要完全由系统策划负责，毕竟不是所有的系统策划都拥有一双美工的手。但我们必须要为之后负责此区块的人提供思路。例如，当玩家点击某个按钮时，是否需要弹出一个新的窗口，弹出的这个新窗口需要显示什么。或者，当玩家点击商城中的购买按钮时，是否需要弹出二次确认框，给玩家第二次的反应机会，避免误触操作。这都是系统策划必须考虑的问题。当然，如果你遇到一些过度负责的美工那更痛苦，他or她极有可能会让你提供灵感图，那么你还需要用到viso或ps手动给他拼一个。
底层逻辑，即这个系统到底干什么使的。这个问题看似简单，但其实……
举个阴阳师最简单的签到系统例子。签到系统到底干什么使的？这还不简单？不就签到使的吗！但是作为一个合格的系统策划，想问题绝不能这么片面。首先明确一点，什么是签到？就是玩家每次登陆游戏时，点击界面某个位置，即将作为签到的变量加一。同时每次的叠加，会给玩家发放一些奖励。奖励是否随机？这需要系统策划考虑清楚。当作为签到的变量累积到一定数值时，是否要再给玩家一份奖励？这需要系统策划考虑清楚。这个变量数值是否一直记在游戏服务端上？需不需要定期重置以减轻服务器的计算读取压力？这也需要系统策划考虑清楚。等到问题都考虑清楚了，再把他们整理成程序一眼就能看明白的流程图，大致如下：
代码构成，别害怕，一个成熟的游戏工作室一般情况下并不会让一个系统策划自己撸胳膊挽袖子亲自上前线码代码。但你应该清楚你的系统从程序方面如何实现，因为程序随时有可能在稀奇古怪的地方卡壳，并需要系统策划给出专业性建议。程序逻辑和运用程序语言毕竟是两回事，只要思路够清晰，应付程序暴风骤雨般的提问也是可以应对自如的。
维护管理，自己提的需求，跪着也要自己去维护。这是身为一个策划的职业操守，尤其是系统策划。有的是上线的系统被玩家喷得跟坨翔一样，于是只能回炉重造的。
３.数值策划（所有网游、RPG类单机，只要不是纯玩法类游戏都需要的专业性技术人才）
简介：是我个人认为的，游戏策划里最枯燥的一个工种，又累又枯燥。当年我所在的组里，数值组的大佬永远奋战在第一线不说，一到版本日，铁定加班的就是他们了。主要负责游戏投放概率的计算，阴阳师里就是ssr掉落的概率，王者农药里就是开箱子开出英雄来的概率。还有在mmo里，玩家下副本用不同的装备要打多长时间，都是数值大佬说了算。每次升级要攒多久，也要看数值大佬的计算结果。总而言之，就是通过复杂的计算，成功保证游戏的营收与玩家的收获绝对公正，但绝不成正比。
必备技能：概率论、高斯函数、微积分学的不好还是不要考虑这个工种了。
4.战斗策划（有技能的游戏都需要的专业性技术人才）
简介：主要负责游戏中所有与战斗相关方面的设计，包括怪物ai编写，怪物技能设计，玩家角色技能设计，简言之就是在游戏中战斗发生以后，除了双方打对方一下扣多少血，用多少蓝是属于数值策划的范畴以外，感受到的所有东西，都是战斗策划搞定的。所以如果农药某个角色玩儿的不爽，尽情去骂战斗策划吧。
战斗策划有时也细分成两种，一种叫技能策划，一种叫怪物策划。前者专门负责技能的设计，需要遍玩天下各路游戏，达到胸中自有技能的境界。而且在设计时必须考虑到技能平衡，完全依赖数值策划后期靠数值找平，那基本找不平。怪物策划主要负责怪物行为逻辑设计，简单来说，怪物行为主要有两种可能，一种是think，一种是ai。think由程序写死，怪物策划只需修改一些数值即可，一般针对一些比较傻的怪物，看到你扑过来就是揍，看不到你就原地站着不动，这就是think。ai控制则相较而言复杂得多，要考虑怪物什么时候扑过来，扑过来用什么技能，扑过来的时候要不要跟你说句话，简单说，ai控制着所有think无法完成的行动。
必备技能：
（1）起码要熟悉主流游戏的所有技能、技能成长，能够设计出足够合理的技能，并能够胜任不同个体间的技能平衡。
（2）逻辑思维清楚，能弄明白如何编写怪物ai。
5.关卡策划（拥有副本的mmo游戏需要的人才）
简介：现在市面所见的所有pc端的mmorpg游戏，不管是魔兽、剑网三、最终幻想15、天涯明月刀还是天谕都有副本系统。此系统作为mmo游戏的主要玩法，几乎决定了一款mmo的胜败。而决定了这个游戏好不好玩的，除了有些玩家特别讲求的打击感外，还有一个因素，就是各个关卡做得是否独到、有趣。这就需要关卡策划来出谋划策了（有的游戏会用其他策划来兼职这一工种）。
作为关卡策划，要对自己游戏的战斗系统非常了解，要能设计出具备可行性的关卡结构，即负责副本ai的编写。副本ai控制什么时候放出什么样的怪物，该怪物死亡会对副本产生什么样的影响，如果需要出现阻挡玩家进入下一关卡的空气墙，则该空气墙在玩家做了什么操作之后会被消除。这些都需要关卡策划考虑。
必备技能：
（1）起码要熟悉主流mmo的副本关卡，并能够设计出足够合理的副本。
（2）逻辑思维清楚，能够完美地统和副本系统及战斗系统。
（3）具备创新性，起码知道怎样才能做出现在市面上没有的副本关卡来，不然怎么吸引玩家留存？
如何快速开发一个小游戏
如何快速开发一款火爆的小游戏？“火爆”是一个偏运营的词，在小游戏上线120天《微信开发者》公众号有一篇推文，其中有几个数字或许可以用来描述“火爆”这个词。截止微信小游戏正式允许第三方开发者发布已有22天，对外发布的小游戏达300多款，注册用户总规模过亿的游戏有数款，安卓月流水过千万的也有数款。
该文还提到与火爆相关的两个姿势。一是社交匹配度，在小游戏这样一个去中心化的大背景下，让游戏内容和微信社交相结合是一个很重要的点，同时开发者也需要在利用社交互动提升用户体验和群聊分享造成用户骚扰之间选择一个平衡点，过犹不及。第二是操作简便度，说的是游戏易上手操作简单。这是我们根据游戏成为爆款后观察得出的结论，并不是说具备这两个特性就一定能开发出一款火爆的游戏，并且新的爆款游戏也不一定符合这些特点，仅供参考。
今天介绍的内容更倾向于技术方面，所以“火爆”就从标题里面去掉了，并且也不会介绍具体的游戏逻辑如何开发，而是更偏向于如何利用好微信的开放能力开发一款小游戏。
什么是“小游戏”？小游戏是什么？
首先为大家介绍一下小游戏是什么。从普通用户的视角看，小游戏是小程序的一个子类目，可在微信内被便捷的获取和传播，即点即玩，具备出色的用户体验。小游戏是小程序，普通用户分不清也无需分清。
小游戏Runtime
如果放大小游戏的Runtime可以看到很多的细节，这是一个典型的分层架构：
最上层蓝色部分，是游戏代码，分为游戏逻辑，游戏引擎、weapp-adapter三部分。大部分游戏开发会用到一些引擎的工具、工作流，以及利用引擎封装的高层API去实现游戏逻辑。其次是weapp-adapter，因为小游戏的底层一方面不是webview，可以简单看成是webview经过精简、优化过后的平台；另一方面核心能力的实现上却参考了webview。所以这里如果有一个适配器，把小游戏的底层API——wx API适配到一个接近webview的接口，对上层引擎、已存在的游戏接入微信小游戏平台则会更加容易，这个就是weapp-adapter的作用。其中只有游戏逻辑是必要的。
可以看到，在架构上小游戏和小程序是有差别的，小游戏没有页面概念的，wxss/wxml不再存在。其次，底层实现也不是webview，小游戏和webview的关系只能说是渲染相关的核心能力可以通过weapp-adapter的简单适配保持接口一致，但同时很多webview上存在的功能并没有对等的实现，比如小游戏就没有DOM/BOM的概念，也没有全局的document/window对象。
小游戏的入口为game js文件，语言为Javascript，但有一些限制，比如禁止执行动态代码，因此eval、new Function等能力是不支持的。配置为game.json，可以配置横竖屏、接口超时等参数。js里面可以组合wx API的能力来实现游戏逻辑， 非代码类的资源应该尽量放到cdn，减少整个代码包打包后的大小，以加快用户首次进入时的速度，微信对首包的大小目前限制为4MB。
Webview Adapter
下面来说一下Webview Adapter，它的初衷是为了让游戏开发者更好地熟悉我们的平台，所以我们的平台在能力上会尽可能地与webview做一些适配，其实这个适配也是很简单的一层。比如说我们在浏览器里面使用image对象创建一个图片，而在小游戏里是通过wx.createimage来创建的，在代码中需要做一个简单的适配。
以此类推，常见的Canvas、document对象都是在Adapter中通过一个简单的适配实现的，大家可以研究链接中的代码。之后官方不会继续维护这个Adapter，我们会更专注于底层能力的建设。
小游戏能力概览
下图是小游戏能力的概览，小游戏能力的迭代比较快，部分能力还没有来得及罗列出来。比如最近刚发布的游戏圈、健康系统防沉迷相关的一些接口。
我们先看一下基础能力，在渲染这部分WebGL1.0和Canvas 2D都是支持的，这里的Canvas更接近于浏览器里面的标准。同时，这里提到的可控帧率的概念，如果小游戏在后台运行的话，可以尽量将帧率降低。
在多媒体部分，小游戏还不能像小程序一样实现实时的音频视频流，这是我们在后续要进一步支持的。网络IO的部分与小程序也是类似的，我们也提供了一些UI的组件，比如说拉起键盘，模态对话框等。
小游戏的社交开放能力现在已经对外了。其中最重要的一个能力是在开放域将微信的好友关系开放出去，给开发者使用，考虑到对用户隐私的保护会有一些设计上的限制。
因为小游戏去中心化的特点，分享这一部分也是非常重要的，开发者要考虑如何将这个能力利用起来。在代码方面，因为首包限制是4MB，但部分小游戏的代码量可能比较大。我们最近也在规划一个分包的能力，允许异步加载代码并执行，但这个代码是一定要经过我们审核的。
如何开发一款小游戏？
那么如何开发一款小游戏？因为我本人也只是开发过一些简单的游戏，并不是专业进行游戏开发，所以接下来我会更多地介绍一下如何利用微信的能力来开发小游戏。
选择小游戏引擎
微信跟引擎商也有比较密切的合作，一般现在的游戏引擎都会支持发布到多个平台，对微信小游戏这个新平台而言，已经有一部分引擎做了适配，比如Cocos Creator、Egret Engine以及LayAir Engine。适配的主要工作，类似之前提到的weapp-adapter，把wx API的能力，和引擎衔接起来。
比如引擎一般会把小游戏平台和webview平台对标，适配过程就是把wx API对应到webview的能力，同时把只存在于webview能力的依赖去除，比如不再依赖BOM、DOM。已适配的引擎都有相应的文章介绍如何把游戏发布到微信小游戏平台。
设备/环境适配
小游戏会有API提供获取屏幕的宽高、设备像素比等能力。小游戏开发完成后，在开发者工具也可以发起真机测试的请求，微信提供了不同设备的测试集群，帮助开发者提前去发现问题。基础库提供的wx API本身是一个不断迭代更新的过程，对于使用了新能力的小游戏，需要做低版本兼容。
微信登录
小游戏的登录过程，跟小程序是类似的。需要用户自己去定义登录状态。appsecret/session_key代表的是小游戏开发者和微信平台之间的一种信任约定，比如支付、上报托管数据，平台方需要验证access_token(只有appsecret才能换得到)，和用户相关的还要验证session_key的签名，才能保证请求来自于小游戏开发者/用户，而不是恶意的第三方和随意捏造的用户。
access_token是一种应用态的access_token，和用户无关，需要保证全局维护一份，应该有一个中控的模块去保证access_token有效，同时在有效期内直接使用本地cache的access_token，而不是每次使用都去生成新的access_token，否则可能遇到调用频率限制的错误而影响服务。切记appsecret/session_key不要放到前端代码中去，否则可能会被坏人利用损坏小游戏开发者/用户的权益。
缓存
缓存类型包括数据缓存和文件缓存两类。数据缓存即key-value存储，适合结构化类型的小数据存储，上限为10MB。文件缓存提供了一个完整的文件系统API，包括目录/文件的增删改读，适合针对经常使用的网络资源做本地缓存，上限是50MB。
和浏览器不同的是，微信只提供了基本的存储管理能力，并不对存储什么，和存储满时删除什么做一些操作。开发者自行灵活定义缓存以及淘汰策略，比如对经常访问的资源存储到文件系统以及在文件存储满时，清理一些最近不常访问的文件。
开放数据域
开放数据域是一个封闭、独立的 JavaScript 作用域，和执行游戏逻辑的环境——称为“主域”隔离。其目的是在保证用户隐私的前提下开放用户数据给第三方，提升小游戏的整体用户体验。以下为物理视图，主域的入口为game.js，开放数据域则是一个独立的目录，其入口文件为index.js。
主域和开放数据域的通信受到严格的管制，基本原则是只进不“出”。
•只进：允许外部的数据进入开放数据域，即主域可以随时postMessage到开放域，以及开放域引用主域准备好的本地资源
•不“出”：不允许开放数据域的数据被上传到第三方服务器去。因为开放数据域里面，index.js是可以直接访问到用户敏感数据的，比如同玩好友数据。当然最终开放数据域需要index.js在综合各种数据后把数据以图形图像的方式渲染到sharedCanvas上，在主语sharedCanvas允许draw到主域的上屏Canvas上，最终用户会在显示屏上看到game.js画出来的好友排行榜、群排行榜或好友超越等社交互动信息。
在开发数据域中的数据，开发者没法把数据拿出去和游戏数据做关联，所以如果需要在开放域下展示的游戏数据，比如分数，开发者需要将该数据通过上报接口把游戏数据托管到平台。这样就可以在开发数据域里面就取到相关数据，其应用场景有好友排行、群排行榜、超越好友提示等。
分享
包括自定义分享和系统菜单分享，可以分享到群聊、单聊。也可以把分享上下文与特定的群关联，实现一些群PK、群排行榜的场景。分享是一把双刃剑，需要谨慎使用，一方面避免过度骚扰用户/群聊，另一方面增强社交互动提供好的游戏体验，需要找到一个合适的平衡点。
支付
小游戏在安卓下支持虚拟支付，它的方式目前只有一种：即货币托管的方式。主要分为2个流程：
1.充值：RMB -> 游戏币，这里开发者只需要拉起支付的流程，平台负责把用户RMB兑换成对应的游戏币，存储到用户对应的游戏帐号上
2.使用游戏币购买道具：开发者可以扣除对应的游戏币，给用户发放游戏内道具，扣除游戏币的过程需要有一定的事务机制，去保证在网络异常的情况下交易正常。扣除游戏币的接口支持根据订单id去重，意味着网络超时等情况下，开发者可用同样的订单id去重试扣除，直至返回明确的响应。
以下为简单时序图，部分角色针对开发者无需关心的部分做了相应简化处理：
性能
小游戏常见的性能问题，一般是内存造成的。如果内存占用太多会被微信客户端主动关闭，因此开发者在用户游戏过程中要及时释放不再使用的内存（js代码去除引用，或主动调用对应资源的释放接口，如果有的话），特别是Canvas和Image类大型对象，同时可以主动调用wx.triggerGC触发底层回收对应资源。
对于和游戏逻辑相对独立的工作，可以考虑在worker中去实现，小游戏提供了独立的worker线程执行js逻辑的能力。
版本更新机制
小游戏启动的过程分为冷启动和热启动。冷启动是指内存中无该小游戏的运行实例的情况下，启动小游戏的过程；热启动是指小游戏的运行实例在内存中还存在，只是暂时切换到了后台，这时用户再次触发小游戏回到前台的过程。
小游戏会在冷启动时检查小游戏的版本，如有新版本，在下载回本地后，下一次冷启动即可使用最新版。当然，我们也提供了API可以供开发者决策在有版本可用时，是否需要强制更新。
运维
特别提醒，小游戏有完善的后端监控，可以通过“运维中心”开启，比如脚本错误监控。脚本错误主要由运行过程中未捕获的异常触发，需要重点关注。该类异常，可能会导致用户小游戏前端的js逻辑暂停执行。
同时，平台也提供了完善的数据分析服务，可以通过“小游戏数据助手”进行数据分析。