Bevy 0.12 – Datengetriebene Game-Engine in Rust

 (bevyengine.org)
2 Punkte von GN⁺ 2023-11-05 | 1 Kommentare | Auf WhatsApp teilen
  • Der Renderer unterstützt optional Deferred Rendering; pro Material kann ein Forward- oder Deferred-Pfad gewählt werden, und mit DefaultOpaqueRendererMethod lässt sich ein globaler Standardwert festlegen
  • Bestehende Bevy-Apps oder -Plugins sollten die Migration mithilfe des 0.11 to 0.12 Migration Guide prüfen
  • Bevy Asset V2 unterstützt Asset-Vorverarbeitung, auf .meta-Dateien basierende Konfiguration, mehrere AssetSource, rekursive Abhängigkeits-Ladeereignisse, asynchrones Asset-I/O und verbesserte Handles
  • Die Asset-Vorverarbeitung wird mit AssetPlugin { mode: AssetMode::Processed } und dem Cargo-Feature bevy/asset_processor aktiviert, wird derzeit aber für die meisten Anwendungsfälle noch nicht empfohlen
  • Unter Android stürzt die App beim Suspendieren nicht mehr ab, stoppt stattdessen die Systemausführung bis zur Fortsetzung und bietet die Events ApplicationLifetime::Suspended und ApplicationLifetime::Resumed
  • StandardMaterial erhält specular_transmission, diffuse_transmission, thickness, ior, attenuation_color und attenuation_distance, um transmissive Materialien wie Glas, Wasser, Kunststoff, Blätter und Papier darzustellen
  • Der glTF-Loader unterstützt die Erweiterungen KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume und KHR_materials_emissive_strength und kann eine zweite UV-Map über TEXCOORD1 oder UV1 importieren
  • Automatisches Batching/Instancing von Draw Commands ist nun möglich; Entitäten mit demselben Material und Mesh können derzeit gebatcht werden, und über die Komponente NoAutomaticBatching lassen sie sich ausschließen
  • Schatten führen PCF Shadow Filtering ein und unterstützen damit weichere Schatten bei DirectionalLight und SpotLight; die Standardmethode ist ShadowMapFilter::Castano13
  • Dem ECS wurden One-Shot-Systems hinzugefügt, die nach der Registrierung bei Bedarf über SystemId ausgeführt werden können; nicht unterstützt werden exclusive systems, Systems für system piping, Selbstaufrufe und parallele Auswertung
  • FixedTime wurde entfernt, und Time liefert nun auch in FixedUpdate kontextgerechte Werte zurück; außerdem verhindert FixedUpdate, dass sich eine „death spiral“ durch übermäßige Akkumulation aufbaut und die App einfriert
  • In AnimationPlayer wird set_elapsed durch seek_to ersetzt, stop_repeating durch set_repeat(RepeatAnimation::Never), und elapsed gibt die tatsächliche verstrichene Zeit zurück, die nicht von der Animationsgeschwindigkeit beeinflusst wird
  • Der Bevy-Shader-Import wurde auf eine Rust-ähnliche Syntax umgestellt und unterstützt #import bevy_pbr::forward_io::VertexOutput, Mehrfachimporte mit geschweiften Klammern, Teilpfadimporte und vollständig qualifizierte Pfade
  • In der UI können mit UiMaterial benutzerdefinierte Material-Shader auf UI-Knoten angewendet werden, und die Komponente Outline unterstützt Knoten-Umrandungen, die keinen Layout-Platz beanspruchen
  • Für die Accessibility-Integration wurde die Ressource ManageAccessibilityUpdates hinzugefügt; ist ihr Wert false, können automatische Updates des Accessibility-Baums der Engine gestoppt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-05
