Zbuduj Snake
w Pythonie

Witaj w Snake XTRA. W tym kursie zbudujesz klasyczną grę Snake — ale nie pobierzesz gotowca ani nie przepiszesz cudzego szablonu. Napiszesz własny kod, linia po linii, rozumiejąc każdą z nich. Zaczniesz od pustego okna, a skończysz na kompletnej grze: wąż rośnie z każdym zjedzonym jabłkiem, przyspiesza na kolejnych poziomach, pojawia się ekran Game Over, a rekord zapisany na dysku przetrwa zamknięcie programu. A pętla gry, obsługa klawiszy i zapisywanie stanu, które tu poznasz, to fundament każdej interaktywnej aplikacji — nie tylko gier.

Zanim ruszysz, warto wiedzieć, jak zbudowany jest ten kurs — bo jego rytm jest celowy i będzie Ci towarzyszył przez wszystkie 44 kroki. To materiał na kilkanaście godzin spokojnej nauki — lekcja lub dwie dziennie to świetny rytm; liczy się regularność, nie tempo.

Kurs przeplata dwa rodzaje lekcji. Lekcje oznaczone literą T to teoria — każda bierze jedno pojęcie Pythona lub Pygame (krotkę, pętlę zdarzeń, kolizję) i rozkłada je na części: metafora, kod, eksperyment do samodzielnego sprawdzenia, zadania. Lekcje oznaczone literą S to Snake — w nich nie poznajesz nowej teorii, tylko składasz zdobyte narzędzia w działający fragment gry. Zasada jest prosta: T daje Ci narzędzie do ręki, S pokazuje, jak zbudować nim kawałek gry. Najpierw rozumiesz, potem budujesz.

Przez cały kurs pracujesz w jednym pliku — snake.py. Zaczyna się on od kilkunastu linii (samo okno), a kończy na ponad setce (pełna gra). Nie zaczynasz od zera przy każdej lekcji: każda lekcja S dokłada nowe linie do tego, co już masz. Twój plik rośnie razem z grą — i pod koniec trzymasz w ręku grę, której każdy fragment napisałeś samodzielnie. W lekcjach S będziemy często prosić, żebyś pisał z pamięci, a dopiero potem porównywał kod ze wzorcem — bo między „rozumiem, gdy czytam” a „umiem napisać sam” jest przepaść, którą zasypuje tylko praktyka.

Zanim napiszesz pierwszą linię gry, potrzebujesz Pythona 3.12 (silnika, który uruchamia Twój kod), Pygame (biblioteki do grafiki i gier — więcej w T01) oraz edytora VS Code. Przygotujesz to raz — naszą instrukcją krok po kroku, ze zrzutem ekranu do każdego kliknięcia.

Zanim wpiszesz pierwszą linię, warto zrozumieć, czym jest to, co za chwilę zaimportujesz. Pygame to biblioteka — gotowy zestaw funkcji napisany przez innych programistów. Jej twórcy spędzili lata, rozwiązując problemy, które nie mają nic wspólnego z mechaniką Twojej gry: jak otworzyć okno na Windows, Mac i Linux jednocześnie, jak zsynchronizować rysowanie z kartą graficzną, żeby ekran nie migotał, jak odczytywać klawiaturę bez opóźnień. Znasz ten mechanizm z kursu podstaw — import random dawał Ci od razu random.randint(), bez pisania własnego generatora liczb. Tutaj jedna linia importu daje Ci okna, rysowanie, klawiaturę i dźwięk. Ty zajmujesz się tym, co najciekawsze: budowaniem gry.

Zwróć jeszcze uwagę na kropkę w zapisach takich jak pygame.display.set_mode(). To ścieżka do funkcji, czytana od lewej: z pakietu pygame, z modułu display, wywołaj funkcję set_mode. Każdy taki zapis w tym kursie czytasz tak samo: skąd pochodzi, z którego modułu, co robi.

