Logo



Wstęp

     Tekst ten zawiera moje wspomnienia z prac nad polskimi grami na platformy Game Boy Color i Game Boy Advance pod egidą Mirage na przełomie XX i XXI wieku (jak to brzmi ;). Jest bardzo subiektywny i pisany z punktu widzenia ich głównego programisty ( więc miejscami mocno techniczny). Używam angielskich nazw (tilemapa, tiles, sprites, cart), chociaż istnieją polskie odpowiedniki (duszek, łatka... ale wywraca mi flaki na lewą stronę jak je słyszę) ). Już prawie 20 lat, minęło, część informacji się zatarło a fakty rozmyły. Jeśli ktoś ma uwagi, zastrzeżenia czy chciałby, aby jego dane zostały usunięte - proszę o kontakt. Copyright itp w stopce strony. Kontakt w zakładce "Contact".

Game Boy Color

     Skąd moje zainteresowanie konsolką Nintendo ? Na początku lat 90, z jednego z wyjazdów zagranicznych przywiozłem - mocno wtedy reklamowanego - Game Boya. W Polsce prawie nikt o nim jeszcze nie słyszał. W zestawie oczywiście był tetris. Po kilku miesiącach zabawy - z powodu braku dostępu do gier - konsolkę wymieniłem na osprzęt do Amigi. Ale sentyment został...

     Kilka lat później ( około 1998 roku ) będąc na studiach znalazłem w sieci stronę z pobieżnymi informacjami o hardware Game Boya. Zacząłem analizowac szczątkową dokumentację, disassemblowac romy z gier. Napisałem emulator rdzenia cpu. Rok później powstał Hash – emulator GBC. Jako pierwszy udawał tryb tzw “hicolor” (o tym później ). Niestety, nie radził sobie zupełnie z dźwiękiem. Od tamtego czasu zająłem się hobbystyczne pisaniem emulatorów ( GBC, Wonderswan, GBA ). Później (2000 ?) dołączyłem do MAME development team, gdzię wciąż zdaża mi się coś napisać. Wbrew pozorom emulacja i emulatory ma spory "udział" w powstanu HoT. Ale o tym za moment.

     Wracając do konsolki GBC Nintendo. Krótki opis jej możliwości.

Procesor

8 bitowy Sharp LR35092, "trochę więcej niz i8080, dużo mniej niż Z80" . Zegar 1/2 (lub 4/8 - jak kto woli) MHz

Pamięć

32 KB RAM, 16 KB Video RAM.
od 32KB do 8 MB na carcie.

Grafika

Ekran LCD 160x144 pixeli.
Typowo "konsolowo/automatowy" hardware ( użyty po raz pierwszy bodajże w grze Galaxian). Tilemapy i tiles (8x8 pixeli w 4 kolorach z 8 palet).
Grafika podzielona jest na kwadraty ( zwane tiles ) 8x8 pixeli w 4 kolorach. Tilemapa definiuje gdzie na ekranie znajduje się dany tile ( każdy tile może być wyświetlany w wielu miejscach ).
40 sprites ( zwanych "objects" przez Nintendo ) 8x8 lub 8x16, bazujące na tych samych tiles co tilemapa.
Do dysposyzji mamy 512 tiles. Tilemapa ma rozmiar 32x32 tiles, czyli 256x256 pixeli. Na ekranie możemy wyświetlić jej dowolny fragment o rozmiarze 160x144 pixeli ( zaznaczony na czerwony na screenie poniżej ). Dodatkowo istnieje kolejna warstwa ( również tilemapa ), tzw window, wyświetlana podnad tłem ( background ), używana w grze ( odpowiednio manipulując rejestrami układu graficznego ) do wyświetlania statusu, mapy, kieszeni oraz dialogów. Generalnie trzeba było używać bardzo wielu różnych sztuczek i obejśc by uzyskać zamierzone efekty na ekranie.

Dźwięk

2 kanały square wave, 1 noise, 1 odtwarzający krótkie sample. Niewiele, ale można było uzyskać naprawdę fajne efekty.

Sterowanie

8 kierunkowy D-pad i 4 przyciski (START, SELECT, A , B)

