Obwohl es keine einheitliche Methode zur Organisation eines Unity-Projekts gibt, werden hier einige wichtige Empfehlungen gegeben:

• Dokumentieren Sie Ihre Benennungskonventionen und Ihre Ordnerstruktur. Ein Styleguide und/oder eine Projektvorlage erleichtern das Auffinden und Organisieren von Dateien. Entscheiden Sie sich für das, was für Ihr Team am besten geeignet ist, und sorgen Sie dafür, dass alle Beteiligten damit einverstanden sind.
• Seien Sie konsistent mit Ihren Namenskonventionen. Weichen Sie nicht von den von Ihnen gewählten Stilrichtlinien oder Vorlagen ab. Wenn Sie Ihre Benennungsregeln ändern müssen, analysieren und benennen Sie die betroffenen Assets auf einmal um. Wenn die Änderungen eine große Anzahl von Dateien betreffen, sollten Sie die Aktualisierung mithilfe eines Skripts automatisieren.
• Verwenden Sie keine Leerzeichen in Datei- und Ordnernamen. Die Kommandozeilentools von Unity haben Probleme mit Pfadnamen, die Leerzeichen enthalten. Verwenden Sie CamelCase als Alternative für Leerzeichen.
• Separate Test- oder Sandkastenbereiche. Erstellen Sie einen separaten Ordner für nicht produktive Szenen und Experimente. Unterordner mit Benutzernamen können Ihren Arbeitsbereich nach Teammitgliedern unterteilen.
• Vermeiden Sie zusätzliche Ordner auf der Stammebene. Im Allgemeinen sollten Sie Ihre Inhaltsdateien im Ordner Assets speichern. Erstellen Sie keine zusätzlichen Ordner auf der Stammebene des Projekts, es sei denn, es ist absolut notwendig.
• Trennen Sie Ihre internen Vermögenswerte von denen Dritter. Wenn Sie Assets aus dem Asset Store oder andere Plug-ins verwenden, haben diese wahrscheinlich ihre eigene Projektstruktur. Halten Sie Ihr eigenes Vermögen getrennt.

Hinweis Wenn Sie ein Asset oder ein Plug-in eines Drittanbieters für Ihr Projekt ändern, kann Ihnen die Versionskontrolle dabei helfen, das neueste Update für das Plug-in zu erhalten. Sobald die Aktualisierung importiert ist, können Sie in der Diff-Datei nachsehen, wo Ihre Änderungen überschrieben wurden, und sie neu implementieren.

Es gibt zwar keine feste Ordnerstruktur, aber die folgenden beiden Abschnitte zeigen Beispiele, wie Sie Ihr Unity-Projekt einrichten können. Diese Strukturen basieren beide auf der Aufteilung Ihres Projekts nach Anlagentyp.

Auf der Handbuchseite Asset-Typen werden die gebräuchlichsten Assets ausführlicher beschrieben. Sie können die Vorlage oder die Lernprojekte als weitere Inspiration für die Organisation Ihrer Ordnerstruktur verwenden. Sie sind zwar nicht auf diese Ordnernamen beschränkt, aber sie können Ihnen einen guten Ausgangspunkt bieten.

Wenn Sie eines der Vorlagen- oder Starter-Projekte aus dem Unity Hub herunterladen, werden Sie feststellen, dass die Unterordner nach Asset-Typ aufgeteilt sind. Je nach gewählter Vorlage sollten Sie Unterordner sehen, die mehrere gemeinsame Assets darstellen.

Wenn Sie von Anfang an eine solide Projektstruktur festlegen, können Sie spätere Probleme mit der Versionskontrolle vermeiden. Wenn Sie Assets von einem Ordner in einen anderen verschieben, sehen viele VCS dies als Löschen einer Datei und Hinzufügen einer anderen an, anstatt die Datei zu verschieben. Dadurch geht der Verlauf der Originaldatei verloren.

Plastic SCM kann Dateiverschiebungen innerhalb von Unity verarbeiten und den Verlauf jeder verschobenen Datei aufbewahren. Es ist jedoch wichtig, dass Sie die Dateien im Editor verschieben, damit die .meta-Datei zusammen mit der Asset-Datei verschoben wird.

Sobald Sie sich für eine Ordnerstruktur für Ihre Projekte entschieden haben, verwenden Sie ein Editor-Skript, um die Vorlage wiederzuverwenden und dieselbe Ordnerstruktur für alle weiteren Projekte zu erstellen. Wenn es in einem Editor-Ordner platziert wird, erstellt das unten stehende Skript einen Stammordner in Assets, der der Variable "PROJECT_NAME" entspricht. Auf diese Weise bleibt Ihre eigene Arbeit von den Paketen Dritter getrennt.

Bei leeren Ordnern besteht die Gefahr, dass es zu Problemen in der Versionskontrolle kommt, daher sollten Sie nur Ordner für das erstellen, was Sie wirklich benötigen. Bei Git und Perforce werden leere Ordner standardmäßig ignoriert. Wenn solche Projektordner eingerichtet werden und jemand versucht, sie zu übertragen, funktioniert das nicht, bis etwas in den Ordner gelegt wird.

