Dlaczego Almora:Origins powstaje tak długo?

Żeby było jasne. Almora, to gra którą wymyślił i stworzył Grzegorz „Borek” Borkowski. Ja na przyczepkę dzięki sporej wiedzy i szczęściu załapałem się, aby na chwilę dać mu odpocząć przy projekcie. Ostatecznie wyszło w końcu tak, że „większą” rozbudowaną wersję i jej engine na PC programuję ja (przy czym Borek wciąż odpowiada za grafikę i nadzoruje gameplay, aby w końcowej fazie ponownie dołączyć), a sam w tym czasie zrobił wersję na komórki – Almora:Darkosen, która niejako przeciera szlaki i jest testem co w „dużej” PC-towej Almorze powinno być, a na co gracze będą narzekać – tak, żeby wydać dzieło idealne.


Wstyd mi się nawet przyznać, kiedy moje prace nad Almorą zostały rozpoczęte. Nie powiem więc kiedy, ale było to naprawdę dawno temu. Cała sprawa wyglądała tak, że Borek który Almorę tworzy nieco się już na ten moment wypalił, a do tego pisząc ciągle tylko jedną grę trochę zhermetyzował swoje spojrzenie na niektóre problemy. Dostałem więc tymczasowo Almorę na próbę i przez dwa miesiące uczyłem się jej o rozszerzałem – głównie o lodową krainę, questy i kilka nowych itemów, wczytywanie zasobów z dysku (szybsze ładowanie) i usprawnienia serwera. Widząc jednak ile rzeczy jest źle i nieoptymalnie, na jednym ze spotkań (w Warszawie, przy wódce i przeterminowanych ogórkach) podjęliśmy więc decyzję, że Almora 0.7.6 której początki powstawały jeszcze za czasów GameMakera 5 zostanie przepisana od zera. Przy okazji odświeżymy trochę grafiki.

Wersja TL;DR (bo tekstu jest do czytania na 15 minut) – na dole :)

W międzyczasie moich prac nad 0.7.6, Borek zaczął pracę nad Alien Territory. Niestety tęsknota za Almorą spowodowała, że na boczku robił projekt o nazwie Triberian – miała to być Almora:Online ale w wersji offline :) Podrasował trochę grafiki, rozszerzył model postaci, a jak zacząłem przepisywać Almorę Online od zera do roboczo przyjętej nazwy 0.8, podesłał mi projekt, żebym taką właśnie animację postaci oraz drzew (to była wtedy nowość) wprowadził w nowej grze. Razem z Tymonem przygotowaliśmy system stref (wczytywanie i zwalnianie z pamięci grafik których gra potrzebuje dopiero w grze, a nie razem ze startem, co przyspieszało start gry o dobre pół minuty), zacząłem pisać edytor map i tak na dobre zaczęły się prace (2009).

Gra zaczęła nabierać kształtów, pojawiły się sklepy, NPC, mobki i nawet odbyły się dwa testy z zaproszonymi graczami z GMCLANu. Napisałem też zarąbisty system liczący ile danych wysyła/odbiera gra i przeliczających ile wytrzyma łącze. Oczywiście ilość danych niestety rosła wykładniczo z każdym graczem, bo każdego stworka trzeba było przesyłać każdemu, a każdego gracza i jego akcje do pozostałych. Optymalizowałem to nie wysyłając danych gdy ktoś jest za ekranem. Niestety, były dwa problemy – pierwszy: serwer musi działać na Windowsie; drugi: internet w okolicach roku 2010/2011 miał słabe uploady, więc wyszło mi, że na domowym hostingu uciągnę… koło 20 graczy. Można by wykupić hosting dedykowany z Windowsem, ale trzeba płacić grubą kasę i pojawiał się trzeci problem – serwer prawdopodobnie nie wytrzymałby więcej niż 100 graczy, bo zwyczajnie GameMaker przestałby wyrabiać swoim silnikiem obsługę aż tylko eventów kolizji itp. Pozostały więc dwie opcje – napisać serwer w C++, albo zarzucić projekt. Sam serwer to nie jest jakaś skomplikowana sprawa, ale już odtworzenie systemu przewidywania ruchu i omijana przeszkód który ma GameMaker – mnie to przerastało, a znaleźć kogoś kto napisze to za darmo – nie było raczej za dużej możliwości. Tak więc w 2011 roku zacząłem pracę nad wersją offline gry.

