@mailman, post #1

Dzięki za słowa uznania. Dostępna jest również Insidia (ADF) z okrojoną muzyką w 16 kolorach (1MB Chip + 1.5MB Fast). Poniżej kolejny projekt stworzony w Backbone:

Jak ktoś ma jakąś fajną muzyczkę do gry to chętnie dołączę zanim wrzucę grę na Aminet.
Tutaj można ją pobrać.

• Odpowiedz

Pograłem na razie w wersję flashowa i jest całkiem klimatycznie.

Zaraz sprawdzam wersje pod Ami

• Odpowiedz

dwie wersje gry: przeznaczona dla Amig wyposażonych w 1 MB pamięci Chip i 1.5 MB pamięci Fast (ośmiokolorowa), oraz 2 MB pamięci Chip i 2 MB pamięci Fast (szesnastokolorowa)

Jakie wymagania miałaby wersja trzydziestodwukolorowa? 4MB Chipu i 2,5MB Fastu?

• Odpowiedz

@PopoCop, post #4

16Mb Chip ... oj przydaloby sie w Amidze przydalo

• Odpowiedz

@selur, post #5

• Odpowiedz

@mikecios, post #6

• Odpowiedz

@Gżegżółka, post #7

"Jakie wymagania miałaby wersja trzydziestodwukolorowa? 4MB Chipu i 2,5MB Fastu?"
Wersja 16 kolorowa zawiera oryginalną ścieżkę dźwiękową a sam mod waży 1.3MB. Jak wiadomo mody są odtwarzane z Chip RAMu więc na resztę gry zostaje niecałe 700KB Chip RAM. Jeśli ktoś podmieni ten duży moduł "LevelMusic_insidia.mod" na inny to wersja 16 kolorowa zadziała również na 1MB Chip, co uczyniłem z wersją ADF. Jako, że nie jestem muzykiem, to przekonwertowałem całą ścieżkę dźwiękową na 8SVX 5512 Hz (mono) i pociąłem ją na kawałki by następnie ją połączyć w jeden moduł na Protrakerze.

"Miejmy nadzieje że nie jest to wersja ostateczna i gra zostanie jeszcze trochę poprawiona"
A co mógłbym w tej grze jeszcze poprawić biorąc pod uwagę ograniczenia Backbone?

Na jednej stronie internetowej, ktoś nie był zadowolony, że nie działa parę rzeczy z oryginalnej gry jak:
po wciśnięciu klawisza T- teleport, M- mapa, po zebraniu przedmiotów postać wyżej skacze czy biega po ścianach.
Takich opcji to nie oferuje 20 letni Backbone jak również RedPill.

Zamiast podwójnego skoku dodałem w wielu miejscach linę aby gracz nie utknął na jakiejkolwiek planszy. Trzeba mieć na uwadze to, że cała gra jest jedną wielką mapą (220x150 bloków!) z ogromną liczbą obiektów. Czasami podczas grania postać gracza jest zamrożona na "kilkanaście" sekund (nawet pod WinUAE).

Backbone ma wiele błędów, nawet prosta rzecz, jak zmiana domyślnej czcionki Topaz na inną (np.Tny) może spowodować wyciek pamięci (1 MB/min), więc zostawiłem czcionkę topaz na górnym panelu. Nawet punkty zdobyte podczas gry nie są resetowane po śmierci gracza. Jedynym rozwiązaniem po stracie wszystkich żyć było dodanie drugiego menu z wyjściem do WB.

Zamiast liter: J (skok), D (podwójny skok), S (szybkość), W (skok na ścianę) mogłem tylko dodać dodatkowe życia (L) dla początkujących.

Oryginalna gra została zaprojektowana do rozgrywki na statycznym ekranie, niestety Backbone oferuje tylko przewijany ekran. Mamy dwie możliwości:
- "Slide Vertical Scrolling" (wyświetla 2 linie bloków pod graczem)
- "Chunky Vertical Scrolling" (wyświetla 3 linie bloków pod graczem)
Dlaczego to takie ważne? Ponieważ gracz musi wiedzieć, gdzie spadnie przed oddaniem skoku.



Oryginalna gra jest w 640x480 i ma zmienną paletę kolorów na każdym z ekranów (patrz zdjęcie).
Wszystkie 3 tła nie są zbudowane z "tilesów" a są zwykłymi przezroczystymi obrazami 640x480, które używają tego samego wzoru.

Backbone ma ograniczoną liczbę "tilesów", więc musiałem stworzyć zapętlającą się teksturę zamiast pierwszego i drugiego planu. Stworzyłem też własny zestaw bloków ułatwiających przenoszenie ekranów.