Hinweis Eine übliche Abhilfe besteht darin, eine ".keep"-Datei in einem leeren Ordner abzulegen. Dies reicht aus, damit der Ordner in das Repository übertragen wird.

SCM aus Kunststoff kann leere Mappen verarbeiten. Verzeichnisse werden von Plastic SCM als Entitäten behandelt, denen jeweils ein eigener Versionsverlauf zugeordnet ist.

Dies ist ein Punkt, den man bei der Arbeit in Unity im Auge behalten sollte. Unity generiert eine .meta-Datei für jede Datei im Projekt, einschließlich Ordnern. Mit Git und Perforce kann ein Benutzer einfach die .meta-Datei für einen leeren Ordner übertragen, aber der Ordner selbst landet nicht in der Versionskontrolle. Wenn ein anderer Benutzer die neuesten Änderungen erhält, gibt es eine .meta-Datei für einen Ordner, der auf seinem Rechner nicht existiert, und Unity löscht dann die .meta-Datei. Plastic SCM umgeht dieses Problem, indem es leere Ordner in die Versionskontrolle einbezieht.

Unity generiert eine .meta-Datei für jede andere Datei innerhalb des Projekts, und obwohl es normalerweise nicht ratsam ist, automatisch generierte Dateien in die Versionskontrolle einzubeziehen, ist die .meta-Datei ein wenig anders. Der Modus Sichtbare Metadateien sollte im Versionskontrollfenster aktiviert sein (es sei denn, Sie verwenden die eingebauten Modi Plastic SCM oder Perforce).

Die .meta-Datei wird zwar automatisch generiert, enthält aber viele Informationen über die Datei, mit der sie verknüpft ist. Dies ist häufig bei Assets der Fall, die über Importeinstellungen verfügen, wie Texturen, Meshes, Audioclips usw. Wenn Sie die Importeinstellungen für diese Dateien ändern, werden die Änderungen in die .meta-Datei (und nicht in die Asset-Datei) geschrieben. Deshalb übergeben Sie die .meta-Dateien an Ihr Repository, damit alle mit denselben Dateieinstellungen arbeiten.

Die Einigung auf Standards hört nicht bei der Projektordnerstruktur auf. Die Festlegung eines bestimmten Benennungsstandards für alle Ihre Spielelemente kann Ihrem Team die Arbeit in den Dateien der anderen erleichtern.

Obwohl es keinen endgültigen Standard für die Benennung von GameObjects gibt, sollte man sich die obige Tabelle ansehen.

Einzelne, große Unity-Szenen eignen sich nicht gut für die Zusammenarbeit. Teilen Sie Ihre Ebenen in mehrere kleinere Szenen auf, damit Künstler und Designer reibungslos an einer einzigen Ebene zusammenarbeiten können und das Risiko von Konflikten minimiert wird.

Zur Laufzeit kann Ihr Projekt Szenen additiv laden, indem Sie SceneManager mit LoadSceneAsync verwenden und den Parameter LoadSceneMode.Additive mode übergeben.

Wann immer es möglich ist, sollten Sie die Arbeit in Prefabs aufteilen und die Vorteile von verschachtelten Prefabs nutzen. Wenn Sie später Änderungen vornehmen müssen, können Sie das Prefab und nicht die Szene, in der es sich befindet, ändern, um Konflikte mit anderen Personen, die an der Szene arbeiten, zu vermeiden. Vorgefertigte Änderungen sind oft leichter zu lesen, wenn man einen Vergleich unter Versionskontrolle durchführt.

Für den Fall, dass es zu einem Szenenkonflikt kommt, verfügt Unity über ein eingebautes YAML-Tool (eine für Menschen lesbare Datenserialisierungssprache), mit dem sich Szenen und Prefabs zusammenführen lassen. Weitere Informationen finden Sie unter Intelligente Zusammenführung in der Unity-Dokumentation.

Mithilfe von Voreinstellungen können Sie den Standardzustand von fast allen Elementen in Ihrem Inspector anpassen. Mit der Erstellung von Vorgaben können Sie die Einstellungen ausgewählter Komponenten oder Assets kopieren, sie als eigene Assets speichern und diese Einstellungen später auf andere Elemente anwenden.

Verwenden Sie Voreinstellungen, um Standards durchzusetzen oder sinnvolle Standardwerte auf neue Assets anzuwenden. Sie können dazu beitragen, einheitliche Standards in Ihrem Team zu gewährleisten, so dass häufig übersehene Einstellungen die Leistung Ihres Projekts nicht beeinträchtigen.

Klicken Sie auf das Voreinstellungssymbol oben rechts in der Komponente. Um die Voreinstellung als Asset zu speichern, klicken Sie auf Aktuell speichern unter... und wählen dann eine der verfügbaren Voreinstellungen, um einen Satz von Werten zu laden.