Mirage

     W czasie studiów, często korzystałem z IRC. "Siedziałem" na kanałach związanych z emulacją (#emu-pl , #emu). Poznałem tam między innymi Lecha Buszczyńskiego ( webmastera 'Nostalgii' ) , pracującego w Mirage Software. Po jakmiś czasie pojawił się pomysł zrobienia Mortyra w wersji na handheld Game Boy Color. Przygotowałem prosty prototyp i pojechałem do Warszawy. Spotkałem się z ówczesnym CEO Mirage - Tomaszem Mazurem. Zapadła pozytywna decyzja. Dostałem również namiary na grafika. Adam Karol był autorem oprawy graficznej kilku gier na Atari i Amigę, wydanych wcześniej przez Mirage (m.in. Magia, Janosik, Jurajski Sen, Poltergeist). Jego ilustracje były również zamieszczone w Kompedium Secret Service. Po wstępnych rozmowach prace powoli ruszyły. Była to prawdopodobnie końcówka 1999 roku. Ja studiowałem, Adam pracował. Mortyrem zajmowaliśmy się po godzinach. Biuro Mirage mieściło się w Warszawie. Adam mieszkał w północnej części kraju. Ja - na Śląsku ( Rybnik ). Na szczęście był internet ( 0 20 21 22 .... koszmarnie wysokie rachunki, na szczęście Mirage pokrywał ich znaczną część ) i dawało się to wszystko jakoś koordynować. Później Adam przerzucił się całkowicie na tworzenie grafiki do gry, rezygnując z pracy. Ja zawiesiłem studia ( na 5 roku ... bywa ). Projekt się rozrastał i wymagał coraz więcej czasu. Dźwiękiem miał początkowo zająć się Yerzmyey ale pojawiły się problemy z czasem/jego dostępnością. Do pracy nad Mortyrem GBC zwerbowany został Krzysztof Wierzynkiewicz. Wcześniej jego muzykę można było usłyszeć w kilku Amigowych grach wydanych przez Mirage ( Rockstar, Wisielec ). Również i jego można było złapać na IRC ( był webmasterem strony MAME hot ). Project Managerem ( i designerem / scenarzystą ) od poczatku był Lech Buszczyński ( chociaż często jakiś pomysł dorzucał ktoś inny z zespołu ). Dodatkowo w HoT designem zajmowali się także Marcin Konicki i Piotr Tkaczyk - stworzyli m.in. "inteaktywną" dokumenatcje kilku poziomów jako aplikację flash. Po nawiązaniu współpracy z Titus Software ( wydawcą ), producentem po francuskiej stronie został Paul Leskowicz.

     Podczas tworzenia gier na konsolki Nintendo Mirage przechodziło wiele przemian ( Mirage Media -> Mirage Interactive ). Zmieniały się sposoby współpracy, szefowie ( Tomasz Mazur, Tomasz Sychowicz ) i współpracownicy. Przez cały okres prac trzonem zespołu byli: Lech, Adam, Krzysztof i ja. Wciąż pracowaliśmy "na odległość", ale co jakiś czas mieliśmy (w różnym składzie, czasem z ludźmi z Titusa) spotkania w Warszawie, w siedzibie Mirage na Obrońców ( podczas jednego z wyjazdów do Warszawy paskudnie skręciłem nogę w kostce, co daje mi się we znaki jeszcze dziś). W późniejszym okresie otworzyłem w Rybniku małe domowe biuro, w którym pracowały w porywach trzy osoby ( Wojciech Wrona, Jacek Cichopek i ja). Mieliśmy sprzęt PC, devkit GBA no i TV do wspomagania się MTV, Cartoon Network i Fashion TV. Później w biurze stanął jeszcze automat do gier. Zdarzały się firmowe grille na Śląsku i w Warszawie. W 2001 roku, miesiąc przed atakiem na WTC ja i Lech polecieliśmy na targi ECTS do Londynu.

     Współpraca trwała gdzieś do końca 2003 roku. Niestety, sporo projektów ( wszystkie GBA ) pozostało w fazie prototypu. Powodów było wiele. Najważniejszymi było spore nasycenie rynku grami GBA i upadek wydawcy, Titus Interactive.

     Po 2003 roku stworzyliśmy z Adamem jeszcze kilkanaście gier mobilnych. Później Adam wrócił do pracy grafika i nie jest związany już z gamedev. Ja jeszcze przez kilka lat zajmowałem się grami, głównie przenoszeniem klasyków z ich platform bazowych na mobilne (m.in. Sonic, ChuChu Rocket dla Segi). Od kilku lat zajmuję się już wyłącznie (a szkoda... bardoz szkoda) aplikacjami biznesowymi iOS. W branży pozostał Krzysztof i od lat tworzy profesjonalną muzykę nie tylko do gier (Witcher, Bulletstorm, Wiedźmin).

Titus

     Wydawcą gier GBC Mirage była firma Titus Interactive.. Późniejsze problemy finansowe mocno rzutowały na sytuację w dziale "handheldowym" Mirage. Upadek i bankructwo Titusa ostatecznie zablokowało plany na dokończenie i wydanie gier GBA.

Narzędzia

     Jakie narzędzia były wykorzystywane przy produkcji gry? Najważniejszy to zestaw kompilator assemblera + linker. Wybór padł na Rednex Game Boy Development System ( w skrócie RGBDS ). Powstał około 1998 roku, źródła można znaleźć na Githubie. Jest to darmowy, nieoficjalny ( i znacznie lepszy od oficjalnego ) pakiet narzędzi. Do tego Ultraedit z konfiguracją kolorującą składnię assemblera. Używałem także Visual C++ do tworzenia własnych edytorów i narzędzi własnych.

     Z grafiką już nie było tak prosto. Do tworzenia grafiki i edycji poziomów używaliśmy świetnego (także darmowego) TileBuddy. Malezyjska (!) firma GameBrains, produkjąca gry na GBC, pod koniec lat 90 udostępniła kilka fajnych tooli, m.in. TIleBuddy i SpriteBuddy. Pierwszy do edycji tiles i tilemap, drugi - do sprites. TileBuddy zaadoptowaliśmy od razu. Do tego własny edytor zdarzeń i obiektów (MLE - Mortyr Level Editor). Działało bez problemów. SpriteBuddy miał być uzwany w następnych projektach ( ale nie został ...). Później Adam zaczął powoli używać Pro motion. Bardzo dobre narzędzie do pixelowania, w stylu starego, dobrego Deluxe Painta. Ma również spore możliwości rozbudowy o pluginy i dodatki. Przez długi okres czasu (aż do wersji 6) byłem jednym z testerów tego narzędzia ( jako programista ) i gorąco go wszystkim polecam.

     O ile z grafiką poszło w miarę łatwo o tyle z dźwiękiem był spory problem. Istniało kilka firm oferujących swoje usługi, ale polegało to na tym, że oferowali gotową muzykę pisaną na zamówienie wraz z biblioteką ją odtwarzającą. Koszty zazwyczaj były bardzo wysokie. Ratunkiem okazał sie Paul Bragiel kierujący wtedy firmą Paragon5, zajmującą się tworzeniem oprogramowaniem i muzyki na GBC. Poznałem go wcześniej (Paul mocno udzielał się na demoscenie). Udostępnił nam Beyond Tracker ( zwany też p5 trackerem ) - świetny tracker umożliwiający pisanie chiptunes na GBC.

     Wszystkie dane umieszczone na carcie były skompresowane. Mirage wykupiło licencję na popularny i szeroko używany na wielu platformach ProPack ( RNC ). Pozwoliło to umieścić w grze naprawdę sporo danych przy bardzo krótkim ( w zasadzie niezauważalnym ) czasie dekompresji.

     Do testowania HoT czasami używałem emulatorów. Zmieniłem i przebudowałem własny ( Hash ) tak, by łatwiej go było używać w pracy. Powstał MD Mortyr Debugger. Hardware GBC ma jednak wiele ograniczeń, m.in. pamięć video nie jest dostępna podczas wyświetlania obrazu. Wiele emulatorów miało z tym problemy, stąd testowanie gry na prawdziwej konsolce było konieczne. Używaliśmy do tego Xchangera. Sprzęt był przeznaczony głównie do odpalania pirackich gier, ale doskonale nadawał się do pracy. Nie umożliwiał oczywiście tego, co oficjalny devkit sprzętowy Nintendo, ale był dużo łatwiejszy do dostania ( i o wiele tańszy ). Oprócz tego do tesstów miałem własny C3 ( Carbon Copy Card - orginalny cartridge Nintendo, z podmienonym ROM-em na Flash Rom ). Xchanger "prawie" idealnie udawał carta GBC. Nie do końca jednak wiernie symulował układy MBC ( memory bank controllers ). Docelowo HoT miało używać MBC5 i obsługiwać 8 Megabitów pamięci ROM. Stąd pojawił się pomysł, by grę zabezpieczyć przed "piraceniem". Ustawiając odpowiednią sekwencję przełączania banków ROM, otrzymywało się inne wyniki na prawdziwym carcie Nintendo, a inne na Xchangerze. Napisałem dosyć złośliwy ( do usunięcia), samomodyfikujący się kod trzymany w RAM-ie. Testował MBC na kilka sposobów w kluczowych momentach gry i odpowiednio "subtelnie" modyfikował rozgrywkę ;) Niestety, podobnie jak kilka innych, późniejszych pomysłów - został on storpedowany przez wydawcę. Sprawa o tyle dziwna, że inne tytuły były zabezpieczone w podobny sposób. Jedynym minusem był wymóg testowania gry na CCC, devkicie Nintendo lub odpowiednio zmodyfikowanym emulatorze ( emulatory dokładnie symulujące zachowanie MBC pojawiły się później ).

     Testowaniem ( czyli graniem, graniem, graniem ) zajmowali się wszyscy. My, inni pracownicy Mirage, rodziny. Z perspektywy lat ( i innych projektów ) muszę przyznać, że brakowało trochę spojrzenia z dystansu, z innej perspektywy. Ludzie zbyt zaangażowani w pracę nad grą często nie widzą jej wad i nie wyłapują oczywistych błędów. Wiedzą jak grać i pomijają wiele innych rozwiązań, często nielogicznych. Dobry zespół QA i projekt obłożony masą scenariuszy testowych to jednak podstawa. Wydawca posiadał własny team QA, ale testowanie ( z tego co pamiętam ) nie było zbyt intensywne.

