nitric

通用数据处理库。

状态说明：高度实验性，未完成，正在进行中，不推荐使用

该库旨在作为 Specs 的后继者，Specs 是一个并行 ECS 库。然而，nitric 旨在比 Specs 更通用、更可组合。实际上，一旦这个库完成，Specs 可以作为 nitric 的前端实现。

动机

Specs 有许多问题，大问题和小问题都有。这个库在没有太多计划的情况下变得很大，现在这种情况将会继续，使其难以维护。

哲学

nitric 将是一个处理数据的集合库。它所有的库都遵循以下哲学：

• 只解决一个单一问题，以合理可组合的方式
• 公开一个通用、可组合和健壮的 API（也请参阅API 设计文档）
  • API 应设计为不产生任何错误情况，或者返回只包含可能错误条件的 Result
  • 不假设 API 如何使用（-> 可组合性）
  • 在默认情况下，通过 *-internals 库公开内部信息，以提供稳定性，并可选择加入更多不稳定的设施
• 尽可能降低使用 nitric 的摩擦
  • 目标是让 nitric 在项目的某个地方以低廉且容易的方式解决特定问题
  • nitric 的目的是与其他数据结构 / ECS / CGS 库兼容，例如 Specs、froggy 等，而不是与它们竞争

将 nitric 作为 ECS 使用

这将如何允许您使用 nitric 而不是 Specs？以下是 ECS 的初步设计

• nitric-entity：提供实体分配器、存储和实体与组件之间的映射

这已经足够有一个 ECS。系统可以是接受存储引用和最终分配器的函数。事实上，这是推荐库公开其 API 的方式；库不应假设代码如何执行。例如

(伪代码)

pub fn process_local_transforms(
    local: &Storage<LocalTransform>,
    global: &mut Storage<GlobalTransform>,
    parents: Storage<Parent>)
{
    // compute global transforms    
}

如果这些组件存储来自动态类型的字符串映射HashMap，那就没问题。如果它们存储在一个struct中 - 也行。系统的运行方式也不重要。

现在，Specs用户肯定还会错过其他一些东西，所以下一个crate将会是...

• nitric-world

正如你可能猜到的，这提供了一个可以存储任意组件存储的映射。与Specs相比，我还计划通过允许额外的键（例如，一个字符串）来支持同一类型的多个值。

• nitric-graph

这将是对shred的Dispatcher的重构版本，允许并行化数据处理（系统的执行）。一个“系统”将只是一个FnMut(T) -> R，这意味着如何获取数据由用户决定（nitric将为此提供解决方案，但它不会强迫你使用任何特定的解决方案）。

Vision

nitric的愿景是提供一组crate，这些crate会随着标准方式解决数据处理问题的演变而演变。Specs已经有了非常有趣的使用案例，包括将其用于编译器和执行更大型的模拟，这些都是在Specs原始范围之外（ECS用于游戏开发）。这就是我打算使nitric适合的地方。因此，以下是一些关于nitric未来可能用到的例子：

• 游戏开发
• 游戏物理
• 模拟
• 编译器
• 数据验证
• 图形用户界面

结构

主crate nitric将简单地作为一个顶层crate，用于重新导出所有nitric-* crate。然而，由于一切都是可选的，nitric通过Cargo功能进行控制，仅导出你启用了标志的crate。

当前crate

• nitric-lock - 具有死锁预防和锁排序的锁

贡献

nitric只能通过活跃的贡献而存在，任何帮助都非常受欢迎！

请注意，在其当前状态下，该项目可能对贡献不是非常友好。如果你仍然有兴趣帮忙，请与我联系（@torkleyy），以确保没有重复的工作。

许可证

除非另有声明，否则所有nitric项目都是Apache-2.0 / MIT的双许可。你可以自由选择其中之一。

对项目的每项贡献都被假设是根据这些条款许可的。