"Murder", un motor de juegos ECS de pixel art hecho en C#

• Murder Engine es un motor de juegos ECS para pixel art construido sobre FNA; todavía está en desarrollo, así que se esperan muchos cambios y posibles breaking changes
• Como ejemplos para empezar, se presentan los proyectos de game jam neocityexpress y hellomurder, que muestran el flujo de creación de mundos, entidades y componentes
• La estructura del proyecto separa game y game.editor, y en lugar de un editor.exe independiente adopta un enfoque donde el usuario controla directamente el editor dentro de su propio proyecto
• El entorno de desarrollo es compatible con Linux, MacOS, Windows y Steam Deck; lo único necesario es el SDK de .NET 8, y el juego soporta como destino Linux, MacOS y Windows
• Todavía no hay paquete NuGet, por lo que se recomienda referenciarlo desde .csproj usando un submódulo de git; por ahora no hay planes de soporte oficial para web ni móvil

---

Naturaleza y estado de Murder Engine

• Murder Engine es un motor de juegos ECS para pixel art basado en FNA
• Actualmente es un motor en desarrollo; aunque se intenta mantener estable la rama de lanzamiento, hay que asumir muchos cambios y partes aún no terminadas
• El README advierte “Proceed at your own risk” y deja explícita la posibilidad de breaking changes

Ejemplos iniciales y ruta de aprendizaje de ECS

• Para quienes prefieren ver ejemplos rápidos y entender el motor así, se recomienda empezar por estos proyectos
  • game jam project: proyecto de game jam donde se puede revisar la arquitectura de Murder
  • Hello World project: ejemplo que muestra cómo se crean mundos, entidades y componentes
• Para entender cómo se aplica ECS en Murder, se indica consultar la documentación de Bang
  • Bang es el framework ECS que utiliza Murder

Estructura del proyecto y enfoque del editor

• La estructura del proyecto Murder se divide en resources, src/game y src/game.editor
  • game incluye bin, packed y resources para el juego final
  • game.editor incluye bin y resources para el editor del juego
• No existe un editor.exe externo; solo existe el proyecto propio del usuario
• Esta estructura se eligió para permitir controlar directamente todo el proyecto, de forma similar al desarrollo de proyectos con MonoGame o FNA
• La razón de tener el editor como proyecto separado es evitar que el código del editor toque el código del juego y permitir que del lado del editor se pueda trabajar con total libertad

Compilación y manejo de dependencias

• Actualmente no existe un paquete NuGet para Murder
• La forma recomendada es incluir Murder como submódulo de git y referenciarlo desde .csproj
• Un ejemplo de referencia puede verse en HelloMurder.csproj

Requisitos y plataformas compatibles

• El entorno de desarrollo para ejecutar el editor es compatible con Linux, MacOS, Windows y Steam Deck
• El requisito necesario es tener instalado el SDK de .NET 8
• Las plataformas de destino del juego son Linux, MacOS y Windows
  • Linux incluye Steam Deck
• El soporte para consolas está actualmente en progreso
• Por ahora no hay planes de soporte oficial para web ni para móviles iOS y Android

Contribuciones y feedback

• El proyecto todavía está en una etapa muy temprana
• Se indica que quienes tengan propuestas o feedback pueden contactar al creador, y que hay interés en recibir uso real y comentarios

[GN⁺]

Opiniones de Hacker News

• Vi que tenía el nombre saint11 y me convencí de que iba a ser bueno. Sus tutoriales de pixel art están muy bien organizados: http://saint11.org/blog/pixel-art-tutorials/

  • Es la primera vez que lo veo, y con solo echarle un vistazo rápido me convencí de que es el mejor blog de todo internet
  • No sabía que era la misma persona. Había visto este tutorial antes, y la forma en que va desplegando el contenido era excelente
  • Creo que saint11 es la persona que hizo el arte del juego Celeste
  • Trabajó en Celeste y Towerfall, y ambos tienen pixel art excelente. Parece tener muchísimo talento

• Los motores de juego nuevos y los frameworks ECS son entretenidos de ver. Si miras Bang, la parte de ECS, hay ejemplos de componentes como CarComponent y sistemas como CarMoverSystem; los sistemas son clases, y la interfaz que implementan parece determinar cuándo se ejecutan
  Se parece un poco a DOTS, pero todavía no encontré dónde se agregan los sistemas al juego ni cómo se ordenan los sistemas del mismo tipo. También me da curiosidad cómo se vería un sistema que haga varias consultas distintas, como autos y obstáculos
  Bang parece usar un generador de código fuente. A diferencia de GetComponent, TryGetVelocity, RemoveFriction y SetVelocity parecen generarse en función de la existencia de los componentes Velocity y Friction, aunque no estoy seguro; quizá sea por una caché de IDs de componentes
  No está basado en arquetipos; cada entidad guarda un diccionario component id => component, y cada sistema lleva el registro de qué entidades coinciden con su filtro. No sé qué tan buen rendimiento tendrá, pero en muchos juegos la comodidad de desarrollo puede importar más que el rendimiento
  Los cambios también parecen aplicarse de inmediato. Entonces, si un sistema agrega o elimina componentes de una entidad y eso cambia si coincide o no con un filtro, me pregunto si que se procese en el mismo tick dependerá del ID de la entidad

  • También me da curiosidad el orden de ejecución de los sistemas. Tener que agregar manualmente cada sistema nuevo a una lista fija puede ser frustrante, pero al mismo tiempo los sistemas suelen depender implícitamente unos de otros, así que también es importante fijar el orden de ejecución en tiempo de compilación
    Mirando la documentación por encima no vi una forma de marcar explícitamente estas dependencias u órdenes, y me pregunto cómo lo maneja este motor

