Showroom - Aktuelle Arbeiten und Projekte

[Krishty]

Ich habe selbst mal versucht Unity-Physik deterministisch hinzukriegen. Mit viel Mühe habe ich es innerhalb von einer Plattform geschafft, aber plattformübergreifend war es ein aussichtsloses Unterfangen.

Respekt, dass es auf einer ganzen Plattform lief! Ich höre ständig Gerüchte darüber, dass es „höchstens auf dem selben System“ reproduzierbar wäre, wie etwa in diesem grottenschlechten Artikel. Spieleentwickler müssen sich natürlich an die Trennung von Update() und FixedUpdate() halten, aber welche Probleme Unity intern hat, weiß ich nicht. Falls es dazu Entwicklerkommentare gibt, würde ich die gern lesen 👀

————

Vor 20 Jahren (oh shit!) war das hier der Goldstandard: https://gafferongames.com/post/fix_your_timestep/

Upps – ich vergaß, dass mir aus (zu recht!) dieses Video ans Herz gelegt worden war:


————

Hm, ja, ich folgere daraus mal, dass es tatsächlich nicht einfach ist.

Ich habe ehrlich gesagt keine Ahnung, ob ich z.B. Fast-Math aktiviert habe. Oder wie das in all meinen Abhängigkeiten aussieht. Oder welche Flags wo und wann aktiviert sind und von welcher Abhängigkeit.

Ich lese „Ich habe keine Ahnung, was meine Software tut. Deshalb ist es nicht einfach, Software zu entwickeln, die tut, was man möchte.“

Man kann mit nicht-deterministischer Physik weit kommen; hängt halt vom Anwendungsfall ab. Deterministische Physik ist aber keinesfalls unmöglich. Half-Life, Quake – die waren alle deterministisch (siehe Demos/Replays im DEM-Format). Die Engine spielt einfach einen Strom Ereignisse ab; egal, ob die aus der lokalen GUI oder von einem Server kommen. Muss aber in Vergessenheit geraten sein, denn so etwas wird heute ja mitunter als Errungenschaft von Entity-Component-Systemen verkauft.

Vielleicht bin ich aber auch einfach ein schlechter Entwickler, weil ich dafür keine Unit-Tests habe

Replays von deterministischer Physik eignen sich übrigens perfekt als Tests. Du kannst ziemlich hohe Testabdeckung erreichen, indem du literally für ein paar Sekunden die Record-Taste hälst, nach jedem Build ein Replay laufen lässt, und schließlich prüfst, ob die Objektpositionen die selben sind 🤷

VSYNC ist eine guter Punkt

Ich gehe nicht auf die Details ein, weil die sich bisher immer als irrelevant herausgestellt haben. Du lässt deine Simulation natürlich nicht mit VSync-Frequenz laufen, sondern mit einer festen Frequenz, die höher ist – optimalerweise der GGT beliebter Frame-Intervalle. Ich nutze gerade 144 Hz; früher mal 240. Autorennspiele laufen intern gern mit 200–1000 Hz (Wikipedia hatte dazu mal eine tolle Tabelle). Interpolieren/Extrapolieren kann man, aber ich habe noch nicht gehört, dass sich jemand wirklich dazu gezwungen sah – außer Soapy in ReDRIVER2, dessen Physik mit 50 Hz lief (weil PlayStation 1!) und das auf 60-Hz-Bildschirmen leicht unrund aussah. Wenn du mit 120 Hz rechnest, wird das auch ohne Interpolation auf jedem gängigen Monitor (60 Hz, 80 Hz, 120 Hz) flüssig aussehen.

Ein Objekt kann dann nicht mehr mit seiner aktuellen Position aus der Spiellogik gerendert werden, sondern es muss eine extra Renderposition berechnet werden. […] dann braucht man auch mindestens mal alle Variablen doppelt und muss auch immer einen extra Update-Schritt machen, und irgendwo zwischenspeichern. Für alles, was irgendwo irgendwie angezeigt wird. Klingt super nervig.

