目前对于个人开发的微信小游戏来讲主要的变现模式就是开通流量主，通过展示广告来进行变现。 最近，我试验了一个新的变现路径，已经验证了其可行性，可以作为小游戏变现的一个补充。 直奔主题，这个方法就是给玩家送外卖红包，这种方式也叫外卖CPS(Cost Per Sale)，不了解的话可以去搜索一下关键词“外卖CPS”，大概的意思就是给用户发外卖红包，如果用户使用了这个外卖红包成功点餐了的话，你将能够获得这次餐费的指定比例的收益。 如果一个外卖订单最终能够完成，那么就意味着一个“三赢”的结果，一方面玩家使用了红包，真的省下了钱，另一方面，外卖平台因此多了一单生意，最后，我们也因促成了这单生意而获得了一定的收益。 在对这个方法进行验证之前，我已查阅了微信小游戏的相关规定，此方法不属于违规的行为。另外，在提交审核时，我在游戏更新内容中也做了详细的说明，游戏顺利通过审核，也证明了其目前的合规性。（请注意：微信小游戏的政策是不停变动的，目前允许的行为也许在未来的政策变动中会被禁止，所以决定使用这个方法前，请自行斟酌未来可能的风险） 我已在“精致1010”中对这种变现方法进行了验证，并且走通了整个流程。大家感兴趣的话可以去看一下。 另外，具体的方法和实现可参见公众号文章（注：这是一篇付费文章）。 详细的实现方法

需求背景在小游戏内场景，用户常基于游戏玩法面临几种选择： ①观看广告/分享，获得激励、继续游戏 ②拒绝广告/分享，继续游戏 ③流失，关闭游戏 [图片]而在设计玩法的同时，开发者也常常面临问题：“该在第几关插入广告”、“怎么设计玩法才能有更高的广告点击率、广告频次”、“这个场景该出分享还是广告”、“用户分享给我带回多少新增用户和新增流水”。 因此，为更好地帮助开发者调优广告点/分享点的设计、收获更高效益、优化用户体验，小游戏推出了自定义场景分析能力，打通游戏内外数据关联，帮助开发者更高效调优。 基本介绍场景分析，又叫自定义分析，提供埋点上报及数据分析能力。开发者可通过场景分析对小游戏各场景中用户行为进行个性化统计和分析，帮助游戏调优。 功能路径：微信公众平台 → 统计 → 场景分析[图片] 快速入门：使用场景分析，建议按以下步骤进行 明确数据需求，创建场景及相应行为分支获取埋点代码，配置上报发布代码配置，收集数据利用平台提供的分析能力，或自助下载数据，分析用户行为 1.1 明确需求，创建场景与行为分支平台以“场景+行为分支”的形式提供自定义上报能力。因此，开发者需先明确对游戏内哪个场景进行分析，再创建该场景下的用户行为分支。 功能路径： 统计→ 场景分析 → 场景管理 → 新建/编辑场景 例如，一个超休闲小游戏，可能针对： 场景：用户在关卡中闯关失败时 行为分支：用户面临选择：a.看激励广告获得复活机会；b.点击banner广告；c.分享获得复活机会（该例子中未出现）；d.使用道具卡；e.跳过 （平台提供三种行为分支类型，刚举例可分别对应：广告行为ab、分享行为c、其他自定义行为de） [图片] 同时，平台还支持开发者通过branchDim字段自定义拆分维度上传，包括但不局限于上传关卡信息、角色类型、... 额外参数branchDim：在场景创建中勾选开启使用。注意：在不勾选开启的情况下，即使上传了branchDim字段平台也不纳入统计。类型为String，取值为1-100的整数。 1.2配置埋点上报数据是以事件为最小粒度进行存储和分析的，不同的行为分支会对应相应需埋点的事件动作，“场景-行为分支-事件”。因此创建行为分支后，开发者可埋点代码，在相应位置配置上报。 例如在激励视频广告事件中可能包含如下事件： step1【广告前场景曝光】： // 将以下代码片段埋入如“看视频复活”的按钮曝光 wx.reportUserBehaviorBranchAnalytics({ branchId: 'XXXXXXXX', branchDim: "X", eventType: 1 }); // branchId为开发者申请时平台进行分配；eventType取值1：曝光，2：点击 // 同时平台支持开发者上传一个自定义字段branchDim，用于关卡、游戏角色等分析；类型为String，取值范围[1, 100]，必须为整数，当上传类型不符条件时不统计 step2【广告前场景点击】： // 将以下代码片段埋入如“看视频复活”的按钮点击 wx.reportUserBehaviorBranchAnalytics({ branchId: 'XXXXXXXX', branchDim: "X", eventType: 2 }); step3【广告曝光】： // 与广告关联，将以下代码片段埋入如激励广告的曝光（广告组件中的show事件） let rewardedVideoAd = wx.createRewardedVideoAd(/* 参考广告使用示例进行初始化 */); rewardedVideoAd.show({branchId: 'XXXXXXXX', branchDim: "X",}); [图片] [图片] 1.3 发布代码配置代码埋点随版本发布后，即会在游戏线上版进行数据统计，MP以“DAY+1”的方式给出数据反馈。 1.4 数据分析发布埋点配置后，即可在第二天起进行相应数据分析。 功能路径： 统计→ 场景分析 → 场景分析 A.分析某个场景的广告玩法效果 “该在第几关插入广告”、“怎么设计玩法才能有更高的广告点击率、广告频次”、... 场景分析提供更多广告价值指标（埋点处的广告点击、广告收入、ARPU等），支持开发者针对某个广告点的数据表现进行分析。 选择场景：开发者自创建的场景 选择行为：激励式广告/banner广告/插屏广告/格子广告/原生模板广告 日期范围：可选择自埋点发布日期后的统计时间 [图片] 查看方式：同时平台提供两种可下拆的维度分析。一者是开发者可自己设置的额外参数，一者是平台提供的按微信场景来源、用户设备平台的筛选。 额外参数：平台支持开发者上传类型String，取值为1-100整数的额外参数。开发者可在创建场景时勾选使用额外参数（注意：创建场景时不启动额外参数的使用，即使埋点中有参数的上传，平台将仍视为不使用） 来源和平台：平台提供按微信场景定义的来源筛选、用户设备平台筛选 [图片] [图片] 数据分析版块：展示的数据分为两部分： ①开发者自埋点的统计指标：广告前场景曝光、广告前场景点击、广告曝光 ②平台关联的广告价值指标：广告点击、广告收入、广告ARPPU、广告ECPM 同时，数据部分支持开发者下载导出。 [图片] B.分析某个场景的分享玩法效果 “这个场景该出分享还是广告”、“用户分享给我带回多少新增用户和新增流水”、“怎么设计玩法才能有更高的分享成功率”、... 场景分析提供更多分享价值指标（埋点处的分享成功率、分享带来用户、带来流水等），支持开发者针对某个分享点的数据表现进行分析。 数据分析版块：展示的数据分为两部分： ①开发者自埋点的统计指标：分享前场景曝光、分享前场景点击） ②平台关联的分享价值指标：分享成功、分享带来活跃、带来活跃次留、分享带来注册、带来注册次留、带来付费用户、带来付费金额、带来付费ARPPU、带来广告观看、带来广告收入、带来广告ARPPU、带来广告ECPM 同时，数据部分支持开发者下载导出。 [图片] C.对比两个不同场景的 广告/分享 玩法效果 “该在哪个时机出分享/广告”、“两种设计哪种表现更好”、... 场景分析支持不同场景下的同种行为表现对比。 [图片] D.自定义分析某个事件转化 除分享与广告行为外，场景分析提供了其他自定义行为的埋点统计能力。开发者可灵活运用这点用于关卡分析、付费转化分析等。 [图片] E.针对某个用户行为的漏斗分析 在用户选择/转化的链路上，平台提供漏斗分析模式，开发者可以更方便地分析点击率、转化率。 功能路径： 统计 → 场景分析 → 数据分析 → 漏斗分析 [图片]

小程序使用自定义分析，通过wx.reportAnalytics上传事件，可以知道按钮的点击次数，小游戏没有自定义分析应该如何统计按钮点击次数呢？是否有第三方平台接入

请问我这边如果版号名字是含有 “ ！” 这个符号的，但是由于微信后台的要求，游戏名字不能含有该特殊符号，版号名字和游戏名字只差了一个“ ！”，这样的情况下，我还能继续使用该版号来运营该款游戏吗？ [图片]

一个账号原来上过一个游戏，后来改成另一个游戏了，原来的那个游戏代码也一直“保护”着吗？有运营规范吗，发我看看

内含开店指引、店铺运营和平台规则，帮你快速掌握小商店经营秘诀。

想请教一个问题：我现在在做微信小游戏不依赖引擎绘制首屏，第一种方案：使用canvas2d绘制首屏，Android和IOS都能绘制出来，但是因为引擎（creator）使用webgl渲染模式导致合入游戏逻辑后引擎初始化失败，所以放弃了这种方案。第二种方案：使用webgl绘制首屏，引擎能正常初始化，游戏逻辑正常启动，但是有一个问题：webgl绘制的首屏在真机Android上正常显示，真机IOS显示不出，控制台也没有报错。 [图片][图片]

声音严重延迟，目前测试的几个android手机微信版本是7.0.15是必现 而在另外一台荣耀8x，微信版本7.0.9上不会出现

