A Crimsonland megtanított gépelni, a Claude Code játékot készíteni

Péter - 9 órája

Volt egy játék a gyerekkoromban amivel gépelni tanultam. A lényege az volt, hogy zombik fejük felett szavak jöttek a képernyőn és be kellett őket gépelni, mielőtt elérik a középen álló karaktert. Egyszerű koncepció, mégis órákig ültem előtte — és közben megtanultam vakon gépelni. Ez volt a Crimsonland Typ'o'Shooter módja. Most hogy a Claude Code-dal ismerkedtem, eszembe jutott: mi lenne, ha ezt a feeling-et újraalkotnam, csak kicsit modernebben?

Így született a Type-o-Shooter: egy 2D-s gépelős párbaj játék, ami 3 nap alatt készült el, a teljes kódbázist Claude Code asszisztenciájával írva.

A minta: Crimsonland Typ'o'Shooter

A közvetlen ihletadó a Crimsonland Typ'o'Shooter játékmódja volt. A 10tons Entertainment 2003-as top-down shooter-ében van egy mód, ahol a játékos középen áll egy shotgunnal, a zombik közelednek felé, és mindegyik felett egy szó lebeg — begépeled, Enter, és a shotgun elsüt. Minél tovább bírod, annál hosszabbak a szavak. Klasszikus és addiktív — a gépelős játékok alap receptje, csak top-down shooter köntösben.

A Typ'o'Shooter eredetileg a 2003-as Crimsonland-ben volt benne, a 2014-es remake-ből kimaradt, de a rajongói nyomásra az 1.1.0 update-ben (2016) visszahozták. A játékmód neve is innen jön — a „Type-o-Shooter" egy tisztelgés az eredeti előtt.

Az ötlet az volt, hogy ezt a mechanikát kibővítsem: ne csak egyedül, hanem 1-4 játékos ellen/együtt lehessen játszani, legyen fegyverválasztás, legyen online multiplayer, és legyen magyar szókészlet is. Mindezt Godot 4.6-ban, GDScript-tel. A spec-et magyarul írtam — a docs/spec.md máig magyarul van a repóban.

3 nap, 45 commit

A projekt teljes idővonala — az első commit-tól a kész, online játszható verzióig:

Március 24. (este) — 4 commit Az első este. 21:26-kor az első commit, 23:34-re már állt a 4 játékos mód, emoji karakterek, és a LAN multiplayer alapja. Egy este alatt a semmiből egy játszható prototípus.

Március 25. (egész nap) — 36 commit A nagy nap. Reggel 8-tól éjjel 10-ig, szinte megállás nélkül készült. A fő feature-ök mind ezen a napon kerültek be:

  • Progresszív nehézség single player módban
  • Raycast lövésmechanika friendly fire-ral
  • Fegyverválasztás: Default, Laser (±3° kitérés + rezgés), Shotgun (5 sugár kúpban)
  • Természetes enemy mozgás szinusz-hullámmal és random megállásokkal
  • Magyar szókészlet
  • Sírkövek a megölt saját enemy-knek 🪦
  • Online multiplayer WebSocket-tel
  • Web export GitHub Pages-re
  • Headless dedicated szerver Dockerben
  • Landing page a type-o-shooter.com-ra

Március 26. (délelőtt) — 5 commit Az online multiplayer stabilizálása és a multi-room szerver. Erről bővebben lentebb.

A stack

  • Godot 4.6 — GDScript
  • WebSocket — online multiplayer (böngészőben is működik)
  • ENet — LAN multiplayer (csak desktop)
  • Docker — a dedicated szerver konténerben fut
  • Render.com — a szerver hostolása (free tier, ~30mp cold start)
  • GitHub Pages — web export a docs/ mappából

A teljes kódbázis ~8.900 sor GDScript.

Hogyan dolgozott a Claude?

Minden commit-ban ott van a Co-Authored-By: Claude Opus 4.6. Ez nem formalitás — a kódnak a döntő többségét ténylegesen Claude Code írta, az én irányításom mellett.

A workflow így nézett ki:

  1. Spec: Írtam egy magyar nyelvű leírást arról, mit szeretnék (ez a docs/spec.md). Fázisonként bővítettem, ahogy haladtunk.
  2. Implementáció: Claude Code-nak adtam a spec aktuális fázisát, ő megírta a kódot, létrehozta a scene-eket, bekötötte a szignálokat.
  3. Tesztelés: F5, kipróbáltam, visszajeleztem mi nem jó, később a godot mcp szerver sokat segítette azt a lépést.
  4. Iteráció: Claude javított, én újra teszteltem. A legtöbb feature 1-2 iteráció után kész volt.

A CLAUDE.md fájl volt a kulcs — ebben tartottam karban a projekt architektúráját, a fájlstruktúrát, és az autoload-ok leírását. Claude Code minden beszélgetés elején beolvassa, így mindig tisztában volt a teljes kontextussal. Ahogy nőtt a projekt, ezt is frissítettük.

Két MCP szerver integráció (.mcp.json) is sokat segített:

  • A Context7 MCP szerveren keresztül Claude mindig a legfrissebb Godot 4.6 dokumentációt használta, nem a training data-ban lévő esetleg elavult verziókat.
  • A godot-mcp közvetlenül összekapcsolta Claude-ot a Godot editorral — látta a scene tree-t, olvasta a hibaüzeneteket, képernyőképet készített, de akár módosítani is tudta a scene-eket és node-okat. Nem kellett kézzel másolgatni a hibákat oda-vissza, Claude egyből látta és tudta is kezelni, mi történik az editorban.

Ami nehéz volt — tanulságok a git log-ból