Ja; zwei/drei Implementierungen, die mir bekannt sind, speichern bei VSync einen Snapshot der aktuellen Szene. Ist durchaus nervig, beschwert mitunter aber auch Synergieeffekte mit Dingen wie Multi-Threaded Rendering.

Ich selber tue das übrigens nicht. Ich unterbreche die Physik-Berechnung, sobald ein Frame angezeigt werden muss, und hole nach dem Rendern wieder auf. Fühlt sich ein wenig schmutzig an; ändere ich wahrscheinlich, sobald ich Multiplayer realisieren muss.

Ich möchte niemandem was vorschreiben und labere hier nur, weil ich das Thema gern diskutiere. Gute Spiele kann man mit Determinismus bauen oder ohne. Aber Aussagen wie, Floats wären grundsätzlich ungenau oder man könnte sie nicht über Plattformen hinweg konsistent nutzen, kann ich nicht stehen lassen.

[smurfer]

Autorennspiele laufen intern gern mit 200–1000 Hz (Wikipedia hatte dazu mal eine tolle Tabelle)

Die fand ich auch klasse, war aber meine ich nur ein Subset der Tabelle aus dem LFS-Forum, deren Eintrag von 2008 auch noch 2023 aktualisiert wurde. Daher der Vollständigkeit halber: https://www.lfs.net/forum/thread/48927- ... acing-sims

[Krishty]

Die fand ich auch klasse, war aber meine ich nur ein Subset der Tabelle aus dem LFS-Forum, deren Eintrag von 2008 auch noch 2023 aktualisiert wurde. Daher der Vollständigkeit halber: https://www.lfs.net/forum/thread/48927- ... acing-sims

Sehr geil; vielen Dank 🙏

[Jonathan]

Ich lese „Ich habe keine Ahnung, was meine Software tut. Deshalb ist es nicht einfach, Software zu entwickeln, die tut, was man möchte.“

Naja, kann man so oder so sehen. Du kannst das so lesen, wenn du das möchtest, und hast dann damit auch nicht unbedingt unrecht. Aber ich würde es eher so formulieren: Man kann fast beliebig weit in die Komplexität absteigen, aber in der Regel entscheide ich mich dafür, Dinge nicht wesentlich besser zu verstehen, als ich muss, um mehr Zeit für anderes zu haben. Ich guck mir z.B. nie den kompilierten Maschinencode an, weil das für meine Zwecke Zeitverschwendung ist. Die Überwiegende Mehrheit der Compilerflags stehen auf Standardeinstellungen, weil die halt tun und das pragmatisch ist. Und konkret zu deterministischer Physik ist das Problem weniger, dass es intellektuell schwierig ist, sondern eher, das es zeitlich aufwändig ist (wobei man philosophisch fragen kann, ob das überhaupt jemals ein Unterschied ist ;) ). Ich muss mir eine Liste an Dingen die schief gehen können zusammenstellen, gucken wie sich mein Code diesbezüglich verhält, und gucken wie sich der Code aller Abhängigkeiten diesbezüglich verhält. Und sicherstellen, dass sich das nicht ändert. Und dieser Zeitaufwand muss mir der erwartete Mehrwert wert sein.

Ich hatte übrigens mal das nette Problem, dass GLM all seine Standardkonstruktoren von "mit 0 initialisieren" auf "gar nicht initialisieren" geändert hat, wegen Performance. Das hat mich mehrere Tage gekostet, alle Stellen in meinem Spiel zu finden, wo meine Variablen jetzt uninitialisiert sind. Ich hätte die neue GLM Version zu dem Zeitpunkt nicht gebraucht, wollte aber mit der Zeit gehen und auf die aktuelle Version umsteigen. Spaß hatte ich damit nicht. Seit dem bin ich etwas vorgeschädigt, weil breaking changes in Abhängigkeiten angeht^^.

