Murder 是一个用 C# 编写的像素艺术 ECS 游戏引擎

整体印象

• 许多评论者称赞这款引擎的外观、编辑器风格以及对像素艺术的专注。
• 其中一位贡献者链接的像素艺术教程也被赞为现有资源中最好的之一，尤其因为内容简洁、写得清楚。
• 一些使用这款引擎制作的 jam 游戏也被分享出来，并因在很短开发时间内做得很出色而受到称赞。

引擎名称与品牌

• 讨论的很大一部分集中在 “Murder” 这个名字上。
• 关注点包括：
  • 由于这个词过于通用且使用频率极高，SEO 表现可能很差。
  • 这个名字给人一种品味欠佳或不必要的“酷炫/危险”感，尤其是在现实世界暴力背景下。
  • 担心平台（例如 YouTube/Google）可能会降低相关内容的排名。
• 反方观点：
  • 搜索 “murder engine” 已经能直接找到这个项目。
  • 许多广泛使用的引擎和工具也都有通用或“奇怪”的名字。
  • 有些人认为这些反对意见有些过度，甚至是“珍珠项链式惊慌”，并且很喜欢“murder of crows”的主题。
• 品味被视为主观问题；最终没有形成共识。

ECS 架构与实现

• 一开始有好几个人把 “ECS” 误解为 Amiga 的芯片组；后来有人澄清它指的是 “Entity Component System”，一种面向数据的游戏架构。
• 讨论了内部的 ECS（“Bang”）：
  • 组件是简单的 struct；系统是由已实现接口触发的类。
  • 过滤器定义某个系统处理哪些实体。
  • 源生成器会创建辅助方法（例如 TryGetVelocity），大概是为了性能和易用性。
  • 实体把组件存放在字典中；这不是 archetype/SoA 风格的 ECS，而是在简洁性上优先于极致速度。
  • 仍有一些问题没有完全厘清，例如系统顺序、一个系统里进行多个查询，以及在一个 tick 中间添加/移除组件时的行为。

ECS 对 2D 像素游戏是否过度设计？

• 一种观点认为：大多数像素艺术游戏都很小，不需要 ECS；OOP 可能更简单。
• 回应包括：
  • ECS 对管理大量实体会有帮助，例如“弹幕地狱”或自动化风格游戏。
  • 更好的内存访问模式可以提升性能并延长电池续航。
  • 也有人认为 ECS 在概念上更清晰，是一种“受控变更”，其价值不依赖性能。

C# 与垃圾回收

• 有人提出了 C# 游戏开发中 GC 暂停的问题。
• 多个回复认为：
  • 只要控制好分配，现代 .NET 的 GC 表现很好（对象池、尽量减少每帧分配）。
  • 这些问题在 Unity 中尤其明显，因为它使用的是较旧的 Mono GC；其他基于 .NET 的引擎表现更好。
  • 可采用的策略包括预分配、对象池、禁用某些 GC 模式，或者在受控时机显式调用 GC.Collect()。
• 讨论还比较了 tracing GC 与引用计数（例如 Swift、Godot 的 GDScript），并指出它们在确定性、开销和平台采用方面各有取舍。

与 Unity、Godot 和 MonoGame 的比较

• Unity 的 ECS 被描述为很复杂，因为它与 GameObject 共存，并且有一套单独的“authoring”工作流；可视化调试也比较有限。
• Murder 的 ECS 被描述为“就是 C#”，层次更少：组件和系统可以直接添加，编辑器中的实体可以立刻使用。
• MonoGame 被介绍为对 XNA 的成熟稳定重实现，被一些知名独立游戏采用，处于底层库和完整引擎之间。
• 也提到了 Godot，涉及其引用计数的使用方式，以及其 .NET 集成正在改进这一点。

用户体验与未解问题

• 一位同时尝试过 Unity ECS 和 Murder 的开发者表示，Murder 的 ECS 学起来和用起来容易得多，尤其是在编辑器中。
• C# 被普遍形容为令人愉快且易读。
• 线程中出现了一个关于能否使用 F# 的问题，但没有得到回答，因此跨语言支持仍不明确。