[VXAce] Co się da, a czego nie da się na eventach ?

[X-Tech]

Tu są nasze sugestie odnośnie tego co jest możliwe na eventach, a niekoniecznie potrzeba do tego Ruby. Również wymieniamy rzeczy, których bez ruby (rgss3) się nie da zrobić. Jako, że ogarnąłem trochę ten język zaczynam

Na eventach da się:

*Zrobić własne menusy obrazkowe i inne wyskakujące tego rodzaju info/wybory/staty na potrzeby gier.
*Systemy Walki - ABSY, własne i systemy podobne do bazowego
*Da się zrobić różnorodne elementy rozgrywki jak minigry i wszelakie rozwiązania jakie tylko przyjdą nam do głowy...
*Zagadki
*Systemy rozgrywki
*Hudy
*Modyfikować znacznie podstawowy system walki

itd...


Na samych eventach nie da się:

*Edytować i włamywać do podstawowych elementów rpgmakera.
(bazowe menu, wyświetlanie przedmiotów z bazowego menu, ekwipowanie ITD.)Dosłownie w Ruby da się włamać do wszystkiego w Rmie.

*Nie da się zmieniać działania podstawowych wbudowanych rzeczy. np: Podstawowe obliczenia obrażeń w systemie walki - nie da się zmienić bez Ruby, sposobu w jaki rm czyta klatki animacji z szablonów itd.



*Nie da się tworzyć elementów, które potrzebują gigantycznej ilości pamięci bez Ruby. Nie ma to sensu w przypadku tworzenia na eventach jeśli zajmie to większą cześć zmiennych/switchy. Metoda szukania drogi z a-b na spore odległości, magazynowanie ogromnej ilości informacji itd.


*Rozszerzyć opcji programu o np: obsługę myszki, dodać hak, który zmieni całkowicie jakiś element stosowany w programie itd.

[Leoś]

Nie ma co dodać. Ująłeś całe sedno. Nasuwa się wniosek, że choć wiele da się zrobić na eventach, bez Ruby mejkerowanie jest jednak ubogie XD Czyli co... warto się uczyć?

[Chod]

Duża jest różnica między językiem w XP a VX Ace? :)

[X-Tech]

@Leoś: Ujmę to tak...zależy do jakich celów.


@Chod: Wiem, że ta wersja języka jest o wiele szybsza, od tej która była w rpgmaker XP

[Adrapnikram]

Ja uważam że trzy opcje eventu: Warunek, Zmienna i opcja Pokaż obrazek( i zmień położenie obazka itd.) mogą wystarczyć do stworzenia wielu systemów , menusów, wyświetlanie eq o ile jest zrobione na evantach, a nie w bazie danych. Jednak jest jeden problem. Mianowicie to może trwać więcej niż napisanie własnego skryptu.
A i nie zrobi się na pewno na eventach:
Obsługi urządzeń zewnętrznych: myszka, kamerka itp.
Połączenie z netem
No i to co powiedział X czyli zmiana podstawowych funkcji programu: poruszanie się postaci po klatkach 32x32 czy inna prędkość bohatera np.4,5

[Dragon Kamillo]

Ze wszystkim powyższym się zgadzam, ale i na ruby wszystkiego zrobić się nie da co by się chciało.

Trzeba zawsze pamiętać że sama struktura programu nas ogranicza. Mamy takie ograniczenia jak wielkość zmiennej, określone na sztywno rozmiary okienek do wpisywania, chory system tiles który w przeciwieństwie do tego z XP nie nadaje się za bardzo do skomplikowanych skryptów, ograniczoną ilość klatek (charsety i animacja - choć to pierwsze nie powinno przeszkadzać) itp. I choć da się to ominąć w ruby to powoli zamienia się to w pisanie gry tylko w ruby, bo na eventach się nie da.

Do niektórych rozwiązań trzeba więc mieć większa wiedzę niż umiejętność ruby (np. ten netplay) po to by napisać zewnętrzne biblioteki i programy do których potem można się odnieść w rubim.

