[Atari] AtariOnLine: Pamiętniczek dinozaurowych koderów

Na spotkaniu autorów gry "Technical Difficulties" dla Atari XL/XE, która jest żartobliwym nawiązaniem do gry "Chrome Dino", znanej ze współczesnych pecetów, opowiedzieli oni o swoim dziełku w sposób zabawny, ale i pouczający, szczególnie o chaotyczności i spontaniczności procesu twórczego, który doprowadził do sukcesu czyli prezentacji na tegorocznym zlocie Atarowców - Silly Venture. Zapis tego spotkania jest prawie dwugodzinny, montował Misza:



A przy okazji otrzymaliśmy wesoły tekst z zapisem zmagań Pecusia i Pirxa, przygody koderskie w postaci pamiętniczka. Tomasz "Pecuś" Pecko napisał:

Jak to się zaczęło?

Oczywiście nie chodzi o Wielki Wybuch, a pomysł zrobienia gry na SV2024SE. Otóż od jakiegoś czasu pracujemy z Pirxem nad programem poprawiającym funkcjonalność FujiNet. Przyznam, że nie szło nam to ostatnio i plan, by coś już działało i by można było to pokazać na Silly Venture, stał się nierealny. Problemy z dokumentacją, implementacją i dość dziwnym działaniem niektórych funkcjonalności FujiNeta doprowadzały nas do frustracji i powodowały, że postępów nie było widać.

W czasie luźnej dyskusji we wtorek, nieco ponad tydzień przed imprezą, rzuciłem:
- „Kurde no... jadę na to SV z niczem. Masz jakiś pomysł na coś prostego może?”

Na co Paweł odpowiedział:
- „No mam, gierka z chrome jak nie ma internetu.”

No i to wywołało pierwszą „burzę mózgów”:
- „W basicu, na znakach. Choć w sumie asembler tak samo prosty w tym wypadku.”
- „Czy losowość ma być, czy może jednak jakaś sekwencja powtarzalna?”
- „Dinozaur na sprajcie, a tło płynny scroll.”
- „Eeee... ale to nie byłby hires!”
- „No to trzeba by go na software'owych sprajtach”
- „A wyobraź sobie 8 zestawów znaków. Na każdym wszystko tak samo, tylko dino przesunięty o piksel. Razem ze scrollem płynnym zmieniasz zestaw.”

Jak widać, wszystkie koncepcje pojawiły się od razu i po 10-ciu minutach dyskusji było już mniej więcej wiadomo, jak będzie działała gra. Czyli finalnie 4 zestawy znaków, tryb tekstowy, płynny przesuw w lewo i jednoczesne przełączanie zestawów znaków, tak by dino przesuwał się w prawo w obrębie swoich znaków. Co da efekt przesuwającego się tła i nieruchomego dinozaura. Był jeszcze taki dziwny pomysł:
„A może zrobić to na grafice i użyć gotowych – szybkich – procedur graficznych ze Scorcha”, ale to nie był mądry pomysł.



Wieczór pierwszy

Ale to był wtorek. Pomysły pomysłami, a pierwszy wolny czas miałem dopiero w piątek, 9 sierpnia, po południu. W między czasie Paweł podesłał fonty i kod do swojej próby (chyba trzeciej) napisania tej gierki, zajrzałem do kodu i nic nie zrozumiałem, a może po prostu nie chciało mi się analizować, jak to działa, bo i tak trzeba było pisać od podstaw. Wersja Pawła była na sprajcie i ze światem w niższej rozdzielczości. I tak by nie pasowała do obecnej koncepcji. W piątek powstały więc… nowe fonty, bo na kod nie starczyło sił. Ale coś już było widać.



Wieczór drugi

Tu trochę skłamaliśmy. Wieczór drugi to była niedziela (11 sierpnia), ale w sobotę na chwilę usiadłem i zrobiłem „mapę świata”, czyli zadeklarowałem tablicę z listą obiektów trochę wykraczającą za ekran, tego dnia nie liczymy.



Na początku wieczora powstała główna pętla rozgrywki i jej kształt zadecydował trochę o niezbyt precyzyjnym działaniu kolizji czy skoków. Otóż cała logika gry działa z dokładnością do pojedynczego znaku. Sprawdzane kolizji czy klawiatury jest realizowane co cztery przesunięcia tła (każde o 2 piksele hires). Tak jest po prostu łatwiej to oprogramować, a nie wpływa to aż tak bardzo na przyjemność z grania.

