W poprzednim rozdziale Project Nations dostało swój pierwszy świat.
Powstały trzy państwa, piętnaście regionów i pierwsze różnice gospodarcze pomiędzy nimi. Gracz mógł wybrać Nordland, a następnie Lakemont jako miejsce rozpoczęcia gry.
Pozostał jednak ważniejszy problem.
Co właściwie powinno wydarzyć się po tym wyborze?
Nie chciałem, żeby kliknięcie „Rozpocznij w Lakemont” przenosiło gracza bezpośrednio do panelu pełnego przycisków, liczb i systemów, których jeszcze nie zna.
Najpierw trzeba było sprawić, żeby Lakemont przestało być punktem na mapie.
Musiało stać się miejscem.
Ostatni krok przed wejściem do świata
Pierwszym rozwiązaniem był trzeci etap onboardingu.
Po wyborze państwa i miejsca startu gracz trafiał na ekran, na którym nadawał swojej postaci nazwę i otrzymywał podstawowe informacje o rozpoczęciu gry.
Po prawej stronie znajdowało się Lakemont.
Tyle że jeszcze go nie było.
Pierwsza działająca wersja tego ekranu zawierała przygotowane informacje o regionie, jego gospodarce, zasobach i kierunkach rozwoju, ale przestrzeń przeznaczona na samo miasto pozostawała prostym gradientem.
Technicznie ekran działał.
Projektowo czegoś w nim brakowało.
Gracz chwilę wcześniej podejmował decyzję, że właśnie tutaj rozpocznie swoją historię, a aplikacja odpowiadała mu nazwą i zestawem danych.
To było za mało.
W grze opartej na lokalnej gospodarce miejsce nie może istnieć wyłącznie jako wartość zapisana w stanie aplikacji.
Lakemont może być nazwą regionu przekazaną pomiędzy kolejnymi etapami onboardingu. Dla kodu to wystarczy, żeby określić miejsce startu. Dla gracza nie.
Jeżeli później lokalizacja ma wpływać na pracę, handel, magazyny, transport i dostępne zasoby, powinna mieć również własną tożsamość.
Lakemont dostało twarz
Kolejna wersja zachowała praktycznie tę samą strukturę ekranu.
Zmienił się jeden element.
W miejscu gradientu pojawiło się Lakemont.
Miasto otoczone lasami, górami i wodą. Obraz odpowiadający temu, co chwilę wcześniej można było przeczytać na mapie świata.
Ta zmiana nie dodawała nowej mechaniki.
Nie zmieniała gospodarki.
Nie dodawała kolejnej tabeli ani przycisku.
A mimo to zmieniała odbiór całego etapu.
Lakemont przestało być tylko rekordem opisanym przez nazwę, państwo, zasoby i specjalizację. Zaczęło wyglądać jak miejsce, do którego rzeczywiście można wejść.
To stało się ważną zasadą dla dalszego rozwoju projektu.
Ważne miejsca w Project Nations powinny mieć własną wizualną tożsamość.
Nie po to, żeby zastępować mechanikę grafiką, ale żeby gracz mógł powiązać systemy gospodarcze z konkretnym miejscem w świecie.
Ekran to jedno. Stan gry to drugie
W tym momencie pojawiła się też mniej widoczna część pracy.
Pierwsze ekrany Project Nations można było traktować stosunkowo niezależnie. Landing prowadził do onboardingu. Onboarding pozwalał wybrać państwo. Następny krok pozwalał wybrać region.
Teraz wybory zaczynały mieć konsekwencje.
Aplikacja musiała wiedzieć, że gracz nie tylko zakończył onboarding, ale wybrał Nordland, rozpoczyna w Lakemont i posiada konkretną postać.
To istotna różnica.
W zwykłym formularzu dane można zebrać, zapisać i przejść dalej.
W grze te dane stają się częścią stanu świata.
Lokalizacja gracza będzie później potrzebna wielu niezależnym systemom. Rynek musi wiedzieć, w jakim mieście odbywa się handel. Praca musi wiedzieć, jakie oferty są lokalnie dostępne. Magazyn musi mieć określoną lokalizację. Transport istnieje właśnie dlatego, że dwa miejsca nie są tym samym miejscem.
Dlatego wybór Lakemont nie mógł pozostać wyłącznie elementem interfejsu onboardingu.
Musiał zacząć być informacją, na której kolejne części aplikacji będą mogły polegać.
Nie chciałem zaczynać od dashboardu
Najprostsze rozwiązanie było oczywiste.
Po zakończeniu onboardingu można było od razu pokazać główny interfejs gry.
Sidebar.
Saldo.
Pracę.
Rynek.
Magazyn.
Transport.
Postać.
I kilka innych elementów, które z czasem miały pojawić się w Project Nations.
Tylko że właśnie tego chciałem uniknąć.
Jednym z założeń projektu od początku było ograniczenie ilości informacji podawanych nowemu graczowi jednocześnie.
Jeżeli pierwszą rzeczą po utworzeniu postaci byłoby kilkanaście przycisków i nieznanych systemów, cały proces wyboru świata kończyłby się dokładnie tam, gdzie zaczyna się problem wielu rozbudowanych gier przeglądarkowych.
Gracz trafiałby do panelu administracyjnego.
Zamiast do świata.
Potrzebne było przejście pomiędzy tymi dwoma etapami.
„Twoja historia właśnie się rozpoczęła”
Tak powstał ekran wejścia do Lakemont.
Bez tabel.
Bez statystyk.
Bez listy dostępnych systemów.
Na ekranie zostało tylko miasto, nazwa państwa i jeden komunikat:
Twoja historia właśnie się rozpoczęła.
Z punktu widzenia mechaniki ten ekran robi niewiele.
Z punktu widzenia całego procesu wejścia do gry robi coś ważniejszego.
Oddziela tworzenie postaci od właściwej rozgrywki.
Gracz kończy wybieranie.
Od tego momentu znajduje się już w świecie.
Pierwsza granica między onboardingiem a grą
Ten etap był również pierwszym momentem, w którym musiałem wyraźniej rozdzielić dwa stany aplikacji.
Przed wejściem do Lakemont użytkownik przechodzi proces konfiguracji swojej obecności w świecie.
Po wejściu jest już graczem znajdującym się w konkretnej lokalizacji.
To rozróżnienie będzie później miało znaczenie nie tylko dla interfejsu.
Kolejne systemy nie powinny za każdym razem pytać gracza, gdzie się znajduje albo z którego magazynu, rynku czy miasta korzysta. Powinny otrzymywać właściwy kontekst z aktualnego stanu gry.
To jedna z tych rzeczy, których praktycznie nie widać na screenshotach.
Ale wraz z rozwojem aplikacji właśnie takie zależności zaczynają decydować, czy następne systemy można dokładać bez przepisywania poprzednich.
Na tym etapie Project Nations było jeszcze daleko od docelowej architektury.
Po raz pierwszy jednak przestało być tylko sekwencją ekranów.
Zaczynało mieć ciągłość.
Lakemont było gotowe
Kilka godzin wcześniej Lakemont było obszarem zaznaczonym na mapie Nordlandu.
Później dostało własny ekran.
Następnie własny wygląd.
A na końcu stało się miejscem, do którego można było wejść.
To nadal nie oznaczało, że gra była gotowa.
Wręcz przeciwnie.
Po drugiej stronie ekranu wejścia czekał kolejny problem.
Trzeba było zaprojektować przestrzeń, w której gracz będzie spędzał większość czasu i z której będzie korzystał z coraz większej liczby systemów.
Nie pojedynczy ekran.
Interfejs całej gry.
Gra nie jest jeszcze publicznie dostępna. Prezentowane ekrany, mechaniki i rozwiązania mogą zmieniać się wraz z rozwojem projektu. Devlog dokumentuje kolejne etapy powstawania gry.