Build Your Own Game

1. 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

2. 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)

3. 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.x 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

4. 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.

5. 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

6. 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

7. Backend mit Supabase

Wenn du ein Highscore-System willst, brauchst du ein Backend. Eigener Server lohnt sich für Solo-Devs nicht. Supabase ist Postgres plus Auto-API plus Auth, der Free Tier reicht für kleine Projekte.

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

8. 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.

9. Komplette Tool-Liste

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

10. 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 der 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.

11. Realistischer Zeitplan

Anpfiff1 hat von Mai 2025 bis April 2026 gebraucht, um auf drei Plattformen mit drei Sprachen und allen Features zu landen. 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.

12. Was es wirklich kostet

Stand April 2026. Preise ändern sich.