Best Practices zur Organisation Ihres Unity-Projekts

Obwohl es keinen einzigen Weg gibt, ein Unity-Projekt zu organisieren, hier sind einige wichtige Empfehlungen:

• Dokumentieren Sie Ihre Benennungsrichtlinien und Ordnerstruktur. Ein Styleguide und/oder eine Projektvorlage erleichtert das Auffinden und Organisieren von Dateien. Wählen Sie, was für Ihr Team funktioniert, und stellen Sie sicher, dass alle damit einverstanden sind.
• Sei konsistent mit deinen Namenskonventionen. Weiche nicht von deinem gewählten Stilhandbuch oder Template ab. Wenn du deine Namensregeln ändern musst, analysiere und benenne deine betroffenen Assets auf einmal um. Wenn die Änderungen eine große Anzahl von Dateien betreffen, ziehe in Betracht, das Update mit einem Skript zu automatisieren.
• Verwende keine Leerzeichen in Datei- und Ordnernamen. Die Befehlszeilentools von Unity haben Probleme mit Pfadnamen, die Leerzeichen enthalten. Verwende CamelCase als Alternative für Leerzeichen.
• Trenne Test- oder Sandbox-Bereiche. Erstelle einen separaten Ordner für nicht-produktive Szenen und Experimente. Unterordner mit Benutzernamen können deinen Arbeitsbereich nach Teammitgliedern unterteilen.
• Vermeide zusätzliche Ordner auf der Root-Ebene. Im Allgemeinen speichere deine Inhaltsdateien im Assets-Ordner. Erstelle keine zusätzlichen Ordner auf der Root-Ebene des Projekts, es sei denn, es ist absolut notwendig.
• Halte deine internen Assets von Drittanbieter-Assets getrennt. Wenn du Assets aus dem Asset Store oder anderen Plugins verwendest, ist es wahrscheinlich, dass sie ihre eigene Projektstruktur haben. Halte deine eigenen Assets getrennt.

Hinweis: Wenn du einen Drittanbieter-Asset oder ein Plugin für dein Projekt modifizierst, kann dir die Versionskontrolle helfen, das neueste Update für das Plugin zu erhalten. Sobald das Update importiert ist, kannst du die Unterschiede durchsehen, um zu sehen, wo deine Modifikationen möglicherweise überschrieben wurden, und sie erneut implementieren.

Obwohl es keine festgelegte Ordnerstruktur gibt, zeigen die folgenden beiden Abschnitte Beispiele dafür, wie du dein Unity-Projekt einrichten könntest. Diese Strukturen basieren beide darauf, Ihr Projekt nach Asset-Typen zu unterteilen.

Die Asset Types-Handbuchseite beschreibt die häufigsten Assets im Detail. Sie können die Template- oder Lernprojekte für weitere Inspiration bei der Organisation Ihrer Ordnerstruktur verwenden. Obwohl Sie nicht auf diese Ordnernamen beschränkt sind, können sie Ihnen einen guten Ausgangspunkt bieten.

Wenn Sie eines der Template- oder Starterprojekte aus dem Unity Hub herunterladen, werden Sie feststellen, dass die Unterordner nach Asset-Typen unterteilt sind. Je nach gewähltem Template sollten Sie Unterordner sehen, die mehrere gängige Assets repräsentieren.

Eine starke Projektstruktur von Anfang an zu definieren, kann Ihnen helfen, später Probleme mit der Versionskontrolle zu vermeiden. Wenn Sie Assets von einem Ordner in einen anderen verschieben, werden viele VCS dies als das Löschen einer Datei und das Hinzufügen einer anderen wahrnehmen, anstatt dass die Datei verschoben wird. Dies verliert die Historie der ursprünglichen Datei.

Plastic SCM kann Datei-Verschiebungen innerhalb von Unity verwalten und die Historie jeder verschobenen Datei bewahren. Es ist jedoch wichtig, dass Sie 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 die gleiche Ordnerstruktur für alle zukünftigen Projekte zu erstellen. Wenn es in einem Editor-Ordner platziert wird, erstellt das folgende Skript einen Stammordner in Assets, der der "PROJECT_NAME"-Variablen entspricht. Dadurch bleibt Ihre eigene Arbeit von Drittanbieter-Paketen getrennt.