Hacker-News-Kommentare

  • Im Vergleich zu traditionellen Engines wie Unity oder Godot ist Bevy eine völlig andere Art, Spiele zu entwickeln
    Alles wird in Rust-Code umgesetzt, ohne UI oder Skripting, und ist damit eher mit libGDX oder Cocos2D-x vergleichbar. Durch ECS und Rust unterscheidet sich der Programmierstil aber noch einmal stark, sodass es sich fast wie eine eigene Insel anfühlt
    Ich würde gern erfolgreiche Indie-Spiele sehen, die mit Bevy entstanden sind, aber die meisten Spieleentwickler bevorzugen wahrscheinlich weiterhin traditionelle Werkzeuge, die sie bereits kennen und die auch ihr Umfeld nutzt. Die Schnittmenge aus Leuten, die Spiele machen wollen und zugleich Rust bevorzugen, ist nicht besonders groß, und selbst innerhalb dieser Gruppe werden viele eher auf Werkzeuge mit mehr Vertrauen und mehr Lernmaterial setzen, statt viel Zeit und Mühe in eine experimentelle neue Engine zu investieren
    Meiner Meinung nach braucht Bevy eine auf Bevy und Rust basierende IDE und Skriptsprache. Das beseitigt zwar nicht die Hürde, für ein neues Projekt viel Aufwand investieren zu müssen, könnte die Engine aber für neue Nutzer ohne Rust-Erfahrung, die vor einer Wand aus Code zurückschrecken, deutlich zugänglicher machen. Das steht im Kontrast zu Unity oder Godot, wo man in wenigen Stunden auf einer Canvas einen sehr einfachen Prototypen bauen kann
    Soweit ich weiß, sind die Entwickler gegen eine Skriptsprache, aber Hot Reload und tiefere Debugging-Möglichkeiten werden gebraucht, und allein mit Rust lässt sich das meiner Meinung nach nur schwer effektiv umsetzen. Viele Spieleentwickler könnten sich von Rust und dem Borrow Checker überfordert fühlen. Im Moment fehlt allerdings die Zeit, die Ressourcen und auch der Wille, das selbst umzusetzen

    • Bei Bevy stößt man strukturell nicht besonders oft direkt auf den Borrow Checker. Komponenten und Ressourcen verwenden meist Owned Types, und über Query und Ref kann man damit ohne große Sorgen arbeiten
      Ich habe ein wenig mit Bevy herumgespielt und im Repository nachgesehen: Es gab 0 Lifetime-Annotationen
    • In der Spieleentwicklung geht die meiste Zeit oft für Asset-Management drauf, und erst danach fürs Programmieren. Engines wie Bevy versuchen zwar, die Zeit für Bugfixes zu senken, aber wenn die Asset-Pipeline schwach ist, verliert man diese Einsparung schnell an anderer Stelle wieder
      Eine Skriptsprache könnte etwas helfen, aber die heutigen Bevy-Nutzer sind meist sehr technisch geprägt und oft keine hauptberuflichen Designer, daher scheint die dringende Nachfrage derzeit nicht besonders groß zu sein
      Ich freue mich auf den Einfluss der Rust-Community auf die Spieleentwicklung und würde irgendwann gern selbst dazu beitragen, aber im Moment werde ich aus den genannten Gründen bei meiner C++/C#-Pipeline bleiben. Rust lerne ich nebenbei richtig, und wenn die Werkzeuge ausgereifter sind, kann ich es für spätere Projekte in Betracht ziehen
      Hot Reload ist oft nur ein Provisorium, das man einsetzt, wenn die Kompilierzeiten untragbar werden. Wenn der Durchschnitt bei 4 Sekunden und eine vollständige Neukompilierung bei etwa 20 Sekunden liegt, lohnt es sich weniger, viele Ressourcen in Wege zu stecken, die den vollständigen Build vermeiden
      Ich habe allerdings gehört, dass Rust insgesamt längere Kompilierzeiten hat, daher könnte der Bedarf an Skripting oder Hot Reload früher kommen als gedacht. Trotzdem werden aktuelle Indie-Projekte vermutlich noch nicht an diese Grenze stoßen
    • Eine IDE ist schon seit ziemlich langer Zeit geplant und soll meines Wissens nach dieser Veröffentlichung die höchste Priorität haben
      Bevy-Gründer Cart ist der Ansicht, dass Bevy Rust-first sein sollte, und ich stimme dem persönlich zu. Das heißt aber nicht, dass man keine Plugins für verschiedene Skriptsprachen bauen kann, und tatsächlich gibt es davon bereits einige

  • Ich bin der Gründer von Bevy und leite das Projekt. Fragt mich alles

    • Wir entwickeln mit Bevy eine ziemlich große WASM-App gemessen an der Unternehmensgröße, und die Erfahrung mit der Engine war sehr gut
      Bevy und die Community sind großartig. Wir mussten an ein paar Tickets arbeiten, und es war sehr einfach, einen der Core-Contributors zu finden, ihn zu sponsern und die Anfrage bis zum Ende durchzuschieben. So war es zum Beispiel bei Morph Targets
      Carter baut da wirklich etwas Wichtiges auf, und dahinter steckt großartige Dynamik. Bevy macht Web-Deployment sehr einfach und verdient mehr Aufmerksamkeit. Die Community ist gut, und es ist leicht, Hilfe zu bekommen
    • Die Dokumentation ist begrenzt, und das hält mich vom Einstieg ab. Das Bevy-Buch ist in ein paar Minuten durchgelesen, und wenn man feststeckt, gehen einem schnell die Referenzen aus
      Wann wird die Dokumentation besser? Wenn ich die Release Notes sehe, hätte ich idealerweise gern zu jedem Feature mehrere Seiten Dokumentation. Ich verstehe, dass viel Arbeit anfällt, und vielleicht ist vollständige Dokumentation erst nach mehr Stabilisierung realistisch
    • Als Hobby-Spieleentwickler würde ich für ein neues Projekt wahrscheinlich Bevy wählen. Es wirkt wie eine gute Mischung irgendwo zwischen Love und Godot: robuster als Love, aber nicht so einsteigerfreundlich wie Godot
      Wie meinungsstark ist Bevy als Engine? Mich würde interessieren, ob ihr jemals zwischen Features und Entwicklerzugänglichkeit Kompromisse eingehen musstet
      Welche Art von Projekt ist aktuell ideal für Bevy?
    • Mich würde interessieren, welche Vor- und Nachteile es hat, Spiele mit Rust und Bevy im Vergleich zu anderen Sprachen zu schreiben. Besonders zu Performance, Sicherheit und Entwicklungsgeschwindigkeit würde ich gern etwas hören
    • Wann werden Features zu sehen sein, die dynamische Systeme und erstklassiges Bevy-Skripting ermöglichen?
      Es gibt einige Skripting-Plugins, und derzeit scheint der Fokus vor allem auf rhai zu liegen, aber es wirkt, als kämen sie wegen fehlender angemessener Bevy-Unterstützung nicht richtig voran
      Unabhängig davon, ob Bevy sich auf reine Rust-Spiele fokussiert oder nicht, gibt es Bedarf an Skripting, und einige Leute sind bereits damit beschäftigt, Third-Party-Lösungen zu suchen. Ich erwarte nicht sofort offizielles Bevy-Skripting, aber ich denke, Bevy sollte die Grundlagen akzeptieren, auf denen Third-Party-Crates funktionieren können

  • Im Artikel steht, dass Deferred Rendering kein MSAA unterstützt, aber das stimmt nur für naive Implementierungen
    Man kann zum Beispiel im Pre-Pass eine Stencil-Maske für komplexe Pixel erzeugen und dann mit hierarchischer Early-Stencil-Rejection für komplexe Pixel einen Sample-pro-Sample-Pass und für die übrigen Pixel einen Pixel-pro-Pixel-Pass ausführen. Die Auslastung der SIMD-Lanes ist dabei nicht perfekt
    Außerdem kann man einen Pass für die komplexe Pixelmaske haben und einen (x, y, sample)-Koordinatenpuffer sammeln, um danach in einem einzelnen hybriden Pixel-/Sample-basierten Compute-Shader-Pass eine perfekte Auslastung der SIMD-Lanes zu erreichen

    • Interessant. Ich hatte früher einmal darüber nachgedacht, bin aber davon ausgegangen, dass es zu langsam wäre. Mich würde interessieren, ob du veröffentlichte Titel kennst, die diese Technik verwenden

  • Ich mache seit einiger Zeit Spiele mit Bevy. Man kann auch den Code ansehen und Fragen stellen.
    https://ant.care/
    https://github.com/MeoMix/symbiants
    Die bisherigen Schwierigkeiten sind, dass das UI-System zu umständlich ist, um Widgets bequem zu erstellen, weshalb ich auf egui umgestiegen bin, aber wahrscheinlich innerhalb eines Jahres zu nativem Bevy zurückkehren werde. Auch egui hat große Einschränkungen.
    Die Unterstützung für Eltern-/Kind-Beziehungen ist nicht besonders umfangreich, und die ECS-Struktur sträubt sich in gewissem Maß dagegen. Einer Sprite ein Label zuzuweisen und die Sprite zu verschieben/zu drehen, während das Label nur der Position folgt, aber nicht der Rotation, war schwieriger als erwartet.
    Persistenz von Entitäten über mehrere Sessions hinweg wird nicht von Haus aus unterstützt. Entity ist für die Eindeutigkeit auf Client-Seite gedacht, und auch gespeicherte Eltern-/Kind-Beziehungen lassen sich nicht automatisch einfach wiederherstellen.
    Es gibt noch keine Unterstützung für WASM-Parallelität, aber die Bevy-Architektur ist stark darauf ausgelegt, durch Aufgabenparallelisierung Performance-Gewinne zu erzielen, weshalb die Systemreihenfolge flexibel gehalten wird.
    Räumliche Abfragen fühlen sich so an, als würden sie mit den Zielen von ECS kollidieren. Wenn man nicht nach Typen suchen will, also danach, ob eine Entität Position hat, sondern nach dem Wert von Position, entstehen viele Hilfscaches, die mit der Abfrage-Engine synchronisiert werden müssen.
    Wenn man die Welt mit commands verändert, wird das aus Performance-Gründen verzögert und im Batch verarbeitet; wenn es viele solche verzögerten Operationen gibt, wird es schwierig, Systeme zu bauen, die die Welt aktiv verändern. Deshalb ruft man häufig apply_deferred auf und verwendet benutzerdefinierte Befehle, um Race Conditions zu lösen.
    WASM auf Android, besonders die Kombination aus Pixel 6 und Chrome, funktioniert derzeit nicht, aber das ist ein Problem in einer unteren Abhängigkeit und soll in Bevy 13 behoben werden.
    Die Vorteile sind, dass die Kombination aus Rust-Engine und Rust-Spiel sehr angenehm zu bearbeiten ist und sich Rust+WASM kaum so anfühlt, als würde einen die Technologie ausbremsen. Sobald das Denken auf ECS umgestellt ist, fällt es schwer, wieder zurückzugehen, und es ist sehr flexibel. Vielleicht sogar zu flexibel.
    Die Community ist aktiv, daher findet man leicht Leute, mit denen man über Probleme sprechen kann, und auch wenn es nicht viele Dokumente gibt, gibt es viele Beispiele. Der Optimismus für die Zukunft ist groß, die Entwicklung verläuft schnell, und mit jeder Release werden die wichtigsten Bedenken deutlich vorangebracht.

    • Übrigens funktioniert ant.care nicht auf dem iPhone. Ich habe es sowohl in Safari als auch in Firefox getestet, und die Website lädt nach kurzer Zeit in einer Endlosschleife neu.

  • Die Release Notes sind hervorragend.
    Für erfahrene Spiele-/Engine-Entwickler ist manches vielleicht zu einsteigerfreundlich, aber aus Sicht von jemandem, der nicht ständig in dieser Welt unterwegs ist, war die Balance zwischen Erklärung der Änderungen und thematischer Einordnung sehr gut.

  • Ich habe den Witz gesehen, dass es 5 in Rust geschriebene Spiele gibt, aber 50 Game-Engines.
    Gibt es tatsächlich eine Liste von mit Bevy geschriebenen Spielen?

  • Alle Frameworks beginnen damit, etwas bereits Vorhandenes einfacher, sauberer und schneller umzusetzen, aber ihnen fehlen die glänzenden Features.
    Dann holen sie bei den Features auf, werden zu demselben komplexen Monster, und der Kreislauf wiederholt sich.

    • Im Großen und Ganzen auf den Lebenszyklus von Softwareprojekten bezogen ist das plausibel, aber es lässt sich auf praktisch jede Behauptung über Einfachheit oder Benutzerfreundlichkeit von Software anwenden und wirkt deshalb nicht wie eine besonders nützliche Kritik.
      Das Fazit klingt wie „Jede einfache Software, die Features hinzufügt, ist zum Scheitern verdammt“, was etwas dramatisch wirkt.
      Ich würde gern wissen, ob es konkrete Gedanken oder Bedenken zur Architektur von Bevy oder zur Art gibt, wie dort Features hinzugefügt werden. Man gibt sich große Mühe, genau diesem Schicksal zu entgehen.
    • Ich würde nicht direkt widersprechen, aber Bevy hat eine Stärke, die den meisten Frameworks fehlt: Modularität. Nicht nur als Konzept, sondern Modularität, die nachweislich in der Praxis funktioniert.
      Tiny Glade verwendet bevy_ecs, nutzt aber die Rendering-Crates von Bevy überhaupt nicht. Ich selbst habe auch ein paar PRs in Arbeit für alternative Rendering-Pfade, etwa Raytracing oder GPU-gesteuertes Meshlet- plus Visibility-Buffer-Rendering, und an Bevy intern ändert sich dabei fast nichts.
      Aus Sicht der Nutzer ändert sich ebenfalls kaum etwas. Man fügt der App einfach FeatureFooPlugin hinzu und verwendet etwas wie FooComponent, dann funktioniert es.
      Einzelne Crates oder Plugins können aufquellen, aber Bevy als Ganzes dürfte in Ordnung bleiben. Nutzer können solche Plugins einfach ignorieren und stattdessen etwas anderes verwenden, das besser zu ihnen passt.
      Außerdem ist das hier eine Game Engine. Per Definition ist sie ein aufgeblähtes, komplexes Monster und wird alle möglichen Features aufsaugen, weil sie für irgendein Spiel nützlich sein könnten. Entscheidend ist, wie sich Feature-Bloat auf die Benutzbarkeit auswirkt. Wenn es 1000 Features gibt, man aber mit den meisten gar nicht interagieren muss, ist das völlig okay.
    • Entscheidend ist aus meiner Sicht, ob ein Projekt bereit ist, die API einfach, sauber und schnell zu halten, auch wenn das bedeutet, mit der Vergangenheit zu brechen.
      Dass das bei neuen Projekten leichter ist, die sich nicht um Abwärtskompatibilität kümmern müssen, stimmt sicher. Bei dem, was ich von Bevy gesehen habe, gibt es eine starke Kultur, eine gute User Experience einzufordern und die API-Oberfläche klein zu halten. Vielleicht liegt das auch an Rusts Paketierung, aber ich finde positiv, wie aktiv man dafür mit der Vergangenheit bricht.
      Das Gute an cargo ist, dass man, selbst wenn man sich entscheidet, von Bevy abzuhängen, kein bewegliches Ziel verfolgen muss, falls eine künftige Version Breaking Changes enthält. Man bleibt einfach bei seiner Version. Trotzdem gibt es Anleitungen, um den Umstieg auf die neueste Version zu erleichtern. Zumindest war das meine Erfahrung aus dem bisschen, das ich mit Bevy herumprobiert habe.

  • Beim Upgrade von 0.10 auf 0.11 waren ziemlich viele Änderungen an der App nötig, diesmal hat es jedoch direkt kompiliert.

  • Bevy ist besonders für große Projekte eine meiner bevorzugten Game Engines. Asset-V2-Preprocessing und .meta-Dateien wirken sehr nützlich.
    Ich freue mich auch auf die Lightmap-Unterstützung in künftigen Releases.

  • Ich habe mir die Web-Beispiele angesehen und dann den UI-Bereich, und es scheint, als würde alles vollständig innerhalb des Canvas verarbeitet.
    Könnte man die UI stattdessen als DOM erstellen und an WASM anbinden?

    • Ja, das geht, und ich habe tatsächlich schon Fälle gesehen, in denen das so gemacht wurde. Man muss nur einen Weg schaffen, Informationen zwischen der UI und Bevy auszutauschen.
      Auf der Rust-, also WASM-Seite gibt es Dinge wie web_sys, und auf der JavaScript-Seite kann man auch WASM-Funktionen aufrufen, also gibt es viele Möglichkeiten.