Skalierung von Unity-Workflows: Lernen aus mittelgroßen bis großen Projekten

Dieser Blogbeitrag ist der erste einer Reihe von Mega Cat Studios, in der sie ihr Unity-Know-how und Lösungen für reale Herausforderungen in der kommerziellen Spieleentwicklung teilen. Wir hoffen, dass Sie einige großartige Tipps aufschnappen!

Sie haben eine großartige Idee und der Code fliegt so schnell wie Sie tippen können. Mit jedem Commit nimmt eine neue Funktion Gestalt an. Aber es ist die Geschwindigkeit, mit der Ihre Ideen entstehen, die bald dazu führen könnte, dass Sie ein großes, fehlerhaftes Chaos vor sich sehen.

Bei Mega Cat Studios beginnen wir alle unsere Projekte mit Leidenschaft, daher verstehen wir die Anziehungskraft, schnell und locker zu spielen und die Dinge so schnell wie möglich zu erledigen. Für einen Prototyp ist dieser Ansatz in Ordnung, und tatsächlich empfehlen wir ihn! Ein kluger Entwickler weiß, wann er die Iterationsgeschwindigkeit und wann er die Stabilität priorisieren soll. Denn wenn Sie die Prototypenphase verlassen, wird dieser „schnelle und lockere“ Ansatz zu einer Belastung.

Wir haben diesen Übergang schon viele Male überlebt Mega Cat Studios, und bei jedem Projekt lernen wir etwas Neues. Wir möchten einige der Lektionen teilen, die wir gelernt haben, um unser neuestes Projekt, Backyard Baseball, startbereit zu machen.

Lektion 1: Struktur für Skalierung

Skalierungsprobleme werden selten durch schlechten Code verursacht; stattdessen entstehen sie häufiger aufgrund einer ungeplanten Architektur. Wenn ein Entwickler oder Künstler ein Asset nicht innerhalb von 10 Sekunden findet, muss der Workflow geändert werden. Einige Tipps zur Einrichtung Ihres Projekts für die Skalierung umfassen:

• Organisieren nach Typ und Zweck: Wir gruppieren nach Typ und dann nach Zweck. Der Typ umfasst Kategorien wie Kunst, Code und Audio. Der Zweck ist, wofür sie verwendet werden. Eine intuitive Organisation reduziert die Einarbeitungszeit; ein neuer Künstler sollte genau wissen, wo ein "Character Idle"-Sprite hingehört, ohne nachzufragen.
• Halten Sie Szenen einfach: Wir haben die "Mega-Szene" verworfen und stattdessen kleinere Szenen gewählt, wie eine Hauptszene, die gespeicherte Daten und kritische Systeme enthält, zusammen mit einem Titelbildschirm und Baseball-Diamant-Szenen, die je nach dem, ob der Spieler in einem Match ist, additiv geladen werden. Ebenso verwenden wir Prefabs für eigenständige Funktionen, sodass die Änderungen weniger wahrscheinlich in der Szenen-Datei, die sie enthält, serialisiert werden. Dies ermöglicht es einem Künstler, an der Umgebung zu arbeiten, während ein Designer das Gameplay im selben "Level" anpasst, ohne Dateikonflikte (mehr dazu später).
• Richten Sie das Addressables-System ein: Anstatt der herkömmlichen Ressourcenordner verwenden wir das Addressables-System , um Assets nur bei Bedarf zu laden und den Speicherverbrauch gering zu halten. Darüber hinaus ist das Laden eines Assets mit seinem Addressable-Schlüssel klarer und weniger fehleranfällig als das Laden über einen Dateipfad zu einem bestimmten Ort im Ressourcenordner.

Das Schwierige ist nicht, diese bewährten Verfahren zu verstehen. Es ist die Verpflichtung, sie von Anfang an einzuhalten und diese Disziplin auch nach Jahren aufrechtzuerhalten.

Wissen Sie, in welcher Entwicklungsphase Sie sich befinden und was Sie in dieser Phase priorisieren.

„In der Prototyping-Phase, da es kaum Code gibt, ist es in Ordnung, es zuerst funktionsfähig zu machen, bevor es modular wird“, sagt Paolo Roxas, ein Entwickler bei Backyard Baseball. „Wir möchten sehen, wie sich das Projekt entwickelt, bevor wir es komplexer machen.“

Lektion 2: Arbeiten Sie mit Unity, nicht gegen sie

