Dziś trochę o systemie dialogów. Przez kilka lat mojej pracy z Game Makerem poznawałem jego zalety – dialogi to chyba jeden z większych progresów jaki uczyniłem. Pierwsze z nich były wyświetlane w pętli while literka po literce w tej samej klatce obrazu, na której „dorysowywane” były kolejne znaki – tak jak np. w Pokemonach. Potem był obiekt któremu ustawiałem odpowiednie zmienne z tekstem i włączałem/wyłączałem animację. Jednak w momencie, gdy do dialogów musiałem dodać również możliwość odpowiadania, dochodziło całkiem sporo zmiennych które trzeba było dodać, oraz warunków (przed pytaniem, w trakcie, po, wybranie odpowiedniego) – krótki dialog potrafił zjadać kilkadziesiąt linijek kodu. W przypadku Almory Online w wersji 0.7.6, skorzystałem z jednej ze struktur danych jaką oferuje GM, zwanych kolejkami. Teksty danego dialogu były wrzucane na kolejkę (stos LILO), a potem skrypty same go ściągały, dzięki czemu mogłem sobie pozwolić na zmniejszenie liczby warunków – nie mniej w przypadku opcji wyboru kod niewiele się zmienił.
Tworząc jednak Almorę singlową nauczyłem się w GM jeszcze jednej rzeczy – każda struktura danych zwraca referencję na siebie w postaci jakiejś cyferki – a cyferkę można przechowywać w innej strukturze/tablicy, tworząc w ten sposób zagnieżdżone struktury. W ten sposób stworzyłem sobie listę tego jakie dialogi mogą być w grze. Do głowy przyszły mi dialogi normalne, ramki z tekstem tytułowym na środku ekranu (np. nazwa rozdziału, czy questu, czy info o nagrodach), tekst na środku ekranu bez ramki (nazwy miast), pytania i listy wyboru, oraz na wszelki wypadek gdyby mi wpadło kiedyś coś innego do głowy – skrypt – gdzie zamiast tekstu na ekranie wykonywany będzie skrypt. Drugą rzeczą, którą ma każdy z tych dialogów, to tekst. Jeśli jest to skrypt, będzie to jego nazwa, ale to nadal tekst. Trzecia rzecz która się tutaj rzuca, to możliwe odpowiedzi. Ostatnią, jest kolejny dialog. W ten sposób stworzyłem strukturę ds_map (klucz/wartość), w której zapisywane będą dialogi. Pierwsza mapa trzyma kolejne id dialogów, a wartościami są kolejne mapy zawierające jako klucze typ, tekst, odpowiedzi, kolejny dialog. Oczywiście gdy nie ma odpowiedzi, wartość jest pusta, a gdy dialog jest ostatnim, id jest zerowe. W ten sposób, zamiast dla każdej postaci pisać skomplikowane warunki na wypadek różnych wyborów odpowiedzi i różnych dialogów zależnie od sytuacji, podaję tylko id skryptu od którego zaczyna się dialog, a resztę obsługuje już gra. Skrypt który to wszystko obsługuje jest porównywalny z tym który w Almorze 0.7.6 obsługiwał jeden krótki quest – z tym wyjątkiem, że teraz mogę stworzyć nieskończoną listę questów, nie dodając już kodu. Co więcej, dialogi mogą być wczytywane z zewnętrznego pliku, więc mogą je przygotować nawet nie programiści. I chociaż spędziłem nad tym systemem 3 dni, to zamiast siedzieć nad każdym z kolejnych questów 3-7 dni, będę potrzebował 3-6 godzin. Możecie się więc spodziewać w Almorze 1.0 dużo ambitniejszych questów niż w wersji online, oraz rozbudowanych dialogów – bo jak już wspomniałem, aby je dodać, nie trzeba będzie nawet programować. Na obrazku z prawej macie rozrysowany przepływ skryptu który obsługuje dialogi.
Poniżej screen porównujący ten sam quest w Almorze Online 0.7.6 oraz Almorze 1.0 (single).