Każda gra zbudowana na Pygame — od najprostszej do najbardziej złożonej — korzysta z tych samych kroków w tej samej kolejności. To nie konwencja, tylko konsekwencja tego, jak działa grafika i system operacyjny. Gdy ten szkielet zapamiętasz, będziesz pisał własne gry bez zaglądania do kursu.

Najpierw pygame.init() budzi wszystkie podsystemy biblioteki — grafikę, dźwięk, obsługę wejścia. Potem pygame.display.set_mode() tworzy okno: podajesz wymiary w pikselach — w Snake kwadrat 600×600 — i dostajesz obiekt będący powierzchnią do rysowania. Ten obiekt, który nazwiesz ekran, będzie Ci towarzyszył przez cały kurs: każde ekran.fill() i każde pygame.draw.rect() trafi właśnie do niego. Przed pętlą główną definiujesz jeszcze stałe — nazwane wartości dla wymiarów, kolorów i prędkości; po co — zobaczysz za chwilę na własnym kodzie.

I wreszcie serce programu — pętla while True, która kręci się bez przerwy dopóki gra działa. W każdym obiegu trzy rzeczy dzieją się po kolei: sprawdź, co się stało od ostatniej klatki, oblicz nowy stan gry, narysuj go na ekranie. Tę trójfazową strukturę poznasz dokładnie w T02. Na razie zapamiętaj jedno: wszystko, co dojdzie do kodu w następnych lekcjach — ruch węża, jabłko, wynik — wejdzie dokładnie w jedno z tych trzech miejsc. Struktura się nie zmienia, zmienia się tylko zawartość.

Najłatwiej zapamiętać, dlaczego coś jest potrzebne, gdy zobaczysz, co się dzieje bez tego. Dlatego zaczniesz od wersji celowo niepełnej — brakuje w niej jednego ważnego elementu. Najpierw zobaczysz efekt braku, potem napiszesz wersję kompletną, już rozumiejąc każdą linię. Wklej poniższy kod do snake.py, zapisz (Ctrl+S) i uruchom:

Czas naprawić program — tym razem rozumiejąc każdą nową linię. Do kodu wejdą trzy elementy.

Pierwszy to nazwane stałe zamiast gołych liczb. W poprzedniej wersji masz set_mode((600, 600)) — dwie liczby bez nazwy. Za miesiąc nie będziesz pamiętał, co oznacza pierwsze 600, a co drugie. Programiści nazywają takie liczby magic numbers: mają sens w chwili pisania, potem stają się zagadką. Rozwiązanie — dajesz wartości nazwę: SZEROKOSC = 600. Od tej chwili wszędzie używasz nazwy, a liczba siedzi w jednym miejscu na górze pliku. Zmiana rozmiaru okna to edycja jednego wiersza, nie szukanie po całym pliku.

Drugi to obsługa zamknięcia okna. pygame.event.get() zwraca listę zdarzeń, które zaszły od ostatniej klatki — kliknięcia, klawisze, zamknięcie okna. Przeglądasz ją pętlą for i reagujesz na to, co Cię interesuje. Kliknięcie X generuje zdarzenie pygame.QUIT — wtedy wykonujesz dwa kroki: pygame.quit() zwalnia zasoby Pygame, a raise SystemExit kończy program Pythona. Dwie linie, bo to dwie osobne czynności: sprzątanie po bibliotece i wyjście z programu.

Trzeci to tytuł okna — jedna linia: pygame.display.set_caption("SNAKE"). Zastąp cały plik tym kodem i uruchom:

Działa. Tytuł na pasku, kliknięcie X kończy program porządnie. Zwróć uwagę na strukturę: wszystko przed while True to inicjalizacja — wykonuje się raz przy starcie. Wewnątrz pętli każda klatka robi to samo: odbiera zdarzenia, czyści ekran, wyświetla. Ta architektura zostaje do końca kursu — dodasz dziesiątki linii, ale każda trafi w jedno z tych miejsc. Szkielet jest gotowy, teraz będziesz go wypełniał.