Hands of Time GBC ( tytuł roboczy: Mortyr)

    Zacznę nietypowo, bo od muzyki z gry autorstwa Krzysztofa. Można jej posłuchać tutaj. Polecam ( w szczególności track 02 ) jako tło do czytania tego tekstu.

    Jak już wczeniej wspominałem, gra miała być mini wersją Mortyra PC ( jednak Titus polecił zmienić nazwę na "Hands Of Time" ). Wspólny jednak miał być jedynie ogólny zarys fabuły. Zamiast fps wersja na mini konsolkę Nintendo to połączenie gry przygodowej ze zręcznościową. Gracz steruje postacią Sebastiana Mortyra, syna słynnego naukowca. Ojciec wysyła swojego potomka w przeszłość, by ten ocalił świat ( jak to bywa w grach ).

    Mamy - podobnie jak w Zeldzie - widok z lotu ptaka. Gra jest spora: intro + 8 poziomów. Każdy podzielony na bloki o rozmiarze 256x256 pixeli ( na ekranie widoczny jest wycinek 160x128 pixeli, płynnie scrollowany wenwątrz bloku). W sumie mamy ponad 200 różnych bloków. Kilkanaście postaci do spotkania ( i porozmawiania ), kilkadziesiąt przedmiotów do znalezienia i użycia. Interaktywne elementy są zazwyczaj sygnalizowane czerwonym "!" nad postacią Sebastiana. Przejście całości trochę trwa. Można oczywiście skorzystać z dokładnego opisu.

    W początkowych poziomach gry walczymy głównie z żołnierzami. Dodatkowo w podziemiach żyja szczury i pająki. Później, po wysadzeniu maszyny czasu scenariusz skręca w kierunku lekkiego horroru. Pojawiają się duchy, zombie, szkielety i podobne stworzenia. Tu i ówdzie można znaleźć również nawiązania do innych gier:

    Gra została wydana w dwu wersjach, różniących się grafiką boxa i carta. Pierwsza - z czarnym tłem - została stworzona oprzez Adama. Drugą przygotował wydawca, i tylko (?) ta przeszła końcową akceptację. Jednak po jakimś czasie można było zobaczyć grę w wersji z pierwszą szatą graficzną. Prawdopodobnie jest to reedycja lub osobna wersja US ( lub EURO ). Również ( pisany niżej ) RoboCop ma dwie wersje graficzne.

    Tutaj mała ciekawostka - oprócz powyższych wersji oficjalnych ( a co za tym idzie - legalnych ), Hands of Time można znaleźć również na kilku pirackich składankach xxx in 1. Wciąż do dostania na Aliexpress ;)

    Co się stanie gdy carta z HoT włożymy do zwykłego Gameboya, a nie do wersji Color? Zobaczymy poniższy screen. To jedno z wymagań Nintendo. Cała gra obłożona była szeregiem wymogów, sprawdzanych przez N po wysłaniu im wersji finalnej. Każda gra wydawana na konsolke N przechodziła przez tzw Lot Check. Hands of Time zostało dwa razy odrzucone. Po raz pierwszy - za błędy językowe (w wersji angielskiej). Drugi raz za użycie niedozwolonego logo Nintendo. Każa z gier musi na starcie przez określoną liczbę sekund wyświetlić ekran licensyjny, zawierający formułkę w rodzaju "Licensed by Nintendo", przy czym słowo Nintendo nie może być wizualnie zbliżone do oficjanlego loga N ( co sugerowałoby, że jest to oryginalna produkjca Nintendo ). U nas wyglądało zbyt podobnie... No ale za trzecim razem nie było już problemów. Rekordem odrzuceń może poszczycić się inna gra Titusa, flagowy Titus the Fox. Po kilkunastu nieudanych próbach wydawca musiał osobiście uzgadniać z N warunki wydania gry. Ale to i tak nic w prównaniu z tym co ( i jak) robi dziś Apple z apliakcjami/grami czekającymi na review (również obowiązkowy przed wrzuceniem do Appstore).

    Wydawca zdecydował się na sześć wersji językowych. Gracz na początku wybiera wersję, która mu odpowiada. Jak to przy tłumaczeniach bywa, pojawiły się problemy m.in. z długością niektórych wyrazów (szczególnie w wersji niemieckiej). Do sprawdzania poprawności wyświetlania tekstów i konwersji na format używany w grze istniało specjalne narzędzie TextC, które wyświetlało wszystkie dialogi dokładnie tak, jak to wyglądało na ekranie konsolki.


    Ekran tytułowy ( animowany ) pozwala rozpocząć grę, zobaczyć ponownie intro, lub wpisać kod. Niestety, nie było możliwości zapisania stanu gry. Wydawca oszczędzał, a podtrzymywana bateryjnie pamięć na carcie ( służąca do zapisu stanu gry ) to był dodatkowy, niepotrzebny koszt. Kody dostępu do poszczególnych leveli można znaleźć poniżej, przy opisie poziomów. Dodatkowo KXYU aktywuje cheat mode, a DOXC przechodzi do credits. Przed każdym levelem wyświetlana jest stylizowana mapa gry z zazaczonym miejscem rozgrywki.

     Sebastianem sterujemy za pomocą D-Pada. Szybkie, podwójne naciśnięcie kierunku powoduje bieg. Przyciskiem A używamy przedmiotów i rozmawiamy z osobami. B to strzał z wybranej wcześnie broni ( jest tego trochę, w tym granaty ). Przeciwnicy po zabiciu odradzają się. Jest to sporym utrudnieniem dla gracza. Gra ogólnie jest dosyć trudna. Łatwo zginąć. Pomocą mogą być porozstawiame w różnych miejscach apteczki i "tarcze", które prze krótki okres czasu zmniejszają obrażenia (ale nie blokują ich zupełnie).

     Po naciśnięciu START można zobaczyć zawartość plecaka Sebastiana. Miejsce jest sporo: 12 slotów na przedmioty i 8 na różnego rodzaju bronie, włącznie z granatami. Podstawowym narzędziem eksterminacji był jednak pistolet z niekończącą się amunicją. Na życzenie wydawcy, pod klawisz SELECT został podpięty prosty widok schematycznej mapy aktualnego poziomu gry, a właściwie to jego "odwiedzonej" części. Miało to ułatwić graczowi orientację w terenie. Przesuwajac kursor po mapie dostajemy dodatkowe informacje o kolejnych lokacjach ( np "Church" , "House" )

     W HoT oprócz chodzenia "na piechotę" można poruszać się kilkoma innymi środkami lokomocji. W trzech przypadkach ( czołg ( Castle road), transporter ( Secret lab ) , łódź (Swamps ) ) zostały wydzielone specjalne obszary, których nie można pokonać pieszo. Jedynie zbroja ( a raczej "mech suit" ) pozwalała na swobodne poruszanie się po całym terenie poziomu (Castle Cathedral). Mamy również cztery dodatkowe wersje paska statusu.

     W pierwszych wersjach gry ( jeszcze przed zmianą tytułu ) zaimpelmentowano rownież obsługę drukarki (Game Boy printer), która miała pozwalać na drukowanie aktualnej mapy. Sama drukarka była wypożyczona od ktoregoś z pracowników Mirage. Jednak pomysł ten nie spodobał się Titusowi i został "ubity"...

    Poniżej kilka słów o każdym etapie ( plus kody dla wersji Easy i Hard).

