Build Your Own Game

Voraussetzungen

Bevor du anfängst, müssen ein paar Dinge installiert sein. Ohne die geht der Rest nicht.

• Node.js LTS, brauchst du für Claude Code
• JDK 17, am einfachsten Adoptium Temurin, brauchst du für Android-Builds
• Git, unter Windows die Variante Git for Windows
• Mindestens 8 GB RAM, irgendeine GPU, 5 GB Platz auf der Platte
• Anthropic-Account für Claude Code
• Optional: Shadow Cloud-PC, falls du keinen Rechner hast

Komplette Tool-Liste

Alles was im echten Workflow benutzt wird, mit Direktlink. Schluss mit der Suche.

Setup, Schritt für Schritt

Zwei Werkzeuge bilden den Kern: die Engine und die KI. Beides ist in 30 Minuten eingerichtet.

Project
      └─ Export...
           └─ Add...
                └─ Android
                     ├─ Package Name: com.deinname.deinspiel
                     ├─ Version: 1.0.0
                     ├─ Permissions: Internet (nur wenn nötig)
                     └─ Renderer: GL Compatibility
    

# Installation (einmalig)
    npm install -g @anthropic-ai/claude-code

    # Im Projekt-Ordner starten
    cd /pfad/zu/deinem/projekt
    claude

    # In der Session
    > Beachte CLAUDE.md
    > Hier mein Plan: ...
    > /clear   (Kontext leeren bei neuer Aufgabe)
    > /exit    (Session beenden)
    

CLAUDE.md, das Herzstück

Diese Datei ist die Bedienungsanleitung für die KI. Ohne sie schreibt Claude jeden Tag anderen Code. Mit ihr bleibt das Projekt über hunderte Dateien konsistent.

Hier ist eine generische Vorlage. Spitze Klammern markieren Stellen, die du auf dein Projekt anpasst.

# <DeinProjekt> - Regeln für Claude Code

    ## Architektur
    - Engine: <z.B. Godot 4.6 mit GDScript, oder Kotlin Android>
    - Pattern: <z.B. Autoload-Manager, Activity-basiert>
    - Daten: <wo liegen Saves, wo statische Daten>

    ## Namenskonventionen
    - Klassen: PascalCase
    - Funktionen, Variablen: snake_case (oder camelCase je Sprache)
    - Signals und Events: Vergangenheit, z.B. match_finished

    ## Kommunikationsregeln
    1. Nie direkt Code schreiben. Erst Plan vorschlagen, auf OK warten.
    2. Bei Fehlern: erst Ursache erklären, dann Fix.
    3. Keine Änderungen außerhalb der besprochenen Dateien.
    4. Antworten auf Deutsch, Code-Kommentare auf Englisch.

    ## Verbote
    - Keine externen Plugins ohne Rücksprache
    - Keine Werbung, keine Microtransactions
    - Keine fremden Bibliotheken installieren ohne Hinweis
    

Der Workflow im Detail

Plan zuerst, Code danach. Klingt langsam, ist aber zehnmal schneller als blind drauflos prompten.

Schritt 1: Plan einholen, nicht Code anfordern

Falsch: "Schreib mir einen Transfermarkt."
Richtig: "Ich will einen Transfermarkt. Mein Plan: TransferManager als Autoload, Funktionen search_players, make_offer, sign_player. Greift auf GameManager.budget zu. Was übersiehst du?"

Schritt 2: Plan diskutieren

Die KI findet meistens drei oder vier Lücken, an die du selbst nicht gedacht hast. Was passiert bei negativem Budget. Wer löscht alte Angebote. Wie wird das gespeichert. Diese Diskussion ist Gold wert.

Schritt 3: Erst nach Plan-OK implementieren lassen

"Implementiere das jetzt nach dem besprochenen Plan, nichts darüber hinaus." Der Zusatz am Ende ist wichtig, sonst baut die KI gerne Extras ein, die du nicht wolltest.

Schritt 4: Review, Test, Iterieren

Jede Zeile lesen. Print-Statements einbauen, im Spiel testen. Wenn etwas falsch ist: Logs zurück an die KI, neuen Plan, neuen Fix. Niemals blind kopieren.

Das Gleiche ohne Spiel-Kontext

Du baust keine Game, sondern eine Web-App? Gleicher Workflow, anderes Beispiel. Sagen wir, du brauchst ein Login-Formular.