Jednej rzeczy w tym kodzie jeszcze nie ma: kontroli czasu. Pętla kręci się tak szybko, jak pozwala procesor — tysiąc klatek na sekundę na szybkim komputerze, sto na wolnym. W T03 dodasz zegar.tick(8), który ustali równe 8 klatek na sekundę — bo wąż ma się poruszać w kontrolowanym tempie, nie „ile zdąży”. Na razie to nie przeszkadza: okno jest puste i nie ma co animować.

Zostało jedno pojęcie: RGB, czyli język kolorów w Pygame. Każdy piksel monitora świeci trzema diodami — czerwoną (Red), zieloną (Green) i niebieską (Blue) — a każda z nich ma jasność od 0 (wyłączona) do 255 (maksimum). Trzy liczby opisują dowolny kolor: (0, 0, 0) to czarny — brak światła. (255, 255, 255) to biały — wszystko na maksimum. (255, 0, 0) to czysty czerwony — świeci tylko jedna dioda. A tło planszy Snake, (15, 25, 15), to bardzo ciemna zieleń — odrobina każdego kanału z przewagą zielonego.

Trzy liczby w nawiasach okrągłych to w Pythonie krotka — niezmienny zestaw wartości. O krotkach dokładnie w T10, ale już teraz widzisz je przy każdym kolorze i rozmiarze okna. Zwróć uwagę na podwójny nawias w set_mode((600, 600)): zewnętrzny to wywołanie funkcji, wewnętrzny to krotka będąca argumentem. Ten wzorzec jeszcze wróci.

Kolory, których użyjesz w Snake — warto je znać od początku:

• (15, 25, 15) — ciemnozielony — tło planszy
• (80, 200, 80) — zielony — ciało węża
• (220, 60, 60) — czerwony — jabłko
• (40, 120, 40) — ciemnozielony — linie siatki
• (255, 255, 255) — biały — tekst i UI

W T01 napisałeś już działający game loop — pętlę while True, która odbiera zdarzenia i odświeża ekran. Działa, ale wygląda jak jeden ciąg instrukcji bez wyraźnych granic. Teraz nadasz jej strukturę, bo każdy game loop na świecie — od Snake po najnowsze gry AAA — składa się z trzech faz wykonywanych co klatkę, zawsze w tej samej kolejności.

Najpierw ZDARZENIA: pytasz system, co się stało od ostatniej klatki — czy gracz nacisnął klawisz, kliknął myszą, zamknął okno. Potem LOGIKA: na podstawie tego, co się stało, obliczasz nowy stan gry — przesuwasz węża o kratkę, sprawdzasz, czy trafił w jabłko, aktualizujesz wynik. Na końcu RYSOWANIE: bierzesz świeżo obliczony stan i malujesz go na ekranie.

Ta kolejność nie jest umowna — wynika z logiki przyczyny i skutku. Gdybyś rysował przed logiką, pokazywałbyś graczowi stan z poprzedniej klatki: wąż zawsze „krok za” tym, gdzie naprawdę jest. Gdybyś zbierał zdarzenia po logice, naciśnięcie strzałki zadziałałoby dopiero w następnej klatce — przy 8 klatkach na sekundę to odczuwalne ósme części sekundy opóźnienia na każdy ruch. Zdarzenia, logika, rysowanie. Zawsze tak.

Pierwszy krok jest prosty, ale ważniejszy niż wygląda: dodasz do pętli trzy komentarze, które wyznaczą strefy faz. Nie zmieniasz żadnej logiki — porządkujesz. Za kilka lekcji w strefie LOGIKA będzie dwadzieścia linii, w RYSOWANIE piętnaście, i bez tych granic wszystko zlałoby się w jedną masę, w której nie wiadomo, gdzie co wstawić. Zastąp swoją pętlę tą wersją:

Okno wygląda tak samo jak przed chwilą — i o to chodzi. Zmieniła się architektura, nie zachowanie. Od teraz, gdy w kolejnych lekcjach przeczytasz „dodaj to do sekcji LOGIKA”, będziesz dokładnie wiedział, gdzie patrzeć. Pamiętasz z T01, co się działo, gdy w pętli zabrakło event.get() — okno zamarzało, bo kolejka zdarzeń systemu się przepełniała. Teraz widzisz to samo z lotu ptaka: faza ZDARZENIA jest jedyną, której nigdy nie wolno pominąć, nawet gdy LOGIKA jest pusta.

