K-04 · Praxis

Portfolio-Projekte für Games-Bewerbungen: Was Studios sehen wollen

Portfolio-Projekte für Games-Bewerbungen: warum fertig wichtiger ist als ambitioniert, wie du Projekte dokumentierst und welche zu deiner Zielrolle passen.

Portfolio-Projekte für Games-Bewerbungen: Was Studios sehen wollen

Wenn Studios Bewerbungen für Junior-Stellen sichten, entscheidet in der Regel nicht der Lebenslauf und nicht das Anschreiben — es entscheidet das Portfolio. Das ist eine gute Nachricht für alle ohne perfekten Werdegang und eine schlechte für alle, die hoffen, dass Begeisterung allein reicht. Das Portfolio ist der Ort, an dem du nicht behaupten musst, was du kannst, weil man es sehen kann.

Umso erstaunlicher, wie viele Portfolios an denselben, vermeidbaren Fehlern scheitern: unfertige Großprojekte, unklare Rollen in Teamarbeiten, kein Wort darüber, wie die Arbeit entstanden ist. Dieser Artikel zeigt dir, was Studios tatsächlich sehen wollen — und wie du mit überschaubarem Aufwand ein Portfolio baust, das diese Erwartungen trifft.

Fertig schlägt ambitioniert

Der häufigste Portfolio-Fehler ist gleichzeitig der menschlichste: das große Traumprojekt. Das Open-World-Rollenspiel, an dem du seit zwei Jahren baust, fühlt sich wie dein stärkstes Stück an — ist es aber fast nie. Denn aus Sicht des Studios erzählt ein unfertiges Großprojekt vor allem eines: Diese Person fängt Großes an und bringt es nicht zu Ende. Genau diese Eigenschaft ist in einer Produktion gefährlich.

Ein kleines, abgeschlossenes Projekt erzählt die Gegengeschichte. Es beweist, dass du scopen kannst, dass du Entscheidungen triffst, dass du die letzten, mühsamen zwanzig Prozent durchziehst — Menüs, Bugfixes, Spielbarkeit für Fremde. Das sind die Fähigkeiten, die im Studio-Alltag täglich gebraucht werden, und sie sind seltener, als man denkt.

Ein fertiges kleines Projekt beweist mehr als ein ambitioniertes unfertiges.

Praktisch heißt das: Schneide klein zu, und zwar von Anfang an, nicht erst, wenn das Projekt kippt. Ein einzelnes, durchdachtes Level statt einer Kampagne. Eine Spielmechanik, sauber umgesetzt, statt fünf angerissener Systeme. Ein zehnminütiges Spielerlebnis mit Anfang, Ende und einem Moment, der in Erinnerung bleibt. Wenn du eine große Idee liebst, extrahiere das kleinste vorzeigbare Stück daraus — und mach genau das richtig gut. Wie man so ein begrenztes Projekt anlegt, zeigt exemplarisch der Leitfaden zum eigenen Adventure: ein Raum, eine Rätselkette, eine spielbare Demo.

Der Prozess zählt: Case Studies schreiben

Hier trennen sich gute Portfolios von starken. Das Endprodukt zeigt, was du gebaut hast — eine Case Study zeigt, wie du denkst. Und genau das wollen Studios wissen, denn sie stellen niemanden für das ein, was er schon gebaut hat, sondern für das, was er bei ihnen bauen wird.

Eine Case Study ist keine Doktorarbeit. Ein bis zwei Bildschirmseiten pro Projekt, mit Bildern, entlang einer einfachen Struktur:

  1. Ziel und Rahmen. Was sollte das Projekt sein, in welcher Zeit, mit welchen Mitteln?
  2. Deine Rolle. Was genau hast du gemacht — und was nicht?
  3. Zentrale Entscheidungen. Zwei, drei Stellen, an denen du etwas abgewogen hast. Warum diese Mechanik? Warum dieser Stil? Was hast du verworfen?
  4. Probleme und Lösungen. Was ging schief, und wie bist du damit umgegangen? Ehrlichkeit wirkt hier stärker als Glanz.
  5. Ergebnis und Learnings. Was würdest du heute anders machen?

Besonders der vierte Punkt wird unterschätzt. Wer schreibt „das Puzzle-Design hat im Playtest nicht funktioniert, hier ist, was ich geändert habe und warum”, demonstriert genau die Reflexionsfähigkeit, die man von guten Teammitgliedern erwartet. Fehlerlose Projektberichte glaubt ohnehin niemand.

Schreib die Case Study zeitnah, solange die Entscheidungen frisch sind — wer sie Monate später rekonstruiert, produziert glatte Nacherzählungen statt echter Einblicke. Und halte die Form schlank: aussagekräftige Bilder, kurze Absätze, Zwischenüberschriften. Eine Case Study, die selbst gut gestaltet ist, ist nebenbei ein weiterer Arbeitsbeleg.