Replays von deterministischer Physik eignen sich übrigens perfekt als Tests. Du kannst ziemlich hohe Testabdeckung erreichen, indem du literally für ein paar Sekunden die Record-Taste hälst, nach jedem Build ein Replay laufen lässt, und schließlich prüfst, ob die Objektpositionen die selben sind 🤷

Hmmm, ich bin mir wirklich nicht sicher, wie viele Fehler ich in meinem Spiel realistisch durch Unit-Tests jemals hätte finden können. Das Problem ist, dass die allermeisten Änderungen am Code auch das erwartete Ergebnis ändern und damit alle Tests ungültig werden. Und dass ich an einer Stelle A etwas ändere, und dadurch an einer Stelle B, die für etwas komplett unterschiedliches da ist, und deren Unit-Test demnach weiterhin durchlaufen sollte, etwas durch unbewusste Abhängigkeiten kaputt geht, passiert mir extrem selten. Daher habe ich jedesmal wenn ich darüber nachgedacht habe, mich gegen Unit-Tests entschieden.

aber ich habe noch nicht gehört, dass sich jemand wirklich dazu gezwungen sah – außer Soapy in ReDRIVER2, dessen Physik mit 50 Hz lief (weil PlayStation 1!) und das auf 60-Hz-Bildschirmen leicht unrund aussah.

Ja, bin mir auch wirklich nicht sicher, ob ich wirklich darauf beharren würde (daher die "Und dann ist halt die große Entscheidung, ob es einem reicht, den letzten Spielzustand anzuzeigen, oder ob man zwischen Frames interpolieren will." - Formulierung), aber es war halt ein großer Punkt der mir eingefallen ist, der einem kaputt geht, wenn man auf eine feste Framerate umsteigt. Man könnte das natürlich einfach mit 10 Zeilen in der Hauptschleife schnell mal ausprobieren und vergleichen, vielleicht mache ich das ja mal. Insbesondere wenn man die Schrittweite verringert, also sich nicht 1 und 2 Logik Updates zwischen dem Rendern abwechseln, sondern z.B. 9 und 10 merkt man das bei 60 FPS vielleicht wirklich einfach gar nicht mehr. Wobei eine größere Anzahl Update-Schritte natürlich auch entsprechend mehr kostet. Hmmmm.

Mir fällt noch auf, dass mein Beispiel mit den Plattformen nichts mit der Framerate zu tun hat - Fehler können sich ja auch bei festen Zeitschritten genau so aufaddieren. Der einzige Unterschied scheint mir zu sein, ob sie sich deterministisch aufaddieren, oder nicht.

Für Harald wären Replays schon eine nette Sache gewesen. Wenn man das Frame-Interpolieren weglässt, würden sich die Änderungen ja sogar in Grenzen halten. Man könnte sogar auf Unterschiede zwischen CPU-Flags pfeifen, es reicht ja theoretisch, wenn das einmal kompilierte Programm auf jedem Rechner gleich läuft, in neuen Versionen könnte sich ja auch die Spiellogik ändern, dann sind die Replays eh pfutsch.
So gesehen, könnte man das wirklich mit einer handvoll Zeilen umstellen. Aber letztendlich hätte man die Replays ja auch mit der Online-Highscore über den Server schicken müssen, einen Abspielmodus einbauen müssen, und und und. Ich hab lange genug für das Spiel gebraucht, es war Zeit für neue Projekte. Nunja, vielleicht in der Zukunft.

Ich möchte niemandem was vorschreiben und labere hier nur, weil ich das Thema gern diskutiere. Gute Spiele kann man mit Determinismus bauen oder ohne. Aber Aussagen wie, Floats wären grundsätzlich ungenau oder man könnte sie nicht über Plattformen hinweg konsistent nutzen, kann ich nicht stehen lassen.

Joah, ich hab das Thema ja auch nochmal ausführlicher angesprochen, weil ich darüber diskutieren wollte. Ich hab beim Lesen und darüber Nachdenken jetzt jedenfalls ein besseres Bild davon bekommen, was die Vor- und Nachteile sind. Hat sich daher für mich schon gelohnt.

