Wie organisiert und versioniert Ihr Eure Adventures und Assets?

[fernewelten]

Hallo, Foristen,

als ich mit der Adventure-Programmierung anfing, habe ich überhaupt keine Versionskontrolle verwendet.

Statt dessem gab es im Stammordner meines Spiels einen Ordner "_Assets", und darin lagen alle Assets (Sprites, Hintergründe usw.) und ihre jeweiligen Quelldateien. Für Backups und Zwischenstände kopierte ich einfach den gesamten Stammordner mit allen Dateien auf einen USB-Stick in einen Ordner mit passendem Namen ("MeinSpiel/1999-12-04a/" und so weiter). Also die ganze Latte mit allen Programmen, Baukastendateien und allen Assets. Heutzutage haben die Sticks ja so viel Speicherplatz, dass ein einziger Stick Platz für viele Speicherstände bietet, selbst wenn man alle Dateien blind kopiert. Ich lief nie in Gefahr, mehr als ein paar Stunden Arbeit zu verlieren (zumal der Rechner selbst automatische Backups fährt). Für den typischen Gamejam war das jedenfalls ausreichend.

Problem ist nur, inzwischen habe ich eine ganze Reihe Adventures geschrieben, und dieses einfache System ist rapide an seine Grenzen gelangt.

Mittlerweile sieht es so aus:

• Die verschiedenen Abenteuer haben (natürlich) jeweils ihre eigenen Assets
• aber sie teilen sich auch Assets, insbesondere Hintergrundmusik, Sounds, Schriftarten, Cursor-Sprites und Character-Sprites.
• Die Adventures sind in unterschiedlichen Baukastenversionen geschrieben worden.
• Gemeinsam verwendete Assets entwickeln sich in anderer Geschwindigkeit als die Spiele, die sie jeweils verwenden. Diese Assets haben sich zu eigenständigen Einheiten mit separatem Versionsfortschritt entwickelt.
• Spiele und Assets sind in unterschiedlichen Baukastenversionen erstellt. Unterschiedliche Entwicklungsstände lassen sich aber nicht frei mischen. (Das mag ein Spezifikum des Baukastens, AGS, sein). Wenn ich GUIs mit einer bestimmten Baukastenversion abspeichere, dann können ältere Baukastenversionen diese nicht mehr laden. Wenn ich also nicht ein ganzes Spiel hochversionieren will, nur um eine kleine Änderung vorzunehmen, muss ich verschiedene Speicherversionen nachhalten.
• Wegen Platzproblemen sind die gemeinsam verwendeten Assets inzwischen an ganz anderer Stelle als die eigentlichen Spiele gelandet, sogar auf einem anderen Volume.

Einfach „alles speichern“, das ist jetzt also nicht mehr gut genug. Es ist fehleranfällig, wenn man dabei immer an verschiedene Entitäten von verschiedenen Orten denken muss.

Nur die jeweiligen Spiele unter Quellcodeverwaltung (dann wohl git) zu stellen, das reicht auch nicht: Wie halte ich dann die gemeinsam genutzten Assets dazu synchron -- die auch noch an ganz anderer Stelle liegen?

Die gemeinsam genutzten Assets in die jeweiligen Spiele zu kopieren, das ist auch nicht das Wahre. Dann werden die Kopien früher oder später geändert, und die Änderungen gehen bei den Originalen verloren.

Etwas muss her, ich bin mir nur unschlüssig, was konkret.

Mit was für einem System behaltet Ihr denn den den Überblick über Eure Spiele und Assets?

[Uncoolman]

Visionaire verlangt alle Bauteile zusammen in einem Mutterordner. Deshalb kann ich z.B. auf Sound- oder Characterfiles aus anderen Bereichen gar nicht zugreifen. Also hat jedes Spiel immer sämtliche Elemente. Das bedeutet natürlich doppelte Dateien. Wie das mit anderen Programmen ist, weiß ich nicht. Ich meine, dass Unity auch Projekte komplett verwaltet.

Aus Cinema4d kenne ich "Projekt speichern", allerdings werden nur Files übernommen, die tatsächlich in der Arbeitsdatei genutzt werden. Häufig werden jedoch Dateien nur probehalber importiert und getestet, z.B. bei Texturen extrem häufig - diese werden dann nicht übernommen.

Da ich üblicherweise Photoshop-Originaldateien mit Ebenen in der 3D-Datei nicht verwende (oder in Vis gar nicht verwenden kann), muss ich mich um diese wichtigen Quellen immer selbst kümmern.
Dazu gibt es immer einen Ordner "Originaldateien". Das gilt auch für Sound.

Da Cinema dummerweise den Kreuz- und Querimport erlaubt, können durchaus mal Dateien fehlen, weil die ursprünglich von irgendwoher gezogen wurden.

Gemeinsam genutzte Elemente lassen sich so natürlich nicht anpassen. Deshalb ist es durchweg so, dass ich für den jeweiligen Zweck auch unterschiedliche Originalfiles habe (beim Sound z.B. bereits die angepasste Lautstärke für jeden Verwendungszweck - ich bearbeite keine Sounds in Visionaire).

