Wie du ein Mitwirkenden-Handoff für Game Artists, Komponist:innen und Designer:innen schreibst

Ein Mitwirkenden-Handoff ist das Paket an Kontext, das jemand braucht, bevor er oder sie sinnvoll an deinem Spiel arbeiten kann. Für Artists, Komponist:innen, Audio Designer:innen und Game Designer:innen ist es der Unterschied zwischen kreativer Partnerschaft und Ticket-Queue.

Am Ende dieses Guides hast du ein einseitiges Handoff-Format, das du nutzen kannst, bevor du jemanden nach Sprites, Musik, UI, Level-Feedback, Mechanik-Tuning oder Sound-Implementation fragst. Das Ziel ist einfach: genug Kontext für gute Entscheidungen, genug Constraints gegen Verschwendung und genug schriftliche Struktur, um beide Seiten zu schützen.

Bevor du anfängst

Du brauchst kein vierzigseitiges Game Design Document, bevor du eine:n Mitwirkende:n reinholst. Du brauchst aber genug Projektrealität, damit die Person nicht raten muss.

Halte das bereit, bevor du das Handoff schreibst:

• Einen spielbaren Build, eine Videoaufnahme, einen Prototyp oder ein Mockup.
• Einen Satz, der das Spiel ohne Lore erklärt.
• Den aktuellen Projektstand: Prototyp, Vertical Slice, Produktion, Polish, Launch.
• Die entscheidende Person für dieses Handoff.
• Ein grobes Budget oder Beitragsmodell.
• Einen Ort, an dem Entscheidungen leben, zum Beispiel Notion, Trello, Linear, GitHub Issues oder ein geteiltes Dokument.

Wenn du nur "Ich brauche einen Artist" oder "Ich brauche Musik" hast, stopp. Du hast noch kein Mitwirkenden-Handoff. Du hast einen Wunsch.

1. Benenne den Mitwirkenden-Job präzise

Der erste Job eines Handoffs ist, die Arbeit zu trennen. "Art" ist kein Task. "Audio", "Design" oder "mach es besser" auch nicht.

Ein brauchbares Handoff beginnt mit Rolle und Job:

• 2D Character Artist für ein Enemy-Animation-Set.
• Komponist:in für einen dreißigsekündigen Combat Loop und einen Menu Loop.
• Sound Designer:in für Player Movement, Hit Confirmation und UI Feedback.
• Level Designer:in für einen ersten Blockout des Tutorial-Raums.
• Systems Designer:in für Economy-Tuning der ersten zehn Minuten.
• UI Artist für HUD-Lesbarkeit und Icon-Behandlung.

Das klingt banal. Genau dort fallen die meisten Indie-Projektanfragen auseinander.

Tim Ruswick hat in einem Transcript über das Anheuern von Artists eine gute stumpfe Zeile: "most people don't know what they want." Sein praktischer Rat: Mach zuerst selbst eine grobe Version, auch wenn sie hässlich ist. Wenn du eine Jump-Animation brauchst, blocke eine Strichfiguren-Version rein. Wenn du Combat-Audio brauchst, nimm einen furchtbaren Mundgeräusch-Pass über einer Bildschirmaufnahme auf. Wenn du UI brauchst, skizziere Boxen auf einen Screenshot.

Du machst das nicht, weil deine Version gut ist. Du machst es, damit die mitwirkende Person die Form des Problems sieht.

Achtung bei: Wenn dein Handoff "mach das besser" sagt, schreib es neu. Besser wie? Schneller lesbar? Klarere Silhouette? Stärkerer emotionaler Ton? Weniger matschiger Mix? Kürzerer Loop? Geringere Speichernutzung? Die Antwort verändert, wen du brauchst und was geliefert werden soll.

2. Gib Projektkontext vor der Asset-Liste

Kreative Mitwirkende können aus einer Asset-Liste allein keine guten Entscheidungen treffen. Sie müssen wissen, was das Spiel beim Player auslösen soll und was rund um die Arbeit schon existiert.

Für Artists heißt Kontext: Genre, Kamera, Plattform, Auflösung, visuelle Referenzen, Animationsbedarf, Zielgruppe und Gameplay-Funktion des Assets. MLC Studios Guide zu einem Game Art Brief macht denselben Punkt: Mechaniken und Kamera zählen, weil die Art im Spiel funktionieren muss, nicht nur isoliert hübsch aussehen.

Bei Audio lässt sich Kontext noch leichter überspringen, weil Asset-Namen eindeutig klingen. "Jump sound" fühlt sich ausreichend an, bis Komponist:in oder Sound Designer:in fragt: schwerer oder leichter Character? Cartoon oder grounded? Spielt der Sound bei jedem Jump, nur bei charged Jumps oder nur bei Landings? Muss er durch Musik schneiden? Wird er durch Animation, Physik oder State Change getriggert?