„Es gibt nichts Mächtigeres, als Bausteine zu erstellen – sei es Komponenten, ScriptableObjectsoder benutzerdefinierte Klassen – die zielgerichtet, prägnant und eigenständig sind“, sagt David Chávez Armenteros, Head of Engineering bei Mega Cat Studios. Unity steht für Modularität. Um flexibel zu bleiben, befolgen wir drei klassische Prinzipien:

1. Einzelverantwortung: Jedes Skript oder jede Klasse sollte eine klar definierte Rolle haben.

2. Lose Kopplung: Systeme sollten über Schnittstellen oder Ereignisse und nicht über direkte Verweise interagieren, und zwar nur dann, wenn dies angemessen ist. Wir empfehlen, Abhängigkeiten zwischen Systemen zu grafisch darzustellen, bevor Sie sie im Code implementieren, um eine zyklische oder verwobene Architektur zu vermeiden.

3. Plug and Play: Kombinieren Sie kleine, fokussierte Einheiten, um komplexes Verhalten zu erzeugen, anstatt sich auf umfangreiche "Gott"-Skripte zu verlassen.

Lektion 3: Nutzen Sie Einschränkungen, um sich zu befreien

Assembly-Definitionen (AsmDefs) sind C#-Konstrukte, die Ihren Code gruppieren. Ihr beworbener Vorteil sind reduzierte Kompilierzeiten, aber ihre geheime Superkraft ist die Durchsetzung von Modularität.

Nico Gaudenzi, leitender Entwickler und Spaghetti-Code-Hasser, schwört darauf.

„In Backyard Baseball, befinden sich die Eingabeebene und die Spielebene in verschiedenen DLLs. Das Gameplay ist völlig unabhängig von den Eingabedetails.“

Dies erspart den Ingenieuren sich selbst, indem jede Abhängigkeit zu einer berechneten Entscheidung wird. Wenn wir wirklich müssten, könnten wir das gesamte Eingabe-System – von der Gamepad-Handhabung bis zum Netcode – neu schreiben, ohne das Risiko einzugehen, die Spielerphysik oder das KI-Verhalten zu beeinträchtigen. Wahrscheinlicher ist, dass ein Ingenieur in einem einzigen Bereich des Codebases arbeiten kann, ohne versehentlich Änderungen an einem anderen System auszulösen, und die Menge an Code reduziert wird, die ein Entwickler für die Implementierung von Funktionen und die Behebung von Fehlern gerade halten muss.

Lektion 4: Testen Sie intelligenter, nicht härter

Wenn Projekte wachsen, kann der „Dominoeffekt“ übernehmen: Eine kleine Änderung hier bricht etwas dort. Gute Architektur ist sehr hilfreich, aber sie ist keine Wunderwaffe.

Bevor Änderungen an Funktionen die Pfoten unserer geschätzten Qualitätssicherungskater für manuelle Tests erreichen, wird das Spiel in einer Reihe automatisierter Unit-Tests gründlich analysiert.

„Tests funktionieren wie eine Liste von Anforderungen“, sagt Nico. „Sie beschreiben, was erwartet wird, und bieten wichtige Anwendungsfälle.“

Wenn ein Charakter in Backyard Baseball einen Fastball wirft, eine Base stiehlt oder einen Home Run schlägt, gibt es spezifische Spielergebnisse, die wir erreichen möchten, wie zum Beispiel sicherzustellen, dass der Ball mit einer Geschwindigkeit fliegt, die für den Wurf authentisch erscheint, die Timing des Läufers mit den Diebstahlmechaniken der Base übereinstimmt oder die Feldspieler korrekt auf einen Treffer reagieren. Die Figur muss korrekt mit dem Boden kollidieren, der Ball muss mit der richtigen Geschwindigkeit bewegt werden, und feinere Systeme wie Spieler-Controller-Flags, die Aktionen wie Anlaufen, Schwingen oder Sprinten zwischen den Bases verfolgen, müssen funktionieren.

Wenn wir eine Anpassung an Pablo Sanchezs Kraft vornehmen oder, was noch kritischer ist, den gemeinsamen Code anpassen, der die Schwingungen des Schlägers steuert, müssen wir sicherstellen, dass jede Interaktion, von der Kontaktzeit bis zur Flugbahn des Balls, im gesamten Spiel konsistent ist.

Oft ist es etwas, womit man nicht rechnet, das den ganzen Test so wichtig macht.

