Rozdział 19 · Model gry
Rozdział 19 · Model gryStan gry
Nie tylko „gra trwa lub się skończyła”
Gra nie tylko "idzie" lub "nie idzie"
Pierwszy prototyp znał tylko igra_okonchena — Bulevo
tak/nie. Ostateczna wersja rozróżnia cztery stany zwykłej gry, a przejścia między nimi są następujące:
To nie jest przypadek, ale jasne zasady:
READY
czekamy na pierwszy kierunek
↓request_direction() — pierwsze wydrukowanie
RUNNING
kleszcze
toggle_pause() ⇄ toggle_pause()
PAUSED
kleszcze ustały
↓kolizja ze ścianą/jaźnią
GAME_OVER
kolizja
↓restart()
READY
czekamy na pierwszy kierunek
| Status | Co się dzieje |
|---|---|
| READY | wąż jest na miejscu, poczekaj na pierwszy nacisk – kleszcze jeszcze nie odchodzą |
| RUNNING | kleszcze są planowane jeden po drugim przez ontimer() |
| PAUSED | tiknięcia się zatrzymają, model się nie zmienia, ekran pokazuje „PAUSE” |
| GAME_OVER | doszło do kolizji; czekamy na restart() |
| WON | pole jest pełne, nie ma już pustej klatki na jedzenie - Rozdział 19.18 |
Piąty stan jest rzadki, ale prawdziwy
B
GameStatus programie końcowym jest pięciu członków, a nie czterech: oprócz czterech stanów regularnej partii, są WON — wąż zajął dosłownie każdą komórkę pola. Jest to prawie nieosiągalne w prawdziwej grze, ale jest to pełny stan terminalny, a nie „prawie GAME_OVER”: rozdział 19.18 pokazuje, skąd pochodzi, a rozdział 19.21 — czym stany terminalne są podobne do siebie.GameStatus jak Enum — ta sama idea, co Tool w rozdziale 18
Cztery stany to ostateczny znany lista, więc
Enum tutaj jest tak samo uzasadnione jak Tool w przypadku narzędzi do rysowania: edytor wykryje literówkę w nazwie państwa, a nie cichy błąd w trakcie gry.Praktyka: przejścia stanów gry
Automatyczne sprawdzanie – funkcja can_transition(): której dozwolone są przejścia między READY/RUNNING/PAUSED/GAME_OVER