邀请各位开发者报名内测小游戏云测试服务 https://developers.weixin.qq.com/community/minigame/doc/000846255205f8c92d5912fca5e401 一、新特性 1.1 录制回放 为了方便开发者获取指定操作步骤下的各种小游戏云测试数据，微信小游戏提供了一套操作录制回放工具。开发者可以在微信开发者工具中录制在模拟器中的操作，生成录制文件作为云测试的“自定义测试”脚本，在云测试中提交“自定义测试”，即可获得固定操作下的云测试数据。 该功能旨在提供定制化游戏操作下的小游戏云测试，该功能有以下优势： ”游戏操作“一致情况下的多机型云测试数据结果，对比分析不同机型下游戏的表现 弥补标准测试无法覆盖复杂的游戏场景的缺陷 操作流程如图： [图片] 录制回放功能操作指引参考链接。 录制回放功能目前仅支持微信开发者工具的开发版(Nightly Build) 1.04.2005212 及以上版本，微信开发者工具下载地址：微信开发者工具。 备注：录制回放功能目前支持Cocos Creater，Laya和Egret引擎，使用问题和异常反馈等请联系”小游戏研发助手”（微信ID：minigamedevop07）。 [图片] 1.2 内存分析专项 在内测期间，我们了解到不少开发者对微信小游戏的内存问题非常关注，为了提供更好的手段帮助开发者了解在不同设备上的内存表现以及定位可能存在的内存问题，我们为此增加了内存分析专项。 内存专项的新特性包含两点： （1）内存资源分析：该特性可以追踪具体机型的整个测试过程的内存变化，可以获取具体场景下内存中的资源文件信息和内存指标信息，还可以对比两个不同场景的资源文件差异。 （2）内存专项数据：该特性是对内存分布和占用的统计数据。 故内存分析专项功能有以下优势： 不同机型、内存指标和内存区间的数据汇总，全面掌握内存分布 具体机型的内存数据统计，概览内存占用情况 具体机型的内存曲线分析，追踪游戏场景的内存变化，详细了解每个场景的内存数据 具体场景的内存资源数据展示，定位占用内存的具体资源，对比不同场景的资源差异 1.2.1 内存资源分析 内存资源分析体现在具体设备详细报告下的内存指标曲线中。 内存指标曲线是多个内存指标在游戏测试过程中的变化曲线图，鼠标选中具体时刻可获取（1）该时刻的内存数据；（2）游戏场景截图；（3）该时刻的内存资源数据统计和场景。 [图片] [图片] [图片] 点击”对比”，在“内存指标曲线”上选择两个时刻可获得这两个时刻的内存资源差异。 [图片] 备注：内存资源详情目前支持Cocos，Laya 1.7.0以上版本和Egret引擎，使用问题和异常反馈等请联系”小游戏研发助手”（微信ID：minigamedevop07）。 1.2.2 内存专项数据 在报告首页选择内存报告可查看内存专项数据。 [图片] 内存概览 所有设备根据不同档位、不同内存类型，对内存数据进行汇总，包含total、graphic、native、private-other等多种内存类型的最大值与均值概况数据。 [图片] 内存分布 总内存最大值的不同区间范围下的机器数量分布情况。 [图片] 内存TOP列表 根据总内存最大值进行降序排列后的TOP5机型。 [图片] 内存数据详情 各设备测试中，total、graphic、native和private-other等内存指标最大值与均值的详细数据。 [图片] 1.3 GameGlobal.isTest 在内测期间，根据开发者反馈，小游戏的新手引导过程限制了云测试对小游戏本身很多场景的测试。为了云测试能够覆盖小游戏中更多场景，在提交体验版代码时，开发者可以通过GameGlobal.isTest属性判断当前是否是云测试环境，进而跳过新手教程等一些无需云测试的场景。 使用方式如下： [代码]// 新手教程 function renderTutorial() { // 判断当前是否为云测试环境。如是，GameGlobal.isTest为true；反之，为false。 if ( GameGlobal.isTest ) { console.log("当前为云测试环境!") return; } // 新手教程逻辑 ··· } [代码] 二、后续优化内容 2.1 云测试评分体系与行业标准 针对开发者对于云测试的表现是否满足同品类游戏的标准不清楚，对好的实践方式希望得到指引，我们会针对测试数据进行评分，并给予响应的优化指引。 2.2 提升标准测试覆盖率 内测期间，标准测试基于monkey的操作策略，许多开发者反馈标准测试难以覆盖复杂的游戏场景，我们将提升测试覆盖率。