[Chromanoid]

[*]Wer seine Programme mit Fast Math kompiliert, gibt alle Determinismus-Garantien explizit auf und ist selber schuld, wenn er keine deterministischen Berechnungen mehr hat. Das sind nicht „die ungenauen floats“ oder „Compiler“.

Mag sein, aber wenn du z. B. Unity und dessen Physik-Engine benutzt, dann hast du keinen Einfluss darauf, da Fremdsoftware.
Ich habe selbst mal versucht Unity-Physik deterministisch hinzukriegen. Mit viel Mühe habe ich es innerhalb von einer Plattform geschafft, aber plattformübergreifend war es ein aussichtsloses Unterfangen.

Für unity3d habe ich irgendwann mal kurz das hier versucht:
https://github.com/Kimbatt/unity-deterministic-physics

Die Lösung ist da floating point Operationen selbst zu implementieren und das "neue" DOTS Zeug zu modifizieren... Kommentar des Entwicklers: https://www.reddit.com/r/Unity3D/commen ... t/gnmb24y/

Quake nutzt wie ich das verstehe fixed point Q16.16.

Alles irgendwie schrecklich, Probleme die man glaubt hinter sich zu haben. https://gafferongames.com/post/floating ... terminism/ Kann man bei allen relevanten c/cpp compilern die zusätzlichen Optimierungen, die zu Abweichungen führen ausstellen? Ab Java 17 ist das ja standard und vorher gab's strictfp (auch lustig https://stackoverflow.com/questions/366 ... nt-systems). komisch, dass die CLR das nicht hat?!