INTRO

    Wprowadzenie. Cutscenka pokazująca jak profesor wraz z synem przedostają się do laboratorium. Sebastian zostaje wysłany w przeszłość by zmienić historię. Całość bazowała na specjalnym języku skryptowym sterującym animacjami.

CASTLE ROAD ( DDCA / BXCL )

    Droga do zamku. Pierwszy ( i chyba najdłuższy etap gry ). Sporo otwartej przestrzeni, kilka budynków do zwiedzenia, podziemne tunele. Poza tym rozsuwany most i kawałek torów. Przeciwnicy to głównie żolnierze. Mamy takżę kawałek poligonu do przejechania czołgiem.

INNER WALLS ( ZWJX / VHRV )

    Za murami zamku. Wioska ( a właściwie to małe miasteczko ). Budynki ( pralnia, szpital) oraz lotnisko wraz z hangarami. Dużo zwiedzania, przebierania i czasami - straszenia. Po raz pierwszy pojawia się 'Evil agent' wysłany naszym śladem w przeszłość.

TUNNEL ( YSEI / XIJH )

    Tunel. W miarę krótki level - opuszczony tunel prowadzący do zamku. Używając dźwigni, kluczy ( czasami i wytrych się przydaje ) musimy znaleźć wyjście. Po drodze naprawa wybrakowanego mechanizmu. Przeciwnicy to "tylko" myszy i pająki. Te pierwsze trochę niewyrośnięte, w porównaniu z innymi, które spotkamy później.

