什么是comfy？

目前Comfy的master分支进行了许多性能改进，尚未发布。如果您在性能方面遇到困难，请考虑使用master分支。更多详情可以在变更日志中找到。

如果您是新手，请查看我们博客上的Comfy公告和v0.2版本发布公告。

Comfy是一个有趣的2D游戏引擎，使用Rust编写。它设计得有观点、高效且易于使用。它使用了wgpu和winit，这使得它是跨平台的，目前支持Windows、Linux、MacOS和WASM。受到macroquad、Raylib、Love2D和其他许多项目的启发，Comfy设计得既简单又实用，能覆盖大多数常见用例。

警告：Comfy目前处于积极开发中。虽然已经有游戏开始使用Comfy，但其API尚不稳定，可能会有重大变更。如果您想用Comfy制作游戏，可能需要深入研究源代码并手动调整一些内容。但话虽如此，源代码设计得简单且易于修改。如果您想制作游戏快闪游戏，Comfy已经足够成熟。

comfy被命名为comfy，因为它非常易于使用。

use comfy::*;

simple_game!("Nice red circle", update);

fn update(_c: &mut EngineContext) {
    draw_circle(vec2(0.0, 0.0), 0.5, RED, 0);
}

Comfy的最终目标是以尽可能简单的方式完成显而易见的事情，无需多余的形式。如果某些功能使用起来令人烦恼，那它就是一个应该被修复的bug。我们并不一定追求对初学者的友好性，而是追求高效和直观的API。对于初学者来说，Comfy应该很容易上手，但它可能不如其他一些替代方案那样完美。Comfy的目标最终不是完善、API的整洁性、设计清晰、类型安全、可扩展性或最大功能。Comfy是一个能够帮助您专注于制作游戏的引擎。

没有什么是从根本上阻止Comfy成为3D引擎的，但我们最不想做的就是与rend3或bevy在PBR精度或骨骼动画方面竞争。Comfy不是与虚幻引擎5竞争。如果简单、风格化、3D游戏（点击查看）、（点击查看）、（点击查看）最终能够实现，那就太好了，但我们首先想得到所有2D的基本构建模块。Comfy的一些内部功能（批处理和Z排序）需要重新实现，以允许这样做，并最终实现更高效的渲染技术，但这不应该以牺牲API的清晰度和大多数游戏的易用性为代价。

功能

• 简单高效的API。
• 支持精灵、文本和形状的即时模式渲染，带有自动批处理。如果你想画一个圆，你可以调用函数 draw_circle。
• 具有HDR、色调映射和泛光功能的2D光照。
• 内置对z-index的支持，这意味着你不必担心你的绘制调用顺序。
• 内置egui支持。
• 支持大多数图像和音频格式的并行资源加载。
• 没有复杂的ECS或抽象需要学习。只需构建你的游戏，让Comfy为你让路。
• 使用kira的简单音频。如果你想播放声音，你可以调用函数 play_sound。
• 简单的2D摄像机。
• 粒子，包括简单的API用于单个粒子以及具有许多选项的系统。
• 带有自定义网格和滚动纹理的轨迹。
• 文本渲染（目前使用egui）。
• 许多用于常见任务的实用工具。

设计目标与哲学

• 高度关注易用性和生产力。
• 没有魔法。代码做它看起来应该做的事。
• 针对简单游戏，目前仅限于2D。
• 有见地的和有用的默认值。
• 简单的即时模式API几乎用于一切。
• 当需要时，暴露内部功能。几乎所有结构字段都是公开的，Comfy不会将事情从用户那里隐藏起来。
• 合理的编译时间。Comfy的编译速度比macroquad慢，但我们想避免事情失控。最终用户不需要使用任何proc宏来使用Comfy。
• 全局变量很棒。Comfy使用了大量的全局变量。
• 少打字很棒。Comfy有一个单独的上下文对象，它被传递到每个地方。
• 约束很棒。Comfy想要用于许多游戏，但不是所有的游戏。
• RefCell很棒。Comfy大量使用它们来处理部分借用。我们多次尝试在不使用它们的情况下做事，这更痛苦。

非目标