Do tego należy pamiętać że niektórych rzeczy nie opłaca się robić w makerze (nawet w ruby) bo wydajność tego może być nie za dobra.

W RMXP było mniej komend zdefiniowanych w podstawie rgss więc można było szybciej obczaić kod, bez żmudnego wkuwania, zaglądania do helpa co do czego służy - przez co było więcej kodu, co przyczyniło się wraz ze starszą wersją ruby (5 razy wolniejszym od tej nowszego...) do tego że RMXP jest wolniejszy. Ale łatwiej w nim ogarnąć skrypty.

Czyli w sumie w ruby można prawie wszystko - ale niektórych rzeczy nie opłaca się robić w makerze i łatwiej jest wtedy zrobić własny silnik.

[X-Tech]

Napiszę tak do ogółu w skrócie. RGSS3 jest dla skrypterów i hakerów - dla osób, które robią skrypty dla tych, którzy robią gry. RGSS3 jest tak wielkie, że to jest jak osobna dziedzina obok robienia gier dlatego na świecie na ogół określa się tych, którzy piszą w Ruby skrypterami i w tym praktycznie tylko siedzą, bo ogrom wiedzy do wbicia żeby z tego korzystać w swobodny sposób tak jak na eventach jest porażający. Znam przypadek BS taktycznego, który powstaje od lat w Ruby także to nie jest tak, że w Ruby zrobisz szybciej i łatwiej.


Ruby/RGSS3 jest potrzebne żeby zrobić rzeczy, których na eventach się nie dało, ale robią to skrypterzy (!) - oni tworzą skrypty, a twórcy gier ich prosto używają w swoich projektach. Tych skryptów są setki/tysiące dlatego nie nie musisz uczyć się Ruby ani RGSS3 jak robisz gry w VX ACE. W odpowiednich kombinacjach można robić porażające projekty...i nie trzeba wkuwać RGSS3...RGSS3 jest dla skrypterów (!)



@Adrapnikram - Na eventach się programuje. Czy zrobisz szybciej w Ruby ? Wątpię. Na pewno nie łatwiej. Obsługa myszki itd. jest już zrobiona przez skrypterów dlatego osoba, która robi gry nie musi się tym zajmować - nie musi znać RGSS3, bo większość skryptów już jest, a podstawowe są już dorobione na skryptach w 100% dlatego nie - nie ma potrzeby uczenia się RGSS3, aby robić w rmie vx ace świetne gry...


@DK:

Wielkość zmiennej ? W każdym języku jest ograniczona wielkość zmiennej.

Rozmiary okienek ? Znowu jakieś pierdoły wypisujesz.
Program cię nie ogranicza w twoich własnych grach - w tym wszystkim co wymieniłem w rzeczach, które da się zrobić bez Ruby. Chcesz własne okienka to sobie zrób jakiej chcesz wielkości na eventach lub zrób sobie własne w Ruby, ale to drugie jest dla raczej dla skrypterów...ale są i hardkorowcy, którzy edytują bez kucia RGSS3 z kontekstu.


NETPLAY ? ...Ty chyba żartujesz. Nie.

[beo117]

Cytat:*Nie da się tworzyć elementów, które potrzebują gigantycznej ilości pamięci bez Ruby. Nie ma to sensu w przypadku tworzenia na eventach jeśli zajmie to większą cześć zmiennych/switchy. Metoda szukania drogi z a-b na spore odległości, magazynowanie ogromnej ilości informacji itd.

I to jest według mnie najbardziej przydatne zastosowanie RGSS. Stworzenie własnej bazy danych bez niego było by bardzo trudne, jeżeli nie niemożliwe. Na samych zdarzeniach nie dało by się zrobić np. rozbudowanego systemu dialogów, zapamiętującego, które kwestie wykorzystaliśmy itp.

[X-Tech]

