已经有一段时间了。但我觉得在尝试构建类似的东西时，让我最头疼的是处理不同元素之间的交互。声明哪些对象会受到“攻击”，或者可以被“玩家互动”，或者“被玩家影响但不被NPC影响”。实际上，这归结为正确的继承。但我发现自己陷入了很深的混乱，重新开始会更好。然后确定是对象本身还是“目标管理器”在每个周期中执行计算。等等，这很混乱。我最终创建了NPC、物品、攻击类，以及每个类对应的NPC管理器、物品管理器和攻击管理器来计算它们的所有交互和状态。这就是为什么你的项目看起来很有趣，因为它似乎处理了行为和“后台”的大量工作。
源讨论Hacker News问答：你正在做什么？（2025年11月）原帖 1,370 条评论 · 导入时统计哦，谢谢你！ 我想听听你之前在项目中试图做什么的更多细节。它更类似于声明式编码部分，自动多人游戏部分，还是其他什么？我之所以这样做，是为了探索游戏应该如何制作的设计空间，我很想听听其他人认为值得解决的问题、问题、烦扰、‘bugbears’等等。
完整原文把你的经验，加入这段讨论。
哦，是的，处理交互和依赖关系以及什么会影响什么。在我之前开发Easel之前，我做了很多React开发（即前端网络框架），并深受它如何与变化挂钩的启发。当你给它一个小程序，它会说明它依赖什么，然后当依赖项变化时，它会完全重新执行整个小程序。所以在Easel中，当你输入`with Health { ... }`时，它会创建一个行为，每次Health变化时都会重新执行。但是，如果它只是重新运行这个行为，那么每次重新执行时都会添加一个新的精灵（例如），直到你有几百个精灵。所以另一个技巧是Easel编译器会为像精灵这样的东西分配一个隐式的ID，这样在第二次运行时它会替换而不是添加。这是编程语言内置的功能，你通常看不到它（大部分时间）。实际上，这花了我两年时间…
完整原文我最近刚刚经历了这个。我也在为孩子们开发一个用来制作游戏的工具。但比Easel更具有主观性。让我觉得有趣的是，Easel看起来是声明式的，但实际上是命令式的。 我实际上选择了100%的声明式方法。基本上，你定义效果，这些效果会在某些交互发生时执行。有一个全面的目标系统。但最好的部分是，这一切都是类型安全的，使用TypeScript，声明式结构被强制执行。这意味着即使当你链式调用效果时，嵌套的效果也能访问（包括自动补全）父效果的目标等。虽然这为使用者提供了非常棒的体验，但构建这个系统确实并不简单。 https://breaka.club/blog/why-were-building-clubs-for-kids
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。