Lerne das Team kennen, das unsere Spiele baut
Wir sind ein kleines Studio. Der Großteil des Teams ist KI. So funktioniert es — in einfachen Worten.
Wir sind ein Indie-Studio. 4 Spiele veröffentlicht auf iOS, Android, Web — Team: 8 KI-Spezialisten + ich (Mensch).
Ich bin kein Programmierer. Ich bin Producer. Ich schreibe Briefings, prüfe Ergebnisse, drücke "Veröffentlichen". Die KI macht den Rest.
Die Teammitglieder
Producer entscheidet, was zu bauen ist Designer visuelle Mockups Architect Strukturentscheidungen Programmer × N schreibt Code Reviewer prüft Code Tester spielt das Spiel Release Store-Veröffentlichung Team Lead koordiniert alle
# Jede KI macht eine Sache. # Ich prüfe jeden Schritt.
/team
Wie ein echtes Studio. Nur schneller.
Ein normales Studio: 8 Menschen. Wir: jede Rolle als KI-Session mit klarer Stellenbeschreibung.
1 Spiel veröffentlichen: 1–7 Tage. Klassische Indies brauchen 3–6 Monate.
Warum so viele Rollen?
Eine Allzweck-KI scheint zu reichen. Beim ersten Spiel (Mole Bash) versucht. Katastrophe.
Tag 1 — Design + Code beginnt Tag 2 — Design ändert sich beim Coden Tag 3 — Features hinzugefügt, die ich nicht wollte Tag 4 — Bestehende Features kaputt Tag 5 — Test versucht, nichts klar Tag 6 — Neustart
✗ Scope explodiert ✗ "Fertig" unklar ✗ 2 Wochen, nicht launchfähig
/why-many
Eine KI macht alles = keine Grenzen.
KI ist wirklich kreativ. Ohne strikte Rollen improvisiert sie. Improvisation zerstört das Design unterwegs.
Rollen trennen = jede KI hat eine Aufgabe und ein klares "Fertig". Designer codiert nicht. Programmer ändert kein Design.
Wie sie zusammenarbeiten
Agents reden nicht direkt. Sie posten Updates auf eine gemeinsame Trello-Karte — wie ein Gruppenchat für Arbeit.
10:15 Designer startet. ✓ HTML-Mockup fertig
10:30 Programmer 1–3 parallel.
11:15 Alle 3 fertig. ✓ Lokale Tests OK
11:30 Reviewer freigegeben. 11:45 Tester: 9/9 PASS. 12:00 Release: staging live.
/coordinate
Trello-Karte = single source of truth.
Wer macht was, wann fertig, was rauskommt — alles sichtbar. Niemand sagt "noch dran" — Arbeit erscheint, sobald sie fertig ist.
Was diese Serie behandelt
In den nächsten 7 Posts gehen wir den vollen Build eines Spiels durch — von "Idee gehabt" bis "App Store live". Jeder Post kurz, mit echten Beispielen.
Step 1 — Idee (ein Satz)
Step 2 — Diskussion (Drucktest)
Step 3 — Plan (Regeln, kein Gefühl)
Step 4 — Design (Screen-Mockups)
Step 5 — Code (parallele Programmer)
Step 6 — Test (Roboter spielen)
Step 7 — Launch (Stores + Beobachten)
Du musst nicht coden können. Der Punkt: Engpass ist der Mensch, der das Briefing schreibt — nicht die Technik. Wer eine klare Idee hat, kann diese Pipeline laufen lassen.