04 · Produktionsplan, Qualitätsziele und nächste Arbeitsschritte

Die folgende Planung setzt ein neues Unity-Projekt voraus. Zu Beginn dieser Recherche war der Arbeitsordner leer. Es wurde kein Spielcode erstellt. Aufwand, Geldbeträge und Hardwarebudgets sind eigene Szenarien mit ausdrücklich genannten Annahmen; keine Angebote oder extern erhobenen Marktpreise.

1. Was „AAA“ hier praktisch bedeutet

Der gewünschte Anspruch wird in überprüfbare Eigenschaften übersetzt: eigenständige und konsistente Kunst, hochwertig animierte Hauptfigur, unmittelbare Steuerung, verständliches Gegnerfeedback, eigens komponierte Musik, sorgfältiger Mix, stabile Performance und vollständige Bedienbarkeit. Ein einzelnes großes Artwork oder eine hohe Ausgabeauflösung stellt diese Qualität nicht her.

Für ein privates Familienprojekt ist die zielführende Form ein kleines Premiumspiel mit ausgewählten Spitzenmomenten. Der große Sechs-Regionen-Entwurf bleibt das Zielbild. Mehr Inhalt darf erst entstehen, wenn Bewegung, Kamera, Fäden und Produktionsablauf tatsächlich funktionieren.

2. Drei klar getrennte Umfangsstufen

Die Familienfassung verdichtet Sonnenhain, Gärten/Sturm und Archiv/Nacht/Krone. Sie behält Anfang, Wendung und Ende. Ein unfertiger erster Akt ist kein Ersatz für diese abgeschlossene kleine Fassung. Ihre gesonderte Levelverteilung wird nach dem Slice aus dem bestehenden Material festgelegt; sie ist eine Scope-Option, nicht die Hauptplanung.

3. Unity-Architektur

Technische Ausgangsentscheidung

Unity 6 in einer beim Projektstart unterstützten LTS-Version, URP mit 2D Renderer, neues Input System, Cinemachine für Grundrahmung und Raumgrenzen. Exakte Editor- und Paketversionen werden gemeinsam geprüft und anschließend festgeschrieben. Updates während einer Produktionsphase nur mit konkretem Anlass und getestetem Upgrade-Zweig.

Unity dokumentiert 2D-Beleuchtung, Sprite-Normal-Maps und Schatten in URP. Das Input System unterstützt Gamepad-Abstraktionen; Cinemachine bietet einen eigenen 2D-Arbeitsablauf. Die Kombination passt zu diesem Entwurf, liefert aber Bewegung, Fadenlogik und gutes Kameraverhalten nicht automatisch. Quellen: URP 2D, Input System, Cinemachine 2D.

Systemaufteilung

Ein zentraler Bootstrap lädt Profil und Dienste. Je Level existiert eine Hauptszene mit kleinen additiven Abschnitten, falls gemessene Speicher- oder Ladezeiten das nötig machen. Nicht früh eine komplexe Streamingarchitektur bauen. Gegner, Upgrades und Levelparameter werden datengetrieben beschrieben, beispielsweise mit ScriptableObjects. Gespeicherter Laufzeitfortschritt liegt getrennt von diesen Projektassets.

Für den Controller einen stabilen, selbst kontrollierten Motor mit Collision Casts und klaren Zustandswechseln entwickeln. Rigidbody2D kann an der Kollisionsintegration beteiligt sein; eine unkontrollierte Physiksimulation darf aber keine Sprungweiten bestimmen. Eingaben werden gepuffert, Simulation und Darstellung zeitlich sauber gekoppelt. Ein 60-Hz-Gameplay-Takt ist die erste Hypothese; messbare Verzögerung entscheidet über Anpassungen.

Datenkonventionen

Stabile IDs für Level, Laternen, Türen, Anker, Bewohner und Sammelobjekte. IDs überleben das Umbenennen einer Szene. Persistente Schalter und temporäre Kampfzustände getrennt speichern. Ein LevelDefinition enthält Spawnpunkte, Fähigkeitsvoraussetzungen, Standardprofil, erlaubte Gegnergruppen und drei eindeutige Sammel-IDs. Ein automatischer Inhaltscheck findet doppelte IDs und fehlende Checkpoint-Verweise vor einem Build.