Backbone ma wiele ograniczeń takich jak:
- brak wsparcia dla chipsetu AGA a gry w 32 kolorach działają bardzo wolno
- maksymalnie 10 animowanych "tilesów" na ekranie
- maksymalnie 60 obiektów (przedmiotów, wrogów) na poziom
Jeśli użyjemy wszystkich 60 obiektów na poziom, nasi wrogowie nie będą mogli do nas strzelać (brak wolnych obiektów). Musimy wtedy zebrać jakiś obiekt (życie, energię, przedmiot) i zwolnić jedną przestrzeń.

W oryginalnej grze Insidia jest ponad 240 animowanych wiatraczków.
Jeśli chcielibyśmy użyć ich jako obiektów w grze to możemy użyć tylko 60. A co z resztą?
Jeśli przekształcimy je na "animowane tilesy" to możemy użyć dowolniej ich liczby na ekranie, ale tylko 10 może być animowanych. Kolejny problem z "animowanymi tilesami" jest taki, że mogą mieć maksymalnie 4 klatki animacji, a oryginalny wiatraczek ma ich 9...

Wiele dodatkowych opcji w Backbone nie działa poprawnie, jak "automatyczne przewijanie ekranu". Jeśli ustawimy na przykład "Prawo, prędkość 2 piksele na klatkę" a w trakcie gry gracz będzie poruszać się szybciej niż "automatyczne przewijanie" to ekran nie będzie przewijany płynnie i zacznie skakać. Jeśli dodamy opcję "Push Player Also?" to automatycznie przestaje działać pozioma kolizja z blokami. Pomimo tych wszystkich ograniczeń jestem zadowolony że udało mi się dokończyć projekt.

Ogólnie to przydałby się nowy silnik do tworzenia gier jak GDevelop lub użyć do tego celu Hollywooda.

• Odpowiedz

@Leon, post #8

Dzięki za pracę, eksperymenty, etc.

• Odpowiedz

@Leon, post #8

Bardzo ciekawe wyjaśnienie- dzięki

• Odpowiedz

@BULI, post #11

Backbone ma oczywiście więcej ograniczeń, zacznijmy od pierwszego z góry... panelu. Aby dodać w grze kolorowy panel z punktacją musimy go najpierw stworzyć na programie graficznym a następnie go wyciąć i zapisać jako "brush". Jeśli ten będzie miał mniej niż 40 pikseli w pionie to przy próbie pozycjonowania czcionki "Position text" (Edit Panel) do liczników energii/życia itd. wyskoczy komunikat o braku możliwości otwarcia okna "Unable to open window" a program wraz z naszym projektem zostanie zamknięty. Aby używać węższych paneli musimy najpierw dodać panel np. 320x40 ustawić dla niego czcionki do liczników, zapisać projekt a następnie wyciąć ponownie brusha na PPaincie ale węższego np. 320x16 i zapisać pod tą samą nazwą. Autor nie przewidział, że ktoś będzie chciał używać takich paneli.

Większość gier stworzona za pomocą Backbone (Elfie the Unicorn, Halloween Nightmare, Marco Gregorio, Max Knight, Reality, Reality itd.) używa "grubych" paneli a co za tym idzie gracz ma mniejsze pole widzenia. Ja zaś preferuje aby panel zajmował jak najmniej miejsca.

Ciekawostka, panel nie musi używać tych samych kolorów co gra. Przykładowo jeśli gra jest w 8 kolorach to panel może być nawet w 32. Czyli kompilując grę w 8 kolorach tak naprawdę będzie miała w tym przypadku 40. Pierwszy kolor palety odpowiada za kolor tła dla czcionki użytej w panelu, zaś kolor czcionki i typ/rozmiar można zmienić w ustawieniach.



Zamiast używania czcionek w panelu można zbudować panel z obiektów (wcześniej wyciętych brushy zapisanych jako 1 obiekt). Stosuje się to głównie dla energii mającej maksymalnie 5 stanów postępu. Ja z tej opcji nie mogłem skorzystać w moim przypadku (9 x toolbox).

Kolejną bolączką jest brak możliwości ustawienia prędkości odtwarzania animacji dla obiektu. Jeśli postać ma 4 klatki animacji to będzie chodzić za szybko i trzeba podczas wycinania klatek każdą klatkę skopiować 2 lub nawet 3 razy aby chodziła wolniej podczas gry. Niektóre postacie po wycięciu nie bedą prawidłowo animowane w grze. Szczególnie jak np. postać rusza głową do przodu i do tyłu. Domyślnie Backbone wycentruje te wszystkie klatki i postać będzie zachowywać się jakby jeździła po lodzie. Widać to dobrze na poniższej lewej animacji.



