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

Dieser Blogbeitrag ist der erste in einer Reihe von Mega Cat Studios, in der sie ihr Unity-Fachwissen und Lösungen für reale Herausforderungen bei der kommerziellen Spieleentwicklung teilen. Sehen Sie sich die anderen Beiträge in dieser Reihe an, die Input und Level- sowie Umgebungsdesign behandeln:

• Volltreffer: Wie das ereignisgesteuerte Input System von Unity die Steuerung in Backyard Baseball 2026 antreibt
• Wie man ein klassisches Sportspiel für eine neue Generation mit Leveldesign, Worldbuilding und VFX neu erfindet
• Rendering in großem Maßstab: Effiziente Strategien für massive Objektmengen

Wir hoffen, Sie erhalten einige großartige Tipps!

Sie haben eine großartige Idee, und der Code fließt so schnell, wie Sie ihn tippen können. Mit jedem Commit nimmt ein neues Feature Gestalt an. Aber genau die Geschwindigkeit, mit der Ihre Ideen entstehen, könnte bald dazu führen, dass Sie vor einem großen, fehlerhaften Chaos stehen.

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

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

Lektion 1: Struktur für Skalierbarkeit

Skalierungsprobleme werden selten durch schlechten Code verursacht; stattdessen entstehen sie häufiger durch eine ungeplante Architektur. Wenn ein Entwickler oder Artist ein Asset nicht innerhalb von 10 Sekunden finden kann, muss der Workflow geändert werden. Ein paar Tipps für die Einrichtung Ihres Projekts zur Skalierung sind:

• Nach Typ und Zweck organisieren: Wir gruppieren nach Typ, dann nach Zweck. Typ umfasst Kategorien wie Art, Code und Audio. Zweck ist das, wofür sie verwendet werden. Intuitive Organisation reduziert den Einarbeitungsaufwand; ein neuer Artist sollte genau wissen, wohin ein „Character Idle“-Sprite gehört, ohne fragen zu müssen.
• Szenen einfach halten: Wir haben die „Mega-Szene“ verworfen und entscheiden uns stattdessen für kleinere Szenen, wie eine Hauptszene, die Speicherdaten und kritische Systeme enthält, zusammen mit einem Titelbildschirm und Baseball-Diamond-Szenen, die additiv geladen werden, je nachdem, ob sich der Spieler in einem Spiel befindet. Ähnlich verwenden wir Prefabs für in sich geschlossene Funktionen, sodass Änderungen weniger wahrscheinlich in der Szenendatei serialisiert werden, die sie enthält. Dies ermöglicht es einem Artist, an der Umgebung zu arbeiten, während ein Designer das Gameplay im selben „Level“ optimiert, ohne dass es zu Dateikonflikten kommt (mehr dazu später).
• Das Addressables-System einrichten: Anstelle von herkömmlichen Resources-Ordnern verwenden wir das Addressables-System, um Assets nur bei Bedarf zu laden und so die Speicherauslastung gering zu halten. Außerdem ist das Laden eines Assets mit seinem Addressable-Schlüssel klarer und weniger fehleranfällig als das Laden über einen Dateipfad zu einem bestimmten Speicherort im Resources-Ordner.

Der schwierige Teil ist nicht das Verständnis dieser Best Practices. Es geht darum, sich von Anfang an dazu zu verpflichten und diese Disziplin auch Jahre später noch 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, ihn zuerst funktionsfähig zu machen, bevor man ihn modular gestaltet“, sagt Paolo Roxas, ein Entwickler bei Backyard Baseball. „Wir wollen sehen, wie sich das Projekt entwickelt, bevor wir es komplexer gestalten.“

Lektion 2: Arbeiten Sie mit Unity, nicht dagegen

„Es gibt nichts Mächtigeres, als Bausteine zu erstellen – ob Components, ScriptableObjects oder benutzerdefinierte Klassen –, die fokussiert, prägnant und in sich geschlossen sind“, sagt David Chávez Armenteros, Head of Engineering bei Mega Cat Studios. Unity setzt im Kern auf Modularität. Um flexibel zu bleiben, folgen wir drei klassischen Prinzipien:

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

2. Lose Kopplung: Systeme sollten über Schnittstellen oder Ereignisse interagieren, anstatt über direkte Referenzen, und nur wenn dies angemessen ist. Wir empfehlen, Abhängigkeiten zwischen Systemen grafisch darzustellen, bevor sie im Code implementiert werden, um zyklische oder verwickelte Architekturen zu vermeiden.

3. Plug-and-Play: Kombinieren Sie kleine, fokussierte Einheiten, um komplexes Verhalten zu erzeugen, anstatt ausufernde „Gott“-Skripte zu schreiben.

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

