目前的进度进行到了第35个道具。

现在的一点想法，随着语言的搭建我逐渐发现我陷入了一个两难的情况，我既想要丰富多样的道具效果，又想要一个可以完整表述道具效果又不复杂的语言，越是独特的道具就会带来越复杂的语言结构和词汇，越是能完整的表述道具效果语言下的道具越是类似，继续进行下去也许可以找到这两端的一个平衡点，但这不是我想做的。然后我翻了翻最开始搭建这个系统时写的想法，我发觉自己有些钻牛角尖了，这个系统本身的意义在于引发玩家对道具效果的思考和指引，而我有些对搭建完整表述道具效果的语言这件事情有些偏执了，所以我决定将这种束缚解除，现在允许这语言搭建的谜题有着缺失的信息，玩家在图鉴解谜的时候只需要完成大致的效果表述就会显示完整的道具信息。

休息一天。

做了个表格分类并列举了目前所有的词，目前表格中有136个词。

以撒一大特色就是各种道具间靠着大量硬编码实现的、总数极其逆天的兼容特效。不知道肥哥对于这一点有没有什么想法呢

>>No.67574892
目前没有什么特殊的想法，如果有机会做会参考以撒的方式。然后就是我觉得以撒是不会用硬编码的方式实现这种系统的，越是这种灵活又庞大的需求就越是需要搭建可靠的系统，我其实已经在之前尝试过整个发射系统的搭建了（可以看2025.9.4附近的日志），只是目前的开发还没有到具体的实现多种攻击方式的时候，目前我还在想办法在今年年底之前做出一个原型。如果是想聊设计方面的话，我认为肥哥应该是想说不那么程式生成有手工感的攻击方式，我认为好的程式生成不是完全依靠复杂的系统和精确的数值或是随机性，这样只会把游戏体验投入未知的黑箱中，我认为好的程式生成是要通过结合手动设计牢牢的把握游戏体验。

因为出题方式和词语分类的修改，从头改了一遍道具的词条，目前有40个道具词条，151个词。

目前有60个道具词条，157个词。

完成全部90个道具词条，164个词。

搭建了词在程序的实现结构，添加了大部分词的数据实现。

休息一天。

实现了词类型在面板中的的层级分类选择。
实现了词数据文件的自动批量创建和自动设置子类列表。

因为unity序列号的问题又修改了符号类型识别方式，现在使用字符类型，之前用的多个层级的静态类只在代码中使用了。
完成了选词面板功能。
初步完成道具选词UI。

完成道具选词UI。
完成道具选词流程。

添加了道具列表导入和输入符号功能。

学习了EasySave插件并添加了数据保存系统和保存接口，现在玩家可以自定义符号的名称了。

休息一天。

完成了解谜数据的保存功能。
报错排查了半天，最后发现是需要保存的变量被打上了不可序列化给自己气笑了。

正在添加道具效果谜题数据，目前进行到了第50个。