解构是Rust的高级特性.

定义特型,类型实现特型,类型上调用特型方法,这是常见的调用方法.

看下面的代码会不会有些别扭,重点看ScorerBuilder::label(builder).

一般的plugin自己就决定了在哪个调度中执行system. 灵活性高一点的plugin则将决定权交给开发者.

下面这段代码非常有意思,将调度做为Plugin的配置进行动态设置.

声明:schedule: Interned<dyn ScheduleLabel>, 使用:schedule.intern().

做为一个0基础学Bevy的淌坑者,下面是一下学习资料汇总,没有这些开源者的贡献,Bevy社区不会高速发展,请给他们认可.

第一次接触Bevy的人

预计10分钟(包含做笔记的时间).

官网首页了解Bevy是什么,包含什么,主打优势是什么.

一个游戏有很多功能,Bevy能做什么,如何做

预计2周(8*14=112小时,如果每天看1小时,周末每天4小时,且刨除不感兴趣的部分,半个月就能啃完).

这个部分是最基础的部分,也是基石,时间花的多,回报也高.这部分花的时间少了,后续提速使用AI时,就缺少分辨能力了.

官方example是初学者/熟练者都需要反复学习的, 捡一些能懂的看,对于看不懂的先跳过,不要但心会遗漏什么,因为后续这些例子会升级, API的升级,性能的优化都会直接体现在这些例子种,需要反复学习,所以别担心遗漏.

对于example经常出现的类型和方法,需要跟进去,简单看一下源码和注释,这是熟悉Bevy用法最好时机.

有了example的学习,下一步需要知道Bevy中遵循的基本规则

预计1周.

bevy cheatbook入门书籍,优点是成体系,快速扫盲.

阅读时需要将书中提到的每一个概念都弄明白,每个链接都浏览一下. 以Bevy内置概念为例,我个人的学习方法是:

1. Bevy独有的,查源码的注释,这个非常丰富,是什么,怎么样,和谁打配合都有详细描述
2. 其他生态的,如gltf/wgpu,搜索引擎,AI聊天,很快就知道是什么了
3. 行业的,如图片格式有很多种,查其优缺点和适用范围,是哪家主导的,支持怎么样
4. fork+新分支,将cheatbook做成双语,查到的资料贴在下方

入门书籍本身就包含了两点意思:

1. 仅包含入门所需的最小知识,如果入门的知识点不掌握透彻,那后续的高级知识点就很模糊
2. 仅仅是入门,仅包含Bevy本身.那些更高级的方案并没有包含在内.这是一个起点.

看完后,再刷一下example,有内功的加持,阅读速度会大大提升.

在处理一个完整游戏之前还需要对具体方面做扩展

查生态库有两个地方:

1. bevy汇总
2. 自己搜索,很多优秀的库和例子都没被收录到上面的链接中

每一个生态库就是一层封装,生态库会跟随Bevy发展,内部的API变化和逻辑变化就被隔离了.

比如说input/audio/animation/ui等场景,生态库一定是要看的.

至于为什么,很好解释:Bevy是通用底座,在具体方面不足才有了生态库,就像树干和树枝的关系, 树枝粗到一定程度,就会被Bevy吸收成为底座的一部分,这是Bevy的发展策略, 几大顶级生态库作者也是Bevy的核心开发者,他们都是认同这个做法的.

生态库专精一方面,所以不会很复杂,源码阅读即能学习Bevy的高质量用法,又能学习如何扩展新功能.

完整游戏的学习

前面做的种种都是为了实现自己的游戏,有了前面的基础功,下一步就是大量学习别人的写游戏.

itch jam 都是好去处,看看bevy能做到哪一步.

itch还提供了大量资产,大量游戏,是个宝库.

工程化

多关注bevy issue和生态,很多人都在努力让Bevy变的更好.

游戏之所以需要 AI，本质上是为了让虚拟世界里的角色看起来有“智能”， 让玩家觉得“他们在思考”，从而增加沉浸感、挑战性和乐趣。

🎯 为什么游戏需要 AI？

🤖 游戏 AI 能做什么？

📌 一句话总结：

游戏 AI 是让 NPC 看起来“活着”的灵魂，让游戏世界有逻辑、有反馈、有惊喜。如果没有 AI，所有角色就像木偶，只会傻站着或重复动作，根本无法打动玩家。

🧱 没有 AI 时，你需要做的事（用“脚本/状态手写硬逻辑”补上）：

🔄 你需要补的模块：

1. 大量的状态/条件判断代码（手动实现“if…else…”）
2. 写死行为逻辑树（每个 NPC 单独写行为流程）
3. 人工调试每种情况的切换（异常容易错）
4. 使用计时器、事件系统模仿“感知”和“选择”
5. 更多维护成本（越复杂越难 debug）

📌 举个例子：

比如你想让敌人“看到玩家就追，追一段时间没追到就放弃”， 如果用 AI（比如行为树或状态机），只需要几条规则就能搞定。

一个项目依赖性多少库,可以从这个视角来看:项目包含feature,feature依赖库, 不想依赖某些库,就disable对应的feature.

.rustfmt.toml是rust项目的格式化配置,这些自定义选项会增加工程的通用性. 以下是从各个Bevy生态库中汇总而成的.

ECS是一个完整的体系,不管是component还是system的参数解析信息都有cache, 这样能显著提高性能,另外各调度的延后执行让并行概率提高,这都得益于ECS的设计.

那么有没有这么一个system,不仅仅使用了system param,还要使用其他非systemparam的参数呢?

bevy有扩展:In,表明system的第一个参数In是调用方传入的.

ScreenWrap 是一种游戏机制,当角色或物体从屏幕的一侧移动出去，会从对面另一侧“穿出来”，就像世界是环形的那样。

🎮 举个例子说明游戏画面： 你控制一艘飞船，在一个 2D 太空中飞行。 飞船从右边飞出屏幕 → 它会从左边重新出现。 飞船从下方飞出屏幕 → 会从上方跳出来。 像是一个穿了个洞的世界地图，角色在边界不断“转圈圈”，没有尽头。

这个机制有什么用？

• 节省资源：地图可以很小，视觉上却像是无限的。
• 增强玩法：让玩家思考更多空间策略，比如“绕过去攻击敌人”。
• 增强节奏：物体不会飞出地图消失，而是持续存在，战斗更激烈。

OO中的多态是子类各有各的逻辑,调用时用父类类型但传入子类, 保障代码简约的同时大大提高扩展性,是OO的三大基本特征之一.

在下面的代码,使用两个特型就模拟出了类似的效果. 特型Spawn实体生成器有两个实现: EntityCommands普通实体生成器和RelatedSpawnerCommands关系实体生成器.

这里核心是实体生成器Spawn可以生成挂件Widgets. 不管是挂件还是实体生成器都是特型,后期就算新增了其他的实体生成器,这块的代码都不用修改,灵活.