Do tej pory Twoja gra reaguje tylko na jedno zdarzenie: zamknięcie okna. Czas nauczyć ją słuchać klawiatury — bo przecież wąż będzie sterowany strzałkami. Gdy gracz naciska dowolny klawisz, Pygame generuje zdarzenie typu pygame.KEYDOWN. Samo KEYDOWN mówi tylko „jakiś klawisz poszedł w dół” — który konkretnie, sprawdzasz w polu event.key. Pygame ma stałą dla każdego klawisza: K_ESCAPE to Escape, K_UP strzałka w górę, K_r litera R.

Zaczniesz od Escape jako drugiego sposobu zamykania gry — to dobra praktyka w każdej grze i najprostszy możliwy trening obsługi klawiatury, zanim w T07 te same mechanizmy posłużą do sterowania wężem. Rozbuduj sekcję ZDARZENIA do tej postaci:

Uruchom i naciśnij Escape — okno znika, dokładnie jak po kliknięciu X. Zwróć uwagę na zagnieżdżenie: najpierw sprawdzasz typ zdarzenia (KEYDOWN — coś naciśnięto), dopiero wewnątrz który klawisz (K_ESCAPE). Ten dwupoziomowy wzorzec wróci w T07 przy strzałkach: jeden warunek KEYDOWN, a w nim cztery porównania event.key — po jednym na kierunek.

T02 skończył się obietnicą: rozwiążemy problem pętli, która kręci się tak szybko, jak pozwala procesor. Czas zrozumieć, dlaczego to w ogóle jest problem. Wyobraź sobie, że wąż przesuwa się o jedną kratkę w każdym obiegu pętli. Na szybkim komputerze pętla wykonuje się tysiąc razy na sekundę — wąż przelatuje przez całą planszę w mgnieniu oka, gra jest nie do ogrania. Na słabym laptopie te same instrukcje wykonują się sto razy na sekundę — wąż pełza dziesięć razy wolniej. Ten sam kod, dwie zupełnie różne gry. Tak być nie może: prędkość gry musi zależeć od Ciebie, nie od sprzętu gracza.

Rozwiązaniem jest miara FPS — frames per second, czyli klatki na sekundę. To liczba mówiąca, ile pełnych obiegów pętli (a więc ile odrysowań ekranu) wykonuje się w ciągu sekundy. Ty ją ustalasz, a zegar Pygame pilnuje, żeby była dotrzymana. Dla Snake wybierzemy FPS = 8 — wąż porusza się skokowo, kratka po kratce, więc 8 ruchów na sekundę daje graczowi około 125 milisekund na reakcję przed kolejnym skokiem. Wystarczająco szybko, żeby trzymać napięcie; wystarczająco wolno, żeby dało się grać.

Mechanizm składa się z dwóch części. Przed pętlą tworzysz zegar — raz: zegar = pygame.time.Clock(). A na samym końcu każdej klatki wywołujesz zegar.tick(FPS) — i tu jest sedno: tick mierzy, ile czasu zajęła bieżąca klatka, i czeka dokładnie tyle, żeby cała trwała 1/FPS sekundy. Szybki komputer poczeka dłużej, wolny krócej — efekt końcowy identyczny na obu.

Zaktualizuj swój kod do tej postaci — trzy nowe linie są oznaczone komentarzami:

Okno wygląda identycznie jak po T02 — i znów o to chodzi. Różnica jest niewidoczna, ale fundamentalna: procesor nie pracuje już na pełnych obrotach renderując tysiące zbędnych klatek, a tempo gry jest w Twoich rękach. Gdy w T06 wąż zacznie się ruszać, jedna zmiana stałej FPS będzie zmieniała prędkość całej gry. Tę właściwość wykorzystasz zresztą na końcu kursu — w finalnej wersji Snake FPS będzie rósł z każdym zjedzonym jabłkiem, podnosząc poziom trudności.