Es scheint so, dass Disziplin nötig ist. Für jedes Spiel ein neues Projekt anlegen. Alle Quellen dort hineinkopieren. Auch die Originaldateien. Ich benenne meine Spiele auch mit Versionsnummer.

Problematisch wird es tatsächlich mit unterschiedlichen Versionen. Als es lange Zeit nur Vis 4.2.5 gab, war das simpel. Aber nun gibt es alle Naselang eine Update-Version, so dass ich für ein (!) Spiel vier oder fünf identische Ordner anlegen muss. Am Ende arbeitet man in der aktuellen Fassung oder in der, die am besten funktioniert. Es ist tatsächlich so, dass einige Spiele nur in 4.2.5 exportiert werden können, in Upgrades oder Updates funktionieren sie anders. Das gibt manchmal Probleme mit 32 oder 64 bit.

Ich habe mich deshalb entschlossen, die meisten Updates zu ignorieren. Jedes Mal gibt es nämlich andere und neue Probleme. Und zurück geht meist nicht, also lege ich immer das Spiel zuallererst in einer alten Version an - denn aufwärtskompatibel geht ja.

[Kikimora]

Bei größeren Projekten nutze ich auch SVN und GIT. Für meine kleinen Jamprojekte und Experimente lohnt sich kein Versionierungssystem.
Was ich bei Unityprojekten allerdings gelegentlich mache, ist, das Projekt als Assetpackage zu exportieren und damit zu sichern.

Sowohl bei Unity als auch Unreal werden die Assets ins Projekt importiert. Bei Unreal könnte ich zwar theoretisch als Quelle eine gemeinsame Assetbibliothek nutzen, aber das bietet sich bei mir nicht an.

Stichwort Assetbibliothek:
Die halte ich komplett separat von allen Projekten und importiere natürlich ins jeweilige Projekt nur, was ich dafür wirklich brauche. Die "Originale" finden sich also stets dort.

[Uncoolman]

Stichwort Assetbibliothek:
Die halte ich komplett separat von allen Projekten und importiere natürlich ins jeweilige Projekt nur, was ich dafür wirklich brauche. Die "Originale" finden sich also stets dort.

Angenommen, ich habe eine Mauertextur. Diese verwende ich z.B. in einem Spiel oder Projekt anders als in einem anderen Spiel oder Projekt. Sie wird jeweils anders bearbeitet (so könnte sie in einem Fall moosbewachsen sein). Ich habe also zwei "Original"dateien. Wenn diese beiden Files zentral verwaltet werden, müsste ich sie dementsprechend benennen, z.B. "Mauer 4 mit Moos für Spiel B" oder so? Ich glaube, beide Methoden haben sowohl Vor- als auch Nachteile, ob nun gesplittet oder zentral...

[Kikimora]

Ich würde die Mauer aus dem Beispiel dann wohl nur als "... mit Moos" bezeichnen. Dann findest du sie auch, solltest du je für ein anderes Spiel erneut eine bemooste Mauer benötigen. Wenn die bemooste Mauer nur in Projekt XY liegt, musst du ggf. ja immer wieder deine Projekte durchwühlen um zu sehen, ob du da irgendwo mal etwas geeignetes hattest.

Aber vermutlich gibt es da einfach nicht das einzige wahre und richtige System.

Apropros:
Was ich grundsätzlich empfehlen kann, ist die Verwendung von Namenskonventionen. Also Dateibenennung mit projektübergreifend einheitlichem System. Beispielsweise T_Name für eine Textur, M_Name für ein Material, oder das ganze im so genannten CamelCase, wo ohne Unterstriche alle Wörter zusammenhängend und jeweils mit Großbuchstaben am Anfang geschrieben werden.

Dass die Assets im jeweiligen Projekt in aussagekräftige Ordner sortiert werden sollten, versteht sich wohl von selbst. Bei Unity sind das typischerweise Ordner wie "Scenes", "Scripts", "Prefabs", "Animations" ... aber das muss ich euch sicher nicht erzählen. Vielleicht guckt hier aber ja mal ein Anfänger rein und nimmt sich noch was mit.

Für die Assetbibliothek bietet sich das jedenfalls auch an. Wenn man sich irgendwo Texturen heruntergeladen hat (beispielsweise von textures.com), sollte man die Namen dort allerdings eher nicht ändern - es hilft meist, wenn noch nachvollziehbar ist, woher eine Textur stammt. Kann man ggf. auch mit zusätzlichen readme.txt files im selben Ordner dokumentieren.
Für die Kategorisierung kann man sich hier ein bisschen was abschauen: https://www.textures.com/library

[Uncoolman]