Teamprojekte: Rollenklarheit ist Pflicht

Teamprojekte gehören ins Portfolio — Spieleentwicklung ist Teamarbeit, und wer zeigen kann, dass er in einer Gruppe funktioniert, hat einen Vorteil. Aber es gilt eine harte Regel: Deine Eigenleistung muss eindeutig erkennbar sein.

„Mitgearbeitet an einem 3D-Plattformer” sagt nichts. „Leveldesign für zwei der fünf Level, dazu das Checkpoint-System konzipiert und in der Engine umgesetzt; Programmierung und Art kamen von zwei Teammitgliedern” sagt alles. Nenne dein Team beim Namen oder verlinke es — das ist nicht nur fair, es signalisiert auch, dass du nichts zu verschleiern hast. Nichts beschädigt eine Bewerbung schneller als der Eindruck, jemand schmücke sich mit der Arbeit anderer; im Zweifel fragt das Studio im Gespräch ohnehin nach Details.

Rollenklarheit hat noch einen zweiten Vorteil: Sie macht Schwächen unschädlich. Wenn die Grafik des Teamprojekts nicht dein Werk ist, musst du sie nicht verteidigen — und deine tatsächliche Leistung steht umso schärfer da. Unklare Zuschreibungen dagegen lassen dich für alles haften, auch für das, was andere verbockt haben.

Projekte nach Zielrolle auswählen

Ein Portfolio ist keine Werkschau, sondern ein Argument für eine bestimmte Rolle. Dieselben Projekte können je nach Aufbereitung für verschiedene Rollen sprechen — aber die Auswahl und Betonung sollte zur Stelle passen, auf die du dich bewirbst.

ZielrolleDas sollten deine Projekte zeigenTypische Formate
Game / Level DesignSysteme, Pacing, dokumentierte EntscheidungenSpielbare Prototypen, Level mit Design-Notizen
ArtStilsicherheit, Bandbreite, Verständnis für Spiele-PipelinesSpielfertige Assets, Environments, Konzeptserien
ProgrammierungSauberer Code, funktionierende Builds, ProblemlösungSpielbare Demos plus einsehbarer Quellcode
NarrativeDialog, Struktur, Erzählen in InteraktionInteraktive Textspiele, Dialogszenen, Quest-Designs

Quer durch alle Rollen gilt: Lieber zwei bis vier kuratierte Stücke als ein Sammelalbum. Studios schauen meist nur die ersten Projekte an — dein schwächstes Stück bestimmt den Eindruck stärker mit, als dir lieb ist. Wenn ein Projekt nicht für deine Zielrolle spricht, fliegt es raus, egal wie viel Arbeit drinsteckt.

Das heißt nicht, dass du für jede Rolle neue Projekte brauchst. Oft genügt es, dieselben Arbeiten anders zu rahmen: Für eine Design-Bewerbung stellst du beim Jam-Spiel die Mechanik-Entscheidungen nach vorn, für eine Narrative-Stelle die Dialogszenen. Das Material bleibt, der Schwerpunkt wandert.

Präsentation: auffindbar, spielbar, ohne Hürden

Das beste Projekt nützt nichts, wenn niemand es in dreißig Sekunden erleben kann. Die Messlatte ist einfach: Eine fremde Person mit wenig Zeit muss ohne Anleitung zum Spielen oder Anschauen kommen.

  • Mach es spielbar mit einem Klick. Eine bekannte Plattform wie itch.io ist dafür ein bewährter Ort — Studios kennen sie, und der Weg vom Link zum Spiel ist kurz. Browser-spielbare Versionen senken die Hürde zusätzlich.
  • Biete ein kurzes Video als Fallback. Nicht jeder lädt einen Build herunter. Ein bis zwei Minuten Gameplay zeigen das Wesentliche auch dem eiligsten Betrachter.
  • Bündle alles an einem Ort. Eine schlichte Portfolio-Seite mit Projekten, Case Studies und Kontakt reicht. Design-Feuerwerk ist unnötig — Klarheit gewinnt.
  • Teste jeden Link. Tote Links und kaputte Builds sind vermeidbare Disqualifikatoren. Prüfe vor jeder Bewerbung einmal alles durch, am besten auf einem fremden Gerät.

Ein letzter Punkt zur Reihenfolge: Dein stärkstes Projekt steht ganz oben, ohne Umwege erreichbar. Viele Sichtungen enden nach dem ersten Eindruck — wenn der sitzt, bekommt der Rest überhaupt erst eine Chance. Sortiere also nicht chronologisch, sondern nach Wirkung, und überprüfe die Reihenfolge bei jeder Bewerbung neu gegen die ausgeschriebene Rolle.

