Small Deity

Zainspirowany przez Startup Weekend Warsaw sprzed dwóch tygodni, postanowiłem, że ten weekend wykorzystam do napisania własnej aplikacji internetowej.

Co robię po weekendach zamiast się opieprzać, jak Bozia przykazała:

Small Deity

Ale może od początku.

Ale o co chodzi?

Czytaliście “Pomniejsze Bóstwa” Terry’ego Pratchetta? To opowieść o bogu, Wielkim Bogu Omie, który objawia się młodemu akolicie swojej religii, chłopcu imieniem Brutha, tylko po to, by zorientować się, że jego wyznawcy już tak naprawdę w niego nie wierzą, a to wiara jest źródłem boskiej mocy i bez wiary Om zostaje uwięziony w ciele małego żółwia stepowego i nie może już wrócić do Nieba.

Pomyślałem, że jest to świetny materiał na grę strategiczną. Gracz jest bogiem i jego zadaniem jest zdobyć jak największą liczbę wyznawców. Zaczyna od objawienia się swojemu pierwszemu prorokowi – czyli jakiemuś pasterzowi, albo rolnikowi – a następnie przez znaki i cuda skłania współplemieńców tego proroka, by w niego, boga, uwierzyli. Wiara tej pierwszej grupki wyznawców zasila pulę mocy boga, dzięki czemu może on powodować dalsze cuda.

Ale oczywiście nie jest znowu tak łatwo. Rzecz dzieje się w starożytności. Mieszkańcy wsi mają problemy z przeżyciem do pierwszego… to znaczy, do kolejnych zbiorów i ani im w głowach jakieś religijne szopki. Pola trzeba obsiać, dzieci przypilnować, dach naprawić… Od czasu do czasu zdarzają się powodzie, trzęsienia ziemi, susze, albo najazdy barbarzyńców. Bóg, jeśli chce zdobyć i utrzymać wyznawców, musi ciągle udowadniać, że tzw. “Zakład Pascala” ma sens i że lepiej w niego wierzyć, niż nie wierzyć. Do tego w okolicy są jeszcze inne, konkurencyjne religie.

I jak to ma działać?

I tu przechodzimy do kwestii technicznych: Po pierwsze, inaczej niż w większości gier strategicznych, gracz nie zajmuje się micromanagementem, czyli nie stawia sam budynków, nie organizuje wojska, nie mówi rolnikom gdzie i ile mają siać. Nawet lepiej – wioska, od której gracz zaczyna, tak naprawdę nie jest jego. W jednej wiosce mogą mieszkać wyznawcy różnych religii. To czym zajmuje się gracz to:

1. Cuda – czyli wszelkie znaki na niebie i ziemi, powstrzymywanie katastrof, wywoływanie katastrof, itp., itd., czyli ogólnie rzeczy dużego kalibru, które mogą, ale nie muszą skłonić ludzi, by w sprawcę tych cudów uwierzyli.
2. Mówienie przez proroków – czyli nakazy i zakazy obowiązujące wyznawców, organizacja religii, oraz tworzenie czegoś w rodzaju “profilu wyznawcy”, opisującego, czy przedstawiciele jego religii są bardziej lub mniej wojowniczy, tolerancyjni, rozwiąźli, i tak dalej. To również przekłada się na popularność religii, oraz ma wpływ na jakość życia w wiosce, ale z jednej strony jest bardziej skomplikowane i działa wolniej – a z drugiej strony jest dużo mniej kosztowne, niż cuda.

Natomiast samo życie wioski jest symulowane przez coś w rodzaju automatu komórkowego. Automat komórkowy, tak pokrótce, to pomysł, zgodnie z którym, symulację można podzielić na pola, każdemu z pól przypisać pewną początkową liczbę, a następnie wyliczać co turę nową wartość, do obliczeń używając jedynie wartości tego pola z poprzedniej tury, oraz wartości z pól sąsiednich. W ten sposób kod programistyczny, który zajmuje się obliczaniem wartości dla jednego tylko pola na planszy nie musi absolutnie nic wiedzieć o reszcie świata – ma tylko swoje poletko, nim się zajmuje, i już. W efekcie jest to automaty komórkowe bardzo ładnie dają się zrównoleglać, albo delegować – to znaczy, możemy dane o takim polu razem z przyległościami wysłać na inny komputer, kazać mu wszystko poobliczać, a potem odebrać wyniki. A komputer, do którego wysyłamy te dane, nie musi nic wiedzieć o całej reszcie gry.

Wioska w mojej grze (która, tak przy okazji, nazywa się tak jak w tytule: “Small Deity”) to właśnie taki automat komórkowy. Ma pewne zmienne, takie jak populacji, stan zdrowia, ilość jedzenia w spichlerzach, oraz ma połączenia z kilkoma innymi, pobliskimi wioskami. Co turę automat wykonuje na niej po kolei pewną sekwencję funkcji, które obliczają nowe wartości tych zmiennych, bazując na innych zmiennych z tej wioski, oraz jej sąsiadów. Na przykład, populacja wioski zależy między innymi od stanu zdrowia (niski stan zdrowia oznacza, że ludzie częściej umierają), od zawartości spichlerzy (ktoś może umrzeć z głodu, ale też być może spichlerze są pełne i można pomyśleć o nowym dziecku), oraz od migracji (być może w innej wiosce mają lepszy stan zdrowia i więcej żarcia i warto się przeprowadzić). W ten sposób populacja w wiosce będzie się zmieniać w dość naturalny, przypominający rzeczywistość sposób, mimo iż automat ma tylko bardzo ograniczoną ilość danych do dyspozycji, oraz dość prosty zestaw obliczeń.