微信社交到底藏着什么秘密？ 这个问题答案藏在诸多前沿产品中，尤其包括小游戏。从微信小程序(小游戏）的开放开始，创业团队在上面构建了无数新爆款产品。但“在微信”就可以出爆款吗？在无处不互动的时代，该怎么理解并用好社交的秘密，来提升裂变、活跃和留存？ 从今天开始，“小游戏说”将深度对话并梳理这些优质小游戏关于增长、留存和变现的心得。这不仅仅是在聊一款小游戏如何从0到1，如何爆发，更是在聊当企业切入微信互联网、创业者们用好小程序时值得借鉴的方法论。 第一期将从创意小游戏“萌萌物语”开始，听他们分享如何运用社交因素，解决用户持续活跃和留存的问题。 [图片] 1 “恶作剧”社交，反而让用户留下来了？ 新进用户次日存留22%，活跃次日留存40%，活跃7日留存26%，人均在线时长25分钟，70%的女性玩家，尤其受Z世代玩家的欢迎。以搞怪为核心的多人社交互动小游戏“萌萌物语”，拿出了这样的成绩单。 这款小游戏有多特别？——周鹏（开发者）形容，这更像是一款“互坑”游戏，里面总有让玩家捣乱的空间： 一个魔法师通过摆放道具，帮助一群奇装异服的兔子们冒险领取胡萝卜，背着萝卜的兔子成功钻进洞里就算完成一局。 但是，最吸引用户的，并不是如何“通关”，而是如何“捣乱”。 [图片] 有人在游戏里“捣乱”，难道不会影响其他玩家的玩耍，反而让他们离开吗？对“恶作剧”社交的进一步思考，来自周鹏陪3岁的小儿子看《小猪佩奇》的经历。 一开始，周鹏并不感冒，不理解小猪佩奇的魅力。但渐渐地，陪看的他反应过来：“这是一个捣乱的动画片”，就像 “小孩子干完小坏事后，还得跑过来告诉你，他才真正达到了最开心的时刻”。这个想法成为了游戏内“恶作剧“社交的雏形。 如何把“捣乱”发挥到极致，让玩家享受捣乱的过程，甚至愿意留下来，继续玩耍？ 小游戏中被置入了许多逗笑因素，如动物表情、搞笑服装、弹幕、语音、搞笑动作等。玩家恶作剧之后，可以用这些来气其他玩家等，“孩子天生都有一些表现欲，捣乱完后自己还得告诉大人，才能释放最终的喜悦，我们得给他表达喜悦的方式。”周鹏甚至认为，这款小游戏正好满足了一个用户的心理诉求—— 所有人，包括大人，都像小孩一样，享受‘恶作剧’。 而这也成了《萌萌物语》独树一帜的社交优势：用捣乱、“互坑”这样非物质激励、非单方面利己的形式，创造有趣的社交场景，让用户享受一起玩耍的乐趣，而不是用游戏内惯用的“对抗”思路。 大多数微信开发者的思路都是：说起小游戏，“比较、比拼、PK”、及由此带来的“排行”等基础玩法，都在帮助用户从对抗中获得成就感，和压力释放后的轻松感。但萌萌物语却提出了一条新思路：用户不总是希望对抗自己、对抗世界，他们需要的是有趣、好玩。如果足够有趣，“等待”并不等于“流失”。 事实上，在萌萌物语里，是存在大量的等待时间的——一个魔法师帮一群兔子过关，所有兔子陆续进洞需要时间、等待魔法师帮助需要时间，中间还要被其他捣乱而耽搁——但是到底为什么，它的用户愿意“等待”？ 2用好三个步骤，让用户愿意“等待” 让用户在一款中“等待”通常意味着是灾难和流失。不过，为什么这款产品中用户会乐意“等待”？ 在过去策划产品时，周鹏发现，如果不让用户等待，而是安排各种事件填充完用户的时间，会发现用户就没有时间，也不会“想要”去观察周围。更重要的是： 有等待，用户才会找事干，才会形成互动。 周鹏在测试另一款产品时也发现，如果没有“等待”，用户结束游戏后就退出，对产品没有认同感。引入“等待”环节后——开始和结束游戏的过程中，都需要在虚拟房间中等待他人——用户更愿意互相聊一聊，甚至加为朋友。 在社交的世界中我们已知：如果好友们在一款游戏中，用户很大概率会去玩这款游戏。有关系，就有扩散、活跃和留存。 萌萌物语根据时间的不同，新近用户次日留存在20%-35%之间变动，人均在线时长25分钟，背后是用户多次进入积累形成。好友关系、等待玩法起到了关键作用。 那么，一个让用户喜欢的“等待”怎么构成的？周鹏将这个过程梳理为三步骤： 制造一个让人等待的场景，同时提供游戏操作之外的情感交流工具。如兔子们等待魔法师的帮助，如开局等待其他玩家的加入时，兔子们进行表情包的交流； 提供情感抒发的设计或玩法，让等待也可以很有趣。倒计时中欣赏蠢萌的魔法师、捣蛋的兔子成员、奇装异服的兔星村民、唯美的油画地图&让人沉醉的童话系等。 控制等待的节奏，把控玩家的心流。把控游戏时长，有节奏切换操作&交流时段，并用丰富的道具&地图保证每一局游戏的新鲜感……萌萌物语将“等待-交流”的节奏和“局时”结合起来，在2分20秒以内，有人一起玩耍的“等待”不会过长，也不至于无聊。 有人一起玩耍的“等待”保证了在线时长，而让用户喜欢的萌系童话风格、充分的供用户“玩耍”的社交工具（如表情包、弹幕、搞笑语音等）也让超高留存成为了可能。同时，萌萌物语用户画像显示，有7成是30岁前后的女性；这也侧面说明了，宝妈们愿意和孩子们一起在这里享受童趣。 轻竞技性、增强社交体验的设计，提升了大小用户们每天打开游戏的预期，这不是一个单纯的游戏局，“我们就是来和朋友、和孩子一起玩耍的”。 [图片] 3从愿意“等待”这回事，发现用户的四大变化 相比APP，小游戏中用户行为更“轻”，原本是腾讯杀手锏的“社交关系”被释放出来作为了基础能力，扩散让获客这件事情变得更为容易。现在，更多企业也在不断借鉴小游戏玩法进行获客、留存，以及变现转化。 不过现实是，大部分团队在利用小游戏化玩法时，仍只简单追求裂变，而忽略了更多有价值的方法论。仅透过萌萌物语，我们就能感知到许多截然不同的、基于小游戏的启发： -剧情类玩法更受欢迎。 不追求常见的套路，在用户体验产品过程中，可以根据场景不同，设置一些小剧情玩法，比如在地图上放一张小蹦床，有很多用户都喜欢在里面蹦来蹦去，或做一个水池，发现居然有很多用户喜欢在里面一直泡着。用户对这些剧情类的小玩法非常认同。 -用户享受改变的成就感。 周鹏在测试产品时做了一些设置，如玩家可以利用道具在下局游戏时变成魔法师，或者可以马上变成魔法师。但有没有特殊身份，用户并没那么在意；在互动中，能够对整个局面发挥作用，甚至改变，反而是成就感的来源——比如，当游戏在进程中时，魔法师表现不好或不佳时，玩家会立刻动用道具变成魔法师，去捣乱或者改变什么。 -有趣就行，没那么玻璃心。 在萌萌物语中也设置有举报系统，用户可以针对其他人恶意不进洞、捣乱等行为进行举报。但几乎没人举报，因为用户在这个游戏中注重过程的参与，而不注重结果。所以当用户在进行捣乱搞怪、动动闹闹时，大家反而不在意。 -允许打断，用户更需要快速直接给出推荐。 在过去，打断用户流畅的体验过程简直是不可想象的事情。但周鹏发现，小游戏用户习惯和希望被打断。这是因为APP多是重度用户，习惯搜索和寻找内容（如去应用市场搜索下载APP），而小游戏是轻量用户，因此需要你快速推荐给他所需要的。 比如在萌萌物语中，直接推荐更有效：用户在游戏过程中时，系统自动判断对方是否需要某一个道具，并直接作出推荐，这样的效果往往最佳。 写在最后： 在这些乃至更多启发面前，带给我们的借鉴也更直接，如：小程序中如何植入剧情类玩法，让用户表现更加活跃？在用户参与过程中，有什么是提高留存的社交秘笈？这些问题的答案都将有效提升留存和活跃。接下来的两周，“小游戏说”将和你们一起探讨。 “ 互动  话题  ”“你认为，可以如何构建用户在场景内的互动来提升活跃和留存？” [图片] （微信扫一扫使用小程序萌萌物语）

1.如何定向投放？ 微信广告定向支持地域、受众属性、偏好等选择。具体介绍请查看：腾讯广告 | 帮助中心 。 2.广告支持自定义人群定向吗？ 你在广告创建流程的定向模块中，可以选择定向投放给「自定义人群」，详细介绍及操作指引请查看：腾讯广告 | 帮助中心 。 3.广告的计费方式是怎样的？ 微信广告目前支持朋友圈广告、公众号广告、小程序广告、支付订单详情页广告位的广告投放。 朋友圈广告支持排期购买和竞价购买两种购买方式，按曝光次数收费。 公众号底部和文中广告支持曝光排期/点击竞价购买，公众号文章视频贴片广告位支持按曝光竞价购买，互选广告按照单篇文章计费，返佣商品CPS广告在商品实际成交后按照广告主设置的佣金比例扣费。 小程序Banner广告支持曝光排期/点击竞价购买，小程序插屏广告支持曝光排期/曝光竞价购买，小程序激广告支持曝光竞价购买。 支付订单详情页广告支持排期购买和竞价购买两种购买方式，按曝光次数收费。 具体的售卖策略和起投门槛可查看官网介绍：售卖策略 4、广告竞价展示规则是怎样的？ 在每一次广告投放中，你的广告是否被展示，取决于你的出价以及广告质量。 5、广告的素材是什么尺寸的？ 微信广告支持原生推广页、微信小程序、自定义链接等推广页。详细介绍可前往腾讯广告官网查看：腾讯广告 | 帮助中心 6、广告如果遭遇恶意点击，平台如何处理？ 微信公众平台专业技术团队提供多重措施防范异常点击，及时提出异常数据信息，智能化数据监控提供多维度测评数据反馈，从而全面监测数据的有效性。 针对非正常的点击作弊行为，平台会有严格的规则进行规避，判定为作弊的点击将不会扣费。例如同一用户短时间内多次点击，将判定为作弊点击。

终于来挖坑了！老规矩！图文+视频讲解！ 效果预览 [图片] 实现步骤 整体思路是先使用 [代码]PolyBool[代码] 计算多边形，接着使用 [代码]cc.PhysicsChainCollider[代码] 将多边形围起来，最后使用 [代码]cc.Graphics[代码] 将整个地形绘制出来。 引入 [代码]PolyBool[代码] [代码]PolyBool[代码]是什么？对多边形（并集，交集，差，异或）进行运算。(Boolean operations on polygons (union, intersection, difference, xor).) [图片] 前往 [代码]https://github.com/voidqk/polybooljs[代码] 下载。并作为插件脚本。 [图片] 这个仓库有个 [代码]PR[代码] 提供了一个声明文件，因为我用的是 [代码]TypeScript[代码] ，我就把它拿来改改用了。 [图片] 参考这个库的示例，里面有一个 [代码]regions[代码] 三维数组记录多边形的信息。 [图片] 我们也用个三维数组记录当前多边形的形状的数据，并初始化为一个长方形吧！ [代码]private _regions: number[][][] = []; reset() { this._regions = [ [[-480, -320], [-480, 250], [480, 250], [480, -320]] ]; } [代码] 添加物理链条 先在场景中添加物理节点。 [图片] 为这个节点初始化一些 [代码]cc.PhysicsChainCollider[代码] ，并开启物理引擎，顺便开启物理调试模式，方便看效果。 [代码]//onLoad() { cc.director.getPhysicsManager().enabled = true; cc.director.getPhysicsManager().debugDrawFlags = 1; for (let index = 0; index < 100; index++) { const c = this.node_dirty.addComponent(cc.PhysicsChainCollider); c.loop = true; c.enabled = false; } [代码] 接着根据[代码]_regions[代码]的数值，把[代码]points[代码]传给物理链条。 [代码]// draw() { const chains = this.node_dirty.getComponents(cc.PhysicsChainCollider); chains.forEach((c) => { c.enabled = false; }) for (let index = 0; index < this._regions.length; index++) { const pos = this._regions[index]; let poly = chains[index]; if (!poly) { poly = this.node_dirty.addComponent(cc.PhysicsChainCollider); poly.loop = true; } poly.points.length = 0; poly.points = pos.map((v, i) => { const v2 = cc.v2(v[0], v[1]) return v2; }); poly.enabled = true; } [代码] 看看效果。 [图片] 开始挖洞！ 监听一个节点的触摸事件。 [代码]// onLoad() { this.node_dirty.on(cc.Node.EventType.TOUCH_START, this._touchMove, this); this.node_dirty.on(cc.Node.EventType.TOUCH_MOVE, this._touchMove, this); [代码] 在触摸点周围圈一个多边形(类似画一个圈，不清楚的话可以参考上一篇中的把圆围成一个圈)，并使用差集的方法计算新的多边形，计算后再重写画物理链条。 [代码]// const DIG_RADIUS = 50; // const DIG_FRAGMENT = 12; // _touchMove(touch: cc.Touch) { const regions = [[]]; const pos = this.node_dirty.convertToNodeSpaceAR(touch.getLocation()); const count = DIG_FRAGMENT; for (let index = 0; index < count; index++) { const r = 2 * Math.PI * index / count; const x = pos.x + DIG_RADIUS * Math.cos(r); const y = pos.y + DIG_RADIUS * Math.sin(r); regions[0].push([x, y]); } const result = PolyBool.difference({ regions: this._regions, inverted: false }, { regions, inverted: false }); this._regions = result.regions; this.draw(); [代码] 看看效果。 [图片] 填充颜色 先画一个多边形，只需先移动到起点，然后逐一划线，就可以了。 [代码]// private _drawPoly(ctx, poly) { poly.forEach((pos, i) => { if (i === 0) ctx.moveTo(pos.x, pos.y); else ctx.lineTo(pos.x, pos.y); ctx.close(); }); [代码] 填充思路是基于 [代码]canvas[代码] 中的 [代码]evenodd[代码] 规则。 [图片] 与上面不一样的地方是，我是计算这个多边形被几个大的多边形包围，当是偶数的时候填充泥土的颜色，当是奇数时，填充背景的颜色。 [图片] 当然，需要注意的是，计数越大的要越后画，这样才能达到最终效果。 [代码]// draw() { const enabled_chains_points=[] for (let index = 0; index < this._regions.length; index++) { // 省略与上面相同 draw enabled_chains_points[index] = poly.points; } this.graphics.clear(true); const enabled_chains_points_sort = enabled_chains_points.map((curPoly, curPoly_i) => { const count = enabled_chains_points.reduce((pre, nextPoly, nextPoly_i) => { if ((curPoly_i != nextPoly_i)) { const length = curPoly.length; for (let i = 0; i < length; ++i) { const p0 = curPoly[i]; if (!cc.Intersection.pointInPolygon(p0, nextPoly)) return pre; } return pre + 1; } return pre; }, 0); return { curPoly, count }; }).sort((a, b) => { return a.count - b.count; }) enabled_chains_points_sort.forEach(({ curPoly, count }) => { this.graphics.fillColor = count % 2 === 0 ? cc.Color.ORANGE : cc.Color.BLACK; this._drawPoly(this.graphics, curPoly); this.graphics.fill(); }) [代码] 顺便吐槽一下，[代码]canvas[代码] 中的 [代码]fill[代码] 可以带[代码]evenodd[代码] 的参数， 而 [代码]cc.Graphics[代码] 中不能带这个参数，可能是因为 [代码]creator[代码] 中的 [代码]webgl[代码] 画图不方便实现吧！(试图从源码中看看有没方案，最终还是自己多次填充了，而且[代码]webgl[代码]中的实现会不停创建[代码]buffer[代码] )。 好吧，看看效果如何！ [图片] 优化 < 未完待续 > 关注 白玉无冰 第一时间获取最新进展！ [图片] 小结 动手实践！在实践中成长！在模仿中学习！ 以上为白玉无冰使用 [代码]Cocos Creator v2.3.3[代码] 开发[代码]"物理挖洞！涂抹地形! "[代码]的技术分享。如果对你有点帮助，欢迎分享给身边的朋友。 视频讲解 视频讲解 参考文章

[图片] 拉取量不能转化为曝光量是多数是什么原因？

 为提升流量主的变现及推广效率，帮助流量主实现流量价值最大化，微信广告正式推出了一套系统课程——“流量主成长营”，为广大流量主答疑解惑，分享流量变现及推广“秘籍”。 高效变现，丰富回报，流量主成长营系统课程上线助力 “流量主成长营”是微信广告团队为提升流量主（包含小程序、小游戏、公众号）变现及推广等综合能力所打造的一套系统课程。在“流量主成长营”中，流量主成长营讲师团队将会为流量主传授流量变现的实战操作指南，详解不同场景下的商业化变现攻略，持续更新组件及工具的升级玩法，解决当前小程序、小游戏及公众号变现和增长问题，从而推动流量主能力升级，高效获取更丰富的价值回报。 独家变现、增长秘籍详解，首期小游戏专场干货课程上线 “流量主成长营”覆盖从入门到进阶的多期课程。第一期主要面向小游戏流量主，课程内容共分为五部分，课程信息如下： [图片] 小游戏专场第一期课程内容涵盖了最新的小游戏广告组件和技术解析，变现设计思路，变现实操案例以及广告调优思路等等一线流量主最为关心的话题。课程讲师从一线实操经验出发，细致讲解小游戏广告变现各流程及思路，解决小游戏流量主变现困惑，帮助广大小游戏流量主夯实行业基础，掌握最妥善的广告变现方式，从而实现商业收益与用户规模的双增长。 本期系列课程共五节课，内容多样，开发者可以按需选择。每节课预计学习耗时分别为： 课时 主题 预计耗时 课程学习链接 第一课 成为流量主，开启广告变现之路 5分钟 https://tencentads.com/l/lessonone 第二课 广告变现上手易，组件和技术全解析 7分钟 https://tencentads.com/l/lessontwo 第三课 探究广告组件特点，解析标杆变现案例 13分钟 https://tencentads.com/l/lessonthree   第四课 掌握买量优化思路，促进用户有效增长 11分钟 https://tencentads.com/l/lessonfour   第五课 组合运用工具，调优广告效率 5分钟 https://tencentads.com/l/lessonfive   时间短，收益大。看到这里，你是否已经心动了？还在等什么，赶快听课吧！ 微信广告团队希望能够通过打造业内领先的分享学习平台，增加与一线人员交流的机会，与广大流量主共同进步。也希望能够通过不断完善和释放平台各项功能，拓宽流量主商业化变现及推广思路，让流量变现更加轻松、快捷，帮助流量主实现正向、可持续稳健发展，与广大流量主共建繁荣的平台生态。 大家还有哪些最想听到的内容或者最希望得到解答的问题也可以通过下方链接反馈给微信广告团队。未来，微信广告将根据反馈优化课程设置，带来更多价值内容。 [图片]  

“WeCare公益计划”发出后，报名小纸片汹涌而来。同时，我们也收到了众多开发者的问题—— “怎样才算公益小游戏？” “有没有公益主题推荐？” “游戏最后归属于谁？” …… 今天，我们为大家总结并解答了十四个疑问。 //“WeCare公益计划”大解疑// 1、什么才是“WeCare公益计划”寻找的公益作品？作品形式要求是小程序和小游戏吗？ 提交的公益作品需充分理解并融合公益关键点，体现公益内涵；通过产品能有效地传递公益信息，带动用户参与公益，在社会范围内能产生公益影响力。初期提交的作品可以是小程序和小游戏的策划方案，但最终作品形式要求是小程序或小游戏。 2、有哪些公益主题可以作为主题？ 主题不限，示例：环保、助学、扶贫、救灾、疾病救助、妇女发展、困境儿童、抗战老兵、空巢老人、特殊人群关爱、传统文化保护…… 3、对小游戏的品类或者玩法有没有要求？ 品类不限，优先考虑具有长线运营能力的玩法。 4、什么时候报名，如何报名？ 4月25日起，大家就可以提交方案报名。报名方式：将方案提交至WeCare专用邮箱: 2531958693@qq.com ,详细报名规则请查看WeCare官网。 5、个人开发者是否可以报名？ 本次计划需要审核开发商公司资质，不支持个人报名。 6、入围方案的S/A/B等级如何评判？ S/A/B主要在方案提交阶段依据方案所规划的游戏内容量、玩法复杂度、团队人力投入、美术资源投入及品质等来评估。 7、方案入围后，需要研发落地和推广？ 需要的。方案入围后，将根据评审等级，提供不同的研发基金和运营激励。后续，将由开发者继续进行小程序（小游戏）的开发落地。 8、游戏上线后版权归属如何？ 版权归属腾讯公益慈善基金会，在非商用的情况下，可与基金会进一步协商获得授权使用。 9、是否允许商业化，比如按广告收入分成？ 公益小游戏、小程序暂不考虑和允许任何商业化内容。 10、如何和腾讯公益平台上的捐款项目打通？ 优质的公益小程序（小游戏）项目会获得公益认证，以及配合公益项目推广和筹款的合作机会。此外，腾讯公益将会提供一套接口指引，按照文档规范接入即可。但需要提前与WeCare小助手咨询，方便与对应项目的公益机构沟通，取得许可。WeCare助手（小游戏）微信号：minigame3，或QQ号：2531958693。 11、激励金额如何发放？ 初始研发基金在签订协议后45日内发放一定比例，在发布上线后发放剩余部分。运营激励基金在达到运营指标后的45日内发放 12、已上线的游戏/产品是否可以改造成为公益游戏/产品参赛？ 可以，但须满足公益产品对于：有公益意义、无商业化、版权归属腾讯公益慈善基金会等要求。且运营指标内的数据以改造完发布上线后的新用户情况为准。 13、公益游戏是否可以参与创意小游戏申报？ 可以。具体参见《微信创意小游戏计划》 14、为什么入围后需要签定协议？ 本次激励的完整发放，将贯穿入围、研发上线、以及稳定运营6个月内，是一个较长的周期。签订协议能保证双方在长周期内如有任何变动，双方的权益得以保障。 我们希望与开发者们共同建设更丰富的小游戏生态的同时，也能探索“游戏以外”的多元价值，让公益成为我们生活中一件“触手可及”的小事。 参与方式： ■ 联系 WeCare助手（小游戏） 微信号：minigame3，或QQ号：2531958693 ■ 作品提交至 邮箱：2531958693@qq.com （附上团队简介及联系方式。方案内容必须包含：主题（世界观）介绍、系统功能、交互、数值、美术风格示例。） ■ “WeCare公益计划”完整规则可参见官网

微信小游戏是否允许接入其他广告?

banner上的同一个广告重复点击是否重复计费

[图片] 游戏再好玩，一秒掉线两秒卡顿可还行？ 微信公开课讲师开发工程师叶轩分享了这一年的优化效果：在小游戏开发者和平台的共同努力下，内存降低了7.7%，启动耗时降低了46%，过滤限帧提高了9%。这几个数据意味着什么呢？ [图片] 启动性能 首先来看劝退优化第一步——启动性能： 无须多言，对于塑料友谊的小游戏玩家来说，启动速度越快越好，慢则容易带来流失。 如果一个小游戏的启动速度能够从6.4s降到4.1s，流失人数可以减少17.4%，从4.1s降到3.3s，可减少21.8%。 “通过运营10年功，结果流失10秒钟”想要减少用户流失，争取到塑料玩家的塑料友情，你需要再快一点。 [图片] 那么具体可以怎么优化呢？平台给出了这样几个解决方案： 1. 资源预加载： 2. 分包：尽可能将资源分包，并缩小首包大小 3. 图集：把零散的图片整理成集，方便一次性下载 4. 加快首帧渲染； 5. 引擎插件： [图片] 在平台能覆盖大多数小游戏所用引擎的情况下，引擎插件可以通过共享重复的引擎代码部分，减少玩家首次打开需要下载的代码量让玩家更快打开小游戏。 目前，小游戏平台已经实现主流引擎全面覆盖开发者只需前往所使用的引擎官网（目前已全面支持cocos、laya以及白鹭引擎）将所用的引擎更新到最新版本IDE，重新导出并上传即可。 接入门槛与效果： 只需1分钟接入，即可节省单游戏1.5M的下载流量，提升1.14s的启动速度，从而减少23%的用户流失目前，以及由351款小游戏已接入引擎插件。 [图片] 运行性能 除了启动性能，运行性能也是今年优化的重点： 逻辑与渲染优化 8月份推出的安卓端排查工具Start CPU Profile，可以帮助开发者检验小游戏运行状态，将所有逻辑进行一一记录，快速排查小游戏哪里逻辑最耗时，知道哪里逻辑最耗时之后再去做优化。 优化建议： 1. 尽量使用Worker； 2. 避免同步接口，使用异步接口； 3. 减少过多局部变量使用； 4. 使用SystemInfo.benchmarkLevel； 5. 使用混合渲染模式优化子域排行榜，可减少开放数据卡顿。 内存优化 可使用开发调试接口：Take Heap Snapshot进行优化； 优化建议： 1. 调动wx.triggerGC()接口，可减少不必要的资源损耗； 2. 监听wx.onMemoryWarning，解引用不必要的资源占用，减少被系统杀掉的可能性； 3. 压缩纹理；

微信小游戏平台上对首包的的限制是4M，超出限制之后可以采取什么样的措施呢？异名做了一下盘算，大概可以有以下操作 挤牙膏式瘦身 如果我们能够在各种常规的瘦身手段下就可以把超出的容量压缩回到4M以内，那当然是最棒的。这一块能做的无非就是引擎的瘦身和资源的瘦身，而资源无外乎是图片，音频，字体等。 引擎瘦身 首先是引擎代码本身，在开发阶段我们的引擎默认是所有模块都包含进去的，但是在打包阶段，有一些无用的代码模块我们就可以在[代码]项目-项目设置-模块设置[代码]中剔除掉，比如一个普通的2D游戏，可能就没有使用到3D模块、物理模块、[代码]EditBox[代码]等等，我们最好根据实际的项目的需要勾选自己需要打包的模块，根据异名自己的经验，大部分情况下做了引擎瘦身和没做引擎瘦身的前后做对比，瘦身之后可能至少会帮你省掉你几百k的大小。其中有些功能模块，它的名字不是很直观，你可能不知道自己有没有用到，那就不要勾选。经常会有新手遇到，为什么打包前，在预览模式下项目跑得好好的，但是打包之后项目功能就不正常了，出现这种情况其实很大概率就是你的模块漏勾了，回去校对一下重新打包就可以了。 资源瘦身 资源无外乎是图片，音频，字体。如果是寻常的web项目我们其实有很常用的几个构建工具，像[代码]gulp/grunt/webpack[代码]等等，引用相关的压缩库，然后执行构建命令就可以了，但是我个人觉得还是没有这种必要引入构建工具，因为代码压缩和名字hash引擎已经自身支持了，那音频和字体其实在我们使用之前只要使用工具一次性压缩就可以了，而图片则因为数量太多以及会涉及到自动合图，所以需要在构建之后重新压缩一遍，但是我个人会比较倾向于依赖引擎自身提供的插件机制，毕竟使用了构建工具之后起码还得去[代码]npm install[代码]一下，还要去设置每个包自身的一些配置，然后项目build完之后还得去敲个命令，整个一套走下来，其实效率还是不够，而且针对图片压缩，社区内其实已经有能够直接就开箱即用的相关插件，像[代码]pngquant[代码]我就用挺顺手的，而且在它的基础上也可以添加一些自己的发布流程进去，比如我就把文件夹改名放到里面，后续的项目直接拷贝过去使用就可以了。 [图片] 音频这块我建议还是使用第三方的工具吧，我自己习惯使用[代码]ffmpeg[代码]。如果有用到其他字体的话，一款普通的中文字体大大几十M，但是我们使用字可能就是那么几个，所以字体提取也很有必要，其实社区内有收费的插件，但是目前中文字体提取库无非就是[代码]Fontmin[代码]或者字蛛，它们都可以可以通过终端命令或者客户端和web端去提取所需的字体，异名以前也写过一款小工具，大家需要的话可以去下载来用，地址放在原文链接。 [图片] 资源远程加载 既然本地放不下了，那就把资源放在远端吧。这块引擎的支持也很好，在打包构建的时候填写远程服务器地址，然后把打包后的res目录存放到服务器下，再删除本地的res文件夹就可以了，运行的时候如果在本地没有这个资源就会去远端获取。但是呢，异名在权衡之后，并不会选择这个方案，首先第一个问题是资源在远端，加载会有网络延迟，这个时候场景是黑屏的，解决这个问题可以做一个简单的初始场景，初始场景的资源还是保留在本地，然后在初始场景预加载真实的游戏场景，等到加载完了之后跳转过去 [代码]cc.director.preloadScene("Game", (completedCount, totalCount) => { // 在这里处理加载进度 console.log(completedCount, totalCount); }, (error, asset) => { if (error) { cc.error(error); return; } cc.director.loadScene("Game") }); [代码] 但是这里的骚操作就是你得在res文件夹里面挑选你的首屏资源，面对一堆嵌套的文件和无规则的文件夹名称，那是多大的效率浪费呀，为了提高效率，异名看到社区内看到有人专门写个[代码]Python[代码]脚本（怎么感觉发力点发错了呢…)，当把资源挑选完毕之后，还得把cdn上的res文件夹删掉，然后重传，那这个发版过程也未免太过于太琐碎了。还有就是网络请求多了，万一遇到个网络不好报个[代码]timeout[代码]呀，或者资源更新但是你的cdn节点还没同步过来，然报个[代码]notFound[代码]呀什么的，那也得做个异常处理是吧。 [图片] 除了上面说的，异名觉得最关键的还有费用问题，带宽都是钱啊，明明微信总包大小有8M，有多少小游戏经过合理的瘦身之后总包大小还能超过8M呢？而且微信针对网络资源的还有一套自己的缓存管理机制，几乎每次打开都会重新去拉取，cdn的流量就这么被挥霍掉了。 [图片] 当然每种手段都有每种手段的应用场景，异名在社区内还看到有同学利用微信的文件系统api去拉取zip资源，然后通过unzip命令去解压的，如果你的游戏资源确实很多很大，那也难以避免的需要使用远程资源，具体场景还是得合理分析才行。 分包 引擎对分包的支持真的非常好啦，对应的文件夹中打个勾就行了。异名的做法其实是多加了一个loading场景，然后把主场景的资源都放在分包里面，在loading场景中通过[代码]loadSubpackage[代码]监听下载分包，下载完成后再跳转主场景就可以了。和资源远程加载相比，整个配置步骤清晰明了，发版过程简单流畅，而且省了你的cdn流量，同时微信自身还会对代码包进行主动缓存，一次下载之后就会缓存下来方便下次使用。异名把两者一对比，觉得是分包那是真的香啊~ 有几个小点还是需要注意一下： 老版本兼容：由微信后台编译来处理旧版本客户端的兼容，后台会编译两份代码包，一份是分包后代码，另外一份是整包的兼容代码。对于老客户端，会去下载整包代码启动 2.1.0 以下版本基础库不存在[代码]wx.loadSubpackage[代码]方法，需要通过require来加载（可以在后台屏蔽以下的用户） 微信 6.6.7 以下客户端开发版/体验版因历史兼容问题无法打开分包小游戏，正式包可以 总结 说这么多，总结下来就是，如果你的代码包超过4M，请先进行各种压缩，如果确实已经是极限压缩了，那使用分包会比远程资源相对来说更加成本更低也更合理。另外异名并不建议子域使用cocos构建，因为确实构建之后又多了一个引擎，首包确实很难控制下来，好的选择是使用canvas的api去绘制或者使用一个简单的模板渲染引擎，当然，这就是另外一个话题了 我是异名，你的阅读是我的动力，其他文章链接： 刮刮卡实现 金币落袋效果 遥控杆实现 背景无限滚动 Cocos游戏开发入门最佳实践 使用Cocos进行2D和3D混合开发 [图片]

新版本进小游戏加载分包会报错，使用老版本的微信是正常进入的，更新之后就进不去了，后台也有很多iOS用户，客户端版本为7.0.12的用户反馈无法正常加载，我司两款使用了分包的Cocos小游戏都会必现这个问题 [图片][图片][图片][图片]

const canvas = wx.createCanvas(568 * , 320 * );//创建画布 var rpxw , rpxh ; //自适应单位 var pR ；//设备像素比 //获取屏幕宽高，获取自适应单位 ，设备像素比。    wx.getSystemInfo({   success: function (res) {     rpxw = res.screenWidth / 568;     rpxh = res.screenHeight/ 320;     pR = res.pixelRatio;   } }) //创建上屏canvas。 const canvas = wx.createCanvas(); const context = canvas.getContext("2d"); //创建离屏canvas。 const canvas1 = wx.createCanvas(); const context1 = canvas1.getContext("2d"); //设定离屏画布宽高。 canvas1.width = 568  * pR; canvas1.height =  320  * pR; //绘制时宽高参数都乘以设备像素比pR。 context1.fillRect(0, 0, 568 * pR, 320 * pR);//矩形 //把离屏画布绘制到上屏画布时宽高参数都乘以自适应单位rpxw , rpxh 。 context.drawImage(canvas1, 0, 0， 568 * rpxw, 320 * rpxh); 案例： Miuseshare 小作曲家软件 简称：小作曲家 [图片] 若有用请帮转一下 ，分享好友。 游戏以控制音名图上下移动发出钢琴对应 乐音，选择与随机产生的音符图碰撞收集对应的音符图片和乐音。音符实时锁定动态显示度数，探测和弦组成音功能。音符音效含三和弦、七和弦以及其转位，四音列上下行重复半音后止于五音。有利于对基础音程的认识与记忆。设有《小鸟落水》（二度）、《小星星》（ 一度、五度）、《蓝色多瑙河A》（三度、和弦）、《摇篮曲》（四度、八度）、《难以抗拒你的容颜》（六度）歌曲练习板块。通过实时锁定音符动态显示度数，探测和弦组成音。让用户对音乐知识有进一步的认知！“创作源”、“音高与弦”、"乐音对接‘’、“音阶和弦” ，“基础音程”，Ukulele板块、辅助记忆、增加 用户对音乐元素的认识，对旋律音程进行与链接的认知。“创作功能”能让用户做简单的创作！

游戏里，玩家要赢就得打败BOSS。 开发者也有BOSS：加载慢、画面卡、闪退、耗电高、网络延迟……性能作为游戏的“基石”，不好的体验分分钟就变成“实力劝退”玩家的大BOSS。 为了帮助开发者们第一时间抢救流失用户，小游戏数据助手“上新”了！全新的“性能数据”有5大技能，帮你找出游戏运行中的“BUG”，让游戏体验更顺畅。 ROUND 1启动性能 等待游戏启动加载就像等待英雄“放大招”，玩家等待时间过长，就有大招放不出的憋屈感，留存率自然上不来。 [图片] 通过“小游戏数据助手-性能-启动性能”可以发现，某个小游戏总的启动过程中留存率（包括非首次打开玩家）约为90%，而首次打开游戏的玩家中，只有87%度过了代码包下载的过程。 [图片] 同时根据“性能数据”中的流失时间分布情况显示，不论有无代码包下载，如果能把时间缩短到4s内，可以减少大约30%玩家的流失。 [图片]   对应技能：开发者可以通过精简首包，例如代码、资源压缩，或分包加载等方式优化。如果问题出现在首屏渲染阶段，则减少首屏前资源加载、精简初始化代码逻辑、对重度逻辑进行分帧。 开发者还可以使用小游戏开发工具Profile，对启动阶段的包体大小、网络资源请求、分包加载、初始化耗时等问题做进一步分析。 ROUND 2运行性能之FPS 丰富的画面和游戏逻辑可以让小游戏更“酷炫”，但也更容易遇到操作不流畅、画面卡顿等“BUG”。尤其是中档和低档机型，卡一秒，等待玩家的只剩下Game Over。 [图片] （通过一些FPS查看工具，可以发现在释放技能时帧率明显降低的情况） 在“小游戏数据助手-性能-运行性能”中，可以看到某款小游戏的帧率普遍偏低，中档机型在20帧以下的占比接近60%，许多玩家被拦在这一关。 [图片]   对应技能：FPS是整体流畅度的表征，问题较为复杂，开发者需要根据Profile工具做分析，针对不同CPU/GPU/内存等进行排查。 ROUND 3运行性能之内存 高品质的小游戏更受玩家和创意评审团青睐，但高品质美术的游戏往往需要占更多的内存。内存跟不上，就会遇到闪退或无法运行等“BUG”。 [图片] 通过“小游戏数据助手-性能-运行性能”，可以看到某款小游戏内存占用接近700MB，内存增长也已达到400MB。 [图片] 在“小游戏数据助手-性能-性能运行”还能看到不同机型下的内存均值，以及用户异常退出次数和人数，方便开发者们分析阈值是否超过预期，从而更合理平衡游戏质量和游戏稳定性。 [图片]   对应技能：开发者可以通过避免内存泄露、规划美术资源、降低资源质量、及时释放资源等方式减少内存占用。 ROUND 4运行性能之CPU 物理、寻路、AI等小游戏复杂度较高，占用的CPU也比较高，更容易导致手机发热严重、耗电量高、流畅度下降等问题。 在“小游戏数据助手-性能-运行性能”可以看到，某小游戏CPU在iOS各分档机型下都非常吃CPU资源。 [图片] 同时根据性能概况显示，不同分档机型在几天下来CPU均值都非常高。 [图片]   对应技能：开发者可以开发阶段Profile工具做CPU热点分析，如使用微信开发者工具“Performance”或“真机调试”工具对计算热点进行分析，适当优化算法减少CPU计算逻辑。 ROUND 5网络性能 对竞技类、io类玩家来说，想要成为MVP，网速必须跟得上。短短几秒的网络延迟，能使一位“黄金”变“青铜”。 通过“小游戏数据助手-性能-网络性能”，开发者可以查看网络接口的综合性能，如延迟、回包长度、错误量等。 [图片] 同时开发者还能在这一模块的“网络接口错误分析”中找到TOP的网络路径，并在“网络接口延迟分析”找到网络延迟的“病因”。 [图片]   对应技能：开发者可以通过压缩资源、精简协议字段、优化服务器环境部署等方式，改善玩家游戏体验。

一、优化启动的意义 衡量一个游戏好坏的一个很重要的标准就是留存，而启动时间直接决定了第一波玩家的流失率。当用户打开游戏，满怀期待的等待游戏开始。最好的情况是游戏在1-2秒内给与反馈，或者能让用户进行下一步操作。一般首次打开，由于首包需要从服务器下载，都会有一个等待过程。在这个等待的过程中，用户的忍耐度是慢慢降低的。如果游戏在2-5秒之后才进入可用的状态，首屏留存就会受到影响。最后如果游戏超过5秒甚至更久才显示首屏，这时用户的耐心可能完全消失，有一部分用户可能会退出重新进入，但更多的用户会放弃使用。 根据小游戏整体启动留存率分析，Android玩家的首屏打开留存率约为85%。这是什么意思呢，就是玩家从点击小游戏到能看到首屏的渲染界面大约有15%的玩家流失。对于首次玩某款小游戏的玩家，由于本地没有版本缓存，留存率会明显低很多。据统计，仅代码包加载阶段新玩家流失率就达到20%。（以上数据来源微信小游戏性能优化指南） 二、晒数据 以下数据来自我们游戏优化前后的数据对比 [图片] 三、启动性能优化 小游戏启动加载时序 以下是官方给出的启动时序图和优化建议 [图片] [图片] 1.首包优化上面，我们可以完全按照官方的建议，尽量减少首包的大小，由于我们对引擎有定制，所以暂未使用引擎插件能力，我们首包中只存放了引擎及基础的启动代码，大小为1.5M。如果使用引擎插件功能，这个大小可以缩减到300K。 2.我们在首包中仅放入了游戏引擎的代码和一些必要的资源。这时候游戏尚不能完整运行，因为游戏的逻辑代码在子包中，需要进一步的加载。但是这时我们要尽快让游戏给出反馈，也就是显示首屏。首屏的内容绘制我们有两种方案：1）依赖游戏引擎绘制 2）不依赖引擎直接绘制。 1）依赖游戏引擎进行绘制 我们利用引擎进行绘制，要做到资源尽量少，能够满足绘制一个启动图和一个进度条就可以了。 a.对于使用CocosCreator制作的游戏：我们可以在游戏启动的时候， 对于第一个场景那里使用动态创建场景的方式， [图片] 这个动态创建的场景，只使用放在首包里的一些资源。 b.对于使用Laya制作的游戏：我们把原本放在工程代码里的入口代码提取出来，完成Stage的初始化。这样我们就可以做绘制了。 [图片] 2）不依赖引擎直接绘制 在第一种方案中，优化的方向也是尽量减少第一个场景的资源。但是忽略了一个很耗时的过程，引擎初始化。这一步经测试，iOS在100ms以内，安卓在1-2s。如果能把安卓这1-2s的时间优化，想想都兴奋。 为了使首屏等待时间减少到极致，在引擎初始化之前，我们自己来渲染第一帧。我们的游戏使用的Cocos Creator引擎，默认使用WebGL。我们绘制了一个最简单的黑色三角形作为游戏的第一帧。 [代码]//顶点着色器程序 var VSHADER_SOURCE = "attribute vec4 a_Position;" + "void main() {" + //设置坐标 "gl_Position = a_Position; " + "} "; //片元着色器var FSHADER_SOURCE = "void main() {" + //设置颜色 "gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0);" + "}";//获取canvas元素 GameGlobal.dycc = wx.createCanvas();//获取绘制二维上下文 var gl = dycc.getContext('webgl'); //编译着色器 var vertShader = gl.createShader(gl.VERTEX_SHADER); gl.shaderSource(vertShader, VSHADER_SOURCE); gl.compileShader(vertShader); var fragShader = gl.createShader(gl.FRAGMENT_SHADER); gl.shaderSource(fragShader, FSHADER_SOURCE); gl.compileShader(fragShader); //合并程序 var shaderProgram = gl.createProgram(); gl.attachShader(shaderProgram, vertShader); gl.attachShader(shaderProgram, fragShader); gl.linkProgram(shaderProgram); gl.useProgram(shaderProgram); //获取坐标点 var a_Position = gl.getAttribLocation(shaderProgram, 'a_Position'); var n = initBuffers(gl,shaderProgram); if(n<0){ console.log('Failed to set the positions'); } // 清除指定<画布>的颜色 gl.clearColor(0.0, 0.0, 0.0, 1.0); // 清空 <canvas> gl.clear(gl.COLOR_BUFFER_BIT); gl.drawArrays(gl.TRIANGLES, 0, n); function initBuffers(gl,shaderProgram) { var vertices = new Float32Array([ 0.0, 0.5, -0.5, -0.5, 0.5, -0.5 ]); var n = 3;//点的个数 //创建缓冲区对象 var vertexBuffer = gl.createBuffer(); if(!vertexBuffer){ console.log("Failed to create the butter object"); return -1; } //将缓冲区对象绑定到目标 gl.bindBuffer(gl.ARRAY_BUFFER,vertexBuffer); //向缓冲区写入数据 gl.bufferData(gl.ARRAY_BUFFER,vertices,gl.STATIC_DRAW); //获取坐标点 var a_Position = gl.getAttribLocation(shaderProgram, 'a_Position'); //将缓冲区对象分配给a_Position变量 gl.vertexAttribPointer(a_Position, 2, gl.FLOAT, false, 0, 0); //连接a_Position变量与分配给它的缓冲区对象 gl.enableVertexAttribArray(a_Position); return n; } [代码] 有了第一帧的绘制，用户可以很快进入到游戏内，不会长时间的在官方白色的加载进度屏那里等待。我们还需要做一些其他处理，不然玩家看到的将是一个黑屏。后续的处理也有两种方案，一种就是如果你对WebGL比较熟悉，可以自行完成更复杂的绘制。另外一种方案就是巧妙利用官方提供的功能。我们这里详细说下后面一种方案。 为了盖住黑屏，我们需要绘制一张启动图。这时候我们使用官方提供的接口[代码]wx.createUserInfoButton[代码]来创建一个满屏的按钮，按钮的背景图就是我们的启动图。但是这时候如果用户点击屏幕，就会造成提示用户授权，这不是我们想要的。接着我们使用官方的另外一个接口[代码]wx.showLoading[代码]，创建一个模态加载弹窗就可以解决这个问题了。有了这样一个首屏，剩下的就是尽快加载子包，开始真正的游戏内容。 四、Demo 希望大家也都能探索一下首屏加载的过程。我们提供了一个简单的demo示例，通过链接即可下载到。打开demo中的index.js文件，里面有操作步骤说明。 laya的例子： 链接: https://pan.baidu.com/s/18RS9HWpmp5l0V3WGQdNvzw 提取码: bdji cocos的例子： 链接: https://pan.baidu.com/s/1c_UPwdlEFuqprmG-QGMvpQ 提取码: jggt 五、结语 以上就是我们的启动优化方案，欢迎各位游戏开发者交流或提出宝贵的建议,对游戏充满热爱的小伙伴也可以选择加入我们大禹网络。HR邮箱：guyifen@dayukeji.com

我们对订阅消息的理解是，放在可以影响玩家切实收益的系统中，且玩家有需要即时获取变化内容。胡莱以下几个功能符合这个理解，体力恢复、矿山抢占、属臣争夺，我们目前将订阅消息能力应用于体力恢复通知。 游戏内的体力恢复机制是：体力不满时，体力随着时间自然增加，到达上限后不再继续增长。满体力之后玩家如果没有及时上线消耗，会有一种持续损失收益的感觉，特别是对于新手玩家，消耗体力定向获取资源，有利于应对前期提升的瓶颈。没有订阅消息之前，玩家为了止损，会大概计算体力恢复时间，在体力大概回满的时候上线消耗，让体力长期处于恢复状态。 现在玩家体力未满时，可以点击【回满体力告诉我】订阅消息，体力回满后会给玩家推送消息提醒玩家上线，一定程度上降低玩家的游戏负担，不需要计算、记忆恢复时间，收到消息后上线游戏即可。我们启用了体力恢复提醒模版，订阅玩家中，收到推送消息后短时间内上线的玩家超过30%，订阅玩家的每日登陆次数略高于未订阅玩家，一定程度上起到了提醒玩家进行游戏的作用。 [图片] 接入该能力后进行数据分析的过程中，无法统计玩家是否从消息推送直接进入游戏，所以我们是以玩家收到推送后首次登录游戏和推送时间的差值来确认作用效果。另外，由于每次推送之后玩家需要重新订阅，会影响玩家订阅的积极性，同时，这种形式也不适用于矿山抢占和属臣争夺两个系统，这两个系统状态改变频率高于体力回复，若只能推送一次就会失去推送的意义，如果可以进行长期推送，并且由玩家自由控制开关，比较适合这两个系统玩法。

为了大家更好的使用红包玩法为用户提供服务。小编对红包玩法的使用规范进行了整理，帮大家避开违规雷区。 红包奖励除现金外，还包含实物、话费购物卡等虚拟奖品、游戏道具等； 【规范说明】 1.     获取红包的任务设计 l 获取红包的任务中不得包含充值或者消耗充值的代币等赌博性任务； l 奖励需明确告知用户，道具类红包不得以现金为噱头传播； 2.     打开红包阶段 l 不得设置任何附加条件在打开红包环节，包括但不限于要求用户分享以及查看视频广告方可打开红包。 3.     提现阶段 l 不得设置任何附条件在提现环节，包括但不限于：限额提现（如“红包余额满10元即可提现”）、限期到账、以及使用任何非小游戏场景提现（包括但不限于关注公众号、下载APP提现等）。 4.     红包样式 l 红包样式不得仿冒、混淆官方红包。 l 红包分享图和分享文案不得仿冒、混淆官方红包 5.     红包分享 l 分享至群或好友时，不得出现完成分享操作后立即获利的诱导分享行为。包括但不限于：分享后立即获得红包，分享后立即完成红包任务等 【现金红包打款能力】     现金奖励可以调用微信支付商户的B2C打款能力下发给用户，用户直接提现。    点此查看 功能介绍及申请及开发指引

人类终于对微观世界发起空袭！搭载流畅的病毒数值球裂变系统，小游戏《消灭病毒》将大众玩家熟悉的飞行射击品类玩出了新花样。  [图片] 主副武器的养成与搭配空间，以及离手触发“子弹时间”的交互设计，鼓励玩家在病毒变种的压力下不断尝试新策略；加上波段化处理的关卡难度，让玩家在“爽关”与“难关”交织成的“心流通道”中渐入佳境，获取“慕然回首，轻舟已过万重山”的闯关体验。  [图片] 这款小游戏的开发团队Kunpo曾打造出《宫爆老奶奶》《异常》等口碑作品，Kunpo取自“宫爆”英文Kung Pow，团队想通过这一原创词来消除搜索的同名干扰，达到精准监测市场认可度的目的。出乎意料的是，率先突破400万微信指数的是他们的小游戏《消灭病毒》。   这款小游戏到底集成了哪些有趣的想法？来自Kunpo的制作人周巍为我们一一解答。 核心玩法构思 1.飞机VS病毒的灵感是怎么产生的？ 考虑到资源大小限制，在美术风格的概念设定阶段我们出具了四版美术设定，由于公司早期有大量的抽象概念设计积累，最终选择了我们擅长的抽象概念设计，同时大量使用了AE特效，增强轻科幻的视觉体验，这个设计差异会让用户觉得和市面上很多游戏长得“不太一样”。   然后当时正好在看一个动画片叫《工作细胞》，讲的就是身体里的血小板之类的微观世界，加上那段时间刚好有同事感冒了，所以就选了病毒这个题材。   2.各种病毒的能力是参照了真实世界里的病毒行为吗？ 会有参考，当时我们在现实的病毒图谱里找了很多样本可以拿来做特殊病毒或者BOSS。这块具体我们会在接下来的版本把病毒的图鉴迭代进去，让玩家了解它们对应的是现实里哪些病理机制。   3.众多副武器的效果和动画设计经历了怎样的创意过程？ 副武器特效动画我们对自己的要求除了流畅自然，还要有符合大众认知逻辑的拟真过程，至少在地球的科技背景下要符合逻辑。比如说发一枚火箭出去需要表现出“后座力”，再比如最后解锁的副武器电锯，电锯持续使用会过热，所以需要时间去冷却，我们就做了一个机械臂出锯收锯的动画。   4.小游戏为何也需注重震动反馈？ 因为触屏手机没有物理按钮反馈，震动反馈对触屏游戏的体验是很重要的，尤其是飞行射击这种讲求体验爽快感的类型。  分支系统设计 5.停止操作飞机进入思考缓冲时间，对于这款游戏的意义在哪？ 当战况特别激烈时，现实中可能会发生一些需要打断游戏去处理的事，这个时候如果需要手指滑动到右上角去点暂停的话，玩家的飞机很可能就会死在这个地方，所以手指离屏进入“子弹时间”可以让玩家立即停一停、缓一缓；而且这个机制也算是为非常硬核的用户提供了可以微操作的地带，这里面其实可以玩出很多花样来。   6.目前的版本不加入签到奖励、任务奖励等系统的原因是？ 签到和任务这块我们有两个考虑，我们觉得小游戏进入游戏后一定要快速进入核心体验，我们内部有一个设计原则，就是从点击icon到开始游戏不能超过两个步骤。点击icon算一步，所以没有很多的空间去弹出公告和签到奖励。如果让玩家在体验之前花太多时间，会抑制他们下一次打开的欲望。   7.随机出现的看广告试用满级副武器的机会，对玩家体验有哪些助益？ ‍试用满级武器是在非BOSS关的情况下小概率触发的。它的意义是每当玩家卡关感到绝望的时候，给玩家一点希望，暂时帮助他过关；此外可以让玩家随机体验到一种副武器满级之后有多爽，让他产生一种目标感去为了升级副武器而继续游戏。  小游戏版本特色 8.小游戏和APP版体现怎样的设计差异？ 这款产品比较特殊，是先有小游戏，再移植到APP，小游戏版有跟微信开放的关系链做结合，这个非常重要。   我们自己看游戏是不看次日留存、七日留存数据的绝对值的，这些对我们来说不是特别有价值，对我们有价值的是留存的衰减率，然后我们发现APP版本的二日到三日的留存衰减率要远远大过小游戏版，可以看出微信的关系链对于减缓留存的折损有非常大的帮助。   9.除了好友排行榜，微信的社交链价值还能如何挖掘？ 之后我们会挖掘挺多社交方面的玩法，比如“无尽模式”，当玩家成绩超过好友的时候好友就会被击落；然后还会做联机版本，可以直接开个房间，丢个链接给微信好友拉他进来当“僚机”助阵，预计5月会上线。 爆款的方法论 10.是否预料到《消灭病毒》会火？有没有深入探究本产品大受欢迎的原因？ 最早的确没想到会火到现在的程度。从当时看来，整个市场高品质的产品不多，所以我认为《消灭病毒》现在火的原因还是踩对了时点，刚好在小游戏市场往精品化转型的时候，收获了一拨对小游戏品质产生了更高要求的用户。   时机真的很重要，小游戏平台花时间把用户的审美调性培养起来了，而我们刚刚好在这个时机上线了这款产品，这个并不是刻意的，真的是运气好。   11.爆款总有背后的逻辑，之所以受欢迎也与玩法精妙的设计思路分不开，你们觉得自己的游戏算创意吗？创意的门槛高吗？ 《消灭病毒》确实凝聚了我们的许多创意点子。我觉得创意更多是一种思考和积累，在自己比较熟悉的品类里头，你做了足够长的时间，也有足够多的想法，那创意无非就是把自己平时不太敢做的东西做出来。因为别人也不太敢做，所以你做出来以后说不定玩家就觉得眼前一亮，觉得挺有意思。   创意门槛其实并不高，看你的想法积累得够不够多，敢不敢做。   12.不少好玩的游戏却因为题材不得不面对受众小的困境，比如一些独立游戏，Kunpo在自研产品时，如何权衡大众化问题，以避免曲高和寡的市场反馈？ 这方面我们现在也一直在探索中。大众用户就是由每一个我们组成的，我们做产品还是先把自己当成用户，了解大众用户一定比了解自己更难，所以还是先把自己取悦好，再推己及人。   团队做过很多看上去小众的游戏，比如说《异常》，它是一个编辑AI的游戏，面向的人群更多的像我们这样的程序员或者对编程有兴趣的人。我们发现这个人群虽然不大，但是对作品的忠诚度很高，如果这一人群对我们的游戏满意，那对我们来说就是一种成功。   13.刚才提到了日本动画片《工作细胞》，那平时你是否会在动画、电影等非游戏作品里头找灵感？ 我看动画比较少，但是平时看布袋戏比较多，比如说霹雳布袋戏、金光布袋戏。像布袋戏这样一种传统木偶剧种，它也一直在自我优化，不断融合一些日本动画元素和好莱坞大片的拍摄技法。现在的布袋戏无论是人偶设计、操偶的维度还有后期特效都比以前好太多，而故事和旁白在这二三十年间依然一脉相承，就感觉这种传承很了不起。   [图片] （扫码体验游戏）

我们有收到很多反馈：在开放数据域做UI界面太难了！！ “我只是想绘制一个简单的好友列表，最多加个赠送或者邀请按钮，在开放数据域做UI界面太难了！！” “开放数据域引入一个独立的游戏引擎会占据好多代码包体积” “纯canvas开发真的太麻烦，代码可读性差，事件处理也很麻烦” 这是很多开发者的心声。 为此，开发哥哥们也提供了开放数据域UI绘制的解决方案——轻量级的canvas渲染引擎。 体积小！性能还杠杠的！上面的demo就是用它完成的。 轻量级的canvas渲染引擎 这款轻量级的canvas渲染引擎，它具有以下特点： · 引擎体积很小，压缩之后仅~50kb； · 类Web开发，只需提供XML + CSS即可渲染界面，提高代码可维护性； · 性能强大：长列表滚动可跑满60帧； [图片] | 使用教程： · step 1：克隆本项目到合适的文件夹，引用引擎 [代码]// 通过Git的方式安装[代码][代码]git clone https:[代码][代码]//github.com/wechat-miniprogram/minigame-canvas-engine[代码] [代码]// 引用渲染引擎[代码][代码]import Layout from [代码][代码]'minigame-canvas-engine'[代码] · step 2：为UI界面编写模板和样式 [代码]let template = `[代码][代码]<view >[代码][代码]  [代码][代码]<text value=[代码][代码]"hello canvas"[代码][代码]> </text>[代码][代码]</view>[代码][代码]`[代码] [代码]let style = {[代码][代码]    [代码][代码]container: {[代码][代码]         [代码][代码]width: 200,[代码][代码]         [代码][代码]height: 100,[代码][代码]         [代码][代码]backgroundColor: [代码][代码]'#ffffff'[代码][代码],[代码][代码]         [代码][代码]justContent: [代码][代码]'center'[代码][代码],[代码][代码]         [代码][代码]alignItems: [代码][代码]'center'[代码][代码],[代码][代码]     [代码][代码]},[代码][代码]     [代码][代码]testText: {[代码][代码]         [代码][代码]color: [代码][代码]'#ff0000'[代码][代码],[代码][代码]         [代码][代码]width: 200,[代码][代码]         [代码][代码]height: 100,[代码][代码]         [代码][代码]lineHeight: 100,[代码][代码]         [代码][代码]fontSize: 30,[代码][代码]         [代码][代码]textAlign: [代码][代码]'center'[代码][代码],[代码][代码]     [代码][代码]}[代码][代码]}[代码] · step 3：调用渲染API，执行真正的渲染 [代码]// 将模板和样式传给渲染引擎，渲染引擎会生成布局树和渲染树等，准备渲染到canvas上面[代码][代码]Layout.init(template, style);[代码][代码] [代码] [代码]// sharedContext自行创建[代码][代码]Layout.layout(sharedContext);[代码] [代码]/**[代码][代码] [代码][代码]* 设置sharedCancas在主域绘制的物理尺寸和位置信息，这一步非常重要，[代码][代码] [代码][代码]* 因为子域渲染引擎并不关心外部使用的引擎是什么，而是自己监听触摸事件来进行事件处理，[代码][代码] [代码][代码]* 因此需要拿到真实的物理尺寸、位置信息来执行事件处理。[代码][代码] [代码][代码]*/[代码][代码]Layout.updateViewPort({[代码][代码]   [代码][代码]width : 200,[代码][代码]   [代码][代码]height: 100,[代码][代码]   [代码][代码]x     : 100,[代码][代码]   [代码][代码]y     : 100[代码][代码]});[代码] · step 4：效果预览 [图片] || TIPS： 详细的教程可以查看文档； 为了方便调试，还可以使用在线编辑功能； 上面的邀请好友获得激励的demo示例，也是用这个canvas渲染引擎实现的喔。 对定向分享奖励还有什么疑问或者经验分享？希望了解哪些方面的实践教程？欢迎在评论区留言。