Nicht die Engine entscheidet, sondern das fertige kleine Spiel
Wer zwei Jahre Tutorials sammelt, hat am Ende zwanzig Projektordner und keinen einzigen Beleg, während ein einziges abgeschlossenes Mini-Projekt jedes Gespräch trägt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Einstieg scheitert selten am Können, sondern am Zuschnitt des ersten Projekts
Die meisten Einsteiger fangen mit dem Spiel an, das sie selbst spielen wollen, und das ist fast immer eines mit offener Welt, Mehrspielerbetrieb, Inventar und Speicherständen. Jedes dieser vier Themen ist für sich ein eigenes System mit eigenen Fallstricken, und zusammen ergeben sie ein Vorhaben, das auch ein besetztes Team über Jahre beschäftigt. Nach ein paar Monaten steht dann eine Landschaft, in der eine Spielfigur laufen kann, und sonst nichts.
Der zweite Bruch entsteht an der Stelle, an der aus einem Prototyp ein Spiel wird. Ein Prototyp braucht keinen Startbildschirm, keine Pause, keine Speicherung, keine Eingabebelegung für ein Gamepad, keine Fehlerbehandlung beim Laden und keinen Build, der auf einem fremden Rechner startet. Genau diese Teile machen erfahrungsgemäß den größeren Teil der Arbeit aus, und sie sind der Teil, den Einsteiger nie geübt haben, weil sie vorher immer abgebrochen haben.
Das kostet nicht nur Zeit, es kostet die Bewerbung. Studios und Auftraggeber lesen ein Portfolio danach, ob jemand etwas zu Ende bringen kann und ob erkennbar ist, welcher Anteil von ihm stammt. Zehn angefangene Projekte belegen Neugier, ein abgeschlossenes kleines Spiel belegt Arbeitsfähigkeit, und zwischen beidem liegt die Einladung zum Gespräch.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ein Weg in die Rolle, der an jedem Punkt etwas Vorzeigbares erzeugt
Die Reihenfolge ist bewusst so gewählt, dass nach jedem Schritt etwas existiert, das man jemandem zeigen kann. Wer zuerst monatelang lernt und erst danach baut, hat nach einem Jahr Wissen ohne Beleg.
- 1
Eine Engine wählen und dabei bleiben
Unreal Engine mit Blueprints und C++, Godot mit GDScript, oder eine kleinere Umgebung mit Lua als Skriptsprache: alle drei tragen weit genug. Der Wechsel nach vier Wochen kostet dich die Vertrautheit, die den eigentlichen Unterschied macht.
Geschafft, wenn: Du findest Projekteinstellungen, Import und Build, ohne zu suchen
- 2
Ein winziges Spiel wirklich zu Ende bringen
Eine Mechanik, drei kurze Abschnitte, ein Startbildschirm und ein Endbildschirm mit Neustart. Das klingt nach wenig und enthält alle Zustandswechsel, die ein großes Spiel auch hat.
Geschafft, wenn: Jemand kann das Spiel starten, verlieren, neu beginnen und beenden
- 3
Assets einmal komplett durch die Pipeline schicken
Modell in Blender bauen, Maßstab und Pivot festlegen, UVs anlegen, texturieren, exportieren, importieren, Material zuweisen. Erst dabei merkst du, welche Einstellungen später Ärger machen.
Geschafft, wenn: Ein eigenes Modell steht mit richtiger Größe und Ausrichtung in der Szene
- 4
Versionsverwaltung und Ablage aufsetzen
Ein Projekt mit Assets ist kein Quelltextprojekt. Große Binärdateien brauchen eine passende Ablage und klare Absprachen, wer welche Datei ändert, sonst ist die erste Zusammenführung auch die letzte.
Geschafft, wenn: Du kannst einen Stand von gestern wiederherstellen, ohne Dateien zu kopieren
- 5
Das Spiel von Fremden testen lassen
Drei Personen, die dein Spiel nicht kennen, spielen ohne Kommentar von dir. Notiere jede Stelle, an der jemand zögert, etwas übersieht oder das Falsche versucht.
Geschafft, wenn: Eine Liste konkreter Stellen statt eines allgemeinen Gefühls
- 6
Bildrate und Ladezeit einmal ernsthaft anfassen
Miss, bevor du optimierst. Meist stecken die Kosten in wenigen Stellen: zu viele Einzelobjekte, zu große Texturen, Berechnungen in jedem Bild, die auch einmal pro Sekunde genügen würden.
Geschafft, wenn: Du kannst benennen, welche Änderung wie viele Millisekunden gebracht hat
- 7
Das Portfolio auf drei Belege zuschneiden
Zu jedem Beleg gehört, was das Ziel war, was du selbst gebaut hast und was du beim nächsten Mal anders machen würdest. Der letzte Punkt wirkt im Gespräch stärker, als die meisten glauben.
Geschafft, wenn: Bei jedem Stück ist in einer Minute erkennbar, was dein Anteil war
Sechs Aufgaben, die in einem Spiel zusammenkommen
- 01 Gameplay-Programmierung baut die Regeln, die das Spiel überhaupt spielbar machen.
- 02 Werkzeug- und Systemarbeit sorgt dafür, dass das Team schnell iterieren kann.
- 03 Technical Art verbindet die Assets mit der Engine und hält die Bildrate.
- 04 Leveldesign entscheidet über Reihenfolge, Tempo und Schwierigkeit.
- 05 Audio trägt einen großen Teil der Wirkung und wird meist zu spät begonnen.
- 06 Qualitätssicherung findet die Fehler, die niemand im eigenen Projekt sieht.
Was dich vom Dauerläufer im Tutorial unterscheidet
Die Fähigkeiten, die im Alltag der Rolle zählen, haben wenig mit der Zahl der beherrschten Engines zu tun. Es sind Entscheidungen über Umfang, Struktur und Übergabepunkte, und man lernt sie nur an einem Projekt, das man tatsächlich abschließt.
Den Umfang so wählen, dass ein Ende in Sicht ist
Ein Spiel mit einer Mechanik, drei Ebenen und einem Endbildschirm ist ein vollständiges Werk. Es zwingt dich durch Menü, Zustandswechsel, Neustart und Build, also genau durch die Teile, an denen große Vorhaben scheitern.
Spiellogik von Darstellung trennen
Wenn die Regeln des Spiels in denselben Bausteinen stecken wie Animation und Effekte, kannst du nichts austauschen, ohne alles zu prüfen. Diese Trennung ist der einzige Grund, warum spätere Änderungen an einer Mechanik nicht das halbe Projekt anfassen.
Assets so übergeben, dass sie in der Engine sofort stimmen
Maßstab, Achsenausrichtung, Pivot, Namensgebung und UV-Belegung entscheiden darüber, ob ein Modell aus Blender in der Szene richtig steht oder ob es jedes Mal nachjustiert wird. Das ist die häufigste stille Zeitsenke in kleinen Teams.
Versionsverwaltung einrichten, bevor das Projekt wächst
Blueprints und viele Assetformate sind Binärdateien, sie lassen sich nicht sinnvoll zusammenführen. Wer das früh weiß, teilt Arbeitsbereiche auf und spricht ab, wer welche Datei anfasst, statt am Freitag eine Woche Arbeit zu verlieren.
Fremde Leute spielen lassen und dabei schweigen
Der Moment, in dem jemand ohne deine Erklärung vor dem Spiel sitzt, liefert mehr brauchbare Hinweise als jede eigene Durchsicht. Schreib mit, wo jemand stockt, und widersteh dem Drang, die Stelle mündlich zu erklären.
Auf dem Zielgerät bauen, nicht im Editor bewerten
Im Editor läuft vieles, was im Build fehlt: Pfade, Einstellungen, Eingabezuordnungen, Speicherorte. Ein Spiel gilt erst als lauffähig, wenn es jemand ohne installierte Engine startet und beendet.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was im Alltag wirklich passiert, und was Einsteiger erwarten
Die Erwartung ist, dass man Spiele erfindet. Die Arbeit besteht überwiegend darin, Systeme zu bauen und stabil zu halten, die niemand bewusst wahrnimmt: Eingabeverarbeitung, Zustände zwischen Menü und Spiel, Speichern und Laden, Kamera, Benutzeroberfläche, Lokalisierung, Fehlerbehandlung beim Start. Wenn diese Teile gut sind, fällt es niemandem auf. Wenn einer fehlt, wirkt das ganze Spiel unfertig, egal wie gut die Mechanik ist.
Der zweite Teil des Alltags ist Iteration unter Zeitdruck. Eine Idee wird gebaut, gespielt, verworfen und anders gebaut, oft mehrfach, und der Wert eines Entwicklers hängt stark daran, wie schnell dieser Kreis läuft. Deshalb ist Werkzeugarbeit in Studios eine eigene, angesehene Spezialisierung: Wer dem Team eine halbe Stunde Wartezeit pro Durchlauf spart, verändert das Spiel mehr als jemand, der eine einzelne Mechanik schöner macht.
Der dritte Teil ist Zusammenarbeit über Fachgrenzen. Ein Leveldesigner braucht Bausteine, die sich zusammenstecken lassen, ein Artist braucht Vorgaben zu Maßstab und Bildkosten, der Audiobereich braucht Ereignisse, an die er andocken kann. Wer diese Schnittstellen früh verabredet, arbeitet ruhig. Wer sie erst kurz vor einem Meilenstein klärt, verbringt Wochen damit, Dinge nachträglich zusammenzupassen.
Blueprints, Code und der Punkt, an dem man umbaut
In der Unreal Engine lässt sich Spiellogik als Knotengraph zusammenstecken, ohne eine Zeile zu tippen. Das ist keine Spielwiese für Anfänger, sondern der übliche Weg, um Verhalten schnell auszuprobieren, und ganze veröffentlichte Spiele bestehen zu großen Teilen daraus. Der Vorteil ist Geschwindigkeit: Eine Idee ist in Minuten spielbar statt in Stunden.
Der Preis zeigt sich im Team. Ein Blueprint liegt als Binärdatei vor, zwei Personen können ihn nicht gleichzeitig sinnvoll ändern, und in der Versionsverwaltung gibt es keinen brauchbaren Vergleich zweier Stände. Deshalb sperren Teams solche Dateien während der Bearbeitung, teilen Verantwortlichkeiten scharf auf und verlagern zentrale, viel genutzte Logik nach C++, sobald sie sich stabilisiert hat. Die Faustregel in vielen Studios lautet: ausprobieren im Graphen, tragende Systeme im Quelltext.
In Godot stellt sich dieselbe Frage anders. GDScript liegt als Textdatei vor und lässt sich vergleichen und zusammenführen, dafür bekommt man weniger geschenkt und baut mehr selbst. Lua begegnet dir wiederum als eingebettete Skriptsprache in Werkzeugen und Engines, also überall dort, wo Inhalte ohne Neubau der Anwendung erweitert werden sollen. Wer eine dieser Sprachen wirklich kann, lernt die nächste in Tagen, und genau deshalb ist die Wahl der ersten weniger wichtig als das Durchhalten.
Der Weg hinein: Ausbildung, Quereinstieg und was Nachweise wert sind
Es gibt keinen geschützten Berufsabschluss für diese Rolle. Üblich sind ein Studium in Informatik, Medieninformatik oder einem Studiengang mit Spieleschwerpunkt, eine Ausbildung in der Anwendungsentwicklung, oder der Quereinstieg aus der Softwareentwicklung. Aus der Web- und Anwendungsentwicklung ist der Übergang machbar, weil das Handwerk gleich bleibt; ungewohnt sind der Umgang mit Bildbudgets, die Arbeit an einer Simulation, die sechzig Mal pro Sekunde läuft, und die enge Abstimmung mit gestalterischen Rollen.
Beim Nachweis gilt eine klare Rangfolge. Ein spielbarer Build, den jemand in zwei Minuten öffnen und bedienen kann, schlägt jedes Zertifikat. Danach kommt der Quelltext oder der Graph, an dem jemand deine Arbeitsweise sehen kann, danach eine kurze Beschreibung der Entscheidungen. Sammelprojekte aus Kursen zählen wenig, weil jeder Prüfer sie kennt und der eigene Anteil nicht erkennbar ist. Ein Game Jam dagegen zählt viel, weil er belegt, dass du unter Zeitdruck etwas abgeschlossen hast.
Was in Gesprächen regelmäßig gefragt wird und nur mit Erfahrung zu beantworten ist: Wie hast du entschieden, was aus dem Umfang fliegt? Woran hast du gemerkt, dass die Mechanik nicht trägt? Wie habt ihr im Team verhindert, dass zwei Leute dieselbe Datei ändern? Diese Fragen zielen auf Arbeitsweise, nicht auf Wissen, und darauf bereitet kein Kurs vor, sondern nur ein abgeschlossenes Projekt.
Woran du wächst, und wohin die Rolle führt
Zwei Leute mit gleicher Berufsdauer unterscheiden sich meist an zwei Punkten. Der erste ist der Umgang mit Änderungen: Die eine Person baut eine Mechanik so, dass eine neue Anforderung an einer Stelle einsteigt, die andere baut sie so, dass jede Anforderung fünf Stellen berührt. Der zweite ist das Messen. Wer bei Bildrate, Ladezeit und Speicher misst statt zu vermuten, findet in einer Stunde, wofür andere eine Woche raten.
Spezialisierung passiert fast von selbst. Aus Gameplay wird häufig Systemarbeit, also Inventar, Fortschritt, Speicherstände, Netzwerk. Aus Systemarbeit wird Werkzeug- und Engine-Arbeit, wo man für das eigene Team baut statt für Spielende. Ein anderer Weg führt über Technical Art in die Nähe der Grafik, mit Shadern, Bildkosten und Pipelines. Führung kommt später als Lead einer Fachrichtung und bedeutet vor allem Abstimmung, Zuschnitt und Abnahme.
Die Fähigkeiten sind über die Spielebranche hinaus gefragt. Echtzeit-3D wird in der Architekturvisualisierung, in der Produktdarstellung, in Simulation und Training, in medizinischer Visualisierung und in der Filmproduktion mit virtuellen Sets eingesetzt. Wer eine Engine beherrscht, arbeitet dort mit denselben Werkzeugen unter anderen Rahmenbedingungen, oft mit ruhigeren Projektverläufen als in der Spieleproduktion.
Dazu passende Kurse
Wenn du die Engine noch nicht kennst, ist der schnellste Weg zu einem eigenen Ergebnis über Kurse, in denen du deine erste spielbare Szene in der Engine zusammensetzt gebaut.
Wer lieber klein anfängt und dabei mehr von den Grundlagen sieht, findet das in Seminare, in denen du ein eigenes kleines Spiel von der Idee bis zum Build bringst .
Warum es zu dieser Rolle keine amtliche Zahl gibt
Für die Spieleentwicklung gibt es keine eigene Zelle in der amtlichen Verdiensterhebung, denn die Klassifikation der Berufe kennt keine Berufsgattung dafür. Die Tätigkeit verteilt sich je nach Zuschnitt auf Softwareentwicklung, Informatik und gestaltende Berufe, und eine Zahl aus einer dieser Gattungen würde etwas anderes messen als diese Rolle. Wir nennen deshalb bewusst keine Zahl und auch keine Spanne. Wer einordnen will, vergleicht am ehesten mit der Softwareentwicklung im eigenen Bundesland und rechnet ein, dass Studiogröße, Auftragslage und Projektphase hier stärker durchschlagen als in anderen Feldern.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Muss ich programmieren können, um in der Spieleentwicklung zu arbeiten?
Unreal oder Godot für den Anfang?
Wie groß darf das erste eigene Projekt sein?
Lohnt sich Blender, wenn ich programmieren will?
Passt thematisch dazu
Bevor du dich zwischen Graph und Quelltext entscheidest, hilft ein Blick darauf, wie knotenbasiertes Skripting in der Unreal Engine aufgebaut ist .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Vom ersten Knoten bis zum lauffähigen Build
Der Unterschied zwischen einem Prototyp und einem Spiel steckt in den Teilen, die man allein zuletzt anfasst, und genau die stehen bei cmt am Anfang, damit du dein erstes Projekt tatsächlich abschließt.