Zostały dwie linie, które piszesz od T01, ale których jeszcze dokładnie nie omówiliśmy — a w tej lekcji domykamy całą pętlę, więc czas to nadrobić. Chodzi o parę ekran.fill() i pygame.display.flip().

ekran.fill(kolor) zamalowuje cały ekran jednym kolorem. Po co, skoro za chwilę i tak wszystko rysujesz? Bo rysowanie w Pygame nie zna pojęcia „przesuń obiekt” — każda klatka maluje wszystko od zera. Jeśli nie wyczyścisz ekranu, nowa klatka namaluje się na poprzedniej: wąż na pozycji nowej i jednocześnie wszystkie jego stare pozycje. Programiści nazywają to ghost effect — ekran zapełnia się „duchami” poprzednich klatek. Dlatego fill() zawsze otwiera fazę RYSOWANIA: czysta kartka, dopiero potem obiekty.

pygame.display.flip() rozwiązuje inny problem. Wszystko, co rysujesz — fill(), prostokąty, tekst — trafia najpierw do niewidocznego bufora w pamięci, nie prosto na monitor. Gdyby gracz widział rysowanie na żywo, ekran migotałby niedokończonymi klatkami: samo tło, tło z połową węża, wreszcie całość. flip() czeka, aż klatka jest kompletna, i dopiero wtedy pokazuje ją na monitorze — jednym ruchem, jak podniesienie kurtyny. Bez fill() masz duchy; bez flip() nie zobaczysz nigdy nic.

Twoja pętla jest kompletna: zdarzenia, logika, rysowanie, kontrola czasu. Spójrz na nią jeszcze raz w formie diagramu — od startu programu do zamknięcia. Każdy element już znasz; teraz zobaczysz je wszystkie naraz, w jednym przepływie:

Przez trzy lekcje teorii budowałeś ten kod kawałek po kawałku: w T01 import, stałe i okno, w T02 trójfazową pętlę z obsługą klawiatury, w T03 zegar i kontrolę czasu. Teraz inaczej — napiszesz wszystko od zera, w jednym podejściu, bez podglądania poprzednich lekcji. Po co, skoro ten kod już masz? Bo między „rozumiem, gdy czytam” a „umiem napisać sam” jest przepaść, którą zasypuje tylko samodzielne pisanie. Ten szkielet to początek każdej gry Pygame, jaką kiedykolwiek stworzysz — po S01 masz go mieć w palcach.

Spróbuj najpierw z pamięci: stałe, inicjalizacja, pętla z trzema fazami, tick na końcu. Dopiero gdy utkniesz, spójrz na wzorzec poniżej. Jeśli przepiszesz całość bez zrozumienia — oszukasz tylko siebie.

Wzorzec, do którego porównasz swój kod. Zwróć uwagę na komentarze dzielące plik na sekcje — STAŁE, INICJALIZACJA, GAME LOOP — od teraz każdy kod w tym kursie będzie tak zorganizowany:

Porównaj swój kod ze wzorcem linia po linii. Jeśli coś napisałeś inaczej, ale działa — świetnie, ważna jest struktura, nie identyczność co do znaku. Zwróć jeszcze uwagę na komentarz # ← TUTAJ w sekcji LOGIKA: dziś to puste miejsce, ale za kilka lekcji będzie tam ruch węża, kolizje i zjadanie jabłek — kilkadziesiąt linii. Cała gra wyrośnie wewnątrz szkieletu, który właśnie napisałeś.

W S01 zbudowałeś działające okno — pustą planszę o wymiarach 600 na 600 pikseli. Piksel to najmniejszy punkt, jaki ekran potrafi zapalić, a Twoje okno to krata 600 na 600 takich punktów. Żeby cokolwiek na nim narysować, musisz umieć wskazać konkretny punkt, i właśnie do tego służy układ współrzędnych.

