O czym jest ten film
- W trakcie Hack Week — tygodnia na dowolne projekty u sponsora kanału, firmy Sentry — CJ zbudował w cztery dni kompletną grę na Game Boya Color: platformówkę z zagadkami „Syntax Error”.
- Zagadki wzorowano na Dr. Mario, Bust-A-Move i Sokobanie, na końcu czeka walka z bossem, a grywalni bohaterowie to CJ, Scott i Wes z zespołu podcastu.
- Cały kod w C powstał w zestawie narzędzi GBDK 2020 i napisało go AI — CJ nie napisał ani jednej linijki.
- AI miało własną pętlę testową: dzięki projektowi Pi Boy agent sterował Game Boyem z Pythona, sam grał, robił zrzuty ekranu i na ich podstawie oceniał, czy wersja działa.
- Testy na sprzęcie odbywały się na kartridżu flash z kartą SD (30–40 dolarów), a na co dzień — w otwartym, wieloplatformowym emulatorze Same Boy.
- Niepewność sprzętową (obsługiwany format zapisu na kartridżu) rozstrzygnął specjalny ROM diagnostyczny wygenerowany przez AI.
- Cała grafika pixel art powstała od zera w programie Pixelorama — z poszanowaniem ograniczeń konsoli: kafelki 8×8, cztery kolory na kafelku, około 56 kolorów na ekranie, brak wbudowanego fontu.
- Trzeci dzień minął na ścinaniu zakresu (trzy korytarze zamiast trzech wielkich poziomów) i na debugowaniu pamięci palet, które AI naprawiało na podstawie samych opisów objawów.
- Do wersji sklepowej powstaje muzyka w formacie UGE (do czterech równoległych ścieżek z generatorów szumu) oraz tryb demonstracyjny attract mode — demo z Hack Week wyszło bez dźwięku.
- Gra trafi do sprzedaży jako fizyczne pudełko z instrukcją w sklepie Syntax, z okładką narysowaną przez człowieka — CJ aktywnie szuka płatnego artysty.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Pierwszy dzień to plan i dowód wykonalności, nie produkcja
Na czym polega: CJ połowę pierwszego dnia spędził na koncepcji gry, a resztę na udowodnieniu, że w ogóle da się coś zbudować i uruchomić na prawdziwej konsoli.
Jak stosować: W krótkich projektach (hackathon, jednotygodniowy sprint) wyznacz sobie na start cel typu „działający program na sprzęcie docelowym” i zbuduj wokół niego cały łańcuch narzędzi. Dopiero na tym gruncie rozwijaj właściwą część.
Na co uważać: Planowanie łatwo rozlewa się na kolejne dni. Przytnij je twardym limitem czasowym — połowa dnia to dobra proporcja.
2.Karm AI gotowymi przykładami, zamiast kazać mu wymyślać od zera
Na czym polega: AI przejrzało przykładowe projekty GBDK 2020 (gotowa platformówka, poruszający się przeciwnicy), wybrało te najbliższe założeniom i złożyło z nich pierwszy działający ROM.
Jak stosować: Zanim poprosisz agenta o kod, zbierz dokumentację i przykłady. Zadaniem modelu powinna być selekcja i składanie, a nie generowanie wszystkiego z niczego — to wyraźnie podnosi jakość wyniku.
Na co uważać: Przykłady edukacyjne mają luźne licencje i niską jakość produkcyjną. Traktuj je jako rusztowanie, nie jako fundament produktu.
3.Zbuduj AI pętlę testową — niech samo gra i samo ocenia
Na czym polega: Dzięki projektowi Pi Boy AI sterowało Game Boyem z Pythona: wykonywało zaplanowane sekwencje przycisków, robiło zrzuty ekranu i na ich podstawie decydowało, czy gra działa.
Jak stosować: Zanim oddasz agentowi samodzielny projekt, daj mu „zmysły”: skrypty testowe, zrzuty ekranu, logi. Dzięki temu może iterować bez twojego udziału i szybciej dochodzi do działającej wersji.
Na co uważać: Testy oparte tylko na obrazie potrafią dawać fałszywe wyniki. Warto mieć drugi, prostszy sygnał (np. log) do porównania.
4.Niepewność sprzętową rozstrzygaj eksperymentem, nie dokumentacją
Na czym polega: Zamiast zgadywać, jakiego formatu zapisu oczekuje kartridż, AI przygotowało ROM diagnostyczny, który na konsoli wypisał obsługiwane lokalizacje i formaty zapisu.
Jak stosować: Gdy dokumentacja milczy, napisz najprostszy możliwy program, który odpowie na twoje pytanie na sprzęcie docelowym — i zrób to, zanim zbudujesz cokolwiek większego.
Na co uważać: Wynik może dotyczyć tylko testowanego egzemplarza lub kartridża. Przy produkcie na sprzedaż sprawdź sprzęt, na którym gra faktycznie trafi do klientów.
5.Dziel pracę równolegle: AI koduje na grafikach zastępczych, ty robisz assety
Na czym polega: Gdy CJ rysował w Pixeloramie, AI budowało poziomy i mechaniki na prostych placeholderach; finalna grafika wchodziła na gotowe fundamenty.
Jak stosować: Rozdziel pracę człowieka (koncepcja, grafika, decyzje) od pracy agenta (kod, testy) tak, aby obie strony nie czekały na siebie. To realnie podwaja tempo w małym zespole.
Na co uważać: Grafiki zastępcze powinny mieć docelowe wymiary (u CJ: kafelki 8×8, postacie 24×16 px), inaczej późniejsza wymiana przyniesie niespodzianki.
6.Poznaj ograniczenia platformy, zanim otworzysz edytor grafiki
Na czym polega: Na Game Boyu wszystko to kafelki 8×8, jeden kafelek ma maksymalnie cztery kolory, na ekranie mieści się ich około 56, a rozdzielczość jest sztywna: 160×144. Postacie zbudowano z trzech kafelków wysokości, żeby zmieściły się detale.
Jak stosować: Przy każdej ograniczonej platformie (retro konsola, e-ink, stare przeglądarki) najpierw spisz twarde limity i dopiero pod nie projektuj. Ciasne ramki często wymuszają ciekawsze pomysły.
Na co uważać: Limity bywają „miękkie” — np. budżet kolorów może liczyć się osobno dla warstw albo scen. Sprawdź, jak platforma naprawdę go rozlicza.
7.Umiej ściąć zakres w połowie projektu
Na czym polega: Zamiast trzech wielkich poziomów z trzema zagadkami każdy i bossem CJ w trzecim dniu zostawił trzy korytarze, trzy zagadki i finał — czyste sedno gry.
Jak stosować: W połowie dostępnego czasu weź cały plan i skreśl wszystko, bez czego gra nadal ma sens. Dokończenie ambitniejszej wersji zostaw na czas po terminie — tak jak CJ zrobił to po Hack Week.
Na co uważać: Tnij funkcje, nie jakość. Wersja prosta, ale dopracowana, wygrywa z wersją pełną, a surową.
8.Z AI debugujesz objawami, nie czytaniem kodu
Na czym polega: CJ nie pisał C ani go nie analizował. Opisywał symptomy — sprite’y w złej palecie, migotanie między klatkami — a AI samo lokalizowało przyczyny w zarządzaniu pamięcią i optymalizowało rysowanie.
Jak stosować: Raportuj agentowi, co widzisz i kiedy to występuje. Kontekst objawów prowadzi model do przyczyny znacznie szybciej niż ogólne „napraw błąd”.
Na co uważać: Bezkrytyczne przyjmowanie poprawek potrafi narobić regresów. Po każdej zmianie żądaj przejścia pełnej pętli testowej.
9.Demo nie musi być kompletne
Na czym polega: Wersja pokazana na Hack Week nie miała ani muzyki, ani dźwięków — i nikt nie musiał o tym wiedzieć. Ścieżka dźwiękowa powstaje dopiero teraz, do wersji sklepowej.
Jak stosować: Przed pokazem rozdziel, co musi być gotowe, a co może poczekać. Braki niewidoczne dla widza odłóż bez poczucia winy i dokończ po pokazie.
Na co uważać: Ten trik działa tylko w demonstracji. Przed sprzedażą domknij i przetestuj całość: dźwięk, zapisy, tryb demonstracyjny.
10.AI do prototypu, człowiek do produktu
Na czym polega: Okładkę pudełka CJ wygenerował z AI do stadium prototypu, ale na setki fizycznych egzemplarzy zdecydowanie chce grafiki od człowieka — i szuka płatnego artysty.
Jak stosować: Wykorzystuj AI do szybkiego sprawdzenia kierunku artystycznego, a decyzje o finalnych, publicznych artefaktach (okładka produktu, materiał wizerunkowy) zostaw ludziom — to też kwestia zaufania społeczności.
Na co uważać: Rynek zleceń zalewają boty udające artystów. Weryfikuj portfolio i wypytuj o proces pracy, zanim zapłacisz.
Redakcyjne tłumaczenie
Cztery dni, jedna kaseta
W 2026 roku zrobiłem grę na Game Boya. Nazywa się „Syntax Error”, nawiązuje do naszego kanału i jest to platformówka przeplatana zagadkami logicznymi. Można w nią zagrać Scottem albo mną. A całość powstała w cztery dni.
Raz w roku Sentry organizuje Hack Week — tydzień, w którym każdy może zająć się czym tylko chce. Ja postanowiłem zrobić grę na Game Boya. W tym materiale pokażę, jak do tego doszło: jakie narzędzia użyłem i jak przerobiłem tego Game Boya Color, który ma obudowę na zamówienie, podświetlany ekran oraz opcję zmiany palety kolorów. (Informacja dodatkowa: Syntax to popularny anglojęzyczny podcast dla programistów; jego wieloletnim partnerem jest firma Sentry, a Hack Week to jej wewnętrzny tydzień autonomicznych projektów.)
Opowiem też, jak pracowałem z AI — bo bez niego ta gra nie powstałaby w cztery dni. AI dosłownie samo grało w moją grę, żeby ją testować. Poziomy rozmieściliśmy w programie Tiled, a całą grafikę pixel art narysowałem od zera. Praca była świetna, a za około miesiąc w sklepie Syntax zadebiutuje fizyczne wydanie gry: pudełko, instrukcja i wszystko, czego oczekujesz po fizycznym tytule. Właśnie kompletujemy wszystkie elementy. Jeśli brzmi zachęcająco — zaczynamy. Nazywam się CJ. Witajcie w Syntax.
Najpierw plan, potem wszystko inne
Chcesz zrobić grę? Zacznij od planu: co to za gra, jaka jest historia, kim są bohaterowie. Połowę pierwszego dnia spędziłem na odpowiedziach właśnie na te pytania i w efekcie oprałem grę na zespole Syntax: ja, Scott i Wes zostajemy wessani do komputera, w którym musimy naprawić kod i pokonać końcowego bossa.
Zasady rozgrywki są proste: platformówka w duchu Mario. Prowadzisz bohatera przez platformy, rozprawiasz się z przeciwnikami, a na końcu każdego korytarza czeka terminal — po jego użyciu startuje zagadka. Wzorowaliśmy się na Dr. Mario, Bust-A-Move i Sokobanie: każdy poziom to inny typ łamigłówki, a jej trudność rośnie w miarę przechodzenia gry. Wyszła z tego mieszanka nostalgii rodem ze świata Game Boya i Nintendo, tyle że w wydaniu Syntax. Plan był. Trzeba było jeszcze wymyślić, jak go zbudować.
Dwie drogi: GB Studio albo GBDK 2020
Dziś grę na Game Boya da się zrobić na kilka sposobów. Najpopularniejszy i najłatwiejszy to GB Studio — dostajesz interaktywny edytor przypominający Unity (o ile masz doświadczenie z silnikami gier). Układasz w nim kafelki i mapy, a pod spodem działa gotowy silnik fizyczny i cała reszta. Kiedy chcesz wystartować błyskawicznie, GB Studio nie ma sobie równych. Ja jednak chciałem kod niskiego poziomu — a właściwie chciałem, żeby pisało go AI — i budowę wszystkiego od zera. Tak trafiłem na GBDK 2020: zestaw narzędzi, w którym gry retro tworzy się w języku C. Obsługuje nie tylko Game Boya — z jego pomocą zrobisz gry także na Analogue Pocket, Segę Master System, Mega Ducka czy NES-a.
To nie mój pierwszy raz
Nie zaczynam w retro devie od zera. Logo Syntax, które widać za mną w tle, działa na Segi Genesis. Rok temu, również w cztery dni, zbudowałem grę na Segę — wyszedł z tego jeden poziom z platformami, napisany niskopoziomowo i wgrany na prawdziwy kartridż. Z tamtej pracy została mi animacja logo, którą od tamtej pory mam w tle nagrań. Wiem więc, jak wygląda praca z takimi zestawami SDK.
Cudze przykłady zamiast wymyślania koła na nowo
Przy czterodniowym budżecie czasu trzeba brać skróty. Dlatego część pierwszego dnia to również rozeznanie: jakie gry open source mogłyby posłużyć za bazę i jakie gotowe zasoby w ogóle istnieją. Bo assety to najcięższy kawał roboty przy takim projekcie — pixel art postaci, bossów, mapy kafelków. Robienie tego wszystkiego od zera boli. Przejrzałem więc gry open source powstające na GBDK 2020 i przykłady z samego zestawu: jest wśród nich gotowa platformówka pokazująca sterowanie postacią krzyżakiem i skok na przycisku B, a także parę projektów z poruszającymi się przeciwnikami.
Cel pierwszego dnia był skromny: cokolwiek na Game Boya. Gdybym udowodnił, że potrafię zbudować projekt w GBDK 2020 i odpalić grę z fizycznego kartridża, uznam dzień za zwycięski. I tak właśnie wyszło. AI przejrzało przykłady, wybrało te najbliższe naszej wizji i złożyło działający ROM, który uruchomiłem na swojej konsoli.
Kartridż flash — najtańsze wejście w prawdziwy sprzęt
Służy do tego kartridż flash. Takie karty kupisz na Amazonie za 30–40 dolarów, a do środka wkładasz kartę SD. Większość ludzi używa ich do grania w ROM-y — mój przyszedł z tysiącem gier na Game Boya i Game Boya Color. Własny plik ROM wgrywasz dokładnie tak samo i od razu widzisz, czy działa. To najprostsza droga do rozwijania gry na prawdziwym sprzęcie. Jeśli kiedyś zechcesz ją sprzedawać, przyjdzie czas na nagrywanie właściwych kartridży — o tym później. Na etapie testów w zupełności wystarczy jedna taka karta.
Pi Boy, czyli AI grające w grę o własnych siłach
Skoro AI miało pisać całą grę i oddawać mi gotowe wersje, potrzebowało też sposobu, żeby samo ją testować i w nią grać. Tu wchodzi Pi Boy — projekt, który pozwala sterować Game Boyem z poziomu Pythona. AI przygotowało sobie kompletne skrypty testowe: najpierw budowało grę z kodu C w GBDK 2020, potem uruchamiało Pi Boya z zaprogramowanymi sekwencjami wciśnięć przycisków potrzebnych do interakcji z rozgrywką, w trakcie wykonywało zrzuty ekranu, a na koniec analizowało je i decydowało, czy wszystko działa poprawnie. Gdy przychodził czas na moje granie, brałem ROM już sprawdzony przez AI i odpalałem go w emulatorze — ciągłe przenoszenie plików na kartę SD byłoby nie do wytrzymania. Wybrałem emulator Same Boy: open source, działa na każdej platformie, ładujesz dowolny ROM i testujesz.
ROM diagnostyczny zamiast zgadywania
ROM-y na Game Boya Color występują w kilku formatach — na przykład GBC 4 i GBC 5 — różniących się sposobem zapisu danych. Musieliśmy ustalić, który z nich obsłuży mój kartridż. AI rozwiązało problem elegancko: stworzyło ROM diagnostyczny, który po podpięciu do konsoli wypisuje wszystkie lokalizacje zapisu, raportuje, czy zapis w ogóle działa, i podaje obsługiwany format. Zanim ruszyliśmy z platformówką, menu i resztą, wiedzieliśmy więc dokładnie, na czym stoimy — i czy można zostać przy wybranym formacie.
Godzina ze śrubokrętem: podświetlany ekran bez lutownicy
Testy ruszyły, AI zaczęło budować pierwszy poziom i menu, a ja musiałem czymś zająć ręce. Wziąłem więc na warsztat konsolę. Fabryczny ekran Game Boya Color nie zachwyca — bez dobrze oświetlonego pokoju praktycznie nic na nim nie widać. Jako dziecko ratowałem się lampką Worm Light wpinaną w konsolę oraz nakładką-lupą z podświetleniem, żeby grać po nocach. Dziś są lepsze czasy: ekrany podświetlane. Kupiłem zestaw z takim ekranem i z możliwością zmiany palety kolorów — tę, którą pokazywałem na początku. Całość montuje się bez lutownicy: wystarczy specjalny śrubokręt do śrub Game Boya Color oraz pęseta, która bardzo pomaga przy odpinaniu i wpinaniu taśmy ekranu. Niestety instrukcja w zestawie była słaba, a w sieci krąży mnóstwo przypadkowych kitów, więc do właściwego montażu doszedłem metodą prób i błędów, porównując zdjęcia. Zajęło mi to około godziny. Linki do zakupionego zestawu i do filmów, które ułatwiły mi sprawę, znajdziecie w opisie. Po tej godzinie miałem pięknego, sprawnego Game Boya, w którego można grać po ciemku.
Bilans po pierwszym dniu
Wróciłem do AI — zrobiło porządny postęp — i tym samym zamknąłem dzień pierwszy. Zużyłem 25% czasu, zostały trzy dni, ale czułem, że stoję mocno: umiemy budować własne gry, mam przerobioną konsolę, a przede wszystkim działa cały łańcuch narzędzi, w którym AI samo buduje ROM i samo go testuje. Teraz zostawało „tylko” dokończyć grę.
Dzień drugi: pixel art od zera
Drugi dzień należał do grafiki. Wspominałem o rozeznaniu w gotowych zasobach — ostatecznie nie użyliśmy żadnych zewnętrznych. Ale sam podział pracy się sprawdził: AI cały czas budowało na grafikach zastępczych, a ja stopniowo rysowałem właściwy pixel art w programie Pixelorama. To narzędzie open source, bardzo zbliżone do Aseprite, jeśli je znacie — rysowanie piksel po pikselu. Właśnie tak powstała cała grafika postaci i kafelków w grze.
Z czym mierzy się grafik na Game Boyu
Warto rozłożyć na części, jak konsola właściwie rysuje obraz, bo od tego zależy wszystko. Ekran ma 160 na 144 piksele i nie ma mowy o responsywnym projektowaniu: każdy Game Boy Color ma identyczny ekran i pod niego się projektuje. Cały obraz składa się z kafelków 8 na 8 pikseli — postacie, tła, tekst, dosłownie wszystko. Konsola obsługuje co prawda 32 768 kolorów, ale w praktyce na ekranie może ich być jednocześnie około 56. A pojedynczy kafelek ma maksymalnie cztery. I to jest właśnie urok oldschoolowego gamedevu: ograniczenia są tak ciasne, że żeby cokolwiek wyglądało ciekawie, trzeba wykazać się sporą pomysłowością.
Ekran ma też warstwy. Warstwa tła jest przewijana — na niej rozkładamy mapę poziomu, czyli układ kafelków ze wszystkimi blokami i elementami, które mają się pojawić. Na to nakłada się warstwa okna, na której trzymamy interfejs i dolny pasek z tekstem: elementy, które zostają na miejscu niezależnie od przewijania. Tekstu w konsoli nie ma z fabryki — jeśli chcesz wyświetlać napisy, musisz zbudować font z kafelków 8×8. Znalazłem kompaktowy, darmowy font na itch.io (do użycia z podaniem autorów) i lekko go przerobiłem, żeby pasował do stylistyki Syntax. (Informacja dodatkowa: itch.io to platforma z grami niezależnymi, na której twórcy udostępniają też zasoby dla twórców — fonty, grafiki i muzykę.)
Osiem na osiem pikseli to z kolei bardzo mało, jeśli marzą ci się jakiekolwiek detale. Dlatego bohaterowie — CJ, Scott i Wes — mają trzy kafelki wysokości (24 piksele) i dwa szerokości (16). Dzięki temu moje wąsy wyglądają jak wąsy, a nie jak kropka, a przy okazji postacie ładniej wypełniają ekran podczas skoków.
Dzień trzeci: cięcie zakresu i polowanie na bugi
Po dwóch dniach miałem spory zestaw grafik i grywalną platformówkę — brzydką, ale działającą. Byłem w połowie limitu, więc przetasowałem priorytety. Trzeci dzień poświęciłem na ściącię gigantycznego planu do rozmiaru, który da się dowieźć na czas. Zamiast trzech wielkich poziomów z trzema zagadkami każdy i bitwą z bossem zrobiłem: korytarz prowadzący do pierwszej zagadki, Syntax Doctor; drugi korytarz prowadzący do Bustera Buga; ostatni korytarz do zagadki Sokoban; a na sam koniec walkę z bossem. Wziąłem plan z wieloma korytarzami i rosnącą trudnością i zostawiłem samo sedno gry.
Trzeciego dnia żyłem też z bugów. Pojawiały się dziwne, przeskakujące kolory, sprite’y renderowały się w złej palecie — a wszystko to sprowadza się do zarządzania pamięcią. Nie napisałem ani jednej linijki C; robiło to AI. W naszej wymianie ustalało na przykład: „Wczytałem kolory jednego sprite’a do pamięci i zapomniałem ich zwolnić przed załadowaniem następnego — dlatego drugi narysował się złymi barwami”. Było sporo takich rund. Co jakiś czas ekran migał też pomiędzy kolejnymi klatkami — odświeżeniami obrazu — więc AI zoptymalizowało kod tak, żeby między rysowaniem klatek nie działo się za dużo. W techniczne szczegóły nie wnikałem; wystarczało, że opisywałem problem z wysokiego poziomu i prosiłem o naprawę.
Fabuła, ekran tytułowy i wybór bohatera
Bo gra ma fabułę: Scott, Wes i ja nagrywamy podcast, kiedy zostajemy wessani do komputera, żeby naprawiać, budować i wdrażać kod. A gra z fabułą potrzebuje sekwencji intro. Po uruchomieniu pojawia się scena z serią plansz opisujących, co czeka gracza — standard znany choćby z Pokémonów, gdzie tekst prowadzi cię przez historię. Zadbaliśmy o niecierpliwych: tekst można przewinąć szybciej, jeśli nie chce się czekać, aż litery pojawią się jedna po drugiej. Na końcu tej sekwencji czeka ekran wyboru postaci z opisami bohaterów i ich umiejętnościami specjalnymi. Wes obrzuca przeciwników gorącymi poradami, ja rzucam sadzonką (mieszkam w ogrodzie kodu), a Scott zdejmuje czapkę i ciska nią we wrogów. Wybierasz bohatera i przechodzisz grę jego umiejętnościami.
Pod koniec trzeciego dnia mieliśmy: działające menu główne, zapisy gry, sekwencję tytułową, poziom pierwszy z Syntax Doctor oraz poziom drugi z Buster Bugiem.
Dzień czwarty: szlif
Czwarty dzień to wyłącznie polish. Potrzebowałem ładnie wyglądającej gry, którą pokażę na Hack Week. Sprzątanie, dopracowywanie wyglądu, dokończenie i podpięcie reszty grafik oraz — w wersji maksymalnie uproszczonej — finałowy poziom, ostatnia zagadka i boss.
Muzyka z generatorów szumu
Ostatnia rzecz, bez której żadna gra nie jest kompletna: muzyka i efekty. Na Hack Week oddałem grę bez ani jednego dźwięku — na demo to żadna zbrodnia, nikt nie musiał wiedzieć, że ich nie ma. Ale wersja, która trafi do sklepu Syntax, będzie miała ścieżkę dźwiękową, więc nad nią teraz pracuję. GBDK 2020 przyjmuje muzykę w formacie UGE i istnieje kilka programów, które w nim tworzą. Sama konsola nie odtwarza „plików audio” — pracuje na generatorach szumu różnych typów, których parametry ustawia się tak, żeby brzmiały jak melodia albo jak bębenki, a sekwencer rozpisuje w czasie, który dźwięk kiedy gra. Naraz można uzyskać do czterech ścieżek. Znalazłem kilka darmowych utworów na itch.io, wziąłem je za bazę i przerabiam pod klimat „Syntax Error”. Chcę osobnej muzyki dla każdego poziomu, każdej zagadki i dla menu — przede mną jeszcze sporo roboty.
Tryb demonstracyjny i reklamówka
Jedna rzecz bardziej przydaje się w grze, która leży włączona w konsoli: tryb demonstracyjny, attract mode — pokaz rozgrywki, który pojawia się przed menu głównym. U nas widać najpierw Bustera Buga, a potem „gracza” przechodzącego poziom pierwszy. To zaprogramowane z góry ruchy: poziom naprawdę się ładuje, a sekwencja kroków i wciśnięć przycisków sprawia, że wygląda to, jakby grał żywy człowiek. Na pewno znacie to z automatów i starszych gier: nie wchodzisz w menu, a po chwili ekran sam pokazuje, co cię czeka. U nas naciśnięcie A otwiera menu główne. Zbudowałem to jako jedno z ostatnich zadań, bo chciałem nagrać mnóstwo ujęć rozgrywki na kilku Game Boyach i skleić z nich spot otwierający mój film z Hack Week.
Reklama: Game Boy Color. Scott i CJ właśnie zostali wessani w głąb kodu. Rozwalaj bugi, łam zagadki, przetrwaj śmierć, zbuduj i wdróż. To „Syntax Error” na Game Boya Color — napędzany przez Sentry. Game Boy Color. Daj się wciągnąć.
Cztery dni później
I stało się: w cztery dni zrobiłem działającą grę, wideo demo i przerobioną konsolę. Jestem bardzo zadowolony z tego, ile udało się osiągnąć w tak krótkim czasie. Teraz jednak chcę, żeby gra była na tyle dobra, żeby móc nią handlować w sklepie — i żeby była warta twoich pieniędzy. Od zakończenia Hack Week dopracowuję ją według pierwotnego planu: każda zagadka ma już kilka poziomów trudności, a poziomom podwoiłem rozmiar, więc przed każdą łamigłówką czeka więcej platform i przeciwników. Gra dostaje ostatnie szlify: testy z żywymi graczami i wyłapywanie finalnych bugów. Czas zamienić ją w prawdziwy, fizyczny produkt.
Okładka od człowieka, nie od modelu
Zacząłem od prototypu grafiki na pudełko. Ta z czasu Hack Week jest w porządku, ale to nie ten styl, którego szukam. Sporo pogenerowałem z AI i doszlifowałem wynik — teraz jest już blisko tego, co chciałbym widzieć na pudełku. Nie zamierzam jednak drukować grafiki wygenerowanej przez AI na setkach egzemplarzy fizycznej gry. Piszę więc do artystów. Jeśli kiedykolwiek próbowaliście zlecić rysunek, wiecie, jak ciężko jest dziś: w epoce AI dostaje się zalew botów próbujących sprzedać ci „sztukę”. Ale z kilkoma prawdziwymi ludźmi już rozmawiam — jedni nie odpisali, inni urwali kontakt. Grafika jest więc w toku, ale możesz być pewien jednego: na okładce wersji sklepowej będzie twórczość człowieka. Jeśli znacie artystę, który robi coś w tym stylu lub podobnym, dajcie znać w komentarzach. Możecie też napisać na cj@syntax.fm, jeśli chcielibyście odpłatnie stworzyć grafikę na fizyczne wydanie. Trudno znaleźć odpowiednią osobę, więc pomóżcie.
Na koniec
To tyle. Zrobiłem grę. Mam nadzieję, że obejrzenie tego było dla was frajdą. Pytania o proces, narzędzia i wszystko inne śmiało zadawajcie w komentarzach — na pewno pomogę. A jeśli sami budowaliście gry, koniecznie dajcie znać — chcę zobaczyć. Do zobaczenia wkrótce w sklepie Syntax. W następnym!