Vor dem Bauen planen
Ein echtes Projekt in Teile zerlegen, bevor du eine Zeile Code schreibst
⏱ ca. ~7 Min
01 · Lesen
Der größte Fehler von Anfängern bei einem neuen Projekt: sie öffnen das Terminal und fangen sofort an zu coden.
Profis machen es umgekehrt. Sie planen zuerst — auch wenn der Plan grob ist und sich später ändert. Planen heißt, darüber nachzudenken, was du eigentlich baust, bevor du Claude bittest, es zu bauen.
Bei der Arbeit mit KI ist das noch wichtiger. Ein klarer Plan liefert hervorragenden Output von Claude Code. "Bau mir ein Spiel" liefert etwas Generisches. "Bau einen Server, der Spielräume verwaltet, wartende Spieler zusammenführt und Züge validiert" liefert genau das, was du willst.
Kernpunkte
- Vor dem Code planen — auch ein grober Plan hilft
- Klare Pläne liefern besseren KI-generierten Code
- Zerlege das Projekt in Schichten: Server, Client, Kommunikation
- Du baust ein Echtzeit-Multiplayer-Tic-Tac-Toe mit Online-Matchmaking
02 · Lesen
Hier ist, was wir bauen: ein Echtzeit-Multiplayer-Tic-Tac-Toe. Zwei Fremde besuchen dieselbe URL, werden zusammengeführt und spielen in Echtzeit. Ein Spieler zieht, und der Zug erscheint sofort auf dem Bildschirm des anderen.
Das fertige Spiel hat drei Schichten: Server — die Autorität. Er verwaltet das Spielfeld, setzt die Regeln durch, führt Spieler zusammen und erkennt den Sieg. Der Server hat immer Recht. Spieler können nicht betrügen, weil der Server jeden Zug validiert.
Client — die Oberfläche. Die HTML-Seite, die die Spieler im Browser sehen. Sie zeigt das Spielfeld, fängt Klicks ab und zeigt die Updates vom Server.
Kommunikation — die Brücke. WebSocket-Events, die zwischen Client und Server fließen. Wenn ein Spieler eine Zelle anklickt, schickt der Client ein 'make-move'-Event. Validiert der Server, schickt er 'move-made' an beide Spieler.
Kernpunkte
- Der Server verwaltet den gesamten Spielzustand — vertraue niemals dem Client
- Der Client zeigt das UI und fängt Nutzeraktionen ab
- WebSocket-Events sind die Kommunikationsschicht zwischen beiden
- Der Server validiert jeden Zug — Schutz vor Cheating
03 · Schritt für Schritt
Geh die drei Schichten jeder Echtzeit-App durch und schau, was jede Schicht in unserem Tic-Tac-Toe macht.
1. Server: der Schiedsrichter
Verwaltet das Spielfeld (3x3-Raster), merkt sich, wer dran ist, validiert Züge (Zelle leer? Du dran?), erkennt Sieg und Unentschieden, führt wartende Spieler in einem Spielraum zusammen.
2. Client: der Bildschirm
Zeigt das 3x3-Spielfeld als klickbare Zellen. Zeigt Statusmeldungen ('Warte auf Gegner...', 'Du bist dran', 'Du hast gewonnen!'). Sendet ein Event, wenn ein Spieler klickt. Aktualisiert das Spielfeld, wenn der Server eine Änderung schickt.
3. Kommunikation: die Events
Der Vertrag zwischen Client und Server. Ein Spieler klickt 'Find Game' — der Client emittet 'find-game'. Der Server führt zwei Spieler zusammen — emittet 'game-start' an beide. Ein Spieler klickt eine Zelle — der Client emittet 'make-move'. Der Server validiert — emittet 'move-made' an beide. Das Spiel endet — der Server emittet 'game-over'.
4. Matchmaking: die Lobby
Eine Warteschlange auf dem Server. Du klickst 'Find Game', du kommst in die Warteschlange. Sobald ein zweiter Spieler dazukommt, führt der Server euch in einem Raum zusammen, vergibt X und O zufällig und startet das Spiel.
5. Disconnect-Handling: sauberes Aufräumen
Schließt ein Spieler mitten im Spiel den Browser, erkennt der Server die Trennung und benachrichtigt den Gegner. Trennt sich jemand in der Warteschlange, entfernt der Server ihn. Keine Zombie-Spiele, keine festsitzenden Spieler.
04 · Code-Beispiel
Das ist der Event-Fluss zwischen zwei Spielern und dem Server. Schau ihn dir genau an — er ist der Bauplan für die nächsten 7 Lektionen.
Event-Fluss: vom Matchmaking bis zum Spielende
Player A Server Player B
| | |
|--- find-game ---->| |
|<--- waiting ------| |
| |<--- find-game -----|
|<-- game-start ----|--- game-start ---->|
| (you are X) | (you are O) |
| | |
|--- make-move ---->| | (A clicks cell 4)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| |<--- make-move -----| (B clicks cell 0)
|<-- move-made -----|--- move-made ----->| (server: valid!)
| | |
| ...more moves... |
| | |
|<-- game-over -----|--- game-over ----->| (X wins!)
| (you won!) | (you lost) |
Beachte, dass jede Aktion über den Server läuft. Spieler A spricht nie direkt mit Spieler B. Der Server empfängt den Zug, validiert ihn und sendet das Ergebnis an beide Spieler. Das ist Standardarchitektur für jedes Multiplayer-Spiel.
05 · Checkliste
Bestätige vor dem Coden, dass du den Plan verstanden hast. Hak jedes Konzept ab, mit dem du dich wohlfühlst.
- Der Server hält den gesamten Spielzustand — Spielfeld, wer dran ist, wer X und O ist
- Der Client schickt nur Events (wie 'make-move') und zeigt an, was der Server ihm sagt
- Matchmaking führt zwei wartende Spieler in einem Spielraum zusammen
- Jeder Zug wird vom Server validiert, bevor er den Spielern angezeigt wird
- Trennt sich ein Spieler, räumt der Server auf und benachrichtigt den Gegner
06 · Quiz
Warum sollte der Server Züge validieren, statt dem Client zu vertrauen?
- Die Validierung auf dem Server ist schneller als auf dem Client
- Der Client hat keinen Zugriff auf den Spielzustand
- Spieler können den Client-Code ändern und betrügen — der Server ist die einzige vertrauenswürdige Autorität
- WebSocket erfordert serverseitige Validierung
Andere Lektionen aus diesem Kapitel
⚠ Das volle interaktive Erlebnis braucht JavaScript. Bitte aktiviere es und lade die Seite neu.
※ Diese Seite ist ein unabhängiges Bildungsprojekt — kein offizielles Anthropic-Produkt. Claude™ ist eine eingetragene Marke von Anthropic, PBC.