THE CASTLE ( QTWW / ZOUY )

    Zamek. Spory poziom. Dużo pomieszczeń ( włącznie z tym najważnieszym - kuchnią oczywiście ). Dodatkowo zwiedzamy podziemia / kanały, gdzie trzeba znaleźć zagubiony (znowu)klucz. Głównym celem jest dostanie się do tajnego laboratorium.

SECRET LABORATORY ( EOVU / JVYP )

    Laboratorium. W końcu nasz główny cel jest blisko. Poruszamy się po laboratorium i systemie kanałów wentylacyjnych ( dosyć szerokich ... ). Wentylatory są oczywiście zabójcze. Trzeba rownież uważać na strefy skażone promieniowaniem (jak to w każdym laboratorium ... ). Pod koniec troche jazdy trasporterem, wysadzenie maszyny czasu i pierwsze spotkanie z Evil Agentem.

CASTLE CATHEDRAL ( KLQS / MMNE )

    Katedra. Tutaj jest już cięzko. Naprawdę ciężko. Bo wysadzeniu maszyny czasu pojawiają się komplikacje. Sporo mutantów, pająków i zapadającuch się platform. Musimy znaleźć nową broń - miotacz ( amunicję uzupełnia się w pobliżu niebieskich butli ). I zabijać. Kolejny kluczowy element to mech suit. No i boss, do pokonania. A poźniej kolejne spotkanei z Evil Agentem. Nieco zmienionym ( zmutowanym )

CEMETERY ( APHH / LYVV )

    Cmentarz. Jak dla mnie to jeden z fajniejszych leveli, inspirowany trochę grą Ghosts'N Goblins. Przez innych ( recenzentów, graczy ) uważany jest za bardzo (zbyt bardzo) odstający od reszty. Amatorzy... Cytując "I realized the makers of this game were definitely smoking something when they made this level".

SWAMPS ( ZXOL / PMAI )

    Mokradła.Tutaj cześciowy ( ??? ) powrót do normy. Możemy (albo raczej - musimy) poływać łodzią, zebrać kilka dzwonów i zlikwidować bossa. Przeszkadzają nam m.in zombie i duchy ( czyli całkiem normalnie ). Nic specjalnego. Jak to na mokradłach.

WEAPON LABS ( YOTX / LCIO )

    Laboratoria. Końcowy etap gry. Lokacje znane z intra. Sebastian może użwać teleportów (po znalezieniu karty). Sporo przeszkadzajek, w tym lasery strzelające ze ścian

    Na koniec opisu mały bonus. Skany kilku notatek / szkiców.

     Gra zebrała średnie recenzje (od 4/10 po 6/10). Cytując autora solucji:
In my opinion Hands of Time is an okay game. It's nothing spectacular, but it's not infuriating, impossible, or full of bugs, either. Give it a shot. You'll figure out soon enough if it's the sort of game you want to complete.



