Almora Origins

Kilka małych nowości

AlmoraSzkicJeśli śledzicie nasz fanpage na Facebooku to pewnie jesteście na bieżąco, ale dla całej reszty (oraz tych, którym FB nie wyświetlił któregoś z postów) kilka krótkich informacji.

Prace nad obiema Almorami są prowadzone cały czas, nie bójcie się. Obie gry planujemy wydać w tym roku – na „dużą” Almorę dodatkowy nacisk kładzie licencja developera iOS kosztująca ponad 300zł którą muszę odnowić we wrześniu, więc jeśli się nie wyrobię oznacza to dla mnie stratę.

StaraAleJaraJeśli chcecie powspominać stare czasy, to zebrałem z forum gmclan.org wasze screeny z Almory Online i stworzyłem album 109 zdjęć – dostępny tutaj. Nie trzeba konta na Facebooku aby go oglądać :)

ItemPackerScrren1Dodałem dział „Narzędzia i Aplikacje” w którym dzielić się z wami będziemy aplikacjami napisanymi na nasze wewnętrzne potrzeby, a które być może da się użyć też do innych typów gier i jakoś skorzystacie na naszej pracy. Na razie jeden pełen program, kod źródłowy do dwóch i zapowiedź jednego, ale w przyszłości pojawią się tam pewnie też przykłady skryptów GM:S itp.


Trochę teorii – towarzysze

Dziś krótka nota o rzeczy którą być może wprowadzę w Almorze pod koniec sam koniec etapu tworzenia. W drodze z i do pracy mam zawsze trochę czasu aby w pociągu przemyśleć niektóre rozwiązania. Grając w kilka gier na konsoli czy PC, a także porównując  z wersją online doszedłem do wniosku, że jedną z rzeczy które by się w grze przydały byłby towarzysz który za nami podąża. No cóż, zagadnienie nie jest takie proste, ale kilka kolejnych dni przemyśleć podsunęło mi trochę rozwiązań. Największym wyzwaniem jest zdecydowanie podążanie za graczem – ale tutaj GM:Studio samo podsuwa rozwiązanie – jeden z przykładów praktycznie podaje na tacy to czego potrzeba. Wystarczy użyć ds_listy która zapamiętuje pozycje gracza – powiedzmy gdy od ostatniej pozycji odejdziemy na 20 pikseli. Postać która za nami podąża przestrzega też jednej zasady – idzie w ustalone miejsca ale tylko tak długo, aż w kolejce są więcej niż dwie ostatnie pozycje – dzięki temu na nas nie wchodzi, stoi w pewnym odstępie i zaczyna podążać dopiero gdy oddalimy się o 20 pikseli. Ma to też jeszcze jedną zaletę – postać chodząca w kółko nie tworzy żadnych nowych pozycji, więc ta podążająca nie reaguje na nie w żaden sposób. Trzecia sprawa – w przypadku walk towarzysz może na chwilę wyłączyć podążanie, a zabrać się za walkę – gdy ona się skończy, z powrotem wrócić do śledzenia postaci, wybierając za następną pozycję tę na której podążanie się kończy (czyli trzecią na liście). Dzięki temu szybko nas dogoni. Tyle teorii, zobaczymy czy praktyka okaże się równie prosta – nie mniej jest to element gry który będę chciał wstawić względnie bliżej 90% ukończonej gry i w przypadku problemów może się stać tak, że jednak go pominę – więc nie obiecuję, że towarzysze w grze się pojawią, ale na pewno poświęcę dzień lub dwa na próby. A może ktoś z was stworzy ciekawy przykład takiego zachowania na podstawie moich przemyśleń?

1 komentarz więcej...

Edytor animacji

almora-animacje2Dzisiaj w ramach nowinek Almorowych, praca moich ostatnich kilku wieczorów – edytor animacji do Almory, dzięki któremu mogę szybko stworzyć nowe animacje do ataku, poruszania się itp. Jeśli zastanawia was po co dla postaci do której animacje w sumie już istnieją robię osobny edytor, po podam wam dwa powody: 1) Drobne poprawki zabierają za dużo czasu – zmiana jednej cyferki, odpalenie gry i sprawdzanie tego w ruchu to ok. 5 minut – tymczasem w edytorze mogę wartości zmieniać „na żywo”. Powód 2) Animacje w tym edytorze będą tworzone nie tylko dla postaci głównej, ale też dla… to zobaczycie za jakiś czas, ale możecie liczyć na nieco bardziej ożywionych przeciwników niż do tej pory.


Edytor map 2.0 w Almorze

