Die in C# entwickelte Pixel-Art-ECS-Game-Engine „Murder“

• Murder Engine ist eine auf FNA aufgebaute ECS-Game-Engine für Pixel Art, befindet sich derzeit in Entwicklung und es ist mit vielen Änderungen sowie möglichen Breaking Changes zu rechnen
• Als Einstiegsbeispiele werden das Game-Jam-Projekt neocityexpress und hellomurder genannt; sie zeigen den Ablauf zum Erstellen von World, Entity und Component
• Die Projektstruktur trennt game und game.editor und setzt statt einer separaten editor.exe darauf, den Editor direkt im eigenen Projekt des Nutzers zu steuern
• Die Entwicklungsumgebung unterstützt Linux, MacOS, Windows, Steam Deck; benötigt wird das .NET 8 SDK, und als Spielziele werden Linux, MacOS und Windows unterstützt
• Da es noch kein NuGet-Paket gibt, wird empfohlen, per Git-Submodule zu arbeiten und in der .csproj darauf zu verweisen; eine offizielle Unterstützung für Web oder Mobile ist derzeit nicht geplant

---

Charakter und Status der Murder Engine

• Murder Engine ist eine FNA-basierte ECS-Game-Engine für Pixel Art
• Die Engine befindet sich derzeit in Entwicklung; der Release-Branch soll zwar stabil gehalten werden, dennoch muss mit vielen Änderungen und noch nicht fertiggestellten Teilen gerechnet werden
• Das README warnt mit „Proceed at your own risk“ und weist ausdrücklich auf mögliche Breaking Changes hin

Einstiegsbeispiele und Lernpfad für ECS

• Für Nutzer, die sich schnell über Beispiele einarbeiten möchten, wird empfohlen, mit den folgenden Projekten zu beginnen
  • game jam project: Ein Game-Jam-Projekt, an dem sich die Murder-Architektur nachvollziehen lässt
  • Hello World project: Ein Beispiel, das zeigt, wie World, Entity und Component erstellt werden
• Wie ECS in Murder angewendet wird, soll laut Hinweis in der Bang-Dokumentation nachgelesen werden
  • Bang ist das von Murder verwendete ECS-Framework

Projektstruktur und Editor-Ansatz

• Die Projektstruktur von Murder ist in resources, src/game und src/game.editor unterteilt
  • game enthält bin, packed und resources für das fertige Spiel
  • game.editor enthält bin und resources für den Game-Editor
• Es gibt keine externe editor.exe, sondern nur das eigene Projekt des Nutzers
• Diese Struktur wurde gewählt, um wie bei der Entwicklung mit MonoGame- oder FNA-Projekten das gesamte Projekt direkt steuern zu können
• Der Editor ist als separates Projekt angelegt, damit Editor-Code nicht mit dem Game-Code in Berührung kommt und man auf der Editor-Seite frei die gewünschten Arbeiten ausführen kann

Build- und Abhängigkeitsmodell

• Derzeit gibt es kein NuGet-Paket für Murder
• Empfohlen wird, Murder als Git-Submodule einzubinden und in der .csproj darauf zu verweisen
• Ein Beispiel für die Referenzierung findet sich in HelloMurder.csproj

Anforderungen und unterstützte Plattformen

• Die Entwicklungsumgebung zum Ausführen des Editors unterstützt Linux, MacOS, Windows und Steam Deck
• Erforderlich ist die Installation des .NET 8 SDK
• Als Zielplattformen für Spiele werden Linux, MacOS und Windows unterstützt
  • Zu Linux gehört auch Steam Deck
• Konsolen-Support ist derzeit in Arbeit
• Für Web sowie Mobile mit iOS und Android gibt es aktuell keine offiziellen Support-Pläne

Beiträge und Feedback

• Das Projekt befindet sich noch in einer sehr frühen Phase
• Für Vorschläge oder Feedback kann der Entwickler kontaktiert werden; es wird ausdrücklich Interesse an realer Nutzung und Rückmeldungen signalisiert

