Minigolf s Claude Code: kde agent pomůže a kde převezme řízení člověk

Šestiměsíční vývoj minigolfu ukazuje, jak Claude Code pomáhá s designem, fyzikou a logikou botů. Bez testů, invariantů a lidského hráčského úsudku však zůstává hra jen prototypem.

Minigolfová ukázka v komunitě vznikala šest měsíců s pomocí Claude Code. Původně administrativní rozhraní přerostlo v animované SVG prvky, pohyblivé překážky, písek, vodu a rampy. Demo dostalo také boty, kteří hrají vlastní minigolf, zatímco člověk zkouší odpalování míčku.

Postup ale neřeší jen tvorbu kódu. Odhaluje, jak rozdělit práci mezi člověka a AI a kde simulaci musí převzít člověk.

Co se v komunitě reálně osvědčilo

Několik lidí ve skupině se shodlo, že k použitelnému designu se dostalo až s novější generací Claude. Dřívější pokusy podle nich vedly k příliš uniformnímu rozhraní: kulaté karty, výrazné gradienty a vizuálně ploché obrazovky. Novější modely umožnily přepracovat jednotlivé minihry do podoby s vlastním vizuálním jazykem.

Užitečná změna se týkala i způsobu práce. Agent nebyl pouze generátorem kódu. Pomáhal navrhovat herní mechaniky, animované SVG komponenty a logiku botů. Výsledky se ladily den po dni: agent upravoval toleranci pro zapadnutí do jamky, tvar kopců, řešení překážek i skybox.

Právě tohle know-how se osvědčilo. Zadání herní mechaniky je smysluplné rozdělit na vizuální komponenty, pravidla, stav a testovatelné okrajové případy.

Samotný požadavek „udělej minigolf“ je příliš široký. Užitečnější je pracovat po jednotlivých typech dráhy a obtížnosti. Agent pak dostává menší úkol, jehož výsledek lze ihned posoudit.

Jak to funguje pod kapotou a kde má postup limity

Přesný odborný název postupu je iterativní vývoj herního prototypu pomocí kódu generovaného AI agentem, doplněný o ruční herní testování. Diskuze jej často popisuje jednoduše jako „AI mi udělala hru“. Rozdíl je zásadní: model nevytváří fyzikální simulaci jako běžící celek, ale generuje další tokeny kódu. Nemá tak přímou představu o spojitém stavu, tuhých kontaktech ani stabilním časovém kroku.

Proto je vlastní sandbox zranitelnou součástí projektu. Míček se v něm může tunelovat skrz tenkou hranu, získat energii při opakovaných dotazech nebo zastavit příliš daleko od jamky. Žádný screenshot animovaného SVG to neodhalí.

Novější model zlepšuje první návrh hlavně díky lepšímu napodobení známých vzorců z tréninkových dat. Ne tím, že by přesněji počítal fyziku. Kvalitní rozdělení na design, fyziku, logiku botů a iteraci je tedy užitečné, ale samo o sobě nepřináší novou metodu.

Agent navíc potřebuje uzavřenou smyčku nad běžícím enginem. Musí vidět výsledky svého kódu, porovnat je s očekáváním a opravit příčinu, ne jen symptom. Bez toho zůstává jen sada hezkých generických promptů.

Nejčastější chyby jsou přitom dobře popsatelné:

• Agent dostane celou hru najednou a výsledek je příliš rozsáhlý.
• Kontrola se řídí podle screenshotu, který neukazuje průběh fyziky.
• Model opravuje projev, ale ne původní příčinu chyby.
• Simulace běží bez opakovaných testů a invariantů.

Kdy vlastní sandbox, kdy hotová knihovna

Pro rychlé hry typu minigolf může být vlastní implementace rozumná, pokud chcete přesně řídit herní pocit. Předem ale stanovte invarianty: míček nesmí opustit dráhu, nesmí získat energii, musí se zastavit v klidovém stavu a musí existovat jednoznačný výsledek odpalu.

Pro komerční nebo rozsáhlejší hru je výhodnější dedikovaný engine. Box2D, Godot nebo Unity nabízejí hotovou detekci kolizí, laděné parametry a nástroje pro profilování. Agent v nich může upravovat konfiguraci nebo přes rozhraní typu MCP ovládat běžící simulaci, místo aby si sám psal základ fyziky.

Rozdíl je v kontrolovatelnosti. Vlastní sandbox vám dává přesně to, co jste napsali. Knihovna vám dává známé chování a nástroje pro hledání chyb.

Ani jedna možnost ale nenahradí hráčský test. Člověk zjistí nepříjemné zdržení, nečitelné značení nebo zbytečně obtížné skórování, které automatická kontrola neodhalí.

Praktický postup vypadá takto:

1. Rozdělte hru na mechaniky, vizuální komponenty, logiku botů a testy.
2. Zadejte agentovi jeden malý ověřitelný celek.
3. Spusťte výsledek v běžícím enginu.
4. Porovnejte chování s očekáváním.
5. Nechte agenta opravit příčinu problému.
6. Výsledek zkontrolujte testem i ručním hraním.

Prompt, který lze znovu použít

Klíčové anglické pojmy z diskuse jsou physics sandbox, tuning, collision tolerance, game feel, bot AI a edge cases. Tento zápis shrnuje jejich funkci:

Build a 2D minigolf course for [target platform] using [technology stack].
The course must support [list of mechanics and hazards] with [physics engine or custom simulation].
Use [target visual style] and [list of reusable UI or SVG components].
Define deterministic invariants for ball position, velocity, collisions, hole detection, and scoring.
Cover edge cases including [nežádoucí artefakty], and provide a repeatable test procedure for each case.

Co si z toho vzít

• Rozdělte práci na mechaniky, vizuální komponenty, logiku botů a testy.
• Modelu zadávejte malé ověřitelné celky, ne celou hru najednou.
• Kontrolujte fyziku přes invarianty a opakované testy, ne jen podle screenshotu.
• Pro sandbox si zvolte Box2D, Godot nebo Unity, pokud nepotřebujete vlastní herní pocit.
• Ponechte si hráčský test: automatická kontrola nepozná, zda je hra zábavná.