• AAA 3D支持。虽然完全有可能扩展渲染器来处理3D，但这还没有有意为之。3D模型、材料、骨骼动画等带来了很多复杂性。Comfy可能会在未来支持简单的3D游戏，但它极不可能试图与大型3D引擎竞争。我们想确保我们拥有的东西能够很好地工作并且可用，然后再添加更多的复杂功能。
• 基于ECS的引擎。虽然Comfy嵌入hecs并提供了一些辅助工具来使用它，但这并不是必需的，甚至不是大多数情况下的最佳选择。
• 模块化。Comfy不是一个模块化引擎。它是一个有见地的工具包，它为大多数游戏提供了有意义的默认值。没有意图拥有插件系统或替换wgpu的能力。
• 最高性能。Comfy 并非旨在成为最快的引擎。为了人体工程学和易用性，我们做出了许多权衡，其中一些会影响性能。如果您正在寻找绘制百万个四边形的最快方式，Comfy 并非您所需。然而，如果您有性能不足的正当用途案例，请提交一个问题。在性能方面有很多低垂的果实，但由于开发由实际应用驱动，除非在游戏分析器中显示出来，否则不太可能进一步优化。

入门指南

仓库中的 comfy/examples 文件夹包含许多示例。虽然目前没有文档，但 API 简单到只需阅读示例就能解释清楚。

为什么使用 Comfy 而不是 X？

macroquad

在我开始开发 Comfy 之前，我一直在使用 macroquad 进行我的游戏开发。它工作得很好，但缺少一些东西，最重要的是 RGBA16F 纹理，这是 OpenGL 3.x 的特性，没有它 HDR 实际上无法实现。这是因为 macroquad 针对较老的 GLES 版本来实现更好的跨平台支持。虽然这对许多用例来说很棒，但当时我非常想尝试 HDR、辉光和色调映射，这让我走上了 wgpu 的道路。

Comfy 的第一个版本实际上具有与 macroquad 几乎相同的 API，我基本上复制粘贴了函数定义，并在 wgpu 上实现了大部分功能。随着时间的推移，我意识到我想要一些额外的东西，特别是内置的 z-index，这样我的游戏代码就不必担心绘制顺序。

如果您喜欢 Comfy 的想法，但它对您的用例来说还不够稳定，我非常推荐您尝试一下 macroquad。虽然它并不完美，但它帮助我制作了许多小型游戏，最重要的是，我在制作它们的过程中感到很开心。

comfy 和 macroquad 之间的差异

Macroquad 是 Comfy 的最大灵感来源，因此有很多相似之处，但也有许多差异。

坐标系

• Macroquad 的坐标系是 [0, 0] 在左上角，y 向下，以像素为单位。
• Comfy 的坐标系是 [0, 0] 在中心，y 向上，以世界单位为单位。默认相机缩放设置为 30，这意味着您可以看到大约 30 个世界单位。在一个 16x16 角色精灵的像素艺术游戏中，您最好将相机的缩放设置为每个精灵为 1 个世界单位。

内置 Z-index。在 macroquad 中，绘制调用按照您调用的顺序进行。在 Comfy 中，几乎所有调用（除文本和 UI 外）都接受一个 z_index: i32。这意味着您不需要自己排序调用，Comfy 会为您完成，同时尽可能地批处理绘制调用。

HDR 渲染纹理：Macroquad 针对 GLES2/3 以支持尽可能多的平台，因此它不能支持 RGBA16F 纹理。Comfy 针对桌面和 WASM 通过 WebGL 2，两者都允许 f16 纹理，因此所有渲染都以 HDR 和色调映射的方式完成。这使得我们的辉光实现可以基于 HDR 颜色工作，并大大简化了与灯光的交互，因为光照强度可以远远超过 1。

包含电池：Comfy包含许多宏quad没有的额外功能，例如egui本身就是Comfy的一部分，并且可能将保持这种方式，直到出现更好的替代品。宏quad和miniquad提供小型灵活的构建块，而Comfy旨在成为制作游戏的一种全面且相对有偏见的途径。

存在许多更微妙的不同之处，但从原则上讲，您可以将Comfy视为“包含更多电池的宏quad，基于wgpu，具有较少的跨平台功能”。请注意，由于Comfy基于wgpu而不是OpenGL，我们无法与GL进行相同的即时模式交互。这使得某些事情变得更为困难，例如渲染目标、更改着色器统一变量等。

