Iteracje: poprawiamy grę, nie psując jej
Gry psują się od poprawek częściej niż strony: fizyka, prędkości i kolizje są ze sobą splecione. Bezpieczna pętla: jedna poprawka → zagraj → następna, zapisywanie wersji i naprawa przez „opisz objaw“.
Poprosiłeś „zrób asteroidy szybsze“ — i statek zaczął przez nie przelatywać. Poznaj sprzężenie kodu gry. Ruszaj ostrożnie.
Pętla: jedna poprawka → gra → następna
Zasada vibe codingu „jedna zmiana na raz“ w grach to niemal prawo: każda poprawka zmienia odczucie gry, a odczucie musi przejść przez twoje ręce. Zmieniłeś prędkość? Zagraj trzydzieści sekund. Dodałeś bonus? Zagraj. Granie po każdej poprawce to nie prokrastynacja, tylko kontrola jakości.
Zapisuj wersje
Na czacie poproś: „daj mi cały aktualny kod jako plik“ — i zapisz go jako game-v3.html przed każdą większą przeróbką. Zepsuje się bez ratunku — wracasz do v3 i zamawiasz inaczej. (Lovable i Replit wersjonują same: tam klikasz cofnij.)
Naprawa przez objaw
Nie „napraw moją grę“, tylko opisz, co widzisz:
- „Statek wylatuje poza krawędź ekranu i już nie wraca“
- „Po restarcie prędkość zostaje maksymalna, a powinna się resetować“
- „Jeden bonus nalicza punkty dwa razy“
Precyzyjny objaw dostaje precyzyjną poprawkę. Działa, bo AI widzi kod, a ty widzisz zachowanie — razem jesteście pełnym zespołem.
Strojenie balansu liczbami
Poproś o to: „wyciągnij ustawienia do bloku na początku kodu z komentarzami: prędkość gracza, częstotliwość asteroid, wzrost trudności“. Teraz balans to zmiana jednej liczby w pliku — bez czatu. Pierwszy krok do czytania kodu, i to bezbolesny.
Short questions on the lesson — with an explanation for every answer.