Falsch: "Bau mir ein Login mit Google."
Richtig: "Ich will ein Email-Login. Mein Plan: Frontend-Form mit Email und Passwort, Validierung clientseitig auf Mindestlänge, POST an /api/login, Server prüft gegen Hash in Postgres, gibt Session-Cookie zurück. Stack: SvelteKit plus Supabase. Was übersiehst du?"

Die KI wird zurückfragen: was passiert bei drei falschen Versuchen, wie wird das Passwort beim Anlegen gehasht, wo speicherst du das JWT, brauchst du Email-Verifikation. Genau diese Fragen sind der Wert. Ohne Plan-First-Prinzip baut sie irgendwas und du merkst die Lücken erst beim Bug.

Werkzeuge, die diesen Ablauf abkürzen

Der Ablauf oben funktioniert mit reinem Chat, so ist Anpfiff 1 zum größten Teil entstanden. Inzwischen gibt es Funktionen, die genau diese Schritte fest verdrahten. Du brauchst sie nicht am ersten Tag, aber du solltest wissen, dass es sie gibt.

• Plan-Modus: Ein eigener Zustand, in dem die KI nur liest und einen Plan vorlegt, ohne eine einzige Datei zu ändern. Das sind Schritt 1 und 2 von oben, nur ohne dass du es jedes Mal dazuschreiben musst.
• Skills: Wiederkehrende Abläufe als Datei im Projekt. Bei uns liegt der komplette Play-Store-Upload so vor, mit Reihenfolge und Stolperfallen. Ein Aufruf statt einer halben Seite Prompt.
• Subagenten: Für Suchen in einem großen Projekt. Der Agent durchsucht die Codebasis und liefert nur das Ergebnis zurück, statt dein Hauptfenster mit Dateiinhalten zu füllen.
• MCP-Server: Verbindungen zu Programmen außerhalb des Terminals. Bei uns hängen die Godot-Instanz, ein Browser zum Testen der Webseiten und die Android-Werkzeuge daran.
• Hooks: Kleine Befehle, die automatisch vor oder nach einem Schritt laufen, etwa der Linter nach jeder Änderung.
• Betrieb ohne Chatfenster: Die KI einen einzelnen Auftrag abarbeiten lassen und beenden. Braucht man erst, wenn man Abläufe automatisiert.

Versionskontrolle, ohne geht es nicht

Ohne Git ist jede KI-Session ein Risiko. Wenn die KI deine Codebase zerschießt und du keinen Commit hast, ist die Arbeit weg.

• Am Anfang im Projektordner: git init
• Privates Repo bei GitHub anlegen, einmalig hochpushen
• Vor jedem größeren Claude-Prompt: kurz committen
• Wenn die KI Mist baut: git restore . oder git reset --hard
• .gitignore für Build-Ordner, *.import, .godot/, *.keystore

Zwei echte Bug-Stories und der Debugging-Workflow

Damit du weißt, was dich erwartet.

Mehr Stories direkt im Devlog.

Der Debugging-Workflow

1. Fehler reproduzieren, Schritt für Schritt aufschreiben
2. Logs und Stack-Trace komplett kopieren
3. An die KI mit Plan-First-Prinzip: "Hier der Fehler, hier der Code, was ist die Ursache, welchen Fix schlägst du vor?"
4. Fix lesen und verstehen, nicht copy-pasten
5. Print-Statements einbauen, manuell testen
6. Erst dann committen

Prüfen, ob wirklich passiert ist, was du wolltest

Der Teil, den fast alle Anleitungen weglassen. Die KI meldet Erfolg, das Skript meldet Erfolg, und trotzdem ist nichts passiert. Drei Beispiele aus einem einzigen Release-Wochenende:

• Ein Upload lief in einen Zeitfehler und meldete trotzdem Erfolg, weil der Rückgabewert nicht vom Upload kam, sondern vom letzten Befehl der Kette. Aufgefallen ist es erst beim Blick in die Store-Konsole.
• Ein Schalter, der einen langen Build überspringen sollte, hätte die alte Version in die Produktion geschoben. Gefunden hat es nur der Trockenlauf.
• Ein Zusatzwerkzeug zählte bei jedem Export die Versionsnummer hoch. Nach drei Exporten passte die Nummer im Projekt nicht mehr zu der, für die die Patchnotizen geschrieben waren.

Drei Regeln