Każdy punkt opisują dwie liczby. Pierwsza z nich, x, mówi, jak daleko w prawo; druga, y, jak daleko w dół. Punkt (0, 0) leży w lewym górnym rogu okna. I tu czeka pułapka, na której potyka się większość początkujących twórców gier: oś y rośnie w dół, odwrotnie niż na matematyce, gdzie y rośnie do góry. Dlaczego akurat tak? Bo ekrany od zawsze „kreślą” obraz od góry do dołu, linia po linii, trochę jak czytanie kartki. Dlatego y=0 to górna krawędź okna, a y=600 to sam dół.

Spójrz na schemat. Czerwony punkt to przykładowa pozycja (300, 300) — w połowie szerokości i w połowie wysokości, czyli środek okna. Skoro umiesz już wskazać punkt, potrzebujesz narzędzia, które coś w nim postawi. Tym narzędziem jest pygame.draw.rect. Przyjrzyj się jego budowie, argument po argumencie:

Trzy argumenty, jeden po drugim: powierzchnia, kolor i czwórka liczb. Kolor podajemy jako trzy liczby od 0 do 255 — pamiętasz z T01, że mówią one, ile w nim czerwieni, zieleni i błękitu. Dlatego (255, 0, 0) to czysta czerwień, a (0, 0, 255) czysty błękit. Z czwórki liczb dwie pierwsze to pozycja, dwie kolejne to rozmiar. Jest jednak szczegół, który zaraz Cię zaskoczy: punkt (x, y) wyznacza lewy górny róg prostokąta, a nie jego środek. Prostokąt rozrasta się od tego rogu w prawo i w dół. Dlatego znacznik o boku 20 pikseli musi zaczynać się najpóźniej na 580: dopiero wtedy zmieści się tuż przy prawej krawędzi (580 + 20 = 600, czyli dokładnie krawędź okna).

Dodaj tymczasowo do sekcji RYSOWANIE (po ekran.fill(), a przed flip()) cztery znaczniki — po jednym w każdym rogu okna. Zanim uruchomisz, postaw hipotezę: który kolor wyląduje w którym rogu?

Sprawdź swoje przewidywania. Czerwony usiadł w lewym górnym rogu, bo (0, 0) to początek układu. Niebieski na (580, 580) trafił w prawy dolny — oba duże, więc daleko w prawo i daleko w dół. Żółty na (0, 580) wylądował w lewym dolnym rogu, bo zerowe x trzyma go przy lewej krawędzi, a duże y spycha na sam dół. Magenta na (580, 0) zajął prawy górny róg — odwrotnie niż żółty: duże x niesie go w prawo, a zerowe y trzyma u góry. Jeśli żółty Cię zaskoczył, to znak, że intuicja matematyczna „duże y znaczy wysoko” wciąż w Tobie siedzi — w Pygame jest dokładnie odwrotnie. Te znaczniki są tylko po to, żeby zobaczyć współrzędne na żywo; usuń je na koniec, bo następną lekcję zaczynamy na czystym oknie.

Zwróć uwagę, jak wiele dało się zrobić jednym narzędziem: cztery wywołania draw.rect z różnymi liczbami postawiły cztery kwadraty w czterech różnych miejscach. Za każdym razem to dwie pierwsze liczby — x i y — decydowały, gdzie w oknie ląduje kwadrat, a reszta była taka sama. Opanowanie tej jednej zależności, że pozycja to para liczb, którą sam wybierasz, to połowa całego rysowania w grach.

W T04 nauczyłeś się trafiać w dowolny piksel planszy. To potężna umiejętność, ale dla węża zbyt dokładna: okno ma 600 na 600 pikseli, czyli 360 tysięcy osobnych punktów, a wąż nie potrzebuje takiej precyzji. On ma skakać po równych, sąsiadujących polach, a nie celować w pojedyncze punkty.

Dlatego grupujemy piksele w pola. Umawiamy się, że jedno pole to kwadrat o boku 20 pikseli, i zapisujemy tę umowę w stałej KRATKA = 20. Skoro plansza ma 600 pikseli szerokości, a pole 20, to mieści się ich 600 ÷ 20 = 30 w jednym rzędzie. Tyle samo w pionie — razem siatka 30 × 30, czyli 900 pól. Od tej chwili myślimy polami, a piksele zostają tylko przelicznikiem w tle.

