Analizy

 
 
 
2k3 vs RMXP - porównanie programów
(Sabikku)

Artykuł powstał jako kontra i sprostowanie do artykułu X-Techa z trzeciego numeru Gońca. Zabiorę się za przedstawienie różnic makerów 2k3 i xp. Chyba nie ma potrzeby konfrontowania innych, mniej popularnych, wersji. Postaram się porównać programy 'kropka w kropkę' - jeno bez zbędnego owijania w bawełnę. Miłego czytania :).

Pierwsze wrażenia

Na razie wcielę się w przeciętnego gracza 2010 roku i 'zrecenzuję' oba programy. Ma to za zadanie (między innymi) wyjaśnić niektórym ludziom, dlaczego nowy użytkownik sięga po RMXP.

Zacznijmy od RPG Makera 2k3. Wchodzę w folder gry stworzonej w tym programie. Cholera, pełno tu folderów i plików map, utrudniających odszukanie .exeka gry. Odpalam. To, co widzę wyzwala we mnie mieszane uczucia. Rozpikselowana grafika na pełnym ekranie nieco razi (nie mamy lat 80' i ekranów 320x240). Wprawdzie działa bardzo płynnie, ale trudno wciągnąć się w taką kratkownicę.
Postanawiam sprawdzić, jak prezentuje się sam program. Prosty interfejs, poza wyborem pojedynczych komend zdarzenia (wszystkiego trzeba 'szukać wzrokiem') i mappingiem, który ciągle mnie ogranicza. No nic, przygoda z tym makerem skończona.
Sprawdzę więc XP. Na początek pierwsza lepsza gra spod tego programu. Od razu pozytywne wrażenie - ładnie posortowane foldery, brak zbędnych przeszkadzajek. Odpalam grę. Ukazuje mi się dwa razy lepsza rozdzielczość niż w 2k3, i to w trybie okienkowym. Ilość kolorów też zdaje się być większa - są nawet różne poziomy przezroczystości. Całość prezentuje się więc bardzo dobrze, możliwości grafiki wydają się dorównywać nowym grom 2D we flashu / na komórkach.
Włączam program. Interfejs okazuje się jeszcze przyjaźniejszy i prostszy. Ładnie pogrupowane komendy, przystępny mapping na trzech warstwach. No i jeszcze ten 'edytor skryptów'. Nie wiem co to, ale skoro tu jest, a tam go nie było, to chyba nawet lepiej.

Nie ma się co dziwić, nowy użytkownik z pewnością sięgnie po Rpg Makera XP. Nie dość, że program posiada przystępniejszy interfejs, to gry w nim wykonane wydają się o wiele ładniejsze.


Podstawowe różnice

Poniżej przedstawiam tabelkę porównującą suche statystyki programów.

XP2k3
32-bitowa grafika.8-bitowa grafika.
Rozdzielczość 640x480.Rozdzielczość 320x240.
Nieograniczona wielkość większości zasobów.Ograniczona wielkość zasobów.
Edytor systemu gry w języku Ruby.Brak edytora systemu gry.

Ograniczenia 2k3

Najczęściej zarzucane wady RMa 2k3 to: słaba obsługa grafiki i brak edytora silnika gry. Przybliżę kilka faktów, starając się obalić niektóre z ograniczeń.

Słaba rozdzielczość programu. 320x240, piksel szerokości 5mm na ekranie. Owa szachownice nie wywiera pozytywnego wrażenia na przeciętnym użytkowniku. Ale pomyślmy nieco dłużej. Poprzednia wersja programu (95) posiadała rozdzielczość 640x480. Dlaczego więc twórcy ją zmniejszyli? Jestem w stanie wyobrazić sobie trzy powody. Po pierwsze, szybkość wyświetlania. Ekran 320x240 wyświetla się 4x szybciej niż 640x480. Być może silnik twórców działał za wolno i tylko w taki sposób mogli doprowadzić go do stanu używalności. Po drugie, prostota edycji grafik. Charasa 16x32 robi się o wiele szybciej niż 32x48. Efektem są setki charsetów krążących po internecie i duża ilość grafików potrafiących się z tym bawić. Po trzecie... 320x240 to rozdzielczość z większości starych gier na na nesa, snesa czy gameboye. Sporo ripów idealnie pasuje do gry. To dzięki temu na 2k3 mamy tak sporo poripowanych chipsetów i charsetów z przeróżnych konsolowych staroci. Podsumowując, z jednej strony jest to wada, z drugiej zaleta. Dodam jeszcze, że po dziś dzień powstają gry w takich rozdzielczościach (ds), choć po prawdzie na nowych monitorach wygląda to średnio (a przynajmniej przy (standardowo wymuszonym) fullscreenie).
Paleta 256 kolorów. Tak. W tym miejscu spora część załamuje ręce, uważając, że ograniczy to importowanie znalezionych obrazków. Otwierają je w paint'cie, klikają 'zapisz jako' i wybierają 256 kolorów. Wychodzi kiszka, program jest zły! Nic bardziej mylnego. Wystarczy, że dostosujemy paletę kolorów z pomocą dodatkowego programu (ifran view, gimp), a praktycznie każda grafika będzie pasowała do gry. Nie tylko więc jest to ograniczenie, co (tu akurat moim zdaniem) zabieg mający na celu przyspieszyć wczytywanie grafiki.
Ograniczenie wielkości charsetów - 16x32. Z jednej strony zaleta (podejrzewam, że brak obsługi większych przyspiesza działanie gier), z drugiej - ogromna wada. Co, jeśli dana postać ma być 2x wyższa od gracza? Nie ma sposobu?! Istnieje rozwiązanie tego problemu, po części. Można tworzyć połączone charasy lub pokazywać ich grafiki na obrazkach. Ten drugi sposób okazuje się świetny (przy bossach itp), działa szybciej niż w xp, ale i on ma wady. Mimo wszystko wczytywanie obrazków chwilę trwa, powstają też problemy z priority obrazków i ilością zdarzeń na mapie. Nie mówiąc już o trudności użycia tego sposobu przez nowicjuszy. 16x32 pozostaje, mimo tych karkołomnych rozwiązań, ogromną wadą.
Edytor skryptów. W 2k3 brakuje prostego sposobu na edycję systemu okienek, titla, menu czy systemu walki. Porównując do xp staje się to sporą wadą, w nowszej wersji wystarczy znaleźć odpowiedni skrypt i mamy gotową modyfikację - obsługę myszy, ominięcie titla itp. W 2k3 tego nie ma... Choć, nie do końca.
Istnieje spora ilość patchy usprawniających / modyfikujących system gry. Większość z nich ujęto w tej tabeli. Co można osiągnąć dzięki patchom? Odtwarzanie nowych formatów muzycznych, obracanie obrazków, ominięcie title screena, obsługę myszy i pełnej klawiatury, wyniki funkcji matematycznych, zmianę czcionki, ominięcie limitu stu obrazków itd. Możliwość tworzenia czy edycji istniejących patchy jest niestety znikoma - wymaga to sporych umiejętności, w porównaniu do dziecinnie prostego ruby z rmxp. Mamy jednak trochę ciekawych gotowców. Rozwijają możliwości programu? Rozwijają.
Poza tym zdarzenia w 2k3 pozwalają na o wiele bardziej skomplikowane systemy. A ich tworzenie przestało już być cholernie niewygodne, wraz z pojawieniem się RM Event Factory. Nie trzeba już kopiować 100 razy tych samych komend zmieniając tylko poszczególne liczby. Dzięki programikowi możemy kopiować fragmenty zdarzeń i zmieniać ich poszczególne liczby - id zdarzeń, id zmiennych, obrazki itp, po czym kopiować z powrotem do programu.
Podsumowując kwestie systemowe - brak możliwości edycji silnika gry wynagradza nam możliwość tworzenia niezwykle skomplikowanych systemów na zdarzeniach i spora ilość niszczących ograniczenia programu patchy.

Podsumowująca tabelka ograniczeń:

Zarzut.Rozwiązanie.
Rozdzielczość 320x480.Brak.
Charsety 16x32.~ Tworzenie łączonych charsetów lub użycie obrazków (picture).
8-bitowa grafika.~ Dobranie odpowiedniej palety kolorów dla grafik.
Brzydki title.Patch.
Brak obsługi myszy i większości przycisków klawiatury.Patch.
Brak edycji czcionki i obejścia niektórych ograniczeń.Patch.
Mozolne tworzenie na zdarzeniach ('w Ruby byłoby 10x szybciej!').RM Event Factory.
Brak możliwości edycji systemu gry.Brak.
Reszta zarzutów związanych z systemem.Brak!

Ograniczenia XP

Teraz zajmiemy się XP. Pójdzie nieco szybciej - na większość zarzutów odpowiedzią jest 'Ruby'. Ale nie na wszystkie. Tym razem wskazywać będziemy te ograniczenia, których nie da się pominąć (w przeciwieństwie do 2k3, gdzie mowa była o obalaniu ograniczeń).

Brak ruchomych panoram. W przeciwieństwie do 2k3, w RMXP nie można ich stosować, nie została wbudowana ich obsługa. Oczywiście szybko powstał skrypt korygujący tą wadę, jednak pokazał tylko, dlaczego twórcy z nich zrezygnowali. FPS. Ruchome panoramy działają w XP z prędkością żółwia i zacinają całą grę. Tak więc stanowczo - nie jest możliwe ich wydajne używanie.
Prędkość działania gry na większych mapach i z większą ilością eventów. Największa i najbardziej odrzucająca wada RMXP. Nie da się zrobić żadnego większego systemu na zdarzeniach (cmsa, cbsa czy huda) bez potwornych lagów. Zarówno wielkość mapy, jak i ilość równoległych zdarzeń bardzo mocno odciskają się na fpsie. Mamy więc wybór: zapomnimy o wielkich, żywych mapach pełnych ruchu, albo zapomnimy o posiadaczach pecetów sprzed 2+ lat. Powyższa wada sprawia, że o ile przeciętny użytkownik 2k3 może stworzyć własny, skomplikoway system walki i menu, o tyle w XP - nie może. W XP potrzeba do tego ruby, czegoś o wiele trudniejszego niż zdarzenia. W rezultacie bez znajomości ruby możemy używać tylko i wyłącznie gotowych skryptów, sami nie stworzymy niczego dostatecznie grywalnego.

Podsumowująca tabelka ograniczeń:

Zarzut.Rozwiązanie.
Brak ruchomych panoram.Brak.
Wolne działanie gier z dużymi mapami.Brak.
Brak możliwości tworzenia własnych, skomplikowanych systemów na
zdarzeniach (z powodu wolnego działania gier z takimi systemami).
Brak.
Reszta zarzutów związanych z systemem.RGSS!

Podsumowanko

Zbierzmy to w całość, raz jeszcze. RMXP jest przyjemniejszy dla nowego użytkownika i prostszy w obsłudze. Przy mniejszym nakładzie pracy można w nim osiągnąć ładniejsze efekty (rgss). Obsługuje więcej kolorów i większą rozdzielczość, kosztem wydajności. No i niestety, prędkość działania zdarzeń uniemożliwia tworzenie customowych, ciekawych systemów przez zwykłych użytkowników.
RM2k3 nieco trudniej opanować - mimo większej ilości tutków jest mniej przyjazny dla użytkownika. Program obsługuje mniej kolorów i mniejszą rozdzielczość, dzięki czemu nie 'muli' nawet na starszych kompach. Żeby stworzyć coś 'niestandardowego', twórca musi się troszkę namęczyć, ale ma ogromne możliwości - może tworzyć co zechce i ile zechce, bez obniżania prędkości gry. Jedynym ograniczeniem jest niemożność edycji samego systemu gry (poza drobnymi modyfikacjami z patchy).

Wybór nie jest więc prosty, w całości zależy od wymagań twórcy. Moim zdaniem fani oldschoolowych gier i szybkiej akcji na ekranie powinni brać się za 2k3, a cała reszta - za xp. Dobry twórca stworzy dobrą grę niezależnie na który się zdecyduje, jednak wybór będzie przyjęciem ograniczeń, których jego gra nie przeskoczy.
To by było na tyle. Good luck.


PS Porównanie napisane na luzie. Może zawierać drobne błędy, ale przymknijcie na nie oko. Pozdrawiam :).