[GN⁺]

Meinungen auf Hacker News

• Als ich sah, dass saint11 daran beteiligt ist, war ich sicher, dass es gut sein würde. Die Pixel-Art-Tutorials sind wirklich gut aufbereitet: http://saint11.org/blog/pixel-art-tutorials/

  • Habe ich gerade zum ersten Mal gesehen, und schon ein kurzes Überfliegen hat mich überzeugt, dass das der beste Blog im ganzen Internet ist
  • Ich wusste nicht, dass das dieselbe Person ist. Ich hatte diese Tutorials früher gesehen, und die Art, wie die Inhalte aufgefächert und gezeigt werden, war großartig
  • saint11 scheint die Person zu sein, die die Art für das Spiel Celeste gemacht hat
  • War an Celeste und Towerfall beteiligt, und beide haben herausragende Pixel Art. Wirkt wirklich sehr talentiert

• Neue Game Engines und ECS-Frameworks machen Spaß anzuschauen. Wenn man sich Bang, den ECS-Teil, ansieht, gibt es Beispiele für Komponenten wie CarComponent und Systeme wie CarMoverSystem; Systeme sind Klassen, und die implementierten Interfaces scheinen zu bestimmen, wann sie ausgeführt werden
  Es erinnert ein wenig an DOTS, aber ich habe noch nicht gefunden, wo Systeme dem Spiel hinzugefügt werden und wie Systeme derselben Art sortiert werden. Mich interessiert auch, wie ein System aussieht, das mehrere unterschiedliche Queries macht, etwa nach Autos und Hindernissen
  Bang scheint einen Source-Code-Generator zu verwenden. Anders als GetComponent scheinen TryGetVelocity, RemoveFriction und SetVelocity auf Basis der Existenz der Komponenten Velocity und Friction generiert zu werden; vielleicht wegen eines Component-ID-Caches, sicher bin ich mir nicht
  Es ist nicht archetypenbasiert; jede Entity speichert ein Dictionary component id => component, und jedes System verfolgt, welche Entities zu seinem Filter passen. Ich weiß nicht, wie gut die Performance sein wird, aber bei vielen Spielen kann Entwicklerfreundlichkeit wichtiger sein als Performance
  Änderungen scheinen auch sofort angewendet zu werden. Dann frage ich mich, ob es von der Entity-ID abhängt, ob etwas im selben Tick verarbeitet wird, wenn ein System einer Entity Komponenten hinzufügt oder entfernt und sich dadurch ändert, ob sie zu einem Filter passt

  • Mich interessiert auch die Ausführungsreihenfolge der Systeme. Neue Systeme manuell zu einer festen Liste hinzufügen zu müssen, kann frustrierend sein, aber gleichzeitig haben Systeme oft implizite Abhängigkeiten voneinander, sodass es wichtig ist, die Ausführungsreihenfolge zur Compile-Zeit festzulegen
    Beim flüchtigen Blick in die Doku habe ich keine Möglichkeit gesehen, solche Abhängigkeiten oder Reihenfolgen explizit anzugeben, und ich frage mich, wie diese Engine damit umgeht

• Die Itch-Seite und der Download eines mit diesem Framework erstellten Jam-Games: https://saint11.itch.io/neo-city-express
  Für ein 72-Stunden-Jam-Game beeindruckend. Die Art und der Text sind gut, und auch mechanisch macht es auf unerwartete Weise Spaß

• Sehr schön. Der Editor ist extrem stylish, das gefällt mir. MonoGame mochte ich immer, weil es performant und Cross-Platform ist, aber ich habe nie ein großes Spiel damit gebaut, nur ab und zu Demos