Pod koniec roku 2011 pojawiła się nowa wersja GameMakera na horyzoncie, którą dostałem do testów – GameMaker:Studio. Wprowadzał wiele zmian i optymalizacji do silnika, więc postanowiłem przenieść projekt na tę nową wersję. Ponieważ grafiki w GM:S były pakowane zupełnie inaczej – trafiały na duży altas np. 2048×2048 i wczytywane były do pamięci dopiero gdy potrzeba ich użyć, mogłem porzucić system stref, pakowania zasobów do specjalnego formatu (żeby ich nie kradziono z dysku) i wczytywania zasobów, bo gra działała szybciej natywnie.

Był to więc trzeci raz, gdy zabrałem się za pisanie gry na nowo :) Przez te 3-4 poprzednie lata sporo się też nauczyłem jeśli chodzi o programowanie, sporo nowych rozwiązań wpadło mi do głowy, więc i tak wolałem przepisać szybko kod niż męczyć stary. Dzięki tej wiedzy dostałem też pracę w YoYoGames – które GameMakera produkowało. Mogłem mieć realny wpływ na rozwój programu i rzeczy których mi brakowało, a przydałyby się w grze. YYG jednak niezbyt radziło sobie z raptem czterema czy pięcioma programistami w szybkim rozwoju. To znaczy, owszem, GM:S bardzo się rozwinął, bo z programu który robił gry na Windowsa w połowie 2012 roku mogliśmy eksportować gry na Mac, iOS, Android, HTML5 – ale przez mnogość platform praktycznie nie dodawano nowych funkcji. Winne było też IDE w Delphi które wnerwiało devów masakrycznie (zmieniono je po 17 latach dopiero w listopadzie 2016 roku wraz z betą GameMakerStudio2 !). Nie mniej, zafascynowany możliwością exportu na smartfon i tablety (w 2012 roku było dopiero dwa lata po premierze pierwszego iPada!), postanowiłem, że gra powinna wyjść też na nie, żeby zarobić. Zacząłem więc przerabiać grę tak, żeby przyjemnie się grało na tablecie. Oczywiście oznaczało to pewne cięcia mechaniki. Np. na początku atakowało się uderzając dwoma palcami…

W drugiej połowie 2012 roku gra w końcu zaczynała działać, nawet pojawił się system dialogów, ale pojawił się inny problem – zupełnie niezwiązany z grą. Po wyjeździe do Szkocji, gdzie byłem sam, tęsknota za krajem i bliskimi osobami okazała się zbyt wielka, więc wróciłem do kraju w poszukiwaniu zgubionego szczęścia. Między 2012 a 2014 rokiem przeprowadzałem się blisko 10 razy, a w życiu prywatnym wiele się działo. Nie będę się wdawał w takie szczegóły, ale bywały przerwy 3-4 miesiące gdy nic nie ruszyłem w projekcie. Świetnie to widać na logu z gita (screen po prawej). Czasem siadałem próbując zrobić fajny interfejs do gry, spędzałem 4-5 dni po kilka godzin dopracowując go, a potem wyrzucałem do śmietnika. Tak traciłem całkiem sporo czasu, gdzie nie było postępów nad grą. W przybliżeniu – interfejsów było przynajmniej z 6-7. Wtedy też, pamiętając czasy naszego packera do itemów dla wersji 0.8, oraz edytora do dialogów czy itemów, postanowiłem go przepisać do C#, żeby generował wykresy przyrostu statystyk itp. Ograniczały mnie też mocno możliwości edytora poziomów w GameMaker Studio, więc zacząłem pisać swój własny. Dane w GMS były zapisywane w XML, więc C# całkiem nieźle sobie z tym radził. Część z tych narzędzi wisi nadal na stronie http://gear-studio.com/narzedzia-i-aplikacje/ – jest nawet kod źródłowy (bitbucket), można zobaczyć ile miesięcy ZMARNOWAŁEM na te edytory:

  • Packer do itemów – od 2013 do 2015 roku. Zastąpiłem go wersją w PHP, która generuje mi czysty kod i pozwala na import/export CSV, bo TListView nie wyrabiał w C# gdy miałem 500 itemów i 40 kolumn dla nich – przeglądarka z tabelką robi to z palcem wiadomo gdzie.
  • Edytor map – 2012 do 2016 (!!!!) roku. Wirtualnie dodawał mi warstwy i możliwość obracania w łatwy sposób assetów na mapie (zapisywał je w osobnym XMLu), a potem mergował do formatu GMS. Gdy dostałem jednak betę GameMakerStudio 2 – edytor map z dnia na dzień poszedł w zapomnienie (o czym za chwilę). Więcej razy zmieniałem założenia, niż faktycznie go użyłem.