Akash Thakkar nutzt das Joshua-Bell-Subway-Experiment für einen Karrierepunkt über Demo Reels, aber die Lektion passt sauber auf Handoffs: Kontext verändert, wie Menschen kreative Arbeit bewerten und interpretieren. Droppe Audio in den falschen Kontext und selbst gute Arbeit liest falsch.

Dein Handoff sollte enthalten:

1. Das Spiel in einem Satz. Kein Lore-Dump. Keine Genre-Suppe.
2. Player Fantasy. Was soll der Player fühlen, wenn er oder sie mit diesem Feature interagiert?
3. Aktueller Build-Stand. Prototyp, Vertical Slice, Produktion oder Polish.
4. Bestehende Referenzen. Screenshots, Clips, Moodboards, Musikreferenzen, Mechanikbeispiele.
5. Non-Goals. Was daraus nicht werden soll.
6. Wo es auftaucht. Level, Menu, Combat State, Cutscene, Boss, Onboarding, Trailer, Steam Page.

Die Non-Goals-Zeile zählt. "Nicht cute", "nicht orchestral", "nicht high contrast", "keine weitere Währung" und "kein kompletter Rework" sparen mehr Zeit als zehn weitere Referenzbilder.

3. Definiere Constraints vor Geschmack

Geschmacksdiskussionen werden teuer, wenn Constraints fehlen.

"Kannst du es punchier machen?" ist eine schlechte erste Feedback-Notiz, wenn der Composer nicht wusste, dass der Loop unter dauernden Weapon SFX sitzen muss. "Kannst du es lesbarer machen?" kommt zu spät, wenn der Artist nicht wusste, dass das Sprite auf Switch mit 64 Pixeln Höhe gerendert wird. "Kannst du die Economy weniger grindy machen?" ist vage, wenn der Designer keine Retention-Ziele, Session Length oder Reward-Timing hat.

Schreib die Constraints ins Handoff, bevor subjektives Feedback beginnt.

Für Artists:

• Canvas Size oder Model Budget.
• Dateiformat und Layer-Erwartungen.
• Animationsanzahl und Frame Count.
• Palette, Lighting, Kamera und Lesbarkeits-Constraints.
• Engine-Import-Regeln.
• Welche bestehenden Assets es matchen muss.

Für Komponist:innen und Audio Designer:innen:

• Länge, Loop-Verhalten, Stems, Loudness-Ziele und Exportformat.
• Middleware- oder Engine-Implementation-Bedarf.
• Trigger Conditions und Game States.
• Mix-Prioritäten: was durchschneiden muss und was im Hintergrund bleiben darf.
• Ob die Person Implementation übernimmt oder nur Assets erstellt.

Für Designer:innen:

• Player Goals, Metriken, Tuning Range, aktuelles Build-Verhalten.
• Berührte Systeme und Systeme, die off-limits sind.
• Datenformat, Spreadsheet-Struktur oder Engine-Zugang.
• Was als akzeptiert zählt: Paper Spec, spielbarer Prototyp, Balancing Pass oder shipped Values.

A Sound Effects Game-Audio-Task-Planning-Guide hat hier einen brauchbaren Standard: Tasks sollten readable, trackable, purposeful und accountable sein. Das ist die Messlatte für jedes Mitwirkenden-Handoff, nicht nur für Audio.

Achtung bei: Wenn der erste bedeutungsvolle Constraint erst nach der ersten Lieferung auftaucht, bist du nicht am Revidieren. Du korrigierst ein schlechtes Handoff.

4. Mach aus dem Handoff eine gehörende Aufgabe, keine vage Rolle

Kleine Indie-Projekte lieben geteilte Verantwortung, bis etwas rutscht.

"Alex und Mina besitzen Art Direction" klingt gemeinschaftlich. Meistens bedeutet es, dass niemand weiß, wer das Sprite abzeichnet. Ein Projektmanagement-Transcript im Repo sagt es sauber: "if two people are accountable for something then no one is accountable for it."

Nutze ein Handoff pro gehörende Aufgabe. Die Card kann alle Beteiligten erwähnen, aber sie braucht einen Owner und eine:n Reviewer:in.

Eine gute Task-Card hat:

Feld	Beispiel
Owner	Mina
Reviewer	Alex
Dependency	Combat-Prototype-Video, Enemy-State-Chart
Deliverable	Eine Enemy-Attack-Animation, 12 Frames, layered Source + exportierter PNG-Sheet
Acceptance Criteria	Lesbar bei 64px, Wind-up-Frame fuer 200ms sichtbar, Export importiert in Unity ohne Slicing-Fixes
Due Date	Freitag, 29. Mai
Review State	In Review vor Done