Assembly Definitions (AsmDefs) sind C#-Konstrukte, die Ihren Code gruppieren. Ihr beworbener Vorteil sind verkürzte Kompilierzeiten, aber ihre geheime Superkraft ist die Erzwingung von Modularität.

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

„In Backyard Baseball befinden sich die Input-Ebene und die Gameplay-Ebene in unterschiedlichen DLLs. Das Gameplay ist völlig agnostisch gegenüber Details des Input System.“

Dies bewahrt Ingenieure vor sich selbst, indem jede Abhängigkeit zu einer kalkulierten Entscheidung gemacht wird. Wenn wir wirklich müssten, könnten wir das gesamte Input System – von der Gamepad-Steuerung bis zum Netcode – umschreiben, ohne zu riskieren, die Spielerphysik oder das KI-Verhalten zu beschädigen. Wahrscheinlicher ist, dass es einem Ingenieur ermöglicht, in einem einzigen Bereich der Codebasis zu arbeiten, ohne versehentlich Änderungen auf ein anderes System zu übertragen, und die Menge an Code reduziert, die ein Entwickler für Funktionsimplementierungen und Fehlerbehebungen im Blick behalten muss.

Lektion 4: Testen Sie intelligenter, nicht härter

Wenn Projekte wachsen, kann der „Dominoeffekt“ übernehmen: Eine kleine Änderung hier macht dort etwas kaputt. Gute Architektur hilft viel, ist aber kein Allheilmittel.

Bevor Funktionsänderungen die Pfoten unserer geschätzten Qualitätssicherungs-Katzen für manuelle Tests erreichen, wird das Spiel in einer Reihe automatisierter Unit-Tests rigoros analysiert.

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

Wenn ein Charakter in Backyard Baseball einen Fastball wirft, eine Base stiehlt oder einen Homerun schlägt, gibt es bestimmte Spielergebnisse, die wir erreichen wollen, wie zum Beispiel sicherzustellen, dass der Ball mit einer Geschwindigkeit fliegt, die sich für den Wurf authentisch anfühlt, das Timing des Läufers mit den Mechaniken des Base-Stealings übereinstimmt oder die Feldspieler korrekt auf einen Schlag reagieren. Der Charakter muss korrekt mit dem Boden kollidieren, der Ball muss sich mit der richtigen Geschwindigkeit bewegen, und detailliertere Systeme wie Player-Controller-Flags, die Aktionen wie Ausholen, Schwingen oder Sprinten zwischen den Bases verfolgen, müssen funktionieren.

Wenn wir eine Anpassung an Pablo Sanchez’ Kraft vornehmen oder, noch kritischer, den gemeinsam genutzten Code anpassen, der die Schwünge mit dem Schläger steuert, müssen wir sicherstellen, dass sich jede Interaktion, vom Kontakt-Timing bis zur Flugbahn des Balls, im gesamten Spiel konsistent verhält.

Oft geht etwas kaputt, womit man nicht rechnet, und genau deshalb ist das Testen so wichtig.

Mit diesem System, das in unseren Workflow integriert ist, werden wir sofort benachrichtigt, wenn eine bestimmte Anforderung nicht mehr erfüllt wird. Das reduziert die Zeit für Tests und Fehlerbehebung, die sonst so mühsam wäre wie die Suche nach der Nadel im Heuhaufen.

Der Test Runner von Unity funktioniert am effektivsten, wenn Ihre Systeme modular aufgebaut sind, was ein weiterer Grund dafür ist, warum wir Assembly Definitions verwenden.

Lektion 5: Bringen Sie Ihre Assets auf Vordermann

„Irren ist menschlich, vergeben göttlich.“

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

Nach stundenlangem Programmieren und Debuggen ist es unvermeidlich, dass ein übermüdeter Entwickler ein paar Mal falsch klickt oder versehentlich Änderungen in das Repository pusht, die nur vorübergehend gedacht waren. Obwohl dies verzeihlich ist (sage ich als jemand, der gelegentlich selbst übermüdet ist), kann ein Asset mit schlecht konfigurierten Importeinstellungen enorme Konsequenzen haben. Und da viele Entwickler an leistungsstarken Rechnern arbeiten, besteht das Albtraumszenario darin, dass das Performance-Problem erst später bemerkt wird, etwa wenn eine Stadionszene mit Charakteren, Animationen und Effekten auf schwächerer Hardware zu Verlangsamungen oder Instabilität führt.

Um dieses Risiko zu mindern, könnte man den Zugriff auf Assets einschränken, aber dies führt aufgrund der vielen Gründe, aus denen Spielinhalte angepasst werden müssen, zu einem Engpass:

• Das Modell ist zu groß für das Kamera-Setup.
• Dieser Audioclip hat weniger Lautstärke und benötigt daher einen speziellen Effekt.
• Jede Textur muss angepasst werden, da sich der Shader geändert hat.