• Sieht gut aus. Ich frage mich, ob es bei C#-Game-Development Probleme mit GC-Pausen gibt

  • Mit einfachem Objektmanagement und expliziten Aufrufen von GC.Collect() in kleinen Vielfachen der Simulationslatenz hat es ziemlich gut funktioniert. Der optimale Punkt scheint vom Szeneninhalt und Gameplay-Stil abzuhängen, also davon, wie sich die Szenenobjekte verändern
    Bei Szenen und Gameplay im Q3A-Stil ist es sehr robust. Es gibt kaum Szenenelemente, die sich pro Tick ändern, daher sind GC-Pausen meist vernachlässigbar
    In .NET 6+ habe ich in einer DIY-Engine bei strategisch schnell wiederholten Aufrufen GC-Pausen von etwa 1–5 ms gemessen. Den niedrigsten Jitter hatte ich, wenn Concurrent/Server/Background-GC in den Projekteinstellungen deaktiviert waren und stattdessen Foreground- plus Workstation-GC verwendet wurde
    Es scheint, als blieben nur zwei Optionen: Speicher zu 100 % selbst verwalten oder Müll so häufig wie möglich aufräumen. In modernem .NET ist es fast unmöglich, den GC ohne schwarze Magie wie Low-Level-DLL-Hacks vollständig abzuschalten. Wenn man den Prozess zwischen Arbeitsereignissen oder Spielrunden neu starten kann, ist Process.Exit() in manchen Bereichen ebenfalls eine gültige GC-Technik
  • Ja. Es gibt einen guten Vortrag von Miguel de Icaza über die Geschichte, wie C# in Game Engines integriert wurde, und darüber, warum er sich auf Swift in Godot freut, mit dem Argument, dass Swifts Reference Counting das Problem von GC-Pausen vermeidet
    https://youtu.be/tzt36EGKEZo?si=WNxwcTPGFbJABKez
  • Ich denke, GC-Probleme gibt es fast nur bei Unity. Andere Game Engines, die normales .NET verwenden, wie Stride, funktionieren problemlos
  • Ja. Nicht nur Unity, auch Unreal hat GC, daher sollte man beim Start allozieren und Object Pooling verwenden
  • Wie die meisten anderen Sprachen kann man auch C# so schreiben, dass Allokationen vermieden werden

• Nur anhand des Links kann ich es nicht gut einschätzen, aber ich frage mich, wie schwierig es wäre, mit der Murder Game Engine ein F#-Spiel zu erstellen

• Ich habe in Unity ein wenig ECS verwendet, und Murder ECS war deutlich einfacher. Die Entwickler haben das wirklich gut gemacht
  Ich habe mit Murder ein kleines Arcade-Game-Projekt erstellt; es ist hier spielbar: https://nopetrides.itch.io/bombs-away

  • Kannst du die Unterschiede etwas genauer erklären?

• Auf der Vorstellungsseite von saint11 steht: „Murder Engine: 2D Pixel art C# ECS Game Engine made by Isa! I usually help on the render and physics side of it.“
  Isa: https://isadorasophia.com/projects/

• Hat nichts mit der Game Engine zu tun, aber ich finde es amüsant, dass eine böswillige Person sagen könnte: „Die Leute auf dieser Hacker-Website diskutieren über murder.“
  In letzter Zeit denke ich viel darüber nach, wie hartnäckige Gegner völlig harmlose Materialien auf diese Weise ausnutzen könnten

  • Klingt etwas weit hergeholt, aber es gab auch Leute, die Artikel von The Onion wörtlich genommen haben
    Wenn es sich aber so leicht widerlegen lässt, weiß ich nicht, ob es einen großen Unterschied zwischen der Formulierung „Leute diskutieren über murder“ und einer offenen Lüge gibt
  • Auf diese Weise, nur umgekehrt gedacht, ist es die einzige Art, Nachrichten in den Massenmedien zu konsumieren. Heutzutage ist alles so voreingenommen und lächerlich, dass es kaum zu glauben ist

• Was ist ECS?

  • Vermutlich Entity Component System. Eine in Game Engines verbreitete Architektur
  • Eine aktuell populäre High-Performance-Architektur. Unity versucht seit einiger Zeit, sie stark zu popularisieren