A commitok nem hazudnak. Három ponton volt jól látható, hogy elakadtunk:

1. Node.js relay → Godot headless szerver

Az online multiplayer-t először egy Node.js WebSocket relay szerverrel oldottuk meg (6785a97). Működött, de hamar kiderült, hogy a Render.com-on a sima WebSocket szerver nem elég — kellett egy explicit HTTP szerver is a health check-hez (3f8de33). Aztán a URL sem stimmelt (06bc6e3).

De a valódi probléma mélyebb volt: a relay szerver „buta" volt, csak továbbította a csomagokat. Godot multiplayer-nél viszont a host-authoritative modell kell — valakinek a peer 1-nek kell lennie. Végül az egész Node.js réteget eldobtuk és írtunk egy headless Godot szerver-t (b53e7a6) ami maga fut Render.com-on Docker-ben. Ugyanaz a GDScript kódbázis, ugyanazok az RPC-k, csak éppen fejetlen. Ez a váltás ~538 sor új kód volt, de megoldotta az összes szinkronizációs problémát.

Tanulság: Ha a game engine-nek van beépített szerver módja, érdemes használni. Ne írjunk relay-t más nyelven — problémát a hosting okozta, mert nem dockeres megoldást választottam.

2. GitHub Pages struktúra

Három commit egymás után (b01b449 → f69627b → b07a7f4), mindegyik 3 percen belül. A probléma: a GitHub Pages-nek pontosan kell a docs/ mappa struktúra. Először web/-nek hívtam, aztán átneveztem docs/-ra, aztán kiderült hogy a játék fájlok egy szinttel mélyebben voltak mint kellett. Klasszikus deploy-yak-shaving.

Tanulság: A deploy konfiguráció mindig tovább tart mint gondolnád, és Claude sem tudja kitalálni elsőre — próba-ellenőrzés lépésekkel lehet megoldani.

3. Online multiplayer WebSocket persistence

A 3. nap teljes délelőttje ezzel ment el (5 commit, 7a7d75c → 19af1a3). A probléma: amikor a játék véget ért és visszamentünk a lobbyba, a WebSocket kapcsolat megszakadt, mert a scene változásnál a NetworkManager újracsatlakozott.

A megoldás: a WebSocket lifecycle-t ki kellett emelni a scene-ekből a NetworkManager autoload-ba, ami túléli a scene váltásokat. Plusz kellett egy rpc_request_lobby_state hogy a visszatérő kliensek megkapják az aktuális állapotot. Végül a multi-room szerver is ezen a napon készült el, ami lehetővé teszi, hogy egyszerre több játék fusson.

Tanulság: A multiplayer networking messze a legkomplexebb része egy játéknak. A alap megoldás gyorsan működik — a szélsőséges esetek (disconnect, reconnect, scene change, game over flow) viszik el az időt, plusz mivel LAN mód volt lőször meg, összekeveredett a Claude egész addig míg nem mondtam meg neki direktbe, hogy szedje nagyjából szét a funkcionalitást.

A web deploy

A játék böngészőben is játszható a type-o-shooter.com-on. Godot 4.6 web export, GitHub Pages hosting, custom domain CNAME-mel.

Két trükk kellett hozzá:

  • coi-serviceworker.min.js — a Godot web export SharedArrayBuffer-t használ, amihez cross-origin isolation kell. Ez a service worker megoldja külső COOP/COEP headerek nélkül.
  • Emoji font fallback — a NotoColorEmoji.ttf (10MB!) be kellett csomagolni, mert a böngésző alapértelmezett emoji renderelése nem megbízható cross-platform.

A dedicated szerver a Render.com free tier-en fut. Van ~30 másodperc cold start, amit egy HTTP ping-gel „ébresztünk fel" mielőtt a WebSocket-et csatlakoztatnánk (e7493b9). Nem elegáns, de free tier-en ez van.

Mit tanultam?

Claude Code-dal nem az a kérdés, hogy meg tudodom-e csinálni, hanem hogy el tudod-e magyarázni, mit szeretnék. A spec leírás minősége közvetlenül befolyásolta az eredmény minőségét. A docs/spec.md fázisonkénti bontása kulcsfontosságú volt — Claude mindig egy kezelhető méretű feladatot kapott, nem az egész játékot egyszerre. Több fázis esetén tudta sorrendezni a lépéseket.

A CLAUDE.md a legjobb befektetés. Ez a fájl az, ami „megtanítja" Claude-ot a projekre. Ahogy nő a kódbázis, ez tartja karban a kontextust. Nélküle minden beszélgetésben elölről kellett volna magyarázni az architektúrát.

A nehézségek nem ott vannak, ahol vártam. A játékmechanika (lövés, enemy mozgás, fegyverek) simán ment. A deploy, a networking edge case-ek, és a böngésző-kompatibilitás — ezek vitték el az időt.

3 nap alatt egy teljes, publikusan elérhető játék. Nem demo, nem prototípus — landing page-dzsel, online multiplayer-rel, dedikált szerverrel. Ez nem azért volt lehetséges, mert a játék egyszerű (8.900 sor kód azért nem semmi), hanem mert a Claude Code workflow drasztikusan felgyorsította az iterációt. És lehetővé tette egy olyan kódbázis létrehozását amiben igazi tapasztalattal nem rendelkeztem eddig. (a projekt végén mondjuk nem sokkal nőt a tapasztalatom)

Próbáld ki

Ha te is gépelni tanultál egy hasonló játékkal a 90-es/2000-es években — most építhetsz sajátot, az AI segítségével, egy hétvége alatt.

Godot 4.6 Claude Code GDscript

Olvasnék még ...