Leere Ordner können Probleme mit der Versionskontrolle verursachen, also versuchen Sie, nur Ordner für das zu erstellen, was Sie wirklich benötigen. Mit Git und Perforce werden leere Ordner standardmäßig ignoriert. Wenn solche Projektordner eingerichtet sind und jemand versucht, sie zu committen, wird es nicht funktionieren, bis etwas in den Ordner gelegt wird.

Hinweis: Eine gängige Lösung besteht darin, eine „.keep“-Datei in einen leeren Ordner zu legen. Das reicht aus, damit der Ordner dann in das Repository eingecheckt wird.

Plastic SCM kann leere Ordner verwalten. Verzeichnisse werden von Plastic SCM als Entitäten behandelt, jede mit ihrer eigenen Versionshistorie.

Das ist ein Punkt, den man im Hinterkopf behalten sollte, wenn man in Unity arbeitet. Unity generiert eine .meta-Datei für jede Datei im Projekt, einschließlich Ordner. Mit Git und Perforce kann ein Benutzer die .meta-Datei für einen leeren Ordner leicht einpflegen, aber der Ordner selbst wird nicht unter Versionskontrolle stehen. Wenn ein anderer Benutzer die neuesten Änderungen erhält, wird es eine .meta-Datei für einen Ordner geben, der auf seinem Computer nicht existiert, und Unity wird dann die .meta-Datei löschen. Plastic SCM vermeidet dieses Problem vollständig, indem leere Ordner unter Versionskontrolle aufgenommen werden.

Unity generiert eine .meta-Datei für jede andere Datei im Projekt, und während es normalerweise nicht ratsam ist, automatisch generierte Dateien in die Versionskontrolle aufzunehmen, ist die .meta-Datei ein wenig anders. Der sichtbare Meta-Dateien-Modus sollte im Versionskontrollfenster aktiviert sein (es sei denn, Sie verwenden die integrierten Plastic SCM- oder Perforce-Modi).

Obwohl die .meta-Datei automatisch generiert wird, enthält sie viele Informationen über die Datei, mit der sie verknüpft ist. Das ist üblich für Assets, die Importeinstellungen haben, wie Texturen, Meshes, Audio-Clips usw. Wenn Sie die Importeinstellungen für diese Dateien ändern, werden die Änderungen in die .meta-Datei geschrieben (anstatt in die Asset-Datei). Deshalb committen Sie die .meta-Dateien in Ihr Repository – damit alle mit denselben Dateieinstellungen arbeiten.

Die Einigung auf Standards endet nicht bei der Projektordnerstruktur. Einen spezifischen Namensstandard für alle Ihre Spiel-Assets festzulegen, kann es Ihrem Team erleichtern, an den Dateien des anderen zu arbeiten.

Obwohl es keinen definitiven Namensstandard für GameObjects gibt, beachten Sie die obige Tabelle.

Einzelne, große Unity-Szenen eignen sich nicht gut für die Zusammenarbeit. Teilen Sie Ihre Levels in mehrere kleinere Szenen auf, damit Künstler und Designer reibungslos an einem einzelnen Level zusammenarbeiten können, während das Risiko von Konflikten minimiert wird.

Zur Laufzeit kann Ihr Projekt Szenen additiv mit SceneManager und LoadSceneAsync unter Verwendung des Parameters LoadSceneMode.Additive laden.

Es ist eine bewährte Praxis, die Arbeit in Prefabs aufzuteilen, wann immer dies möglich ist, und die Leistung von verschachtelten Prefabs zu nutzen. Wenn Sie später Änderungen vornehmen müssen, können Sie das Prefab ändern, anstatt die Szene, in der es sich befindet, um Konflikte mit anderen, die an der Szene arbeiten, zu vermeiden. Änderungen an Prefabs sind oft einfacher zu lesen, wenn man einen Diff unter Versionskontrolle durchführt.

Falls Sie mit einem Szenenkonflikt enden, hat Unity auch ein integriertes YAML-Tool (eine menschenlesbare Datenserialisierungssprache), das zum Zusammenführen von Szenen und Prefabs verwendet wird. Für weitere Informationen siehe Smart merge in der Unity-Dokumentation.

Voreinstellungen ermöglichen es Ihnen, den Standardzustand von fast allem in Ihrem Inspektor anzupassen. Das Erstellen von Voreinstellungen ermöglicht es Ihnen, die Einstellungen ausgewählter Komponenten oder Assets zu kopieren, sie als eigene Assets zu speichern und diese gleichen Einstellungen später auf andere Elemente anzuwenden.