Ordner: Art/Characters, Art/Environments, Audio/Music, Audio/SFX, Data, Scenes, Scripts, UI, Tests, Documentation. Quelldateien und exportierte Laufzeitassets unterscheiden. Versionsverwaltung ab dem ersten Prototyp, große Binärdateien in passender Dateiversionierung; tägliche externe Sicherung des Arbeitsstands.

4. Grafik- und Audio-Pipeline

Umgebungen: Kompositionsskizze → spielbare Graybox → Lesbarkeitstest → Material- und Farbstudie → modulare Vordergrundteile → individuell gemalter Hintergrund → Licht und Effekte → Performanceprüfung. Kollisionsflächen entstehen vor der dekorativen Überarbeitung und werden danach erneut kontrolliert.

Figuren: Silhouette → Turnaround → Rig-Probe → Bewegungstest in Spielgröße → alle Zustände → Material- und Lichtanpassung → Trefferfeedback. Ein vollständiges Heldenrig wird vor sechs fertigen Landschaften benötigt. KI-Konzeptbilder können Richtungen explorieren; sie ersetzen keine konsistenten Animationsfolgen, sauberen Ebenen und geprüften Exportdateien.

Musik: Motive → kurze Weltstudie → Loop und Übergänge → Kampf-Stems → Implementierung → Mix im echten Level. Musik wird nicht erst am Schluss unter fertige Szenen gelegt. Sound: pro Aktion Variation, Lautheitsabgleich, Prioritätsgrenzen, Plattformtest mit Kopfhörer und Fernseher.

Inhaltsbudget der Vollfassung

Gesamtzahl der Frames, Texturen und Sprachminuten erst nach Pipelineprobe verbindlich planen. Ein Rig mit 30 Zuständen ist nicht automatisch billig; Mischungen, Abbrüche, Richtungswechsel und Trefferübergänge verursachen einen wesentlichen Teil des Aufwands.

5. Performance und Bildqualität

Ziel ist 1920 × 1080 bei stabilen 60 fps. Höhere Auflösungen können angeboten werden, ändern aber nicht die spielbare Sichtweite. Andere Seitenverhältnisse erhalten bewusst gestaltete Ränder oder geprüfte Kameraanpassungen. Der Basistest bleibt 16:9.

Ein konkreter vorhandener Familien-PC wird vor Produktionsstart als Referenzgerät festgelegt. Ohne dessen GPU, CPU, RAM und Bildschirm lassen sich keine seriösen Mindestanforderungen oder garantierten Frameraten nennen. Folgende Werte sind interne Startbudgets:

• 16,67 ms Framebudget; anhaltende CPU- und GPU-Zeiten jeweils möglichst unter 13 ms, als parallele Budgets und nicht addiert.
• Keine wiederkehrenden Allokationsspitzen im normalen Kampf; gemessene Garbage-Collection-Pausen beheben.
• Kontrollierte Transparenzflächen und begrenzte dynamische 2D-Lichter; Partikel und Regen zuerst gegen Overdraw profilieren.
• Zunächst höchstens ungefähr 2 GB Arbeitsspeicher und 1 GB residente Texturen auf dem Referenzgerät anstreben; tatsächlicher Verbrauch entscheidet über Korrektur.
• Neustart nach Niederlage ungefähr zwei Sekunden; Szenenwechsel bevorzugt unter fünf Sekunden auf dem Referenzlaufwerk.
• Niedrige Grafikstufe entfernt dekorative Effekte, behält alle Spielinformationen und Schattenkanten bei.

Input-to-Photon-Verzögerung separat messen. Eine niedrige CPU-Zeit allein beweist keine schnelle Steuerung; Controller, Framequeue und Fernseher beeinflussen das Ergebnis. Im internen Build Eingabeeingang und erste sichtbare Reaktion markieren und bei Bedarf mit Zeitlupenaufnahme prüfen.

6. Der Vertical Slice als konkreter Arbeitsauftrag

Enthaltene Systeme

Vollständige Xbox-Menünavigation; Laufen/Springen/Dash; Standardbogen mit Zielhilfe; eine Fadenbrücke mit korrektem Ablauf; ein Heilitem; zwei Laternen; drei Gegnerfamilien; eine gekürzte Borun-Begegnung; sichere Gleitstrecke; ein Profil mit Speichern/Laden; zwei Talismane nutzbar und ein dritter kaufbar; vollständige grundlegende Audio- und Atmosphärenoptionen.