RoboCop GBC

    Pod koniec prac nad Hands of Time ( czyli gdzieś tak w okolicach grudnia 2000 roku) Titus poprosił o kolejną grę na GBC. W trybie ekspresowym. Ba, błyskawicznym. Z tego co pamiętam, miało to związek z wymykającą się a uzyskaną od MGM ) licencją na tytuł RoboCop. Inne studia współpracujące z wydawcą pracowały nad wersjami GBA, PS2, XBOX itp ( z kiepskim skutkiem.. ). Wydawcy zależało na wypuszczeniu gry jak najszybciej. Mieliśmy około czterech-pięciu miesięcy na pracę. Ja kończyłem HoT i jednocześnie zająłem się RoboCopem. Do zespołu dołączył Wojciech Wrona ( z doświadczeniem w programowaniu na C64 ). Designem gry i projektowaniem leveli zajął się Paweł Kalinowski ( od dawna związany z Mirage, pracował m.in. nad Mortyrem PC ). Producentem i PM został Lech. Po stronie Titusa produkcją zajmował się Paul Leskowicz. Za grafikę zabrał się Adam a Krzysztof tworzył muzykę. W Rybniku, w moim domu stworzyłem niewielkie biuro, w którym wraz z Wojtkiem pracowaliśmy nad kodem gry i narzędziami.
    Postanowiliśmy użyc podobnych technologii jak w HoT. Duet TileBuddy + własny edytor poziomów spisywał się nieźle. Na bazie MLE powstał więc( RoboEdit ).

    Początkowo gra używała trybu hicolor dla wszystkich statycznych screenów. A było tego sporo: ekran tytułowy, posterunek policji (kilka ekranów), briefingi przed misją, wiadomości TV. Efekt był naprawdę fajny. Niestety, już we wczesnej fazie produkcji Titus zakazał używania hicolor. Grafiki przekonwertowałem przy użyciu GiQ do 4 kolorowych tiles w 8 paletach. Dithering, brak kolorów. Wyglądało to źle. Część screenów Adam narysował od nowa, reszta z braku czasu na poprawki - została. Skąd ta nagła zmiana? Wydawca stwierdził, że hicolor znacznie zwiększa zużycie baterii i Nintendo odrzuci grę. Faktycznie, baterie szybko padały, ale kilka gier (m.in. Alone in The Dark) z powodzeniem korzystało z hicolor.

    Konwersję z trybu hicolor do formatu GBC umożliwiało między innymi narzedzie o nazwie GIQ ( Genetic Image Quantizer ). Był to dosyć prosty konwerter, który bazując na algorytmach genetycznych starał się znaleźć jak najlepsze dopasowanie ustawień grafiki ( palety, kolory, dithering ). Jego minusy to silne obciążenie systemu i czas działania. Kilka dobrych godzin zajmowało mu znalezienie optymalnych ustawień konwersji. Z powodu awarii sprzętu pracowałem na wypożyczonym z Mirage laptopie marki California Access. Z powodu awarii dysku długo jednak u mnie nie zagrzał miejsca. Właśnie .. zagrzał. Laptop to była tylko funkcja uboczna. Tak naprawdę CA to był grzejnik. Miniaturowe słońcem stojące na biurku i ogrzewające całe biuro. Odpalenie zestawu laptop + GIQ (lekko podrasowany w task managerze, priority ustawione na Realtime) na noc okazało się ciekawym doświadczeniem. Komputer - w celu lepszego przepływu powietrza - postawiłem na kilku pustych pudełkach po dyskach Zip ( napędu Zip używałem do tworzenia kopii bezpieczeństwa ). Rano okazało się, że laptop, pudełka i biurko stały się jedną, gorącą bryłą plastiku. Ale grafika wyszła fajna.

    Wracając do RoboCopa. Powstał fajny i ciekawy scenariusz gry, bazujący na powiązaniach przestępców z ratuszem i kontroli wszystkiego przez sztuczną inteligencję (Mind). Rozrysowano lokacje.

    Sam "engine" gry został lekko usprawniony: więcej sprajtów, płynniejszych animacji tła ( więcej klatek ). Niestety nie było czasu na podstawową zmianę - większe, dynamicznie budowane sprajty ( miała do tego służyć integracja z narzędziem SpriteBuddy ). Mechanika była bardzo podobna do HoT - kilkadziesiąt scrollowanych ekranów 256x256. Sama gra miała zupełnie inny, typowo zręcznościowy charakter. Nie było zbierania przedmiotów, dialogów, pojazdów itp. Tylko strzelanka ze sporą liczbą broni do wyboru (zdobywanych / odkrywanych w kolejnych levelach).

    Jednak coś nie do końca poszło tak jak miało. Robocop uznawany jest niestety za jedną z gorszych gier na GBC. Sporo niedoróbek i brak czasu odcisnęły swoje piętno na tej produkcji. Do dziś nie jestem pewien, czy Titus wysłał właściwą, finalną wersję do produkcji, czy poszła beta. Podobnie jak HoT, dostępne były dwie wersje okładek.

    Cała oprawa gry wykonana była w ( podobnie jak i filmy ) cyberpunkowym klimacie. Każda z misji (oprócz ósmej, ostatniej) rozpoczyna się na posterunku policji, gdzie można przeczytać najnowsze wiadomości i komunikaty na terminalu, porozmawiać ze swoją partnerką Lewis lub sprawdzić co nowego w weapon labie przygotowała Lazarus. Zazwyczaj wszystkie powyższe czynności są konieczne, by rozpocząć właściwą misję. Poziomy były mocno zróżnicowane, między innymi: wysypisko, biura, magazyny, platforma wiertnicza. Przeciwnicy RoboCopa to głównie gangsterzy i cyborgi. W grze pojawiają się także postacie, do których nie powinniśmy strzelać: policjanci i cywile. RoboCop automatycznie identyfikuje kto jest kim.







Kody do kolejnych leveli: AGFHGH, UYFVCB, UYGFVJ, BNAJKH, MNJSGG, NBXZHJ, PONBVA, JHBVRP, LKJSHA.
Cheat mode: BACAXL

