Tygrys mnie zachęcił, żeby opisać - więc publikuję kolejne kroki jakie dzieją się z portem/modem gry Oregon Trail, którą przenoszę na ZXa, z ogromną pomocą programistyczną Tygrysa.
Podstawowe założenia: grafika czb z wersji z Macintosha, mechanizmy podobnie - dużo bardziej rozbudowane niż wersja pierwotna w BASICu.
Dev narzędzia - z80dk, co daje też szansę na sportowanie tego na CPC i ZX81 (z ZXPandem rzecz jasna). Robiłem też przymiarkę do cc65, ale to daleeeeeeki etap
Pozostałe: Photoshop, ZX Painbrush na Wine (robię wszystko na MacOS) i pewnie parę innych rzeczy - postaram się wspominać co, może się komuś przyda.
Żeby była jasność NIGDY nic nie napisałem w stricte C. Moje ostatnie programowanie to skrypty w Apple Script, aczkolwiek jak się zastanowić to w użyciu też był AppleScriptObjC - ale to doświadczenie totalnego amatora i nooba - jak to mówią.
Dlaczego ta gra? Bardzo ją lubię (ale w wersji na Macintosha, sterowanie w trakcie "polowania" na Apple II mnie odrzuca). Mam ją w iluś wersjach, łącznie z kolekcjonerkami i małą "konsolką" jaka wyszła rok temu. Jeżeli ktoś obserwuje mój profil/stronę na fejsie, to pewnie już pewne "zwiastuny" notatkowe widział.
Dlaczego w ogóle gra? To coś z mojej tzw. kupki wstydu. Miałem ileś takich projektów rozgrzebanych w latach 80tych jako dzieciak. Niby skończone, ale guzik z tego było na 100% zapięte. Zwykle gry i programy w BASICu. Teraz chcę to trochę nadrobić, tylko pozostał dylemat platformowy - gra na ZXa to mój hołd dla komputera którego nie miałem mając 12lat a który chciałem mieć. Całość projektu mam tak przemyślaną, że wydaje mi się, że będzie możliwe zrobienie portów na inne platformy - dla sportu i poznania tej opcji. Zawsze lubiłem przygodówki - co prawda myślałem, że zacznę od gry przygodowo-tekstowej, ale z kolei ten wariant sobie trochę skomplikowałem na studiach pracując przy "algorytmach słownikowych" (analiza słowotwórcza etc.) - więc nie mogłem po prostu wziąść PAW i napisać prostej gry tekstowej. Do tego wrócę w osobnym wątku
Czyli OREGON TRAIL - gra decyzyjna, coś tam kupujemy, zużywają się nam zasoby (jedzenie, amunicja etc.), losowo (ale i zgodnie z logiką) napadają nas bandyci, indianie, jak nie jemy to chorujemy, można złamać nogę, zgubić się, trzeba zdobywać pożywienie i... można umrzeć. Dodatkowym motywatorem jest czas, podróż nie może trwać zbyt długo - na razie nie odkryję Wam wszystkiego, tym bardziej, że dodaję pewne zmienne czynniki.
Dla mnie ta gra jest mockupem pisania w C, używania z88dk. Jak skończę tą grę to siadam z Tygrysem do drugiego projektu, ale to osobny temat.
Czemu ma posłużyć ten wątek - to finalnie będzie albo jakiś przykład, że można pisać sobie gry na ZX Spectrum, albo jak nie należy tego robić
Jak wygląda projekt - z brutalną uczciwością:
1. Zrobiłem analizę już istniejących wersji gry. Generalnie... zagrałem we wszystkie dostępne porty. Od crapów na Atari w BASICu, po wersję BASICową na ZX81, port na DSa i Wii etc.
2. zrobiłem skrukturę i algorytm na cyfrowym papierze - pętle zależności etc. Taki mindmapping - zresztą de facto użyłem do tego apki mindmappingowej.
3. Postanowiłem co chcę zmienić i co jest dla mnie istotne w tej grze. Np. cały motyw zręcznościowy - polowania oraz motyw spływu tratwą na koniec - dla mnie na ten element jest pomijalny. To będzie wynikać z umiejętności/predyspozycji postaci oraz podjętych decyzji. Na Macintoshu celowanie myszką ma sens. To samo na Apple II joystickiem jest tragiczne. Po prostu - traper będzie polował lepiej niż bankier i lekarz, o nauczycielu nie wspominam
4. Tygrys zlitował się i napisał mi procki do wczytywania fragmentów ekranu - grafika zajmuje 2/3 ekranu, ale żeby zoptymalizować część rzeczy konieczne będzie operowanie fragmentami ekranu. Generalnie - bez motywacji Tygrysa na tym etapie pewnie bym się poddał.
5. Przygotowałem grafiki, sprawdziłem ich wczytywanie. Testowo sprawdziłem ekran tytułowy i wczytywanie części ekranu procką Tygrysa - duża oszczędność pamięci. Alternatywą była tablica ze współrzędnymi do czegoś w rodzaju plot/draw, niestety w konwencji takiej grafiki i jej szczegółowości się to nie sprawdza - zrobiłem test na jednym obrazku i wyszło prawie tyle co cały ekran ZXa z atrybutami czyli masakra, pewnie można zoptymalizować takie generowanie wektorowe - ale potem jest jeden feler - rysowanie tego trwa. Procka Tygrysa i zmiana grafiki jest w zasadzie niezauważalna czasowo.
6. Grafiki zajmują za dużo, być może trzeba będzie kompresować albo zrzucić je na doczytywanie. To drugie oznacza, że będzie to chodzić na czymś pozwalającym na więcej niż RAM 128k. Dandanator? DivMMC? dyskietka? Czyli pierwszy problem sprzętowy pt. pamięć.
7. mockup zmiennych w trakcie testowania. Czyli cała gra bez grafiki za to z wyświetlaniem wszystkich używanych zmiennych. Jak zwykle coś nie działa i muszę to ogarnąć - zachciało się zrobić wersję rozszerzoną - tylko jak znam życie jak bym zrobił konwersję tej pierwotnej z BASICa to tak by zostało, a chciałem coś od siebie dodać i zrobić "ciekawszą" wersję, pod względem decyzyjnym.
8. zauważyłem, że zamiast wyliczać krzywą prawdopodobieństwa czegoś mogę zrobić tablicę z wartościami, zajmuje... chyba z 10 razy mniej miejsca, aczkolwiek to jest powiedzmy 200-300 bajtów vs 12 bajtów tablicy. O prędkości nie wspominam, bo pomijalna - sprity tu nie latają.
To jest moment w którym jestem. Testuję mockup logiki. Czyli mam nadzieję nastąpi kontynuacja, a jak ktoś ma pytania to można śmiało pytać.