In einem Spiel wie Backyard Baseball, bei dem die visuelle Identität von größter Bedeutung ist, erhalten Modelle und VFX Hunderte von Optimierungen, während wir vor der Veröffentlichung den Look and Feel perfektionieren.

„Keine technischen Spezifikationen können die Tatsache ausgleichen, dass eine Vielfalt an Inhalten bedeutet, mit geringfügigen, aber signifikanten Unterschieden zwischen verschiedenen Assets umzugehen“, sagt Nico.

Automatisierung hilft auch hier:

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

Lassen Sie sich jedoch letztendlich nicht von all diesem Gerede über Automatisierung von einfachen, manuellen Korrekturen ablenken, wenn diese schneller sind.

„Verbringen Sie niemals 10 Tage damit, eine Aufgabe zu automatisieren, die manuell 10 Minuten dauert“, warnt David.

Lektion 6: Meistern Sie das menschliche Element (Zusammenarbeit)

Version Control-Systeme wie Git sind eines der ersten Dinge, die einem in den Sinn kommen, wenn man täglich Hunderte von Änderungen von Dutzenden von Entwicklern koordiniert. David empfiehlt diese bewährten Methoden für alle unsere Projekte bei Mega Cat:

• Kleine, atomare Änderungen: Vermeiden Sie „Mega-Commits“, die viele Systeme gleichzeitig betreffen. Isolieren Sie die Arbeit an einzelnen Feature-Branches, bis diese stabil und überprüft sind. Halten Sie einzelne Änderungen in einzelnen Commits für eine gut dokumentierte Versionshistorie, was bei Bedarf auch Cherry-Picking und andere Git-Magie erleichtert.
• Tägliche Merges vom Main-Branch: Halten Sie Feature-, Abteilungs- und langlebige Branches mit dem Main-Branch auf dem neuesten Stand, da dies die Größe und Komplexität der endgültigen Merges reduzieren und helfen kann, großflächige Konflikte zu vermeiden.
• Merge-Requests überprüfen: Dies ist die erste Instanz der Qualitätssicherung, bei der Sie Fehler finden, Projektstandards durchsetzen und die Kohäsion mit dem Gesamtsystem sicherstellen.

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

Stellen Sie sicher, dass diejenigen, die den Code überprüfen, über Fachkenntnisse in dem implementierten Bereich verfügen und mit den Best Practices für die Programmierung vertraut sind, damit sie Korrektheit und Wartbarkeit genau beurteilen können.

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

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 und ohne Konflikte arbeiten.

Dies ist wichtig, da Merge-Konflikte in Szenen und Prefabs am schwierigsten zu lösen sind, weil ihre Daten für Entwickler nicht leicht lesbar sind. Um diesen Prozess zu glätten, serialisieren wir diese Dateien als Text, nicht als Binärdatei, und aktivieren die Auto-Merge-Funktion unserer Git-Konfiguration für YAML-Dateien. Dies erhöht die Wahrscheinlichkeit, dass Git Merge-Konflikte selbst löst, und spart Entwicklerzeit für die wichtige Arbeit an neuen Funktionen.

Doch trotz alledem:

„Konflikte zu vermeiden ist meist eine bessere Strategie, als zu versuchen, sie zu lösen“, sagt Nico.

Eine klare Zuständigkeit für Assets kann hier viel bewirken.

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

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

Finden Sie wie immer heraus, welches Verfahren für Ihr Team am besten funktioniert.

Bauen für die Zukunft

Bei Mega Cat Studios haben wir gelernt, dass es bei der Skalierung eines Unity-Projekts weniger um „härteres Programmieren“ geht, sondern vielmehr um architektonische Disziplin. Indem wir die komponentenbasierte Natur von Unity respektieren, Grenzen mit Assembly Definitions durchsetzen und Assets zukunftssicher organisieren, bewahren wir einen Großteil des kreativen Flusses der Prototypenphase, ohne dass das Projekt vor der Veröffentlichung in technische Schulden versinkt.

Obwohl diese Lektionen wichtig sind, denken Sie daran, dass keine Codebasis perfekt ist. Softwareentwicklung ist ein epischer Kampf, bei dem empfohlene Programmiermuster und praktische Überlegungen täglich aufeinanderprallen. Wenn das Befolgen eines dieser Prinzipien die Entwicklung ins Stocken bringt, ohne einen vorteilhaften Kompromiss zu erzielen, ist das ein Zeichen dafür, dass Sie sensibler für die Besonderheiten Ihres eigenen Teams sein müssen und nicht für Lehrbuchempfehlungen. Schließlich ist jedes Projekt, jedes Team und jede Person anders.

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