Enthaltene Inhalte

Ein Dorfstart von etwa zwei Minuten, eine sechs- bis achtminütige Route, ein zweiminütiger optionaler Nebenraum, ein drei- bis vierminütiger Bossabschnitt und ein kurzer Ausblick. Keine zusätzlichen Welten. Eine kleine voll ausgearbeitete Umgebung dient als Maßstab für die spätere Assetproduktion.

Abnahmekriterien

1. Mindestens 80 Prozent einer kleinen Testgruppe verstehen Sprung, Schuss und ersten Faden ohne mündliche Anleitung. Das ist ein Screeningziel, keine statistische Marktstudie.
2. Der erste Boss ist von Neulingen nach Lernen der Muster erreichbar; erfahrene Spielende erkennen einen Vorteil durch saubere Bewegung.
3. Kein Pflichtsprung verlangt Zielhilfe, Talisman oder verstecktes Upgrade.
4. Aus 50 gezielten Fadenabbrüchen, Stürzen und Neustarts entsteht kein Softlock.
5. Speichern, Beenden und erneutes Starten erhält alle zugesagten permanenten Zustände.
6. Das gesamte Erlebnis funktioniert ohne Tastatur und Maus.
7. Grafik, Sound und Bewegung werden im Spiel und nicht nur im Standbild als zusammengehörig wahrgenommen.
8. Der definierte Referenz-PC erfüllt das 60-fps-Ziel auch im dichtesten Abschnitt.

Scheitern mehrere Kernkriterien, wird der Slice überarbeitet. Weitere Regionen werden zu diesem Zeitpunkt nicht in hoher Qualität produziert.

7. Phasenplan

Beispiel für ein erfahrenes kleines Kernteam von zwei bis vier Personen während der Vorproduktion. Die Kalenderangaben gelten nicht unverändert für eine Einzelperson am Abend.

Inhaltsproduktion nie als 24 unabhängige kleine Projekte behandeln. Zuerst eine vollständige grobe Spielreise herstellen, damit Schwierigkeitsverlauf, Freischaltungen und Länge prüfbar sind. Danach jeweils ein Gebiet fertigstellen, ohne die Gesamtstrecke aus dem Blick zu verlieren.

8. Aufwand und Kosten als transparente Szenarien

Slice: als erste Schätzung etwa 600–1.000 produktive Arbeitsstunden über Technik, Design, Art, Animation und Audio, sofern Erfahrung und wiederverwendbare Werkzeuge vorhanden sind. Bei 20 Stunden pro Woche einer Einzelperson entspricht das rechnerisch 30–50 Wochen vor zusätzlichen Lern- und Abstimmungszeiten. Ein einfacher Mechanikprototyp ist deutlich kleiner und sollte in 40–80 konzentrierten Stunden eine erste Antwort liefern.

Vollfassung in der beschriebenen Qualität: Beispielannahme sechs bis acht Vollzeitäquivalente über 18–24 Monate: 108–192 Personenmonate. Bei rein angenommenen Vollkosten von 7.000–11.000 Euro pro Personenmonat ergibt sich eine Bandbreite von etwa 756.000–2.112.000 Euro, mit 20 Prozent Reserve etwa 907.000–2.534.000 Euro. Diese Rechnung zeigt die Größenordnung eines Teams; sie ist keine Preisempfehlung, kein Angebot und keine Aussage über garantierte Lieferzeit. Vertrieb, Steuern und Konsolenportierung sind nicht gesondert kalkuliert.

Für private Eigenarbeit entsteht ein anderer Geldfluss, aber der Zeitaufwand verschwindet nicht. KI-Unterstützung kann Entwürfe, Varianten, Routinecode und Dokumentation beschleunigen. Konsistenz, Animation, Spieltests und Integration bleiben reale Arbeit. Ein glaubwürdiges persönliches Budget lässt sich erst aus dem Slice und der eigenen verfügbaren Wochenzeit ableiten.