Oczywiście Backbone oferuje ustawienie pozycjonowania dla każdej klatki animacji ale nie jest to łatwe do zrobienia szczególnie jeśli postać jest ciemna i nie widać jej za dobrze na czarnym tle (przykład powyżej z białym celownikiem). Do tego trzeba wiedzieć, która klatka jest źle ustawiona, a jak już to wiemy, to o ile pikseli musimy przesunąć punkt ciężkości w pionie i poziomie dla danej klatki. Podsumowując ciężko to ustawia się myszką szczególnie, że nie ma przy tym opcji powiększenia czy współrzędnych. Przypomina to trochę nawlekanie nitki na igłę z małym oczkiem. Co gorsza jeśli daną klatkę skopiowaliśmy 3 razy to tę operację musimy powtórzyć 3 razy. Łatwo można przy tym dostać oczopląsu.

A co jeśli obiekt ma strzelać innym obiektem? Tutaj pojawią się kolejne problemy, których autor programu znowu nie przewidział. Najpierw tworzymy z naszego obiektu "pocisk" (Object type: Weapon Shot) i wybieramy czy ma strzelać w dowolnym kierunku czy prawo/lewo. Szkoda, że nie pomyślał o dodaniu opcji strzelanie góra/dół... Mamy tutaj dodatkowo parę ważnych parametrów jak prędkość pocisku, jego zasięg w pikselach, czy odstęp pomiędzy kolejnymi wystrzałami (25=1 sekunda). Później dla innego obiektu "strzelającego działa" ustawiamy (Object type: Patrolling Enemy) ale dla "Move/Fall Speed" zostawiamy prędkość 0 dzięki czemu nasze działko pozostanie tam gdzie je umieściliśmy, następnie przypisujemy broń (Weapon->"pocisk") jaką wcześniej utworzyliśmy.

Wszystko fajnie ale tylko w teorii bo w praktyce nie jest już za ciekawie. Po umieszczeniu działka na planszy wybieramy czy ma być obrócone w prawo czy w lewo i w tę stronę będzie strzelać w jaką ustawimy (zaś dla parametru "Chasing Enemy" będzie się obracało w dwie strony przy "zerowych" ustawieniach). Problemy są inne, jak wiadomo kolizja nie działa dobrze w Backbone i dotyczy to nie tylko podczas skakania po platformach ale również podczas strzelania. Pomimo włączonej opcji "Cannot Travel through Walls" pociski lecące pod skosem są w stanie przelecieć przez blok i trafić gracza. Raz trafieni przez pocisk tracimy życie innym razem nie, czysta loteria. Jedynym ratunkiem jest ustawienie dla działka w opcji "Weapon" innej wartości dla "Shot Height", trochę to pomaga.

Drugi błąd jaki zauważyłem pojawia się czasem podczas zmiany typu strzelania. Jeśli ustawimy "strzelanie lewo-prawo" to pociski normalnie lecą zaś jak zmienimy na "strzelanie we wszystkich kierunkach" to zamiast pocisku leci pocisk wyglądający jak nasze działko. Ten błąd można szybko wyeliminować przez ponowne utworzenie obiektu pocisk ale zamiast jednej klatki animacji trzeba dać minimum dwie.

Autor też nie przewidział, że ktoś może użyć tej samej muzyki w różnych miejscach gry. Czyli jak ustawimy tę samą piosenkę dla intro, menu i np. 1 poziomu to zostanie ona skopiowana 3 razy zabierając nam cenne miejsce na dyskietce bo w przypadku HD nie ma to większego znaczenia.

• Odpowiedz

@Leon, post #12

• Odpowiedz

@Leon, post #12

• Odpowiedz

@Leon, post #12

• Odpowiedz

@Norbert, post #15

Tylko każdy z tych modułów (Scene1/4/11.mod) występuje wiele razy w pliku uruchamialnym z grą i trzeba je wszystkie zamienić. Gorzej jest z muzyką dla poziomów bo dodatkowo przed nazwą pliku dopisywana jest fraza "LevelMusic_". Nie wiem czy wogóle jest możliwe ustawienie jednego modułu dla menu i 1 poziomu. Poza tym ostatni raz edytowałem takie pliki dobre ćwierć wieku temu. Teraz już nawet nie pamiętam jak zmienić nazwę z Scene1 na Scene11 tak aby plik ważył 1 bajt więcej.