W poprzednim wpisie wspomniałem o tym, że robię nowy edytor map – room editor z GM:Studio może i nie jest zły, na pewno lepszy niż wcześniej – ale mapy w Almorze są dość skomplikowane i wiele elementów nakłada się, przez co ciężko je jakkolwiek edytować, do tego sporo elementów ma specjalne właściwości (np. numer questu czy dialogu) – zamiast tworzyć 100 obiektów w których zmienia się tylko ubranie i numer dialogu, łatwiej ustawić zmienne bezpośrednio na mapie. Wcześniej korzystałem z edytora napisanego w GM, który szyfrował dane, zapisywał dane o zasobach i potem gra je odczytywała. Jak pisałem w poprzednim poście, nie ma sensu już tak dalej robić, a nawet częściowo się już nie da – nie mniej GM:Studio zapisuje zasoby jako pliki XML, więc wpadłem na inny pomysł. Na podstawie istniejącego edytora GMare do GM8 (a więc częściowo na gotowym kodzie), stworzyłem specjalny edytor w C# korzystający z OpenGL, który jest w stanie odczytać zasoby GMowe i zapisać mapę bezpośrednio do GM:Studio – i tam wciąż edytować. Mogę też tworzyć mapę najpierw w GM:S, a potem poprawiać ją w edytorze – program więc integruje się w pracę i ułatwia tworzenie, a nie tworzy nowe pliki które trzeba interpretować. Edytor będzie w miarę uniwersalny (tzn. powinien nadać się do wszystkich gier, w których jak w Almorze elementy otoczenia będą jednym obiektem, którego właściwości są nadawane po stworzeniu – sprite_index, mask_index, solid, x, y, oraz jakieś customowe zmienne). Edytor zostanie w najbliższym czasie (gdy go skończę) wydany publicznie, także każdy będzie mógł go wykorzystać w swojej grze (dostępna będzie dokumentacja i prosty projekt przykładowy).


Gdzie ta duża Almora?

Ostatnio sami zagadujecie w komentarzach, na facebooku czy to nawet na GG, kiedy pojawi się w końcu nowa Almora. No cóż, to dobre pytanie, ale na pewno nie pojawi się ona przed wyjściem GameMaker:Studio w wersji 1.2. Dlaczego? Otóż  ta właśnie wersja zaoferuje kilka rzeczy, które niewątpliwie wpłyną na działanie gry. Np. Shadery – które pozwolą na efekty graficzne nieosiągalne wcześniej lub bardzo niewydajne (liczę na: blur, grayscale, tint), LLVM czyli pełną kompresję binarną kodu GML (znaczne przyspieszenie wykonywania eventów), nowy Debugger (przydatny przy wykrywaniu błędów gdy ma się kilka tysięcy obiektów w grze, oraz np. do czytania struktur danych które Almora wykorzystuje, a w których błędu obecnie można szukać czasem i dwa dni), czy obsługę plików OGG. Dodatki wersji 1.3 i 1.4 nie są czymś co obecnie chciałbym wykorzystać (chociaż oczywiście obsługa sieci czy GPSa znalazła by swoje zastosowanie).

Duże opóźnienie spowodowało też kilka zmian w GM:Studio. Po pierwsze, do tej pory wszystkie zasoby czytałem z zewnątrz, w tym także generowałem itemy i mapy. Niestety od jakiegoś czasu GM:S sandboxuje gry (tzn. nie pozwala czytać plików spoza katalogu gdzie działa) i 39dll który do tego wykorzystywaliśmy zaczął się nieźle gubić – nie mniej ponieważ GM:S jest już wystarczająco bezpieczny, to nie ma sensu tego czytać z zewnątrz, a na iPadzie też stanowiłoby to problem. Uprościłem więc całość i mapy oraz itemy są teraz zdefiniowane w grze – przy okazji, wczytywanie przyspieszyło.
Czytanie grafik z zewnątrz też stanowiło pewien problem – po pierwsze, GM nie chciał ich czytać z tego folderu którego chciałem, po drugie na iPadzie i tak to nie działa, po trzecie – GM:Studio oferuje coś takiego jak „texture pages” i można fajnie zoptymalizować grę – tak jak kiedyś nieużywane w aktualnym terenie grafiki usuwaliśmy z pamięci, tak teraz GM:S robi to sam (każda kraina jest na innej stronie tekstur, a GUI na jeszcze osobnej) – i też widać pewien skok wydajnościowy. Ostatnia zmiana to mapy – kiedyś całość mieściła się na jednej mapie – nie mniej w trybie simple nie ma potrzeby trzymać wszystkiego na jednej mapie – nie ma innych graczy których trzeba utrzymywać na ich pozycjach – więc przerabiam też edytor map tak, aby można było ich tworzyć więcej. To oznacza też, że pojawi się więcej niż do tej pory dungeonów i niektóre będą losowo wczytywane.

Ogólnie w końcówce stycznia większość zmian powinna już być gotowa i gra będzie rozbudowywana od tego momentu głównie o questy i nowe akcje przeciwników (jedyną formą ataku AI nie będzie już tylko podchodzenie i atakowanie, będą ataki magiczne, itp.). Pewnie część rzeczy byłaby gotowa wcześniej, ale bugi nękające GM:Studio często zatrzymywały mnie nawet na 2-3 tygodnie (wieszanie się GMa przy dużych tablicach gdy wystąpił błąd, przez co nie mogłem zdebugować praktycznie nic, bo nawet jeśli błąd nie dotyczył itemów, to oczekiwałem na komunikat o błędzie nawet 15 minut…).