Mit diesem in unseren Workflow integrierten System werden wir im Moment eines spezifischen Anforderungsausfalls darauf aufmerksam, was die Test- und Fehlersuchsitzungen reduziert, die so zeitaufwendig sind wie das Finden einer Nadel im Heuhaufen.

Unity's Test Runner funktioniert am effektivsten, wenn Ihre Systeme modular sind, was ein weiterer Grund dafür ist, warum wir Assembly-Definitionen verwenden.

Lektion 5: Bringen Sie Ihre Assets in Schwung

"Fehler zu machen ist menschlich; zu vergeben, göttlich."

Aber Systeme einzurichten, um menschliche Fehler von vornherein zu vermeiden, ist geradezu legendär.

Nach Stunden des Programmierens und Debuggens ist es unvermeidlich, dass ein paar gerötete Entwickler ein paar Fehlklicks machen oder versehentlich Änderungen im Repository vornehmen, die eigentlich nur vorübergehend gedacht waren. Obwohl es vergebungswürdig ist (ich sage das als einer der gelegentlich geröteten), könnte ein Asset mit schlecht konfigurierten Importeinstellungen enorme Konsequenzen haben. Und da viele Entwickler an leistungsstarken Maschinen arbeiten, ist das Alarmszenario, dass das Leistungsproblem erst später bemerkt wird, z. B. wenn eine Stadion-Szene mit Charakteren, Animationen und Effekten zu Verlangsamungen oder Instabilität auf Hardware mit geringeren Spezifikationen führt.

Um dieses Risiko zu verringern, könnten Sie beschränken, wer Zugriff auf Assets hat, aber dies führt zu einem Engpass, da der Spielinhalt aus vielen Gründen angepasst werden muss:

• Das Modell ist zu groß, um mit der Kameraeinstellung zu passen.
• Dieser Audioclip hat eine geringere Lautstärke, daher ist ein bestimmter Effekt erforderlich.
• Jede Textur muss jetzt angepasst werden, da sich der Shader geändert hat.

In einem Spiel wie Backyard Baseball, wo die visuelle Identität von höchster Bedeutung ist, erhalten Modelle und VFX Hunderte von Anpassungen, während wir den Look und das Gefühl vor der Veröffentlichung genau richtig einstellen.

„Keine technischen Spezifikationen können die Tatsache vermeiden, dass eine Vielzahl von Inhalten bedeutet, dass man sich mit geringfügigen, aber bedeutenden Unterschieden zwischen verschiedenen Assets auseinandersetzen muss“, sagt Nico.

Automatisierungen helfen hier ebenfalls:

• AssetPostprocessor: Wir schreiben benutzerdefinierte Importlogik, die Projektnormen durchsetzt.
• OnValidate: Wir verwenden die OnValidate-Methode, um fehlende Referenzen im Editor zu melden, die immer vor dem Build ausgelöst wird.

Lassen Sie sich jedoch von all diesem Automatisierungswahn nicht von einfachen manuellen Korrekturen ablenken, wenn diese schneller sind.

„Verwenden Sie niemals 10 Tage für die Automatisierung einer Aufgabe, die manuell nur 10 Minuten dauert“, warnt David.

Lektion 6: Beherrschen Sie das menschliche Element (Zusammenarbeit)

Versionskontrolle Systeme wie Git gehören zu den ersten Dingen, die einem in den Sinn kommen, wenn man täglich Hunderte von Änderungen von Dutzenden von Entwicklern koordinieren muss. David befürwortet diese bewährten Methoden für alle unsere Projekte bei Mega Cat:

• Kleine, atomare Änderungen: Vermeiden Sie „Mega-Commits“, die viele Systeme auf einmal betreffen. Isolieren Sie die Arbeit an einzelnen Feature-Branches, bis sie stabil und überprüft sind. Bewahren Sie einzelne Änderungen in einzelnen Commits auf, um eine gut dokumentierte Versionsgeschichte zu erhalten, die auch das Cherry-Picking und andere Git-Zaubertricks bei Bedarf erleichtert.
• Tägliche Zusammenführungen aus dem Hauptzweig: Halten Sie Feature-, Abteilungs- und langlebige Branches auf dem neuesten Stand mit dem Hauptzweig, da dies die Größe und Komplexität der endgültigen Zusammenführungen reduzieren und großflächige Konflikte verhindern kann.
• Überprüfung von Zusammenfassungsanfragen: Dies ist die erste Stufe der Qualitätssicherung, bei der Sie Fehler erkennen, Projektstandards durchsetzen und die Kohärenz mit dem Gesamtsystem sicherstellen.