Comfy打算支持所有这些功能，但这将需要更多开发。许多引擎（例如bevy和rend3）最终使用渲染图来向用户公开渲染逻辑。虽然这些非常灵活且提供高性能，但它们的API并非简单。

鉴于我们的意图不是支持AAA图形，目标应该是找到某种形式的中间地带，在那里我们可以在API简单性、表达性和乐趣方面达到类似于宏quad的水平，同时利用wgpu提供的一切功能。

Comfy的最终设计目标是，其大部分API应该仅通过查看类型签名即可理解，无需深入研究文档，也不需要过度使用“陷阱”。

rend3

除了挖掘其代码外，我对rend3的经验不多，但作为一个3D渲染器，它与Comfy填补了非常不同的市场。如果您正在构建3D游戏且不想进行PBR渲染，rend3可能是您想要考虑的东西。

Fyrox

Fyrox似乎正在与Unity、Godot和Unreal正面竞争，目前是唯一一个功能齐全的Rust游戏引擎，特别之处在于还包括完整的3D场景编辑器。其3D演示特别令人印象深刻，如果您正在寻找一个功能齐全的3D引擎，那么这绝对是一个值得考虑的选项。

话虽如此，Comfy毫不犹豫地专注于简单的游戏，因此与Fyrox填补了非常不同的市场。

bevy

Bevy是“大型Rust游戏引擎”竞争者之一。在2D功能方面，Bevy在社区规模和整体crate支持及模块化方面确实占优，但这是Comfy甚至没有尝试竞争的领域。Comfy旨在具有偏见、简单和实用，而Bevy的目标是模块化、可扩展，并在其全面的全局ECS之上构建。

由于其模块化，Bevy通过社区asset crates提供许多更多功能，极大地扩展了其功能，但也拥有一个相当分散和不稳定的生态系统。

Comfy的目标在许多方面正好相反。目标是提供简单、稳定和实用的基础。Comfy不是一个用于实验Rust的类型系统、ECS或其他抽象的平台。它是一个用于制作小型游戏的工作套件。

在Comfy中，您会发现的是那些可以立即使用、理解并且从第一天起就能工作的功能。如果一个功能在现实游戏中没有使用，它就不会出现在引擎源代码中。

godot-rust

如果目标是“真正制作游戏”，特别是3D游戏，那么godot-rust可能是最佳选择。没有Rust引擎可以与Godot提供的东西相媲美。在用godot-rust制作BITGUN的过程中，我们可以说它非常成熟、稳定且维护良好。

然而，最大的好处（Godot）也是我们最大的缺点。我们发现基于代码的框架使用起来更有趣。许多人认为GDScript是Godot中存在问题的一部分，但当我们正在开发BITGUN时，它实际上帮了我们很多忙，因为有许多事情“只需要几行代码”并且使用Rust并没有真正受益。

特别是如果你正在考虑制作3D游戏，godot-rust可能是帮助你顺利发布的最佳选项。

ggez

ggez 是那些已经存在了一段时间的库之一，但我从未真正有机会使用它。它似乎有一些历史问题，与失去维护者有关，这就是为什么我从未使用过它，因为我切换Rust框架/引擎的两次，它都处于维护状态。尽管在当前版本中，它确实升级到了基于wgpu的后端，但我无法评论其质量。我想象它可能是 macroquad 的一个很好的替代品。

Rust 中还有许多其他框架/引擎，但我还没有机会以任何有意义的方式与之互动，因此它们没有包含在这个比较中。

路线图

以下目标没有特定的顺序，但应该很快就会实现。Comfy 不是一个只能在两年后出现的空想项目。这里只列出了需要最多几周工作的特性。