Nie jest też tak, że Almora to jedyny projekt nad jakim siedzę. Prowadzę dwie strony internetowe – hmt.pl i ps-plus.pl, którym też poświęcam trochę czasu pisząc artykuły i unowocześniając kod strony. One też sporo zjadają. Nie mówiąc o tym, że lubię pograć na PS3, PS4 i paru innych konsolach które mam. W latach 2012 – 2015 sporo czasu odpadło więc głównie przez brak czasu i czasem nastroju do prac nad grą, opracowywanie kolejnego GUI, pisania systemu dialogów w potem wyrzucania go, stracony czas na narzędzia w C#. Ciężko policzyć ile straciłem na te „poboczne” zadania które efektu praktycznie nie dały, ale pewnie z 2-3 miesiące po 8h w plecy jak nic – a pamiętać trzeba, że grę robię tylko w wolnym czasie po 2-3 godziny. Myślę, że z dzisiejszej perspektywy gdybym olał to co nie wyszło i spędził ten czas na dodawaniu zawartości w grze – mielibyśmy już sprawną betę. Do tego w 2016 roku kupiłem dom który trzeba było wykończyć i urodziła mi się córka, a także mieliśmy wesele – więc nawet nie było czasu odpalić komputera w niektóre dni. Ale z drugiej strony teraz w domu ma własne biuro gdzie mogę wieczorami oddawać się Almorze – przez ostatnie miesiące projekt w końcu zaczął się ostro zmieniać.

GameMakerStudio 2 – czyli jak Almora:Origins wróciła na właściwe tory i jest szansa na jej wydanie.

W październiku 2016 gdy zapraszałem Borka na moje wesele, wspomniałem, że albo do wiosny wydam wersję alpha gry, albo zarzucam projekt i oddaję go jemu, a sam albo robię co innego albo kończę z tworzeniem gier. Dosłownie tydzień później dostałem jednak betę GameMakerStudio 2. Przepisane od nowa IDE, nowe funkcjonalności (i niestety porzucenie niektórych starych) – nie mniej zajarałem się straszliwe, zwłaszcza edytorem z layerami (!!!!), który akurat jest skrojony idealnie pod Almorę, gdzie układamy wszystkie rzeczy warstwowo. Ponieważ GMS2 jest częściowo kompatybilny z wersją 1.4, zaimportowałem Almorę, żeby sprawdzić, jak dużo rzeczy trzeba by zmienić, co oczywiście nie było najlepszym pomysłem patrząc na listę zmian.
Wyobraźcie sobie jednak, że GMS2 za usunięte funkcje stara się wprowadzić „zastępcze” skrypty i jakimś cudem, bez zmiany ANI JEDNEJ linijki kodu, gra od razu ruszyła. Wiedziałem więc od razu, że jeśli grę mam wydać, to tylko za pomocą GMS2, bo nawet jeśli miesiąc czy dwa stracę na zmiany w logice kodu, żeby działał z nowymi rozwiązaniami i uciekając od skryptów ratujących kompatybilność, to w końcowym etapie zyskam czas, gdyż porzucę mój nieszczęsny edytor map, któremu wciąż sporo brakowało, a parę innych zmian spowoduje, że mniej będę rzeźbił w kodzie. Co prawda mój termin poddania się na wiosnę odsunąłem przez to w czasie – bo jeszcze parę pomysłów wpadło mi do głowy – ale od czasu wydania GMS2 w 3-4 miesiące w grze dodałem i naprawiłem tyle rzeczy, ile w latach 2014-2015. Dodałem np. ostatecznie działający skrypt dialogów, w którym mogę robić nawet całe cutscenki i zastawiać triggery. Ot, np. obecnie w jakieś 10-15 minut praktycznie bez programowania można napisać questa z 20-30 dialogami i opcjami wyborów, gdzie po drodze trzeba zabić przeciwników (bez ucieczki – gra tworzy okrąg z którego nie można wyjść, więc jest też świetny do bossów) i podjąć odpowiednie decyzje.