Rainbow Fish

     Ostatnim zrywem GBC w Mirage był projekt o roboczej nazwie "Rainbow Fish". Gra miała powstać dla kanadyjskiego klienta (możliwe, że był to Teletoon producent kreskówki - nie pamiętam już szczegółów) i bazować na serii animowanej (na podstawie książki dla dzieci) pod tym samym tytułem. Adam narysował trochę grafik ( tło - dno morskie i sprajty - różne stworzenia, animowane bąble powietrza itp ). Kod - ze względu na jzupełnie odmienny ( od pozostałych produkcji ) charakter gry - był pisany od zera. Niestety, projekt został bardzo szybko odwołany. Szkoda - miał to być zestaw fajnych ( zaprojektowanych przez Lecha ) mini gierek dla młodszych graczy, w tym wyścigów, "tańca" w stylu DDR, labiryntów, puzzli itp. Skończyło się na kawałku kodu i grafiki.

Game Boy Advance

     Rainbow Fish to ostatni projekt ( a właściwie to ostatnią próba ) związany z Game Boy Color. Był już 2002 rok i następca GBC - Game Boy Advance zawładnął rynkiem przenośnych konsolek.

     Naturalnym wydawało się przejście na nowszą platformę. Naturlanym - ale nie do końca łatwym zadaniem. Po pierwsze - popyt na oficjalne development kity ( a co za tym idzie - licencję na pisanie ) był ogromny. Na sprzęt Nintendo czekało się w dłuuugiej kolejce. Kolejce, która została w pewnym momencie ukrócona - N doszło do wniosku, że rynek jest już nasycony (a nawet przesycony ) i nie będzie więcej devkitów rozdawało ( oczywiście nie za darmo, koszt to kilka tysięcy $ ). Można było oczywiście dostać devkit od wydawcy i podpiąć się pod niego z licencją, ale posiadanie własnej dawało pełną niezależność. Lech juz wcześniej rozmawiał z Nintendo na temat devkitu. Zamówienie tak naprawdę złożono kilka miesięcy wcześniej. Jednak z różnych wzgledów zostało wstrzymane ( jak nie wiadomo o co chodzi ... ). Po kolejnych rozmowach okazało się, ze jest już, niestety, za późno. No ale nie do końca. Niewiadomo jakich argumentów użył Lech, ale pewnego popołudnia do moich drzwi zapukał kurier Servisco ( ktoś jeszcze pamięta? ) z paczką ze stolicy. W środku TO. Po drobnych zakupach ( przetwornica 220V/110V, karta SCSI ) sprzętu udało się go odpalić i dalej już było tylko lepiej.

     Z devkitami wiąże się również inna historia. Któregoś dnia zadzwonił do mnie lekko zdenerowany Lech pytając czy zamawiałem coś dla firmy za kilka paczek zielonych. Okazało się, żę na cle czekał development kit ProDG. Przypomniałem sobie, że kilka tygodni wcześniej, przeglądając stronę SN Systems (producenta ProDG) zgłosiłem chęc testowania ich narzędzi ( kompilator SNC, biblioteki systemowe ) dla GBA. Testowanie wiązało się jednak ( czego już nie doczytałem ) z wysyłką ( za darmo ... ) devkitu. Po okresie testowym można było go zwrócić, lub wykupić licencję ( albo użyć keygena ... ). Mimo, że był darmowy, urząd celny ( po znalezieniu w przesyłce faktury proforma ) dowalił cło i podatek do zapłacenia. Ostatecznie udało się unikać opłat i pomarańczowo - granatowe pudło długo jeszcze leżało w warszawskim biurze na Obrońców 2c.

     Można było również "poszaleć" z muzyką. GBA to już nie tylko prosta synteza dźwięku, ale i zaawansowane odtwarzanie próbek. Krzysztof stworzył kilka świetnych modułów, które były używane w kolejnych projektach ( a w zasadzie przechodziły z projektu na projekt, ale nie uprzedzajmy faktów ).

     Pierwszym moim zadaniem było stworzenie dobrego narzędzia do edycji gier. Tak powstał AGE - Advanced Game Editor. Pisałem go ( w c++ używając tylko Win Api, bez MFC... z perspektywy czasu był to niestety średnio trafiony pomysł ) i udoskonalałem przez kilka miesięcy. Na bieżąco dodawałem brakujące "ficzery". W efekcie powstał naprawdę mocno rozbudowany kombajn, umożliwiający edycję tiles, metatiles, tilemap, sprajtów, kolizji, zdarzeń, palet kolorów, i wielu, wielu innych kluczowych elementów. W połączeniu z odpowiednim kodem po stronie GBA ( pisanym również w C++ - to już nie dłubanina w assemblerze jak w czasach GBC ) dawał naprawdę spore możliwości. Poniżej trzy zrzuty ekranu z edytora:

Sgt. Cruise

     Pierwszym projektem GBA był Sgt. Cruise. Gra robiona dla wydawcy ( Titus ... ), mająca być młodszym bratem wersji (PC i Xbox, GC) tworzonej prze X-Ray Interactive ( odpowiedzialnych między innymi za Kao The Kangaroo ). Ja pracowałem nad edytorem AGE i - razem z Wojtkiem - nad kodem gry. Adam tworzył grafikę. Możliwości sprzętowe GBA były znacznie większe - nie musiał ograniczać się do 4 kolorowych tiles. Mógł poszaleć z 16 ( a nawet z 256 - w zależności od trybu ) kolorami. Niestety, projekt został zamknięty gdzieś w okolicy 2 grywalnych leveli i całej masy przygotowanej grafiki ( część została użyta w prototypie VShooter - o czym niżej ). Grzebiąc w archiwach, znalazłem głównie mapy leveli, budowane pod AGE. Reszta ( kod, wersje testowe, grafiki postaci ) wciaż czeka na odkurzenie. Gra miała komiksowy, lekko ( ? ) prześmiewczy charakter. W skrócie - opowiadała o przygodach (w klimacie sf) sierżanta Cruisa. Była to typowa strzelanka wzorowana na klasykach z automatów: Commando, Ikari Warriors czy Shock Troopers. W planach było strzelanie, bieganie, latanie i jeżdżenie czołgiem. Część grafiki wykonał również Sławomir Bubel, który w międzyczasie rozpoczął współpracę z Mirage.

