Pierwsza gra w Pythonie — co realnie zbudujesz

„Chcę zrobić własną grę". Od tego zdania zaczyna większość osób, które w ogóle siadają do programowania. Zaraz potem przychodzi wątpliwość: co realnie da się zbudować, kiedy dopiero zaczynasz? Odpowiedź jest lepsza, niż podejrzewasz, pod warunkiem, że pójdziesz we właściwej kolejności.

Gra nie powstaje naraz. Powstaje warstwami

Nikt nie pisze gry „w całości". Gra rośnie warstwa po warstwie, a każda warstwa to jedna mała rzecz, która działa: program, który coś pamięta i pokazuje. Potem decyzje. Potem okno, ruch, kolizje, wynik. Na każdym etapie masz coś, co da się uruchomić, i to właśnie trzyma przy nauce mocniej niż jakakolwiek motywacja z zewnątrz.

Warstwa pierwsza: walka, która dzieje się w tekście

Zaczyna się tu, w przeglądarce, bez instalowania czegokolwiek. Poniżej jest prawdziwy Python. Goblin ma 30 punktów życia, cios zabiera 8. Kliknij Uruchom i policz w głowie, zanim zobaczysz wynik:

↑ kliknij „Uruchom", żeby zobaczyć wynik

To nie jest „przykład przed prawdziwą nauką". To już jest mechanika gry: stan (ile goblin ma zdrowia), zdarzenie (cios) i informacja dla gracza. Z dokładnie takich klocków składa się cała walka: goblin oddaje, czyjeś punkty schodzą do zera, na ekranie pada „wygrana" albo „koniec gry". Gra tekstowa to nie namiastka gry. To jej szkielet, który później ubierzesz w grafikę.

Warstwa druga: okno, wąż i klawisze

Kiedy podstawy siedzą, do Pythona dochodzi biblioteka Pygame, zrobiona do gier 2D. Nie trzeba do tego nic instalować, bo w naszym kursie gra powstaje w przeglądarce, w Kokpicie. Ten sam kod działa też na własnym komputerze, jeśli ktoś woli mieć Pythona i Pygame u siebie. Tu powstaje klasyka pierwszych gier: wąż. Najpierw puste okno (kilkanaście linii i już coś jest na ekranie), potem wąż, który słucha klawiszy, potem jabłka, wzrost, punkty, kolizje i ekran końcowy, a na sam koniec tempo, które rośnie z każdym jabłkiem. W coś takiego da się grać naprawdę i da się to pokazać.

To jest też właściwy moment na instalację Pythona. I dobra wiadomość: robisz ją, umiejąc już programować i wiedząc, po co Ci ona. Wtedy to dwadzieścia minut z instrukcją krok po kroku, a nie bariera na samym wejściu, o którą rozbija się najwięcej osób.

Warstwa trzecia: statek, laser i asteroidy

Trzecia warstwa to pełna zręcznościówka: statek, który lata w każdą stronę, laser, fale asteroid, punkty i kolejne poziomy trudności. Brzmi jak przepaść względem węża, ale nie jest, bo każdy element stoi na czymś, co już znasz: ta sama pętla gry, te same zmienne, te same warunki. Rośnie tylko liczba klocków, nie ich rodzaj.

Jak to wygląda naprawdę

Pierwsza gra nie będzie wyglądać jak z PlayStation i o to właśnie chodzi. Chodzi o zrozumienie, jak gra działa od środka: pętla, stan, zdarzenia, kolizje. To fundament każdej kolejnej, ładniejszej gry. Czasowo: pierwsza działająca walka to jeden wieczór, grywalny wąż z grafiką to raczej kilka tygodni po pół godziny dziennie. Jeśli ktoś obiecuje „pełna gra w weekend, od zera", to mówi o przeklikaniu gotowca. A gotowiec działa dokładnie do chwili, w której przychodzi pierwszy własny pomysł.

Ta kolejność ma znaczenie także w drugą stronę: start od razu od Pygame, bez podstaw, to najczęstszy powód zniechęcenia, bo instalacja i składnia uderzają naraz. Rozpisaliśmy właściwą drogę osobno: cała ścieżka od zera do własnej gry, a o tym, od czego zacząć i czego unikać, jest osobny tekst.

Dlaczego nie bloczki i nie gotowiec

Na końcu tej drogi nie masz „ukończonego kursu". Masz grę, w której rozumiesz każdą linijkę, bo każda powstała pod Twoimi palcami. W czasach, w których AI wypluwa kod na zawołanie, umiejętnością nie jest „mieć kod". Jest nią wiedzieć, co ten kod robi, i umieć go zmienić. Tego nie da się przeklikać. A ile czasu realnie zajmuje dojście do kolejnych etapów, opisaliśmy bez ściemy tutaj.

Uczymy Pythona przez budowanie własnych gier: od pierwszej linijki po działający efekt. Kto za tym stoi?