Skalierung von Unity-Workflows: Lektionen aus mittleren 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 sowie Level- und Umgebungsdesign behandeln:

• Volltreffer: Wie das ereignisgesteuerte Input System von Unity die Steuerung in Backyard Baseball 2026 antreibt
• Wie man einen Sportspiel-Klassiker für eine neue Generation mit Leveldesign, Worldbuilding und VFX neu erfindet

Wir hoffen, Sie nehmen einige großartige Tipps mit!

Sie haben eine großartige Idee, und der Code fliegt 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 überstanden 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 ungeplante Architektur. Wenn ein Entwickler oder Künstler ein Asset nicht innerhalb von 10 Sekunden finden kann, muss der Arbeitsablauf geändert werden. Ein paar Tipps für die Skalierung Ihres Projekts sind:

• Nach Typ und Zweck organisieren: Wir gruppieren nach Typ, dann nach Zweck. Typ umfasst Kategorien wie Kunst, Code und Audio. Zweck ist das, wofür sie verwendet werden. Intuitive Organisation reduziert die Einarbeitungshürden; ein neuer Künstler sollte genau wissen, wo ein „Character Idle“-Sprite hingehö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 der Spieler sich in einem Match befindet. Ebenso 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 Künstler, an der Umgebung zu arbeiten, während ein Designer das Gameplay im selben „Level“ anpasst, 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 Addressables-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, es zuerst funktionsfähig zu machen, bevor man es modular gestaltet“, sagt Paolo Roxas, ein Entwickler bei Backyard Baseball. „Wir wollen sehen, wie sich das Projekt entwickelt, bevor wir es komplexer machen.“

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 macht sich Modularität im Kern zu eigen. Um flexibel zu bleiben, folgen wir drei klassischen Prinzipien:

1. Single Responsibility: 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 verschiedenen DLLs. Das Gameplay ist völlig agnostisch gegenüber Input-Details.“

Dies bewahrt die 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 Kopf behalten muss.

Lektion 4: Intelligenter testen, nicht härter

Wenn Projekte wachsen, kann der „Dominoeffekt“ die Oberhand gewinnen: Eine kleine Änderung hier macht etwas dort kaputt. Gute Architektur hilft sehr, aber sie ist 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 fungieren als Anforderungsliste“, 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 spezifische Spielergebnisse, die wir erreichen wollen, wie etwa 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 Basestiehlens ü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, das man nicht erwartet hätte, was der ganze Grund dafür ist, warum Testen so wichtig ist.

Mit diesem System, das in unseren Arbeitsablauf integriert ist, werden wir in dem Moment aufmerksam, in dem eine spezifische Anforderung nicht mehr erfüllt wird, was die Test- und Fehlersuch-Sitzungen verkürzt, die so zeitaufwendig sind 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 ist göttlich.“

Aber Systeme einzurichten, um menschliches Versagen von vornherein zu verhindern, ist geradezu legendär.

Nach stundenlangem Programmieren und Debuggen ist es unvermeidlich, dass ein übermüdeter Entwickler ein paar Fehlklicks macht oder versehentlich Änderungen in das Repo pusht, die nur als vorübergehend gedacht waren. Obwohl verzeihlich (sage ich als einer der gelegentlich Übermüdeten), könnte ein Asset mit schlecht konfigurierten Importeinstellungen enorme Konsequenzen haben. Und da viele Entwickler an leistungsstarken Rechnern arbeiten, besteht das Albtraumszenario darin, dass das Leistungsproblem erst später bemerkt wird, etwa wenn eine Stadionszene mit Charakteren, Animationen und Effekten auf Hardware mit geringerer Leistung zu Verlangsamungen oder Instabilität führt.

Um dieses Risiko zu mindern, könnten Sie einschränken, wer Zugriff auf Assets hat, 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, daher benötigt er einen spezifischen Effekt.
• Jede Textur muss angepasst werden, jetzt 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 Anpassungen, während wir vor der Veröffentlichung das Aussehen und das Gefühl genau richtig abstimmen.

„Keine Menge an technischen Spezifikationen kann die Tatsache umgehen, 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 Build 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: Beherrschen 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. Behalten Sie einzelne Änderungen in einzelnen Commits bei, um eine gut dokumentierte Versionshistorie zu erhalten, die bei Bedarf auch Cherry-Picking und andere Git-Magie erleichtert.
• Tägliche Merges vom Main: 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 nur sicher, dass diejenigen, die den Code überprüfen, über Fachkenntnisse in dem implementierten Bereich verfügen und sich der Best Practices für die Programmierung bewusst sind, damit sie Korrektheit und Wartbarkeit genau beurteilen können.

Es gibt spezifische Tipps und Tricks, um 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 bewahrt die Zeit der Entwickler 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 Asset-Zuständigkeit kann hier viel bewirken.

„Definieren Sie, wer bestimmte Szenen oder Prefabs bearbeiten 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.

Für die Zukunft bauen

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 dem Start unter technischer Schuld zusammenbricht.

Auch wenn diese Lektionen wichtig sind, denken Sie daran, dass keine Codebasis perfekt ist. Softwareentwicklung ist ein epischer Kampf, bei dem empfohlene Programmiermuster und praktische Erwägungen täglich aufeinanderprallen. Wenn die Befolgung 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 jeden Tag bei Mega Cat Studios, 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.