Do wersji alpha brakuje mi już tylko sklepu z depozytem, poprawek dodawania/zdejmowania statystyk z przedmiotami, poprawek osi rysowania spritów broni, 2-3 nowych animacji postaci, grafik ekwipunku w nowej wersji (w Almorze:Online postać miała całe ramię, teraz zbroja/ręka/dłoń to trzy osobne grafiki), animacji roślin gdy w nie wejdziemy (Borek zrobił je w Almorze:Darkosen na Androida), dokończenia map, skończenia 3-4 questów i poprawy animacji w cutscenkach, poprawek używania magii przez przeciwników, możliwości walki z NPC-ludźmi, interakcji z drzwiami i poprawek wyświetlania statusów w walce (ilość HP itp.). Liczę zrobić te rzeczy do końca marca i będzie gotowa wersja alpha, w której pozostanie już tylko rozwijanie questów i mechaniki gry (głównie wyważenie itemów/przeciwnków, oraz pacing historii).

No cóż, przez ten czas gdy ja ciągle testowałem/wznawiałem/przepisywałem Almorę na PC próbując jak najlepiej odwzorować to co byśmy chcieli, Borek dał radę praktycznie skończyć wersję na komórki startując z tego samego Triberiana. Zdecydowanie dałem dupy z niektórymi pomysłami i robiłem je niepotrzebnie, trochę czasu też po prostu olewałem projekt – ale zebrałem siły do kupy, jest teraz nowe lepsze narzędzie i za 2-3 miesiące wrócimy jednak do prac w dwójkę, gdyż Borkowi Almora spać nie daje i jednak chce ją dalej robić i kończyć.

Dlaczego przejście na GameMakerStudio 2 tak bardzo się grze opłaci?

