Murder is a pixel art ECS game engine in C#

Overall impressions

• Many commenters praise the engine’s look, editor styling, and pixel art focus.
• Linked pixel art tutorials by one of the contributors are lauded as some of the best available, especially for being concise and clearly written.
• Several jam games made with the engine are shared and described as impressive for short development times.

Engine name and branding

• Significant debate centers on the name “Murder.”
• Concerns:
  • Poor SEO due to the generic, heavily used word.
  • Perceived tastelessness or unnecessary edginess, especially given real-world violence.
  • Fear that platforms (e.g., YouTube/Google) might down-rank content.
• Counterpoints:
  • Searching for “murder engine” already surfaces the project.
  • Other widely used engines and tools also have generic or “weird” names.
  • Some consider objections overblown or “pearl-clutching” and appreciate the “murder of crows” theme.
• Taste is framed as subjective; no consensus is reached.

ECS architecture and implementation

• Multiple people initially confuse “ECS” with Amiga’s chipset; others clarify it means “Entity Component System,” a data-oriented game architecture.
• The internal ECS (“Bang”) is discussed:
  • Components are simple structs; systems are classes triggered by implemented interfaces.
  • Filters define which entities a system processes.
  • Source generators create helper methods (e.g., TryGetVelocity), likely for performance/ergonomics.
  • Entities store components in dictionaries; this is not an archetype/SoA ECS, favoring simplicity over maximum speed.
  • Questions remain about system ordering, multiple queries in one system, and behavior when components are added/removed mid-tick.

Is ECS overkill for 2D pixel games?

• One view: most pixel-art games are small and don’t need ECS; OOP might be simpler.
• Replies:
  • ECS can help manage large numbers of entities (e.g., “bullet hell” or automation-style games).
  • Better memory access patterns can improve performance and battery life.
  • Some find ECS conceptually cleaner as “controlled mutation,” independent of performance.

C# and garbage collection

• Concerns about GC pauses in C# game development are raised.
• Several replies argue:
  • Modern .NET GCs perform well if allocations are controlled (object pooling, minimal per-frame allocations).
  • Problems are especially pronounced in Unity because it uses an old Mono GC; other .NET-based engines fare better.
  • Strategies include pre-allocation, pooling, disabling certain GC modes, or explicitly calling GC.Collect() at controlled times.
• There is discussion comparing tracing GC with reference counting (e.g., Swift, Godot’s GDScript), noting trade-offs in determinism, overhead, and platform adoption.

Comparison with Unity, Godot, and MonoGame

• Unity’s ECS is described as complex due to coexistence with GameObjects and a separate “authoring” workflow; visual debugging is limited.
• Murder’s ECS is described as “just C#” with fewer layers: components and systems are added directly, and editor entities are immediately usable.
• MonoGame is introduced as a mature, stable reimplementation of XNA, used in several well-known indie games, sitting between low-level libraries and full engines.
• Godot is mentioned regarding its use of reference counting and as an alternative where .NET integration is improving.

User experience and open questions

• A developer who tried both Unity ECS and Murder reports Murder’s ECS as much easier to learn and use, especially in the editor.
• C# is widely described as pleasant and readable.
• A question about using F# with the engine appears but is not answered in the thread, so cross-language support remains unclear.