Verwenden Sie Voreinstellungen, um Standards durchzusetzen oder angemessene Standardwerte auf neue Assets anzuwenden. Sie können dazu beitragen, konsistente Standards in Ihrem Team sicherzustellen, damit häufig übersehene Einstellungen die Leistung Ihres Projekts nicht beeinträchtigen.

Klicken Sie auf das Voreinstellungs-Symbol oben rechts in der Komponente. Um die Voreinstellung als Asset zu speichern, klicken Sie auf Aktuelle speichern unter… und wählen Sie dann eine der verfügbaren Voreinstellungen aus, um eine Reihe von Werten zu laden.

Hier sind einige andere praktische Möglichkeiten, Voreinstellungen zu verwenden:

• Erstellen Sie ein GameObject mit Standardwerten: Ziehen Sie ein Voreinstellungs-Asset in die Hierarchie, um ein neues GameObject mit einer entsprechenden Komponente zu erstellen, die Voreinstellungswerte enthält.
• Ordnen Sie einen bestimmten Typ einer Voreinstellung zu: Geben Sie im Voreinstellungs-Manager (Projekteinstellungen > Voreinstellungs-Manager) eine oder mehrere Voreinstellungen pro Typ an. Das Erstellen einer neuen Komponente wird dann standardmäßig auf die angegebenen Voreinstellungswerte eingestellt.
• Pro-Tipp: Erstellen Sie mehrere Voreinstellungen pro Typ und verlassen Sie sich auf den Filter, um die richtige Voreinstellung nach Namen zuzuordnen.
• Speichern und Laden der Manager-Einstellungen: Verwenden Sie Voreinstellungen für ein Manager-Fenster, damit die Einstellungen wiederverwendet werden können. Wenn Sie beispielsweise planen, dieselben Tags und Ebenen oder Physikeinstellungen erneut anzuwenden, können Voreinstellungen die Einrichtungszeit für Ihr nächstes Projekt verkürzen.

Kodierungsstandards halten die Arbeit Ihres Teams ebenfalls konsistent, was es Entwicklern erleichtert, zwischen verschiedenen Bereichen Ihres Projekts zu wechseln. Es gibt hier erneut keine in Stein gemeißelten Regeln. Sie müssen entscheiden, was für Ihr Team am besten ist – aber sobald Sie entschieden haben, stellen Sie sicher, dass Sie dabei bleiben.

Als Beispiel können Namensräume Ihren Code präziser organisieren. Sie ermöglichen es Ihnen, Module innerhalb Ihres Projekts zu trennen und Konflikte mit Drittanbieter-Assets zu vermeiden, bei denen Klassennamen möglicherweise wiederholt werden.

Hinweis: Wenn Sie Namensräume in Ihrem Code verwenden, unterteilen Sie Ihre Ordnerstruktur nach Namensraum für eine bessere Organisation.

Ein Standardkopf wird ebenfalls empfohlen. Das Einfügen eines Standardkopfes in Ihre Codevorlage hilft Ihnen, den Zweck einer Klasse, das Erstellungsdatum und sogar den Ersteller zu dokumentieren; im Wesentlichen alle Informationen, die in der langen Geschichte eines Projekts leicht verloren gehen könnten, selbst bei Verwendung von Versionskontrolle.

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

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

Die Standard-MonoBehaviour-Vorlage ist diese hier: 81-C# Script-NewBehaviourScript.cs.txt

Es gibt auch Vorlagen für Shader, andere Verhaltensskripte und Assembly-Definitionen.

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

Sie können auch die Standard-Skriptvorlagen direkt für alle Projekte ändern, aber stellen Sie sicher, dass Sie die Originale sichern, bevor Sie Änderungen vornehmen. Jede Version von Unity hat ihren eigenen Vorlagenordner, daher müssen Sie beim Aktualisieren auf eine neue Version 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# gibt den eingegebenen Dateinamen oder den Standarddateinamen an (zum Beispiel NewBehaviourScript).
• #NOTRIM# stellt sicher, dass die Klammern eine Zeile Leerraum enthalten.

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

Verwenden Sie die Kopfzeile im folgenden Skriptbeispiel innerhalb 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, dem es ursprünglich gehörte, anzeigt. Dies ist nützlich, um den Code in zukünftigen Projekten wiederzuverwenden.