Po wyborze Lakemont i pierwszym wejściu do miasta Project Nations miało już świat, lokalizację gracza i początek właściwej rozgrywki.
Pojawił się jednak kolejny problem.
Gra ma docelowo składać się z wielu połączonych systemów. Rynek, praca, firmy, magazyny, transport, polityka czy rozwój postaci potrzebują własnych ekranów, ale wszystkie nadal są częścią tego samego świata.
Nie chciałem budować ich jako zbioru niezależnych podstron.
Potrzebowałem wspólnej konstrukcji.
Z ekranu miasta do interfejsu całej gry
Po pierwszym wejściu do Lakemont powstał właściwy ekran miasta.
Lakemont zajmuje jego centralną część. Na panoramie znajdują się miejsca związane z różnymi obszarami rozgrywki. Strefa przemysłowa, centrum, terminal i strefa leśna nie są tylko elementami grafiki. Mają łączyć świat gry z konkretnymi funkcjami.
Wokół miasta pojawiły się elementy wspólne dla całej aplikacji.
Po lewej znajduje się główna nawigacja. Na górze informacje o aktualnej lokalizacji, koncie i walucie. Po prawej przestrzeń na informacje zależne od aktualnej sytuacji. Na dole lokalny chat.
Tak powstała pierwsza wersja GameShella.
Główne systemy gry powinny działać wewnątrz jednej wspólnej konstrukcji interfejsu.
Zmienia się zawartość ekranu, ale gracz nie powinien za każdym razem trafiać do wizualnie innej aplikacji.
Nawigacja przed systemami
W menu pierwszej wersji GameShella znajduje się więcej pozycji niż obecnie działających mechanik.
Miasto. Praca. Rynek. Firmy. Magazyn. Transport. Ratusz. Świat. Postać.
Nie wszystkie te elementy są już gotowe.
Ich obecność pomaga jednak odpowiedzieć na ważne pytanie projektowe: jak przygotować strukturę aplikacji tak, aby dodawanie następnych systemów nie wymagało przebudowy całego interfejsu.
Zamiast projektować każdy ekran jako osobną całość, powstał najpierw szkielet, do którego można podłączać kolejne części gry.
Stałe elementy, zmienna zawartość
GameShell dzieli interfejs na kilka obszarów o różnych zadaniach.
Górny pasek utrzymuje najważniejszy kontekst gracza.
Lewy panel odpowiada za przemieszczanie się pomiędzy głównymi częściami gry.
Środek jest właściwą przestrzenią aktualnego systemu.
Prawa strona może reagować na to, co gracz właśnie robi.
Lokalny chat pozostaje częścią świata niezależnie od otwartego ekranu.
Od strony implementacji oznacza to oddzielenie wspólnej konstrukcji aplikacji od zawartości konkretnych widoków. Elementy takie jak górny pasek, nawigacja czy przestrzeń kontekstowa nie muszą być tworzone ponownie dla każdego ekranu.
To istotne również dlatego, że nie próbuję teraz przewidzieć ostatecznego wyglądu wszystkich przyszłych systemów.
GameShell ma dawać im wspólne ramy, a nie narzucać gotową odpowiedź na każdy przyszły problem.
Lakemont ma pozostać miejscem
Stworzenie wspólnego interfejsu niesie też pewne ryzyko.
Gra ekonomiczna bardzo łatwo może zamienić się w panel administracyjny. Menu po lewej, liczby w środku, kilka tabel i przyciski.
Tego chcę uniknąć.
Lakemont ma znaczenie nie tylko jako wartość zapisana przy postaci. Gracz powinien czuć, że znajduje się w konkretnym mieście.
Dlatego głównym ekranem nie została lista dostępnych funkcji.
Zostało nim samo Lakemont.
Na panoramie miasta znajdują się punkty prowadzące do jego obszarów. Strefa przemysłowa kojarzy produkcję, magazyny i pracę. Terminal transport, logistykę i handel. Centrum ratusz, rynek i usługi. Strefa leśna surowce, pracę i naturę.
Nie wszystkie związane z nimi mechaniki już istnieją.
Powstaje natomiast wizualny związek pomiędzy miejscem a systemami, które mają w nim funkcjonować.
Im więcej funkcji dostaje gra ekonomiczna, tym łatwiej zamienić jej interfejs w zestaw tabel i formularzy.
W Project Nations mechaniki mają być osadzone w świecie. Interfejs powinien pomagać obsługiwać symulację, ale nie może całkowicie zastąpić poczucia miejsca.
Nie wszystko musi być widoczne jednocześnie
GameShell rozwiązuje problem miejsca dla wielu systemów, ale tworzy następny.
Skoro aplikacja może zawierać tak dużo informacji, ile z nich powinno znajdować się przed graczem jednocześnie?
Saldo, produkcja, magazyny, ceny, transport, zadania, aktywność innych graczy i kolejne statystyki mogą być ważne. Pokazanie ich wszystkich naraz nie sprawi jednak, że interfejs stanie się bardziej użyteczny.
Dlatego przyjmuję prostą zasadę.
Ekran powinien przede wszystkim pomagać w wykonaniu aktualnej czynności.
Pozostałe informacje mogą pojawiać się wtedy, gdy są potrzebne.
Pierwsza wersja GameShella nie jest ostatecznym rozwiązaniem tego problemu. Jest szkieletem, na którym można sprawdzać tę zasadę podczas tworzenia kolejnych funkcji.
Pierwszy test wspólnej konstrukcji
Pierwszym systemem, który można osadzić w GameShellu, jest praca.
Po przejściu z miasta do Giełdy Pracy centralna zawartość może zostać zastąpiona listą ofert. Nie ma przy tym potrzeby budowania osobnego interfejsu całej aplikacji.
Pozostaje ten sam górny pasek.
Pozostaje nawigacja.
Pozostaje przestrzeń kontekstowa.
Pozostaje lokalny chat.
Zmienia się to, czym gracz aktualnie się zajmuje.
To właśnie zadanie GameShella.
Pierwsze wejście do Lakemont stworzyło miejsce dla gracza w świecie.
GameShell tworzy miejsce dla systemów, z których ten świat będzie zbudowany.
Szkielet właściwej gry
Na początku Project Nations było zbiorem zasad określających, czym właściwie ma być ta gra.
Później pojawił się pierwszy działający ekran, świat, wybór Lakemont i możliwość wejścia do miasta.
Teraz potrzebna jest konstrukcja, która pozwoli przejść od pojedynczych ekranów do rozwijającej się aplikacji.
GameShell jest pierwszą odpowiedzią na ten problem.
Nie musi być ostateczny.
Nie musi już teraz przewidywać wszystkich funkcji.
Ma zapewnić wspólną strukturę i pozwolić rozwijać kolejne systemy bez zamieniania Project Nations w zbiór niezależnych paneli.
Pierwszy z tych systemów jest już na horyzoncie.
Praca.
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.