Jak z numeru pola wyliczyć piksel? Reguła jest jedna i prosta. Pole o numerze (kolumna k, wiersz r) zaczyna się w pikselu (k×20, r×20). Pole (15, 15) zaczyna się więc w pikselu (300, 300) — dokładnie w środku planszy. Pole (0, 0) to piksel (0, 0), czyli lewy górny róg — z T04 wiesz, gdzie on jest i jak trafić w piksel.

Ten sam kwadrat możesz postawić w różnym polu — wystarczy zmienić numer pola, a piksel (x, y) policzy się sam. Inne pole to po prostu inne (x, y). I jedna rzecz nie zmienia się względem T04: (x, y) to wciąż lewy górny róg kwadratu. Dlatego głowa siedzi swoim rogiem dokładnie w rogu pola, a stamtąd wypełnia je w prawo i w dół.

Czas postawić pierwszy stały element gry. Dodasz dwie nowe stałe — KRATKA i KOLOR_GLOWA — ustawisz pozycję głowy na środku planszy i dorzucisz jedną linię draw.rect w sekcji RYSOWANIE. To pierwszy obiekt, który zostaje na ekranie na dobre, a nie tylko na czas testu.

Na środku planszy siedzi jasnozielony kwadrat — pierwszy stały obiekt Twojej gry. Zatrzymaj się na chwilę nad tym, co jest tu zmienną, a co stałą. glowa_x i glowa_y to zmienne, bo opisują stan, który będzie się zmieniał — w T06 głowa ruszy z miejsca i te liczby zaczną rosnąć. KRATKA i kolory to stałe, czyli konfiguracja, która się nie zmienia w trakcie gry.

Głowa stoi w pikselu (300, 300), więc — jak już wiesz z przelicznika — siedzi w polu (15, 15), w samym środku siatki 30 × 30. Rogiem trzyma się rogu pola, a resztę pola wypełnia w prawo i w dół. To jest dokładnie ten obiekt, którym za chwilę zaczniesz sterować.

Pewnie zauważyłeś dziwny szczegół w kodzie — kwadrat ma bok KRATKA - 2, czyli 18, a nie pełne 20. Po co ta dwójka? Spójrz na tę jedną linię z osobna:

Chodzi właśnie o tę widoczną linię między polami. Pole ma 20 pikseli, ale kwadrat zajmuje tylko 18 — zostają 2 piksele marginesu, przez które prześwituje ciemne tło. Przy jednym kwadracie różnicy prawie nie widać, ale gdy wąż urośnie i pól będzie wiele obok siebie, te szczeliny tła narysują cienkie linie siatki między segmentami. Dzięki temu wąż wygląda jak łańcuch osobnych ogniw, a nie jeden zlany pasek. Spójrz na schemat — od razu zobaczysz różnicę.

To lekcja, na którą pracowały trzy poprzednie: kwadrat z T05 wreszcie się ruszy, a wszystko sprowadzi się do prostej matematyki na współrzędnych z T04. Kierunek ruchu opiszesz dwiema liczbami: dx i dy — litera „d” jak delta, czyli zmiana. dx mówi, o ile zmienia się x w każdej klatce, a dy — o ile zmienia się y. Zanim ruszymy głową, przypomnij sobie dwa operatory, których zaraz użyjemy — += oraz -=:

Czyli += dodaje do tego, co już jest w zmiennej, a -= odejmuje — to po prostu krótszy zapis tej samej operacji. Dlatego ruch głowy zapiszemy identycznie: glowa_x += dx to dokładnie to samo co glowa_x = glowa_x + dx, tylko zamiast jedynki dodajemy dx. Cały ruch to ta jedna linia powtarzana co klatkę — osobno dla x i osobno dla y.

Zamiast uczyć się czterech kierunków naraz, weźmiemy je po kolei — każdy z osobnym rysunkiem.