Hier finden Sie einige weitere praktische Möglichkeiten zur Verwendung von Voreinstellungen:

• Erstellen Sie ein GameObject mit Standardeinstellungen: Ziehen Sie ein Preset-Asset in die Hierarchie, um ein neues GameObject mit einer entsprechenden Komponente zu erstellen, die Preset-Werte enthält.
• Verknüpfen Sie einen bestimmten Typ mit einer Voreinstellung: Geben Sie im Voreinstellungsmanager(Projekteinstellungen > Voreinstellungsmanager) eine oder mehrere Voreinstellungen pro Typ an. Bei der Erstellung einer neuen Komponente werden dann standardmäßig die angegebenen Voreinstellungswerte verwendet.
• Profi-Tipp: Erstellen Sie mehrere Voreinstellungen pro Typ, und verlassen Sie sich darauf, dass der Filter die richtige Voreinstellung anhand des Namens zuordnet.
• Speichern und Laden von Managereinstellungen: Verwenden Sie Voreinstellungen für ein Managerfenster, damit die Einstellungen wiederverwendet werden können. Wenn Sie beispielsweise planen, dieselben Tags und Ebenen oder Physikeinstellungen erneut anzuwenden, können Sie mit Voreinstellungen die Einrichtungszeit für Ihr nächstes Projekt reduzieren.

Durch Kodierungsstandards wird die Arbeit Ihres Teams konsistent gehalten, was es für die Entwickler einfacher macht, zwischen verschiedenen Bereichen Ihres Projekts zu wechseln. Auch hier sind die Regeln nicht in Stein gemeißelt. Sie müssen entscheiden, was für Ihr Team das Beste ist - aber wenn Sie sich entschieden haben, sollten Sie dabei bleiben.

Namespaces können zum Beispiel Ihren Code genauer organisieren. Sie ermöglichen es Ihnen, Module innerhalb Ihres Projekts zu trennen und Konflikte mit Drittanbieter-Assets zu vermeiden, bei denen sich die Klassennamen wiederholen könnten.

Hinweis Wenn Sie Namespaces in Ihrem Code verwenden, sollten Sie Ihre Ordnerstruktur zur besseren Organisation nach Namespaces aufteilen.

Eine Standardkopfzeile wird ebenfalls empfohlen. Durch die Aufnahme einer Standardkopfzeile in Ihre Codevorlage können Sie den Zweck einer Klasse, das Erstellungsdatum und sogar den Ersteller dokumentieren; im Grunde alle Informationen, die in der langen Geschichte eines Projekts leicht verloren gehen können, selbst wenn Sie eine Versionskontrolle verwenden.

Unity verwendet eine Skriptvorlage, aus der gelesen wird, wenn Sie ein neues MonoBehaviour im Projekt erstellen. Jedes Mal, wenn Sie ein neues Skript oder einen Shader erstellen, verwendet Unity eine Vorlage, die in %EDITOR_PATH%\Data\Resources\ScriptTemplates gespeichert ist:

• Windows C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Hub/Editor/[version]/Unity/Unity.app/Contents/ Resources/ScriptTemplates

Die Standardvorlage für MonoBehaviour ist diese: 81-C# Script-NewBehaviourScript.cs.txt

Außerdem gibt es Vorlagen für Shader, andere Verhaltensskripte und Baugruppendefinitionen.

Für projektspezifische Skriptvorlagen erstellen Sie einen Ordner Assets/ScriptTemplates und kopieren die Skriptvorlagen in diesen Ordner, um die Standardeinstellungen zu überschreiben.

Sie können die Standard-Skriptvorlagen auch direkt für alle Projekte ändern, aber stellen Sie sicher, dass Sie die Originale sichern, bevor Sie irgendwelche Änderungen vornehmen. Jede Version von Unity hat ihren eigenen Vorlagenordner. Wenn Sie also auf eine neue Version aktualisieren, müssen Sie die Vorlagen erneut ersetzen. Das folgende Codebeispiel zeigt, wie die ursprüngliche 81-C# Script-NewBehaviourScript.cs.txt-Datei aussieht.

Im folgenden Beispiel gibt es zwei Schlüsselwörter, die hilfreich sein könnten:

• #SCRIPTNAME# bezeichnet den eingegebenen Dateinamen oder den Standard-Dateinamen (z. B. NewBehaviourScript).
• #NOTRIM# stellt sicher, dass die Klammern eine Zeile mit Leerzeichen enthalten.

Sie können Ihre eigenen Schlüsselwörter verwenden und sie durch ein Editor-Skript ersetzen, um die Methode OnWillCreateAsset zu implementieren.

Verwenden Sie die Kopfzeile im folgenden Skriptbeispiel in Ihrer Skriptvorlage. Auf diese Weise wird jedes neue Skript mit einer Kopfzeile erstellt, die das Datum, den Benutzer, der es erstellt hat, und das Projekt, zu dem es ursprünglich gehörte, enthält. Dies ist nützlich für die Wiederverwendung des Codes in zukünftigen Projekten.