Czy plik skompilowany w Backbone oraz później spakowany Impolderem4 gdzie zajmuje 2x mniej miejsca można tak samo edytować i nie wpłynie na stabilność itd. Ciekawe za to są zapiski w pliku uruchamialnym z grą jak "Copper not disabled", "Scrolling zone not defined" i inne. Ciekawe kiedy te komunikaty miałyby się pojawiać? Bo ja z nimi się nie spotkałem w trakcie używania BB.

Czasem tak sobie myślę, że BB może mieć ukryte parę funkcji i można je aktywować przez edycję jednego z plików. Przykładowo wyłączyć przewijanie ekranu poprzez zmianę numerka z 1 na 0 gdzie "Slide Vertical Scrolling" to 1 a "Chunky Vertical Scrolling" to 2. Czy dodanie określonego czasu dla poziomu. Poniżej obrazek jak wygląda zapis w pliku Prefs.

Ktoś się może zastanawiać dlaczego Insidia powstała w 2 wersjach: 8 i 16 kolorowej a wersji 32 kolorowej brak. A no dlatego, że wersja 32 kolorowa o wiele lepiej by nie wyglądała na chipsecie ECS ze względu na ograniczoną paletę 4096 kolorów. Niby paleta 4096 to dużo ale w praktyce nie zawsze wystarcza. Poniżej zamieszczam obrazek jak prezentowałaby się gra w 32 kolorach na AGA i ECS.

Odnośnie gier jakie chciałbym w przyszłości przygotować i które chodzą mi po głowie to:
Kroma2, która pewnie nie ukazała się jeszcze na żadną platformę a sam autor wrzuca czasem zrzuty ekranu na różnych stronach internetowych. Poniżej mój zrzut jak mogłaby wylądać w 32 kolorach (320x240).

Kolejną jest Pixel Quest, akcja toczy się na statycznym ekranie, tło jest jednolite na wszystkich poziomach. Gracz dysponuje podwójnym skokiem, szybszym bieganiem oraz chodzeniem po ścianach. Tutaj grafikę trzeba przerysować z 640x480 do 320x240 bo po przeskalowaniu nie wygląda za dobrze. Przymiarkę mógłbym zrobić w Backbone aby sprawdzić czy tilesy dobrze pasują.

• Odpowiedz

@Leon, post #16

• Odpowiedz

@mailman, post #18

• Odpowiedz

@Leon, post #19

Nie grałem jeszcze w Insidia, ale już teraz serdecznie Ci gratuluję porządnego podejścia do swojej pracy. Zdobyłeś bezcenne doświadczenie, poświęcając czas i pracę na zapoznanie się z tymi pakietami, ich możliwościami i ograniczeniami. Tak samo porządnie podchodziłeś również do edycji poziomów do gry Gloom, dzięki czemu powstało kilka rzetelnych artykułów, które zamieściłeś na stronach portalu eXec. Wyciągasz wnioski i nabierasz doświadczenia!

Podziwiam Twoje zaangażowanie, trud i wspaniałe efekty i nie ukrywam, że jesteś dla mnie autorytetem na tym polu.

Życzę Ci dalszej owocnej pracy przy tworzeniu gier na Amigę i wykorzystaniu dostępnych pakietów! Chciałbym byś dzielił się dalej doświadczeniami, najlepiej pisując artykuły jak dotychczas. Myślę, że redaktorzy PPA również z przyjemnością opublikowali by je na łamach ich portalu. Bo są to artykuły pisane przez człowieka, który po prostu porządnie podchodzi do tematu.

• Odpowiedz

@Hexmage960, post #20

• Odpowiedz

Wpierw odpaliłem flashowy oryginał i zaraz po tym z wielkim zaciekawieniem wersję Amigową. I tak się zastanawiam jak żeś w tym cholernym backbone rozwiązał problem długiego wczytywania ekranów po przejściu z jednego w drugi... Miałem nadzieję że jakimś cudem znalazłeś na to receptę. Szybko jednak sprawa się wyjaśniła bo widzę że zdecydowałeś się na scrolla :), który w.g. mnie w bb jest lekko mówiąc nie najlepszy. Tak czy inaczej piąteczka i gratulacje bo gra wygląda bardzo ładnie.

• Odpowiedz

@Leon, post #2

• Odpowiedz

@jubi, post #23

• Odpowiedz

@Leon, post #16

• Odpowiedz