Menu

gorgh

o buddyzmie, życiu i ideach

Kulisy powstawania gry "The Rescue Expedition"

victorioushappiness

Dzień dobry. W tym wpisie chciałbym podzielić się historią powstawania naszej gry na 8 bitowy komputer Atari XL/XE.
Produkcje gry rozpocząłem 22 Marca i zamysłem było stworzenie gry inspirowanej grą Aztec.

aztec
Jest to gra z lat 80 w trybie wysokiej rozdzielczości, w której eksplorujemy katakumby walcząc z przeciwnikami i zbierając fanty. Gra ma bardzo fajny klimat i miło mi się w nią grało.
Jak prawie wszystkie moje gry ta produkcja również planowana była w trybie hi-res, czyli rozdzielczości 320x240 przy 2 kolorach, jednak ze względu na wygodę programowania oraz szybkość rysowania zdecydowałem się na „wąski ekran” czyli jeden z trybów wyświetlania obrazu w Atari, gdzie obraz ma szerokość 256 pikseli, czyli 32 bajtów. Jak programiści zapewne dobrze wiedzą, taka organizacja ekranu bardzo dużo ułatwia- 32 razy 8 to 256, czyli jedna strona pamięci, więc jest to bardzo wygodne.
Zapomniałem wspomnieć, że gra powstawała w trybie bitmapy a nie znakowym- tryb bitmapy różni się od znaków tym, że każdy bajt ekranu ma swoją bezpośrednią reprezentacje w pamięci, w odróżnieniu od drugiego trybu, gdzie zmieniamy wygląd znaków, które mają rozmiar 8x8 pikseli i takimi znakami rysujemy obraz w pamięci ekranu.
Zdecydowałem się na to rozwiązanie, ponieważ chciałem, aby gra urozmaicony wygląd poziomów- teren miał być generowany losowo i miał być pofałdowany. W grafice znakowej byłoby to trudne do osiągnięcia.
floor


Poza tym myślałem, że dzięki zastosowaniu tego trybu będę miał możliwość szybszego rysowania ruchomych elementów- i faktycznie, dzięki zastosowaniu metody XOR można było uzyskać 3 przeciwników rysowanych w jednej ramce i to w systemie NTSC, czyli tam, gdzie cyklów procesora na jeden ekran jest sporo mniej (system NTSC wyświetla 60 obrazów na sekundę, system PAL – 50 ekranów).
Obiekty ruchome w trybie znakowym są rysowane dużo wolniej, ze względu na to, że najpierw trzeba przepisać tło, potem nałożyć maskę bitową, dodać sprite-a i dopiero przepisać to do pamięci. W trybie XOR po prostu odwracamy bity ekranu.

kod
Kolejnym elementem, który chciałem dodać, były wybuchy dynamitu, który niszczył teren, umożliwiając zejście niżej, jednak po dodaniu funkcjonalności, którą zaproponował jeden z testerów, czyli wspinania się na wyższe platformy, ta funkcjonalność stała się trochę zbędna. Poza tym procedury obsługi wybuchów i modelowania terenu były kłopotliwe, ponieważ zostawały na ekranie czasem śmieci, lub wybuch kasował elementy ekranu jak szkatułki. Last but not least cała ta procedura wchodziła w konflikt z innymi procedurami, najprawdopodobniej korzystając z tych samych zmiennych, co powodowało czasem zawieszenie ekranu, spowodowane „rysowaniem” elementów nie w obszarze pamięci ekranu ale w obszarze samego programu. Zrezygnowałem więc z tego elementu gry, co jednak nie obniżyło znacznie grywalności.

Aby zmieścić wszystkie 48 lokacji w pamięci, ekrany są generowane proceduralnie- w programie istnieje około 10 tabelek, każda po kilka kategorii, które są odpowiedzialne za ułożenie przystkich elementów ekranu, łącznie z przełącznikami, bonusami i tak dalej. Dla przykładu tabela pionowych ścian posiada kategorie: wysokość ściany, szerokość ściany, położenie na osi X, położenie na osi Y. Dzięki zastosowaniu proceduralnego rysowania ekranu wszystkie dane lokacji zajmują 3-4 kilobajty, czzyli tyle ile ma połowa 1 ekranu w trybie graficznym.


Moim priorytetem było to, aby gra działała w systemie NTSC. Aby to osiągnąć rozdzieliłem działanie procedur programu na parzyste i nieparzyste ekrany. W parzystych rysowani byli przeciwnicy, oraz obsługiwane wszystkie ruchome elementy ekranu jak szpikulce, ogień i krople kwasu. W ekranach nieparzystych rysowany był główny bohater oraz rysowana była lina, która musiała mieć przydzielone aż 70 % czasu ramki, ze względu na to, że może ona być rozciągnięta na całą wysokość ekranu.
W krytycznych momentach procedury zajmują 90% czasu procesora w ramce, jednak nigdy nie przekraczają tej wartości. Z początku bałem się, że w NTSC nie będzie muzyki, ale po rozpętleniu kodu rysującego przeciwników udało się zmieścić muzykę.
Gra ma 48 lokacji, dla wprawionego gracza przejście jej zajmuje 25 minut. Jednak ja sam, gdy już finalna wersja była gotowa poległem pierwsze 2 razy na 32 i 40 poziomie, chociaż przecież sam ją robiłem. Gra nie jest prosta, ale po pewnym treningu można ją spokojnie przejść.
Dużą rolę w powstaniu gry mieli testerzy, Marek „Poison” Pesout i Rafał „Mgr Inż Rafał” Chabowski. Muzykę do gry stworzył Michał „Caruso” Brzezicki.
Sądzę, że gra powinna się spodobać graczom, będzie ona miała swoją premierę za kilka miesięcy.

© gorgh
Blox.pl najciekawsze blogi w sieci