Space Marines

    Sergeant Cruise płynnie wyewoluował w Space Marines - autorski projekt Mirage o zbliżonej tematyce. Rozgrywka miała zostać ulepszona. Fabuła rozbudowana. Dwie postacie do wyboru ( male / female ), trzecia ( kot Minhty ), sterowana przez grę miała wspierać gracza i pomagać w kluczowych momentach. Lech przygotował cały koncept gry, dokumentację i design pierwszych leveli. Adam zaczął od narysowania świetnej grafiki koncepcyjnej i prace ruszyły.

    Zmienił się charakter gry (zniknęły przejaskrawienia i karykatury) i styl grafiki. Zwrot o 180 stopni - wszystkie materiały stworzone do Sgt. Cruisa poszły "do piachu". Punktem odniesienia miały być prace tworzone przez Dana Malone. Adam stworzył całą masę świetnie prezentujących się elementów tła, sprajtów, gadżetów i animacji. 2D engine gry był już mocno rozbudowany. Dodałem kilka efektów pogodowych (deszcz, mgłę), "lightspot" w podziemiach. Zrezygnowaliśmy z poruszania się pojazadami i latania. Każdy włożył naprawdę dużo pracy w projekt. I na tym się w zasadzie skończyło... (patrz Rambo III).

    W międzyczasie do rybnickiego teamu dołączył ( z polecenia Wojtka ) Jacek Cichopek. Zajmował się głównie żmudnym ( baaardzo ) tworzeniem i edycją leveli. W miarę zapotrzebowania dodawałem nowe funkcje do edytora AGE (m.in. kilka "pulpitów" między którymi można było kopiować większe elementy map), ale i tak leveldesign / building to była benedyktyńska praca.

     Było lato 2002 roku. Lech wybierał się na targi ECTS do Londynu. Przygotowaliśmy więc wersję specjalną Space Marines z jednym, grywalnym poziomem:



VS

    VS ( Vertical Shooter ) był grą - przynentą przeznaczoną na targi ECTS. Część grafiki ( tła ) pochodziła z ubitego projektu Sergeant Cruise. Reszta ( wybuchy, fake status, obiekty ) zrobił "na szybko" Adam. Zaprogramowanie prostego shootera z pionowym scrollem nie zajęło wiele czasu. Z Jackiem poskładaliśmy jeden poziom w A.G.E. Ogólny zamysł był taki, by pokazać możliwości engine i znaleźć potencjalnego wydawcę gry. W razie niepowodzenia prace miały być kontynuowane, ale z mniejszym priorytetem, niż inne projekty.

Haunted Manor ( tytuł roboczy : Willy’s Mansion)

    Nad tym tytułem ( jeszcze jako Willy's Mansion ) początkowo pracowałem sam ( używając tymczasowej grafiki m.in. z Bombermana i SC ). W rezultacie powstało bardzo proste demo techniczne. Następnie projektem porządnie zajął się się osobny team, złożony z Janusza Dąbrowskiego (znanego z m.in. z 'Hansa Klossa' na C64) i Sławomira Bubla. Fabuła gry była prosta: dostajemy stary, nawiedzony dom w spadku po krewnym. Musimy pozbyć się wszystkich duchów i straszydeł. Całość miała składać się z 75 poziomów, podzielonych na 5 stref: ogród, dom, podziemia, cmentarz, strych. Mechanika rozgrywki zbliżona była do klasycznej, znanej z automatów gry Pengo. W skrócie: popychając "bloki" zabijamy przeciwników. Janusz zrobił działające, grywalne demo "ogrodu" z fajną grafiką Sławomira. Żywopłoty przesuwały się i łączyły. Można było zbierać klucze, zabijać wilkołaki i duchy. Głowny bohater w cylindrze lekko przypominał tego z Heartland. Niestety, z tego co pamiętam, powstała tylko pierwsza strefa.

Rambo III

     Podczas prac nad Space Marines odezwał się Titus i zaproponował zrobienie gry na licencji filmu Rambo III. Nastąpiła kolejna "dobra zmiana" i SM poszło w odstawkę. Kod można było wykorzystać ponownie, ale grafika w klimacie sf przestała w większości pasować. Po lewej szkic poziomu z design doca; po prawej - level zbudowany przez Jacka.


    Sławomir Bubel przygotował ekran tytułowy, Adam Karol zaczął tworzyć nową grafikę. Od samochodów, helikopterów, budynki, umocnienia, podziemne magazyny i pomieszczenia mieszkalne po skomplikowane sprajty (Rambo, Rambo z łukiem, Rambo na koniu, Rambo na koniu z łukiem... ;) itd) Krzysztof Wierzynkiewicz zrobił muzykę. Powstało grywalne demo (z jednym poziomem)....

    I to już był koniec. Na tym niestety zakończyła się współpraca z Mirage. Wszystkie projekty "poszły w karbonit".






© 2018 Tomasz Słanina. Zastrzegam sobie wszelkie prawa do publikacji. Kopiowanie i używanie informacji/materiałów tutaj zamieszczonych bez zgody autora jest zabronione.