Und wenn dir noch Material fehlt: Die schnellste Quelle für fertige, dokumentierbare Projekte sind Game Jams — ein Wochenende, ein abgeschlossenes Spiel, eine fertige Geschichte für die nächste Case Study.

Nächster Schritt

Nimm dein bestes vorhandenes Projekt — und wenn es ein raues Jam-Spiel ist — und schreib diese Woche die erste Case Study dazu: Ziel, Rolle, zwei Entscheidungen, ein Problem samt Lösung, ein Learning. Eine Stunde konzentrierter Arbeit reicht für den ersten Entwurf, und damit hat dein Portfolio bereits mehr Substanz als die meisten Bewerbungen, die Studios täglich auf den Tisch bekommen.

Rückfragen

F-01Wie viele Projekte sollte mein Games-Portfolio enthalten?

Weniger, als die meisten denken: Zwei bis vier fertige, dokumentierte Projekte sind in der Regel stärker als acht halbfertige. Studios haben wenig Zeit pro Bewerbung und schauen sich meist nur die ersten Stücke an. Kuratiere streng – jedes schwache Projekt im Portfolio verwässert den Eindruck der starken.

F-02Müssen Portfolio-Projekte fertige Spiele sein?

Sie müssen abgeschlossen sein, nicht groß. Ein spielbarer Prototyp mit klarem Anfang und Ende zählt als fertig, ein abgebrochenes Großprojekt nicht. Studios lesen aus fertigen Projekten die wichtigste Eigenschaft heraus: dass du Dinge zu Ende bringst. Ein Level, ein Puzzle-Set oder ein Jam-Spiel können völlig ausreichen.

F-03Was ist eine Case Study im Portfolio und brauche ich sie?

Eine Case Study ist eine kurze schriftliche Aufbereitung eines Projekts: Ziel, deine Rolle, zentrale Entscheidungen, Probleme und Lösungen, Ergebnis. Sie zeigt, wie du denkst – und genau das interessiert Studios oft mehr als das Endprodukt. Ein bis zwei Bildschirmseiten pro Projekt mit Bildern reichen meist völlig.

F-04Wie gehe ich mit Teamprojekten im Portfolio um?

Teamprojekte sind willkommen, aber deine Rolle muss glasklar sein. Schreib präzise, was du beigetragen hast: welche Level, welche Systeme, welche Assets. Unklare Formulierungen wie 'mitgearbeitet an' wirken schnell so, als würdest du dich mit fremden Federn schmücken. Konkrete Eigenleistung plus Nennung der Teammitglieder wirkt professionell.

F-05Welche Projekte passen zu welcher Zielrolle?

Richte das Portfolio an der Rolle aus: Angehende Designer zeigen Systeme, Level und dokumentierte Entscheidungen, Artists zeigen stilistische Bandbreite und Werkverständnis, Programmierer sauberen Code und funktionierende Builds, Narrative-Bewerber Dialoge und interaktive Texte. Ein Projekt kann mehrere Facetten haben – aber die Präsentation sollte die Zielrolle betonen.

F-06Wo veröffentliche ich meine Portfolio-Projekte am besten?

Spielbare Projekte stellst du am einfachsten auf eine bekannte Plattform wie itch.io, dazu eine eigene Portfolio-Seite, die Projekte und Case Studies bündelt. Wichtig ist, dass alles ohne Hürden erreichbar ist: ein Klick zum Spielen oder Video, kein Login, keine toten Links. Teste jeden Link, bevor du dich bewirbst.

F-07Zählen Game-Jam-Spiele als richtige Portfolio-Projekte?

Ja, sogar besonders gut. Jam-Spiele beweisen, dass du unter Zeitdruck scopen, entscheiden und abschließen kannst – alles Eigenschaften, die Studios täglich brauchen. Niemand erwartet von einem Wochenend-Projekt Politur. Mit einer kurzen Case Study aufbereitet, wird aus einem rauen Jam-Spiel ein starkes Portfolio-Stück.

F-08Sollte ich ein großes Traumprojekt ins Portfolio aufnehmen?

Nur wenn es fertig ist – und das ist bei großen Traumprojekten selten der Fall. Ein unfertiges Großprojekt sendet das falsche Signal: viel Ambition, wenig Abschluss. Besser ist, du schneidest aus der großen Idee ein kleines, abschließbares Stück heraus und machst genau das richtig gut.

F-09Wie aktuell müssen die Projekte im Portfolio sein?

Es gibt keine feste Verfallszeit, aber das Portfolio sollte deinen aktuellen Stand zeigen. Wenn dein neuestes Stück mehrere Jahre alt ist, stellt sich die Frage, was du seitdem gemacht hast. Ergänze regelmäßig Neues und entferne Älteres, das nicht mehr deinem Niveau entspricht – Kuratieren ist Teil der Arbeit.