Cocos Creator 2D物理引擎的使用详解

原创

于 2024-05-28 09:32:11 发布 · 1.4k 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#游戏引擎

Cocos Creator是一款优秀的游戏开发工具，它提供了强大的2D物理引擎，帮助开发者轻松实现游戏中的物理效果。在本文中，我们将详细介绍Cocos Creator中2D物理引擎的使用方法，并通过代码实现来演示其具体应用。

对惹，这里有一个游戏开发交流小组，大家可以点击进来一起交流一下开发经验呀！

一、Cocos Creator中的2D物理引擎

Cocos Creator中的2D物理引擎是基于Box2D引擎进行封装的，它提供了一系列的API和组件，方便开发者快速实现各种物理效果。通过2D物理引擎，开发者可以轻松实现物体之间的碰撞、重力、摩擦等效果，为游戏增添更加真实的交互体验。

二、2D物理引擎的使用方法

创建物理世界

在Cocos Creator中，我们可以通过PhysicsManager组件来创建物理世界。首先，在场景中创建一个节点，并添加PhysicsManager组件，然后设置物理世界的一些参数，如重力大小、碰撞检测等。

let physicsManager = node.addComponent(cc.PhysicsManager);
physicsManager.enabled = true;
physicsManager.gravity = cc.v2(0, -320);

添加物理组件

在Cocos Creator中，我们可以为节点添加RigidBody组件和Collid

最低0.47元/天解锁文章

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

Clank的游戏栈

关注关注

14
点赞
踩
11

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

参与评论您还未登录，请先登录后发表或查看评论

博客

AI游戏开发全自动编程课程体系(Cursor版,支持Unity/Cocos, Laya后续支持)

12-24

789

1: 基于AI工具+阅读《C#服务器+双客户端(Unity/Cocos)TurnKey》方案的架构与设计;基于《C#服务器+(Unity/Cocos)客户端Turnkey方案》全栈自动开发《好友对战五子棋》基于《C#服务器+(Unity/Cocos)客户端Turnkey方案》全栈自动开发《对战射击类游戏》基于《C#服务器+(Unity/Cocos)客户端Turnkey方案》全栈自动开发《捕鱼达人3D》基于《C#服务器+(Unity/Cocos)客户端Turnkey方案》全栈自动开发《割草类》

博客

技术分享：游戏战场中如何处理角色死亡时各种姿势的“尸体“

12-02

617

Step2: 要模拟角色"死亡"后不同的骨骼摆放的位置，姿势各有不同，那么我们要给人形动画的每个关节带上一些物理刚体RigidBody+物理形状。(3)全部把"物理人形骨骼"开启以后，在脚下给"物理人形骨骼"一个"物理爆炸"的力。Step5: "物理爆炸"结束2秒后，再禁用"物理人形骨骼"，这样角色就会躺在地面上，骨骼摆放为不同的姿势。运行的时候，正常情况下，"物理人形骨骼"都被禁用，不会对角色正常控制产生任何的影响。单独的针对"人形骨骼"的节点做一个独立的物理分组，不与其它的物理分组产生任何碰撞。

博客

搜打撤类技术分享：基于人形动画的上下半身分层状态控制

11-19

395

Move(下半身)+Idle(上半身)做为普通的Move状态，Move(下半身)+瞄准射击(上半身)做为带攻击的Move状态。支持Unity/Cocos双客户端，以“第三人称射击类”游戏为玩法主体，基于目前比较火的”搜“，”打“，”撤“的游戏结构，玩家通过战斗，收集装备，升级装备，获取宝物等可以战斗，可以撤退。ShootLayer: 播放角色的idle 或者瞄准射击动画，把ShootLayer的人形动画，带一个动画Mask, 只作用上半身。(2)：完整的第三人成射击类的”地图编辑器“的工具开发;

博客

给出一套方案：角色如何自由搭配枪械与武器

11-17

559

支持Unity/Cocos双客户端，以“第三人称射击类”游戏为玩法主体，基于目前比较火的”搜“，”打“，”撤“的游戏结构，玩家通过战斗，收集装备，升级装备，获取宝物等可以战斗，可以撤退。如果每种武器对于不同的模型，手臂的挂载点的位置不一样，我们可以在骨骼里面添加特殊的挂载点，来做到更好的匹配。分为"单手"模式与"双手模式",单手又分为"左手"与"右手"，左手就绑定到左手的"锚点"，右手就绑定到右手的"锚点"。step4: LateUpdate里面武器把自己的"锚点"与角色的"骨骼点"同步;

博客

关于“SUD全资收购Cocos“对开发者影响的一些看法

11-12

425

