Tutorial-Jak stworzyć Pixelmovement w RM 2k3?
Wstęp:W przeciwieństwie do innych RM, w 2k3 nie możemy wgrać skryptu, który stworzy pixelmovement za nas. Stworzyłem ten toturial dla osób, które lubią pokombinować w wiekowym już 2k3 i stworzyć coś niecodziennego. Zdaje sobie z tego sprawę, że niektórzy będą narzekać na obrazek wyświetlany co 0.1 sekundy, ale w sumie i tak nie ma innego sposobu, aby to objeść, gdyż postać się animuje.
Tutorial przeznaczony raczej dla obeznanych użytkowników.
I)
Potrzebujemy grafik naszej postaci, ja do tego celu wziąłem postać z RMXP. Dzięki zastosowaniu pixelmovementu nie jesteśmy ograniczeni do 16x32.
II) Zaczynamy od wyświetlenia na środku ekranu obrazku naszej postaci.
Jako zmienną X ustawiamy pozycję startową bohatera, tak samo Y. Przełącznik został użyty po to, aby ta strona zdarzenia nie wykonywała się w nieskończoność. Następnie tworzymy drugą stronę zdarzenia ustawioną na naciśnięcie przycisku, z warunkiem startu SWITCHA 0001.
Tworzymy na mapie drugie zdarzenie.
W tym zdarzeniu operujemy klawiaturą. Niestety RM2k3 może odczytać jedynie jedną strzałkę na raz(chyba że najpierw wciśniemy górny, albo dolny klawisz). Ja w tym tutorialu odpuściłem sobie ruch w 8 kierunkach (stwarza to problem 2x szybszego poruszania się postaci na ukos).
->Ustalamy zmienną klawiatura na 0.
->Odczytujemy przyciski z klawiatury zmienną klawiatura.
->Jeżeli zmienna klawiatura == 2 (został wciśnięty przycisk lewo), to odejmujemy od zmiennej X 1 i ustawiamy Facing (kierunek obrotu twarzy postaci) na 4. (może być to dowolna liczba jaka wam odpowiada, ja po prostu posłużyłem się oznaczeniami klawiatury numerycznej).
Analogicznie robimy do reszty przycisków wstawiając je w ELSE HANDLER.
Na koniec poruszamy obrazek 1 poprzez zmienne X i Y. (bez opcji czekania na zakończenie).
III)
Teraz zajmiemy się animacją bohatera. Nie możemy zrobić tego klasycznie poprzez wait (zbuguje to animacje, kiedy zmienimy dynamicznie kierunek animacja może wyświetlać się przez ułamek sekundy w złą stronę). Więc stosujemy do tego to:
Przełącznikiem TICK zajmiemy się później. Na razie ważne, żeby tu po prostu był.
->Czekamy 0,1 sec.
->Zmieniamy zmienną DT o +1.
->Jeżeli zmienna DT==12 to ustawiamy ją na 0.
Maksymalną wartość zmiennej DT możecie ustalić na inną liczbę, u mnie po prostu animacja może być maksymalnie 12 klatkowa.
IV)
Teraz czas na wyświetlanie.
Ten punkt powtarzamy do każdego możliwego Facingu (2,4,6,8).
->Sprawdzamy czy Facing == 2.
->Jeżeli zmienna klawiatura jest różna od 0 to:
->Zmieniamy SWITCHA TICK na ON. (to on odpowiada za animacje).
->Jeżeli zmienna DT jest równa 3 lub mniejsza:
->Wyświetl obrazek bohatera skierowanego w dół względem zmiennych X i Y.
ELSE
->Jeżeli zmienna DT jest równa 6 lub mniejsza:
->Wyświetl obrazek nr 2 bohatera skierowanego w dół względem zmiennych X i Y.
Itd.
Pozwala nam to na utworzenia animacji chodzenia o dowolnej liczbie klatek.
Jeżeli zmienna klawiatura będzie równa 0 to zmieniamy przełącznik TICK na OFF i wyświetlamy klasyczny obrazek bohatera stojącego twarzą w dół.
V)
System kolizji. Niestety RM 2k3 nie pozwala na wczytanie wysokości i szerokości obrazka. Musimy więc obejść się bez tego. Ograniczy to nas do tego że będziemy musieli użyć standardowego systemu blokowania w tilesetach wbudowanego w RM.
Zmieniamy w Database terrain tilesetów, które mają blokować bohatera na 2.
Następnie wchodzimy w Common event.
Tutaj tworzymy zdarzenie Blokowanie triggerowane jako równoległe zdarzenie. Deklarujemy nowe zmienne: Pole X, Modulo, Pole Y, Blokowanie.
Potem robimy tak:
->Ustawiamy zmienną Pole X na wartość zmiennej X.
->Zmienną modulo ustawiamy na taką samą wartość jak zmienna Pole X.
->Ustawiamy zmienną modulo na mod 16.
->Odejmujemy od zmiennej Pole X zmienną Modulo.
->Dzielimy zmienną Polę X przez 16.
To samo robimy ze zmienną Pole Y.
->Ustawiamy Store Terrain ID przez zmienne Pole X i Pole Y, zapisujemy ID terrainu do zmiennej Blokowanie.
->Jeżeli zmienna Blokowanie==2 to:
->Jeżeli zmienna Facing==2 to:
->Odejmujemy od zmiennej Y 1.
->Jeżeli zmienna Blokowanie==8 to:
->Jeżeli zmienna Facing==2 to:
->Dodajemy do zmiennej Y 1.
->Jeżeli zmienna Blokowanie==4to:
->Jeżeli zmienna Facing==2 to:
->Dodajemy do zmiennej X 1.
->Jeżeli zmienna Blokowanie==6 to:
->Jeżeli zmienna Facing==2 to:
->Odejmujemy od zmiennej X 1.
W tym momencie blokowanie już działa. Ale nie stworzyliśmy jeszcze HITBOXU naszej postaci! Jak już pisałem RM nie pozwala na pobranie wysokości i szerokości obrazka, więc musimy wpisać dane ręcznie. Uznajmy że Hitbox naszej postaci będzie tworzyć jej dolna część o wielkości 24x32. Blokowanie sprawdza naszą środkową koordynatę X i Y. Więc zabieramy się za hitboxa, który będzie sprawdzać aż 4 koordynanty! Skopiowałem poprzedni kod 4 razy, raz robiąc +16 do X, za drugim razem -16 do X, za trzecim -16 do X i +24 do Y, a za czwartym +16 do X i +24 do Y (zobacz w demie).
Zauważyłem w tym momencie pewną zależność, przez wielkość mojej postaci potrzebuje ona dwukartkowej przestrzeni, aby przejść w poziomie i trzykartkowej przestrzeni, aby przejść w pionie. Na szczęście dla postaci o standardowej postaci o hitboxie 16x16 takie rzeczy nie mają miejsca :P.
Przez to zdecydowałem się zmienić wszystkie wartości do X z +/-16 do +/-8. Przez to postać nie ignoruje już jednokartkowych przeszkód i wymaga jedynie dwóch kratek w poziomie aby przejść.
Mowa końcowa:
To koniec tego tutoriala. Jeśli znajdą się zainteresowani, to może zrobię następną część, w której będzie jak zrobić scrolling i inne duperele :>
Demo:
https://www.mediafire.com/?533hcll1eggo2mg