Poradniki
RGSS
(Shlizer)
Przedwstęp
Z uwagi, iż poradnik jest pisany po kolei częściami (nie mam dokładnego planu jak będą wyglądać poszczególne etapy
prezentowania wiedzy) mogą występować jakieś niedopowiedzenia, powtórzenia części materiału
lub po prostu lekki chaos w kolejności prezentowanej treści (głównie w tej części kursu). Po ukończeniu większej
ilości części postaram się go przeredagować, aby pozbyć się tych niedogodności i jednocześnie dostosować do Waszych
propozycji oraz zaleceń i żali.
Kurs programowania w RGSS/Ruby - część 1
Gdy zaczynałem naukę RGSS i Ruby niemałym problemem okazał się brak obszernych tutoriali i szerokiej dokumentacji
języka. Choć konstrukcje i założenia nie były mi obce, wiele problemów z elementami składni nie dawało mi spać po
nocach, gdy angielskojęzyczna dokumentacja milczała, a wszelkie porady były kierowane do języków pokroju Java, czy C++.
Często też na forach spotykałem się z niemałą ilością postów z zapytaniem co i jak należy zrobić, aby coś dodać albo
żeby działało. Z tego powodu postanowiłem napisać kurs Ruby/RGSS (przynajmniej jego pierwszą część =p). Od razu jednak
zaznaczam, że prawdopodobnie pominę część wstępu do języka i niektóre zagadnienia będziecie musieli poszukać sami.
Pierwsza część jest stricte teoretyczna, jednak wiedza tu zawarta jest pomocna, nieraz wręcz niezbędna do dalszych
przygód z kodem. Nie martwcie się, jeśli nie wszystko będziecie rozumieć - w takim wypadku postarajcie się po jakimś
czasie, po przeczytaniu dalszych części lub innych artykułów o Ruby wrócić do tej części. Jestem pewny, że wtedy
wszystko będzie klarowne i zrozumiałe.
Czym jest Ruby?
Ruby jest językiem programowania - jak już zapewne wszyscy o tym wiemy. Jest on jednak nietypowym językiem z kilku
powodów. Po pierwsze jest to język interpretowany (jak np. PHP), a nie kompilowany. Co za tym idzie - szybciej się
uruchamia, ale wolniej działa (w locie musi tłumaczyć skrypt na kod maszynowy zrozumiały dla komputera). Ponadto wiele
błędów może zostać wykrytych dopiero wtedy, gdy program dojdzie do danych linii kodu - nie są one wszystkie sprawdzane
przed uruchomieniem (co w językach kompilowanych jest zadaniem kompilatora). Wyjątkiem są tu jednak deklaracje modułów,
klas i metod - są one przedwstępnie trawione przez interpreter. Cały kod jest także sprawdzany pod kątem błędów składni
(jak niedomknięcie jakiegoś bloku, zgubiony nawias itd).
Dodatkowo istotną dla nas rzeczą jest własny Garbage Collector, czyli odśmiecacz pamięci komputera - gdy jakaś zmienna,
funkcja albo zasób nie jest używany przez program (nie posiada odwołania do danego miejsca w pamięci komputera) jest
zwalniana.
Kolejną sprawą jest obiektowość Ruby'ego. Czym ona jest po trosze zajmiemy się później, ale jeśli w pełni chcesz poznać
zalety jej korzystania poczytaj o programowaniu zorientowanym obiektowo (OOP) w innych artykułach (np. w megaporadniku
Xiona).
Interpretowanie kodu w locie daje nam kolejną cechę języka (dla jednych jest to wada, dla innych zaleta). Nie musimy
bowiem martwić się o deklarowanie zmiennych - możemy je tworzyć w dowolnym miejscu w kodzie. Istnieje także redeklaracja
kodu oraz półautomatyczne rzutowanie zmiennych, ale tym zajmiemy się przy ich opisywaniu.
Miejsce pracy
Ponieważ ten kurs Ruby jest skierowany bardziej w stronę RGSS i przyszłych programistów RPG Makera, opiszę pokrótce jak wygląda miejsce pracy skryptera/programisty. Nie martw się, jeśli nie będziesz znać wszystkich przedstawionych tu słów i określeń - część z nich będzie opisana w tym poradniku, a resztę bez problemu poznasz odwiedzając Internet.
Jak na rysunku powyżej widać, z lewej strony mamy listę stron kodu z rubryką na nazwanie strony właśnie wyświetlonej.
Choć cały kod równie dobrze możemy umieścić na pojedynczej stronie, część ta ułatwia odnajdywanie oraz porządkowanie
kodu. Programiści Makera przyjęli, że każda strona oznacza osobną klasę (z wyjątkiem tych bardzo długich - one posiadają
kilka stron) i takiej konwencji raczej będziemy się trzymać, aby zachować ład i porządek w kodzie.
Prawa, główna część okna to kod właściwy naszej gry. To tutaj właśnie wrzucamy wszelkie skrypty oraz piszemy własne i
to na jej zawartości będziemy się skupiać. W samej ramce mamy kilka przykładowych struktur języka, o których jeszcze
będziemy pisać.
Pod częścią z kodem znajdują się przyciski akceptacji zmian dokonanych w kodzie, anulowania tychże oraz odnośnik do
dokumentacji RGSS/Ruby, z której zasobów korzystać polecam.
W tym miejscu mam także smutną nowinę dla osób, którym język Szekspira jest bardzo obcy - niestety bez znajomości
angielskiego żaden programista (czy to Ruby, czy innego języka) daleko nie zajdzie. Dzieje się tak z wielu powodów -
po pierwsze kod przypomina językowo angielskie słownictwo, więc już z samej znajomości słówek możemy dowiedzieć się
co prostsze skrypty robią. Ponadto większość poradników oraz dokumentacji jest właśnie pisana w tym języku obcym, a
ich polskie odpowiedniki nieraz są bardzo uproszczone, niepełne lub przetłumaczone tylko fragmentami. Dlatego jeśli
masz zamiar Drogi Czytelniku przyszłość swą wiązać z programowaniem w jakimkolwiek języku, możesz mi wierzyć na słowo,
że nauka języka angielskiego nie będzie czasem straconym.
Komentować
Zanim przejdziemy do konkretów programowania powinniśmy omówić sposób komentowania kodu. W Rubym komentarze linii
rozpoczynamy znakiem hash (#). Po tym znaku wszystko, co napiszemy staje się komentarzem i jest ignorowane przez
interpreter.1 2
Listing 1.1
# to jest jakiś komentarz
a = 0 # podstawiamy liczbę 0 pod zmienną 'a'
# poniżej linia, która nie zostanie przetworzona przez interpreter:
# a = 1
print a #=> 0
Komentarze wieloliniowe rozpoczynamy znakiem równości i słowem begin (=begin) i kończymy podobnie, z tym, że ze słowem
end (=end). O ile jednak komentarze linii możemy wprowadzić w dowolnym miejscu w kodzie, o tyle słowa kluczowe
komentarzy wieloliniowych muszą znajdować się na początku wiersza.
Listing 1.2
=begin
komentarz, który ma wiele linijek - każda deklaracja klasy,
metody, czy działania na zmiennych są pomijane przez interpreter
def foo
print "tekst"
end
tu następuje koniec komentarza:
=end
self.foo # wyświetli błąd - nie istnieje metoda o nazwie 'foo'
W jaki sposób komentować? To zależy już od samego programisty. Przykładowo ja w swoim kodzie zamieszczam komentarze
pisane po angielsku (w kursie tego robić nie będę). Dodatkowo przed samym kodem zaznaczam wersję skryptu, jego działanie,
ew. datę (przy większych klasach także cel istnienia poszczególnych metod oraz wymaganych danych do przetworzenia).
Ważne jest to, abyśmy po miesięcznym, dwumiesięcznym, czy półrocznym powrocie do tego samego kodu, po samych
komentarzach mogli dowiedzieć się za co odpowiada dana porcja kodu. Nie wolno jednak przegiąć w drugą stronę -
komentowanie każdej linijki tylko zaciemnia skrypt i przeszkadza w zrozumieniu jego działania.
Kolorowo
Przeanalizujmy teraz jak kolorowana jest składnia w edytorze Makera. Kolorem zielonym
(jak już pewnie zauważyliście) oznaczane są wszelkie komentarze. Na niebiesko oznaczone
są wszystkie słówka kluczowe składni kodu (class, for, while, def, in itd.). Jasnoniebieskim
kolorowane są znaki operatorów (+, -, *, &, ||, =) oraz wszelkie nawiasy. Kolorem
ciemnoczerwonym oznaczane są wszelkie liczby, purpurowym
zaś - łańcuchy znaków (tekst) oraz wyrażenia regularne. Na czarno natomiast jest zaznaczana cała reszta kodu =p.3
Bloki kodu i wcięcia
W programowaniu nie tylko to co piszemy jest istotne, ale także jak piszemy (co już po trosze opisałem przy
komentarzach). Istotne jest, abyśmy potrafili oddzielać umiejętnie porcje kodu tak, aby było wyraźnie widać gdzie się
kończą i gdzie zaczynają (co wcale nie znaczy, że każdy blok kodu mamy oddzielać 10 liniami odstępu). Aby zaprezentować
Wam to, o czym mówię spójrzcie na kod z obrazka poniżej.
Z lewej strony mamy kod bez wcięć, a z prawej ten sam tekst, ale już ze wcięciami. Teraz zadanie dla Was - który z
nich jest czytelniejszy? Chyba nie ulega wątpliwości, że ten po prawej - wyraźnie widać gdzie się kończy, a gdzie zaczyna
wnętrze klasy. Oddzielone są zarówno definicje metod (def), jak i struktury kontrolne - pętle (for) oraz instrukcje
warunkowe (if). Często także większe bloki oddzielane są jedną lub kilkoma liniami komentarze, co możecie zaobserwować
studiując kod gotowych klas w Makerze.
Trochę o składni
Składnia języka Ruby jest nieco bardziej frywolna niż w innych popularnych językach programowania. Pierwszym rzucającym
się w oczy elementem jest brak średników obecny w większości języków - tutaj końcem polecenia jest koniec wiersza.
Nic jednak nie stoi na przeszkodzie, aby średników używać - są one przydatne, gdy chcemy np. wywołać krótką pętlę i
nie chcemy jej rozpisywać na kilka linii.
Listing 1.3
for i in (0..3); print i.to_s; end;
#=> 0 1 2 3
Co jednak, gdy nie chcemy łamać linii? Nie mamy się czym martwić. O braku przerwania procedury informujemy interpreter
poprzez dodanie znaku backslasha (\) na końcu linii:
Listing 1.4
if @jakas_bardzo_dluga_nazwa_zmiennej \
and @inna_dluga_nazwa_zmiennej
print "alert"
#=> alert
end
O co chodzi z tym print? No właśnie - jeśli szukaliście innych poradników i kursów Ruby zapewne zauważyliście, że
metodą wypisującą wynik na ekranie jest 'puts'. O ile jej wywołanie w RGSS nie zwróci żadnego błędu, o tyle nie zwróci
także żądanej wartości (nawet jeśli uruchomimy program z konsoli!). Sam RGSS jednak został wyposażony w inną metodę
prezentującą dane wyjścia i jest nią właśnie 'print'. Wywołując ją wyświetlamy okno Windowsa z informacją, której treść
jest równa naszemu wyjściu. Warto jednak pamiętać, że metoda ta przyjmuje wartości typu łańcucha znaków
(tekst), dlatego w listingu 1.3 liczby 0-3 musieliśmy zamienić na tekst ("0", "1" itd.) rzutując zmienne poprzez '.to_s'.
Kolejną ważną rzeczą w Ruby są dopowiedzenia. Wiele struktur interpreter sam sobie dopowiada, więc (o ile nie może to
zostać dwuznacznie zinterpretowane) sam je sobie dodaje.
Listing 1.5
self.metoda(a,b)
self.metoda a b
# oba powyższe wywołania będą równoznaczne
Podsumowując:
- jeśli znasz inne języki programowania niż Ruby, nauka tego języka będzie raczej bezbolesna i szybka
- znając angielski jesteś o kilka kroków do przodu w zdobywaniu wiedzy dotyczącej programowania
- pisząc kod staraj się, aby był on przejrzysty i klarowny - nie dopuść do sytuacji, w której Twój kod nie jest jasno
udokumentowany
- dbaj o wcięcia kodu oraz wyraźnie zaznaczaj główne bloki skryptu
- nie bój się zaglądać do innych źródeł wiedzy programistycznej - nie tylko z języka Ruby, bowiem większość
popularnych języków różni się głównie składnią, zostawiając zasady pisania takie same (głównie tyczy się to
programowania obiektowego, czyli OOP).
Ćwiczenia i zadania:
- przejrzyj kod gotowych klas w Makerze i przeanalizuj w jaki sposób jest on komentowany oraz w jaki sposób oddzielane są bloki; nie musisz wnikać co dany kod robi;
Postscriptum
W tej części kursu to tyle. W następnej partii materiału zapoznamy się z prostszymi rodzajami zmiennych oraz stałych,
operacjami arytmetycznymi i powoli wejdziemy w temat programowania obiektowego.
Wszelkie sugestie, pochwały, uwagi, groźby i krytykę kierujcie na forum RMXP.pl lub na mój osobisty mail shlizer*wp.pl
(przy czym poczty nie sprawdzam nieraz nawet przez tydzień, więc nie martwcie się, jak nie odpiszę od razu =)).
1 ze względu na przejrzystość czasem linie kodu będą posiadać numery;
2 przyjąłem taką konwencję, że każda wartość wypisywana na wyjściu będzie przeze mnie prezentowana w komentarzu
zaczynającym się od '#=>'
3 starałem się, aby kolorowanie kodu w kursie było podobne do tego w programie, ale jak wyszło - sami
widzicie.. =p