„In großen Unity-Projekten sind Code-Reviews nicht nur eine Formalität“, rät David. „Sie sind ein wichtiger Bestandteil der Konfliktprävention und der allgemeinen Projektqualität.“

Stellen Sie nur sicher, dass die Personen, die den Code überprüfen, über Fachkenntnisse in dem umgesetzten Bereich verfügen und sich der bewährten Methoden der Programmierung bewusst sind, damit sie Richtigkeit und Wartbarkeit genau beurteilen können.

Es gibt bestimmte Tipps und Tricks, um die Versionskontrolle in Unity so reibungslos wie möglich zu gestalten. Szenen und Prefabs bilden das Fundament Ihres Projekts, daher sollten Sie sie nicht nur für die CPU-Leistung, sondern auch für die Zusammenarbeit der Entwickler optimieren.

Wir bevorzugen immer kleinere, additive und verschachtelte Komponenten gegenüber einer großen Szene oder einem monolithischen Prefab. Auf diese Weise können Entwickler parallel ohne Konflikte arbeiten.

Dies ist wichtig, da Zusammenführungskonflikte in Szenen und Prefabs am schwersten zu lösen sind, da ihre Daten für Entwickler nicht leicht lesbar sind. Um diesen Prozess zu vereinfachen, serialisieren wir diese Dateien als Text und nicht als Binärdatei und aktivieren die automatische Zusammenführungsfunktion unserer Git-Konfiguration für YAML-Dateien. Dadurch ist es wahrscheinlicher, dass Git Zusammenführungskonflikte selbst löst und die Entwicklerzeit für die wichtige Arbeit an neuen Funktionen geschützt wird.

Aber trotz all dem:

„Die Vermeidung von Konflikten ist in der Regel eine bessere Strategie als der Versuch, sie zu lösen“, sagt Nico.

Klare Asset-Eigentumsverhältnisse können dabei sehr hilfreich sein.

„Definieren Sie, wer bestimmte Szenen oder Prefabs ändern darf“, sagt David. „Dann fordern Teammitglieder Änderungen außerhalb ihres Eigentums an, anstatt Assets direkt zu bearbeiten.“

Nico beschreibt ein ähnliches Verfahren als „Semaphore-System“. Dies ist im Grunde eine Tabelle, in der Entwickler protokollieren, wann sie ein Asset ändern, und es effektiv „sperren“. Wenn ein anderer Entwickler Änderungen an dieser Datei vornehmen muss, muss er warten, bis der Entwickler, der die Datei gesperrt hat, seine Änderung im Repository hochlädt und sie „entsperrt“.

Wie immer sollten Sie herausfinden, welches Verfahren für Ihr Team am besten geeignet ist.

Aufbau für die Zukunft

Bei Mega Cat Studios haben wir gelernt, dass es bei der Skalierung eines Unity-Projekts weniger darum geht, "härter zu programmieren", sondern vielmehr um architektonische Disziplin. Indem wir die komponentenbasierte Natur von Unity respektieren, Grenzen mit Assembly-Definitionen durchsetzen und Assets mit Blick auf die Zukunft organisieren, bewahren wir einen Großteil des kreativen Flusses der Prototypenphase, ohne das Projekt vor dem Start in technische Schulden zu stürzen.

Obwohl diese Lektionen wichtig sind, denken Sie daran, dass kein Codebase perfekt ist. Die Softwareentwicklung ist ein epischer Kampf, in dem empfohlene Programmiermuster und praktische Überlegungen täglich aufeinandertreffen. Wenn die Einhaltung eines dieser Prinzipien die Entwicklung behindert, ohne einen vorteilhaften Kompromiss zu erzielen, ist dies ein Zeichen dafür, dass Sie sensibler auf die Besonderheiten Ihres eigenen Teams und nicht auf die Empfehlungen aus dem Lehrbuch achten müssen. Schließlich ist jedes Projekt, jedes Team und jede Person unterschiedlich.

Wir versuchen jeden Tag bei Mega Cat Studios, dieses Gleichgewicht zu finden. Mit jedem neuen Projekt, während unsere Spielbibliothek weiter wächst, hoffen wir, bessere Unity-Entwickler und bessere Mitarbeiter zu werden.