Englisch für Game‑Entwickler: Schlüsselbegriffe in Programmierung, Design & Publishing

Wenn du dein Leben damit verbindest, Spiele zu entwickeln, weißt du schon, dass der Code universell ist. Doch Team‑Chats, Design‑Dokumente und Pressemitteilungen? Die sind auf Englisch verfasst. Und egal wie sauber dein C# ist: Wenn du in einem Stand‑Up nicht erklären kannst warum ein Feature wichtig ist, kommt das Projekt ins Stocken.

Ich habe talentierte Entwickler gesehen, die nicht an der Logik, sondern an der Sprache kämpfen. Sie frieren bei Calls mit Publishern ein, schreiben unklare Commit‑Nachrichten und verlieren sich in Design‑Reviews. Die Lösung? Nicht ein besseres IDE – sondern professionelles Englisch.

Hier findest du die wichtigsten Begriffe, die du wirklich brauchst, unterteilt nach den drei Phasen eines Spiels: Programmierung, Design und Publishing.

Programmierung: Build & Bug

Die meisten Spielcodes werden in C++, C# oder Python geschrieben. Die Gespräche darüber laufen auf Englisch. Hier die Begriffe, die täglich auftauchen.

Build – Kann ein Verb sein („Wir bauen jede Nacht“) oder ein Substantiv („Der Build ist kaputt“). Ein Build ist eine kompiliert Version des Spiels. Wenn jemand sagt „der Build ist rot“ oder „der Build ist fehlgeschlagen“, stimmt etwas nicht. Ist er „grün“, läuft alles.

Bug – Ein Fehler im Code. „Bug“ ist universell, aber du hörst auch „crash“ (das Spiel schließt), „glitch“ (visueller oder audio‑Hiccup) und „edge case“ (eine seltene Situation, die etwas kaputt macht). Ein guter Entwickler behebt nicht nur den Bug – er schreibt einen Repro‑Step, damit andere ihn nachvollziehen können.

Merge / Pull Request (PR) – Wenn du ein Feature fertig hast, beantragst du das Mergen deines Codes in den Hauptbranch. Das Team wird „deinen PR prüfen“. Wenn sie dich bitten, deine Commits zu squashen, wollen sie mehrere kleine Commits zu einem sauberen zusammenfassen.

Kurztipp: Schreibe bei einer PR‑Beschreibung keine technischen Details, sondern fang mit dem Spielerlebnis an. Beispiel: „Dieser PR behebt das Kameraschneiden durch Wände, wenn der Spieler in der Nähe einer Tür kniet.“ Das hilft Designern und QA sofort zu verstehen.

Design: Gameplay & Player Feel

Hier reden Programmierer und Designer oft über den Kopf – es sei denn, der Programmierer versteht die Vokabeln des Designers.

Gameplay – Wie das Spiel sich anfühlt. Wenn jemand sagt „das Gameplay ist steif“, meint er, dass die Steuerung oder Animationen nicht reaktionsschnell sind. Ist es „fluid“, funktioniert alles gut.

Loop – Kurz für „Game Loop“. Der Kernzyklus, den ein Spieler wiederholt: kämpfen, leveln, Ausrüstung holen, erneut kämpfen. Ein „tight loop“ ist süchtig machend. Ein „broken loop“ lässt die Spieler gehen.

UI / UX – User Interface (Buttons, Menüs) und User Experience (wie einfach es zu navigieren ist). Ein Designer könnte sagen „die UI ist verwirrend“ oder „der UX braucht Feinschliff“. Argumentiere nicht – bitte um konkrete Screenshots.

Player Onboarding – Die ersten 10 Minuten deines Spiels. Hier lernt der Spieler die Regeln. Ist das Onboarding schlecht, verlassen die Spieler das Spiel. Ist es gut, bleiben sie stundenlang.

Reales Beispiel: Ein Programmierer sagte einmal: „Ich habe den Kollisionsbug behoben.“ Der Designer fragte: „Schiebt der Spieler jetzt an Wänden?“ Der Programmierer hatte nicht an das Spieler‑Erlebnis gedacht – nur die Mathematik. Das Wort „Kollision“ reicht nicht aus. Du musst es mit dem Spielerlebnis verbinden.

Publishing: Lokalisierung & Press Kit

Wenn das Spiel bereit zum Versand ist, wird Englisch noch wichtiger. Du sprichst nicht mehr nur mit Teamkollegen, sondern mit der ganzen Welt.

Lokalisierung – Das ist nicht nur Übersetzung. Es geht darum, dein Spiel für verschiedene Kulturen anzupassen. Ein Witz, der im Englischen funktioniert, kann in Japanisch anstößig sein. Ein „Localization Kit“ ist ein Dokument, das du den Übersetzern gibst. Dort erklärst du den Kontext: Dieser Charakter ist sarkastisch, oder Dieser Soundeffekt soll lustig wirken.

Press Kit – Ein Ordner mit Materialien, die Journalisten nutzen, um über dein Spiel zu schreiben. Er braucht einen „One‑Liner“ (ein Satz, der dein Spiel beschreibt), „Screenshots“, ein „Fact Sheet“ und Kontaktinformationen. Wenn dein Press Kit unübersichtlich ist, überspringen Journalisten dich.

Launch Day / Ship Date – Der Tag, an dem das Spiel live geht. Alles ist „crunch“ (zusätzliche Arbeitsstunden) vor dem Launch. Ein „Day‑One Patch“ ist ein Update, das am Launch‑Tag veröffentlicht wird, um letzte Bugs zu beheben.

Noch ein letzter Punkt

Du musst kein perfektes Englisch sprechen, um ein großartiges Spiel zu machen. Du brauchst nur genug, um klar mit deinem Team, deinen Spielern und deinem Publisher zu kommunizieren. Fang bei diesen Begriffen an. Nutze sie in deinem nächsten Stand‑Up. Schreibe deine nächste PR‑Beschreibung mit dem Spieler im Kopf.

Und wenn du wissen willst, wo dein Englisch wirklich steht – nicht raten, sondern messen – probiere den English Measure Test. Er deckt Lesen, Hören, Schreiben und Sprechen ab. Kein Preis, keine Haken. Nur ein klares Bild davon, was gut läuft und was noch verbessert werden kann.

👉 Mache jetzt den kostenlosen Englisch‑Test für Spieleentwickler