Na główną pętlę gry składa się:

przepisanie obiektów z mapy na ekran (dinozaura nie ma na mapie!),

narysowanie dinozaura z jednoczesnym sprawdzeniem kolizji i ewentualnym końcem gry,

sprawdzenie klawiatury i joysticka i ustawienie odpowiednich flag definiujących stan dino,

przesunięcie ekranu o 2 piksele w lewo i zmiana zestawu znaków – czekanie 1 ramkę,

przesunięcie ekranu o 2 piksele w lewo i zmiana zestawu znaków – czekanie 1 ramkę,

przesunięcie mapy o jeden znak, animacja chmur,

przesunięcie ekranu o 2 piksele w lewo i zmiana zestawu znaków – czekanie 1 ramkę,

animacja obiektów (nogi dino, pterodaktyle),

przesunięcie ekranu o 2 piksele w lewo i zmiana zestawu znaków – czekanie 1 ramkę.
I to jest cała gra!

Jak widać przesunięcie mapy i animacja obiektów jest przeplatana z przesuwem ekranu, ale równie dobrze te operacje mogły by być wykonane na początku pętli, a wtedy widać by było wyraźniej, że mamy całą logikę, a następnie cztery przesunięcia o 2piksele (w sumie jeden znak) i tak w nieskończoność.

Niestety, Dino migał co 4 ramki, synchronizacja jest robiona do przerwania systemowego VBI w precyzyjniej do tyknięcia zegara. Wyglądało na to, że mimo tego, że procedury czyszczenia, rysowania i logiki nie są długie, to jednak nie kończą się przed wyświetlaniem przez ANTIC-a pola gry. Rozwiązanie? Minuta i przesunięcie pola gry o paręnaście linii w dół! (potem okazało się że w NTSC dalej miga).

Prawie wszystko to udało się zaprogramować w ciągu chyba dwóch godzin – to dość prosty kod i na koniec tego wieczora gra właściwie działała. Nie było jeszcze tylko sprawdzania kolizji i chmur. No i pozom trudności nie rósł – a to było ważne.

Wieczór trzeci

Pomysł na poziom trudności był następujący: mapa tworzy się tak, że po przesunięciu jej o 1 znak, na końcu (poza widoczną na ekranie częścią) dodawany jest kod obiektu, domyślnie gleba. Można wtedy policzyć odległość do ostatniej przeszkadzajki i jeśli jest większa od jakiejś wartości (definiującej poziom trudności) zamiast gleby generujemy przeszkadzajkę. Jeśli tę sprawdzaną odległość będziemy zmniejszać w trakcie rozgrywki, to przeszkadzajki będą pojawiały się coraz gęściej. Ja zaproponowałem pomysł, Paweł to zakodował.

Mi pozostało dopisanie kolizji i wymyślenie jak/kiedy ma zmieniać się poziom trudności oraz jak ma działać mechanizm losowania przeszkadzajek na końcu mapy i w zasadzie gra była już w 100% grywalna. Wtedy Paweł rzucił hasło:
„A może jak dino biegnie w prawo, to niech potem wraca?”

Potrzymaj mi piwo! Wystarczy rysować obiekty przepisując je z mapy w drugą stronę i przygotować 4 odwrócone zestawy znaków. Pół godziny i gotowe! No ale skoro wraca, to może śmieszniej byłoby odwrócić linię statusową i mieć widok z wnętrza monitora – proszę bardzo. W ten sposób w trzy wieczory (a mowa była o czterech…) mieliśmy gotową grę.

Wieczór czwarty

Wszystko działa, ale... Po przyjrzeniu się oryginałowi doszło do nas, że coś można by dodać - chmury! Żeby nie dotykać istniejącego i działającego kodu (bo jeszcze przestanie działać) postanowiłem, że chmury będą na sprajtach. Kolor szary
zamaskuje trochę niższą rozdzielczość. Kilka minut i już widać dwie na ekranie. Ale czemu tylko dwie? Wyświetlam przecież cztery! Zmiana priorytetów PM, nie widać nic. Kolejna zmiana, widać dwie, ale inne niż na początku! No cóż, tak to jest jak się nie zna czy nie pamięta specyfiki platformy, na którą się programuje...

