Ein externes Team in eine laufende Unity-Produktion zu holen, ist zuerst eine Übergabefrage und erst danach eine Engineering-Frage. Die neuen Entwickler müssen wissen, was sie gefahrlos ändern können, was schon jetzt fragil ist und welche Arbeit für den Release wirklich zählt. Genau darauf sollte ein Projekt-Audit antworten. Häufig entsteht stattdessen eine lange Liste von Beobachtungen: „zu viele Singletons“, „veraltete Packages“, „die Performance könnte besser sein“. Nichts davon lässt sich einplanen, schätzen oder abnehmen.
Dieser Leitfaden richtet sich an technische Leads und Producer, die ein Audit beauftragen oder ein vorliegendes bewerten wollen. Er beantwortet eine Frage: Wie wird aus einem Audit eine priorisierte Liste und ein Arbeitspaket, das sich sicher übergeben lässt?
Wann ein Audit der richtige erste Schritt ist
Ein Audit kostet Zeit, bevor sichtbarer Fortschritt entsteht. Es sollte deshalb durch Unsicherheit begründet sein, nicht durch Gewohnheit. Meist ist es der richtige erste Schritt, wenn:
- das Projekt übernommen wurde. Das ursprüngliche Team ist nicht mehr da oder arbeitet an anderem, und niemand kann sicher sagen, welche Systeme tragend sind.
- die Performance auf der Zielhardware nicht reicht, aber unklar ist, ob Content, Code, Rendering oder Architektur die Ursache sind.
- das Projekt langsam, instabil oder schwer änderbar geworden ist. Kleine Features dauern Wochen, Merges zerstören Szenen, und dieselben Bugs kehren zurück.
- aus einem Prototyp eine Produktion werden soll. Der Code hat das Spiel bewiesen, wurde aber nicht dafür gebaut, viel Content und ein größeres Team aufzunehmen.
- Producer oder Publisher entscheiden müssen, ob sie weiter investieren, und dafür eine technische Grundlage brauchen.
Ist das Problem eng umrissen, reproduzierbar und die Ursache bereits bekannt, ist ein gezielter Fix oft günstiger als ein vollständiges Audit. Ein guter Partner sagt Ihnen das auch. Der Umfang des Audits sollte zur Größe der Unsicherheit passen.
Was Sie vor dem Audit bereitstellen sollten
Die Qualität eines Audits hängt von seinen Eingaben ab. Bereiten Sie Folgendes vor, bevor das externe Team beginnt, und behandeln Sie alles, was Sie nicht liefern können, als eigenen Befund.
| Eingabe | Warum sie wichtig ist |
|---|---|
| Unity-Version und Render-Pipeline | Bestimmen Upgrade-Pfade, Package-Kompatibilität und die verfügbaren Werkzeuge. |
| Zielplattformen und repräsentative Hardware | Performance-Befunde sind nur auf der Hardware aussagekräftig, auf der Spieler spielen werden. |
| Ein aktueller Build und die Schritte, ihn zu erzeugen | Zeigt, ob der Build außerhalb des Rechners eines einzelnen Entwicklers reproduzierbar ist. |
| Reproduzierbare Probleme mit Schritten | Macht aus „ruckelt manchmal“ ein Szenario, das vorher und nachher gemessen werden kann. |
| Vorhandene Profile, Crash-Logs und Bug-Reports | Sparen Zeit und zeigen, was das Team bereits ausgeschlossen hat. |
| Scope und Verantwortlichkeiten | Was das Audit abdeckt, wer welches System verantwortet, welche Branches aktiv sind und welche Code-Review-Regeln gelten. |
| Die Entscheidung, die das Audit stützen soll | Zum Beispiel: „Kann ein externes Team Kampfsystem und KI übernehmen, ohne die Content-Produktion zu blockieren?“ |
Die letzte Zeile fehlt am häufigsten. Ein Audit ohne zu stützende Entscheidung wächst leicht zu einer Bestandsaufnahme ohne Prioritäten.
Was das Audit prüfen sollte
Ein Unity-Audit vor dem Co-Development sollte die Bereiche abdecken, in denen ein neu einsteigendes Team am ehesten Probleme verursacht oder auf sie stößt. Wie tief jeder Bereich geprüft wird, hängt von der oben genannten Entscheidung ab.
| Bereich | Fragen, die das Audit beantworten sollte |
|---|---|
| Architektur | Wie sind Assemblies und Abhängigkeiten organisiert? Wo verlaufen die Grenzen zwischen Gameplay, Networking, Präsentation und Daten? Welche Systeme sind zu eng gekoppelt? |
| Packages und Plugins | Welche Packages und Versionen sind im Einsatz? Sind welche geforkt, eingebettet oder verwaist? Was blockiert ein Upgrade? |
| Szenen und Prefabs | Wie werden Szenen geladen, und wem gehören sie? Woher kommen Merge-Konflikte und gebrochene serialisierte Referenzen? |
| Datenflüsse | Wo liegt die Hoheit über den Spielzustand? Wie fließen Konfiguration, Spielstände und gegebenenfalls Netzwerkzustand durch das Spiel? |
| Tooling | Welche Editor-Tools, Import-Regeln und Datenvalidierungen gibt es? Wo können Designer oder Artists den Build unbemerkt brechen? |
| Build-Pipeline | Kann eine saubere Maschine oder die CI jeden Ziel-Build erzeugen, einschließlich Headless-Server-Builds, falls das Spiel welche hat? Welche Schritte sind manuell? |
| Performance | Was zeigen CPU-, GPU-, Speicher-, Lade- und Garbage-Collection-Profile auf repräsentativer Zielhardware in einem wiederholbaren Szenario? |
Zur Performance-Zeile gehört eine eigene Warnung. Profile aus dem Editor oder von einem starken Entwickler-PC helfen bei der Orientierung, sind aber kein Beleg für ein mobiles VR-Headset oder einen durchschnittlichen Spieler-PC. Techniken wie Burst, Native Containers oder datenorientierte Layouts gehören nur dann in die Maßnahmen-Spalte, wenn eine gemessene Last sie rechtfertigt. Unser Team hat sie bei VOXSYS eingesetzt, einem Mobile-VR-Shooter mit dem Ziel von 90 FPS (umgesetzt von heutigen Teammitgliedern in ihren früheren Rollen bei VR Storm Studio). Die Lehre daraus: erst messen, dann den nachgewiesenen Engpass optimieren, nicht den vermuteten.
Aus demselben Grund zählt die Zeile zur Build-Pipeline. Bei Bean stalker, einer prozeduralen VR-Welt, die ein 18-köpfiges, interdisziplinäres Team gebaut hat, waren Tools, Validierung und Build-Automatisierung genauso wichtig wie der Generierungsalgorithmus selbst: Content-Ersteller brauchten schnelles Feedback, das Release-Team reproduzierbare Ergebnisse.
Was jeder Befund enthalten muss
Das ist der Kern eines nützlichen Audits. Jeder Befund sollte eine eigenständige Einheit sein, die ein Producer einplanen und ein Entwickler überprüfen kann. Nutzen Sie diese Vorlage:
| Feld | Inhalt | Schwache Fassung | Brauchbare Fassung |
|---|---|---|---|
| Problem | Ein konkretes Problem, eingegrenzt auf ein System oder einen Workflow. | „Die Architektur ist unübersichtlich.“ | „Das Spawnen von Gegnern alloziert Speicher und instanziiert Prefabs während des Kampfes.“ |
| Beleg | Wie es festgestellt wurde: Profil, Log, Codeverweis, Reproduktionsschritte. | „Ist uns aufgefallen.“ | „Capture auf Zielhardware, Szenario X, Frames N–M; Codepfad in SpawnController.“ |
| Auswirkung auf Spieler / Geschäft | Was Spieler spüren oder was die Produktion verliert. | „Schlecht für die Performance.“ | „Sichtbarer Hänger auf dem Höhepunkt jeder Kampfwelle.“ |
| Priorität | Gegenüber anderen Befunden nach Auswirkung und Risiko eingeordnet. | Überall „hoch“. | „P1: blockiert die vereinbarte Qualitätsschwelle für den Release.“ |
| Vorgeschlagene Maßnahme | Was geändert wird und ob es ein Quick Fix, ein schrittweises Refactoring oder eine Umstrukturierung ist. | „Spawning refactoren.“ | „Gegner-Prefabs poolen, Allokationen pro Spawn entfernen, ein Regressionsszenario ergänzen.“ |
| Abnahmekriterium | Woran alle erkennen, dass es erledigt ist, gemessen wie der Beleg. | „Sollte schneller sein.“ | „Gleiches Szenario, gleiche Hardware: kein Frame während der Welle über dem vereinbarten Budget.“ |
Zwei Felder werden oft ausgelassen, und gerade sie machen ein Audit umsetzbar. Der Beleg macht den Befund für Ihr eigenes Team überprüfbar. Das Abnahmekriterium macht aus dem Befund ein Arbeitspaket mit klarem Ende und wird zum Review-Maßstab, wenn die Arbeit an Sie zurückgeht.
Quick Fix, schrittweises Refactoring oder größere Umstrukturierung
Jede vorgeschlagene Maßnahme sollte eingeordnet werden, denn die drei Typen tragen sehr unterschiedliche Risiken für eine Produktion, die währenddessen weiter Content liefert.
| Typ | Typischer Fall | Risiko für die Produktion | Wie geprüft wird |
|---|---|---|---|
| Quick Fix | Eine lokale, gut verstandene Ursache: eine heiße Allokation, eine fehlende Validierung, ein manueller Build-Schritt. | Niedrig; betrifft ein System. | Die ursprüngliche Reproduktion und Messung, vorher und nachher. |
| Schrittweises Refactoring | Ein System, das funktioniert, sich aber Änderungen widersetzt: verflochtene Abhängigkeiten, unklare Zustandshoheit. | Mittel; braucht eine testbare Grenze und einen Migrationsplan, der zur laufenden Content-Arbeit passt. | Tests um kritische Regeln, unverändertes Verhalten und die vereinbarten Abnahmekriterien. |
| Größere Umstrukturierung | Die Belege zeigen eine strukturelle Ursache, etwa eine Zustandshoheit, die eine neue Anforderung nicht tragen kann. | Hoch; konkurriert mit Features und braucht einen gestuften Plan. | Gestufte Meilensteine mit jeweils eigenen Abnahmekriterien. |
Ein vertrauenswürdiges Audit springt nicht sofort zum Rewrite. Die meisten Befunde sollten in den ersten beiden Zeilen landen. Schlägt ein Audit eine Umstrukturierung vor, muss es belegen, warum kleinere Maßnahmen nicht reichen, und einen Plan liefern, der den Rest der Produktion nicht einfriert.
Vom Audit zur Co-Development-Übergabe
Nützlich wird das Audit, wenn aus seinen Befunden ein Arbeitspaket entsteht, das ein externes Team verantwortlich übernehmen kann. Vor Beginn der Umsetzung sollten Sie vier Dinge vereinbaren.
Verantwortlichkeiten. Typischerweise verantworten Sie den Repository-Zugang, die Branching-Regeln und die Code-Review-Policy, die Produktprioritäten und die Abnahme gelieferter Arbeit sowie Zielhardware und Plattformanforderungen. Das externe Team verantwortet die Engineering-Qualität seiner Lieferungen, reproduzierbare Messungen für jede Optimierungsaussage und klare Zuständigkeitsgrenzen zu Ihren internen Entwicklern.
Abhängigkeiten. Halten Sie für jeden Befund im Paket fest, wovon er abhängt: von anderen Befunden, Content-Lieferungen, einem Package-Upgrade, dem Zugang zu einem Gerät, einer Design-Entscheidung. Nicht dokumentierte Abhängigkeiten werden zu Verzögerungen, für die niemand zuständig ist.
Review. Legen Sie fest, wer Pull Requests prüft, wie oft Fortschritt gezeigt wird und was passiert, wenn sich ein Befund als größer als geschätzt herausstellt. Die Abnahmekriterien aus dem Audit sind die Review-Checkliste.
Übergabe. Definieren Sie, was nach Abschluss zurückkommt: gemergter Code, Tests um die geänderten Regeln, Dokumentation, aktualisierte Tools und die Vorher-nachher-Messungen. Ziel ist eine Codebasis, die Ihr Team weiter pflegen kann, keine Abhängigkeit vom externen Team.
Die verschiedenen Verantwortungsmodelle, vom abgegrenzten Workstream bis zu eingebetteten Engineers, beschreiben wir auf der Seite Spieleentwicklung. Wie wir Audits bestehender Unity-Projekte konkret angehen, zeigt die Seite Unity-Spieleentwicklung.
Beispielbefund (zur Veranschaulichung)
Fiktives Beispiel zur Veranschaulichung. Der folgende Befund ist hypothetisch. Er beschreibt keinen realen Kunden und kein reales Projekt und enthält keine Messwerte. Er zeigt nur, wie die ausgefüllte Vorlage aussieht.
| Feld | Inhalt |
|---|---|
| Problem | Während der Kampfwellen werden Gegner beim Spawnen aus Prefabs instanziiert, und die Spawn-Logik alloziert bei jedem Gegner temporäre Collections. |
| Beleg | CPU-Profil auf der vereinbarten Zielhardware in einem wiederholbaren Szenario (ein fester Spielstand zu Beginn der dritten Welle). In den Spitzen-Frames sind Instanziierung und Garbage Collection im Spawn-Codepfad zu sehen. Die Codestelle ist referenziert. |
| Auswirkung auf Spieler / Geschäft | Spieler sehen im intensivsten Moment jeder Welle einen Hänger. Auf einer VR-Zielplattform wäre derselbe Hänger zusätzlich ein Komfortproblem. In Rezensionen und Playtest-Notizen taucht er als „Ruckeln“ auf. |
| Priorität | P1: betrifft jede Session und blockiert die vereinbarte Performance-Schwelle für den nächsten Meilenstein. |
| Vorgeschlagene Maßnahme | Quick Fix: ein vorgewärmter Pool für die in der Welle genutzten Gegner-Prefabs und das Entfernen der Allokationen pro Spawn aus dem Spawn-Pfad. Das Szenario kommt in den regelmäßigen Performance-Check, damit das Problem nicht unbemerkt zurückkehrt. |
| Abnahmekriterium | Im selben Szenario auf derselben Hardware überschreitet während der Welle kein Frame das vereinbarte Frame-Time-Budget, und nach dem Aufwärmen alloziert der Spawn-Pfad pro Spawn keinen Managed Memory. Die Vorher-nachher-Captures hängen am Pull Request. |
Achten Sie darauf, was im Beispiel fehlt: eine versprochene prozentuale Verbesserung. Das Abnahmekriterium ist an das eigene Budget des Projekts gebunden und wird gemessen wie der Beleg. Dadurch ist es überprüfbar.
Ist Ihre aktuelle Produktion ein Netzwerkspiel, funktioniert dieselbe Vorlage für Befunde zu Server-Builds und Zustandshoheit. In Bad Goons, unserer aktuellen eigenen IP in aktiver Entwicklung, werden Unity-6-Client, FishNet-Realtime-Schicht, Voxel-Simulation und dedizierte Linux-Server als getrennte Produktionssysteme behandelt, und genau diese Trennung sollte ein Audit suchen oder empfehlen. Die VOXSYS-Fallstudie zeigt die Performance-Seite derselben Disziplin.
Checkliste zur Bewertung eines Audit-Angebots
Stellen Sie diese Fragen, bevor Sie ein Audit freigeben, und noch einmal, wenn Sie den Bericht erhalten.
- Das Angebot nennt die Entscheidung, die das Audit stützen soll, nicht nur die zu prüfenden Bereiche.
- Die benötigten Eingaben sind aufgeführt: Unity-Version, Render-Pipeline, Zielplattformen und Hardware, Build-Schritte, reproduzierbare Probleme, vorhandene Profile, Scope und Verantwortlichkeiten.
- Performance-Arbeit ist auf repräsentativer Zielhardware in wiederholbaren Szenarien geplant.
- Die Prüfung umfasst Architektur, Packages, Szenen, Datenflüsse, Tooling, Build-Pipeline und Performance oder begründet, warum ein Bereich ausgeklammert wird.
- Jeder Befund wird Problem, Beleg, Auswirkung auf Spieler oder Geschäft, Priorität, vorgeschlagene Maßnahme und Abnahmekriterium enthalten.
- Die Befunde sind gegeneinander priorisiert, nicht alle als „hoch“ markiert.
- Jede Maßnahme ist als Quick Fix, schrittweises Refactoring oder größere Umstrukturierung eingeordnet, mit ihrem Produktionsrisiko.
- Jeder Umstrukturierungsvorschlag enthält den Beleg, dass kleinere Änderungen nicht reichen, und einen Plan, der die Content-Produktion nicht einfriert.
- Der Bericht endet mit einem Arbeitspaket: Verantwortlichkeiten, Abhängigkeiten, Review-Prozess und Übergabeleistungen.
- Optimierungsaussagen werden durch Vorher-nachher-Messungen im selben Szenario belegt.
- Ihr eigenes Team kann jeden Befund ohne das externe Team überprüfen.