Naja, aber so wie ich das verstehe, ist cross device play meist auch rechtlich ein Problem (edit: mmh, dann müsste diese Liste aber kleiner sein https://en.m.wikipedia.org/wiki/List_of ... tform_play). Wenigstens für Aufnahmen wäre es natürlich schön...

[Krishty]

Alles irgendwie schrecklich, Probleme die man glaubt hinter sich zu haben. https://gafferongames.com/post/floating ... terminism/

Danke für die Link-Liste; auf diesen fantastischen Artikel hatte auch schon Unity verwiesen. Er zählt drei Probleme auf:

1. Compiler-Bugs in IEEE754-Optimierungen;
2. Hardware-optimierte Gleitkommabefehle;
3. ganz speziell die x86-FPU.

Punkt 3. ist tot und durch SSE2 ersetzt worden. Heute bekommt man es ohne große Umwege gar nicht mehr hin, dass GCC/MSVC x86-FPU-Code emittieren.

Punkt 1 hat sich enorm verbessert, und das ist wohl hauptsächlich dem Aufkommen von Clang in den 00ern zu verdanken; außerdem großen portablen Projekten wie Google Chrome (ursprünglich GCC, dann für Windows auf MSVC portiert, dann weiter zu Clang).

Punkt 2 erfordert Feingefühl. Die 2008er Revision von IEEE754 hat Reproduzierbarkeit eingefordert. 1.+3. haben dafür gesorgt, dass sich die C-Laufzeitbibliotheken angleichen und Implementierungen bspw. von sin() auf allen großen Plattformen den gleichen Genauigkeits- und Verhaltensstandards entsprechen.

Dummerweise sind aber auch spezielle CPU-Befehle populär geworden (FJCVTZS auf ARM, zahllose SSE-Befehle auf x86), die teils IEEE754 nicht voll implementieren. Und GPUs sowieso nicht. Und da muss man wirklich aufpassen, ob der schnellere CPU-Befehl für 32-Bit Quadratwurzeln einem nicht die Portabilität kaputtmacht … deshalb hat es ja auch ewig gedauert, bis wir auf x86 ein Multiply-Add bekommen haben.

Dazu aus dem Artikel:

Interestingly, SSE with its support for SIMD FP commands actually can make things worse in the standard-violating-algebraic-optimizations department. Specifically, Intel's compiler reportedly has (had?) an optimization which unrolls FP accumulation loops and reorders additions in order to utilize SIMD FP commands (gcc 4 does that, too, but only if you explicitly ask for trouble with -funsafe-math-optimizations or similar). But I wouldn't conclude anything from it, except that automatic vectorization, which is known to work only on the simplest of code snippets, actually doesn't work even on them.

Der Burn war so sick, dass ich nach Stunden immernoch drüber lache 🤣

Also ja: Portable Gleitkommazahlberechnungen auf x86 waren bis ca. 2010 ein Martyrium. Das ist nun 14 Jahre her. Es ist wirklich viel, viel besser geworden.

[Lord Delvin]

Ich selber tue das übrigens nicht. Ich unterbreche die Physik-Berechnung, sobald ein Frame angezeigt werden muss, und hole nach dem Rendern wieder auf. Fühlt sich ein wenig schmutzig an; ändere ich wahrscheinlich, sobald ich Multiplayer realisieren muss.

Ich möchte niemandem was vorschreiben und labere hier nur, weil ich das Thema gern diskutiere. Gute Spiele kann man mit Determinismus bauen oder ohne. Aber Aussagen wie, Floats wären grundsätzlich ungenau oder man könnte sie nicht über Plattformen hinweg konsistent nutzen, kann ich nicht stehen lassen.

Habe letztens in anderem Kontext einen Vortrag zum Thema deterministische Berechnungen, Modularisierung, Tests gehalten und bin glaube nicht durchgedrungen. Nur fragende Gesichter und kaum Gegenfragen.

Replays von deterministischer Physik eignen sich übrigens perfekt als Tests. Du kannst ziemlich hohe Testabdeckung erreichen, indem du literally für ein paar Sekunden die Record-Taste hälst, nach jedem Build ein Replay laufen lässt, und schließlich prüfst, ob die Objektpositionen die selben sind 🤷

Hmmm, ich bin mir wirklich nicht sicher, wie viele Fehler ich in meinem Spiel realistisch durch Unit-Tests jemals hätte finden können. Das Problem ist, dass die allermeisten Änderungen am Code auch das erwartete Ergebnis ändern und damit alle Tests ungültig werden. Und dass ich an einer Stelle A etwas ändere, und dadurch an einer Stelle B, die für etwas komplett unterschiedliches da ist, und deren Unit-Test demnach weiterhin durchlaufen sollte, etwas durch unbewusste Abhängigkeiten kaputt geht, passiert mir extrem selten. Daher habe ich jedesmal wenn ich darüber nachgedacht habe, mich gegen Unit-Tests entschieden.

Das ist jetzt wirklich nicht böse gemeint, aber: Weil du halt nie irgendwas wirklich kompliziertes gemacht hast und Spaß hast rumzubasteln.
Wenn man ein größeres Projekt bauen möchte, dann muss man an den Punkt kommen, an dem man Themen abschließen und vergessen kann.
Das schaffst du anders nicht. Und wenn man dann irgendwann gezwungen ist, irgendwelche fundamentalen Änderungen zu machen, dann will man wissen wo es Probleme gibt.

Der zweite Punkt ist, dass du bei deterministischen Tests auch beliebig oft eine Debugsession auf demselben Test starten kannst und immer wieder in dieselbe Situation kommst.
Das brauchst du insbesondere dann, wenn dir nicht klar ist, wo du was wissen musst und immer wieder feststellst, dass du zu weit gesteppt bist oder eigentlich an ganz anderer Stelle schauen musst, was eigentlich passiert.

In Tyr sind selbst die Objektallokationen bei gleichem Input deterministisch. Wenn ich das nicht hätte wäre ich auch mit einem Zehnmannteam und in Vollzeit nicht so weit gekommen wie ich jetzt bin. Es bringt ja nichts, wenn irgendwas nicht so ist wie man will, das irgendwie gerade zu biegen und dann ist was anderes nicht so wie man will und man hat keine Ahnung warum. Wenn man lange genug spannende Projekte baut, dann kann man die auch nicht mehr überblicken.

[Krishty]

In Tyr sind selbst die Objektallokationen bei gleichem Input deterministisch. Wenn ich das nicht hätte wäre ich auch mit einem Zehnmannteam und in Vollzeit nicht so weit gekommen wie ich jetzt bin. Es bringt ja nichts, wenn irgendwas nicht so ist wie man will, das irgendwie gerade zu biegen und dann ist was anderes nicht so wie man will und man hat keine Ahnung warum. Wenn man lange genug spannende Projekte baut, dann kann man die auch nicht mehr überblicken.

Fun fact: Irgendeine Bibliothek musste mal gepatcht werden, weil deterministische Hash Tables eine Sicherheitslücke darstellen. Wenn der Angreifer dein Hashing kennt, kann er Anfragen geziehlt so auswählen, dass dein O(1)-Zugriff in die Hash Table zu O(n) wird, was je nach Verwendung direkt zu DoS führen kann. Sie mussten einen Zufallszahlengenerator verwenden.

Will nicht bewerten, ob das gut oder schlecht war, aber kam mir bei totalem Determinismus in den Sinn.

Deterministische Heaps möchte man ja auch tunlichst vermeiden, damit Angreifer nicht die Adressen wichtiger Datenstrukturen raten können.

Aber meine Debug-Builds mag ich tatsächlich auch so deterministisch wie möglich.

Edit: Betroffen war 2011 die .NET-Runtime, Tomcat, JRuby, und mehr; Google spuckt aus, dass das ständig in allen möglichen Sprachen und Bibliotheken wiederentdeckt wird.

[EyDu]

Fun fact: Irgendeine Bibliothek musste mal gepatcht werden, weil deterministische Hash Tables eine Sicherheitslücke darstellen. Wenn der Angreifer dein Hashing kennt, kann er Anfragen geziehlt so auswählen, dass dein O(1)-Zugriff in die Hash Table zu O(n) wird, was je nach Verwendung direkt zu DoS führen kann. Sie mussten einen Zufallszahlengenerator verwenden.

Ja, das zog sich quer durch sehr viele Systeme. Eine schöne Übersicht gibt es hier: https://ocert.org/advisories/ocert-2011-003.html.

Besonders stark betroffen war fast alles, was auf Python basiert, da dort jeder Attribut-Zugriff über Hashmaps erfolgt.

[Krishty]

Hier übrigens ein Aufsatz über die Frage nach deterministischem Lerp, die im Video oben offen gelassen wurde: https://blog.pkh.me/p/41-fixing-the-ite ... games.html

[Lord Delvin]

...

Fun fact: Irgendeine Bibliothek musste mal gepatcht werden, weil deterministische Hash Tables eine Sicherheitslücke darstellen. Wenn der Angreifer dein Hashing kennt, kann er Anfragen geziehlt so auswählen, dass dein O(1)-Zugriff in die Hash Table zu O(n) wird, was je nach Verwendung direkt zu DoS führen kann. Sie mussten einen Zufallszahlengenerator verwenden.

Will nicht bewerten, ob das gut oder schlecht war, aber kam mir bei totalem Determinismus in den Sinn.

Deterministische Heaps möchte man ja auch tunlichst vermeiden, damit Angreifer nicht die Adressen wichtiger Datenstrukturen raten können.

Das ist sicher eine erwähnenswerte Reaktion ;)