Dieser "In Review"-State zählt. Done durch die mitwirkende Person und akzeptiert durch das Projekt sind zwei verschiedene Momente. Wenn dein Board nur "To Do, Doing, Done" hat, muss die mitwirkende Person raten, ob Done hochgeladen, getestet, integriert, akzeptiert oder shippable bedeutet.

Bei Audio können Acceptance Criteria ein Video enthalten, das zeigt, welcher Sound wann triggern soll, dazu Repro Steps, State Names und ein Build Check. Der Guide von A Sound Effect empfiehlt genau so einen Drittcheck, weil jemand anderes damit das Ergebnis bestätigen kann, ohne dass die ursprüngliche Audio-Person alles live erklären muss.

Bei Design können Acceptance Criteria ein Playtest-Script, eine Before-and-after-Tuning-Tabelle oder ein kurzer Loom sein, der das neue Verhalten im Kontext zeigt.

Achtung bei: Schreib nie "final art pass" oder "audio polish" auf eine Card, wenn die Card nicht sagt, welche Assets, welche Scenes, welcher Owner, welche Acceptance Criteria und welche Review-Person gemeint sind.

5. Halte Rechte, Credit und Portfolio-Nutzung früh schriftlich fest

Das Handoff geht nicht nur um kreativen Kontext. Es muss auch die unangenehmen Fragen beantworten, bevor jemand wertvolle Arbeit macht.

Artists und Komponist:innen wurden von toten Projekten, vagem Upside und Portfolio-Beschränkungen verbrannt. Die Customer Research in diesem Repo hat die relevante Zeile: "Artists can typically only showcase their work on personal portfolios for shipped games, not cancelled ones." Wenn dein Spiel stirbt und die mitwirkende Person die Arbeit nicht zeigen darf, hast du nicht nur ihre Zeit verschwendet. Du hast den Beweis eingeschlossen, dass sie die Arbeit gemacht hat.

Deine Contributor Terms müssen keine juristische Kathedrale sein. Sie müssen schriftlich sein.

Decke ab:

• Was die mitwirkende Person erstellt.
• Bezahlung, Upside oder andere Gegenleistung.
• Wem die Arbeit gehört oder welche Lizenz das Projekt erhält.
• Ob die mitwirkende Person die Arbeit im Portfolio zeigen darf.
• Credit-Formulierung.
• Revisionsgrenzen.
• Was passiert, wenn das Projekt steckenbleibt oder die mitwirkende Person geht.
• Was passiert, wenn das Projekt shippt, portiert wird, wächst oder ein Sequel bekommt.

Legal GPS' 2026-Zusammenfassung für ein Audio Engineer and Sound Design Agreement listet dieselben praktischen Eimer: Scope, technische Spezifikationen, Ownership Rights, Revisionsgrenzen, Payment Structure, Credit, Portfolio Usage, Milestones und schriftliche Amendments. Für echte Verträge brauchst du echte Rechtsprüfung, aber die Checkliste ist der Punkt.

Mach das vor dem ersten bedeutungsvollen Deliverable. "Das Papierzeug regeln wir später" schiebt das Risiko auf die mitwirkende Person mit der geringsten Verhandlungsmacht.

Wenn du genau diesen Teil vermeidest, lies How to Spot Rev-Share Red Flags Before You Join an Indie Game Project und Working as a Game Composer for Free. Beide Posts existieren, weil sich diese Probleme wiederholen.

6. Lege den Feedback-Loop vor der ersten Lieferung fest

Feedback ist der Ort, an dem ein Handoff entweder Vertrauen aufbaut oder zu Scope Creep wird.

Entscheide den Feedback-Loop vor der ersten Lieferung:

• Wer gibt finales Feedback?
• Wo lebt Feedback?
• Wie oft findet Review statt?
• Wie viele Revisionsrunden sind enthalten?
• Welche Art Feedback erzeugt einen neuen Task, statt diesen Task zu verändern?
• Was passiert, wenn Feedback kollidiert?

Ein:e Reviewer:in schlägt fünf Drive-by-Kommentare. Ein wöchentliches Review schlägt laufende Slack-Pings. Schriftliches Feedback schlägt einen Voice Call, an den sich alle halb anders erinnern.

A Sound Effect warnt, dass formales Feedback verhindern sollte, dass Actions zu Add-ons auf dem Original-Task werden. Genau daran scheitern kleine Projekte. Jemand fragt nach "einem kleinen Tweak", dann nach noch einem, dann nach noch einem, und die mitwirkende Person merkt, dass der Task nicht mehr zur Vereinbarung passt.

Nutze diese Regel: Feedback darf den Task klären, aber es darf ihn nicht still erweitern.

Wenn der Composer einen Stinger ergänzen soll, der Artist einen zusätzlichen Hit Frame erstellen soll oder die Designerin ein zweites System rebalancen soll, mach eine neue Card. Hänge sie an den ursprünglichen Task, wenn nötig. Gib ihr eigenen Owner, eigenen Scope und eigene Acceptance Criteria.