• 改进光照。目前我们确实有2D光照，但它们很基本，在一些场景中很丑，并且不够灵活。
• 可配置的泛光。目前泛光被硬编码以简化一些事情，并且始终启用。我们不希望因为解决这个问题而推迟发布，因为这确实会使游戏看起来更好，但它是在v0.1发布后需要修复的第一件事之一。
• 可配置的后期处理。
• 自定义着色器和材质。
• 渲染目标。
• 游戏手柄和触摸板支持。
• 抗锯齿。
• 具有柔化阴影的2D阴影投射器。
• 无需 include_dir 的资产打包。目前Comfy依赖于其内置的 include_dir 使用（一个小分支，有少量额外功能），或者用户手动处理资产加载。有其他许多打包资产的方法，支持这些方法会很有趣，但我们目前没有这样做，因为对于合理（<1GB）大小的资产，include_dir 已经足够好了。
• 无 egui 的文本渲染。目前所有文本（使用 draw_text 和朋友绘制）都是使用 egui 的画家在单独的一层上渲染的。这给我们带来了许多文本渲染功能，但也带来了一些限制。目标是仅使用 wgpu 实现文本渲染。我们已经尝试了多种不同的方法（例如 glyphon），但最终发现没有一种方法足以替换我们在 egui 中的东西，并且由于没有游戏因更灵活的渲染而受阻，这仍然是一个相对较低的优先级问题。
• 整体引擎/渲染器代码清理。Comfy 中的代码并不美丽，因为它在构建多个游戏的过程中有机发展。有一些特性可以更好地公开，还有一些我们游戏需要的东西的残留。提供的示例应该作为确保 Comfy 足够灵活的基础，但这是一个持续的努力来改进代码库。话虽如此，你几乎在 Comfy 中找到的任何东西都应该在一定程度上工作。
• 减少重借和 RefCell。目前我们几乎用 RefCell 来处理几乎所有事情。虽然这有助于一些地方，但还有许多地方它是不必要的，我们还在每帧多次过多地借和重借。目前我们没有注意到这影响性能，但这应该被清理。还有一些东西不必要地使用了 Mutex。

虽然Comfy已经可以使用，但代码库远非整洁。随着我们制作游戏，引擎也在快速发展，许多部分都可以并且将会得到改进。Comfy在还没有达到100%完美之前就已经发布，因为即使在当前状态下，它也可以很好地用来制作2D游戏。

你可能遇到一些奇怪的情况，一些内部结构也计划进行重做，但所有包含在示例中的内容应该都能100%工作。我们已经在内部使用了Comfy超过6个月，其代码库的大部分已经从我们之前的基于OpenGL的引擎迁移过来。这并不意味着引擎已经成熟，但我们确实有玩家玩过我们用Comfy制作的游戏。

贡献

Comfy还处于生命周期的早期阶段。虽然它已经被用来制作游戏，但到目前为止，只有少数人使用过它或看过源代码。最好的贡献方式是使用Comfy并报告你发现的任何问题。

代码库根本就不整洁。Comfy的目标不是成为最漂亮的代码库。许多事情可能不是最优的，对于其中一些，开放讨论是非常有意义的。但只是重构代码或移动某些东西或进行某种重新组织的pull request可能会被拒绝，除非之前有过讨论。

如果你发现任何不符合预期的情况，请务必打开一个问题。Comfy旨在成为那些想要制作游戏的用户的富有成效和人体工程学的伴侣。

如果某些功能不够人体工程学，或者你有一个想法，如何在不牺牲太多的情况下使其更符合人体工程学，请打开一个问题。

如果你真的只想提交一个pull request来贡献某些东西而没有先进行讨论，最好的地方是示例。简单和高级的示例，以及小型示例游戏都受欢迎。

由于发展速度很快，Comfy目前不追求大量的文档覆盖。示例比文档更受欢迎，因为当API更改时，它们更容易修复。大多数事情应该都是不言自明的。

如果你想聊任何关于Comfy的事情，请加入我们的Discord服务器。

许可证

Comfy是免费和开源的，并且根据MIT和Apache 2.0许可证双授权。

使用Comfy的游戏

Comfy被LogLog Games使用，其中一款游戏已经发布在Steam上，名为Unrelaxing Quacks - 快速的幸存者！

我们还使用Comfy在一些小型游戏中，例如我们的1-bit jam参赛作品，我们在其中尝试了CPU纹理和2D光线追踪。

Comfy通过Jetbrains的开放源代码倡议和为Comfy开发提供许可证得到了Jetbrains的支持。