1. Kierunek w prawo. Zacznij od najprostszego: ustawiasz dx = +KRATKA (x rośnie o 20) przy dy = 0. Głowa z pola (300, 300) przeskakuje do sąsiedniego (320, 300):

2. Kierunek w lewo. Tu jest odwrotnie: skoro x ma maleć, dajesz dx = -KRATKA (z minusem!), wciąż przy dy = 0. Ten sam start, ale głowa cofa się o jedno pole, do (280, 300):

3. Kierunek w dół. Teraz pion — i tu procentuje T04. W dół to dy = +KRATKA przy dx = 0. Uwaga na pułapkę z układu współrzędnych: y rośnie w dół, więc dodawanie do y spycha głowę niżej, do (300, 320):

4. Kierunek w górę. Góra to lustrzane odbicie dołu: dy = -KRATKA. Skoro y rośnie w dół, to odejmowanie od y unosi głowę do góry, do (300, 280). To klasyczna pułapka „każę w górę, a jedzie w dół” — ale Ty już wiesz, czemu w górę to minus:

Teraz, gdy rozumiesz każdy kierunek z osobna, zbierzmy je w jedną ściągę. Zwróć uwagę na prawidłowość: zawsze dokładnie jedna z dwóch liczb jest zerem — to definicja ruchu w klasycznym Snake, w którym wąż sunie poziomo albo pionowo, nigdy na skos.

Zaktualizuj kod do tej postaci — nowości to dx, dy przed pętlą oraz sekcja LOGIKA, która po raz pierwszy przestaje być pusta:

Rusza się! Kwadrat startuje ze środka i równym tempem jedzie w prawo — osiem skoków na sekundę, każdy o jedną kratkę. Zatrzymaj się na moment przy tym, co właśnie widzisz: to pierwsza prawdziwa animacja w Twoim kursie. Pamiętasz flip-book z T02? Właśnie patrzysz na niego w akcji — każda klatka rysuje kwadrat w odrobinę innym miejscu, bo między klatkami glowa_x urosło o 20. Iluzja ruchu z nieruchomych obrazków.

Po kilku sekundach kwadrat znika za prawą krawędzią — i to na razie jest w porządku. Głowa przesuwa się bez sprawdzania granic: glowa_x rośnie powyżej 600, a Pygame, jak wiesz z T04, po prostu nie rysuje tego, co poza oknem. Kwadrat „istnieje” dalej — gdzieś na (700, 300), (720, 300)… — tylko go nie widać. Wykrywanie wyjścia poza planszę i kończenie gry to temat T18 i S08. Na razie celowo zostawiamy świat bez ścian.

Zasada ta sama co w S01: pisz z pamięci, nie przepisuj. Tym razem masz więcej elementów do złożenia — przejdź je w głowie, zanim dotkniesz klawiatury. Szkielet znasz z S01: stałe, inicjalizacja, trójfazowa pętla. Do tego dochodzą nowe klocki: stała KRATKA i kolor głowy (T05), pozycja startowa na środku (T05), delty kierunku i ruch += w sekcji LOGIKA (T06) oraz draw.rect w RYSOWANIU. Jeśli pamiętasz po co jest każdy klocek, kolejność złoży się sama.

Porównaj swoją wersję ze wzorcem. Drobne różnice w nazwach czy kolejności stałych nie mają znaczenia — liczy się struktura: stałe na górze, stan gry (pozycja, kierunek) przed pętlą, ruch w LOGICE, rysowanie po fill(). Zwróć uwagę na komentarz ← TUTAJ zmienisz na skręt (T07) przy dy — to dokładnie ten punkt, w którym za dwie lekcje strzałki przejmą kontrolę nad kierunkiem.

To nie kartkówka, tylko lustro: pokaże, które lekcje warto odświeżyć. Pytania pojawiają się pojedynczo, po odpowiedzi od razu widzisz poprawną. Wynik poniżej progu? Zanotuj tematy, przy których się potknąłeś, wróć do tych lekcji — i losuj nowy zestaw.