Achtung bei: "Wenn du eh drin bist" ist meistens unbezahlte Scope-Erweiterung mit freundlicher Maske.

7. Halte das Handoff lebendig, wenn sich das Projekt ändert

Game-Projekte bewegen sich. Mechaniken ändern sich. Characters werden gestrichen. Eine Scene wechselt von Wald zu Fabrik. Der Audio Trigger zieht vom Animation Event in die State Machine. UI bekommt einen neuen Constraint, weil Steam-Deck-Text unlesbar ist.

Das heißt nicht, dass das Handoff gescheitert ist. Es heißt, dass das Handoff gepflegt werden muss.

Aktualisiere es, wenn:

• Eine Dependency sich ändert.
• Eine Referenz akzeptiert oder verworfen wird.
• Ein Deliverable in kleinere Tasks gesplittet wird.
• Die Review-Person wechselt.
• Eine technische Anforderung sich ändert.
• Eine Entscheidung Rechte, Credit, Scope, Timeline oder Budget betrifft.
• Ein Stück Arbeit akzeptiert wurde.

Das Game Design Document wird oft als lebendiges Dokument beschrieben, weil Game Development sich verändert, sobald Produktion das echte Projekt freilegt. Dein Mitwirkenden-Handoff ist die kleine Version davon. Stabil genug, um Chaos zu verhindern. Lebendig genug, um wahr zu bleiben.

Hier helfen strukturierte Rituale. Ein wöchentlicher Accountability Call, eine In-Review-Spalte und ein kurzes Decision Log helfen Mitwirkenden mehr als noch ein Discord-Channel. Wenn dein aktuelles Setup ein Chatraum mit gepinnten Nachrichten ist, lies als Nächstes Discord Server vs. Game Dev Team.

8. Nutze diese Mitwirkenden-Handoff-Vorlage

Kopiere das in ein Dokument, Issue oder eine Project Card. Halte es kurz. Eine Seite ist das Ziel.

## Mitwirkenden-Handoff

### Projektkontext
- Spiel:
- Aktueller Stand:
- One-sentence pitch:
- Player Fantasy:
- Plattform/Kamera/Engine:
- Relevanter Build, Video oder Screenshot:
- Non-Goals:

### Mitwirkenden-Job
- Rolle:
- Task:
- Owner:
- Reviewer:
- Due Date:

### Constraints
- Format:
- Masse, Laenge, Budget oder Datenform:
- Engine-, Middleware- oder Import-Anforderungen:
- Bestehende Assets oder Systeme, die gematcht werden muessen:
- Dependencies:
- Off-limits-Aenderungen:

### Referenzen
- Referenz 1:
- Was davon kopiert werden soll:
- Was davon nicht kopiert werden soll:
- Referenz 2:
- Was davon kopiert werden soll:
- Was davon nicht kopiert werden soll:

### Deliverables
- Files oder Spec:
- Source Files:
- Exported Files:
- Implementation-Verantwortung:
- Acceptance Criteria:

### Terms
- Payment oder Beitragsmodell:
- Ownership oder Lizenz:
- Portfolio-Nutzung:
- Credit:
- Revisionslimit:
- Kill-, Pause- oder Exit-Terms:

### Feedback
- Review-Kadenz:
- Feedback-Ort:
- Finaler Decision-Maker:
- Was als neuer Task zählt:

### Offene Fragen
- Frage 1:
- Frage 2:

Die Vorlage ist mit Absicht langweilig. Langweilig schützt die Arbeit.

Was du als Nächstes tust

Wenn die nächste mitwirkende Person ein Artist ist, lies How to Work With a Game Artist on Your Indie Project. Wenn die nächste Person komponiert, lies Working as a Game Composer for Free, bevor du etwas schreibst, das nach Exposure riecht. Wenn das Problem Kadenz ist, gibt dir Accountability Circles das wöchentliche Ritual.

Der größere Punkt ist strukturell. Artists, Audio-Leute und Designer:innen werden nicht zu Service Desks, weil ihnen Meinungen fehlen. Sie werden zu Service Desks, wenn das Projekt ihnen keinen Kontext, keine Rechteklarheit, keine Feedback-Grenze und keine Möglichkeit gibt, die Arbeit früh mitzuformen.

Clowdr ist für das Gegenteil gebaut: Mitwirkende übernehmen gescopte Tasks, behalten ihre Rechte, arbeiten mit schriftlichen Vereinbarungen und shippen in einer Struktur, in der jemand bis Freitag auf die Arbeit zählt.

Melde dich für Clowdr an, wenn du willst, dass Mitwirkende mit Kontext in dein Projekt kommen statt mit Ratespiel.