Pewnie wiele osób, zwłaszcza tych które śledzą rozwój Almory od początku zastanawia się, czy nie będziemy odkładać wydania gry w nieskończoność, skoro od czasu wersji 0.8.0 przeszliśmy już przez trzy generacje GameMakera – 8.x, Studio 1.4 i teraz Studio 2. No cóż, każdy z nich wprowadzał nowe, przydatne zmiany. Dwójka ma ich tyle, że mimo wycofania kilku rzeczy nadal warto przejść, gdyż Almora nie cierpi na tych brakach, ale zyskuje na nowościach.

  • layery w edytorze poziomów: oczywiście ucieszyłem się, gdy zobaczyłem tę funkcję, bo Almora ma widok z góry i wszystko poukładane jest warstwowo – najpierw trawy, potem drogi, potem krzaki/kamienie, potem płoty, potem NPC/mobki, na wierzch drzewa i dachy domów. Wszystko jest jedno na drugim więc w GMS2 było ciężko tym zarządzać bo żeby coś przesunąć często najpierw musiałem 10 innych rzeczy przesunąć, albo wybrać obiekt z listy – ale jak na mapie jest ich 500 to ciężko to zrobić. Teraz mamy layery, więc wszystko ma swoje miejsce.
    Okazuje się jednak, że w GMS2 warstwy to nie są takie warstwy jak w photoshopie – one zostają po odpaleniu gry! Oznacza to, że mogę je modyfikować już w grze, odwołując się po tej samej nazwie. Layer może zmienić swoją przezroczystość, tryb blendingu, albo zostać całkiem ukryty. Można nawet ustawić dla niego shader! Do tego można dowolnie mieszać kolejnością layery z obiektami, assetami i tłami.
  • assety w edytorze poziomów: GMS2 pozbył się czegoś takiego jak podział na sprite/background – o czym dyskutowałem już w 2012 roku, bo skoro i tak grafiki lądowały na jeden atlas tekstur, to nie widziałem sensu tego podziału. Na szczęście GMS 1.x miał taką funkcję, że jak są dwie identyczne 1:1 grafiki, to na atlasie pakuje je jako jedna grafia i nie ma duplikatu, więc sprytnie to wykorzystywałem, mogąc mieć tła i obiekty z tą samą grafiką :) Ale GMS2 połączył to w jedno, więc oszukiwać nie trzeba. System layerów pozwala jednak na układanie bezpośrednio na ekranie spritów, bez tworzenia z nich obiektów. Gra jest przez to szybsza, bo nie zarządza eventami itp., a sporo grafik w Almorze jest dość statyczna, więc mogę z tego skorzystać. W pracy mam kompa z raptem zintegrowaną karą intela i powiem wam, że o ile w 1024×768 wersja z GMS1.4 miała 20-30 klatek, tak teraz po zmianach dochodzi do 58-60 przez większość gry – więc zmiana jest spora, a ja mogę wepchnąć więcej do gry. Dodatkowy efekt jest taki, że to karta graficzna wyrzuca sprity które są poza ekranem z rysowania, a nie mozolne aktywowane/dezaktywacja obiektów, żeby przetwarzanie kodu nie zabiło gry. Część dla świętego spokoju już nie ruszam, niech jest jak było, szkoda czasu, może po premierze gry je naprawię i zapotymalizuję :)
    W późniejszym etapie myślę nad przeniesieniem cieni na osobne layery assetowe – wtedy cały layer można by rysować zmieniając alpha kanał na 80% i nakładając się cienie nie powinny posiadać zmniejszonej przeźroczystości – co może mieć fajny efekt. Oczywiście cienie będą się tworzyć same – prosta pętla for i dla każdego sprite’a zrobię takiego samego z czarnym blendingiem layer niżej.
  • free deform spritów: tego akurat jeszcze w GMS2 nie ma, ale sobie zamówiłem, a Mike powiedział, że to ekstra pomysł i na pewno fajnie to wprowadzić do GMS2. Na czym to polega ? jak wstawimy sprite, to można by go wyginać w room editorze. Tak wygląda to teraz:
    a tak mogłoby po zmianach (btw. to nowa wersja podziemi w grze, ale jeszcze mocno z placeholderami):
    można by wyginać grafiki i tak do siebie dopasować, że by wyglądały jakby cała mapa była jedną wielgachną grafiką z photoshopa, a tymczasem raptem 2-3 grafiki by ją tworzyły :)
  • zmiany w samym engine:
    • np. działa teraz operator trójargumentowy „?:” (w końcu!!!), który trzylinijkowe if/else zmienia w jedną linijkę – sporo oszczędzonego czasu i kodu. Tablice można wsadzać w tablice, więc przestają być tylko dwuwymiarowe.
    • Wkrótce wszystkie zasoby mają zgłaszać swój własny typ, a nie jak teraz ID w pamięci (więc np. domyślnie room_0 i sprite_0 mają wartość 1, i za cholerę ich nie odróżnisz po przypisaniu do zmiennej). Dzięki temu wszelkie ds_ struktury będą mogły mieć garbage collector tak jak obecnie jest to z tablicami. To by strasznie pomogło, bo można wtedy spokojnie używać hasz-tablic to trzymania zawartości (ds_map / [? ]). Teraz jak stworzysz listę/hasztablicę/grida i go nie usuniesz, a zmienna zniknie wraz z obiektem, to niestety trafiają do limbo i siedzą w pamięci.
    • Wróciły ku mojej uciesze funkcje sprawdzające czy zmienna istnieje :) Almora 0.8.0 w pierwszej wersji ich używała, ale w 2012 roku wraz z GameMaker Studio 1.0 wyleciały. Śmieszne, robię grę tak długo, że je przywrócili :P
    • Jest dziedziczenie poziomów – tzn. można zrobić jeden poziom, a potem kolejny który jakby używa rodzica za tło, więc można nałożyć nowe obiekty. Można sobie wyobrazić np. mapę miasta, gdzie mam drzewa i drogi, ale potem robię dwa poziomy dzieci – jeden z domami, a drugi jak miasto zostało spalone. Oczywiście na siłę mogę zrobić kod który mi to zamieni, ale w wersji z dziedziczeniem mogę dodać sporo innych assetów i zmienić ich położenie.
    • Rysowanie automatycznych tilesetów – można stworzyć tileset, który automatycznie dorysowuje wszystkie rogi naokoło siebie. Tak jak wcześniej każdy dom rysowałem osobno w photoshopie (więc ile domów tyle grafik) – tak teraz mogę szybko rysować ściany, a krawędzie naokoło rysują się same. Cała grafika na wszystkie domy w grze jest mniejsza, niż wcześniej na jeden…

