Unity 最新DOTS系列之《Baking与Baker的详解》

原创 于 2023-10-23 09:37:48 发布 · 828 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#unity #游戏引擎

本文分享了Unity DOTS中Baking与Baker的关键概念。介绍了Authoring、Baking、Baker的含义，剖析了Baking机制，包括Authoring Data、Runtime Data，以及Full Baking和Incremental Baking两种模式。还分析了Baker机制，说明了依赖关系，并给出了普通MonoBehaviour Component的Baker代码示例。

Unity DOTS Baking与Baker详解

最近DOTS终于发布了正式的版本, 我们来分享一下DOTS里面Baking 与Baker的关键概念，方便大家上手学习掌握Unity DOTS开发。

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

Unity DOTS开发模式,为了让大家在”创作”游戏的时候使用原来组件方式来编辑游戏场景与资源，同时Unity提供了一种Baking机制，把普通的GameObject数据转成ecs模式下的entity数据，程序运行的时候，直接加载转换好的ECS模式的数据。在深入了解Baking与Baker机制之前，我们先熟悉几个概念:

Authoring: 英文单词是”创作”的意思，上文提到ECS模式开发的时候创作游戏节点可以使用原来的方式，再通过baking转换。所以那些待转换成ecs 模式的GameObject与Component被称为Aurthoring。

Baking: 指的是把传统GameObject+组件数据转成ecs模式下所需要的

最低0.47元/天 解锁文章
博客
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 345
考虑射击游戏的题材，本游戏为3D游戏，不考虑2D模板。游戏的商业化渠道主要面向微信抖音小游戏，来做关卡和策划案，如果是手游或Steam，再做更复杂的场景+关卡。《肉鸽类》同一套数值，同时支持2D/3D类游戏，商业化方案已经完成，很多学员关心接下来是哪个方案。我们在找全免素材的过程中发现一套素材还不错，角色也是百搭，正好结合最近很火的《逃离鸭科夫》我们决定下一个课程方案为：第三人人称射击类游戏，核心玩法为鸭科夫的核心玩法”搜，打，撤“。(1)：完整的第三人称射击类的"搜打撤"玩法的策划案，数值与成长体系;
博客
如何基于全免费素材，0美术成本开发游戏
11-03 1181
最近我们肉鸽游戏原型方案开发完毕，接下来做商业化。遇到的第一个问题就是美术成本太贵。找了一些美术外包公司评估，报价都在15万以上。和之前的游戏美术成本评估有比较大的差距。IAA纯小游戏在没有验证的时候就投入"高成本"(相对于小游戏来说)无疑风险比较大。我们内部商议决定："游戏商业化可以分为"数值商业化+美术精品化“。先快速试水与迭代，做好数值精品化。如果数据可以，再做美术精品化"。对惹，这里有一个游戏开发交流小组，希望大家可以点击进来一起交流一下开发经验呀观点1：免费素材3D比2D好,精品化2D比3D成本低
博客
战斗系统核心设计：如何提供机制解决游戏项目中的成百上千的Buff
10-20 1118
每一类Buff我们称为一个BuffModel, BuffModel实现了Buff的计算逻辑与策略，Buff框架根据BuffId的类型，找到匹配的BuffModel，再根据相关"属性"找到对应的处理函数，而BuffModel的编写留给具体的项目逻辑，我们只提供BuffModel的机制。比如复活以后，5秒的无敌状态，我们的实现逻辑为，计算伤害的时候，如果目标有"无敌Buff"，那么我们就不计算伤害直接返回。-1,表示的是大类默认的，如果有特殊的小类，我们就可以注册这个属性的特殊的小类。有限状态机，行为决策树？
博客
战斗系统架构：为什么游戏战斗适合ECS架构?
10-17 717
以此来代替传统复杂的继承体系。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 733
如此一来，当游戏战斗世界要暂停的时候，只要针对"游戏管理"来暂停不迭代，从而导致游戏管理的update不再迭代其它的战斗单元的"Logic Update",这样导致整个的游戏世界+游戏战斗单元全部暂停。思考2: 游戏暂停，我们是针对战斗逻辑暂停，其它的部分可以不用暂停，这样开宝箱等动画需求时，都不会受到影响，我们只是暂停游戏的逻辑迭代+游戏角色的动画暂停，游戏世界中的粒子暂停。(一)针对游戏战斗世界暂停，游戏逻辑管理负责做好游戏战斗单元的暂停与恢复即可：暂停战斗单元迭代，暂停战斗单元动画，特效。
博客
团体战斗核心技术：如何防止团体进攻中角色堆叠在一起
09-28 576
比如A, B两个角色同向向右移动，当A,B发现彼此"堆叠"后，A迭代完移动，然后堆叠处理模块再把A往回迭代，这样A就不动，B正常移动，这样多次处理后，A与B保持安全距离了，则A继续移动。如：角色与怪物走进了自己的攻击区域，则发起攻击，不会继续前进，自然就通过攻击来将"异类"的堆叠避免，如果有必要，也可以把同类堆叠处理改成全类防堆叠处理。"堆叠模块"在每次迭代的最后的逻辑处理。如下图的代码接口，战斗迭代的时候，堆叠发生在寻路导航，AI处理，技能释放等迭代的最后，最后再调用堆叠模块"来"修正堆叠"现象。
博客
经典面试题：“你们的项目中是如何做红点系统的“？
09-17 499
面试官你好，红点是复杂游戏必备的提醒玩家与推进玩家游戏进程的工具与手段，在项目中非常常用。每个公司的项目的需求不同，设计的方式和结构可能不一样，我们公司之前的某个项目是这样做的。
博客
面试经典问题：如何设计红点系统?
08-18 947
游戏开发中，随着功能越来越复杂，我们会有一些重点的提示，需要让玩家每天都了解与清楚，比如新触发的任务，未领取的奖励，商城中的特惠活动，有未读的系统消息，有新的装备可以穿戴上，达成可以升级条件，升级相关的角色与装备等需求。而二级界面下面可能又有不同，比如任务，二级分类为"系统任务"，“好友任务”，下面就有新的任务需要显示红点，一级分类"任务"有红点,同时二级分类"系统任务"，“好友任务”也要有红点提示。红点数据，不同的界面层级，有不同的红点数据，比如，一级界面的红点可能显示的是，任务，邮件，商城，奖励等。
博客
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的线程限制。// 主线程每帧调用。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值