Jeszcze w tym miesiącu spodziewajcie się nowych informacji o grze :)


Almora – kwietniowy pamiętnik

Cześć i czołem, Hidden Sword pod stołem, hłe hłe. Witam najbardziej cierpliwych graczy w tej części Europy, którzy czekają na Almorę. Oczywiście wciąż do zrobienia w grze jest dużo, ale zaczynam zbliżać się do momentu, gdy jest tego mniej niż więcej. Od ostatniego czasu zdążyłem się przeprowadzić, wydać inną grę, czy przylecieć na święta do Polski – działo się dużo… pracowałem przez jakiś czas nad edycją ścieżek w grze – do tworzenia rzek, oraz tras w lesie – niestety efekty wciąż są niezbyt zadowalające (tekstury się „rozciągają” co nie wygląda najpiękniej), więc na razie ten element pominąłem – bez sensu tracić dni na coś, co jest tak naprawdę w tej chwili mniej potrzebne – popierdółki graficzne mogę sobie przecież dorabiać w trakcie, gdy gra będzie już w fazie beta testów. Tak więc skupiłem się teraz na Questach i NPC. Na razie tych pierwszych jeszcze nie ma, chociaż częściowo już mam pod to przygotowane skrypty, ale zaczynają się pojawiać NPC, których mogę sobie konfigurować w edytorze map. Wkrótce dorobię też dla nich znaczniki do ścieżek, więc do Alebry znów wróci życie, jak za czasów Almory Online. Co prawda w mieście zmieni się nieco lokacja budynków (głównie tawerny), ale starych kolegów znajdziecie bez problemu – wciąż będzie można usłyszeć słynne „Leave me alone” albo „hehehe” od odpowiednich NPCów. W grze zmieniło się menu (prawdopodobnie już ostatecznie, pojawią się tylko różne dodatkowe ozdobniki), wkrótce zacznie pojawiać się GUI (ponieważ atakowanie wszystkimi 3 rodzajami broni już działa, więc najwyższy czas dodać wyświetlanie magii, czy używanie itemów). Udało mi się też nieco poprawić AI, chociaż to wciąż nie to, co chciałbym uzyskać (przejście za plecami NPCa dosłownie ocierając się o niego, powinno jednak wywołać jego zainteresowanie…).

Z innych rzeczy: parę dni temu dla oderwania się na chwilę, testowałem stary prototyp Almory (Triberian) na iPadzie 2. Niestety, spora część rzeczy nie działała (iPad nie obsługuje wczytywania plików luzem z dysku, muszą być wkompilowane w grę), więc wywaliłem co zbędne aby nie przedłużać testu i z samą trawą i grafiką bohatera, zrobiłem proste dotykowe poruszanie (palec – chodzenie, dwa palce – atak). Absolutnie nie myślcie, że pracuję obecnie nad wersją na iPada – tą zajmę się dopiero gdy gra wyjdzie na PC – na podstawie waszych opinii będzie można jeszcze zmienić to i owo. Bowiem to wersję na iPada zakładam jako tą, która przyniesie większy sukces finansowy dla mnie i Borka.


Almora DevDiary #3 – dialogi

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


Dev Diary #1 – dodatkowe narzędzia

Jak pewnie niektórzy z was wiedzą, nasze gry tworzymy za pomocą Game Makera – nie jest to jednak jedyny zestaw narzędzi wykorzystywany do pracy. Pomijając już programy graficzne wykorzystywane do tworzenia całego świata, np. przy tworzeniu Almory wykorzystywane są jeszcze inne aplikacje. Świat Almory znacznie się rozrósł od wydanego dawno temu Hidden Swords – zarządzanie niektórymi zasobami stało się przez to dość kłopotliwe – ot dla przyspieszenia ładowania mapy postanowiliśmy ją podzielić na strefy – niestety przez to Room Editor zawarty w Game Makerze stał się nieprzydatny, ponieważ mapa jest wczytywana fragmentami z pliku. Trzeba było więc stworzyć własny room editor, ale dzięki temu można go też było wyposażyć w kilka bajerów, jak rozkładanie trasy dla NPC, ustawianie spawn pointów, czy obracanie otoczenia  – wszystko to potem można zapisać w plik i gotowa gra odczytuje w locie potrzebne fragmenty mapy.
Podobnie sprawa ma się z przedmiotami dostępnymi w grze. Zarządzanie (czytaj dalej…)


© 2011 GEAR-STUDIO. Wszystkie prawa zastrzeżone.
Szablon: Jarrah autorstwa Templates Next, poprawki oraz modyfikacja Gear-Studio, tłumaczenie: Wordpress PL | Działa na WP