W tym trybie dwa sprajty są pod polem gry. Szybka decyzja zmiany trybu w liniach, w których są chmury i... działa! Tylko czemu są czarne? Mija ponad godzina walki o szary kolor chmur i na koniec okazało się, że wpisuję kolor do rejestru sprzętowego, a PM mają cienie i mamy włączony OS i przerwania. Zapomniałem o tym. Ale jest sukces, brak tylko muzyki.

Muzyka! A było to w środę, 14 sierpnia, dzień przed deadline! Już tydzień wcześniej zapytałem Mikera czy nie ma jakiejś muzyki w szufladzie… niestety był na wakacjach, więc skontaktowałem się z Alexem i usłyszałem że ma muzykę gotową, tylko musi odpalić Atari, znaleźć dyskietkę i przenieść to na PC… I już o koło godziny 19:00 w środę są pliki! W międzyczasie dodany został napis Game Over oraz ikonka taka jak w oryginale.

Muzyka przyszła w formacie MPT, biorę player z dyskietki z programem, przeglądam dokumentację, robię wszystko co trzeba w kodzie, dodaję player i… cisza! W debuggerze Altirry widać, że kod playera się wykonuje, ale nic nie gra. Walka trwała kilka godzin, a skończyło się na konwersji za pomocą emulatora na SAP R3, ja padłem spać, a kod playera dodał Paweł, jeszcze trochę perypetii rano i już godzinę przed terminem mamy gotową grę!

Całość kodu i danych jest dostępna tu na Githubie. Można tam prześledzić nasze zmagania krok po kroku i zobaczyć jak szybkie pisanie nie poprawia jakości kodu. Już po party powstała wersja nie migająca w NTSC i jednocześnie grająca w tym systemie muzykę z poprawną prędkością. Zmieniony został także sposób przyrastania poziomu trudności i wydłużony skok, co powoduje, że gra staje się trochę łatwiejsza.

Nie napisałem tutaj, niestety, nic o pracy Pawła, bo to on przygotował oba intra i robił to jeszcze krócej niż ja pisałem kod gry. Ale może on doda coś od siebie.


Suplement od Pawła "Pirxa" Kalinowskiego:

Dodatek ode mnie. To powyżej to czwarta próba zrobienia śmiej-gierki z dino. Poprzednie były:

w Turbo Basicu XL na BASIC 10-Liner Contest, oparte na „silniku” gierki flappy, którą popełniłem z 10 lat temu,

w Mad Pascalu w celu przypomnienia MP (zrobiłem tylko jedną prostą gierę „skyscrapers” w Pascalu),

w asemblerku na Wapniaka 2018.

Żadna z tych wersji mi nie wyszła, kodowanie solo mnie nie zadowolo. Interko „Technical Difficulties” to żarcik z problemów na dawnych SillyVenture. Można to było zrobić znacznie lepiej, hakując oryginalną muzyczkę, ale jako że ze mnie haker na ST taki jak i poeta, to pociągłem jakieś nagranie z jutuba, jakość dźwięku była w nim zaskakująco nieżenująca, więc zabrałem się do konwersji na 4 bity no i tu szło ciężko.

W sumie sprawdziłem około 50 różnych metod konwersji sampli na 4-bit. To co słychać, to najlepsze, co udało mi się uzyskać, ale zupełnie nie maksimum możliwości Atarki. Robiłem to podczas wieczoru drugiego i trzeciego. Prawdziwy hakier zrobiłby tego sampla w kilku KiB, ze znacznie lepsza jakością, używając oryginalnego loopowania od Jochena Hippela. No, ale jak na 10-sekundowy żart to pewnie jakoś(ć) jest wystarczająca.

Jeszcze malutka informacja dla chcących skorzystać z playera LZSS we własnym kodzie – oryginalny player od DMSC działa tylko raz, nie pozwala na pętlenie muzyki i jej zmianę, w zasadzie nadaje się tylko do dem. Playerek z repo gry został poprawiony i znacznie łatwiej go użyć w niedemie.

Autorzy, gdy rozpoczynali pracę nad grą (wieczór pierwszy):

Autorzy po zakończeniu prac nad grą (wieczór czwarty):

2024-09-05 14:01 by Kaz

komentarzy: 12