Mein Ansatz ist weder HashMaps noch Zeiger*werten* zu erlauben die Ausführung zu beeinflussen. In dem Fall geht das relativ einfach mit etwas Disziplin. Wenn Algorithmen von Maps und Sets beeinflusst werden würden wäre das vielleicht nicht durchzuhalten. Timing gibt's bei mir natürlich einfach nicht.

[Schrompf]

Splatter. Auf Koreanisch.

Ich hab tatsächlich noch paar Bugs gefunden und gefixt. Plus Framerate-Begrenzung und ner verbesserten Goldenen Pistole. Einige Spieler*innen hatten sich ja (zu Recht) beschwert, dass die Pistole, wenn man sie mal komplett hat, nix besser macht als die Voll Ausgebaute Pistole. Zu Recht, war halt damals die Zeit alle. Und jetzt hab ich einfach nen zusätzlichen Codepfad eingebaut, so dass sie jetzt in Gold noch bissl heftiger rattert. 10 Jahre nach Release.

Einer der Bugs war so alt wie die C++-Menschheit:

Code: Alles auswählen

assert( ptr != null );
if( ptr != null ) return dummy;

Hat ne Weile funktioniert, im Debug assert und im Release zumindest kein Crash. Dann aber habe ich vor x Jahren mein assert() umgebaut, dass es im Release-Build zu einem assume( !condition ); wird. Bringt was an Performance zum Beispiel in großen Schleifen:

