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.
Smacznego =)

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.
rys.1.1
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.
rys.1.2
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

 
 
www.000webhost.com