1. Den Rückgabewert eines Skripts nie als Beweis nehmen. Frag die Gegenseite: Welche Version liegt auf dem Server, wann wurde die Datei hochgeladen, was zeigt die Store-Konsole an.
2. Vor jedem Schritt, der nach außen geht, ein Trockenlauf, der nur anzeigt, was passieren würde.
3. Nach dem Hochladen einmal von außen gegenprüfen. Seite im Browser aufrufen, Datei herunterladen, Größe vergleichen.

Backend: erst Supabase, dann eigener Server

Wenn du ein Highscore-System willst, brauchst du ein Backend. Für den Anfang ist Supabase die schnellste Lösung: Postgres, fertige REST-API und Auth in einem, der Free Tier trägt ein kleines Spiel lange. Tabelle anlegen, zwanzig Minuten später schreibt das Spiel hinein.

In Godot bindest du es über den HTTPRequest-Node ein. Daten als JSON per POST an die REST-Endpoints schicken, Antwort parsen, fertig.

Highscore senden, GDScript

Skizze. URL und Anon-Key durch deine Werte ersetzen. Im echten Code in Konstanten auslagern, nicht hardcodet.

extends Node

    const SUPABASE_URL  = "https://<dein-projekt>.supabase.co"
    const SUPABASE_ANON = "<dein-anon-key>"

    func submit_highscore(player_name: String, score: int) -> void:
        var req := HTTPRequest.new()
        add_child(req)
        req.request_completed.connect(_on_done.bind(req))

        var url := SUPABASE_URL + "/rest/v1/highscores"
        var headers := [
            "apikey: " + SUPABASE_ANON,
            "Authorization: Bearer " + SUPABASE_ANON,
            "Content-Type: application/json",
            "Prefer: return=minimal",
        ]
        var body := JSON.stringify({
            "player_name": player_name,
            "score": score,
        })
        req.request(url, headers, HTTPClient.METHOD_POST, body)

    func _on_done(result, code, _h, _b, req):
        req.queue_free()
        if code == 201:
            print("Highscore gespeichert")
        else:
            push_error("Upload fehlgeschlagen: " + str(code))
    

Row Level Security in Supabase, SQL

Im Supabase-Dashboard unter Table Editor, Policies. Ohne diese drei Regeln ist deine Tabelle offen wie ein Scheunentor.

-- 1. RLS aktivieren
    alter table highscores enable row level security;

    -- 2. Lesen erlauben (öffentliches Leaderboard)
    create policy "anyone can read"
      on highscores for select
      using (true);

    -- 3. Schreiben einschränken
    create policy "score plausibel"
      on highscores for insert
      with check (
        score >= 0
        and score <= 1000000
        and length(player_name) between 1 and 20
      );

    -- 4. Rate-Limit (per Postgres-Funktion oder Edge-Function)
    -- z.B. max 1 Insert pro IP pro 60 Sekunden
    

Wann du davon wieder wegziehst

Bei Anpfiff 1 läuft heute ein eigenes PHP-Backend auf demselben Webspace wie die Webseite. Nicht weil Supabase schlecht wäre, sondern weil mit der Zeit Anforderungen dazukamen, die über das Speichern von Tabellenzeilen hinausgehen: Spielstände in der Cloud, Freischaltcodes prüfen, eine Schnittstelle für den Discord-Server. Sobald der Server eigene Regeln durchsetzen soll, brauchst du Logik zwischen Spiel und Datenbank, und die willst du dann selbst in der Hand haben.

Vom Code zum Store

Nicht alle Plattformen gleichzeitig. Reihenfolge ist wichtig, sonst zerlegt es deine Zeit.

1. Android zuerst. Günstig (25 Euro einmalig), Reichweite hoch, schneller Feedback-Loop. APK für Tester, AAB für Production. Closed Testing am bequemsten über eine Google Group, wer der Group beitritt ist automatisch Tester.
2. Dann Web-Build auf eigene Domain. Gut für Demos, Reddit-Posts, Discord. Browser-Export aus Godot mit GL Compatibility.
3. Dann itch.io. Kostenlos, Indie-freundlich, einfaches Upload-Interface.
4. Steam erst wenn echte Reichweite da ist. 100 USD App-Fee einmalig, SteamPipe-Upload, Depots korrekt konfigurieren, sonst landen Test-Builds in Production. Linux-Build für Steam Deck macht Steam fast automatisch.
5. iOS erst wenn die Android-Version stabil läuft. 99 USD pro Jahr für das Apple Developer Program. Mac oder Mac-Cloud nötig für Xcode. TestFlight für Beta. Game Center und StoreKit 2 früh einplanen, lassen sich nachträglich nicht einfach reinflicken.