Empfehlung: Mechanikprototyp → Vertical Slice → kleine abgeschlossene Familienfassung → danach Erweiterung zum Sechs-Regionen-Spiel. Der Nutzerwunsch nach maximaler Ausarbeitung ist im großen Design erfüllt; die Produktion sollte ihre Größe an nachgewiesener Qualität ausrichten.

9. Rollen und Arbeitsverteilung

Benötigte Verantwortungen: Game Direction und Leveldesign; Gameplay-/Tools-Programmierung; Umweltgrafik; Figurenanimation und Effekte; Audio und Musik; QA und Produktion. Eine Person kann mehrere Rollen übernehmen. Trotzdem muss jede Verantwortung ausdrücklich besetzt sein. Externe Unterstützung ist besonders bei Heldenanimation, Soundmix und einzelnen Hintergrund-Landmarken sinnvoll, sobald der Stil feststeht.

Jedes Regionspaket benötigt eine kurze Freigabefolge: Graybox spielbar → Lernziele erfüllt → Kamera geprüft → Art integriert → Audio integriert → Performance und Hilfen getestet. Abnahme erfolgt nicht nach einer Menge gelieferter Bilder, sondern nach dem funktionierenden Level.

10. Testplan

Technische Tests mit echtem Fehlerrisiko

• Save-Migration, unterbrochenes Schreiben und Wiederherstellung.
• Doppelte IDs, fehlende Ankerpartner und nicht erreichbare Spawnpunkte.
• Einmalige Storyfreischaltungen und doppelte Kauftransaktionen.
• Controller-Trennung, Wiederverbindung, Remapping und Menüfokus.
• Fadenablauf mit Figur darauf, inaktiver Anker, Bossphasenwechsel während Treffer.
• Plattformbewegung, Deckenberührung, Sprungpuffer und hoher/niedriger Frameratewechsel.

Spieltests

Früh zunächst ungefähr acht Personen: vier aus dem jüngeren Zielbereich und vier Jugendliche/Erwachsene, jeweils mit unterschiedlicher Erfahrung. Beobachten, nicht vorsagen. Eine erwachsene Begleitperson ist bei jüngeren Kindern dabei. Keine stundenlangen Sitzungen; etwa 20–30 Minuten reichen für den Slice. Später wiederkehrende Tests mit neuen Personen, damit erlernte Fehlerumgehungen nicht als gute Bedienung erscheinen.

Messen: Zeitpunkt des ersten selbstständigen Erfolgs; unklare Todesursachen; versehentliche Fadenwechsel; Hilfenutzung; abgebrochene Versuche; Erinnerbarkeit des Ziels. Danach fragen: „Was wolltest du tun?“, „Was glaubst du, ist passiert?“ und „Würdest du noch einmal spielen?“ Begeisterte Zustimmung allein ist kein Ersatz für beobachtetes Verhalten.

Vollfassungs-Abnahme

Jedes Hauptlevel mit minimal erlaubter Storyausrüstung; alle Pflichtwege ohne optionales Sammeln; alle Profile speichern korrekt; alle Bossphasen mit Hilfen; Textskalierung und Controller-Menüs; Vergleich auf Monitor und Fernseher; kompletter Offline-Durchlauf; keine kritischen Softlocks; geprüfter Installations- und Updateweg. Ton und Bild bleiben auch in den dunklen Kapiteln lesbar.

11. Risiken und konkrete Gegenmaßnahmen

12. Die ersten konkreten Arbeitspakete

13. Definition of Done für das Gesamtspiel

Die gewählte Fassung besitzt einen vollständigen Anfang, eine verständliche Entwicklung und einen befriedigenden Abschluss. Jeder obligatorische Inhalt ist gebaut, gespielt, vertont und getestet. Es gibt keine Platzhalter in wichtigen Figuren, keine stummen Hauptaktionen und keine verwirrenden Menüzustände. Fortschritt ist robust gespeichert. Die jüngsten vorgesehenen Spielenden verstehen die Ziele; erfahrene finden freiwillige Tiefe. Performanceziele sind auf benannter Hardware nachgewiesen. Alle externen Assets besitzen dokumentierte Herkunft und passende Nutzungsbedingungen.

Der vorliegende Plan ist damit die Grundlage für Umsetzung und Diskussion. Er behauptet weder fertige Spielqualität noch einen bereits bestandenen Test. Seine nächste überprüfbare Aussage entsteht im spielbaren Fadenraum.