每次版本重大的升级，都会有很多的调侃，"这很Cocos"，“这很王哲”。对于开发者而言，其实也没有必要过于的担心，如果下一阶段Cocos的引擎还可以满足企业的需求，那继续用就可以了，如果不能满足需求，换别的引擎即可，从一个引擎换到另外一个引擎，对于开发者的技术成本没有那么高，代码能力，设计思想，处理经验等，不会随着引擎的切换而改变。不同的工具，不同的生态，不同的做法，也会带来很多思路上的不同和思维上的碰撞，其实对开发者更多是好事。"变化"能给"一潭死水"的生活带来"意想不到"的变化。

博客

新课发布：《逃离鸭科夫》搜打撤类商业化方案

11-04

342

考虑射击游戏的题材，本游戏为3D游戏，不考虑2D模板。游戏的商业化渠道主要面向微信抖音小游戏，来做关卡和策划案，如果是手游或Steam，再做更复杂的场景+关卡。《肉鸽类》同一套数值，同时支持2D/3D类游戏，商业化方案已经完成，很多学员关心接下来是哪个方案。我们在找全免素材的过程中发现一套素材还不错，角色也是百搭，正好结合最近很火的《逃离鸭科夫》我们决定下一个课程方案为：第三人人称射击类游戏，核心玩法为鸭科夫的核心玩法”搜，打，撤“。(1)：完整的第三人称射击类的"搜打撤"玩法的策划案，数值与成长体系;

博客

如何基于全免费素材，0美术成本开发游戏

11-03

1181

最近我们肉鸽游戏原型方案开发完毕，接下来做商业化。遇到的第一个问题就是美术成本太贵。找了一些美术外包公司评估，报价都在15万以上。和之前的游戏美术成本评估有比较大的差距。IAA纯小游戏在没有验证的时候就投入"高成本"(相对于小游戏来说)无疑风险比较大。我们内部商议决定："游戏商业化可以分为"数值商业化+美术精品化“。先快速试水与迭代，做好数值精品化。如果数据可以，再做美术精品化"。对惹，这里有一个游戏开发交流小组，希望大家可以点击进来一起交流一下开发经验呀观点1：免费素材3D比2D好,精品化2D比3D成本低

博客

战斗系统核心设计：如何提供机制解决游戏项目中的成百上千的Buff

10-20

1117

每一类Buff我们称为一个BuffModel, BuffModel实现了Buff的计算逻辑与策略，Buff框架根据BuffId的类型，找到匹配的BuffModel，再根据相关"属性"找到对应的处理函数，而BuffModel的编写留给具体的项目逻辑，我们只提供BuffModel的机制。比如复活以后，5秒的无敌状态，我们的实现逻辑为，计算伤害的时候，如果目标有"无敌Buff"，那么我们就不计算伤害直接返回。-1,表示的是大类默认的，如果有特殊的小类，我们就可以注册这个属性的特殊的小类。有限状态机，行为决策树？

博客

战斗系统架构：为什么游戏战斗适合ECS架构?

10-17

716

以此来代替传统复杂的继承体系。2: 游戏世界中的角色：玩家(主角，其它玩家角色，小兵队友等)，敌人(近战小怪，远战小怪，精英怪，Boss怪等)，道具(戒子，宝石，加速鞋等)，传送门，NPC(任务NPC, 商城兑换NPC等)，游戏子弹等。8: 面对5种英雄，8种军团兵种，25种敌人怪物，37种道具，49种技能，32种局内升级，15级的局外天赋升级，我们是如何做好技能与Buff的架构？优势4: 组织结构更加的清晰规范，基于不同的迭代，分开代码文件，避免一个代码文件中，N个不相关的代码逻辑，也方便重构与替换。

博客

《商业化陪跑肉鸽项目》正式结束!

10-13

383

2: 本教程的详细目录如下:(注:框架使用我们商用框架，课程没有包含在内)(8): 战斗逻辑采用ECS架构，扁平独立的逻辑处理，替代继承体系;(5)适合微小,抖小的创业者，快速基于我们的工具构建自己的产品项目;(2): 8种暗影军团角色，包含远战与近战，局外天赋与局内升级;(1)熟练掌握商业化项目的框架设计，策划案，项目开发;第048节战斗范围的调试区域绘制与被攻击时的决策规则。第080节局外战斗Buff与局内升级Buff的初始化。(4): 16种技能，17种道具，59种Buff;

博客

游戏开发中的暂停的设计

10-11

732

如此一来，当游戏战斗世界要暂停的时候，只要针对"游戏管理"来暂停不迭代，从而导致游戏管理的update不再迭代其它的战斗单元的"Logic Update",这样导致整个的游戏世界+游戏战斗单元全部暂停。思考2: 游戏暂停，我们是针对战斗逻辑暂停，其它的部分可以不用暂停，这样开宝箱等动画需求时，都不会受到影响，我们只是暂停游戏的逻辑迭代+游戏角色的动画暂停，游戏世界中的粒子暂停。(一)针对游戏战斗世界暂停，游戏逻辑管理负责做好游戏战斗单元的暂停与恢复即可：暂停战斗单元迭代，暂停战斗单元动画，特效。

博客