Zapomniałem jeszcze o jednym. Ruby jest dość proste do zastosowania w rmie ( wystarczy znać zmienne i warunki) do robienia skomplikowanych obliczeń matematycznych i również prostych np: do liczenia odległości dwóch punktów od siebie itp. W zmiennych rm nie ma liczb rzeczywistych tylko całkowite - w Ruby jest Float, a więc łatwo i szybko dopisać w komendzie script jakieś obliczenie, które chcemy zrobić na eventach w przypadku bardzo złożonych obliczeń i zwrócić do zmiennych rma - w formie zaokrąglonej. Przyznaję jednak, że to się przyda tylko w specyficznych sytuacjach w specyficznych projektach.


Kolejna rzecz to Ruby zastępuje podstawowe komendy z rm 2k3

wystarczy dać jako $Game_Variables[[$Game_Variables[zmienna2]] aby uzyskać komendę z 2k3 znaną jako: ustaw wartość zmiennej nr: blabla na zmienną, którą wskaże zmienna o adresie "zmienna2" git


Trzecia rzecz:
Nie trzeba się uczyć całej bazy rma żeby rozumieć składnię RGSS3 - wystarczy ogarnąć trochę Ruby i poruszasz się po tym jak po własnym podwórku..

[Dragon Kamillo]

Ale nie zastępuje w prosty sposób wszystkich komend z 2k3.

Dodatkowo to co piszesz o skryptach to wszystko prawda, jest tylko jeden problem - tych skryptów są setki, każdy ma swoje bugi itp - trzeba więc się przekopywać przez syf by znaleźć jakąś perełkę.

A co do skryptu na obsługę myszy - to naprawdę wolałbym ją zrobić z jakakolwiek łatką na 2k3 (+ wyświetlanie obrazka) - niż mieć gotowca z kursorem itp całą działalnością w ruby. Jeśli jednak istnieje jakiś skrypt który by tylko i wyłącznie zapisywał współrzędne kursora do dwóch normalnych zmiennych i mógł sprawdzić podobnie jak komenda obsługa klawiatury w makerze wciśnięcie przycisków na myszy itp - to coś by z tego było. Ale za pewne te wszystkie skrypty na mysz zmieniają całą działalność gry. Nie lubię gdy skrypt robi za mnie za dużo - bo jednocześnie często też w ten sposób ogranicza.

X-Tech zewnętrznego programu (w tym wypadku jest to RMXP) potrzeba gdy chce się mieć normalny system tiles a nie ten VXsowy syf. Albo inny przykład więcej tilesów w RMVX tez się obsługiwało przez zewnętrzny program. Samo ruby nie wystarczy.

Zapomnij co pisałem o ograniczeniu miejsca w okienkach - scroll tekst załatwia sprawę.

Ale np zmienna ma w vx ace 8 cyfr, w 2k3 - 7, ale istnieją tam łatki że może mieć 10 + parę kliknięć i mamy normalną obsługę tego z normalnej komendy.
W vx ace musisz już takie zmienne obsługiwać całkowicie z ruby.

Może się ostatnio źle wyraziłem - chodzi mi o to że skrypterzy w ruby mogą wszystko, ale żeby potem udostępnić to tym zielonym - i tu zaczynają się ograniczenia programu.
Znowu posłużę się tym zwiększeniem cyfr w zmiennej, taki skrypt wymagał by obsługi całej komendy zmień zmienne w ruby, do tego jeszcze komendy warunkowe. No chyba że ilość cyfr możliwych do wpisania w programie jest jakoś związana ze skryptami w grze - w co wątpię.

"ale są i hardkorowcy, którzy edytują bez kucia RGSS3 z kontekstu" - robiłem (i robię nadal) tak w RMXP, ale w Ace nigdy mi się nie udawało.

Kto pamięta te wszystkie skrypty które obsługiwało się wyłącznie przez linijki kodu, a wszystkie eventy były ignorowane...