Reproduzierbare Asset-Importe: Identität, Einstellungen und Tool-Versionen erhalten

Festlegen, was reproduzierbar sein muss

Eine Asset-Pipeline wandelt erstellte Dateien in Laufzeitressourcen um. Reproduzierbarkeit setzt voraus, dass sowohl die Eingabe als auch die Transformation bekannt sind. Zwei Entwickelnde können identische Bilddaten besitzen und trotzdem unterschiedliche Laufzeittexturen erzeugen, weil ihre Importeinstellungen voneinander abweichen. Zu entscheiden ist, ob das Projekt identische Ausgabebytes, gleichwertige Ressourceneigenschaften oder ein vereinbartes visuelles Ergebnis verlangt; das sind unterschiedliche Abnahmekriterien.

Referenzidentität erhalten

Unity speichert in der zugehörigen .meta-Datei eine eindeutige Kennung und die Importeinstellungen eines Assets. Wird ein Asset ausserhalb des Editors verschoben, muss diese Datei mitgeführt werden; gehen die Metadaten verloren, können Referenzen brechen. [1] Das Verschieben eines Assets ist daher als Operation zu behandeln, die die Identität bewahren muss, und Änderungen an Metadaten sind zusammen mit Änderungen an den Quelldateien zu prüfen. Ein Dateiname ersetzt die Kennung nicht, über die serialisierte Referenzen auf ein Asset verweisen.

Konfiguration und Cache trennen

Godot legt die Importkonfiguration pro Asset in .import-Dateien neben den Quelldateien ab und empfiehlt, diese Konfiguration zu committen. Die erzeugten Importe liegen unter .godot/imported/ und lassen sich neu generieren. [2] Die Hinweise zur Versionsverwaltung für Godot 4.1 und neuer schliessen die Cache-Daten in .godot/ aus. Ältere Versionen haben andere Ausschlüsse, deshalb sollten die Hinweise verwendet werden, die zur Projektversion passen. [3]

Erforderliche Projekteinstellungen, Import-Skripte und Abhängigkeitsversionen gehören zusammen mit der massgeblichen Quelle abgelegt. Überschreibungen für Zielplattformen sind ebenso bewusst festzuhalten wie die Standardeinstellungen. Der Arbeits-Cache auf einem Entwicklungsrechner sollte nicht die einzige noch vorhandene Kopie einer benötigten Eingabe sein.

Eine Prüfung mit sauberem Import durchspielen

Als Beispiel dient eine Steinmauer-Quelltextur, die sowohl für die Nahansicht als auch für entfernte Kulissen verwendet wird. Ein Rechner importiert sie mit Mipmaps und einem gewählten Kompressionsformat, ein anderer deaktiviert die Mipmaps. Die Prüfsumme des Quellbilds stimmt weiterhin überein, doch das Sampling-Verhalten zur Laufzeit unterscheidet sich.

Für einen vorgeschlagenen Verifikationslauf wird mit einem sauberen Checkout begonnen, bei Bedarf werden die tatsächlichen Inhalte grosser Dateien bezogen, und es kommen die festgelegten Versionen von Engine und Importer zum Einsatz. Danach werden die abgeleiteten Daten neu erzeugt, und für diese Testdatei werden Abmessungen, Anzahl der Mip-Stufen, Format und Material-Referenzen geprüft. Anschliessend wird eine kleine Szene geöffnet, in der die Mauer aus mehreren Entfernungen zu sehen ist. Die vereinbarten Abnahmeeigenschaften werden verglichen, und Abweichungen werden festgehalten. Dies ist ein Beispiel für einen Workflow und keine Aussage darüber, dass ein Import tatsächlich ausgeführt wurde.

Änderungen nachvollziehbar machen

Bei einem Upgrade der Tools sollten zuerst repräsentative Texturen, Meshes und Audiodateien neu erzeugt werden, bevor alles neu gebaut wird. Quell-Hashes, Tool-Versionen und Änderungen an den Importeinstellungen gehören in das Build-Protokoll. Ändern sich die Ausgabebytes, während die vorgesehenen Ressourceneigenschaften stabil bleiben, ist die Ursache zu untersuchen, bevor entschieden wird, ob die Abweichung akzeptabel ist.

Getestet werden sollten neben dem Bearbeiten auch das Umbenennen und Verschieben der Testdatei. Eine reproduzierbare Textur, die sämtliche Material-Referenzen verliert, bedeutet weiterhin eine defekte Pipeline. Cache-Richtlinie, Identitätserhalt und Ausgabeprüfungen sind als getrennte Verantwortlichkeiten zu prüfen.

Quellen

[1] Asset metadata — Unity Technologies.

[2] Godot import process — Godot Engine contributors.

[3] Godot version control systems — Godot Engine contributors.