Sam gracz natomiast może wpływać na pewne współczynniki, które z kolei przekładają się na jakość życia. Na przykład, może przemówić przez proroków i nakazać swoim wyznawcom, by częściej się myli. W efekcie stan zdrowia wzrośnie. Albo może wybrać stary, tradycyjny sposób, i wywołać plagę myszy w konkurencyjnej wiosce, przez co ich spichlerze opustoszeją i kierunek migracji odwróci się. Ale trzeba uważać – jakiemuś innemu bóstwu może się to wcale nie spodobać

No dobra, ale jakie narzędzia…

Powiem szczerze: żaden ze mnie web programmer. Mam alergię na XMLa, nienawidzę konfigurowania serwerów, a dyskusje czy jedna technologia o trzyliterowym skrócie jest lepsza od drugiej sprawiają, że chcę wyjść z pokoju. Dla mnie programowanie to nadal wymyślanie nowych rozwiązań, dłubanie w poszukiwaniu lepszych algorytmów, oraz tworzenie czegoś, czego jeszcze nikt do tej pory nie zrobił. Idea zrobienia kolejnego sklepiku internetowego za pomocą złożenia do kupy istniejących już klocków wywołuje u mnie coś w rodzaju mentalnego pawia.

Dlatego poszedłem po najmniejszej linii oporu i wybrałem jedną technologię o trzyliterowym skrócie, którą jeszcze jakoś tam trawię: Google Web Toolkit.

Google przynajmniej nie wymaga ode mnie znajomości pierdyliarda bibliotek i sam załatwia większość nudnych rzeczy. GWT to technologia pozwalająca na budowę strony www wyłącznie w Javie – Google już sam zajmuje się generowaniem HTML’a, CSS’a, JavaScriptu, przesyłaniem danych przez RPC… uff. Ja po prostu piszę w Javie, że chcę mieć tabelkę tu, przycisk tu, a jak kliknę na ten przycisk, to ma się stać to. Reszta mnie nie obchodzi. Dziękuję.

Do tego Google udostępnia własny serwer aplikacji, co oznacza, że jak już napiszę swój startup w Javie to klikam w jedną ikonkę i sruuu, cała aplikacja leci na serwer i od razu jest dostępna dla użytkowników w caluteńkich internetach. Bez żadnej żmudnej konfiguracji.

Do tego jest jeszcze Fusion Tables, również Gugla. Fusion Tables to coś w rodzaju internetowej bazy danych, do której można się podłączyć z dowolnego webappa. I to nie tylko z serwera, ale również z JavaScriptu. Obecnie najczęściej z FT korzystają aplikacje nakładające różne dodatkowe informacje na Google Maps,ale nic nie stoi na przeszkodzie, żeby w takiej tabelce Fusion trzymać dane o wiosce. Automat komórkowy, napisany w GWT i działający po stronie klienta, mógłby ściągnąć te dane (których wcale by tak dużo znowu nie było), wyliczyć wartości dla kolejnej tury, i wysłać aktualizację z powrotem do Fusion Tables. A sam serwer aplikacji jedynie zlecałby zadania.

No i jest jeszcze Google Maps. Mój pierwszy pomysł był taki, by użyć fragmentu mapy świata jako planszy. Z mapy możnaby usunąć większość znaczników, a zamiast nich umieścić własne – czyli ikonki wiosek i dróg między nimi. Niestety, coś jest nie tak na styku Google Maps i GWT. Cały piątek wieczór spędziłem na próbach wyświetlenia mapki i umieszczenia na niej ikonek. Mapka najpierw w ogóle nie chciała się wyświetlać, zdawałoby się zupełnie bez powodu (po jednej kompilacji była, po drugiej już nie), a potem odmówiła współpracy przy podłączaniu zdarzeń pod kliknięcia w ikonki. W końcu stwierdziłem, że to nie ma sensu i w sobotę zaprogramowałem własną planszę, tabelę zbudowaną z 10×10 pól, wypełnionych ikonkami terenu.

Co z tego wyszło

Stan na chwilę obecną (4 grudnia 2012) to główne elementy interfejsu użytkownika – plansza, parę przycisków, miejsce na nagłówek i druga zakładka, w której ma być profil gracza; oraz pod spodem logika pozwalająca mi na łatwe podłączanie kolejnych automatów komórkowych. Na razie działa tylko jedna funkcja, zwiększająca populację na podstawie nadwyżki w żywności, ale cały mechanizm już działa i trzeba tylko dopisać kolejne zmienne i funkcje, by uzyskać symulację życia w wiosce. Na samego gracza przyjdzie czas później.

Uff. To na razie tyle. To był bardzo kreatywny weekend. Czas spać