h5游戏开发_【Creator】H5小游戏开发（一）

前言

在使用Cocos Creator开发小游戏过程中，遇到了不少值得探究下去的问题，因此写下这篇博客分享总结，希望能给遇到类似问题的朋友一些思路。

---

• 骨骼碰撞

在投掷标枪的游戏中，人物是骨骼动画资源，标枪是带刚体的节点，我们希望标枪可以投掷，并且击中人物后，跟随人物移动。

Weld Joint - 焊接关节，根据两个物体的初始角度将两个物体上的两个点绑定在一起。

WeldJoint是官方提供的焊接关节，它可以解决标枪连接刚体的问题，但是想让标枪一直跟随着人物移动，那么人物必须得是一个刚体，另外人物是骨骼动画资源，意味着我们希望人物在播放动画过程中，标枪也跟随着移动，例如人物手舞足蹈，标枪也跟着动，这意味着标枪是跟随焊接点移动，如，击中的是手腕，那么手腕每一个细微的移动，都希望能改变标枪，刚开始想着在骨骼节点下创建一个刚体，但是事实上没有直接的接口提供这样直接操作，因为creator（v1.9.3）本身不支持对骨骼节点的碰撞修改。

后来就考虑着在人物同层级的位置，单独对人物的关节创建对应的刚体节点，然后对骨骼动画监听，提前沟通好动画关节的移动轨迹，那么创建的刚体节点轨迹也就可以定好，这样就基本满足跟随需求。

---

• 同步问题

同步问题涉及比较广，因为产生同步问题的原因也不少，下面所提及的同步问题不可能涵盖的那么全面，但也包含绝大数游戏面临的同步问题，下面逐个讲解

浮点计算的误差

实时对战类游戏，需要考虑不同设备去模拟的问题，不同设备浮点数计算存在误差，这个误差不容忽视，物体之间的碰撞，角度大小、力度大小如果存在差异，那么就会出现不一致的问题，导致体验非常差。

最初上图的游戏出现同步问题，以为是物理步长不同所导致，（物理步长指的是物理引擎更新的频率，类似Unity中的fixedUpdate），后面设定了相同的物理步长依然存在多次碰撞后，导致球的位置不一样，事实上问题不仅仅这一个原因。

要知道物理引擎，所做的移动、检测碰撞、得出各种角度都是对像素的计算，那么这些计算过程中，出现浮点数是很频繁的，那么这些浮点数在不同设备上的计算偏差也就存在了。

定点数计算

如果存在浮点数问题，但游戏事实上精度要求并不高，只希望控制在一定精度范围内，不需要达到高精度的计算一致，只需要基本一致，从而使得游戏结果一致，那么我们可以考虑采取定点数，保留小数点固定几位，并且客户端手写四舍五入的实现函数，这样的计算偏差是基本可控的。

“回合制”物理模拟

部分游戏，要求物体碰撞，但却不是完全实时的，它所要求的是回合制表现。 我选择的处理方式是，自己回合自己的客户端直接用物理引擎跑效果，并且将这个过程中的物体坐标，全部按一个与后台约定好的帧率发送给服务器，服务器纯转发给其他客户端，其他客户端收到消息后，立即修改物体坐标，保持与服务器一样的帧率去更改坐标。如果不是自己回合，那么自己就是接收者，接受到服务器消息就去更改坐标。关于坐标的同步采取用UDP的方式转发所有坐标。

巧用动作系统

部分游戏只是要求移动，当然也可能另外要求移动具备不同速度的表现，如下图，不同矿石质量不一样，最终导致爪子速度表现不一样，这里可以考虑不使用物理引擎，巧用部分动作系统的方法，是可以达到简单的移动需求的 只需要准确控制物体移动的起点，朝向的终点，以及过程的耗时，那么两个客户端出来的效果，通常是一致的。

//收到点击屏幕的消息，出爪

实现部分物理计算

有些游戏适合去手写物理计算的逻辑，与后台统一，这样客户端只是一个输入设备，把计算交给服务器，那么多个客户端的物理结果都由服务器下发，是否碰撞，速度结果，都听服务器的，这样大家的结果都是一致。这部分内容会在下次的博客中详细讲解。

---

其他

在做实时对战游戏，UDP丢包会导致接收方的表现没那么平滑，那么这时就需要用线性插值去“补偿”，丢失的数据是一个过程量，少了过程量意味着游戏物体移动有种跳跃及停顿感，如果A点到B点有填补移动，那么视觉上是可以接受的，少了停顿感，游戏体验也会好很多。