Code: Alles auswählen

assert( (loopcount % 8) == 0 );
for( size_t a = 0; a < loopcount; ++a )

Dann unrollt der Compiler die Schleife partiell und macht immer 8 Aktionen auf einmal, was selbst ohne Autovektorisierung bissl was bringen kann. Aber damit hab ich halt auch aus Versehen meine Not-Aus-Schalter rausoptimiert und mir ein paar Zugriffe auf ungültige Iteratoren eingetreten.

[Krishty]

Niiiice! Die Pistole muss ich mal ausprobieren.

Interessant mit __assume() und for.

[smurfer]

Hallo zusammen,

ich hatte ja schon ein paar Posts weiter vorne von meinem kleinen Raumschiff-Emitter-Experiment berichtet. Die Daten für das Raumschiff (Form, Emitter-Parameter, etc.) wollte ich komfortabler "malen", wobei mir diverse Blender-Exporte oder svg einfach zu umfassend dafür sind. Da ich auch gerne so grundlegende Dinge aus Spaß an der Freude selbst mache und es meinem Lernprozess in Zig nur hilft, habe ich mich für -- nicht hauen ;-) -- XFig entschieden. Das kenne ich, es wird immer noch unterstützt, das Textformat ist simpel (bis auf die Farbpalette und die Logik dahinter), unterstützt Ebenen und es ist sehr gut für meine Zwecke geeignet.

Hier mal ein Vergleich XFig zu Spiel (alles nur ein Testobjekt):

Ein Aspekt, der die Entscheidung zu XFig unterstützt hat, ist, dass sehr einfach Kommentare an Objekte (Shapes) geheftet werden können. Geht bestimmt auch bei Inkscape und Blender, aber wie gesagt, XFig war einfach direkt und simpel.
Als Test habe ich Kreise für die Emitter verwendet, die Position ist durch das Kreiszentrum beschrieben, der Emittertyp als ID und die Ausrichtung (in Grad) im Kommentar. Die restlichen Parameter sind in json hinterlegt, mit der Emittertyp-ID als Referenz.

Sicher nicht die beste Lösung, aber für ein paar wenige Abende Rumprobieren war es aus meiner Sicht keine verschwendete Energie, auch wenn ich irgendwann in Zukunft evtl. das Format/Tool wechseln muss oder möchte.

Beste Grüße

[kristof]

Ich bastele gerade an einem kleinen Node Editor Feature. Bisher ist es nur eine Spielerei. Aber ich stelle mir vor es zum darstellen vom Datenfluss zwischen Systemen in meiner Game Loop zu verwenden. Vielleicht auch zum Zusammenstöpseln von Materials oder Soundeffekten...

(anklicken für ein bewegtes GIF)

Technisch ist es auch ganz interessant, da ich hier C++ nach WebAssembly kompiliere und daraus das HTML DOM manipuliere. Natürlich durch einen dünnen JavaScript Layer. Seitdem WebAssembly External Reference Types unterstützt, ist das plötzlich sehr viel schmerzfreier geworden.