aldelaro5/Bug-Fables-Internal-Docs

# Bug-Fables-Internal-Docs 一个用于汇总 Bug Fables 内部工作机制文档的仓库。 本仓库包含了我多年来积累的所有文档，以及随着我对游戏了解深入将在此推送的新文档。建立这个仓库的目的是为了有一个集中的地方来查阅我的文档。这也防止了这些文件丢失的情况，并提供了一个不依赖 wiki 或 Discord 的信息来源。我计划在未来寻求更好的展示信息的方案，例如 GitHub Pages，但目前，我只是将原始信息以 Markdown 格式存放，随着我继续研究游戏内部机制，这些内容将得到完善。 信息不应来自 wiki 或 Discord 的原因在于，前者已被证明不够可靠，且难以查阅或编辑，而后者查找复杂且无法保证始终可用。关于内部机制的信息对于任何想要进行 Mod 制作的人来说都是至关重要的，对于我目前的项目也是如此，因此必须在一个所有人都能访问的中心位置提供这些信息。本仓库也有一个 [wiki](https://github.com/aldelaro5/Bug-Fables-Internal-Docs/wiki)，它将更侧重于重要的操作流程，例如提取资源、反编译和调试游戏。 随着更多信息的汇总和发现，本仓库将获得更新，以免随时间流逝。我接受 Pull Request 或 Issue（如果是错别字或信息不准确），但所有内容都需要提供一种让我验证信息的方式。 ## 仓库中允许的内容与禁止的内容 本仓库将仅包含描述游戏接口的信息。这主要包括： - 任何数据文件的文档（其格式以及每行或字段的作用） - 枚举值列表 - 字段名称或方法签名（不包含任何代码主体） - 关于游戏子系统或整体的高级文档。这意味着主要用英语句子描述某物如何工作，而不提供游戏中的任何代码。 这意味着它永远不会包含以下任何内容： - 视觉或音频资源 - 由提取器生成的 Unity 资源文件 - 数据文件或对话文件（即使是汇总格式） - 方法的代码主体 - 游戏中的任何二进制文件 这不仅仅是因为显而易见的法律原因（主要是代码部分），还因为它们在这里实际上并没有帮助。原因有很多： - 对于代码，在不理解游戏制作过程的正确背景下，可能会留下错误的印象。这是因为部分代码存在紧耦合或采用单体方法，这会导致开发问题并影响 Mod 制作。背景可以解释一切，但很容易被忽视，而且除非具有历史相关性（例如描述一个已知问题及其发生原因），否则在记录内部机制时并没有必要提及。避免共享代码可以避免这种认知问题。 - 对于数据文件，仅仅是因为没有意义：其格式并非为人类可读而设计，因为它们是由自动化工具生成的。本仓库的目标是允许外部工具或人工手动读取它们。至于为什么不提供它们的汇总版本，是因为它们可以说不属于文档仓库，后者应仅包含数据的规范，而不包含其实现。我宁愿将两者解耦，因为数据不会改变，但对它的认知可能会改变。 - 对于 Unity 资源，只是因为实际实例（主要是地图预制件）对本仓库来说并不那么重要。重要的是它们如何工作，这样人们才能选取一个实际实例并理解它在告诉游戏做什么。 - 对于其他任何东西，都不需要 + 我分享的游戏文件越少越好。

标签：Bug Fables, Markdown, RPG游戏, Ruby, URL提取, 反编译, 开源文档, 技术文档, 数据结构, 文件格式, 模组开发, 游戏内部机制, 游戏存档, 游戏逆向工程, 知识库, 网络安全研究, 调试, 资产提取, 防御加固