tuig

tuig 是一个专注于系统化文本模式游戏的引擎。

你应该查看仓库的 README 文件。你看到的就是在 crates.io 上看到的那个。

lib.rs:

tuig 是一个专注于系统化文本模式游戏的引擎。

如果你想直接通过示例开始，请查看 docs::walkthrough。

功能选择

在您实际上运行游戏之前，您需要使用 Cargo 特性选择一些后端功能。

运行器实际将消息传递给每个 Agent 和 Game，并协调与所有这些的 IO 系统。选择以下之一

• run_rayon：一个非常合理的默认选项。使用 rayon 将代理分布在多个线程上，它在有效地使用所有可用核心方面非常出色。
• run_single：只有在某些原因（例如，小型单元测试或 no_std）使您不希望使用 rayon 时才有用。

IO 系统——tuig-iosys::backends 之一——将处理我们的平台输入和输出。所有 tuig-iosys 后端都可用，但特性具有额外的 io_ 前缀。因此，您有

• io_nop：非常适合集成测试，在您实际上不关心输入或输出，但希望有一个其他方面完整的 tuig 时。
• io_cli_crossterm：使用 crossterm 将字符网格渲染到真实终端。
• io_gui_softbuffer：使用 CPU 渲染和 softbuffer 将字符网格渲染到 winit 窗口。它具有非常广泛的兼容性，因为您实际上不需要任何 3D 硬件才能使其工作。

您必须选择 exactly one 运动员，但您可以选择多个 IO 系统。 Runner::load_run 将尝试根据您已开启的系统智能选择 "最好的它可以做到的"，但如果您有合理的不同意见，或者如果您想使用第三方后端，您可以加载您首选的系统并使用 Runner::run 代替。

架构

tuig 是围绕共享的消息总线构建的。游戏中发生的所有事情都由一个单一的类型 M: [Message] 来表示。您还将拥有各种 Agent<M>，它们执行所有的实际模拟和消息处理。玩家实际上与之交互的是 Game<M>，它处理用户输入并渲染输出，并通过产生消息与代理进行通信。点击这些链接获取每个特定特质的更多详细信息。

Agent 和 Game（巧合的是我的新 ska 乐队名字）可以通过 Replies 注入新的代理或消息，这是对游戏内部大多数事物的通用处理方式。一个 Agent 可以通过返回不同的 ControlFlow 来让自己进入睡眠状态——包括永远——这有助于通过减少需要考虑的代理数量来提高性能，但不应依赖于任何太严肃的事情。 Game 也有类似的选项在 Response 中，尽管它们将不断被调用，因此它们的响应主要是重新渲染文本或完全退出游戏。