团体战斗核心技术：如何防止团体进攻中角色堆叠在一起

09-28

576

比如A, B两个角色同向向右移动，当A,B发现彼此"堆叠"后，A迭代完移动，然后堆叠处理模块再把A往回迭代，这样A就不动，B正常移动，这样多次处理后，A与B保持安全距离了，则A继续移动。如：角色与怪物走进了自己的攻击区域，则发起攻击，不会继续前进，自然就通过攻击来将"异类"的堆叠避免，如果有必要，也可以把同类堆叠处理改成全类防堆叠处理。"堆叠模块"在每次迭代的最后的逻辑处理。如下图的代码接口，战斗迭代的时候，堆叠发生在寻路导航，AI处理，技能释放等迭代的最后，最后再调用堆叠模块"来"修正堆叠"现象。

博客

经典面试题：“你们的项目中是如何做红点系统的“？

09-17

499

面试官你好，红点是复杂游戏必备的提醒玩家与推进玩家游戏进程的工具与手段，在项目中非常常用。每个公司的项目的需求不同，设计的方式和结构可能不一样，我们公司之前的某个项目是这样做的。

博客

面试经典问题：如何设计红点系统?

08-18

945

游戏开发中，随着功能越来越复杂，我们会有一些重点的提示，需要让玩家每天都了解与清楚，比如新触发的任务，未领取的奖励，商城中的特惠活动，有未读的系统消息，有新的装备可以穿戴上，达成可以升级条件，升级相关的角色与装备等需求。而二级界面下面可能又有不同，比如任务，二级分类为"系统任务"，“好友任务”，下面就有新的任务需要显示红点，一级分类"任务"有红点,同时二级分类"系统任务"，“好友任务”也要有红点提示。红点数据，不同的界面层级，有不同的红点数据，比如，一级界面的红点可能显示的是，任务，邮件，商城，奖励等。

博客

Unity面试技巧每日分享

08-15

238

某个类型的某个新上架的商品。1: 方便有红点需求的地方，调用一个接口就可以把红点展示出来,所以我们会提供一个显示红点的接口，只要调用，就能在特定的位置显示红点;而二级界面下面可能又有不同，比如奖励，下面就有未领取的奖励需要显示红点，而正式因为有未领取的奖励，所以一级界面"奖励"那里才有红点。3: 红点的显示有对应的层级，我们会把红点单独的放一个层级，这样避免红点来打乱界面的合批，同时能让红点在一起渲染。红点数据，不同的界面层级，有不同的红点数据，比如，一级界面的红点可能显示的是，任务，邮件，商城，奖励等。

博客

又亏了，《暴打小黑子》投流总结

07-22

807

上面是针对《暴打小黑子》这个项目的买量的一些操作与总结，又亏了^_^，调整后，可能我们经过不断多创建广告计划,做广告素材，然后可能能买到更高单价的用户，适配小黑子这个游戏，能让其ROI为正。7月14日，我们广撒网，创建多条广告计划，跑出一条ROI相对比较高的计划，7月17日，我们对这条计划做更近，发现ROI高的ECPM明显高于7月14日广投放的ECPM。经过这两个尝试以后，我并没有广创建计划，而是只创建了一条广告计划，来进行测试，发现出价到2.2还是消耗不动，消耗了的买回来的用户，还是几分钱级别的。

博客

Unity GPU Timeline性能热点分析与优化指南

06-30

850

/ 捕获Timeline执行区间。

博客

Unity基于GraphView的可视化关卡编辑器开发指南

06-06

1872

/ 基础设置// 网格背景// 样式设置// 创建节点连接关系// 禁止自连接// 输入只能连输出// 不同类型端口不能连接});场景优化策略大型关卡分区块加载/动态卸载复杂节点虚拟化渲染/按需加载实时预览LOD细节分级。

博客

2025年低成本创业项目：微信小游戏买量投流总结

05-06

2764

第16条: 当买的用户增加的时候，我们的利润也开始逼近"边际"，例如买量10000利润是1500, 买量15000,利润是14000,这个时候用户边际效应出现，可以讲买量的数目控制在 10000~12000之间，利润最大化。第4条: 出价的时候，不要扣扣索索，要用最快的速度买到有价值的游戏用户来做数据分析，以及进一步的买量规划，一般我们用高价来买，比如1元开始。第15条：关注好游戏运营数据与利润计算: 日活，时长，次留，日收入，ARPU，MP广告金投放，实际后台扣费, 实际投流成本，利润，ROI。

博客

Unity多线程渲染指令队列设计与集成技术详解

04-22

1508

通过本方案实现的指令队列系统，可将渲染准备阶段的CPU负载降低60%-80%，特别适用于大规模动态场景。// 参数数据偏移量。// 第一阶段：合并相同Mesh/Material的绘制命令。// 其他URP指令转换...// 其他命令处理...// 第二阶段：生成合并后的指令。：兼容不同图形API的线程限制。// 主线程每帧调用。