个人开发小游戏路上的一些“坑坑洼洼” 新游上线 ：欢迎指点《冲吧地球》！

Creator 2.x
#1

**

难得闲暇，瞎写了一点分享（槽点）；

**

开场自白

首先！祝贺你踏入CocosCreator引擎开发这个大家庭/大坑（为自己默哀三秒钟）！算起来到现在（19年5月），我刚好入坑CocosCreator小游戏开发一周年，想起来其实说是能分享出来的点就是为了实现各种各种的套路的技术。（呜呼哀哉！）

微信小游戏

就以这几个月做的割草游戏这个系列中用到的点来做说明，分享的同时也是为了回顾一下自己在游戏中用的技术点（也许称不上技术）。（下面一段为个人感慨，请自行绕过！）
因为是在小公司，从项目的开发到各种迭代，几乎不会有闲暇的时间，有的时候一天要在几款游戏间换来换去，特别是最近在做的割草系列的，有时候连老板自己都不知道哪一款是哪一款了……。（PS：创业不容易，无论是老板还是作为员工的我们，且行且珍惜吧！）

言归正传！！！！

适配

我印象中自己好像并没有去看过多少别人的源码，就算去看也是为了看看人家怎么实现某个功能的，所以我也并不知道真正的大潮流中的适配方案是怎么样的，我就讲讲我自己的适配方案！有什么好的建议给我的可以联系我，大家共勉！

一般界面弹窗节点适配

我做游戏一般选择的游戏尺寸是720 x 1280，之前看都过有技术分享的文章说，其实大多是我们想节省资源空间的时候可以选择 450 * 800 这种低一点分辨率，我觉得对游戏的像素要求不那么高的游戏，这个策略是可以的，因为现在做游戏几乎都是要适配的， 你想象一下一张100100的图片，放大到 300300 ，其实大多数时候是不会差到哪去的！
再回来说我的方案，这个720X1280没有任何用意，选择自己习惯的，符合大流的机型比例就好。
在此之前我的界面弹窗几乎都是做成 prefab预制节点，弹窗一般情况都是弹出到当前最上层并且不可穿透的，那这就隐含着两个需求：

  1. 完全覆盖背后的（既是低于当前弹窗）UI，而且大多数弹窗是有遮罩的，那这个遮罩就更得完全适应屏幕；
  2. 弹窗中的UI必须自成一体（这个可能是我自己臆想的…………）；
    我的做法好像一直没变过，也没仔细看过别人怎么做的：
    xxxNode（bg，rootNode（弹窗中的各种childNode）），结构一直就是这样：
  3. “xxxNode”表示这个弹窗的根节点，一般适配为屏幕的大小
  4. “bg” 就是遮罩，一般就直接用 widget全适配父节点
  5. rootNode就是重点要适配的节点，首先默认的大小设置成跟我们的默认大小一样，然后按现在手机厂商的尿性，一般都是越出越长（就跟在掩饰他们的“短小”一样），所以一般我选择的是宽适配，
    代码里面
    rootNode.width = cc.winSize.width;
    rootNode.width = cc.winSize.width*1.77778;
    然后那些sprite、button 什么的全放到rootNode下，使用widget适配就可以了
  6. 对于那些特殊的机型，要是有什么特别的需求，可以在判断机型的条件下做特殊的处理

套路的需求适配

如果你的公司是只靠广告挣钱的，而且也不是特别特别高品质的话，那么你的游戏难免会需要套路玩家。
最常见的就是banner广告的误点, 比如一个button无限靠近banner，或者一开始是按钮的位置突然蹦出来一个banner同时按钮刚好移到banner的边边位置， 这个的适配就比较繁琐一点，因为微信的banner广告的位置、大小信息采用的是逻辑像素来表示的，而我们正常开发的时候用的都是物理像素。更骚的是各种机型之间这两种像素得到比例还是不一样的。
其实有两种方法做这方面的适配，一种是利用微信的wx.getSystemInfoSync()获取设备的信息，然后根据里面的有用信息进行调整；我一般用的就是自己算一套比例出来，同样上面的接口获取到屏幕的逻辑像素，然后通过和屏幕的物理像素对比，得到一个比例px_pt，接下来只要拿到banner.style.top这个数据，就能设置button到紧挨着banner的位置了。

PS

如果是弹窗中的按钮和banner之间的关系，那这个按钮的父节点选择好会更方便点！

ps中的ps

如果要做这种 -误点- 的操作的话，最好做一下版本控制或者地域限制，不然应该过不了申的

摄像机的新手操作

这个游戏的游戏场景我是用到了两个摄像机，一个是控制UI的展示的，既那些需要一直展示在场景中间的UI、弹窗就挂在这个摄像机上；
还有一个最主要的，也就是跟随割草器视角的摄像机，其实这个摄像机要做的操作也就几个：

  1. 跟随割草器改变位置，保证割草器一直在我们的视角中间
  2. 改变摄像机的“zoomRatio”，实现拉伸视角的效果
  3. 摄像机的“culingMask”中具体要勾选那些，就得看具体情况了，我这里是但凡需要进行拉伸的组，就都勾选上
    ** 其实想来想去也不知道游戏里面具体用了什么知道记录出来的功能点，只能瞎比比了………… **

tiled map 的一点点使用体验

至于游戏中的瓦片地图，我这边的做法是这样的：因为我不想分包也不想用服务器，所以100关的地图，加上各种各样的资源，如果按正常操作，地图上的土地层、草层、花点这些全弄上的话，资源就太大了，而且工作量也太大。所以就选择地图工作减少，靠代码来解决：** 每一张地图上就画出土地背景和标记这张地图需要种什么颜色的草，然后就用代码来检测这张地图上土地层的位置及其范围和该种什么草， 然后再按一定的密度种上草，放上特效花 **。 然后就没然后了。

广告的杀币操作

来波《天天割草》的AI探索之路

补充点啥呢？？？

下次闲暇再补点

##PS 新游上线 ：欢迎指点《冲吧地球》！

4赞
#2

怒顶:2:

#3

mark

#4

误点的设计真的不自重，大家克制一下哈哈

#5

我根本不知道什么是适配，我的设计是900 1600 :joy:
我也不知道该咋办，这样行不啊

#6

这个自重不自重全在上级，就算再抵制，还是吃饭重要

#7

大概比例差不多就ok

#8

新游戏！《冲吧地球》，大佬来指点一下怎么优化

#9

大量节点隐藏的时候建议使用opacity = 0 来做。
能优化帧率。

#10

大量节点使用修改透明度的话，但是实际节点数量还是摆在那啊
比如我有一关一共有800个节点，如果只是用修改透明度， 这也是可行的方案吗？

#11

因为不了解你的游戏机制是怎样的，建议可以用对象池去回收。

#12

现在用的就是对象池，就是当屏幕中存在太多节点的时候就会卡顿了！！菜鸟村出来的，没什么好的优化方案！！

#13

我有个项目最多会生成1300个节点，但是dc只有7，所以玩起来并不会卡（直到我给每个节点加了拖尾，dc变成了1300就没法玩了）。这个项目看起来应该也不会卡顿。图片小，纯白，甚至用的是官方图片，又有对象池处理，照理来说应该是不会跌下50帧才对。

#14

跪求指导！！！

#15

emmmm，其实我也只是个小白，可以相互分享下，白色节点是一次性生成的还是逐渐生成的？节点进入屏幕会不会有dc的变化？你说节点大量进入屏幕时卡顿大概会掉多少帧？