Da meine Photoshop-Dateien sowieso aus vielen Ebenen bestehen, kann man das „Originalbild“ gar nicht mehr ausmachen. Die meisten Ebenen sind ausgegraut und werden bei Bedarf aktiviert. Somit ist die Nomenklatur ohnehin schwierig - welchen Namen soll die Datei denn bekommen? Deshalb hat es sich bei mir bewährt, solche Originaldateien beim Projekt zu lassen, denn obwohl dieselben Texturen drein sind, so ist doch das Ergebnis stark projektabhängig. Im Texturordner sind zwar alle Texturen gelistet (ich belasse die Textures.com-Namensgebung auch), aber die werden ja immer mal wieder neu zusammengefügt.

Hier müsste man ohnehin fragen, ob nicht die Kategorien für die Originalfiles selbst anders aussehen sollte als für z.B. ein Spiel oder Projekt. Für Visionaire habe ich lange Zeit die 3D-Elemente komplett abgekoppelt bearbeitet - das heißt, der ganze C4d-Kram lag woanders, da ich ja nur die Resultate als PNG- oder Wav-Datei brauche. Außerdem arbeite ich auf mehreren Rechnern.

Bei Visionaire sind ja am Ende bloß die Charakter-Frames, die Hintergründe und die fertigen Sounds ausschlaggebend.

PS Die Einordnung bei Textures.com ist ok, aber obwohl ich mal angefangen habe, das zu übernehmen, gibt es immer Überschneidungen. Auch dort findet man Abweichler in anderen Ordnern. Ist das nun ein Fußboden, eine Mauer oder eine Pflanze oder ein Mauerbewuchs? Inzwischen kommt alles in einen Ordner, und die Suche geht schneller mit Scrollen.

[kanedat]

Nur die jeweiligen Spiele unter Quellcodeverwaltung (dann wohl git) zu stellen, das reicht auch nicht: Wie halte ich dann die gemeinsam genutzten Assets dazu synchron -- die auch noch an ganz anderer Stelle liegen?

Die gemeinsam genutzten Assets in die jeweiligen Spiele zu kopieren, das ist auch nicht das Wahre. Dann werden die Kopien früher oder später geändert, und die Änderungen gehen bei den Originalen verloren.

Generell ist es wichtig zu schauen, welchen Zweck man verfolgen möchte:

1. Grundsätzliches Arbeitsmaterial für zukünftige Projekte (=zentrale Asset-Bibliothek)
2. Aktuelles Arbeitsmaterial
3. Archiv

An dem Aufbau orientiere ich mich grundsätzlich, d.h. es gibt eine zentrale Asset-Bibliothek aus der einzelne Assets in die jeweiligen Projekte kopiert werden. Wichtig dabei ist, dass man Abschluss eines Projekts eine Asset-Bestandsaufnahme macht und Assets in die zentrale Bibliothek überführt. Hierbei muss man schauen, ob es sich um ein neues Asset bzw. aktualisiertes Asset handelt oder nur um eine spezifische Version für das jeweilige Projekt. An der Stelle gibt es keine perfekten, allgemeingültigen Auswahlkriterien, das hängt vom Material ab. (Wenn ich das richtig sehe, dann verfährt Kikimora nach dem selben Prinzip)


Soweit ich das sehe, hast du bisher eine Mischung aus Punkt 1 und 2. Eigentlich wählst du bereits (bis zu einem gewissen Grad) Assets aus und lagerst diese in an einem Ort, aber dieser ist aktiv mit Projekten verknüpft und in erster Linie eine Erweiterung der Projektordner (anstatt einer zentralen Asset-Bibliothek).

Meine Empfehlung wäre (Überraschung, Überraschung) das zu trennen. Mit einer zentralen Asset-Bibliothek hat man sein zukünftiges Arbeitsmaterial an einem Ort gelagert und entfernt Abhängigkeiten (was evtl. anfallende Daten-Umzüge sehr einfach macht). Dabei kann man auch problemlos verschiedene Asset-Versionen lagern, wenn man Namenskonventionen verwendet (simples Beispiel-Schema: Name des Assets - Versionsnummer AGS - Versionsnummer Asset).

Die Frage wäre eben, ob es überhaupt notwendig ist verschiedene Asset-Versionen zentral verfügbar zu halten, da man neue Projekte in der Regel mit dem aktuellen technischen Stand (der Assets) beginnt. Wenn man ständig an verschiedenen Projekten mit verschiedenen AGS-Versionen arbeitet, dann wäre es sinnvoll verschiedene Asset-Versionen in der Asset-Bibliothek zu lagern. Wenn es nur mal vorkommt, dann wäre es sinnvoll nur die neueste Asset-Version in der Asset-Bibliothek zu lagern, weil man die alten Versionen nicht mehr benötigt und die in jeweiligen Projekten liegen bleiben können. (Bei letzterem wäre das vom Prinzip her quasi wie bei github: Master --> Fork --> Pull)

An der Stelle muss eben aufpassen, dass man nicht erst ein Mischmodell in "Asset-Bibliothek" und "Projekte" auftrennt, um im selben Atemzug "Asset-Bibliothek" und "Archiv" zu vermischen. (Im Archiv ist ja wirklich alles und das hast du bereits, wenn du regelmäßig Backup fährst)