Rozpisałem się, ale mam nadzieję, że teraz wiadomo na czym projekt stoi, że jest przed nim świetlana (oby) przyszłość i za miesiąc/dwa planuję mieć grywalną alphę, w której głównie dodawać będziemy fabułę/grafikę poziomów, a nie kod :)

TL;DR

Opóźnienia związane są głównie z:
– rezygnacją z tworzenia gry online
– przejściem z GameMaker 7/8 na GameMaker:Studio 1.x a potem na GameMaker Studio 2 (to drugie wyjdzie akurat plus)
– pisaniem edytorów map najpierw w GM8 a potem w C#
– pisaniem edytora do itemów w C# trzy razy od nowa
– przepisaniem gry od nowa trzy razy
– młynkiem w prywatnym życiu i przeprowadzkami
– spędzaniem tygodnia nad projektowaniem elementów GUI które potem i tak usuwałem
– bałaganem który przez te lata został (np. są teraz trzy systemy dialogów, z czego dwa równolegle w użyciu…)
– próbą optymalizacji kodu, gdyż na przestrzeni tych lat mimo wszystko nauczyłem się nowych rzeczy a niektóre problemy programistyczne rozwiązać potrafię lepiej

Co dalej?

Grę chciałem wrzucić w okolicach lata na Greenlight na steamie, no ale chyba go zamykają, więc zobaczymy co wyjdzie – najwyżej zrobimy zbiórkę na kickstarterze, jeśli faktycznie będą wołać 5000$ za wydanie gry (ale już bez głosowania).

Chcielibyśmy też razem z Borkiem – bo jednak wciąż jego gra, wydać grę na PS4 i XBOX ONE jeśli będzie się sprzedawać dobrze na PC.

Mam nadzieję, że pod koniec kwietnia / początek maja, zaczniemy coś pokazywać i w grę będzie dało się już nieco pograć. Gra zawierać też będzie nowe grafiki z Darkosena (otoczenie/grafiki), którego Borek kończy i wyda wkrótce na Androidy.

P.S. Postaram się skończyć przed premierą GameMakerStudio 3 :)

6 thoughts on “Dlaczego Almora:Origins powstaje tak długo?

  1. Łukasz Kurowski

    Gra ma niesamowity potencjał. Życzę powodzenia a tak szczerze to marzę, że ujrzę ją kiedyś na GitHubie.

  2. Kowal

    Witam.
    Czy wiadomo coś na temat gry Almora czy projekt został w całości porzucony? :)

  3. Trwają prace, ale ponieważ to jest projekt „hobbystyczny” i robiony w wolnym czasie, to trwa to długo (czasem 10h na tydzień, a czasem 0,5-1h). Ale tyle lat poświęconych nie może się zmarnować :)

Dodaj komentarz