Wo KI-Coding nicht funktioniert

Es gibt Bereiche, in denen die KI scheitert oder zumindest nicht hilft. Wer das vorher weiss, spart sich die Frustration.

Multiplayer-Netcode

Synchronisation, Lag-Compensation, Tick-Rates, autoritativer Server. Die KI kennt die Konzepte, aber wenn es um konkretes Tuning für dein Spiel geht, ist sie raten. Hier brauchst du Spezialwissen oder eine fertige Bibliothek.

Shader und Grafik-Programmierung

Compute-Shader, eigene Render-Pipelines, GPU-Optimierung. Die KI baut dir gerne einen Shader, der irgendwas macht. Aber subtile Fehler bei Vertex-Transformation oder UV-Mapping erkennt sie schlecht. Hier hilft echte Grafik-Erfahrung mehr als Prompts.

Performance-kritische Loops

Wenn du eine Physik-Simulation für 10000 Objekte schreiben musst, gibt die KI dir oft den Lehrbuch-Code. Der ist korrekt, aber zu langsam. Profiling und Optimierung sind kein Prompt-Problem, sondern Messen, Verstehen, Umbauen.

Game-Design und Spielspaß

"Mach das Spiel spaßiger" funktioniert nicht. Balancing, Pacing, Spielgefühl, Schwierigkeitskurve. Diese Entscheidungen muss der Mensch treffen, über Spieltests, über Bauchgefühl, über User-Feedback. Die KI kann hier nur Vorschläge liefern, die du verwerfen oder annehmen musst.

Audio-Engineering und Musik

Sound-Design, Mixing, Komposition. Hier ist die KI nicht das richtige Werkzeug. Lieber ein Asset-Pack kaufen oder mit einem Musiker zusammenarbeiten.

Große Architektur-Entscheidungen

Wie strukturiere ich 100 Manager-Klassen, soll Save-State zentral oder verteilt sein, ECS oder OOP. Die KI kann beide Seiten erklären, aber sie wird nicht die für dein Projekt richtige Entscheidung treffen. Du musst sie treffen, sonst refaktorierst du dreimal.

Fehler über mehrere Systemgrenzen hinweg

Der härteste Fall: Ein Fehler entsteht aus alten Spielständen, einem Datenstand von vor Monaten und einer Ausweichlogik gleichzeitig. Die KI folgt dann gern der erstbesten plausiblen Spur und begründet sie überzeugend. Was hilft, sind Beweise statt Vermutungen: ein echter Spielstand, die Logdatei, der alte Build zum Vergleichen. Damit wird die Suche wieder verlässlich. Ohne Beweise bekommst du eine schöne Erzählung und den falschen Fix.

Realistischer Zeitplan

Anpfiff 1 hat von Mai 2025 bis April 2026 gebraucht, um mit allen Features auf den ersten Plattformen zu landen. Seitdem geht die Arbeit weiter, aktuell bei Version 2.1.2. Hier die ehrliche Aufteilung, damit du weißt, worauf du dich einlässt.

Pro Woche

• 10 bis 14 Stunden Code, abends nach Job und Familie
• Davon produktiv ungefähr die Hälfte, der Rest ist Debugging
• Sonntag ist familienfrei, kein Code

Pro Phase, grobe Schätzung

• Tool-Suche und Setup: 2 bis 4 Wochen, bis du den Workflow verinnerlicht hast
• Erste spielbare Version: 4 bis 8 Wochen, Hauptmechanik plus Save/Load
• Kernfeatures: 2 bis 4 Monate, alles was das Spiel ausmacht
• Polish und Bugfixes: 1 bis 2 Monate, oft länger als gedacht
• Store-Vorbereitung und Marketing: 3 bis 6 Wochen, Texte, Screenshots, Trailer, Closed Testing
• Nach dem Launch: Updates und neue Features hören nie auf

Was du wirklich erwarten solltest

• Mindestens 6 Monate für ein erstes spielbares Release
• Mindestens 12 Monate für ein vorzeigbares Spiel mit allem drumherum
• Wer schneller fertig sein will, baut kleiner. Lieber ein 4-Wochen-Spiel das fertig wird als ein 2-Jahres-Projekt das im Limbo bleibt.

Was es wirklich kostet

Stand Juli 2026. Preise ändern sich.