Historia pewnej gierki by Kaz 2009-06-28 23:07:42
Paweł "Sikor" Sikorski napisał był:
Chciałbym się dzisiaj podzielić z Wami, drodzy czytelnicy atarionline.pl historią powstania gry Sssnake It!. Gra nie jest jakimś dziełem sztuki, jednak dostępność kodu (wymóg regulaminu "Grzybsoniady") pozwoli młodym programistom na dogłębną analizę i być może sprawi, że wiele zarzuconych pomysłów ujrzy światło dzienne. Z autopsji wiem, że wiele projektów umiera śmiercią naturalną, bo coś tam. A nam potrzeba nowych programów.
Na początek troszkę historii. Po dyskusji na niniejszej stronie o braku nowych gier udało mi się odnaleźć porzucony onegdaj kod do gry Snake It! – nigdy nie ukończonego, choć grywalnego, projektu tej gierki. Udostępniłem na łamach portalu wersję, która wtedy powstała, jak również prosty edytor plansz, który powstał w 2004 roku.
.png)
.png)
Los chciał, że mniej więcej w tym samym czasie Grzybson ogłosił, że na "Grzybsoniadzie" jedyną konkurencją będzie wystawienie dowolnej gierki (początkowo miała być w ATASCII). Po namowach Kaz-a zgodziłem się dostosować stary projekt do nowych warunków. Postawiłem jeden warunek – dostanę grafikę do testów. Pierwsze, co uległo zmianie – to tryb graficzny. Zamiast preferowanego wcześniej trybu GR.7 postanowiliśmy zastosować tryb GR.15 (stąd grafika wygląda o niebo lepiej, niż w oryginale). Zrobiłem pierwsze przymiarki (w tym poprawki kolorów, które mi się deko rozjechały – Kaz może więcej o tym powiedzieć) i… dopadła mnie choroba, a projekt został odłożony.
Na szczęście na jakieś 2-3 tygodnie przed planowanym terminem "Grzybsoniady" udało się ruszyć wszystko dalej. Kod, muzyka (którą Kaz załatwił), grafika i… lipa… Gra zaczyna się zawieszać. Niestety, brak miejsca w pamięci, a uparłem się, aby wszystko zrobić w jednym pliku. W końcu męska decyzja: wyrzucam planszę z autorami (na szczęście mamy program "Integrator" od Larka – pomyślałem). Ostatnie przymiarki, znowu nie działa…
Tu u większości początkujących koderów rodzą się duże wątpliwości i – ku naszej rozpaczy – porzucenie kodu. Ale się zawziąłem (były nawet namowy ze strony Kaza, aby wszystko się doczytywało, ale się uparłem). Na jednym ze skanów moich zapisek (o których będzie mowa w dalszej części artykułu) widać, jak bardzo zmieniały się adresy poszczególnych danych w pamięci. Co gorsza – wszystko było robione „na ślepo”, gdyż trzeba pamiętać, że pisząc w Turbo Basicu XL – wszystko siedzi pod innymi adresami przy interpreterze (czyli wtedy, kiedy piszemy) i przy kompilacji. Po kompilacji sprawdzałem adresy kodu za pomocą "Super Packera" (a tu też się sporo działo po każdej zmianie – widać na „najdłuższym” skanie notatek). Bardzo owocny okazuje się pomysł Mikera, aby „dane wgrać na ekran, a przed uruchomieniem gry zamazać DOS” – w ten sposób udało się dodać dźwięki.
.png)
.png)
W końcu prawie wszystko gotowe – wydruk programu pomocny przy szukaniu błędów (skan), drobne zmiany, działanie… Prawie działa, ale jeszcze nie do końca. Aż wreszcie: udało się, efekty działają z grubsza jak założyłem wszystko chodzi, kwestia dołączenia obrazka z autorami (dzień przed wyjazdem na "Grzybsoniadę"). Wysyłam do Kaz-a wersję roboczą i… okazuje się, że dałem nie tą wersję obrazka przy TopSnakes, inny kolor ramki. Kaz mi przysyła ją dopiero rano, kolejne grzebanie (cholera, deko przesunięte) i jest. Udało się wyciąć to, co trzeba. Finalnie gra jest pokazana na "Grzybsoniadzie", gdzie zajmuje trzecie (na cztery) miejsce w konkursie.
Nieco później okazuje się, że pozostały dwa błędy: ucięta jedna linia w grafice TopSnakes oraz błąd krytyczny – zbyt niski indeks przy wpisywaniu top listy. Ale to był już drobny szczegół do poprawek – pięć minut roboty.
Kilka uwag:
1. Podczas pisania gry zrezygnowałem ze wstępnego projektu, aby żółte „kule” były teleportami. Stało się tak z dwu powodów – brak miejsca na całość oraz niegrywalność na trzecim (ostatnim) poziomie. Zamiast tego zastosowałem odbicia od nich.
2. Pisząc grę zastosowałem metodę odczytywania pozycji przez instrukcję LOCATE – przez to wąż czasem potrafi „wejść” na przeszkody, ale nigdy głową. Ponieważ wąż jest „śliski” – uznałem, że jest to do przyjęcia.
3. Duży problem z kwestią nazewnictwa. Ponieważ jest Top Snake, nie chciałem, aby gracz kończył przy przejściu jakiejś odległości. Stąd słowo „Distance” – jest to minimalna odległość (czas), jaki wąż musi osiągnąć, aby przejść do kolejnego poziomu.
Porady dla początkujących programistów:
1. Jeżeli nie używamy całej grafiki, to warto ją sobie pociąć „na kawałki”, trzymając w pamięci tylko to, co jest nam potrzebne (jak się przyjrzycie kodowi – to nigdzie nie trzymam całego ekranu).
2. Jeśli istnieje taka możliwość, to warto spakować sobie dane (tutaj nie jest wykorzystane).
3. Należy pamiętać, że często kod źródłowy siedzi gdzie indziej, niż wynikowy. Jeżeli planujemy program skompilować i zlinkować z biblioteką – podejrzyjmy, gdzie kod właściwie siedzi (idealny do tego jest "Super Packer", który nam powala podejrzeć, co gdzie siedzi, jak również zmienić adresy nagłówków).
4. Nie załamujmy się drobnymi niepowodzeniami, jak czegoś nie wiemy – pochwalmy się kodem na forum, zadawajmy pytania – z reguły ktoś pomaga.
5. Warto „dane” wczytywane połączyć w jeden blok (na przykład wspomnianym tu "Super Packerem"), wraz z nagłówkami (wskazującymi, co gdzie ma siedzieć).
6. Pamiętajmy, że większe projekty zazwyczaj pisze się więcej niż jeden wieczór. Sssnake It! miał chyba z 20-30 różnych źródłówek, zanim doszedł do ostatecznej wersji. Do tego doszły poprawki w lokalizacjach grafiki, muzyki… Wbrew pozorom, masa pracy.
Zastosowane środowisko developerskie:
Ponieważ nie potrafię pisać kodu dla Atari na pececie (przynajmniej nie w Turbo Basicu XL), całość pisałem na małym Atari (z wyjątkiem dołączania grafiki z autorami – tu pomógł "Integrator"). Do powstania gry od strony Atari w pełni wystarczające okazały się:
1. Turbo Basic XL ver. 1.5 – wprowadzanie kodu, wstępne testy.
2. Turbo Basic Compiler - kompilacja kodu.
3. Linker – do połączenia skompilowanego kodu z biblioteką Turbo Basica XL.
4. EkrExtraktor – prosta procedura w Turbo Basicu do wycinania bloków grafiki (autorska – ale śmiało można użyć do tego celu "GRFindera".
5. SuperPacker – połączenie grafiki w jeden blok (grafa7.dat na dyskietce), każdy obrazek ma nagłówek z adresem.
6. Chaos Music Composer – do ustawienia adresów muzyki/playera (tu jest baaardzo nisko).
7. Mossad – do zlinkowania całości (za mała pamięć w "Super Packerze") – uwaga, ważna kolejność, bo część danych zadeptuje runtime Turbo Basica!
8. Dużo cierpliwości przy poprawkach ;)
Zasadniczo to wszystko wystarcza, jednak użyliśmy jeszcze "Integratora", do dołączenia grafiki z autorami przed właściwym programem (problemy z małą pamięcią – a pamiętajmy, że wszystko działa na standardowym Atari z 64KB pamięci RAM. Miłego grania i pisania własnych programów życzy Sikor.
Chciałbym się dzisiaj podzielić z Wami, drodzy czytelnicy atarionline.pl historią powstania gry Sssnake It!. Gra nie jest jakimś dziełem sztuki, jednak dostępność kodu (wymóg regulaminu "Grzybsoniady") pozwoli młodym programistom na dogłębną analizę i być może sprawi, że wiele zarzuconych pomysłów ujrzy światło dzienne. Z autopsji wiem, że wiele projektów umiera śmiercią naturalną, bo coś tam. A nam potrzeba nowych programów.
Na początek troszkę historii. Po dyskusji na niniejszej stronie o braku nowych gier udało mi się odnaleźć porzucony onegdaj kod do gry Snake It! – nigdy nie ukończonego, choć grywalnego, projektu tej gierki. Udostępniłem na łamach portalu wersję, która wtedy powstała, jak również prosty edytor plansz, który powstał w 2004 roku.
Los chciał, że mniej więcej w tym samym czasie Grzybson ogłosił, że na "Grzybsoniadzie" jedyną konkurencją będzie wystawienie dowolnej gierki (początkowo miała być w ATASCII). Po namowach Kaz-a zgodziłem się dostosować stary projekt do nowych warunków. Postawiłem jeden warunek – dostanę grafikę do testów. Pierwsze, co uległo zmianie – to tryb graficzny. Zamiast preferowanego wcześniej trybu GR.7 postanowiliśmy zastosować tryb GR.15 (stąd grafika wygląda o niebo lepiej, niż w oryginale). Zrobiłem pierwsze przymiarki (w tym poprawki kolorów, które mi się deko rozjechały – Kaz może więcej o tym powiedzieć) i… dopadła mnie choroba, a projekt został odłożony.
Na szczęście na jakieś 2-3 tygodnie przed planowanym terminem "Grzybsoniady" udało się ruszyć wszystko dalej. Kod, muzyka (którą Kaz załatwił), grafika i… lipa… Gra zaczyna się zawieszać. Niestety, brak miejsca w pamięci, a uparłem się, aby wszystko zrobić w jednym pliku. W końcu męska decyzja: wyrzucam planszę z autorami (na szczęście mamy program "Integrator" od Larka – pomyślałem). Ostatnie przymiarki, znowu nie działa…
Tu u większości początkujących koderów rodzą się duże wątpliwości i – ku naszej rozpaczy – porzucenie kodu. Ale się zawziąłem (były nawet namowy ze strony Kaza, aby wszystko się doczytywało, ale się uparłem). Na jednym ze skanów moich zapisek (o których będzie mowa w dalszej części artykułu) widać, jak bardzo zmieniały się adresy poszczególnych danych w pamięci. Co gorsza – wszystko było robione „na ślepo”, gdyż trzeba pamiętać, że pisząc w Turbo Basicu XL – wszystko siedzi pod innymi adresami przy interpreterze (czyli wtedy, kiedy piszemy) i przy kompilacji. Po kompilacji sprawdzałem adresy kodu za pomocą "Super Packera" (a tu też się sporo działo po każdej zmianie – widać na „najdłuższym” skanie notatek). Bardzo owocny okazuje się pomysł Mikera, aby „dane wgrać na ekran, a przed uruchomieniem gry zamazać DOS” – w ten sposób udało się dodać dźwięki.
W końcu prawie wszystko gotowe – wydruk programu pomocny przy szukaniu błędów (skan), drobne zmiany, działanie… Prawie działa, ale jeszcze nie do końca. Aż wreszcie: udało się, efekty działają z grubsza jak założyłem wszystko chodzi, kwestia dołączenia obrazka z autorami (dzień przed wyjazdem na "Grzybsoniadę"). Wysyłam do Kaz-a wersję roboczą i… okazuje się, że dałem nie tą wersję obrazka przy TopSnakes, inny kolor ramki. Kaz mi przysyła ją dopiero rano, kolejne grzebanie (cholera, deko przesunięte) i jest. Udało się wyciąć to, co trzeba. Finalnie gra jest pokazana na "Grzybsoniadzie", gdzie zajmuje trzecie (na cztery) miejsce w konkursie.
Nieco później okazuje się, że pozostały dwa błędy: ucięta jedna linia w grafice TopSnakes oraz błąd krytyczny – zbyt niski indeks przy wpisywaniu top listy. Ale to był już drobny szczegół do poprawek – pięć minut roboty.
Kilka uwag:
1. Podczas pisania gry zrezygnowałem ze wstępnego projektu, aby żółte „kule” były teleportami. Stało się tak z dwu powodów – brak miejsca na całość oraz niegrywalność na trzecim (ostatnim) poziomie. Zamiast tego zastosowałem odbicia od nich.
2. Pisząc grę zastosowałem metodę odczytywania pozycji przez instrukcję LOCATE – przez to wąż czasem potrafi „wejść” na przeszkody, ale nigdy głową. Ponieważ wąż jest „śliski” – uznałem, że jest to do przyjęcia.
3. Duży problem z kwestią nazewnictwa. Ponieważ jest Top Snake, nie chciałem, aby gracz kończył przy przejściu jakiejś odległości. Stąd słowo „Distance” – jest to minimalna odległość (czas), jaki wąż musi osiągnąć, aby przejść do kolejnego poziomu.
Porady dla początkujących programistów:
1. Jeżeli nie używamy całej grafiki, to warto ją sobie pociąć „na kawałki”, trzymając w pamięci tylko to, co jest nam potrzebne (jak się przyjrzycie kodowi – to nigdzie nie trzymam całego ekranu).
2. Jeśli istnieje taka możliwość, to warto spakować sobie dane (tutaj nie jest wykorzystane).
3. Należy pamiętać, że często kod źródłowy siedzi gdzie indziej, niż wynikowy. Jeżeli planujemy program skompilować i zlinkować z biblioteką – podejrzyjmy, gdzie kod właściwie siedzi (idealny do tego jest "Super Packer", który nam powala podejrzeć, co gdzie siedzi, jak również zmienić adresy nagłówków).
4. Nie załamujmy się drobnymi niepowodzeniami, jak czegoś nie wiemy – pochwalmy się kodem na forum, zadawajmy pytania – z reguły ktoś pomaga.
5. Warto „dane” wczytywane połączyć w jeden blok (na przykład wspomnianym tu "Super Packerem"), wraz z nagłówkami (wskazującymi, co gdzie ma siedzieć).
6. Pamiętajmy, że większe projekty zazwyczaj pisze się więcej niż jeden wieczór. Sssnake It! miał chyba z 20-30 różnych źródłówek, zanim doszedł do ostatecznej wersji. Do tego doszły poprawki w lokalizacjach grafiki, muzyki… Wbrew pozorom, masa pracy.
Zastosowane środowisko developerskie:
Ponieważ nie potrafię pisać kodu dla Atari na pececie (przynajmniej nie w Turbo Basicu XL), całość pisałem na małym Atari (z wyjątkiem dołączania grafiki z autorami – tu pomógł "Integrator"). Do powstania gry od strony Atari w pełni wystarczające okazały się:
1. Turbo Basic XL ver. 1.5 – wprowadzanie kodu, wstępne testy.
2. Turbo Basic Compiler - kompilacja kodu.
3. Linker – do połączenia skompilowanego kodu z biblioteką Turbo Basica XL.
4. EkrExtraktor – prosta procedura w Turbo Basicu do wycinania bloków grafiki (autorska – ale śmiało można użyć do tego celu "GRFindera".
5. SuperPacker – połączenie grafiki w jeden blok (grafa7.dat na dyskietce), każdy obrazek ma nagłówek z adresem.
6. Chaos Music Composer – do ustawienia adresów muzyki/playera (tu jest baaardzo nisko).
7. Mossad – do zlinkowania całości (za mała pamięć w "Super Packerze") – uwaga, ważna kolejność, bo część danych zadeptuje runtime Turbo Basica!
8. Dużo cierpliwości przy poprawkach ;)
Zasadniczo to wszystko wystarcza, jednak użyliśmy jeszcze "Integratora", do dołączenia grafiki z autorami przed właściwym programem (problemy z małą pamięcią – a pamiętajmy, że wszystko działa na standardowym Atari z 64KB pamięci RAM. Miłego grania i pisania własnych programów życzy Sikor.
Kaz 2009-06-29 00:17:58
W artykule brakuje linku do zrodlowki, bo obawiam sie, ze takowej nie mam, szczegolnie, ze byly tam zmiany i poprawki po konkursie. Podeslij Sikor to podepne.
larek 2009-06-29 07:57:15
@Sikor: "[...] trzeba pamiętać, że pisząc w Turbo Basicu XL – wszystko siedzi pod innymi adresami przy interpreterze (czyli wtedy, kiedy piszemy) i przy kompilacji".
Przyznam, że pierwszy raz spotykam się z takim zarzutem w kierunku TBXL, a trochę już programów napisałem w tym języku. Przy projekcie gry ustalam precyzyjnie, co i gdzie ma siedzieć w pamięci i nigdy nie zdażyło mi się, żeby po kompilacji, coś się przesunęło! Oczywiście nie mamy wpływu na to, gdzie leży sobie kod programu, ale do niczego nam to nie jest potrzebne, a poza tym możemy jednak ustalić, gdzie go nie powinno być! Wystarczy aby obiżyć RAMTOP (komórka 106) o potrzebną wielkość pamięci (liczonej w stronach - 256 bajtów) i będziemy mieli wydzieloną część RAM'u przeznaczoną na dane i 100% pewności, że program nam w tem obszar nie wejdzie - zarówno przed, jak i po kompilacji.
sikor 2009-06-29 08:38:23
@Kaz: źródłowka jest taka sama, jak na Grzybsoniadzie. Zmieniły się tylko dwie linie, i to nieznacząco: linia z indeksem tablicy i indeks przy instrukcji for przy rysowaniu napisu "TOP SNAKES".
@Larek: tak, chodziło mi o kod, który ma zupełnie inną lokalizację po skompilowaniu i przed. Obniżenie ramtopu na dane pomaga, fakt, pod warunkiem, że danych mamy tyle, aby wszystko bezproblemowo weszło. Jednak jak masz dużo rzeczy - część musisz zarzucić na runtime od Turbo Basica - uzyskujesz kilkadziesiąt bajtów więcej (ważne, aby zachować kolejność przy linkowaniu). I o ile często coś chodzi pod interpreterem - o tyle po kompilacji i zlinkoiwaniu w jeden plik trzeba się mocno nagłowić, aby było o.k.
s2325 2009-06-29 09:13:41
ja wiem że na Atari rysowanie to nic przyjemnego (w dodatku joystickiem), ale bez przesady z tym zielonym robalem
bjc 2009-06-29 17:58:48
Gra nie wydaje sie skomplikowana, a tyle roboty... gratulacje za cierpliwosc.
miker 2009-06-29 19:16:27
@Sikor: przeglądając źródła Larka zauważyłem, że zawsze obniża on RAMTOP (komórka 106), co daje mu możliwość:
1. umieszczenia wszystkich danych za ekranem;
2. jak coś się zaczyna "nadpisywać" w pierwszej kolejności włazi na ekran.
Warto z tej lekcji skorzystać.
@Larek: sorry, że tak o Tobie w trzeciej osobie. :)
larek 2009-06-29 20:05:15
:)
sikor 2009-06-29 23:54:00
Gdzie mi do Mistrza Larka ;) A z lekcji skorzystam, choć - jak napisałem - czasem i tak trzeba coś gdzieś wcisnąć "pomiędzy" ;)
Yosh 2009-07-10 20:58:34
@bjc: w rzeczy samej - a pomyśl o tych bardziej skomplikowanych grach.... na 8mio bitowce to masakra :]
W artykule brakuje linku do zrodlowki, bo obawiam sie, ze takowej nie mam, szczegolnie, ze byly tam zmiany i poprawki po konkursie. Podeslij Sikor to podepne.
larek 2009-06-29 07:57:15
@Sikor: "[...] trzeba pamiętać, że pisząc w Turbo Basicu XL – wszystko siedzi pod innymi adresami przy interpreterze (czyli wtedy, kiedy piszemy) i przy kompilacji".
Przyznam, że pierwszy raz spotykam się z takim zarzutem w kierunku TBXL, a trochę już programów napisałem w tym języku. Przy projekcie gry ustalam precyzyjnie, co i gdzie ma siedzieć w pamięci i nigdy nie zdażyło mi się, żeby po kompilacji, coś się przesunęło! Oczywiście nie mamy wpływu na to, gdzie leży sobie kod programu, ale do niczego nam to nie jest potrzebne, a poza tym możemy jednak ustalić, gdzie go nie powinno być! Wystarczy aby obiżyć RAMTOP (komórka 106) o potrzebną wielkość pamięci (liczonej w stronach - 256 bajtów) i będziemy mieli wydzieloną część RAM'u przeznaczoną na dane i 100% pewności, że program nam w tem obszar nie wejdzie - zarówno przed, jak i po kompilacji.
sikor 2009-06-29 08:38:23
@Kaz: źródłowka jest taka sama, jak na Grzybsoniadzie. Zmieniły się tylko dwie linie, i to nieznacząco: linia z indeksem tablicy i indeks przy instrukcji for przy rysowaniu napisu "TOP SNAKES".
@Larek: tak, chodziło mi o kod, który ma zupełnie inną lokalizację po skompilowaniu i przed. Obniżenie ramtopu na dane pomaga, fakt, pod warunkiem, że danych mamy tyle, aby wszystko bezproblemowo weszło. Jednak jak masz dużo rzeczy - część musisz zarzucić na runtime od Turbo Basica - uzyskujesz kilkadziesiąt bajtów więcej (ważne, aby zachować kolejność przy linkowaniu). I o ile często coś chodzi pod interpreterem - o tyle po kompilacji i zlinkoiwaniu w jeden plik trzeba się mocno nagłowić, aby było o.k.
s2325 2009-06-29 09:13:41
ja wiem że na Atari rysowanie to nic przyjemnego (w dodatku joystickiem), ale bez przesady z tym zielonym robalem
bjc 2009-06-29 17:58:48
Gra nie wydaje sie skomplikowana, a tyle roboty... gratulacje za cierpliwosc.
miker 2009-06-29 19:16:27
@Sikor: przeglądając źródła Larka zauważyłem, że zawsze obniża on RAMTOP (komórka 106), co daje mu możliwość:
1. umieszczenia wszystkich danych za ekranem;
2. jak coś się zaczyna "nadpisywać" w pierwszej kolejności włazi na ekran.
Warto z tej lekcji skorzystać.
@Larek: sorry, że tak o Tobie w trzeciej osobie. :)
larek 2009-06-29 20:05:15
:)
sikor 2009-06-29 23:54:00
Gdzie mi do Mistrza Larka ;) A z lekcji skorzystam, choć - jak napisałem - czasem i tak trzeba coś gdzieś wcisnąć "pomiędzy" ;)
Yosh 2009-07-10 20:58:34
@bjc: w rzeczy samej - a pomyśl o tych bardziej skomplikowanych grach.... na 8mio bitowce to masakra :]