Minecraft 文本组件颜色和点击指南
9 分钟阅读
Minecraft 文本组件出现在比tellraw 更多的地方。相同的编写决策会影响标题、操作栏、物品名称、lore、书籍、bossbars、团队和显示实体。 NBTForge 使可视文本编辑接近命令Output，因此可读消息不会成为大量引用的 JSON 琐事。
指南结果
用于播放器消息、项目工具提示、书籍、标题和 bossbar 的可读文本组件工作流程。
推荐路径
- 在添加颜色或点击行为之前，用简单的语言编写消息。
- 使用颜色来区分含义，而不是每个单词。
- 保持物品名称短于 lore 行，并保持 lore 行可扫描。
- 添加仅当命令表面支持时悬停和单击行为。
- 每次编辑文本后预览Output，因为嵌套的 JSON 可能会快速更改。
色彩与装饰规则
使用一种主颜色表示消息，使用一种强调色表示状态、危险、奖励或操作。太多的颜色会使命令Output更难以阅读，玩家文本也更难以解析。
粗体、斜体、下划线和模糊样式应该是有意的。对于地图 UI，重点应该帮助玩家理解发生了什么变化。
- 为危险或失败保留红色或深红色。
- 使用金色或黄色作为奖励和目标。
- 使用灰色作为辅助上下文。
- 避免在长正文上进行装饰。
单击和悬停行为
单击事件对于命令、链接、建议和导航提示很有用，但如果可见文本没有描述操作，它们可能会让玩家感到惊讶。将操作放在文本中，而不仅仅是悬停工具提示中。
悬停文本应添加上下文。它不应该包含唯一重要的指令，因为有些玩家不会悬停每条消息。
跨表面重复使用文本
相同的任务标题可以成为标题命令、tellraw 行、项目 lore 提示和书面书籍条目。在这些表面上保持措辞一致，以便玩家识别目标。
当同一消息出现在多个命令系列中时，请使用共享命名约定将每个命令保存到 Project。
运送Copy 的工件
使用本指南来生成玩家或地图制作者将实际运行的工件：Copy 的命令、订购的 Project 包或datapack资源。最终审查应该发生在 Copy 的Output上，而不仅仅是可编辑的构建器状态。
当工作流对版本敏感时，请在命令旁边标记目标版本。当它使用选择器、记分板、bossbars、标签、loot table或项目顺序时，请在发布设置之前在干净的世界中测试这些依赖项。
- 来自 Output 的 Copy 用于一个命令，来自 Project 的订购包。
- 将 Java、Bedrock 和快照变体分开。
- 首先用无害的Output测试破坏性的选择器。
- 当指南成为规范工作流程时更新相关预设。
相关指南与预设
常见问题
每个文本表面都可以使用点击事件吗？
不可以。某些表面比其他表面支持更丰富的 JSON 行为。在相关 NBTForge 模块中构建文本并在假设功能可用之前检查生成的 Output。
为什么项目 lore 看起来与聊天文本不同？
Item 工具提示具有不同的空间、行长度和可读性限制。传说通常应该比聊天或书籍文本更短、更结构化。
本指南什么时候应该成为 Project 包？
当工作流需要多个命令、有设置和清理顺序或测试后必须再次编辑时，请使用 Project。一次性命令可以保留在 Output 中。