《合成骑士》微信小游戏，技术分享

Showcase
#1

开发了三周多，游戏终于上线了。
这里分享游戏当中用到的技术。功能太多了不能一个个讲下来，这里用提问的方式。
大家可以去玩玩看，对里面的功能有想知道怎么实现的，就在下方留言，我看到的话会跟你们讲一下实现的思路，很抱歉不能提供代码给大家。
这里也谢谢大家支持。
有需要的可以加我wx（上班的时候大家可以先把问题发给我，或者直接在帖子下面留言。下班有时间我会解答的。）：

6赞
#2

很厉害啊，画面很好，祝火

1赞
#3

想问一下楼主对于creator中的scrollview加载是怎么优化的

#4

首先我们把每个item作成预制体，在加载页面的时候实例化预制体添加到content当中。

为了优化，我限制了实例化的个数，然后在更新scrollview的时候判断是否需要更新item。
item的控制组件肯定有初始化item的方法。没有的自己写。
然后会在管理scrollView的组件脚本上自己记录scrollView的offset值，通过判断这个值来计算出当前需要显示的item的index，然后通过判断index是否改变来初始化item的表现跟更新位置。
比方说我一个content最多有4个item。现在计算offset得到要显示[0,1,2,3]。那就根据下标更新item。之后在拖动scorllView的时候计算offset得到要显示[2,3,4,5],这个时候再根据新的下标更新item。
再进一步优化，我们可以每次更新的时候只更新头尾两个item，中间部分的不变。这里提供思路，具体怎么写靠自己啦。

这个方法适用横竖方向单个item，如果是列表的话就用二维数组再做，思路都是通用的。

然后关于item drawcall的优化，首先要用图集来做UI，然后用到label的话，避免不了合批打断，只能重构scrollView content里面的节点结构，比如说我把一个item拆成两层（两个预制体），一层放图片信息，一层放文字信息，然后添加item的时候，把item的图片层一起放到一个节点里，文字层一起放到另一个节点里。
麻烦的是需要自己去管理这两个节点的位置保证其位置的统一。

总结：限制个数并重用，管理节点降低drawCall

3赞
#5

游戏不错

#6

mark

#7

可以可以，祝火~~~~

#8

页面很好看诶

#9

手机上也可以传火了，继续受苦吧

#10

太阳骑士找到了组织

1赞
#11

这里更新一下小伙伴在微信上问我的问题。
1、游戏数据是本地存储的吗
2、游戏数值计算思路是怎么样的
3、人物是骨骼动画做的还是？如果是的话那骨骼动画的资源替换是怎么做的
4.拖动武器合成是坐标计算去处理的还是用碰撞组件实现的

1.数据是存在本地的。
2.数值我们是参考其他游戏的。（我们没有牛逼的策划，整个游戏的数值其实不是特别稳定。如果有策划小伙伴想找工作可以联系我。）
3.人物是动画是用cocos creator 的动画编辑器调的。也是用骨骼动画的思路。换武器等其实就是更换武器节点上的图片。因为cocos现在还没有支持图片锚点的功能，所以我们是额外储存了每把武器的锚点信息，更换的时候设置节点的位置。盾牌锚点变化不大就不变了。
4.我们是用坐标计算的，为了性能跟包体考虑，我们几乎不会在小游戏当中用到碰撞和物理组件。这里简单的设计思路是：你可以把背包想成一个二维矩阵（数组），通过鼠标的位置和每个格子的大小计算出鼠标是在第几行第几列，然后对比按下时候的坐标跟弹起时候的坐标做处理。

2赞
#12

支持一波~~~~~~~~~

#13

多项装备合成你是怎么处理的啊 还是随机的形式对比相邻格子查看是否存在同类装备，然后进行合并生成的吗？

#14

遍历背包，判断是否有同等级的装备。
这里的算法我没有进行优化。

#15

问题很多 有待提高

#16

方便提点意见或者问题吗，我们会好好修改的:grin:

#17

更新一下微信提问
“想问一下游戏里面的“邀请/唤醒玩家”这个功能是怎么实现的”

邀请好友的功能，需要用到服务端。用微信提供的方法获得用户的openID，当作用户的唯一标识。https://developers.weixin.qq.com/minigame/dev/api/open-api/login/code2Session.html

我是临时学的服务器，数据库是这样设计的。
表1，存着
用户的openid,
用户已经邀请的用户数
表2，存着
发送邀请用户的openid

用户在发送分享卡片的时候，会往query里面传入自己的openid。
其他用户在通过这个分享卡片进入游戏的时候，可以获取到这个openid。

在向服务器发送请求的时候，会发送自己的openid跟邀请用户的openid。（前提是获得到openid了）
服务器收到请求的时候，会查询表1是否有openid的记录了，如果没有，则说明是新用户，往表1里面插入自己的记录。如果用户还是受邀用户，则会往表2里面插入一条邀请玩家的openid。

当发送邀请的玩家登陆游戏或者打开邀请页面的时候，会向服务器发送查询请求，带着自己的openid，服务器在收到请求后，会查询表2里面openid == 玩家openid的数据，这个数据的个数就是玩家邀请到的玩家的个数。然后会更新表1里面的用户已经邀请的用户数。然后删除表2里面的相关记录。最后返回给客户端的就是表1里面用户已经邀请的用户数。

这是我自己瞎搞的，反正用着没有问题。（有问题我也不知道。哈哈）

这里也算抛砖引玉，大家有没有其他更好的方法？

#18

OpenId应该是在服务器获取的，当然在客户端获取也行，我们公司做的分享也是取启动参数，就是当用户分享的时候，会吧自己的UserId带上，然后当别人点击小卡片上，会把获取到的启动参数作为登录服务器的一个参数，后台会判断，其他就差不多

#19

请问下楼主，item index你是如何计算的，谢谢。

#20

没看懂这算小游戏吗。。。