Murder es un motor de juego ECS de pixel art en C#

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo motor de juego 2D de pixel art de código abierto en C#, construido en torno a una arquitectura Entity Component System (ECS), está recibiendo elogios por su diseño limpio, su sólido flujo de trabajo en el editor y el uso de tecnologías familiares como MonoGame. Los comentaristas comparan su enfoque ECS y el comportamiento de la recolección de basura en C# con Unity y Godot, y debaten si ECS es excesivo para títulos pequeños de pixel art o una forma útil de estructurar juegos complejos con muchas entidades. El nombre provocador del proyecto, “Murder”, también suscita debate sobre su facilidad de búsqueda, su posible mal gusto y si una marca con aire provocador es una desventaja o algo irrelevante para herramientas de desarrollo.

Impresiones generales

  • Muchos comentaristas elogian el aspecto del motor, el estilo del editor y su enfoque en el pixel art.
  • Los tutoriales de pixel art enlazados por uno de los colaboradores son alabados como algunos de los mejores disponibles, especialmente por ser concisos y estar claramente escritos.
  • Se comparten varios juegos de jam hechos con el motor y se describen como impresionantes para tiempos de desarrollo tan cortos.

Nombre del motor y marca

  • El debate significativo se centra en el nombre “Murder”.
  • Preocupaciones:
    • Mal SEO debido a la palabra genérica y muy usada.
    • Percibido como de mal gusto o innecesariamente provocador, especialmente dado el contexto de la violencia real.
    • Temor a que plataformas (p. ej., YouTube/Google) puedan rebajar su clasificación.
  • Contraargumentos:
    • Buscar “murder engine” ya muestra el proyecto.
    • Otros motores y herramientas ampliamente usados también tienen nombres genéricos o “raros”.
    • Algunos consideran las objeciones exageradas o una actitud de “recatamiento” y aprecian la temática de “murder of crows”.
  • El gusto se presenta como subjetivo; no se alcanza un consenso.

Arquitectura e implementación ECS

  • Varias personas confunden inicialmente “ECS” con el chipset de Amiga; otras aclaran que significa “Entity Component System”, una arquitectura de juego orientada a datos.
  • Se comenta el ECS interno (“Bang”):
    • Los componentes son structs simples; los sistemas son clases activadas por interfaces implementadas.
    • Los filtros definen qué entidades procesa un sistema.
    • Los generadores de código crean métodos auxiliares (p. ej., TryGetVelocity), probablemente por rendimiento/ergonomía.
    • Las entidades almacenan componentes en diccionarios; no es un ECS de tipo archetype/SoA, priorizando la simplicidad sobre la velocidad máxima.
    • Siguen abiertas preguntas sobre el orden de los sistemas, múltiples consultas en un mismo sistema y el comportamiento cuando se añaden o eliminan componentes a mitad de tick.

¿Es ECS excesivo para juegos 2D de pixel art?

  • Una opinión: la mayoría de los juegos de pixel art son pequeños y no necesitan ECS; OOP podría ser más simple.
  • Respuestas:
    • ECS puede ayudar a manejar grandes cantidades de entidades (p. ej., juegos tipo “bullet hell” o de automatización).
    • Mejores patrones de acceso a memoria pueden mejorar el rendimiento y la duración de la batería.
    • Algunos consideran ECS conceptualmente más limpio como “mutación controlada”, independiente del rendimiento.

C# y recolección de basura

  • Surgen preocupaciones sobre pausas de GC en el desarrollo de juegos con C#.
  • Varias respuestas sostienen:
    • Los GC modernos de .NET funcionan bien si se controlan las asignaciones (pooling de objetos, mínimas asignaciones por frame).
    • Los problemas son especialmente notorios en Unity porque usa un GC antiguo de Mono; otros motores basados en .NET funcionan mejor.
    • Las estrategias incluyen preasignación, pooling, desactivar ciertos modos de GC o llamar explícitamente a GC.Collect() en momentos controlados.
  • Hay discusión comparando GC por tracing con conteo de referencias (p. ej., Swift, GDScript de Godot), señalando compensaciones en determinismo, sobrecarga y adopción en plataformas.

Comparación con Unity, Godot y MonoGame

  • El ECS de Unity se describe como complejo por convivir con GameObjects y un flujo de trabajo separado de “authoring”; la depuración visual es limitada.
  • El ECS de Murder se describe como “solo C#” con menos capas: los componentes y sistemas se añaden directamente, y las entidades del editor son utilizables de inmediato.
  • MonoGame se presenta como una reimplementación madura y estable de XNA, usada en varios juegos indie conocidos, situada entre librerías de bajo nivel y motores completos.
  • Se menciona Godot por su uso de conteo de referencias y como alternativa cuya integración con .NET está mejorando.

Experiencia de usuario y preguntas abiertas

  • Un desarrollador que probó tanto Unity ECS como Murder informa que el ECS de Murder es mucho más fácil de aprender y usar, especialmente en el editor.
  • C# se describe ampliamente como agradable y legible.
  • Aparece una pregunta sobre usar F# con el motor, pero no se responde en el hilo, así que el soporte entre lenguajes sigue sin aclararse.