• La página de Itch y la descarga de un juego de jam hecho con este framework: https://saint11.itch.io/neo-city-express
  Es impresionante para un juego de jam de 72 horas. El arte y la escritura son buenos, y también tiene diversión mecánica de una forma inesperada

• Muy bueno. El editor es muy estilizado y me encanta. Siempre me gustó MonoGame porque tiene buen rendimiento y es multiplataforma, aunque nunca hice un juego grande con él; solo demos de vez en cuando

• Se ve bien. Me pregunto si en el desarrollo de juegos con C# hay problemas de pausas por GC

  • Me fue bastante bien con una gestión sencilla de objetos y llamando explícitamente a GC.Collect() en intervalos de pequeños múltiplos del retraso de simulación. El punto óptimo parece depender del contenido de la escena y del estilo de gameplay, es decir, de cómo cambian los objetos de la escena
    En escenas y gameplay estilo Q3A es muy sólido. Como casi no hay elementos de la escena que cambien en cada tick, las pausas de GC son mayormente despreciables
    En .NET 6+, en un motor DIY, las pausas de GC se midieron en alrededor de 1 a 5 ms cuando se invocaba rápidamente de forma estratégica y repetida. En la configuración del proyecto, desactivar el GC concurrente/servidor/en segundo plano y usar GC en primer plano + workstation produjo el menor jitter
    Las únicas opciones parecen ser administrar el 100% de la memoria manualmente o limpiar la basura con la mayor frecuencia posible. En .NET moderno es casi imposible desactivar por completo el GC sin magia negra como hacks de DLL de bajo nivel. Si puedes reiniciar el proceso entre eventos de trabajo o rondas del juego, Process.Exit() también es una técnica de GC válida en algunos ámbitos
  • Sí. Hay una buena charla de Miguel de Icaza sobre la historia de agregar C# a motores de juego, y sobre por qué le entusiasma usar Swift en Godot, argumentando que el conteo de referencias de Swift evita el problema de las pausas por GC
    https://youtu.be/tzt36EGKEZo?si=WNxwcTPGFbJABKez
  • Diría que el problema del GC existe casi solo en Unity. Otros motores de juego que usan .NET común, como Stride, funcionan sin problemas
  • Sí. Unity, por supuesto, y Unreal también tienen GC, así que hay que asignar al inicio y usar object pooling
  • Como en la mayoría de los otros lenguajes, C# también se puede escribir de forma que evite asignaciones

• Leyendo solo el enlace no me queda claro, pero me pregunto qué tan difícil sería hacer un juego en F# con el motor de juego Murder

• Usé un poco ECS en Unity, y el ECS de Murder me resultó mucho más fácil. Los desarrolladores hicieron un trabajo realmente bueno
  Hice un pequeño proyecto de juego arcade con Murder, y se puede jugar aquí: https://nopetrides.itch.io/bombs-away

  • ¿Podrías explicar con un poco más de detalle las diferencias?

• En la página de presentación de saint11 dice esto: “Murder Engine: motor de juego ECS en C# para pixel art 2D, hecho por Isa. Yo suelo ayudar en la parte de renderizado y física.”
  Isa: https://isadorasophia.com/projects/

• No tiene que ver con el motor de juego, pero me da gracia que alguien malintencionado pueda decir que “la gente de ese sitio web de hackers está discutiendo murder”
  Últimamente pienso mucho en cómo un adversario persistente podría usar material completamente inocuo como este

  • Suena un poco forzado, pero ha habido gente que se tomó artículos de The Onion literalmente
    Aun así, en un caso tan fácil de refutar, no sé si hay mucha diferencia entre decir “la gente discute murder” y una mentira descarada
  • Pensar así, pero al revés, es la única forma de consumir noticias de medios masivos. Hoy en día todo está sesgado y ridículo hasta un punto difícil de creer

• ¿Qué es ECS?

  • Supongo que Entity Component System. Es una arquitectura común en motores de juego
  • Es una arquitectura de alto rendimiento que está de moda. Unity está intentando popularizarla bastante últimamente