System zarządzający grami programistycznymi Meridius

Transkrypt

1 Uniwersytet Wrocławski Wydział Matematyki i Informatyki Instytut Informatyki Praca magisterska Jakub Kowalski Marek Kembrowski System zarządzający grami programistycznymi Meridius Promotor: Prof. dr hab. Krzysztof Loryś Wrocław 2011

2

3 University of Wrocław Faculty of Mathematics and Computer Science Institute of Computer Science Master of Science Thesis Jakub Kowalski Marek Kembrowski Programming games management system Meridius Supervisor: Prof. Krzysztof Loryś, PhD Wrocław 2011

4

5 Dziękujemy: Profesorowi Krzysztofowi Lorysiowi, za akceptację tematu pracy i patronat nad rozwojem systemu; Pawłowi Zalewskiemu, za wsparcie merytoryczne i techniczne; Bartoszowi Doleckiemu, za stworzenie aplikacji Turnip. Jakub Kowalski Marek Kembrowski

6 Dla Osoby, która podarowała mi życie i wrażliwość na imponderabilia. Otworzyła oczy na świat, wspierała w realizacji marzeń i cierpliwie pokazywała jak co dnia stawać się lepszym człowiekiem. Jakub Kowalski Moją pracę magisterską dedykuję moim ukochanym Rodzicom Państwu Jolancie i Cezaremu Kembrowskim. Marek Kembrowski

7 Spis treści 1 Wstęp 9 2 Wprowadzenie do tematyki gier programistycznych Terminologia Przykładowe gry programistyczne Core War A.I. Wars (The Insect Mind) CeeBot Turnieje programistyczne i gier manualnych Sphere Online Judge (SPOJ) Internetowy Turniej Programów Walczących (ITPW) IEEE Conference on Computational Intelligence and Games Competitions Kurnik Opis systemu Sposób użytkowania Gry programistyczne Funkcjonalności gier programistycznych Boty Wizualizacja rozgrywek Gra manualna Architektura Podstawowe założenia Model obiektowy Implementacje logik gier Przebieg pojedynczej rozgrywki Komunikacja Aplikacje zewnętrzne Virtual Safe Slots i Proxy Turnip wizualizacja oraz gra manualna Testy i organizacja pracy Alternatywne rozwiązania i potencjalne rozszerzenia Testowa zawartość systemu 43 7

8 5.1 Gry programistyczne Kółko i krzyżyk Wumpus Skarb Labiryntu Robosseum Języki programowania Boty Interfejs użytkownika Strona główna Tworzenie rozgrywki Wizualizacja rozgrywki Tworzenie zawodnika Szczegóły zawodnika Administracja systemem Instalacja systemu Obsługa panelu administracyjnego Monitorowanie działania systemu Podsumowanie Perspektywy rozwoju projektu Perspektywy wykorzystania systemu Meridius Literatura 62 A Podział pracy 65 B Etymologia nazwy systemu 65 C Schemat bazy danych 66 D Porównanie algorytmów botów 68 D.1 Wumpus D.1.1 Opis algorytmu D.1.2 Przedstawienie wyników D.2 Skarb Labiryntu D.2.1 Opisy algorytmów D.2.2 Przedstawienie wyników

9 1 Wstęp Gry programistyczne to rodzaj gier komputerowych, w których gracz może wpływać na świat gry za pośrednictwem napisanych przez siebie programów. Do tworzenia programów wykorzystywane są różne języki programowania, często specjalizowane, stworzone na potrzeby danej gry. Gry programistyczne nadzorują wykonanie programu gracza i udostępniają protokół komunikacji pomiędzy uruchamianym programem a światem gry. Rozgrywka polega na uruchomieniu algorytmu wykonującego akcje, analogiczne do tych, jakie w standardowych grach komputerowych są wykonywane bezpośrednio przez graczy. Historia gier programistycznych rozpoczyna się w 1961 roku od gry Darwin ([40, 25]), w której celem programów graczy była walka o przetrwanie polegająca na reprodukcji własnego kodu oraz niszczeniu kodu przeciwników. Od tego czasu powstało wiele gier programistycznych rozwijających koncepcję walki pomiędzy cyfrowymi organizmami oraz adaptujących gry komputerowe rozmaitych gatunków. Gry programistyczne były tworzone głównie jako rozrywka dla informatyków oraz w celach dydaktycznych jako pomoc do nauki programowania. Z powodu wąskiego grona odbiorców są one niszową kategorią gier komputerowych i powstałe gry mają najczęściej charakter produkcji niekomercyjnych, tworzonych przez pasjonatów dla pasjonatów. Meridius jest środowiskiem zarządzającym grami programistycznymi, czyli systemem udostępniającym graczom wiele gier opartych na wspólnym schemacie i posiadających spójny interfejs gracza. Obsługa rozszerzalnego zbioru gier programistycznych realizowana jest poprzez traktowanie pojedynczej gry jako programu, który określa zasady rozgrywki, pozostawiając systemowi zarządzającemu wymuszenie ich przestrzegania przez graczy. Zarządzanie grami programistycznymi oznacza więc nadzorowanie zarówno wykonania programów graczy jak i programów gier, a także zapewnienie komunikacji pomiędzy tymi elementami. Idea systemu w spójny sposób zarządzającego grami programistycznymi zrodziła się z obserwacji niedogodności, jakie bardzo często mają użytkownicy gier programistycznych. Powszechne, zwłaszcza przy rozbudowanych grach, są problemy z ich instalacją i uruchomieniem. Do prawidłowego działania taka gra potrzebuje zainstalowania i często pracochłonnej konfiguracji dodatkowych komponentów: bibliotek, kompilatorów, środowisk programistycznych, itp. Każda z gier programistycznych zapewnia te same podstawowe funkcjonalności (obsługę języka programowania, bezpieczne uruchomienie programów graczy i ich testowanie, wizualizację rozgrywki), jednak ich realizacja jest całkowicie odmienna przez co gracz zmuszony jest do nauki mechanizmów każdej gry z osobna. Dodatkowe, dostrzeżone przez nas, czynniki zniechęcające potencjalnych graczy to wysoki stopień skomplikowania zasad gier oraz potencjalne niebezpieczeństwo uruchamiania na swoim komputerze programów innych graczy. Istotną niedogodnością dla graczy jest niemożność bezpośredniej gry przeciw programowi, która to funkcjonalność jest podstawowa we wszystkich grach komputerowych innych rodzajów. Do tej pory nie zaprojektowano systemu, który automatycznie udostępniłby obsługiwanym grom programistycznym wymienione w poprzednim akapicie funkcjonalności, upraszczając proces tworzenia samej gry i zapewniając użytkownikom jednolity sposób rozgrywki. Stworzenie takiego środowiska i umożliwienie korzystania z niego przez Internet (na wzór portali z zadaniami programistycznymi) bez potrzeby instalowania żadnego oprogramowania, z funkcją bezpiecznego uruchamiania programów na serwerze i umożliwieniem bezpośredniej gry człowieka wprowadza nową jakość i otwiera nowy kierunek rozwoju w tworzeniu gier programistycznych. Zaprezentowana w tym dokumencie wersja systemu Meridius realizuje opisaną w poprzednim akapicie specyfikację. Środowisko zostało skonstruowane tak, aby móc współpracować z różnymi interfejsami użytkownika, systemami zapewniającymi bezpieczne uruchamianie programów oraz systemami odpowiedzialnymi za wizualizację rozgrywek. Elementy te nie wchodzą bezpośred- 9

10 nio w skład Meridiusa. Interfejs użytkownika zrealizowany został w przykładowej formie jako strona internetowa. Natomiast wizualizacja i bezpieczne uruchamianie są realizowane przez zewnętrzne aplikacje. W celu prezentacji możliwości systemu do pracy dołączone zostały również przykładowe gry programistyczne wraz z programami graczy. Ten dokument pozwala na zapoznanie się z tematyką gier programistycznych, budową i działaniem systemu Meridius oraz dodatkowymi, dołączonymi do niego składnikami. W rozdziale 2 wprowadzamy terminologię wykorzystywaną w grach programistycznych oraz opisujemy kilka przykładowych gier programistycznych i innych systemów udostępniających funkcjonalności pokrywające się z Meridiusem. W rozdziale 3 przedstawiamy zasady działania Meridiusa i zastosowane w nim rozwiązania, abstrahując od aspektów technicznych. Wprowadzamy je w rozdziale 4 opisującym architekturę systemu oraz wykorzystane technologie. Rozdział 5 przedstawia elementy nie należące do systemu, ale stworzone w celu jego przetestowania i prezentacji możliwości. Omówiona jest obsługa strony internetowej stanowiącej interfejs użytkownika, zasady zaimplementowanych gier programistycznych, a także spis obsługiwanych przez system języków programowania. Rozdział 6 omawia instalację systemu oraz jego konfigurację za pośrednictwem aplikacji zarządzającej. Po podsumowaniu w rozdziale 7, znajduje się załącznik A określający podział prac nad systemem pomiędzy autorów projektu. Z kolei w załączniku B przedstawiamy pochodzenie nazwy systemu. Dalsze załączniki zawierają: C schemat wykorzystywanej przez system bazy danych i D wyniki rozgrywek pomiędzy stworzonymi na użytek testów systemu programami graczy. 2 Wprowadzenie do tematyki gier programistycznych Gry programistyczne powstały dokładnie pół wieku temu jako forma rozrywki dla informatyków i funkcję tę z powodzeniem spełniają do dziś. Jednak oprócz rozrywki znalazły one zastosowanie również w innych dziedzinach. Gry programistyczne wykorzystywane są w edukacji jako pomoce przy nauce programowania, implementują środowiska dla cyfrowych organizmów w projektach związanych z symulacją sztucznego życia, a także stanowią pole do badań naukowych w dziedzinie zastosowań algorytmów sztucznej i obliczeniowej inteligencji. Obszerną listę gier programistycznych wraz z ich krótkimi opisami oraz odnośnikami do opisujących je materiałów można znaleźć na stronie internetowej Programming Games Wiki ([27]). Aby przybliżyć Czytelnikowi ten specyficzny rodzaj gry komputerowej, dokonamy jego szkicowej analizy pod kątem kluczowych dla graczy aspektów rozgrywki. Podstawową cechą rozróżniającą gry jest ich przynależność gatunkowa, związana z rolą jaka wyznaczana jest graczom i pośrednio z fabułą gry. Pierwsze gry programistyczne umieszczały programy graczy w wirtualnych komputerach i symulowały ich wykonanie. Celem każdego programu było wyeliminowanie wszystkich kopii programów przeciwników, najczęściej przez zamazanie obszarów pamięci zawierających ich kod. Z czasem, ewolucja zasad tego typu gier doprowadziła do uformowania najbardziej powszechnego gatunku gier programistycznych walk robotów. W grach tych programiści definiują algorytmy określające zachowanie pewnych obiektów (robotów, czołgów, statków kosmicznych, itp.), których celem jest wyśledzenie i zniszczenie przeciwnika. Walki robotów są atrakcyjne dla twórców gier ze względu na prostotę implementacji zasad oraz dużą dowolność kreacji świata gry. Natomiast z punktu widzenia graczy, na ich atrakcyjność wpływa występowanie wyraźnego czynnika rywalizacji, prostota przedstawionego celu gry i możliwość tworzenia rozbudowanych strategii nawet do gier o nieskomplikowanych zasadach. Jednak gry programistyczne mogą należeć do dowolnego gatunku specyficznego dla gier komputerowych. Najczęściej, poza walkami robotów, implementowane są wyścigi samochodowe, gry planszowe i logiczne oraz gry strategiczne. Niektóre gry programistyczne powstały nie jako samodzielne projekty, lecz wykorzystują komercyjne gry komputerowe, umożliwiając pisanie grających w nie programów. 10

11 O grach tych wspominamy szerzej w dalszej części tego rozdziału. Drugim determinującym grę programistyczną czynnikiem, nie istniejącym w przypadku standardowych gier komputerowych, jest sposób realizacji programów graczy. Zagadnienie to ma kluczowy wpływ na rozgrywkę i najczęściej stosowanych jest kilka rozwiązań, które omówimy rozpoczynając od najpopularniejszych. W najczęściej spotykanej sytuacji twórcy gry definiują własny język programowania, specjalizowany dla ich produktu. Stworzone przez graczy programy są wtedy interpretowane bezpośrednio przez grę programistyczną, co daje pełną kontrolę nad wykonaniem kodu źródłowego, a tym samym pełną gwarancję bezpieczeństwa. W innym przypadku twórcy gry wykorzystują jeden lub kilka istniejących języków programowania, tworząc do nich biblioteki umożliwiające komunikację z grą programistyczną. Programy graczy wywoływane są jako biblioteki lub obiekty implementujące pewne klasy bezpośrednio przez grę programistyczną. Sposób ten jest wygodny dla graczy, jednak często nie daje gwarancji bezpieczeństwa. Ostatnie stosowane rozwiązanie określa komunikację z grą w sposób niezależny od języka programowania, np. poprzez wykorzystanie sieci lub potoków procesowych. Jeżeli programy graczy uruchamiane są na ich komputerach, pozwala to na zastosowanie każdego języka programowania, ale nie zapewnia ochrony przed płynącymi ze strony tych programów zagrożeniami. Jeżeli gra posiada serwer, na którym uruchamiane są programy graczy, bezpieczeństwo jest pełne. Ograniczona zostaje jednak swoboda wyboru języka programowania, który musi należeć do jednego z języków obsługiwanych przez ten serwer. Przedstawioną powyżej charakterystykę gier programistycznych w dalszej części tego rozdziału uzupełniamy szczegółowym opisem kilku gier. Tak, aby Czytelnik, zapoznając się z zastosowanymi w systemie Meridius rozwiązaniami, dysponował odpowiednimi punktami odniesienia. Opisujemy również systemy zarządzające turniejami gier programistycznych i komputerowych, których cechy, istotne z punktu widzenia konstrukcji Meridiusa, będziemy przyrównywali do opisanej w kolejnych rozdziałach implementacji. Najpierw jednak zdefiniujemy pojęcia, powszechnie wykorzystywane w związku z grami programistycznymi, niezbędne do zrozumienia dalszej części tej pracy. 2.1 Terminologia Niektóre używane w pracy terminy mogą nie być Czytelnikowi znane lub też ich znaczenie w kontekście tej pracy może się różnić od ogólnie przyjętego. Ponieważ założyliśmy, że Czytelnik zna podstawowe pojęcia związane z programowaniem i technologiami informatycznymi, zdefiniowane zostały jedynie terminy dotyczące bezpośrednio gier programistycznych. Bot, robot, program bota, program gracza, program walczący, wojownik program stworzony przez gracza i wpływający na świat gry; zazwyczaj implementuje algorytm określający sposób zachowania występującego w grze zawodnika. Debug, tryb testowy, tryb debug proces wspomagający wykrywanie błędów w programie bota w trakcie jego działania. Gra manualna, bezpośrednia gra człowieka bezpośrednia gra użytkownika nie wymagająca pisania programu bota. Interfejs programistyczny mechanizm umożliwiający komunikację pomiędzy logiką gry a pisanymi przez graczy botami. Logika gry, program logiki, program gry program definiujący zasady gry i kontrolujący jej przebieg. Parametry startowe, parametry gry wymagany przez zasady gry zbiór parametrów, którym przed rozpoczęciem każdej rozgrywki muszą zostać przypisane wartości. 11

12 Rozgrywka, mecz zamknięty fragment gry, rozgrywany pomiędzy ustalonymi wcześniej graczami i zakończony określeniem wyniku każdego z tych graczy. Tryb gry wariant zasad rozgrywki. Typ bota, rodzaj bota określa rolę bota w grze, a tym samym dotyczące go reguły; służy rozróżnianiu zawodników, których obowiązują odrębne zasady rozgrywki. Wizualizacja rozgrywki graficzne przedstawienie przebiegu rozgrywki. 2.2 Przykładowe gry programistyczne Opis klasy gier obsługiwanych przez system Meridius, przedstawiony w rozdziale trzecim, odnosi się do budowy istniejących gier programistycznych i możliwości przez nie oferowanych. Wybraliśmy subiektywnie kilka gier, z którymi porównanie wydało nam się najbardziej wartościowe i które w jak największym stopniu pokrywają spektrum stworzonych dotychczas projektów. Grę Core War, która stała się inspiracją dla twórców pierwszych wirusów komputerowych; rozbudowane walki insektopodobnych robotów A.I. Wars (The Insect Mind) oraz stworzoną w formie kursu, do realizacji na lekcjach informatyki, grę edukacyjną CeeBot4. Są to gry reprezentujące różne gatunki, o diametralnie innych założeniach i stworzone przy użyciu odmiennych technologii, a równocześnie jedne z najbardziej popularnych i dopracowanych gier programistycznych w historii Core War Core War (pl. Wojny Rdzeniowe) jest to gra programistyczna, w której boty napisane w Redcode, opartym na assemblerze języku programowania, walczą ze sobą w pamięci wirtualnego komputera nazwanego MARS (ang. Memory Array Redcode Simulator). Celem każdego bota (określanego w nomenklaturze Core War wojownikiem) jest wyeliminowanie wszystkich pozostałych programów i objęcie niepodzielnej władzy nad komputerem. Zasady Wojen Rdzeniowych zostały po raz pierwszy przedstawione szerszej publiczności w maju 1984 roku, kiedy to profesor Alexander Keewatin Dewdney, twórca Core War, opisał tę grę w czasopiśmie Scientific American[2]. Pomysł zyskał zainteresowanie. W ciągu kilku kolejnych lat pojawiły się pierwsze implementacje MARS i poświęcone Core War biuletyny. Zostało założone Międzynarodowe Stowarzyszenie Wojen Rdzeniowych (ang. ICWS International Core Wars Society), które zdefiniowało oficjalny standard języka Redcode. Rozpoczęto również rozgrywanie oficjalnych turniejów pod patronatem ICWS. Obecnie, ponad 25 lat po powstaniu gry, Wojny Rdzeniowe wciąż się rozwijają. Nadal rozgrywane są turnieje ([9, 33]), istnieją też liczne poświęcone grze strony internetowe (np. [22, 34]). Wykorzystywany w Core War język Redcode został skonstruowany tak, aby zapewnić zarówno wygodę jak i prostotę gry. Obecnie nie jest on już rozwijany. Dotychczas powstały trzy standardy Redcode: w latach 1986, 1988 ([7]) i 1994 ([6]). Zgodnie ze standardem ICWS-88 posiada on jedynie 10 instrukcji (zbiór ten został rozszerzony do 18 w Redcode 94). Każda instrukcja (zwana też rozkazem) składa się z trzyliterowego kodu i dwóch pól numerycznych zawierających argumenty, wraz z przypisanymi im trybami adresowania (podstawowe to: natychmiastowy, bezpośredni, pośredni). W Redcode wszystkie adresy są traktowane jako względne (offset od aktualnej pozycji). Ponieważ pamięć w MARS ma formę pierścienia (adresowanie jest cykliczne), wszystkie adresy są prawidłowe, a do ich wyliczania stosuje się arytmetykę modulo wielkość pamięci. Dostępny zbiór instrukcji Redcode pozwala na przechowywanie danych (rozkaz DAT), kopiowanie komórek (MOV), porównywanie ich zawartości, skoki warunkowe i bezwarunkowe, działania arytmetyczne 12

13 (ADD, SUB, itd.) oraz zawiera specjalny rozkaz SPL tworzący nowy proces. Specyfikacja Redcode 94 wprowadza dodatkowo prywatną przestrzeń (tzw. P-space), pozwalającą wojownikom na przechowywanie danych, które nie mogą zostać zamazane przez przeciwników. Na początku rozgrywki, kody źródłowe wszystkich wojowników umieszczane są bezpośrednio w pamięci wirtualnego komputera, w pewnej (zazwyczaj losowej) odległości od siebie. Każdy program ma swój własny proces, w ramach którego wywoływane są jego kolejne instrukcje. Programy mogą zmieniać miejsce swojego wykonania, wykonywać obliczenia, nadpisywać dowolne komórki pamięci oraz tworzyć nowe procesy. MARS rozdziela czas procesora równo pomiędzy każdego z wojowników, więc im więcej procesów stworzył bot, tym wolniejsze jest wykonanie każdego z nich. Proces kończy działanie jeśli wykona operację dzielenia przez 0 lub w zajmowanej przez niego komórce pamięci będzie się znajdował rozkaz DAT. Wojownik przegrywa, jeżeli nie pozostaną mu żadne aktywne procesy. Na rysunku 1 pokazana jest pamięć MARS-a w trakcie rozgrywki pomiędzy kilkoma wojownikami. Rysunek 1: MARS w trakcie rozgrywki. Widok ogólny oraz kod jednego z wojowników. Gra lokalna w Core War jest możliwa za pomocą programów implementujących MARS-a (najpopularniejsze to pmars i CoreWin). Symulatory te pozwalają na grę pomiędzy posiadanymi przez użytkownika botami. Na szczęście specyfika środowiska Core War jest taka, że większość wojowników jest publicznie dostępna, a więc można je pobrać i wykorzystywać do własnych rozgrywek. Turnieje w Core War odbywają się na serwerach internetowych, na których znajdują się tzw. wzgórza (ang. hills). Poszczególne wzgórza różnią się między sobą ustawieniami (obowiązującym standardem języka, wielkością procesora, ograniczeniem na liczbę procesów, itd.) oraz reprezentowanym poziomem, np. istnieją wzgórza dla początkujących. Na wzgórzu znajduje się dwudziestu najlepszych wojowników, którzy przyjmują wyzwania od pretendentów. W momencie wyzwania toczone są pojedynki każdy z każdym. Wojownik, który uzyskał najgorszy wynik schodzi pokonany, a na wzgórzu znajduje się aktualnie najlepsza dwudziestka. Bot, który uzyskał najlepszy rezultat ogłaszany jest Królem wzgórza (ang. King of the Hill). O statusie wojownika świadczy jego wiek, liczony jako liczba przeżytych wyzwań (w całej historii Core War, jedynie kilka programów przekroczyło wiek 2000). Ciekawa analiza losów jednego z najbardziej 13

14 popularnych wzgórz znajduje się w [5]. Jednym ze skutków upubliczniania wojowników jest powszechna debata nad możliwymi algorytmami botów. Większość biuletynów poświęconych Core War, oprócz przedstawiania sytuacji na najbardziej popularnych wzgórzach, zajmuje się właśnie analizą strategii różnych wojowników. Dzięki tym czynnikom powstało wiele ciekawych taktyk i sztuka tworzenia botów rozwinęła się bardzo szybko. Podstawą do dalszych rozważań stał się podział na kategorie wojowników, między którymi występują zależności takie jak w grze kamień-papier-nożyce[23]. Kamieniem (lub inaczej bomberem) określa się program, którego metodą walki jest systematyczny ostrzał pamięci przy użyciu pocisków, rozumianych zazwyczaj jako komendy DAT. Trafienie, czyli nadpisanie kodu wykorzystywanego przez przeciwnika, skutkuje wykonaniem przez niego niedozwolonej operacji i zakończeniem procesu. Kamienie bardzo często są małe (a więc trudno je zlokalizować) i szybkie. Przykładowy bomber Dwarf (drugi opublikowany wojownik w historii Core War, opisany szczegółowo w [2]), który ostrzeliwuje co piątą komórkę pamięci, składa się jedynie z 4 rozkazów i wygląda następująco: 001: DAT -1 ; Przechowuje adres komórki - celu bombardowania 002: ADD #5-1 ; Zwieksza zawartość poprzedniej komórki o 5 003: MOV ; Nadpisuje komórkę, której adres znajduje się ; w komórce 001, rozkazem DAT 0 004: JMP -2 ; Skacze do komórki 002 Papierem, a więc wojownikiem bardzo skutecznym przeciwko bomberom jest replikator. Strategia takiego wojownika opiera się na kopiowaniu swojego kodu w inne miejscu pamięci i stworzeniu procesu, który będzie go wykonywał. Tak przygotowana kopia będzie działała analogicznie tworząc własną kopię, która stworzy kolejną kopię, itd. Papiery są ciężkie do wyeliminowania, ale często mają problem z przeprowadzeniem skutecznego ataku. Nożycami w tej nomenklaturze są skanery oraz wampiry, stworzone z myślą o pokonywaniu replikatorów. Strategia tych wojowników polega na spowolnieniu przeciwników, poprzez zmuszenie ich do wykonania wielu instrukcji SPL i tworzenia bezużytecznych procesów. Skanery przeprowadzają ataki nakierowane, starając się wcześniej wykryć miejsca gdzie znajdują się wrogie programy. Wampiry zazwyczaj bombardują pamięć instrukcjami skoku, przenoszącymi przeciwników do specjalnie skonstruowanej jamy, która najpierw ich spowolni, a następnie zniszczy. Nożyce są zazwyczaj długimi i złożonymi programami o małej liczbie procesów, przez co mogą zostać łatwo trafione i wyeliminowane przez bombera. Najskuteczniejsi wojownicy łączą opisane wyżej strategie, tworząc bardziej wyspecjalizowane taktyki wzbogacone często o zachowania obronne, nastawione przeciwko konkretnym kategoriom przeciwników. Ciekawym pomysłem, o którym warto wspomnieć są tzw. Core War Evolvers [26, 39]. Programy te (najczęściej wykorzystując algorytmy genetyczne) automatycznie tworzą i rozwijają wojowników A.I. Wars (The Insect Mind) Gra A.I. Wars (The Insect Mind) umożliwia tworzenie algorytmów sztucznej inteligencji przeznaczonych dla insektopodobnych, zmechanizowanych wojowników oraz na rozgrywanie z ich udziałem symulowanych bitew. Programowanie botów (zwanych Cybugami, ang. Cybug) odbywa się w specjalnie skonstruowanym do tego języku programowania CAICL (ang. Cybug A.I. Command Language), konstrukcyjnie przypominającym BASIC. Cybug jest programowalnym, sześcionogim, przypominającym insekta robotem o zaawansowanych możliwościach bojowych. Wyposażony został w system skanerów umożliwiających orientację w otoczeniu oraz zdolność do samoreperacji. Cybug do działania potrzebuje paliwa, 14

15 szybkość zużywania którego zależna jest od stopnia uszkodzenia jednostki. Paliwo przetwarzane jest na energię wykorzystywaną przez systemy elektroniczne, jednostkę napędową, osłonę ukrywającą przed wrogimi skanami oraz system chłodzenia. Istnieją sytuacje, w których przez zbyt długie wykorzystywanie urządzeń takich jak np. generator osłony przed pociskami, system może ulec przegrzaniu, co skutkuje wyłączeniem robota. Na uzbrojenie Cybuga składają się: działko, wyrzutnia rakiet, wyrzutnia granatów oraz stawiacz min. Robot jest w stanie sam wytworzyć pociski do tych broni, pod warunkiem posiadania odpowiedniej ilości prefabrykatu amunicji. Wystrzelenie rakiety lub granatu wymaga dodatkowo zużycia paliwa. Istnieje także możliwość spowodowania kontrolowanego wybuchu energii, raniącego robota oraz wszystkich w jego otoczeniu lub, w ostateczności, dokonania samozniszczenia jednostki. Cybug może zbierać potrzebne mu zasoby (paliwo i amunicję) odzyskując je z pokonanych przeciwników lub transportując przez port zasobów (wymaga zbliżenia jednostek) od innego robota, sojusznika lub wroga (kradnąc). Istnieje także możliwość podłączenia się do portu danych innego Cybuga i wprowadzania komend z zewnątrz, bezpośrednio do jego procesora, co wiąże się z niebezpieczeństwem wrogiego przejęcia kontroli nad jednostką. System rozpoznawania sojuszników pozwala tworzyć drużyny (roje) i zapewnia bezpieczną wymianę informacji pomiędzy członkami jednej drużyny. Podstawowym zadaniem Cybugów jest eliminacja przeciwników. Scenariusze bitew mogą jednak wyznaczać dodatkowe cele: eliminację specjalnego Cybuga określanego jako Królowa i okupację umieszczonego na mapie strategicznego punktu zapewniającego regularne dostawy paliwa i amunicji. Stopień złożoności Cybugów sprawia, że zaprogramowanie dobrej sztucznej inteligencji jest zadaniem skomplikowanym i wymagającym wiedzy na temat niuansów zasad. Procesory robotów wykonują zlecone im polecenia w porcjach określanych jako kliknięcia i wyznaczających jedną turę gry. Koszt wykonania poszczególnych działań różni się między sobą w zależności od ich złożoności, wobec czego kluczowe staje się umiejętne rozdysponowanie kolejności operacji. I tak: akcja poruszenia się lub wykorzystania broni kosztuje jedno pełne kliknięcie, skanowanie 1 3 kliknięcia, natomiast wykonanie linii kodu zawierającej operacje arytmetyczne oraz logiczne wymaga 0.1 kliknięcia. Kod źródłowy Cybuga pisany jest w języku CAICL stworzonym specjalnie na potrzeby gry, co wiąże się zarówno z jego zaletami jak i wadami. Uruchomione programy znajdują się pod ścisłą kontrolą interpretera, co pozwala na precyzyjne obliczanie akcji wykonywanych w czasie jednego kliknięcia. Umożliwia to również bardzo wygodne testowanie bota. W trakcie wizualizacji na bieżąco wyświetlane są podejmowane przez bota działania, natomiast po rozgrywce udostępniany jest zapis wybranych fragmentów wykonanego przez robota kodu, umożliwiając prześledzenie bitwy linijka po linijce. Składnia CAICL jest prosta i w zakres jej poleceń wchodzą akcje Cybuga, operacje arytmetyczne oraz instrukcje warunkowe i skoki. Jednak prostota konstrukcji jest również czynnikiem ograniczającym, np. funkcja generująca liczby losowe zwraca cztery możliwe wartości. Programista ma dostęp jedynie do 72 prostych zmiennych (przechowujących dowolne wartości w tym polecenia języka) o ustalonych nazwach. Nie ma możliwości korzystania z tablic, list, a tym bardziej zdefiniowania własnych struktur danych, np. drzew. Nie jest możliwe zapamiętanie w skuteczny sposób planszy i posługiwanie się np. algorytmami grafowymi w celu wyznaczania ścieżki. Podsumowując, CAICL umożliwia jedynie tworzenie prostych programów, co czyni je bardziej przyjaznymi dla osób nieobeznanych z programowaniem i równocześnie zmusza do prowadzenia wnioskowań w obrębie samych zasad gry, w oderwaniu od standardowych zagadnień algorytmicznych. Gra A.I. Wars dystrybuowana jest w postaci aplikacji, przeznaczonej na systemy z rodziny Windows, pozwalającej na lokalne rozgrywki pomiędzy Cybugami posiadanymi przez użytkownika. Tworząc rozgrywkę można wybrać mapę, ustawić wartości parametrów gry (początkową ilość paliwa i amunicji, wytrzymałość Cybugów, itd.) oraz zmodyfikować niektóre zasady np. nie 15

16 umieszczając na mapie punktu strategicznego lub wyłączając możliwość przegrzania się robota. Zmodyfikowane ustawienia można zapisać w formie scenariuszy, pozwalających na ich późniejsze wykorzystanie. Istnieje także możliwość tworzenia automatycznie rozgrywanych turniejów pomiędzy dużą liczbą botów (do 500). Wizualizacja rozgrywek dostępna jest w trybie tekstowym lub graficznych (rysunek 2): 2D (wyświetlane są wtedy informacje testowe, rozgrywkę można przyspieszać oraz zwalniać) oraz 3D (dostępnych jest kilka ustawień kamery). Przebieg rozgrywki można zapisać w postaci pliku powtórki z możliwością późniejszego odtwarzania. Do aplikacji dołączony jest edytor tekstu wspomagający programowanie w języku CAICL oraz narzędzie do tworzenia map. Rysunek 2: Wizualizacja rozgrywki w 2D oraz 3D Pierwsza wersja gry powstała w 1996 roku, natomiast najnowsza aktualizacja miała miejsce w grudniu roku Pełną wersję A.I. Wars (The Insect Mind) można pobrać za darmo z oficjalnej strony internetowej gry [24]. Znajduje się tam również dużo, stworzonych przez użytkowników, map i botów, które można swobodnie wykorzystywać do gry lokalnej. Twórcy botów publikują swoje Cybugi bez obaw o podglądnięcie ich kodu, dzięki możliwości zabezpieczenia bota hasłem dostępu. To świetne rozwiązanie pozwala na tworzenie rozgrywek z udziałem wszystkich botów, ale już podgląd kodu źródłowego i uruchomienie zabezpieczonych Cybugów w trybie testowym wymagają autoryzacji. Na stronie gry znajdują się również liczne samouczki i porady użytkowników przedstawiające zawiłości programowania Cybugów oraz oficjalny podręcznik zawierający szczegółowe zasady rozgrywki [29] CeeBot4 W grze CeeBot użytkownik wciela się w astronautę, który powierzone mu misje wykonuje za pomocą programowanych przez siebie robotów. W odróżnieniu od omówionych wcześniej gier programistycznych, główny nacisk w CeeBot jest położony nie na rywalizację z innymi użytkownikami, lecz na samodzielną naukę programowania poprzez rozwiązywanie różnorodnych zadań programistycznych. Gracz tworzy programy w wysokopoziomowym, obiektowym języku C-Bot (bardzo podobnym do Javy i C#), który został stworzony specjalnie z myślą o ułatwieniu nauki programowania. Postawione przed graczem zadania mają bardzo różnorodny charakter i wymagają zaprogramowania wielu różnych rodzajów robotów. Roboty wyposażone w chwytaki pozwalają na transportowanie różnych obiektów oraz konstruowanie budynków. Roboty geologiczne pozwalają odnajdować złoża minerałów. Roboty ochronne generują tarczę osłaniającą przyległy teren przed ostrzałem. Pojazdy posiadające zamontowany pisak mogą rysować obrazy, na wzór 16

17 znanego z języka LOGO żółwia. Dostępne są także roboty-samochody oraz pojazdy latające, niektóre dodatkowo uzbrojone co umożliwia im strzelanie do innych jednostek. Większość zadań ma formę ćwiczeń przeznaczonych dla jednego gracza, ale CeeBot wprowadza także dyscypliny, w których rywalizować mogą programy napisane przez różnych graczy. Jedna z dyscyplin to wyścigi samochodów, które pokonują trasy wyznaczone przez znajdujące się na mapie punkty kontrolne. Bardziej zaawansowaną grą z udziałem samochodów jest piłka nożna robotów. Pojazdy poruszają się po boisku i aby skierować piłkę w pożądaną stronę uderzają ją, najeżdżając pod odpowiednim kątem. Celem jest umieszczenie piłki w bramce, otoczonej polem bramkowym, po którym poruszać się może jedynie pojazd-bramkarz. Użytkownik może stworzyć oddzielny program dla każdego z zawodników, co pozwala na zastosowanie zaawansowanych taktyk. Taktyka ma kluczowe znaczenie przy dyscyplinach związanych z walką, w których dwie drużyny uzbrojonych pojazdów starają się zniszczyć wszystkie roboty drużyny przeciwnej. Najbardziej rozbudowana forma rywalizacji pozwala na zaprojektowanie całej strategii rozwoju bazy. Od budowy struktur wydobywczych, elektrowni, fabryk robotów, poprzez zarządzanie przetwarzaniem i transportem surowców oraz produkcją pojazdów, po obronę swojej infrastruktury i atakowanie bazy przeciwnika przy użyciu własnych jednostek bojowych. Dodatkowo, CeeBot4 umożliwia tworzenie własnych zadań [31] i grę w misje przygotowane przez innych użytkowników. Języka programowania C-Bot użytkownik uczy się w trakcie rozgrywki, wykonując zadania ze zbioru oznaczonego jako szkoła programowania. Znajdujące się tam ćwiczenia pozwalają na zapoznanie się z podstawami programowania: korzystaniem ze zmiennych, instrukcjami warunkowymi, pętlami, itp. Gracz uczy się również wydawania robotom poleceń poprzez wywołania odpowiednich funkcji. W dalszej części szkółki ćwiczenia dotyczą bardziej zaawansowanych zagadnień. Omawiane jest definiowane własnych funkcji i klas, obsługa zdarzeń z klawiatury, operacje na plikach oraz przedstawiony zostaje paradygmat programowania obiektowego. Ponieważ CeeBot ma konstrukcję programu edukacyjnego, każde ze znajdujących się w grze zadań posiada instrukcję związaną z jego wykonaniem. Wyjaśnia ona szczegółowo cel zadania oraz podaje wskazówki dotyczące sposobu jego rozwiązania. W przypadku ćwiczeń wprowadzających nowe elementy (instrukcje języka, rodzaj robota, itd.), sposób ich działania jest dodatkowo ilustrowany fragmentami kodu źródłowego. W każdym momencie gry dostępna jest także rozbudowana pomoc programistyczna, zawierająca opisy wszystkich elementów języka wraz z przykładami i szczegółowymi opisami wykorzystania. Język C-Bot jest językiem programowania, którego łatwość nauczenia się wynika przede wszystkim z atrakcyjnej formy nauki, odbywającej się krok po kroku i wspartej dobrą pomocą programu. W rzeczywistości jest to język o zaawansowanych możliwościach i konstrukcji oraz składni zaczerpniętej wprost z komercyjnych języków programowania takich jak C++, Java i C#. Różni się od nich jedynie stopniem rozbudowania swojego modelu obiektowego, systemu typów i biblioteki funkcji. Siła wyrazu tego języka i oferowane przez niego możliwości, pozwalają graczowi na pełną swobodę tworzenia algorytmów sterujących dostępnymi w grze robotami. Proces tworzenia i testowania programów jest wspomagany przez wbudowany w grę i zintegrowany z debugerem edytor kodu. Podpowiada on składnię poleceń i pozwala w prosty sposób uzyskać pomoc dotyczącą każdej wykorzystywanej instrukcji. Uruchomiony program można w każdym momencie spauzować i zmodyfikować jego kod źródłowy. Możliwe jest też wykonywanie instrukcji robota krok po kroku. Edytor podświetla aktualnie wykonywaną przez pojazd instrukcję i pokazuje wartości wszystkich zadeklarowanych w programie zmiennych (rysunek 3). 17

18 Rysunek 3: CeeBot4. Widok kodu źródłowego w trakcie uruchomienia pojazdu. Gra CeeBot4 została stworzona w 2005 roku i jest najbardziej rozbudowanym produktem z serii gier CeeBot, służących do nauki programowania. Poszczególne części serii przeznaczone są dla różnych grup wiekowych różnią się od siebie ilością i stopniem zaawansowania oferowanych zadań programistycznych. Aplikacja gry [30] przeznaczona jest na systemy z rodziny Windows i posiada atrakcyjną, w pełni trójwymiarową oprawę graficzną. CeeBot4 nie jest grą darmową, możliwe jest natomiast pobranie ze strony producenta [32] bezpłatnej wersji demonstracyjnej, udostępniającej jedynie część misji. 2.3 Turnieje programistyczne i gier manualnych Podstawowym zadaniem Meridiusa jest zarządzanie dużą liczbą gier programistycznych i udostępnianie tych gier szerokiemu gronu odbiorców. Punktami odniesienia są w tej materii inne systemy zapewniające podobne usługi. W tej sekcji opisujemy te najbardziej charakterystyczne i popularne, których udostępniane funkcjonalności są zbieżne z założeniami Meridiusa. Jako punkty odniesienia wybraliśmy: zawody gier programistycznych rozgrywane w ramach IEEE Conference on Computational Intelligence and Games, serwis z zadaniami algorytmicznymi Sphere Online Judge, portal z grami online kurnik.pl i turniej gier programistycznych ITPW. Przedstawiamy pokrótce zasady ich działania, najważniejsze cechy oraz sposób w jaki kształtują one dany system oraz jego odbiorców, a także nasze wnioski i spostrzeżenia uczynione pod kątem systemu Meridius Sphere Online Judge (SPOJ) SPOJ[19] jest zbiorem problemów algorytmicznych wraz z serwisem internetowym umożliwiającym ich rozwiązywanie w wielu językach programowania. Dostępne zadania posiadają zróżnicowany stopień trudności: od sprawdzających znajomość podstawowych algorytmów, do zadań występujących na konkursach i olimpiadach informatycznych. Użytkownicy portalu nadsyłają napisane przez siebie programy w postaci kodów źródłowych, które są następnie kompilowane i uruchamiane na wcześniej przygotowanych danych testowych. Za rozwiązane zadania przyznawana jest odpowiednia, zależna od stopnia trudności zadania, liczba punktów. Na tej podstawie prowadzony jest globalny ranking użytkowników. 18

19 Za testowanie rozwiązań odpowiedzialne jest jądro systemu, tzw. silnik SPOJ (ang. SPOJ Engine). Odpowiada on za kompilację, uruchomienie i weryfikację poprawności wysyłanych przez użytkowników programów. Aby rozwiązać dany problem, program musi wczytać dane testowe ze standardowego wejścia i wypisać odpowiednio sformatowane rozwiązanie na standardowe wyjście. Oprócz poprawności wyniku, do zatwierdzenia rozwiązania wymagane jest także zmieszczenie się w zadanych limitach: czasowym, wielkości programu oraz wykorzystywanej przez niego pamięci. Silnik SPOJ używany jest także w innych portalach przeznaczonych dla programistów (np. ideone.com, codechef.com, scarky.com). Sphere Online Judge, ze względu na prostotę obsługi, łatwość rozszerzania przez użytkowników zbioru zadań oraz możliwości silnika, jest wśród programistów bardzo popularny. Portal zawiera ponad zarejestrowanych użytkowników i ponad zadań, które można rozwiązywać w 44 językach programowania. Występuje w kilku wersjach językowych: polskiej, angielskiej, portugalskiej i wietnamskiej. Jest wykorzystywany przez szkoły oraz uczelnie do prowadzenia zajęć dydaktycznych z tematyki programowania i algorytmiki. Zapewnia również wsparcie techniczne innym zawodom programistycznym, w tym Międzynarodowej Olimpiadzie Informatycznej oraz High School Programming League. W kontekście prac nad systemem Meridius, SPOJ pokazuje nam jak istotne jest umożliwienie programistom sprawdzenia swoich umiejętności poprzez konfrontację z postawionymi przed nimi problemami. Zwraca przy tym uwagę na siłę płynącą z wykorzystania przemysłowych języków programowania, a nie zastępowania ich sztucznymi odpowiednikami, jak ma to miejsce w przypadku dużej części gier programistycznych. Dzięki temu, użytkownicy mają poczucie rzeczywistego rozwoju swoich umiejętności. Duże znaczenie ma także aspekt społecznościowy. Zgromadzeni wokół portalu ludzie nawzajem sobie pomagają i uczą się od siebie. Natomiast istnienie rankingu użytkowników wykorzystuje mechanizm rywalizacji i stanowi silny doping do rozwiązywania kolejnych zadań Internetowy Turniej Programów Walczących (ITPW) Internetowy Turniej Programów Walczących polega na napisaniu, w ciągu kilkunastu dni, programu walczącego (bota) grającego w pewną zadaną grę. Każda edycja turnieju rozpoczyna się od ogłoszenia zasad aktualnej gry. Do dyspozycji uczestników zostaje oddana aplikacja, zwana sędzią, pozwalająca lokalnie grać w tę grę i testować swoje boty. Sędzia umożliwia także grę człowieka oraz pełni rolę wizualizacji, tzn. wyświetla przebieg rozgrywek w formie graficznej. Boty można pisać w jednym z kilku popularnych języków programowania. Uczestnik zgłasza program do konkursu przesyłając pliki źródłowe za pośrednictwem strony internetowej. Następuje wtedy jego próbne uruchomienie przeciwko innym botom, pozwalające ocenić twórcy jego poziom. Po czasie przewidzianym przez regulamin konkursu na zaprogramowanie botów, rozgrywany jest turniej. W trakcie turnieju nadesłane programy walczą między sobą w pojedynkach. Zwycięzcą zawodów zostaje uczestnik, którego program zdobędzie największą liczbę punktów. Zasady tworzenia programów walczących są proste. Boty komunikują się z sędzią za pośrednictwem standardowych strumieni wejścia/wyjścia, zgodnie z ustalonym przez grę protokołem. Otrzymują tą drogą informacje o stanie rozgrywki i deklarują swoje posunięcia. Czas, który program ma na rozegranie partii jest ograniczony. W każdej turze gry, sędzia informuje o ilości pozostałego czasu. Boty podlegają jednak kilku istotnym ograniczeniom od strony technicznej. Możliwość wyboru języka programowania jest niewielka (w 2010 roku dostępne były C, C++, Pascal, Java i OCaml). Programy nie mogą tworzyć wątków ani otwierać plików. Istnieje także limit wywołań poleceń systemowych. Zadane gry programistyczne mają stosunkowo proste reguły, są jednak wymagające pod względem napisania dobrze grającego algorytmu. Oprócz gier stworzonych specjalnie na po- 19

20 trzeby ITPW w zawodach wykorzystywane były także znane gry dla ludzi, takie jak gomoku (kółko i krzyżyk na planszy o boku 5) lub karciana gra w planowanie. Wspólną ich cechą jest podział na tury, umożliwiający wygodne zarządzanie komunikacją pomiędzy graczami a sędzią. Gry programistyczne z poprzednich edycji turnieju nie są dalej rozwijane, choć istnieje możliwość nadsyłania do nich rozwiązań w ramach tzw. turnieju stałego. Funkcjonalność ta została uruchomiona stosunkowo niedawno i stanowi raczej ciekawostkę, nie stymulując programistów do ulepszania swoich botów i ciągłej rywalizacji. Internetowy Turniej Programów Walczących organizowany jest co roku przez Koło Naukowe Informatyków Uniwersytetu Warszawskiego. Pierwsza jego edycja miała miejsce w roku Zwycięzcy turnieju otrzymują nagrody fundowane przez sponsorów. Liczba uczestników to zazwyczaj niewiele ponad 100 osób. Wśród nich znajdują się zarówno uczniowie liceów jak i studenci oraz doktoranci. Rozważając jakie cechy ITPW uważamy za istotne z punktu widzenia pracy nad systemem Meridius, zwróciliśmy szczególną uwagę na dwie. Pierwszą jest aplikacja sędziego, która wizualizuje przebieg rozgrywek, wspiera testowanie programów walczących oraz umożliwia, w wygodny sposób, grę człowieka przeciw botom. Udostępnienie tej ostatniej funkcjonalności, rzadko występującej w grach programistycznych, jest jednym z podstawowych założeń Meridiusa. Drugą cechą jest postawienie na różnorodność implementowanych gier programistycznych. W ramach jednego turnieju uczestnicy mają do dyspozycji tylko jedną grę. Natomiast gry będące przedmiotami kolejnych edycji różnią się nie tylko fabularnie, ale też wymagają od uczestników zastosowania odmiennych algorytmów i taktyk. Dzięki temu oraz dzięki odpowiedniemu doborowi poziomu trudności gier, ITPW co roku stanowi wyzwanie dla programistów w różnym wieku i o różnym poziomie umiejętności IEEE Conference on Computational Intelligence and Games Competitions Nieodłączną częścią IEEE Conference on Computational Intelligence and Games [35], corocznej konferencji poświęconej zastosowaniom obliczeniowej sztucznej inteligencji w grach, są zawody gier programistycznych. Zawody składają się z kilku konkursów związanych z konkretnymi grami programistycznymi. Nie wszystkie konkursy polegają na napisaniu najskuteczniejszego gracza. W niektórych przypadkach, celem nadsyłanych programów jest automatyczne tworzenie zawartości gry (np. plansz, na których toczy się rozgrywka) lub symulacja ludzkiego sposobu rozgrywki. Uczestnicy zawodów mają możliwość przesłania artykułu dotyczącego wysłanego przez nich programu, opisującego jego architekturę, wykorzystane algorytmy ideę działania, itd., który jest traktowany jako praca konferencyjna. Po zakończonych zawodach w Internecie umieszczane są podsumowania poszczególnych konkursów, zawierające opisy charakterystycznych cech uczestniczących w nich botów. Umożliwia to porównanie różnych podejść i prześledzenie tendencji w stosowanych przez twórców metodach. Zbiór gier w których rozgrywane są zawody nie jest stały i zawiera zazwyczaj 4 6 pozycji. Niektóre gry pojawiły się w historii zawodów (od 2005 roku) jedynie raz, inne występują regularnie prawie w każdej edycji. Jedną z takich gier jest TORCS - The Open Racing Car Simulator [37], gra, której celem jest napisanie programu biorącego udział w wyścigach samochodowych. Zawodnicy przygotowują swoje boty zarówno do jazdy na pustym torze, jak i do bezpośredniego starcia w wyścigach zbiorowych. Interfejs gry pozwala na oglądanie wyścigów w trójwymiarowym środowisku oraz bezpośrednie sterowanie samochodem przez człowieka. W kolejnej, często występującej na IEEE CIG, grze Mario AI [38], nawiązującej do znanej gry platformowej Mario, rozgrywanych jest kilka konkurencji. Celem podstawowych zawodów jest najsprawniejsze przechodzenie przez boty kolejnych poziomów (plansz). Pozostałe konkurencje obejmują: stworzenie botów jak najlepiej uczących się trasy (ten sam poziom przechodzony jest 1000 razy, punkto- 20

21 wane jest podejście numer 1001), jak najwierniejsze odzwierciedlenie przez bota ludzkiego stylu gry oraz stworzenie programu generującego najciekawsze, z punktu widzenia sędziów, poziomy. Popularną w zawodach grą jest również Ms Pac-Man Screen Capture [20], oparta na klonie gry Pac-Man. W tym przypadku, rozgrywka wymaga specjalnego interfejsu odczytującego stan gry z ekranu komputera i przekazującego polecenia do uruchomionego programu gry. Kolejnym często występującym konkursem jest 2K Bot Prize - a Turing Test for Bots [21], którego celem jest stworzenie bota grającego ludzkim stylem w gry typu FPS (ang. First Person Shooter). Do zawodów tych wykorzystywany jest moduł do gry Unreal Tournament 2004, pozwalający na programowanie własnych zawodników. Ciekawy konkurs, rozgrywany od 2010 roku, związany jest ze strategiczną grą czasu rzeczywistego StarCraft [4]. Umożliwia on stworzenie programu grającego w pełną wersję znanej gry komputerowej, przy czym ze względu na stopień złożoności rozgrywki, dostępne są także kategorie, w których zasady gry ulegają znacznemu uproszczeniu. Zawody skierowane są głównie do studentów i naukowców zajmujących się dziedziną sztucznej (obliczeniowej) inteligencji i ich celem jest pokazanie użyteczności zaawansowanych algorytmów obejmujących m.in. uczenie się, sieci neuronowe, logikę rozmytą i algorytmy genetyczne. W związku z tym, stopień złożoności występujących w zawodach gier jest wysoki. To z kolei sprawia, że napisanie bota jest dużym wyzwaniem i liczba uczestników jest niewielka (np. w 2010 roku w grze Ms Pac-Man udział wzięło 7 zawodników, w StarCraft 28, natomiast 2K BotPrize 11). Wielu zawodników bazuje na doświadczeniach z poprzednich edycji zawodów, usprawniając programy pisane przez lata, co sprawia, że dołączenie do niektórych konkursów może być dla nowych graczy zadaniem trudnym. Warto również zwrócić uwagę na fakt, że każda z wykorzystywanych gier programistycznych jest odrębnym i niezależnym od zawodów projektem. Nie ma więc między nimi żadnej korelacji w sposobie dystrybucji, udostępnianej użytkownikom dokumentacji ani interfejsie programistycznym (w szczególności różnią się akceptowanymi językami programowania). Wszystkie te cechy zawodów IEEE CIG, dla nowych osób zainteresowanych tematyką gier programistycznych, stanowią wady. Ich analiza pozwala wyciągnąć wnioski na temat konstrukcji systemu Meridius tak, aby był od tych wad wolny i umożliwiał rozgrywkę w sposób jak najbardziej spójny i przejrzysty. Niewątpliwą zaletą gier występujących na IEEE CIG jest natomiast ich różnorodność. Osoba chcąca wziąć udział w zawodach może wybrać konkurencję pod względem swoich zainteresowań zarówno fabularnych, jak i algorytmicznych. Pulę możliwych aktywności zwiększają jeszcze konkursy, które można uznać za niestandardowe (np. wspomniane już generowanie plansz). Występuje tu zbieżność z założeniami Meridiusa, powodem powstania którego jest umożliwienie obsługi jak najbardziej różnorodnych gier. Wprowadzone w naszym systemie mechanizmy, również pozwalają na rozgrywanie wielu konkursów w oparciu o jedną grę Kurni k Strona internetowa kurnik.pl jest serwisem z grami online dla ludzi. Udostępnia głównie najpopularniejsze gry planszowe oraz karciane. Zalogowani użytkownicy mają możliwość gry, w czasie rzeczywistym, przeciwko innym graczom przebywającym aktualnie w serwisie. Aby zagrać nie trzeba pobierać żadnych dodatkowych programów, wszystkie mecze odbywają się na stronie internetowej za pośrednictwem apletów. Tworząc rozgrywkę można ustalać zależne od rodzaju gry parametry rozgrywki, takie jak np. czas trwania partii lub możliwość dawania bomb w tysiącu. W trakcie trwania meczu, gracze mogą się ze sobą porozumiewać za pośrednictwem czatu. Rozgrywki można również oglądać jako obserwator, nie biorąc w nich bezpośredniego udziału. Po każdym meczu gra zwraca wynik, który jest zachowywany w celu wyliczania statystyk. Na podstawie dotychczasowych rezultatów, system wylicza ranking każdego użytkownika, określający jego poziom w danej grze. Oprócz rankingu dostępne są także bardziej rozbudowane 21

22 statystyki. Znajdują się w nich informacje m.in. o liczbie rozegranych partii, liczbie zwycięstw, ucieczek i aktualnej passie. Możliwy jest także wgląd w szczegółową historię rozgrywek użytkownika oraz spis przeciwników z którymi grał. Wszystkie te informacje pozwalają użytkownikom wybrać do gry przeciwników o odpowiadających im umiejętnościach. Stymulują także do osiągania coraz lepszych rezultatów. Portal wprowadza również aspekt społecznościowy. Istnieje możliwość określania innych użytkowników jako znajomych, wysyłania im wiadomości, sprawdzania gdzie aktualnie grają i zapraszania do wspólnej gry. Oprócz zwykłych rozgrywek, portal umożliwia branie udziału we w pełni zautomatyzowanych turniejach. Oficjalnych, bądź prywatnych organizowanych przez zwykłych użytkowników. Ranking uzyskany w ramach turniejów jest oddzielony od zwykłego. Serwis istnieje od 2001 roku. Obecnie udostępnia 34 gry, m.in. szachy, go, brydż, tysiąc, kalambury, mahjong. Jest dostępny w 34 wersjach językowych. O jego popularności świadczy fakt, że w tym samym czasie z serwisu korzysta około tysięcy użytkowników. Portal kurnik.pl pokazuje w jaki sposób udostępniać gry w Internecie, w sposób satysfakcjonujący użytkowników. Na uwagę zasługują zwłaszcza te cechy, które w grach programistycznych zazwyczaj nie występują, np. brak konieczności pobierania jakichkolwiek aplikacji. Także prostota zasad udostępnianych gier stoi w opozycji do programów typu A.I. Wars (The Insect Mind), których reguły są tak skomplikowane, że mogą zniechęcać potencjalnych odbiorców. Portal, udostępniając statystyki graczy i prowadząc ich rankingi, potwierdza spostrzeżenia uczynione przy okazji analizy innych systemów, o skuteczności wykorzystania mechanizmu rywalizacji. Z tego powodu, udostępnienie podobnych funkcjonalności zostało przez nas określone jako jedno z podstawowych założeń systemu Meridius. 3 Opis systemu To co czyni system Meridius wyjątkowym to pomysł, aby stworzyć nie pojedynczą grę programistyczną, ale uniwersalne środowisko w spójny sposób zarządzające wieloma grami. Przechodzimy zatem na wyższą warstwę abstrakcji i traktujemy grę programistyczną nie jako samodzielną aplikację, lecz modyfikowalny element większej całości. Równocześnie zapewniamy, że znajdujące się w systemie gry nie są przez ten system zbyt ograniczone. Meridius automatycznie udostępnia funkcjonalności charakterystyczne dla standardowych gier programistycznych. Większość z nich możemy odnaleźć w grach omówionych w poprzednim rozdziale. Aby zapewnić takie własności gier programistycznych oraz efektywne metody zarządzania tymi grami, potrzebowaliśmy znaleźć kombinację cech, która zapewni odpowiedni balans pomiędzy elastycznością środowiska a jego prostotą. W tym rozdziale przedstawimy najważniejsze z tych cech i pokażemy w jaki sposób realizują one stawiane przed systemem wymagania. Będziemy w tym celu traktowali system Meridius jak zbiór funkcjonalności, abstrahując za pomocą jakich technologii i narzędzi zostały one osiągnięte. 3.1 Sposób użytkowania System Meridius działa jako serwer, który może udostępniać swoje funkcje szerokiej grupie odbiorców na różne sposoby. Istnieje możliwość integracji z serwerem WWW i stworzenia portalu internetowego. Przykład realizacji takiego mechanizmu jest przedstawiony w rozdziale 5.4. Można również dystrybuować samodzielne aplikacje, które będą komunikowały się z systemem za pośrednictwem sieci. Większość gier programistycznych jest wydawanych właśnie jako aplikacje. Wiąże się to z koniecznością instalacji oraz konfiguracji programu i zaznajomienia się 22

23 z jego interfejsem. W przypadku złożonych projektów, takich jak opisany A.I. Wars (The Insect Mind), może to być problematyczne. Najczęściej aplikacje takie wymuszają uruchamianie rozgrywek oraz botów na komputerze użytkownika. To z kolei może mieć wpływ na bezpieczeństwo, ponieważ w przypadku uruchomienia potencjalnie niebezpiecznych programów botów, istnieje bezpośrednie zagrożenie dla systemu użytkownika. Kolejną powszechną wadą samodzielnych aplikacji jest możliwość tworzenia jedynie lokalnych rozgrywek. W ten sposób utrudniona jest rywalizacja z innymi graczami. Zdobycie napisanych przez nich botów, wymaga zazwyczaj szukania i pobierania ich z Internetu, po czym instalacji w grze. Ponieważ Meridius jest systemem scentralizowanym, którego baza danych botów i użytkowników jest globalnie dostępna, problem ten nie występuje. Do prawidłowego działania aplikacji wymagane jest jednak połączenie z Internetem. Drugim rozważanym mechanizmem interfejsu są portale WWW. Omówione strony internetowe, takie jak kurnik.pl lub SPOJ, nastawione są głównie na umożliwienie użytkownikom rywalizacji oraz wymiany doświadczeń. Posiadają prosty interfejs, którego łatwo można się nauczyć i nie wymagają od użytkowników pobierania ani instalacji żadnych dodatkowych aplikacji. Elastyczność systemu Meridius pozwala na równoczesne korzystanie z dobrodziejstw obu tych rozwiązań. Jest to framework, który może posiadać wiele interfejsów, dając użytkownikom możliwość wyboru z którego z nich skorzystać. Podstawowe funkcjonalności, które udostępnia Meridius są, tak samo jak w grach programistycznych, skierowane do twórców botów. Mają oni możliwość tworzenia i rozwijania swoich programów, uruchamiania ich w grach przeciwko innym zawodnikom, oglądania rozegranych meczów, a także zapisywania i odtwarzania ich powtórek. Wgląd w zbierane przez system statystyki pozwala na analizę gry botów i umożliwia ocenę postępów programisty. Natomiast istnienie globalnego (w ramach jednej gry) systemu rankingowania daje możliwość wygodnego porównywania osiągnięć botów oraz stymuluje rywalizację. Aby uczynić tworzenie botów bardziej przyjaznym, lista obsługiwanych przez system języków programowania może być w prosty sposób rozszerzana. Zastosowane rozwiązanie jest podstawową funkcjonalnością portali z zadaniami algorytmicznymi. Nie jest ono natomiast popularne w grach programistycznych, które najczęściej obsługują jeden język programowania, bardzo często stworzony sztucznie, specjalnie na potrzeby gry. Chociaż twórcy botów są bardzo ważni, to w systemie Meridius nie są oni jedyną grupą użytkowników. Respektowane są jeszcze dwie role. Po pierwsze, nie wszyscy użytkownicy muszą być programistami, którzy grają za pośrednictwem napisanych przez siebie botów. System pozwala użytkownikom także na grę bezpośrednią i traktowanie przez nich gier programistycznych jak zwykłych gier komputerowych, co w ramach tej pracy zostało określone jako gra manualna. Uczestniczenie w rozgrywkach zarówno programów jak i ludzi w sposób nierozróżnialny dla systemu było jednym z podstawowych wymagań stawianych przed Meridiusem. Idea połączenia gry programistycznej z grą wideo, choć rzadko stosowana, nie jest nowa. Istnieją gry komputerowe, do których została dodana możliwość pisania botów. Zazwyczaj, jak w przypadku Empire Deluxe: Enhanced Edition lub Fortress of Flags: A.I. Sandbox, jest to rozszerzenie, które dodano w późniejszych wersjach. Z tego powodu funkcjonalność ta nie wpasowuje się idealnie w system. Ponieważ gry te nie były od początku tworzone jako gry programistyczne, nie zostały w nich zaimplementowane mechanizmy bezpiecznego uruchamiania kodu i użytkownicy korzystający z botów napisanych przez innych czynią to na własną odpowiedzialność. Meridius realizuje opisywaną ideę w odmienny sposób, podobnie jak Internetowy Turniej Programów Walczących. W tym przypadku bazą jest gra programistyczna, której wizualizacja posiada dodatkowo interfejs do gry manualnej. W ITPW główny nacisk położony jest na zagadnienia algorytmiczne, natomiast możliwość konfrontacji programu z człowiekiem jest traktowana jako ciekawostka oraz pomoc przy testowaniu programów. System Meridius idzie w tym podejściu krok dalej, traktując ludzi jako pełnoprawnych graczy, którzy podlegają takim samym zasadom jak boty. Wszystkie statystyki, wyniki gier oraz rankingi są liczone w ten sam sposób, zgodnie z założeniem przezroczysty dla systemu. Co więcej możliwe jest przeprowadzanie rozgrywek, w których bierze udział 23

24 więcej niż jeden człowiek, a nawet w ogóle nie ma botów. Z tego powodu, w przypadku zastosowania strony WWW jako interfejsu użytkownika, Meridius upodabnia się do portali z grami online takimi jak kurnik.pl i również w ten sposób może być wykorzystywany. Ponieważ gry programistyczne są elastycznymi elementami systemu, które można dodawać i modyfikować, kolejną możliwą rolą dla użytkownika jest bycie twórcą gier. Wiąże się to z całkowicie odmiennym wykorzystaniem systemu. Do zadań twórców gier należy stworzenie zasad gry, napisanie implementującego je programu (logiki gry) oraz stworzenie grafiki i wizualizacji rozgrywek. Rola ta wiąże się z dużą odpowiedzialnością. Gry niedopracowane, z błędami i źle zbalansowane, zamiast zachęcić pozostałych użytkowników do korzystania z systemu spowodują jedynie ich niechęć i frustrację. Z tego powodu oraz ze względu na bezpieczeństwo systemu, twórcami gier powinni być jedynie zaufani użytkownicy. Sam proces tworzenia nowych gier, ich testowania oraz umieszczania w systemie, powinien być jak najmniej skomplikowany. Dlatego do dyspozycji twórców gier, oprócz niezbędnej dokumentacji, zostają oddane narzędzia i biblioteki wspomagające ich pracę. Ponieważ kolejnym z głównych celów Meridiusa było osiągnięcie jak największej elastyczności gier, nałożone przez system wymagania zostały tak określone, aby nie ograniczać inwencji ich twórców. Są oni bardzo ważną grupą użytkowników i mają dużą swobodę w realizacji swoich zamierzeń, ponieważ to od ich pomysłowości oraz umiejętności programistycznych zależy rzeczywisty rozwój systemu. 3.2 Gry programistyczne Na potrzeby systemu Meridius zdefiniowaliśmy grę jako skończoną sekwencję tur, wykonywanych przez ustaloną i niezmienną liczbę uczestników, a zakończoną przyporządkowaniem każdemu z uczestników wyniku w postaci liczbowej. Turę rozumiemy tutaj jako skończoną sekwencję komunikatów wymienianych pomiędzy logiką gry a ustalonym uczestnikiem. Definicja ta zawiera istotne ograniczenia, które będziemy po kolei doprecyzowywać. Uważa się za normalne, że każda gra w której biorą udział ludzie, powinna się w pewnym momencie zakończyć. Mecz piłkarski trwa dwa razy po 45 minut. Seria partii pokera kończy się, gdy wszyscy gracze oprócz jednego zostają bez żetonów. W grach, które potencjalnie mogą trwać w nieskończoność, takich jak np. szachy lub karciana rozgrywka w wojnę, przyjęło się tworzyć dodatkowe kryteria pozwalające zawsze zakończyć rozgrywkę (dla szachów jest to trzykrotne powtórzenie pozycji oraz wykonanie 50 posunięć bez bicia lub ruchu pionem). Jednak intuicyjny niezmiennik skończoności gry nie ma zastosowania w przypadku gier komputerowych. Wraz z ich rozwojem powstała idea gier ciągłych, czyli takich które trwają przez cały czas, a ich uczestnicy naprzemiennie dołączają do rozgrywki lub ją opuszczają. Jedyną znaną nam grą programistyczną tego typu jest ScriptCraft [36]. System Meridius od początku nie miał na celu obsługi gier ciągłych. Wymagałoby to całkowitej modernizacji planowanej architektury oraz porzucenia pozostałych ograniczeń, takich jak stała liczba uczestników i sekwencyjność tur. Rezygnacja z nich zaburzyłaby równowagę pomiędzy elastycznością systemu a jego prostotą, powodując m.in. problemy z zarządzaniem zasobami. Dodatkowo zaimplementowanie przez twórcę gier ciekawego, ciągłego zbioru reguł wymagałoby od niego znacznie większej ilości pracy. Zawężenie się do gier turowych tzn. takich, w których czynności muszą być przez graczy wykonywane sekwencyjnie jest mocnym, lecz z naszego punktu widzenia koniecznym ograniczeniem. Istota wielu gier, zarówno sportowych jak i komputerowych, polega na wykonywaniu czynności równocześnie. Liczą się wtedy refleks, umiejętność szybkiego myślenia, a często też sprawność fizyczna. Także nieliczne gry programistyczne rozgrywają się w czasie rzeczywistym. Do prawidłowego działania wymagają jednak natychmiastowej, najlepiej bezpośredniej, komunikacji między programem bota a logiką gry. Aby to osiągnąć boty ograniczane są do dynamicznie dołączanych bibliotek lub skryptów w specjalnie tworzonych językach i uruchamianych w wirtual- 24

25 nych maszynach. Zawęża to swobodę twórców botów do jednego języka programowania i utrudnia przygotowanie środowiska do gry manualnej. Ponieważ Meridius z założenia korzysta z komunikacji zewnętrznej pomiędzy logiką a botami, w jej trakcie, niezależnie od pracy systemu, mogą występować opóźnienia. Z tego powodu system jest w stanie zapewnić poprawną obsługę jedynie grom turowym. Jednak gdy bliżej przyjrzeć się zagadnieniu okazuje się, że wymuszenie sekwencyjności ruchów wcale nie jest dużym problemem. Większość gier czasu rzeczywistego można zasymulować, bez większego uszczerbku na grywalności, wprowadzając interwały czasowe. Niektóre gry programistyczne wykorzystują ten mechanizm umożliwiając turową rozgrywkę w rajdy samochodowe (RARS [28], TORCS [37]) lub symultaniczne walki robotów (QUAIKE [18]). Tura jest to zamknięty fragment gry, w którym jeden z botów podejmuje decyzje i wykonuje swój ruch. W trakcie trwania tury odbywa się wymiana komunikatów pomiędzy logiką a botem. Ze względów technicznych i bezpieczeństwa, czas na wykonanie tury jest ograniczony przez system, a w sytuacji jego przekroczenia gra jest automatycznie przerywana. Liczba wymienionych komunikatów nie podlega żadnym restrykcjom, chyba że zasady gry mówią inaczej. Zasady gry określają też jakie komunikaty uznawane są za poprawne. Jeżeli przesłane przez bota polecenie nie będzie prawidłowe, rozgrywka również zostaje przerwana. Dla większej kontroli nad przebiegiem gry, komunikaty które może przesłać bot podzieliliśmy na komendy i zapytania. Zapytanie jest to operacja, która informuje bota o aktualnej sytuacji w rozgrywce. W szachach zapytać można np. o pozycję figur na szachownicy. W pokerze mogą istnieć zapytania o aktualną stawkę lub wspólne karty. Należy tutaj zaznaczyć, że bot nie otrzymuje na początku tury żadnych informacji o stanie gry. Wszystkie dane są przekazywane wyłącznie jako odpowiedzi na zapytania. Korzyść z tego rozwiązania to większa swoboda twórców gier i botów. Dla autora gry taki system przekazywania danych jest bardziej usystematyzowany i wygodniejszy w implementacji. Natomiast twórca bota nie musi co turę parsować dużej liczby danych, tylko może pobierać je w ramach potrzeb. Zapytania są mechanizmem elastycznym i można je bez trudu zastosować do zasymulowania rozwiązania, w którym logika przekazuje cały stan gry od razu (stosowanego np. w starszych edycjach ITPW). Wystarczy aby gra udostępniała pojedyncze zapytanie StanRozgrywki, zwracające pełny opis stanu gry. Zwróćmy uwagę, że symulacja w drugą stronę nie jest możliwa. System obsługuje też drugi rodzaj poleceń, określany mianem komend. Wydanie przez bota komendy oznacza podjęcie przez niego decyzji o zmianie stanu rozgrywki. Po otrzymaniu komendy gra nie zwraca żadnej odpowiedzi. Aby zasymulować transakcyjność tur, komendy nie są wykonywane od razu tak jak zapytania, a dopiero po zakończeniu aktualnej tury. W ten sposób nie modyfikują one aktualnego stanu gry i nie mają wpływu na wartości zwracane przez zapytania. Komendy są mechanizmem dodatkowym, który powstał w celu zapewnienia twórcom gier większej wygody. Z używania komend można w prosty sposób zrezygnować, definiując zapytania modyfikujące stan gry i zwracające nieistotne wartości. Jednak zastąpienie ich zapytaniami, przy zachowaniu sposobu działania, jest rzeczą bardziej skomplikowaną. O momencie zakończenia tury decyduje bot, przesyłając specjalne polecenie systemowe. Wtedy następuje uruchomienie, w odpowiedniej kolejności, wszystkich komend, zaś logika gry wybiera następnego uczestnika (może to być ten sam zawodnik), któremu będzie przysługiwał ruch. Stawiamy też ograniczenie, aby liczba graczy w trakcie pojedynczej rozgrywki nie ulegała zmianie. Z punktu widzenia logiki gry, na różnych etapach rozgrywki gracze mogą być aktywni lub nie. To logika decyduje, który uczestnik aktualnie wykonuje ruch. Zakładając, że pojedyncza rozgrywka, bez udziału ludzi, trwa od kilku sekund do kilku minut, system może sobie pozwolić aby od razu zaalokować wszystkie zasoby i zwolnić je dopiero na końcu rozgrywki. Z tego powodu, z punktu widzenia systemu, cały przebieg gry podzielony jest na etap alokacji zasobów, faktycznej rozgrywki oraz zwolnienia zasobów i zapisania wyniku. Brak przeplatania się tych etapów ułatwia zarządzanie całością. Gdyby pominąć omawiane ograniczenie, to przy limitowanych zasobach, mogłoby dojść do sytuacji, w której rozgrywka musi zostać wstrzymana, ponieważ logika gry wymaga dołączenia nowego bota, natomiast system nie jest w stanie spełnić 25

26 żądania. Pozwolenie na zaistnienie takiej sytuacji, w połączeniu z możliwością uruchamiania wielu gier na raz, może w łatwy sposób doprowadzić do zakleszczenia. Wymaganie dotyczące stałej liczby uczestników również jest konsekwencją, poczynionych wcześniej, ogólnych założeń o działaniu systemu. Gdyby gry były uruchamiane lokalnie, a boty działały wewnątrz wirtualnej maszyny, obejście takiego ograniczenia byłoby dużo prostsze. Każda gra, zarówno sportowa jak i komputerowa czy programistyczna, w jakiś sposób wyłania zwycięzcę. Ponieważ Meridius ma za zadanie obsługiwać jak najszerszy zakres gier uznaliśmy, że sama informacja kto jest zwycięzcą a kto przegranym nie jest wystarczająca. Wymagamy więc, aby logika gry obliczała jej wynik w postaci jednej liczby dla każdego z uczestników rozgrywki. Ta metoda pozwala ocenić nie tylko kto w danym meczu spisał się lepiej a kto gorzej, ale także jak bardzo gracze odstawali od siebie poziomem. Punkty zwracane przez różne gry najczęściej mają różną interpretację i nie można ich ze sobą porównywać. Muszą jednak spełniać dodatkowy warunek: więcej punktów oznacza lepszego zawodnika. Dzięki takiemu ujednoliceniu zasad, system może w dużo prostszy sposób automatycznie zarządzać wynikami. Idąc krok dalej, system umożliwia prowadzenie globalnego rankingu dla każdego bota. Dzięki temu możliwa jest ocena poziomu bota za całokształt jego dokonań. Takie rozwiązanie znajduje powszechne zastosowanie w portalach typu SPOJ, kurnik.pl oraz zawodach TopCoder, w których osiągnięcie wysokiego rankingu staje się celem samym w sobie. Aby umożliwić obliczenie nowego rankingu, jego stara wartość musi być przekazana logice. Szybko okazało się, że nie może to zostać zrobione na początku rozgrywki, ponieważ bot może równocześnie brać udział w wielu grach. Dochodzi wtedy do sytuacji, w której jedna rozgrywka zmieni ranking bota, a następnie druga, która rozpoczęła się wcześniej, również zmieni ranking, ale nie biorąc pod uwagę zmian dokonanych w trakcie jej trwania. Metoda logiki obliczająca nowe rankingi botów na podstawie starych, jest więc wywoływana dopiero po zakończeniu rozgrywki. W tym momencie przyszło nam zmierzyć się z kolejnym problemem, który nie ma odzwierciedlenia w realnym świecie. Mianowicie jeden uczestnik może brać udział w rozgrywce równocześnie na kilku pozycjach (w szczególności bot może grać sam ze sobą). W związku z tym, zgodnie z zasadami, po meczu powinien mieć przypisanych kilka rankingów. Aby zachować jednoznaczność, w takiej sytuacji musi nastąpić proces tzw. normalizacji rankingu, który zadecyduje o jego ostatecznej wartości. Meridius obsługuje normalizację, pozostawiając twórcom gier pełną swobodę w jaki sposób ją przeprowadzać. 3.3 Funkcjonalności gier programistycznych System Meridius, dzięki narzuconym na gry programistyczne wymaganiom, może udostępnić szereg dodatkowych funkcjonalności. Zostały one wprowadzone aby dać twórcom gier jak największą swobodę kreacji, przy równoczesnym wsparciu ich działań ze strony systemu. Z tego powodu stworzyliśmy mechanizm parametryzowania rozgrywek. Po pierwsze, pozwala on na zdefiniowanie więcej niż jednego zbioru zasad, dla jednej implementacji logiki gry. Umożliwia to stworzenie gry, która będzie miała kilka wariantów (tzw. trybów). Jest to naturalny mechanizm występujący w wielu grach komputerowych, planszowych oraz dyscyplinach sportowych. Przykładem niech będzie bilard, w którym przy użyciu tego samego stołu, kijów i bil, można zagrać na różnych zasadach, np. w ósemkę, dziewiątkę czy piętnastkę. Drugim udogodnieniem jest możliwość zdefiniowania typów botów, które mogą brać udział w grze. Pozwala to logice na rozróżnienie graczy mających pełnić różne role. Przykładów na zobrazowanie takiego rozróżniania, zarówno z życia jak i świata gier, również jest wiele. Bramkarza obowiązują inne zasady niż pozostałych zawodników jego drużyny. Pilot rajdowy wykonuje inne czynności niż kierowca, pomimo, że obaj biorą udział w tych samych zawodach. Trzecim istotnym elementem mechanizmu parametryzowania jest możliwość zdefiniowania parametrów wymaganych do uruchomienia rozgrywki. Mogą to być liczby (całkowite oraz zmiennoprzecinkowe), napisy, daty lub wartości z pewnego zdefiniowanego zbioru. Twórca gry określa jakie parametry są wymagane, natomiast 26

27 użytkownik, tworząc rozgrywkę, musi podać ich wartości. Uzależnienie przebiegu rozgrywki od pewnych wartości początkowych, po przeanalizowaniu różnych gier, okazuje się naturalną potrzebą. Mechanizm ten może być wykorzystany do określenia limitu tur/punktów, początkowej liczby posiadanych przez graczy zasobów, rozmiaru mapy, itd. Parametry pozwalają twórcom logik na tworzenie gier złożonych, które nie będą szybko nudziły użytkowników. Zapewniają także wygodne możliwości rozwoju gry, np. poprzez dodanie trybu uwzględniającego bardziej zaawansowane zasady lub umieszczenie kolejnego parametru początkowego pozwalającego wpływać na wartość, która wcześniej była stała. System Meridius usprawnia pracę twórców gier automatycznie weryfikując syntaktyczną poprawność parametrów. Parsuje podane przez użytkowników wartości parametrów, sprawdza zgodność typów i nie pozwala np. na rozegranie meczu z botem o niezadeklarowanym przez grę typie. W przypadku wykrycia nieprawidłowości logika gry nie jest uruchamiana, a użytkownik otrzymuje stosowny komunikat o błędzie. Twórca gry powinien mieć jednak możliwość bardziej szczegółowego określenia jakie parametry są prawidłowe, a jakie nie. Chcieliśmy, aby mógł on bez problemu zdefiniować warunki takie jak: parametr rozmiar mapy powinien przyjmować jedynie wartości od 5 do 20 lub w trybie gry Duel muszą brać udział dwa boty o tym samym typie. Weryfikacja semantycznej poprawności również powinna zostać wykonana przed uruchomieniem rozgrywki. Początkowo planowaliśmy, aby twórca gry określał poprawne parametry definiując więzy. Jednak, po zdefiniowaniu wstępnej gramatyki takiego systemu więzów, zorientowaliśmy się, że byłby on albo bardzo skomplikowany, albo narzucałby twórcom gier sztuczne ograniczenia, czego za wszelką cenę chcieliśmy uniknąć. Zdecydowaliśmy, że należy oddzielić deklarację parametrów od ich walidacji, a tą przeprowadzić wewnątrz logiki, pozostawiając twórcy gry pełną swobodę. Na początku każdej rozgrywki logika decyduje czy podane parametry zatwierdzić, czy odrzucić i przekazać użytkownikowi stosowny komunikat informujący o błędzie. Kolejną funkcjonalnością jest obsługa parametrów opisujących zakończony mecz. Uznaliśmy, że wynik, jako jedyna informacja dostępna po rozgrywce, nie zawiera dostatecznej liczby danych o jej przebiegu. W świecie sportu, po każdym meczu przedstawiane są różnorodne statystyki, takie jak: całościowy czas gry, procentowe posiadanie piłki, liczba przewinień, liczba punktów uzyskana przez każdego z zawodników, itd. Podobną sposobność chcieliśmy dać także twórcom gier programistycznych. Umożliwiliśmy gromadzenie dowolnych statystyk z przebiegu rozgrywki za pomocą zdefiniowanego przez twórców zbioru parametrów (tzw. końcowych), które są zwracane przez logikę równocześnie z wynikiem meczu. Parametry te mogą dotyczyć całej rozgrywki (jak czas gry) lub być przypisane konkretnym uczestnikom (np. liczba przewinień). Możliwe typy tych statystyk są takie same jak parametrów początkowych: liczby, napisy i daty. System jest odpowiedzialny za zapamiętanie ich i udostępnienie do wglądu w przyszłości. Jest to cecha pomocna z punktu widzenia użytkowników, którzy chcą mieć możliwość szczegółowej analizy gry swojej i swoich botów, a także potencjalnych przeciwników. Mechanizmy podobne do wyżej opisanych można spotkać w większości gier programistycznych. Bardzo rozbudowany system parametrów i statystyk posiada A.I. Wars (The Insect Mind). W Core War parametry są dużo prostsze, ale również występują. Natomiast CeeBot pozwala na programowanie różnych typów botów oraz rozgrywkę w różnych trybach. Istnieje jednak zasadnicza różnica pomiędzy tymi samymi funkcjonalnościami występującymi w wyżej wymienionych grach a w Meridiusie. Gry te mają rozbudowane systemy spersonalizowanych statystyk tylko na swoje potrzeby. Natomiast naszym zadaniem, jako twórców Meridiusa, było zaprojektowanie mechanizmu uniwersalnego. Takiego, który pozwoliłby systemowi na zarządzanie w skuteczny sposób, jak najbardziej spersonalizowanymi, statystykami dowolnej umieszczonej w nim gry. Zastosowane rozwiązanie, elastyczne i proste w obsłudze, założenie to spełnia. 27

28 3.4 Boty Tworząc mechanizmy obsługi botów, naszym celem było zapewnienie ich twórcom jak największej swobody. Uznaliśmy, że o swobodzie w dużej mierze świadczą następujące cechy: brak ograniczenia dostępnych języków programowania, prosty system komunikacji z logiką, brak narzuconej struktury programu i swobodny dostęp do usług systemowych. Braliśmy pod uwagę trzy rozwiązania w różnym stopniu realizujące wymienione cechy. O ostatecznym wyborze zadecydowały kwestie techniczne, omówione szczegółowo w rozdziale 4.7. Ustalone w ten sposób zasady tworzenia botów opisane są w [15]. Zastosowane rozwiązanie pozwala na korzystanie z wielu języków programowania. W obecnej wersji obsługiwanych jest 10 języków, wybranych ze względu na popularność. Ponieważ jedynym warunkiem dodania nowego języka jest możliwość jego kompilacji i uruchomienia pod systemem Linux, Meridius może obsługiwać liczbę języków porównywalną z portalem Sphere Online Judge (obecnie 44 języki i dialekty). Jako formę komunikacji wybraliśmy standardowe wejście/wyjście. Korzystanie ze standardowych strumieni jest podstawową umiejętnością nabywaną na samym początku nauki programowania. Nie zawęża więc docelowej grupy odbiorców do zaawansowanych programistów. Wykorzystanie tego mechanizmu pozwala również na wstępne testowanie programu bez połączenia z systemem, jedynie przy wykorzystaniu lokalnego środowiska programistycznego. Jedynym poważnym ograniczeniem na strukturę programu bota jest to, że musi on znajdować się w jednym pliku źródłowym i generować tylko jeden plik wykonywalny. Po uruchomieniu, bot ma za zadanie komunikować się z logiką, zgodnie z ustalonym przez zasady gry protokołem. Program bota jest uruchamiany na cały czas trwania rozgrywki, ma więc możliwość zapamiętania i modyfikacji swojego stanu z poprzednich tur gry. Zdolność do wysyłania poleceń w trakcie nie swojej tury jest blokowana przez system, który na ten czas zatrzymuje wykonanie bota. Program bota ma pełną swobodę korzystania z systemu operacyjnego, na którym jest uruchomiony, w ramach uprawnień użytkownika. W szczególności może wykonywać operacje na plikach, tworzyć wątki i procesy oraz wywoływać polecenia systemowe. Ogranicza go jedynie fakt, że system ten nie jest podłączony do żadnej zewnętrznej sieci. Kolejny aspekt to zarządzanie botami jako elastycznymi elementami systemu, dostarczanymi i rozwijanymi przez użytkowników. Meridius pozwala na przechowywanie kodu źródłowego, proste wersjonowanie oraz zabezpieczenie przed dostępem osób innych niż jego twórca. Bot jest dostarczany przez użytkownika w postaci kodu źródłowego, który następnie jest kompilowany przez system lub (w przypadku języków interpretowanych) sprawdzana jest jego poprawność syntaktyczna. Twórca bota może go aktualizować przesyłając kolejne wersje jego kodu źródłowego. W przypadku wystąpienia błędu, system przekazuje użytkownikowi otrzymany od kompilatora komunikat zwrotny, a kod bota nie ulega zmianie. System gwarantuje również zapamiętanie błędów, które bot spowodował podczas rozgrywki. Dotyczy to zarówno błędów związanych z grą i jej zasadami (np. przekroczenie czasu, nieprawidłowe polecenie) jak i błędów wykonania programu. System zbiera dane o popełnionych przez bota błędach i są one później udostępnione w postaci statystyk, świadczących o stopniu jego niezawodności. W przypadku gdy system Meridius jest dostępny tylko zdalnie, na przykład za pośrednictwem portalu WWW, konieczny jest sprawny system testowania botów w trakcie rozgrywek. W tym celu wprowadziliśmy możliwość oznaczenia bota jako testowego. Taki bot, w trakcie meczu, może przesyłać dodatkowe komunikaty, które zostaną przez system zapisane i będą widoczne w trakcie wizualizacji. Mechanizm ten pozwala na monitorowanie stanu bota w trakcie rozgrywki i wykrywanie ewentualnych błędów w działaniu. Bot testowy jest niewidoczny dla użytkowników i jedynie jego twórca może tworzyć i oglądać rozgrywki z jego udziałem. Rozgrywki takie, zwane testowymi, różnią się od innych jedynie tym, że ich rezultat nie wpływa na statystyki botów oraz ich rankingi. Wynik oraz parametry końcowe są po takiej rozgrywce dostępne. W jednym meczu może brać udział więcej niż jeden bot testowy. W takiej sytuacji, oglądając rozgrywkę 28

29 użytkownik wybiera bota, którego komunikaty testowe chce mieć widoczne. 3.5 Wizualizacja rozgrywek W przypadku gier programistycznych, system wizualizacji jest ich integralną częścią dostosowaną do potrzeb danej gry. System wizualizacji Meridiusa musi obsługiwać nie tylko wiele różnych gier, ale także umożliwiać grę użytkownikom. Dodatkowo, powinien on być niezależny od wyboru interfejsu użytkownika. Nie chcemy ograniczać systemu wyłącznie do serwisu WWW, ani lokalnej aplikacji. Problem ten można rozwiązać stosując odpowiednie wzorce projektowe, na przykład MVC (ang. Model-View-Controller). Ponieważ, ze względu na liczbę i różnorodność potencjalnych gier, stworzenie jednego systemu wizualizacji jest prawie niemożliwe, rozpatrywaliśmy inne możliwości. Jedną z nich było zobowiązanie twórcy gry do implementacji własnej wizualizacji, która musiałaby spełniać pewne określone standardy. Takie rozwiązanie ma jednak sporo wad. Spowodowałoby duże różnice w interfejsach gier, zaburzając poczucie spójności systemu. Znacznie wzrosłaby ilość pracy dla twórcy gry, co przekłada się na przedłużenie czasu powstawania gry. Ponieważ interfejs ten byłby używany także do gry manualnej, twórca gry musiałby samodzielnie zaimplementować komunikację pomiędzy wizualizacją a logiką. Pozbawiłoby to system Meridius sporej części zalet, wynikających z projektu architektury. Wdrożone rozwiązanie zakłada, że wizualizacja działa podobnie do odtwarzacza animacji. Wykorzystujemy tu fakt, że wszystkie gry są turowe. Twórca gry jest zobowiązany do generowania co turę tekstu stanowiącego ramkę wizualizacji, która opisuje w odpowiednim formacie stan gry w danej turze. W grze w pokera ramka taka zawierałaby informację o aktualnym graczu, kartach i żetonach wszystkich użytkowników, kartach wspólnych oraz puli. Aby umożliwić grę manualną, oprócz ramek dla wszystkowiedzącego obserwatora, potrzebne są także takie z punktu widzenia gracza. W naszym przykładzie, ramka dla gracza byłaby pozbawiona informacji o kartach pozostałych uczestników. Wszystkie ramki są zapisywane, a następnie przekazywane wizualizacji. W tym rozwiązaniu twórca gry zajmuje się jedynie warstwą graficzną. Natomiast system wizualizacji umożliwia operacje takie jak: przewijanie rozgrywki, pauzowanie, przyspieszanie/spowalnianie animacji, itd. Posiada także mechanizm do obsługi gry manualnej, który twórca gry może w prosty sposób wykorzystać. Tak sformułowany protokół działania pozwala na wydzielenie systemu wizualizacji jako zewnętrznej aplikacji, która może być rozwijana niezależnie od Meridiusa. Zaletą takiego rozwiązania dla twórcy gry jest zmniejszenie ilości pracy jaką trzeba włożyć w jej stworzenie. Z punktu widzenia użytkownika jest to spójny interfejs w ramach całego systemu, a z punktu widzenia architektury uniwersalny sposób zapisywania i odtwarzania rozgrywek. Istnieje też możliwość wykorzystania więcej niż jednego programu do wizualizacji, wszakże pod warunkiem, że każdy będzie korzystał z ramek opisanych w tym samym formacie. Rozwiązanie ma też pewne wady. Odpowiednią aplikację należy stworzyć i połączyć z systemem. Atrakcyjność wyświetlanych rozgrywek prawdopodobnie będzie mniejsza niż wizualizacji dostosowanej do konkretnej gry. Aplikacja może ograniczać twórcę gry w sytuacji, gdy nie będzie on w stanie, wykorzystując ramki, wygenerować oczekiwanego efektu. Ramki powinny mieć więc dużą moc wyrazu, a równocześnie być skonstruowane tak, aby logika mogła je w prosty sposób generować. Jeśli tak nie będzie, ilość wymaganej od twórców gier pracy nie zmniejszy się takim stopniu, aby rozwiązanie to było opłacalne. Kolejną cechą tego rozwiązania jest zwiększenie niezależności między logiką rozgrywki a jej wyświetlaniem. Może ona być traktowana jako wada lub zaleta, zależnie od okoliczności. 29

30 3.6 Gra manualna Czynnikiem, który był bardzo ważny podczas planowania systemu, było uwzględnienie ludzi, jako uczestników rozgrywek gier programistycznych. Ze względu na brak jednolitego nazewnictwa oraz sporadyczne występowanie takiej możliwości w istniejących grach programistycznych przyjęliśmy określenie gry manualnej. Aby móc zagrać w daną grę, użytkownik musi założyć tzw. profil, odpowiadający botowi o pewnym wybranym, akceptowanym przez tę grę, typie. Oznacza to, że do jednej gry można mieć więcej niż jeden profil, ale tylko jeden profil danego typu. Automatycznie pozwala on na rozgrywkę we wszystkich dostępnych trybach gry. Profil gracza niewiele różni się od zwykłego bota. Obowiązujące zasady gier, sposoby liczenia statystyk oraz rankingów, są takie same dla wszystkich. Z tego też powodu użytkownicy mogą grać nie tylko z botami i innymi ludźmi, ale także z własnymi profilami. Z punktu widzenia logiki gry, nie da rady odróżnić bota od gracza. Za obsługę wszystkich możliwych różnic, jak komunikacja oraz alokacja i zwalnianie zasobów, jest odpowiedzialny system. Twórca gry, tworząc logikę, ma jedynie za zadanie wygenerować ramki wizualizacji obrazujące stan meczu z punktu widzenia gracza, którego tura ma teraz nastąpić. Twórca logiki musi zadbać o to, aby gracz nie dysponował ani większą, ani mniejszą wiedzą na temat stanu gry, niż wysyłający zapytania bot. To, któremu graczowi dostarczyć odpowiednią ramkę, jest już w gestii systemu. Gra manualna odbywa się za pośrednictwem aplikacji odpowiedzialnej za wizualizację rozgrywek. Interfejs użytkownika zależy więc od jej stopnia zaawansowania. Może ona udostępniać jedynie prosty terminal, służący do ręcznego wpisywania poleceń zgodnie z zasadami gry. Istnieje też możliwość stworzenia warstwy abstrakcji, umożliwiającej użytkownikowi wykonanie predefiniowanych akcji za pomocą wciskanych klawiszy, przycisków lub bezpośredniego oddziaływania kontrolerem na planszę gry. Zastosowanie takich mechanizmów przystosowuje grę, pierwotnie stworzoną z myślą o programach, do wygodnej rozgrywki dla ludzi. Upodabnia ją w ten sposób do gier komputerowych i aplikacji umieszczanych na portalach internetowych takich jak kurnik. 4 Architektura W poprzednim rozdziale przedstawione zostały najważniejsze koncepcje systemu Meridius. W tej części pracy znajduje się opis funkcjonalności systemu z technicznego punktu widzenia oraz krótkie objaśnienie, jakimi środkami zostały zrealizowane. Oprócz wypunktowania cech systemu, przedstawimy także, rozpatrywane przez nas w fazie koncepcyjnej, alternatywne rozwiązania. Jądro systemu zostało napisane na platformie Microsoft.NET 4.0, w języku C# i z zachowaniem paradygmatu obiektowego. Do przechowywania danych został wybrany Microsoft SQL Express Spośród innych popularnych technologii, należy wspomnieć o wykorzystaniu języka XML. 4.1 Podstawowe założenia Patrząc na wymagania stawiane systemowi Meridius przez pryzmat architektury, najbardziej naturalna wydaje się aplikacja modułowa, gdzie cały system składa się z niezależnych, łatwo wymienialnych elementów (specyfikacja implementacji których znajduje się w [14]). Poszczególne moduły są odpowiedzialne za komunikację z uczestnikami gier, kompilację botów, uruchomienie rozgrywek oraz zapis powtórek. Samo serce systemu (zwane także jądrem, ang. Core) udostępnia między innymi zbiór interfejsów do komunikacji z danymi modułami, mechanizm do zarządzania zasobami oraz podstawowe implementacje interfejsów, które mogą być wykorzystane jako baza 30

31 podczas tworzenia własnych modułów. Większość elementów systemu jest wymienna. Należy do nich zaliczyć mechanizmy zapisu i odczytu danych uczestników, parametrów początkowych i końcowych gier oraz powtórek. Architekturalnie poniżej modułów, znajdują się logiki gier. Każda logika musi dziedziczyć po pewnej abstrakcyjnej klasie bazowej. Jeszcze niżej w hierarchii znajdują się uczestnicy (boty lub profile). Bot, w zależności od modułów odpowiedzialnych za komunikację czy wizualizację, może mieć dowolną postać pliku tekstowego, interaktywnej konsoli lub aplikacji komunikującej się przez standardowe wejście/wyjście, sieć, itp. Uproszczony schemat architektury, właściwy dla opisywanej implementacji systemu Meridius, znajduje się na rysunku 4. Wszystkie wyszczególnione na nim elementy systemu zostaną przedstawione w dalszej części tego rozdziału. Rysunek 4: Uproszczony schemat architektury portalu Meridius. Głównym kryterium wyboru technologii, którą posłużyliśmy się do napisania systemu Meridius, była łatwość w tworzeniu i osadzaniu logik gier w systemie. Pozostałe wymagania były w porównywalny sposób osiągalne za pomocą alternatywnych narzędzi. Za platformą.net przemawiało wiele języków programowania przeznaczonych na tę platformę oraz mechanizm refleksji, umożliwiający w dużym stopniu automatyczną weryfikację poprawności logiki gry. Wybór silnika Microsoft SQL Express jako dostawcy warstwy danych był wynikiem poprzedniej decyzji. Jest to system darmowy oraz świetnie zintegrowany z platformą.net. 31

32 System Meridius działa w oparciu o kolejkowane zadania, wykonywane według ściśle określonego schematu: sprawdzenia dostępnych zasobów, alokacji zasobów, wykonania zadania (poprawnego lub zakończonego błędem) i zwolnienia zasobów. Jedynym bazowo zaimplementowanym zadaniem jest klasa odpowiedzialna za przebieg pojedynczej rozgrywki. Za pomocą dostarczonych bibliotek możliwe jest zaimplementowanie dodatkowych zadań w przypadku opisywanej wersji systemu była to klasa nadzorująca kompilację botów. Pozostały do przedstawienia dwa ostatnie, jednak nie pozbawione znaczenia, elementy systemu Meridius. Pierwszym jest rozbudowany mechanizm do tworzenia logów z działania systemu, przygotowany z myślą o deweloperach rozwijających poszczególne moduły i logiki gier oraz administratorach zarządzających systemem. Drugim elementem jest wbudowany (w tej chwili niemodyfikowalny) mechanizm do zarządzania konfiguracją oraz aktywnymi modułami. 4.2 Model obiektowy Główną klasą odpowiedzialną za obsługę zadań jest JobManager. Podczas uruchamiania systemu zostaje utworzony singleton tej klasy, a następnie przez cały czas działania aplikacji kolejkuje on obiekty dziedziczące po abstrakcyjnej klasie JobDefinition. W zależności od ustalonego limitu i dostępnych środków, kolejne zadania alokują konieczne zasoby i zostają uruchomione w osobnych wątkach. JobManager czuwa nad prawidłowym wykonywaniem zadań, odpowiada za zapis do pliku z logami oraz obsługuje zwalnianie zasobów i wyjątki. Ze względu na dużą dowolność w implementacji zadań, deweloper musi zapewnić prawidłowe zwolnienie wszystkich zasobów w razie wystąpienia błędu. W przeciwnym wypadku całemu systemowi grożą powolne wycieki zasobów (np. pamięci), spadek wydajności, a w końcu całkowite zakleszczenie. Jest to więc najbardziej wrażliwy element systemu. Najważniejszą klasą dziedziczącą po JobDefinition jest RunGameContext. Jest to klasa odpowiedzialna za przebieg każdej pojedynczej rozgrywki. Jej instancje są jedynymi obiektami, które mają bezpośredni dostęp do obiektu logiki gry i odpowiadają za komunikację pomiędzy nią a światem zewnętrznym. Klasa ta jest również odpowiedzialna za przechwytywanie błędów logiki i obsługę błędnych komunikatów od uczestników gry. Dba ona o wykonywanie kolejnych etapów rozgrywki oraz, pośrednio, korzystając z zaimplementowanych modułów, dokonuje zapisu tur, podsumowania rozgrywki i pośredniczy w komunikacji z uczestnikami. Klasą odpowiedzialną za zarządzanie modułami jest EngineFactory. Pierwszą grupą modułów są klasy, które implementują następujące interfejsy: public interface IAccountProvider public interface IBotProvider public interface IGameHistoryProvider public interface IGameMethodsProvider public interface IGameProvider public interface ILanguageProvider public interface IGameValidator public interface IGameService Każdy z grupy interfejsów IProvider odpowiada za prosty zapis lub odczyt odpowiednich danych, niezbędnych do przebiegu rozgrywki. Domyślna implementacja, dołączona do systemu Meridius, korzysta z bazy Microsoft SQL Express do zapisu i odczytu niemal wszystkich informacji o rozgrywkach, botach, grach i użytkownikach. Nieco odmiennym interfejsem jest IGameMethodsProvider, którego bazowa implementacja dostarcza za pomocą refleksji informacji o dostępnych w danej rozgrywce komendach i zapytaniach oraz tworzy kontekst wywołania tych metod (co zostanie opisane w następnym podrozdziale). IGameService jest odpowiedzialny za 32

33 bardziej złożone operacje związane z zarządzaniem logiką gry: załadowanie odpowiedniej klasy logiki do pamięci, zapis i odczyt parametrów końcowych i początkowych oraz utworzenie repozytorium dla parametrów (domyślnie nowych tabel w bazie MSSQL). Ostatnim szczególnym interfejsem jest IGameValidator, odpowiedzialny za sprawdzenie poprawności definicji parametrów i logiki również oparty głównie na mechanizmie refleksji. Drugą grupą dodatkowych modułów są klasy dziedziczące po abstrakcyjnej klasie GameEventReceiver. Instancje tej klasy, podczas trwania rozgrywki, otrzymują kolejne ramki z każdej tury. Klasy te współpracują z obiektami odpowiedzialnymi za komunikację z uczestnikami rozgrywki. Po utworzeniu każdej ramki, wywoływane są odpowiednie metody w kontekście aktualnego uczestnika, na przykład w celu dalszej obróbki (zależnej od protokołu komunikacji) lub przesłaniu ich do uczestnika gracza. Powyższe moduły tworzone są dynamicznie za pomocą singletona EngineFactory. Podczas instalacji systemu należy zarejestrować odpowiednie biblioteki zawierające implementacje interfejsów i klas abstrakcyjnych, po czym ich instancje będą dynamicznie tworzone i uruchamiane podczas trwania rozgrywki. Podane implementacje interfejsów, wymagające bezparametrowego konstruktora, z założenia powinny być lekkie i bezstanowe. Instancje klasy GameEventReceiver są tworzone po jednej na instancję RunGameContext. Innym rodzajem modułów są obiekty odpowiadające za komunikację z uczestnikami rozgrywek. W tym celu deweloper implementuje klasy dziedziczące po CommunicationService. Z każdym uczestnikiem rozgrywki kojarzona jest pojedyncza instancja takiej klasy odpowiedzialna za inicjalizację protokołu komunikacyjnego, wymianę komend, zapytań i odpowiedzi oraz ewentualnych innych operacji (na przykład związanych z przekazywaniem ramek dla graczy, we współpracy z GameEventReceiver). Dodatkowo instancja tej klasy, przed rozpoczęciem rozgrywki, ma możliwość zarezerwowania własnych zasobów, a na koniec ich zwolnienia. Elementami najbardziej zewnętrznymi są moduły odpowiedzialne za wizualizację oraz kompilację i uruchamianie botów. Wizualizacja otrzymuje ramki za pośrednictwem IGameHistoryProvider lub GameEventReceiver. Z kolei za kompilację oraz uruchamianie botów odpowiadają implementacje JobDefinition oraz CommunicationService. 4.3 Implementacje logik gier Pojedyncza gra programistyczna jest pakietem dostarczanym przez użytkownika systemu określanego jako twórca gry. Pakiet taki składa się z czterech części: biblioteki w kodzie zarządzanym zawierającej klasę dziedziczącą po GameLogicBase i implementującej zasady gry, plików konfiguracyjnych gry, plików wykorzystywanych przez logikę oraz dodatkowych plików odpowiedzialnych za wizualizację. Proces tworzenia gry programistycznej, dedykowanej dla systemu Meridius, został przedstawiony w [16]. Kluczową kwestią było zdefiniowanie czym są logiki gier i w jaki sposób system ma nimi zarządzać. Jednym z rozwiązań było dopuszczenie programu napisanego w dowolnym języku, który byłby, tak samo jak boty, uruchamiany w bezpiecznym środowisku. Rozwiązanie to nastręczałoby wiele trudności, ponieważ wymagałoby stworzenia złożonego protokołu komunikacji logiki z systemem i botami za pomocą wejścia/wyjścia. Na twórców gier spadałby wtedy obowiązek trzymania się tego protokołu oraz samodzielnego parsowania poleceń botów. Zamiast tego zdecydowaliśmy, że logika gry będzie biblioteką w kodzie zarządzanym, ładowaną dynamicznie do pamięci systemu. Jest to bardzo mocne ograniczenie jednak niesie ze sobą dużo korzyści. Dzięki narzuconej strukturze, napisanie logiki sprowadza się do zdefiniowania przez twórcę gry kilku metod oraz komend i zapytań. Nie ma już potrzeby pisania kodu nie związanego bezpośrednio z grą. Komunikacja logiki z systemem odbywa się automatycz- 33

34 nie. Metody logiki są po prostu wywoływane z odpowiednimi parametrami, zgodnie z ustalonym schematem. Odpowiadają za to instancje RunGameContext oraz implementacja interfejsu IGameMethodsProvider. Gdy logika chce zgłosić koniec rozgrywki, jedyne co musi zrobić to wywołać odpowiednie metody klasy bazowej. Oprócz samej definicji klasy bazowej, dostarczamy twórcom gier bibliotekę zawierającą przydatne podczas tworzenia gry struktury oraz funkcje. Dla twórców gier dużym problemem jest obsługa poleceń, które są przekazywane przez bota w formie tekstu. Zweryfikowanie poprawności polecenia wymaga jego żmudnego, powtarzalnego we wszystkich grach parsowania. Chcieliśmy więc, aby czynność tę przejął system. Wykorzystaliśmy w tym celu dostarczony przez.net mechanizmu refleksji. Twórca gry definiuje polecenie, które bot może wywołać po prostu pisząc oznaczoną odpowiednim atrybutem metodę, mającą je obsługiwać. Sprawdzenie czy komunikat bota dopasowuje się do zdefiniowanych poleceń, przypisanie odpowiednich parametrów wywołania i uruchomienie odpowiedniej metody, pozostają już w gestii systemu. Atrybut CommandAttribute opisuje komendy, natomiast QueryAttribute zapytania. Za pomocą mechanizmu refleksji oraz IGameValidator jesteśmy w stanie automatycznie stwierdzić, czy dana klasa implementuje logikę zgodną ze specyfikacją systemu Meridius. Sprawdzane są między innymi parametry metod (czy są typami prostymi) oraz czy wszystkie zapytania zwracają wartości lub odwrotnie, czy komendy są typu void. Bot, chcąc wywołać dane polecenie, wysyła napis złożony z nazwy metody i wartości kolejnych argumentów oddzielonych spacjami, a zakończony znakiem nowej linii. Następnie system parsuje komunikat i dopasowuje go do odpowiedniej metody. Każde prawidłowo zdefiniowane zapytanie i komenda powinny przyjmować jako pierwszy argument numer uczestnika rozgrywki. Podany numer jest dodawany do kontekstu wywołania metody automatycznie. Sprawdzenie tego wymagania z perspektywy syntaktyki również leży w gestii interfejsu IGameValidator. Pliki konfiguracyjne, w podstawowej implementacji, mają postać dokumentów w formacie XML. Zawierają definicje parametrów początkowych, końcowych oraz opisy trybów rozgrywek i typów botów. Pliki te, podczas dodawania gry, również podlegają walidacji. Następnie na ich podstawie tworzone są w bazie tabele, przeznaczone do przechowywania wartości parametrów każdej rozgrywki (wciąż mówimy o podstawowej implementacji). Po utworzeniu nowej rozgrywki parametry zapisywane są do nowej tabeli, zaś po jej zakończeniu dopisane zostają wyliczone wyniki oraz statystyki. Mechanizm jest zintegrowany z atrybutami opisującymi metody dostępne dla botów. Atrybuty CommandAttribute oraz QueryAttribute mogą być parametryzowane za pomocą nazw typów botów i trybów rozgrywek, co ogranicza dostępność wybranych metod jedynie do wskazanych wartości. Egzekwowaniem tych ograniczeń zajmuje się system. Oprócz definicji parametrów, w plikach konfiguracyjnych znajdują się także informacje o limitach czasowych dla uczestników oraz nazwa i opis gry. Pozostałe pliki przeznaczone są do wewnętrznego użytku logiki oraz aplikacji odpowiedzialnej za wizualizację. Mogą to być dowolne pomocnicze dane. Logika gry domyślnie, podczas tworzenia obiektu, otrzymuje ścieżkę do swojego katalogu roboczego. Istotne jest jednak to, że katalog i pliki w nim występujące są używane równocześnie przez wszystkie instancje danej klasy (logiki). System w żaden sposób nie kontroluje tych plików. Drugim rodzajem plików, są dowolne dane przeznaczone do użytku przez zewnętrzny system wizualizacji. Mechanizm ten został przygotowany z myślą o wszelkich grafikach lub plikach audio wykorzystywanych przez wizualizację. System Meridius domyślnie w żaden sposób nie ingeruje w te pliki. Przechowuje jedynie informację o ścieżce do głównego katalogu Przebieg pojedynczej rozgrywki Klasa RunGameContext, jak wspomniano powyżej, implementuje przebieg pojedynczej rozgrywki. Jeszcze przed utworzeniem zadania zaleca się sprawdzenie poprawności parametrów 34

35 rozgrywki za pomocą funkcji ValidateParameters, zdefiniowanej wewnątrz klasy z logiką gry. Jest to podyktowane względami praktycznymi. Kolejna walidacja następuje już po utworzeniu historii rozgrywki. Etap uruchomienia rozgrywki przebiega następująco: 1. Tworzony jest obiekt RunGameContext, który otrzymuje w konstruktorze parametry początkowe oraz, dla każdego uczestnika, instancję CommunicationService. 2. W konstruktorze, instancje IGameHistoryProvider oraz IGameService otwierają historię rozgrywki oraz zapisują parametry początkowe. 3. JobManager sprawdza dostępność zasobów dla rozgrywki. 4. Jeśli zasoby są dostępne, następuje ich rezerwacja, łącznie z zasobami CommunicationService. 5. Logika gry wykonuje metodę InitializeGame, która powinna zawierać wszystkie pracochłonne operacje, takie jak czytanie plików, alokacje pamięci itd. Metoda wyłania również uczestnika, który jako pierwszy wykonuje ruch. 6. Wszystkie instancje CommunicationService inicjalizują swoje protokoły w osobnych wątkach. Etap ten jest ograniczony czasowo przez wartość zdefiniowaną w konfiguracji gry. 7. Logika tworzy ramkę inicjalizująca wizualizację. 8. Rozpoczyna się globalne odliczanie czasu, po przekroczeniu którego rozgrywka kończona jest z błędem. W tym momencie następuje etap właściwej rozgrywki. Przebieg prawidłowej tury wygląda następująco: Jeśli aktualny uczestnik jest człowiekiem, tworzona jest ramka z widokiem, po czym jest ona przekazywana do instancji GameEventReceiver Uczestnik otrzymuje komunikat informujący o początku nowej tury. Rozpoczyna się odliczanie czasu trwania tury. RunGameContext oczekuje na komunikaty. Mogą to być komendy, zapytania, komunikaty testowe lub komunikat zakończenia tury. W przypadku zapytania, IGameMethodsProvider sprawdza poprawność metody i tworzy kontekst wywołania, po czym metoda zostaje wywołana przez logikę. Wynik zostaje zwrócony uczestnikowi. Obsługa komendy jest podobna, z tą różnicą, że kontekst wywołania zostaje włożony do kolejki, zaś uczestnik otrzymuje potwierdzenie przyjęcia komendy. Komunikat testowy, w przypadku bota w trybie testowym, zostaje odłożony do kolejki, w przeciwnym wypadku jest pomijany. W przypadku komunikatu zakończenia tury zatrzymywane jest odliczanie czasu tury, GameEventReceiver otrzymuje odłożone komunikaty debug oraz kolejno wykonywane są zachowane w kolejce komendy (poprzez wywołania odpowiednich metod logiki). Jeżeli na żadnym z etapów nie wystąpił błąd oraz nie został przekroczony limit czasu, wykonywana jest metoda logiki GameStep, w wyniku której zwracany jest nowy uczestnik otrzymujący ruch. Generowana jest ramka obserwatora (ponownie obsłużona przez IGameHistoryProvider oraz GameEventReceiver). Jeżeli na którymś z etapów wystąpi błąd lub zostanie przekroczony czas, następuje faza zamykająca rozgrywkę. Zatrzymywane jest odliczanie czasu, następuje próba przekazania nieobsłużonych komunikatów debug do obiektów GameEventReceiver i tworzona jest przez logikę ramka błędu. Jeśli błąd wystąpił z winy uczestnika, logika otrzymuje informację zawierającą 35

36 treść i rodzaj błędu. Ramka jest zapisywana oraz obsługiwana przez GameEventReceiver. Logika gry również może zgłosić błąd (wynikający na przykład ze złamania zasad) i jego obsługa przebiega identycznie jak w pozostałych przypadkach. W sytuacji gdy rozgrywka przebiegła poprawnie, logika zwraca parametry końcowe, które zostają uzupełnione o aktualne rankingi uczestników. Następnie oblicza nowe rankingi i jeśli jest taka potrzeba dokonuje ich normalizacji. W zależności od implementacji IGameHistoryProvider możliwe jest nadpisanie rankingów w bazie danych. W opisywanej wersji systemu rankingi nie są uaktualniane w przypadku rozgrywek testowych. IGameService zapisuje parametry końcowe. Generowana jest ramka podsumowująca. W tym momencie, rozgrywka dobiega końca i JobManager przystępuje do zwolnienia zasobów: zamknięcia komunikacji z uczestnikami oraz usunięcia logiki z pamięci. W trakcie trwania rozgrywki, system rozróżnia następujące rodzaje błędów: złamanie zasad zgłaszane przez logikę gry; błąd bota kod zakończenia programu inny niż 0; ucieczka program bota zakończył się z kodem 0, przed zakończeniem rozgrywki; bot przekroczył dopuszczalny czas tury; gra przekroczyła czas gdy sumaryczny czas rozgrywki został przekroczony; niedozwolona metoda metoda przeznaczona dla innego typu bota lub trybu gry; nieprawidłowa metoda metoda o podanych parametrach nie została odnaleziona; niespodziewany błąd logiki występuje, gdy obiekt logiki gry rzuci wyjątkiem; nieznany błąd występuje w sytuacji, gdy jeden z modułów systemu nie zadziałał prawidłowo, np. jeden z interfejsów lub moduł odpowiedzialny za komunikację; rozgrywka odrzucona występuje, gdy nie powiedzie się inicjalizacja protokołu CommunicationService (np. gracz odrzuci zaproszenie). 4.4 Komunikacja Temat komunikacji pojawiał się już w poprzednich rozdziałach. Poniżej, chcielibyśmy uporządkować oraz uzupełnić podane wcześniej informacje. Na kwestie związane z komunikacją można w systemie Meridius spojrzeć z kilku punktów widzenia: logiki gry (oraz jej twórcy), bota (programisty) lub gracza. Osobnym tematem jest komunikacja z systemem wizualizacji oraz kwestie dodawania i modyfikacji botów. Założeniem systemu Meridius było maksymalne uproszczenie protokołu komunikacyjnego dla twórców botów oraz twórców gier. Definicja logiki zawiera metody opisane atrybutami QueryAttribute oraz CommandAttribute, być może z nałożonymi dodatkowymi ograniczeniami dotyczącymi trybu i typu. Pierwszy argument obu rodzajów metod musi być typu int i oznaczać numer bota wykonującego polecenie. Argument ten jest automatycznie ustawiany przez system i bot nie powinien go wysyłać w poleceniu. Definiowane metody muszą być publiczne i niestatyczne. Mogą przyjmować i zwracać wyłącznie argumenty typów prostych. Każde zapytanie musi zwracać wartość, natomiast żadna komenda wartości zwracać nie może (musi posiadać typ void). Są to wszystkie wymagania stawiane twórcy logiki z punktu widzenia komunikacji. Jak wspomniano wyżej, za parsowanie, sprawdzanie uprawnień, dopasowywanie parametrów oraz wywoływanie metod, odpowiada system. Z punktu widzenia bota (uczestnika), w najprostszym przypadku, polecenia i ich rezultaty mogą być wysyłane przez standardowe wejście/wyjście. W praktyce jednak, kanał komunikacyjny może być dowolny. Po stronie sytemu znajduje się wspomniany wcześniej obiekt 36

37 CommunicationService, który implementuje metody odpowiedzialne za inicjalizację i zamknięcie kanału komunikacyjnego oraz metody czytania i pisania. Kanałem komunikacyjnym może być webservice, wejście/wyjście, TCP/IP, itp. Konieczne jest jedynie zachowanie formatu danych przekazywanych do logiki oraz ich porządku. Z punktu widzenia systemu wszystkie operacje czytania/pisania wykonywane są synchronicznie (blokująco). W danym momencie komunikować się z logiką może tylko jeden uczestnik. Inicjalizacja nowej tury zawsze pochodzi od logiki uczestnik (i CommunicationService) nie może wymusić lub zasygnalizować chęci przesłania komunikatu. Możliwe jest przesłanie tylko pojedynczego polecenia. Wszelkie próby równoczesnego wysłania kilku komend lub zapytań, muszą być symulowane przez implementację CommunicationService, ponieważ logika nie wspiera kolejkowania poleceń. Dodatkowo komunikacja jest stanowa i z punktu widzenia architektury dwustronna, a wszystkie komunikaty pozostają bez odpowiedzi, ponieważ każda odpowiedź na zapytanie lub potwierdzenie komendy ma miejsce jako osobny komunikat od logiki. Zastosowanie warstwy pośredniej, w postaci abstrakcyjnej klasy do zaimplementowania, było niezbędne do ustanowienia jednakowego protokołu dla graczy oraz botów. Zastosowanie pojedynczej klasy oczekującej komunikatów wyłącznie na standardowym wejściu/wyjściu wymagałoby dodatkowych, nienaturalnych obejść w celu zapewnienia wygodnej komunikacji dla graczy. Zgodnie z naszym założeniem, gracze nie powinni podawać komendy w postaci tekstu, gdyż może to prowadzić do błędów oraz odbiega od graficznych interfejsów, do których w większości przypadków przywykli. System wizualizacji jest ściśle związany z tematem gry manualnej. W teorii możliwe jest ustalenie bardzo wysokich limitów czasowych w konfiguracji gry i rozgrywanie partii za pomocą wyłącznie komend i zapytań, używając jednego kanału komunikacyjnego. Nie jest to jednak wygodne, ani tym bardziej eleganckie. Ponieważ system Meridius nie posiada informacji o sposobie wizualizacji rozgrywki, jego działania ograniczają się do żądania od logiki gry ramek poszczególnych tur oraz ich zapisu za pomocą IGameHistoryProvider. Po zakończeniu rozgrywki (lub w trakcie jej trwania), system wizualizacji, za pomocą tego samego interfejsu, może pobierać zapisane ramki z perspektywy obserwatora (tylko ten typ ramek jest zachowywany w bazie). Każda tura rozgrywki (ramka) jest zapisywana w postaci tekstowej. Format tego tekstu zależy wyłącznie od ustaleń twórców gier i twórcy systemu wizualizacji. Dla zapewnienia obsługi ramek graczy dodano klasę GameEventReceiver. Po utworzeniu każdej ramki jest ona przekazywana do instancji zarejestrowanych klas, dziedziczących po GameEventReceiver. Razem z ramką podawana jest referencja do obiektu CommunicationService aktywnego bota. Dzięki temu rozwiązaniu możliwa jest implementacja komunikacji z graczem na poziomie wizualizacji, a nie tylko zapytań. Również implementacja GameEventReceiver umożliwia modyfikacje ramek w celu dopasowania ich do nowej wizualizacji, bez konieczności wprowadzania zmian w logice gry. Ostatni akapit został poświęcony komunikacji z punktu widzenia zarządzania botami. System Meridius nie zapewnia żadnej gotowej funkcjonalności w tym zakresie. Chcieliśmy, żeby Meridius był zdolny do obsługi botów z jak największej liczby źródeł. Aby to zapewnić nie wymuszaliśmy żadnego konkretnego protokołu tworzenia botów lub ich uruchamiania. IBotProvider posiada jedynie metody umożliwiające zapis danych bota, takich jak autor, typ, przebyte rozgrywki itd. Umożliwia również przechowywanie kodu źródłowego. Dodatkowo, posiada odniesienie do obiektu reprezentującego język programowania. Za przechowywanie tych informacji odpowiada ILanguageProvider. Domyślnie przechowuje on następujące informacje o językach programowania: nazwa, rozszerzenia plików, komenda kompilacji oraz komenda uruchomienia. Nie jest jednak zaimplementowana żadna biblioteka korzystająca bezpośrednio z tych danych. Podczas tworzenia rozgrywki, obiekt CommunicationService odpowiada za inicjalizację bota. Nie dostaje on bezpośrednio podanych powyżej informacji gdyż nie umiemy przewidzieć jakie dane będą mu potrzebne. Zamiast tego posiada on dostęp do EngineFactory, za pomocą którego może 37

38 utworzyć odpowiednią implementację interfejsu i pobrać dane niezbędne do uruchomienia bota. Przykład takiego mechanizmu jest opisany w następnym podrozdziale. 4.5 Aplikacje zewnętrzne Architektura opisana powyżej przedstawiała jedynie możliwości, jakie oferuje system Meridius. Poniżej znajduje się opis gotowych aplikacji oraz zaimplementowanych modułów, które zostały wykorzystane do stworzenia przykładowego serwisu WWW z grami programistycznymi (opisanego w rozdziale 5). Opisywaną wersję systemu będziemy skrótowo nazywać portalem Meridius, w odróżnieniu od systemu Meridius, który jest jedynie pewnego rodzaju API. Portal Meridius jest aplikacją internetową uruchamianą na serwerze Windows IIS (w wersji 6. lub 7.). Korzysta z ośmiu podstawowych implementacji interfejsów (omówionych w rozdziale 4.2) i wszystkie dane przechowuje w bazie MSSQL. Na potrzeby portalu, zaimplementowano klasę CompileBotJob umożliwiającą kompilację botów w bezpiecznym środowisku Virtual Safe Slots (w skrócie VSS). Klasa ta dziedziczy po JobDefinition. Zdefiniowano również klasę VSSRunGameContext rozszerzającą RunGameContext o własną implementację rezerwacji i zwalniania zasobów. Za komunikację z VSS w trakcie trwania rozgrywki odpowiada obiekt klasy ProxyReader, dziedziczący po CommunicationService. Aplikacją do wizualizacji oraz gry manualnej jest Turnip plugin stworzony we flashu. Klasy TurnipReader oraz TurnipEventReceiver, implementujące odpowiednio CommunicationService oraz GameEventRecevier, odpowiadają za komunikację z graczem oraz przekazywanie mu ramek z trwającej rozgrywki. Opis strony wizualnej portalu znajduje się w rozdziale Virtual Safe Slots i Proxy Virtual Safe Slots (VSS, [8]) jest aplikacją przygotowaną na system Linux i służącą do uruchamiania programów w bezpiecznym środowisku. Tworzy on wirtualne maszyny (tzw. sloty), z którymi można się komunikować za pomocą potoków systemowych oraz przesyłając pliki. Programy uruchamiane wewnątrz slotów VSS mają pełny dostęp do zasobów oferowanych przez maszynę, z wykluczeniem komunikacji sieciowej. Na nasze potrzeby, w wirtualnym systemie tworzonym przez VSS zainstalowano szereg popularnych kompilatorów oraz interpreterów języków programowania, umożliwiając uruchamianie oraz kompilację botów użytkowników. Kiedy użytkownik chce dodać kod źródłowy bota do systemu tworzony jest obiekt BotCompilationJob. Cała komunikacja odbywa się, za pomocą protokołu SSH, pomiędzy serwerem Meridiusa a pomocniczym serwerem linuksowym. Ponieważ liczba slotów VSS jest ograniczona, przed rozpoczęciem zadania sprawdzana jest ich dostępność. W przypadku powodzenia, obiekt rezerwuje pojedynczy slot pobierając od niego unikatowy klucz sesji. Każda komenda wysłana do slotu wymaga podania tego klucza. Wykonanie zadania polega na wysłaniu źródeł bota za pomocą linuksowej komendy scp, a następnie, korzystając z danych dostarczonych przez implementację ILanguageProvider, komendy kompilacji. Jeśli operacja się powiedzie, aby nie wykonywać kompilacji przed każdym uruchomieniem rozgrywki, skompilowana wersja binarna lub zweryfikowane źródła są kopiowane do odpowiedniego folderu na pomocniczym serwerze. W przypadku błędu, jego treść jest zwracana do portalu i udostępniana użytkownikowi. Ostatecznie następuje zwolnienie slotu oraz zamknięcie kanału SSH. Uruchamianie bota oraz komunikacja z nim są nieco bardziej skomplikowane. Oprócz wcześniej wymienionych elementów systemu, w komunikacji pośredniczy dodatkowa aplikacja zwana Proxy. Jest to element portalu Meridius znajdujący się na serwerze pomocniczym, który odpowiada za komunikację między znajdującym się w slocie botem a obiektem ProxyReader. Proxy 38

39 jest programem napisanym w języku Python (wcześniejsza jego implementacja stworzona była w C++), wysyłającym i odbierającym komunikaty pomiędzy serwerami za pośrednictwem protokołu TCP/IP. Dla każdego grającego bota uruchamiana jest oddzielna instancja programu Proxy. W sytuacji gdy użytkownik tworzy rozgrywkę w portalu, po stronie kodu wykonywane są następujące operacje: Tworzony jest obiekt VSSRunGameContext reprezentujący rozgrywkę. Obiekt rozgrywki rezerwuje po jednym slocie dla każdego bota, tworzy obiekty ProxyReader, otwiera połączenia SSH oraz zaczyna nasłuchiwać na przydzielonym porcie TCP. ProxyReader, podczas protokołu inicjalizacji, uruchamia za pomocą SSH aplikację Proxy z parametrami zawierającymi m.in. następujące informacje: numer uruchamianego bota, adres IP i port służący do komunikacji, klucz sesji slotu VSS oraz informację o trybie testowym rozgrywki. Dalsza komunikacja odbywa się po TCP/IP. Proxy kopiuje binaria bota do przydzielonego slotu i wysyła swój PID (ang. process id) do obiektu ProxyReader. ProxyReader w odpowiedzi wysyła komendę uruchomienia bota, którą następnie wykonuje Proxy wewnątrz slotu VSS. W przypadku niepowodzenia zwracany jest kod błędu, natomiast w przypadku poprawnego zakończenia operacji, proces bota jest wstrzymywany. Inicjalizacja dobiega końca i rozpoczyna się normalna wymiana komunikatów pomiędzy botem a logiką gry. Konstrukcja tego etapu jest już o wiele prostsza. Logika gry przekazuje komunikaty do obiektu ProxyReader, a następnie kanałem TCP/IP są one wysyłane do Proxy. Proxy przekazuje je na standardowe wejście bota lub, w przypadku komunikatów systemowych, podejmuje stosowne działania. Komunikatami systemowymi są: początek tury Proxy uruchamia wstrzymany proces bota; koniec tury proces bota zostaje wstrzymany; komenda prawidłowa ponieważ bot wysłał prawidłową komendę, Proxy może wysłać następny jego komunikat; zapytanie prawidłowe Proxy przekazuje botowi odpowiedź od logiki oraz przystępuje do wysyłania kolejnych komunikatów. Dodatkowo Proxy sprawdza czy komunikaty od bota są wiadomościami trybu testowego. Jeśli rozgrywka nie jest uruchomiona w trybie testowym, w celu zmniejszenia liczby komunikatów, wiadomości te nie są w ogóle wysyłane do logiki. W przypadku wystąpienia błędu bota, Proxy przekazuje informację o błędzie oraz jego typie, zgodnie z rozróżnieniem wymienionym w poprzednim podrozdziale. Jeżeli rozgrywka zakończyła się prawidłowo następuje zwolnienie zasobów: zamykany jest kanał TCP/IP, po SSH wysyłana jest komenda zwalniająca slot, unicestwiany jest proces Proxy oraz, ostatecznie, zamykane jest połączenie SSH Turnip wizualizacja oraz gra manualna Turnip ([3]) to plugin do przeglądarek internetowych, stworzony w technologii Flash. Osadzony na stronie, pobiera z osobnych plików XML konfigurację oraz zapis animacji do wyświetlenia. Z punktu widzenia odtwarzania rozgrywki mechanizm jest bardzo prosty. Podczas osadzania wtyczki na stronie, w parametrach, podawany jest odnośnik do pliku z zapisem animacji 39

40 reprezentującej rozgrywkę. Z punktu widzenia systemu Meridius nie ma czegoś takiego jak plik z zapisem rozgrywki. Za pomocą IGameHistoryProvider zapisywane są osobne ramki. Za utworzenie takiego pliku odpowiada TurnipEventReceiver, który po zakończeniu rozgrywki pobiera wszystkie ramki i zapisuje je w dedykowanym folderze, do którego ma dostęp Turnip. Mechanizm gry manualnej jest odrobinę bardziej skomplikowany. Turnip, w trybie rozgrywki online, udostępnia okno do wprowadzania oraz wyświetlania komunikatów. Z pomocą tej konsoli można symulować zachowania bota wysyłając komendy oraz zapytania. Nie jest to najwygodniejsza forma rozgrywki, na szczęście nie jedyna udostępniana przez Turnipa. Umożliwia on także dodanie oraz skonfigurowanie własnych przycisków, do których można przypisać dowolne napisy wysyłane tak, jakby zostały wprowadzone z konsoli. Pozwala to podpiąć komendy lub zapytania wraz z parametrami i w ten sposób zwiększyć wygodę gracza oraz przyspieszyć nieco rozgrywkę. Komunikaty wysyłane są przez Turnipa za pośrednictwem protokołu HTTP. Po stronie portalu Meridius znajduje się klasa TurnipHandler implementująca IHttpHandler, interfejs platformy.net odpowiedzialny za obsługę zapytań GET i POST HTTP. Obiekt TurnipHandler sprawdza czy komunikat pochodzi od właściwego użytkownika i czy dotyczy właściwej gry. Jeśli tak, odnajduje w pamięci odpowiednią instancję klasy TurnipReader przypisaną do danego gracza oraz przekazuje mu komunikat. Inicjalizacja gracza jest prostym procesem, który polega na wysłaniu do użytkownika zaproszenia do gry, widocznego w panelu bocznym portalu Meridius. Gracz akceptuje lub odrzuca rozgrywkę wysyłając odpowiednie zapytanie HTTP obsługiwane przez TurnipHandler i przekazywane do TurnipReader. Należy tutaj obiektywnie zaznaczyć, że mechanizm ten jest wyjątkowo nieelegancki. Protokół komunikacji jaki implementuje system Meridius dla wszystkich gier i uczestników jest przede wszystkim protokołem stanowym. Obie strony (uczestnik oraz logika gry) mają prawo wysłać komunikat. Logika gry, na początku tury, wysyła informację do uczestnika, że ten ma prawo ruchu. Następnie uczestnik wysyła komendę lub zapytanie. Wysłanie tego komunikatu nie wiąże się z natychmiastowym otrzymaniem odpowiedzi zamiast tego, logika gry ponownie inicjuje połączenie wysyłając nowy komunikat, zawierający odpowiedź na poprzednią wiadomość. Turnip korzysta z protokołu HTTP, który jest bezstanowy i dodatkowo może być inicjowany wyłącznie przez przeglądarkę uczestnika. Dodatkowym utrudnieniem jest fakt, że tym samym kanałem Turnipowi należy wysyłać odpowiedzi na zapytania i komendy oraz ramki gracza. Obejście tych ograniczeń było możliwe poprzez wysyłanie w równych odstępach czasu zapytań protokołu HTTP. W ten sposób pozyskiwana jest informacja czy są już dostępne nowe ramki lub odpowiedzi na dotychczas wysłane komunikaty. 4.6 Testy i organizacja pracy Bardzo duża zależność systemu Meridius od zewnętrznych aplikacji oraz duża elastyczność pod względem wymiany poszczególnych modułów wymaga od nas, aby poruszyć temat testowania i organizacji pracy. Pierwszym etapem prac nad systemem było przygotowanie specyfikacji wymagań, jakie system Meridius miał spełniać. Wbrew pozorom, etap planowania oraz prac koncepcyjnych był bardzo pracochłonny i zajął dużą część czasu. Zaowocowało to jednak płynnym przejściem do etapu projektowania architektury oraz pisania kodu. Podczas przygotowywania architektury i założeń systemu nie znaliśmy specyfikacji VSS oraz nie wiedzieliśmy o istnieniu Turnipa. Etap planowania polegał na systematycznych spotkaniach w celu iteracyjnego doprecyzowania poszczególnych elementów systemu, dokumentowaniu najważniejszych postanowień na portalu typu wiki (w postaci szkiców dokumentacji oraz otwartych problemów) i poszukiwaniu rozwiązań technologicznych, które najlepiej spełnią nasze wymagania. Na etapie pisania kodu zastosowaliśmy technikę programowania przyrostowego, zaczynając 40

41 od elementów najbardziej wrażliwych, czyli komunikacji z zewnętrznym środowiskiem. Jedna osoba odpowiedzialna była za rozwój kodu po stronie serwera głównego, zaś druga za kod umieszczony na serwerze pomocniczym oraz testy i zgłaszanie błędów. Do zgłaszania błędów oraz aktualnych zadań wykorzystywany był ten sam portal wiki, który wcześniej służył do opisywania najważniejszych elementów specyfikacji. Do wersjonowania kodu używane było prywatne repozytorium SVN. Ze względu na ograniczony czas, główny nacisk został położony na testy funkcjonalne. Przygotowaliśmy zestaw botów oraz gier programistycznych, które odpowiadały za przetestowanie większości popularnych błędów, jakie mogą wystąpić ze strony implementacji logiki lub bota. Kiedy prace nad systemem wkroczyły w bardziej zaawansowaną fazę przystąpiliśmy do implementacji testowej zawartości w postaci gotowych gier programistycznych oraz portalu internetowego. Położyliśmy duży nacisk na testy użyteczności, uwzględniające również osoby z zewnątrz. Mimo, iż sam portal nie wchodzi w skład systemu Meridius, docelowo jedna z implementacji ma opierać się na serwisie internetowym. Stąd bardzo istotne było dostosowanie systemu od strony architektonicznej oraz API do potencjalnych potrzeb, jakie pojawią się podczas pisania kolejnych wersji tego rodzaju interfejsu użytkownika. Po implementacji każdej kluczowej funkcjonalności oraz przejściu do kolejnego etapu, sporo czasu było poświęcane na refaktoryzację kodu oraz testy regresyjne. Również wtedy jedna osoba była odpowiedzialna za refaktoryzację, druga za testowanie. Na koniec chcielibyśmy dodać, że chociaż temat testowania nie był traktowany dostatecznie systematycznie, wynikało to poniekąd z ustalonego planu pracy. Zakłada on przygotowanie dla deweloperów, twórców gier i twórców botów zestawu aplikacji, które w dużej mierze będą implementować narzędzia służące do testowania poszczególnych elementów systemu. 4.7 Alternatywne rozwiązania i potencjalne rozszerzenia Ostatnim zagadnieniem, które chcielibyśmy poruszyć, są inne rozwiązania projektowe jakie braliśmy pod uwagę przy realizacji założeń z rozdziału 3. W fazie projektowej rozwoju systemu rozważane było osadzenie Meridiusa na innej platformie programistycznej, a także odmienne sposoby implementacji logik gier oraz obsługi botów. Zdecydowaliśmy się na implementację serca systemu w platformie.net. Decydującym kryterium była możliwość wykorzystania mechanizmu refleksji oraz doświadczenie w pracy w tym środowisku z poprzedniego projektu (wspomniana wcześniej gra programistyczna QUAIKE). Mechanizm tożsamy z Reflection z.net posiada na przykład Java. Główną zaletą użycia tego środowiska byłaby możliwość używania systemu Meridius na platformie innej niż systemy rodziny Windows. W przypadku platformy.net można obejść to ograniczenie używając nieoficjalnych implementacji tej platformy, na przykład Mono. Ze względu na wykorzystanie niestandardowych bibliotek system Meridius nie jest jednak w pełni kompatybilny z takimi rozwiązaniami. Dodatkowo, istnieje kilka cech platformy Java, które przemawiają na niekorzyść tego rozwiązania. Przede wszystkim, podczas implementacji logik gier ich twórcy zostaliby ograniczeni tylko do jednego języka programowania. Java, dzięki apletom, mogłaby umożliwić dobrą integrację z portalem WWW, jednak takie same możliwości integracji zapewni Microsoft Silverlight, który jest również dostępny dla systemów Linux pod nazwą Moonlight. Kwestie dotyczące wydajności bytecode u Javy oraz Microsoft CIL (ang. Common Intermediate Language) w tym wypadku pominęliśmy. Osiągnięcie mechanizmu dynamicznego wywoływania metod podobnego do mechanizmu refleksji, byłoby również możliwe za pomocą języka Python, który jest beztypowym językiem skryptowym. Wywołanie komendy lub zapytania logiki gry polegałoby na dynamicznym zbudowaniu kodu, a następnie jego wykonaniu. Język Python, podobnie jak Java, jest dostępny na platfor- 41

42 mach Windows oraz Linux. Co więcej, Python jest coraz silniej wykorzystywany w aplikacjach internetowych, co ułatwiałoby tworzenie portalu Meridius. Z drugiej strony ponownie ograniczylibyśmy twórców logik gier do jednego języka programowania. Dodatkowo, to rozwiązanie wymagałoby od nas dużej ostrożności w kwestii bezpieczeństwa. Złośliwy twórca bota, posiadając wiedzę o implementacji systemu Meridius, mógłby próbować tak preparować polecenia bota, aby wywołać niechciany przez nas kod metodą XSS (ang. cross-site-scripting). Również definicje komend oraz zapytań musiałyby się znajdować w osobnych plikach w celach walidacji poleceń. Powyższe rozważania zakładały, że logiki gier będą uruchamiane w kontekście systemu, a nie jako zewnętrzne aplikacje. Wynikało to głównie z chęci zdjęcia z twórcy gry obowiązku obsługiwania komunikatów. Gdyby pominąć to założenie, można brać pod uwagę rozwiązania, w których cała komunikacja odbywa się poprzez wejście/wyjście również z punktu widzenia logiki gry. Zaletą takiego rozwiązania byłoby tworzenie gier w dowolnym języku programowania i uruchamianie ich w zewnętrznym środowisku (np. w VSS). Stracilibyśmy jednak dużą część kontroli nad rozgrywką, znacznie trudniejsze byłoby przekazywanie parametrów początkowych, pobieranie parametrów końcowych oraz ramek. Za przestrzeganie kolejności wykonywania etapów pojedynczej tury byłby w dużej mierze odpowiedzialny twórca gry. Znacznie trudniejsze byłoby również testowanie takiej aplikacji. Ponadto nawet jeśli system Meridius, na podstawie jakiejś zewnętrznej konfiguracji, byłby w stanie sprawdzić poprawność komunikatu od bota, twórca gry i tak musiałby dokonać ręcznego jej parsowania i dopasowania. Ilość niepotrzebnego kodu wzrosłaby znacząco. Jest jeszcze jeden aspekt, który był brany pod uwagę. W przyszłości chcielibyśmy udostępnić aplikację uruchamianą lokalnie, wykorzystującą system Meridius i przeznaczoną do testowania botów oraz logik gier przez ich twórców. Konieczność uruchamiania dodatkowych aplikacji implementujących logikę mogłoby znacząco utrudnić instalację takiego programu, co byłoby wbrew jednemu z podstawowych założeń projektu. Na koniec dodamy tylko, że w obecnej postaci, dzięki modułowej architekturze, system Meridius umożliwia realizację takiego scenariusza. Wymagałoby to odpowiedniej implementacji klasy JobDefinition oraz interfejsów IGameValidator, IGameMethodsProvider, IGameProvider i IGameService, które w przeciwieństwie do RunGameContext nie ładowałaby dynamicznie bibliotek w kodzie zarządzanym, zamiast tego uruchamiając zewnętrzną aplikację. Odmienne podejście zastosowaliśmy w przypadku botów, ponieważ zależało nam na zainteresowaniu jak największej liczby potencjalnych użytkowników. Pod uwagę brane były rozwiązania w których: definiujemy własny język programowania dla wszystkich gier, oczekujemy botów realizowanych również jako biblioteki uruchamiane wewnątrz procesu systemu Meridius lub pozostawiamy deweloperom pełną dowolność. Większość gier programistycznych (między innymi opisanych w 2.2) stosuje jedno z dwóch pierwszych podejść. Posiadają one kilka ogromnych zalet, które są oczywiście bardzo podobne do tych, którymi argumentowaliśmy naszą realizację obsługi logik gier. Pierwszą, dość ogólną, jest posiadanie dużej kontroli nad uruchamianym botem. Jesteśmy w stanie udostępnić twórcy bota bieżący podgląd wszystkich użytych przez niego zmiennych, a także umożliwić pauzowanie i wznawianie działania bota oraz przechodzenie przez poszczególne jego instrukcje, krok po kroku. W przypadku naszego rozwiązania twórca bota jest ograniczony, na dzień dzisiejszy, tylko do debugowania na poziomie komunikatów ze standardowego wyjścia, które sam zdefiniuje. Drugą zaletą rozpatrywanego rozwiązania jest zwiększone bezpieczeństwo. Większa kontrola umożliwia łatwiejsze przeciwdziałanie niechcianym operacjom. Kolejnym plusem jest możliwość udostępnienia dedykowanego pod daną grę API, które może przyspieszyć tworzenie botów. W przypadku systemu Meridius, te zalety mogłyby się okazać niewystarczające. Tworząc własny język najprawdopodobniej zbyt mocno ograniczylibyśmy rodzaje gier, jakie można zaimplementować w systemie. Na przykład, ze względu na zbyt ubogą siłę ekspresji języka w kontekście algorytmu grającego w potencjalną grę. Natomiast w przypadku zastosowania pojedynczego, komercyjnego języka programowania, ograniczylibyśmy liczbę potencjalnych twórców botów. Byłyby to jedynie osoby znające już ten język lub zmotywowane do nauczenia 42

43 się kolejnej składni oraz zainstalowania niezbędnych narzędzi. Biorąc pod uwagę fakt, że gry programistyczne są dziedziną niszową, byłaby to zbyt wysoka cena. Jednocześnie warto zwrócić uwagę, że i w tym przypadku nie ma problemu, aby za pomocą odpowiedniej implementacji CommunicationService oraz klasy dziedziczącej po JobDefinition, służącej dodawaniu botów, udostępnić obydwie powyższe funkcjonalności. Ostatnimi tematami, które chcielibyśmy poruszyć, są kwestie związane z potencjalnymi rozszerzeniami systemu Meridius z punktu widzenia architektury. Są trzy aspekty, które chcemy w tym miejscu omówić. Pierwszym jest dalszy rozwój modułowej architektury. Drugim, rozwój systemu Meridius w stronę systemu rozproszonego. Natomiast trzecim, rozwój dodatkowych aplikacji przeznaczonych dla twórców botów oraz logik. W tej chwili, wiele elementów systemu można wymienić poprzez własne implementacje interfejsów. Jednak system wciąż wymaga do działania serwera MSSQL. Wynika to z tego, że EngineFactory zapisuje wszystkie informacje o zarejestrowanych modułach również w bazie danych. W przyszłości chcielibyśmy umożliwić całkowitą dowolność w implementacji warstwy danych, która obecnie jest możliwa tylko na poziomie wcześniej wymienionych ośmiu interfejsów. Dodatkowo, chcielibyśmy umożliwić rejestrowanie dedykowanych interfejsów oraz implementacji GameEventReceiver pod konkretne gry. W opisywanej wersji systemu, możliwe jest zarejestrowanie tych klas wyłącznie globalnie. System Meridius uruchamia w tej chwili wszystkie rozgrywki w ramach pojedynczego procesu, w osobnych wątkach. Ze względu na ograniczoną ilość zasobów (mieliśmy dostęp wyłącznie do dziesięciu slotów VSS) nie byliśmy w stanie przetestować wydajności systemu pod względem dużej liczby równoczesnych rozgrywek, jednak zdrowy rozsądek podpowiada nam, że dość szybko okaże się to wąskim gardłem aplikacji. W przyszłości chcielibyśmy, aby implementacje JobDefinition mogły być uruchamiane w osobnych procesach roboczych, być może na innych maszynach. Do osiągnięcia tego celu zamierzamy posłużyć się narzędziem Power Shell 2.0, które udostępnia między innymi serializację oraz zdalne wywoływanie poleceń. Poprzez aplikacje pomocnicze rozumiemy wszelkie programy wspierające twórców gier oraz botów. Obecnie, twórca logiki gry nie posiada żadnego wsparcia ze strony systemu Meridius w kwestii testowania gry. Jedyną możliwością jest pisanie własnych testów oraz ręczne sprawdzanie poprawności ramek wizualizacji. W celu przetestowania prawidłowego cyklu tury konieczne jest dodanie gry do istniejącego systemu (na przykład portalu) i obserwowanie logów lub korzystanie z debuggera. Twórca bota jest jeszcze w gorszej sytuacji, ponieważ jest ograniczony do korzystania komunikatów debug, a funkcjonalność ta jest dostępna dopiero po dodaniu bota do systemu. W związku z tym, każdy wykryty w procesie testowania błąd skutkuje aktualizacją bota, co jest nieefektywne zarówno z punktu widzenia wygody użytkownika, jak i liczby przechowywanych w systemie danych. Dlatego planujemy przygotować odpowiednie aplikacje, umożliwiające lokalne testowanie poprawności i wydajności tworzonych przez użytkowników elementów systemu. 5 Testowa zawartość systemu Zadaniem systemu Meridius jest udostępnienie wyspecyfikowanych i opisanych w poprzednich rozdziałach funkcjonalności. Ponieważ jednak są one związane z przetwarzaniem pewnych danych (gier, botów), aby móc z tych funkcjonalności korzystać potrzebna jest pewna początkowa zawartość. Zarówno gra manualna, jak i za pośrednictwem botów, jest możliwa dopiero wówczas, gdy w systemie znajdują się już jakieś gry. Zauważmy również, że system został zaprojektowany tak, aby móc współpracować z wieloma interfejsami użytkownika, jednak żadna implementacja interfejsu nie wchodzi bezpośrednio w skład Meridiusa. Z tego powodu, w trakcie 43

44 tworzenia systemu, konieczne było stworzenie zawartości, którą można określić jako testową lub przykładową, umożliwiającej jego testowanie. W tym rozdziale znajduje się opis stworzonej przez nas testowej zawartości Meridiusa: gier programistycznych, botów oraz przykładowego interfejsu użytkownika w postaci strony internetowej, a także wykorzystywanych do testów języków programowania. Przedstawione zostały tylko elementy kompatybilne z aktualną wersją systemu. Wcześniej wykorzystywaliśmy interfejs użytkownika w postaci aplikacji windowsowej, powstały także dwie gry programistyczne, w tym jedna służąca wyłącznie testowaniu odporności systemu na błędy w działaniu logik. Na pewnym etapie prac elementy te przestały być jednak potrzebne i nie były już dalej rozwijane. 5.1 Gry programistyczne Do testowej zawartości systemu Meridius włączyliśmy cztery gry programistyczne. Wśród nich znajdują się zarówno proste implementacje znanych gier, jak i bardziej rozbudowane projekty wykorzystujące zaawansowane mechanizmy Meridiusa: parametryzowanie rozgrywek, obsługę kilku wariantów zasad i przypisywanie uczestnikom różnych ról. Wybrane gry wykorzystują różne typy interakcji pomiędzy uczestnikami grę dla jednego gracza, dla wielu współzawodniczących graczy (przy czym ich liczba może być stała lub nie) oraz wymagającą od graczy kooperacji. Pozwoliło nam to na doszczegółowienie ograniczeń, które system narzuca grom oraz doprecyzowanie metody ich umieszczania w systemie, w oparciu o praktyczne doświadczenia. Jednym z celów Meridiusa było uproszczenie i przyspieszenie procesu tworzenia gier programistycznych. Cel ten został osiągnięty implementacja każdej z logik przedstawionych gier trwała od jednego do trzech dni pracy programisty. Mankamentem jest jednak czas tworzenia wizualizacji rozgrywki, na który główny wpływ ma interfejs wykorzystywanej przez system zewnętrznej aplikacji. Przydatna byłaby także aplikacja wspomagająca testowanie gier. W przypadku jej braku, testy muszą być wykonywane dopiero po umieszczeniu gry w systemie lub wymagają napisania własnych klas testujących. Pomimo tych wad, zaplecze które zapewnia Meridius (tworzenie rozgrywek, bezpieczne uruchamianie botów, interfejs użytkownika, zarządzanie statystykami) jednoznacznie sprawia, że zaimplementowanie gry przeznaczonej do tego systemu jest o wiele prostsze, niż stworzenie samodzielnej aplikacji oferującej takie same funkcjonalności Kółko i krzyżyk Jest to implementacja standardowej gry w kółko i krzyżyk, rozgrywanej pomiędzy dwoma uczestnikami na planszy o wymiarach 3 3 (wizualizacja rozgrywki przedstawiona jest na rysunku 5). Gra umożliwia zapoznanie się w prosty sposób z zasadami działania systemu. Uczestnicy mają możliwość odpytania o swoją rolę, numer aktualnej tury, zawartość każdego z pól planszy oraz współrzędne pola na którym został postawiony ostatni symbol. W każdej turze uczestnik musi dokładnie raz zadeklarować (wywołując odpowiednią komendę) postawienie symbolu na jednym z pól leżących na planszy. Każdy ruch niezgodny z zasadami jest traktowany jako błąd uczestnika przerywający rozgrywkę. Ranking liczony jest w systemie Elo [41], a nowi gracze startują z rankingiem Po każdym meczu generowane są proste statystyki dotyczące każdego uczestnika. Zawierają one informacje o liczbie ruchów blokujących wygraną przeciwnika, liczbie założonych widełek, itd. Szczegółowy opis zasad i interfejsu użytkownika oraz programisty znajduje się w [10]. 44

45 Rysunek 5: Wizualizacja rozgrywki w grę Kółko i Krzyżyk. Umieszczone w systemie przykładowe boty realizują proste strategie w różnym stopniu korzystając z losowości Wumpus Gra Wumpus, oparta na grze komputerowej Hunt the Wumpus z 1972 roku, jest często wykorzystywana w sztucznej inteligencji do demonstracji metod wnioskowania logicznego opartego na wiedzy. Uczestnik wciela się w niej w poszukiwacza skarbu przemierzającego labirynt zamieszkały przez tajemniczego potwora Wumpusa. W naszej implementacji (szczegóły w [13], wizualizacja rozgrywki przedstawiona jest na rysunku 6) labirynt ma postać siatki o wymiarach 5 5. Na planszy znajduje się wejście do labiryntu, złoto, Wumpus i losowo rozmieszczone przepaście. Na uczestnika, zajmującego konkretne pole, działają percepty umożliwiające orientację w labiryncie. Informują one czy gracz stoi na polu ze złotem oraz czy na przyległych polach znajduje się Wumpus lub przepaść. Na tej podstawie uczestnik musi podjąć decyzję: czy przemieścić się na któreś z sąsiednich pól, wystrzelić swoją jedyną strzałę w kierunku, w którym podejrzewa, że znajduje się Wumpus, podnieść złoto, czy też wyjść z labiryntu. Wejście na pole z przepaścią lub żywym Wumpusem oznacza przegraną uczestnika. Rysunek 6: Wizualizacja rozgrywki w grę Wumpus. 45

46 Zaimplementowane przez nas przykładowe boty analizują percepty i obliczają prawdopodobieństwo zagrożenia występującego na każdym z pól. Jeżeli uznają, że istnieje w miarę bezpieczna możliwość dalszej eksploracji labiryntu to ją wykorzystują. W przeciwnym wypadku oraz po odnalezieniu złota, wycofują się do wyjścia. Strzelają jedynie wówczas, gdy pozycja Wumpusa jest w stu procentach pewna. Boty oparte są na tym samym szablonie i różnią się między sobą jedynie skłonnością do podejmowania ryzyka. W załączniku D.1 znajduje się bardziej rozbudowany opis algorytmu i porównanie skuteczności działania botów Skarb Labiryntu Skarb labiryntu (pełny opis w [12]) jest grą autorską, wymyśloną na potrzeby Meridiusa. Rozgrywka toczy się pomiędzy dwoma uczestnikami posiadającymi odmienne role. Jeden z graczy (poszukiwacz) przemierza planszę w poszukiwaniu drogi do skarbu (umiejscowienie skarbu jest jawne), natomiast drugi (architekt) utrudnia mu to zadanie stawiając na jego drodze przeszkody. Zasady gry zabraniają architektowi całkowitego zablokowania drogi pomiędzy poszukiwaczem a skarbem oraz stawiania przeszkód w ich bezpośrednim sąsiedztwie. Wynik rozgrywki zależy od czasu, w jakim uda się poszukiwaczowi zrealizować swój cel. Każda tura zwłoki skutkuje odebraniem punktów poszukiwaczowi i przekazaniem ich na konto architekta. Istnieją dwa warianty zasad. W pierwszym, poszukiwacz posiada magiczną mapę labiryntu, przez co obaj gracze znają pełny stan gry. W drugim, nieposiadający mapy poszukiwacz zna rozkład przeszkód jedynie w swojej okolicy. Rysunek 7: Wizualizacja rozgrywki w grę Skarb Labiryntu. Zasady gry zostały skonstruowane w taki sposób, aby umożliwić przetestowanie kluczowych funkcjonalności związanych z parametryzowaniem rozgrywek. Plansza jest kwadratem o długości boku z przedziału od 5 do 20 i liczbę tę, definiującą rozmiar labiryntu, należy podać jako parametr startowy każdorazowo podczas tworzenia nowej rozgrywki. Zgodność typów uczestników (na pierwszej pozycji musi się znajdować architekt, a na drugiej poszukiwacz) również jest sprawdzana przed uruchomieniem meczu. Gra definiuje zarówno polecenia, z których może korzystać każdy (np. zapytanie o rozmiar labiryntu) jak i takie, które może wywołać jedynie uczestnik o odpowiednim typie (np. zablokowanie danego pola). Gra definiuje także obostrzenia związane z trybem gry: poszukiwacz skarbu może obejrzeć mapę labiryntu (co wiąże się z wywołaniem odpowiedniego polecenia) jedynie grając w trybie z pełną informacją. 46

47 Algorytmy zastosowane dla przykładowych botów zależą oczywiście od ich typu. Architekci prezentują dwie strategie: konstruują labirynt według określonego schematu lub tworzą go na bieżąco, starając się blokować możliwe ścieżki poszukiwacza. Poszukiwacze skarbu, w trybie z pełną informacją, korzystają z podstawowych algorytmów BFS oraz DFS, wyznaczając losowe ścieżki prowadzące do skarbu. Porównanie skuteczności zastosowanych algorytmów oraz ich szerszy opis znajduje się w załączniku D Robosseum Robosseum jest najbardziej rozbudowaną z zaimplementowanych gier. Jest to autorska gra typu walki robotów fabularnie nawiązująca do nazwy systemu (etymologia nazwy Meridius opisana jest w załączniku B), dotyczy więc potyczek toczonych na arenach rzymskich koloseów. W Robosseum od 2 do 4 uczestników-gladiatorów przemieszcza się po kwadratowej planszyarenie starając się przetrwać jak najdłużej i wyeliminować jak najwięcej swoich przeciwników (obraz z gry przedstawia rysunek 8). Dostępne są trzy typy uczestników (Murmillo, Hoplomachaus i Retiarius) inspirowane kategoriami gladiatorów w starożytnym Rzymie ([1]) i różniące się uzbrojeniem, szybkością oraz odpornością na obrażenia. Pojedynki mogą się toczyć w trybie każdy na każdego lub drużynowym (wymaganych jest wtedy 4 graczy: pierwszy jest w drużynie z trzecim, natomiast drugi z czwartym). Kompletny zbiór zasad gry znajduje się w [11], tutaj przedstawimy jedynie ich skrócony opis. Boty wykonują swoje tury po kolei, rozpoczynając od pierwszego. W każdej turze bot zna swój stan (aktualną pozycję, kierunek w którym jest zwrócony oraz liczbę punktów żywotności, tzw. HP ang. Health Points) i widzi pewien obszar areny oraz znajdujących się na nim gladiatorów. Wie także, którzy gladiatorzy jeszcze uczestniczą w starciu i ile każdy z nich zdobył punktów. Aby wykonać ruch, bot musi zadeklarować sekwencję komend. Dostępne komendy to: zrób krok w przód, zrób krok w tył, obróć się w lewo, obróć się w prawo, zaatakuj bronią podstawową, zaatakuj bronią pomocniczą. W każdej turze bot ma do dyspozycji pewną liczbę punktów, zwanych punktami akcji (AP ang. Action Points), zależną od jego typu. Każda komenda ma przypisany koszt w punktach akcji. W ramach jednej tury wykonywane są kolejne zadeklarowane przez bota komendy, aż do wyczerpania puli AP. Wykonanie nadmiarowych komend zostaje odłożone na następną turę. Każdy bot ma do dyspozycji dwie bronie zależne od jego typu i różniące się polem rażenia oraz liczbą zadawanych punktów obrażeń. Przeprowadzenie komendy ataku powoduje, że od stanu zdrowia każdego bota znajdującego się w polu rażenia odejmowane są punkty obrażeń. Jeśli jakiś gladiator ma mniej niż 1 HP schodzi z areny. Każdy kto na niej pozostał zyskuje 1 punkt, a dodatkowy punkt otrzymuje gladiator, który zadał ostateczny cios. Gra w trybie drużynowym jest nieco bardziej rozbudowana. Każdy bot może zapytać o stan swojego sojusznika (jego pozycję i wartość HP), odebrać od niego komunikat oraz nadać swój przekaz. Komunikaty mają postać trzyliterowych napisów o ograniczonym alfabecie, które umożliwiają przesłanie prostych wiadomości oznaczających np. Iść na północ?, Potrzebuję pomocy!, Atakuj., Patrz na wschód!, Przyjąłem. Za wyeliminowanie własnego sojusznika przyznawane są punkty ujemne. W trybie drużynowym, wynik drużyny jest sumą punktów jej członków. Rozgrywka kończy się, gdy na arenie zostanie tylko jeden bot (w trybie każdy na każdego), członkowie jednej drużyny (w trybie drużynowym) lub gdy upłynie limit tur. Zwycięzcą zostaje bot (drużyna), który uzyskał najwięcej punktów. 47

48 Rysunek 8: Wizualizacja rozgrywki w grę Robosseum. Przykładowe boty bazują na algorytmie przeszukującym drzewo możliwych ruchów pod kątem zadania przeciwnikom jak największych obrażeń. W sytuacji braku wiedzy na temat pozycji przeciwników, boty realizują różne strategie poruszania się po arenie: okrążanie jej, trzymanie się środka, podążanie za sojusznikiem lub poruszanie się po losowych trasach. Boty przystosowane do trybu drużynowego nadają oraz odczytują jedynie komunikaty w trybie rozkazującym dotyczące pomocy, przemieszczania się lub obrony i różnią się skłonnością do wypełniania poleceń wysłanych przez sojusznika. 5.2 Języki programowania Aby przetestować mechanizm obsługi wielu języków oraz umożliwić tworzenie testowych botów, do systemu zostały wprowadzone przykładowe języki programowania. Znajdują się wśród nich języki, które można podejrzewać, że ze względu na swoją popularność będą najczęściej wykorzystywane przez użytkowników oraz takie, których obsługa jest z jakichś względów nieoczywista w realizacji (interpretowane, dedykowane dla systemu Windows, zwykłe pliki tekstowe z zapisem ruchów). Lista testowych języków programowania, wraz z wykorzystywanymi poleceniami kompilującymi, znajduje się w tabeli 1. Zawartością listy obsługiwanych przez Meridiusa języków programowania można dowolnie manipulować, wykorzystując do tego panel administracyjny opisany w rozdziale Boty System zawiera zbiór testowych programów graczy, których stworzeniu przyświecały różne cele. Część botów implementuje algorytmy grające w testowe gry. Ich szerszy opis znajduje się w rozdziale 5.1 opisującym testowe gry programistyczne oraz w załączniku D zawierającym porównania niektórych zastosowanych algorytmów. Zadaniem tych botów było przetestowanie logik gier pod kątem poprawności działania, ocena stopnia trudności tych gier oraz ogólna ocena przyjazności protokołu komunikacji, narzucanego na twórców botów przez system. Odrębną grupę stanowią boty weryfikujące techniczną poprawność poszczególnych elementów systemu. Niektóre z nich są zależne od gier testowych, a pozostałe całkowicie od nich abstrahują. Do tej pierwszej grupy należą programy testujące mechanizmy związane z logiką: wykrywanie 48

49 Język Kompilator Polecenie kompilujące C GCC gcc -Wall -W -std=gnu99 -O2 program.c C++ GCC g++ -Wall -W -O2 program.cpp C# Mono C# compiler gmcs program.cs Python Python python -mpy_compile program.py Ruby Ruby 1.9.1p243 ruby -c program.rb Haskell Glasgow Haskell Compiler ghc -Wall -Werror -O2 program.hs Java Sun Java 1.6.0_18 javac -encoding utf8 program.java Pascal Free Pascal Compiler fpc -O2 -XS program.pas Perl Perl v perl -c program.pl Bash GNU bash, version 4.1.5(1) bash -n program.sh plain text Tablica 1: Testowe języki programowania. błędnych poleceń, wykrywanie niedozwolonych poleceń (niezgodnych względem trybu gry/typu bota) oraz zgłaszanie przez logikę naruszenia zasad. Boty testujące poprawność komunikacji nie są związane z konkretną grą programistyczną, a jedynie z rdzeniem systemu oraz aplikacją Proxy. Pokrywają one swoim działaniem zbiór wszystkich możliwych błędnych zachowań programów botów: przekroczenie czasu, błąd wykonania i przedwczesne zakończenie działania. Umożliwiają także m.in. sprawdzenie mechanizmu komunikatów testowych, weryfikację poprawności parsowania wartości różnych typów i przetestowanie reakcji systemu na różne kodowania plików źródłowych. Kolejny aspekt testowych botów związany jest z wykorzystywanymi przez system językami programowania (przedstawionymi w rozdziale 5.2). Boty grające w testowe gry są napisanie głównie w językach Python i C#. Jednak ponieważ system obsługuje wiele języków, zarówno kompilowanych jak i interpretowanych, sprawdzona musiała zostać poprawność obsługi każdego z nich. W tym celu, większość testów wymienionych w poprzednim akapicie była realizowana przez kilka programów o takim samym działaniu, lecz napisanych w różnych językach. Zbiór botów zawiera również niepoprawne kody źródłowe, nie przechodzące pomyślnie procesu weryfikacji. Służyły one testowaniu zachowania systemu w przypadku błędu kompilacji/sprawdzenia składni, następującego podczas próby aktualizacji bota przez użytkownika. 5.4 Interfejs użytkownika Aby umożliwić korzystanie z systemu Meridius stworzyliśmy testowy interfejs użytkownika w postaci strony internetowej opartej na technologii ASP.NET z wykorzystaniem JavaScript i udostępnianej przez serwer IIS. Zdecydowaliśmy, że przykładowa implementacja interfejsu będzie miała postać serwisu WWW w dużej mierze dlatego, że taką formę ma przyjąć planowany interfejs docelowy. Uznaliśmy, że udostępnianie funkcjonalności oferowanych przez Meridiusa bezpośrednio ze strony internetowej zwiększa wygodę użytkowania (a także testowania) systemu i koresponduje ze wstępnymi założeniami, głoszącymi, że korzystanie z systemu powinno być możliwe bez względu na system operacyjny użytkownika i bez instalowania dodatkowego oprogramowania. Wybór technologii został dokonany ze względu na łatwość integracji tak utworzonego serwisu internetowego z systemem osadzonym na platformie.net. Aby umożliwić Czytelnikowi zapoznanie się z interfejsem, w stopniu umożliwiającym swobodne korzystanie z niego, w tym podrozdziale znajdują się omówienia najważniejszych podstron serwisu. Na każdym z rysunków pokazujących stronę lub jej fragment zaznaczone zostały elementy, których bardziej szczegółowy opis znajduje się pod rysunkiem. 49

50 5.4.1 Strona główna Rysunek 9: Strona główna interfejsu użytkownika. 1. Menu użytkownika, w którym znajdują się opcje rejestracji nowego konta w serwisie, logowania i wylogowania użytkownika oraz edycji danych aktywnego użytkownika. Do rejestracji wymagane jest podanie unikalnej nazwy konta, hasła, adresu oraz przejście weryfikacji techniką CAPTCHA. Menu serwisu: 2. Strona główna, której widok jest właśnie opisywany. 3. Krótki opis projektu stojąca za nim idea, podstawowe informacje oraz historia powstawania. 4. Tworzenie nowej rozgrywki. Opis procesu tworzenia rozgrywki został szczegółowo omówiony na stronie Wykaz archiwalnych rozgrywek zawierający wszystkie mecze, które można obejrzeć. Ekran odtwarzania rozgrywki został opisany na stronie 52. Możliwe jest filtrowanie wykazu ze względu na nazwę gry oraz tryb rozgrywki. 6. Wykaz wszystkich utworzonych rozgrywek testowych (tylko dla zalogowanego użytkownika). 7. Wykaz zawodników aktualnie zalogowanego użytkownika (tylko dla zalogowanego użytkownika). 8. Wykaz wszystkich zawodników utworzonych w systemie. Możliwe jest filtrowanie wykazu ze względu na nazwę gry oraz rodzaj zawodnika (czy jest to bot czy gracz). W zależności od posiadanych uprawnień umożliwia obejrzenie dokładnych danych zawodnika, ich edycję lub całkowicie zastrzega dostęp do informacji o zawodniku. 9. Umożliwia utworzenie nowego bota (tylko dla zalogowanego użytkownika). Dokładniejszy opis procedury znajduje się na stronie Umożliwia stworzenie nowego profilu gracza (tylko dla zalogowanego użytkownika). Dokładniejszy opis procedury znajduje się na stronie Strona zawierająca dokumentację projektu: zasady gier, informacje dla programistów 50

51 i twórców gier oraz techniczną dokumentację systemu. Panele boczne: 12. Lista zaproszeń skierowanych do aktualnie zalogowanego użytkownika. Kliknięcie łącza z grą powoduje akceptację propozycji rozgrywki i przejście do strony umożliwiającej grę manualną. Wybranie opcji odrzuć anuluje rozgrywkę. 13. Lista ostatnich aktywności użytkownika (także niezalogowanego). Znajdują się tu informacje o ostatnio tworzonych przez użytkownika rozgrywkach oraz przeprowadzanych aktualizacjach botów. Kolor symbolu informacyjnego oznacza status danej aktywności (czerwony zakończona powodzeniem, żółty w trakcie realizacji, czarny zakończona błędem), natomiast po jego kliknięciu widoczne są bardziej szczegółowe informacje, np. treść błędu kompilacji uniemożliwiającego aktualizację bota. 14. Lista ostatnio utworzonych rozgrywek. Kolor przycisku przenoszącego do wizualizacji informuje o statusie danej rozgrywki: czerwony oznacza prawidłowe zakończenie, żółty że rozgrywka jeszcze trwa, natomiast czarny że rozgrywka została zakończona z błędem. Zawartość strony: 15. Strona główna serwisu zawiera wykaz najpopularniejszych gier, listy rankingowe najlepszych zawodników (wg. różnych kryteriów) oraz poglądową wizualizację losowej rozgrywki. Kolory przycisków informacyjnych przypisanych zawodnikom na listach rankingowych świadczą o ich rodzaju. Niebieski oznacza profile graczy, zielony boty testowe, czarny boty nie posiadające prawidłowego kodu źródłowego, a czerwony wszystkie pozostałe boty. Przycisk informacyjny wywołuje podręczny panel zawierający szczegółowe informacje o bocie, natomiast nazwa bota jest linkiem do podstrony przedstawiającej jego profil Tworzenie rozgrywki Rysunek 10: Ekran tworzenia nowej rozgrywki. 1. Lista zawierająca gry umieszczone w systemie umożliwia wybór gry, do której ma zostać utworzona rozgrywka. 2. Skrótowy opis gry, zawierający np. informacje o fabule lub najważniejsze zasady. 51

52 3. Lista umożliwiająca wybór trybu rozgrywki (zależny od wybranej gry). 4. Ustalenie liczby zawodników biorących udział w rozgrywce. Wartości minimalne i maksymalne definiowane są przez wybraną grę i nie można ich przekroczyć. 5. Umożliwia wybór kategorii, do której będzie należał zawodnik na określonej pozycji. Dla użytkowników niezalogowanych możliwość wyboru jest zablokowana i w rozgrywce mogą wziąć udział jedynie publicznie widoczne boty. Użytkownicy zalogowani mogą dodatkowo tworzyć rozgrywki z udziałem swoich botów testowych, swoich profili oraz profili innych, aktualnie zalogowanych na portalu, użytkowników. 6. Lista rozwijana zawierająca wszystkie boty z wybranej kategorii, które mogą wziąć udział w rozgrywce. Przed nazwą bota znajduje się jego aktualny ranking oraz niezawodność (procent rozgrywek zakończonych bez błędu ze strony bota). 7. W tym miejscu należy wprowadzić wartości parametrów z którymi ma zostać uruchomiona rozgrywka. 8. Przycisk uruchamiający rozgrywkę. Automatycznie przechodzi do strony umożliwiającej jej obejrzenie. 9. Przycisk uruchamiający rozgrywkę. Nie zmienia aktualnie oglądanej strony Wizualizacja rozgrywki Rysunek 11: Strona rozgrywki: panel wizualizacji. 52

53 Rysunek 12: Strona rozgrywki: panel statystyk. 1. Przełącznik pomiędzy panelami: z wizualizacją rozgrywki oraz z jej statystykami. Panel wizualizacji: 2. Wizualizacja stanu rozgrywki. 3. Przyciski kontroli wyświetlania: głośność dźwięków, szybkość odtwarzania animacji, pokaż/ukryj nazwy, pasek przybliżenia planszy. 4. Przyciski kontroli odtwarzania (od lewej): przejście do poprzedniej klatki animacji, odtwarzanie/pauza, stop, przejście do następnej klatki, pasek postępu animacji. Widoczne tylko podczas odtwarzania powtórki rozgrywki. 5. Okno służące do wpisywania poleceń gracza zgodnie z protokołem gry (tylko podczas gry manualnej). 6. Przycisk wysyłający do logiki polecenie znajdujące się w powyższym oknie (tylko podczas gry manualnej). 7. Przyciski automatycznie wysyłające predefiniowane polecenia lub wstawiające je do okna poleceń (tylko podczas gry manualnej). 8. Okno informujące o przebiegu komunikacji pomiędzy graczem a grą (tylko podczas gry manualnej). Panel statystyk: 9. Podstawowe informacje o rozgrywce: czas rozpoczęcia i zakończenia, tryb gry, status, liczba tur oraz wartości parametrów początkowych 10. Wyliczane po zakończeniu rozgrywki statystyki (każda gra definiuje własne) dotyczące jej przebiegu. 11. Informacja o biorących udział w rozgrywce zawodnikach: ich wyniku, rankingu przed rozgrywką oraz po niej i wartości statystyk definiowanych przez grę, indywidualnie dla każdego z uczestników. 53

54 5.4.4 Tworzenie zawodnika Rysunek 13: Tworzenie zawodnika: bota. Rysunek 14: Tworzenie zawodnika: gracza. 1. Pole do wprowadzenia unikatowej nazwy zawodnika. 2. Pole do wprowadzenia publicznie widocznego opisu zawodnika. 3. Wybór (opcjonalny) portretu zawodnika (tzw. avatara). 4. Nazwa użytkownika będącego właścicielem zawodnika. 5. Wybór języka programowania, w którym będzie tworzony bot. 6. Wybór gry, w którą zawodnik będzie grał. 7. Wybór typu bota (zależy od wybranej gry). 8. Czy bot, już w momencie stworzenia, będzie oznaczony jako testowy. 9. Wybór trybów gry, w które bot będzie potrafił grać (konieczne jest zaznaczenie co najmniej jednego). 10. Zakończenie procesu tworzenia zawodnika. 54

55 5.4.5 Szczegóły zawodnika Ogólnie dostępne informacje: 1. Podstawowe dane o zawodniku. 2. Statystyki zawodnika. Rysunek 15: Szczegóły zawodnika 3. Wybór panelu: ze statystykami lub wykazem ostatnich rozgrywek z udziałem bota. Widoczne tylko dla właściciela zawodnika: 4. Możliwość zmiany danych zawodnika (opisu, avatara, czy jest botem testowym). 5. Wykaz, spowodowanych przez zawodnika, ostatnich błędów (przycisk informacyjny przedstawia szczegóły błędu). Widoczne tylko dla właściciela zawodnika-bota: 6. Pole umożliwiające aktualizację bota poprzez wysłanie nowej wersji jego kodu źródłowego (wraz z opcjonalnym komentarzem). 7. Wykaz dotychczasowych wersji bota, z możliwością podglądu kodów źródłowych. 6 Administracja systemem Rozdział ten zawiera informacje niezbędne administratorom systemu Meridius. Przedstawiamy w nim sposób instalacji systemu, aplikację służącą do jego konfiguracji oraz narzędzia 55

56 pozwalające na monitorowanie jego pracy. 6.1 Instalacja systemu Do zainstalowania portalu Meridius (czyli opisywanej wersji systemu wraz z testową zawartością i bazowymi interfejsami) niezbędny jest komputer z zainstalowanym systemem Windows 7, Windows 2003 Server lub Windows 2008 Server. System musi mieć zainstalowaną usługę IIS w wersji 6 lub 7, bazę danych MSSQL 2008 Express oraz Microsoft Framework 4.0. Na serwerze MSSQL należy utworzyć nową bazę danych i wykonać na niej skrypt, który tworzy niezbędną strukturę bazy oraz dodaje domyślne języki programowania. Tworzony jest również użytkownik techniczny. W usłudze IIS należy utworzyć nową aplikację internetową oraz skopiować do wirtualnego folderu niezbędne pliki. W pliku web.config należy skonfigurować dostęp do nowo utworzonej bazy. Zdefiniowane połączenie musi mieć nazwę MeridiusBattleFieldConnectionString. Oprócz tego należy zdefiniować dodatkowe handlery http, klasy TurnipHandler oraz ActivitiesHandler, odpowiednio dla ścieżek *.mhs oraz *.act. Obie klasy znajdują się w bibliotece Meridius.Web.dll. Po dodaniu ich do pliku web.config, w panelu administracji serwera IIS należy dodać MIME Type dla obu rozszerzeń: text\plain oraz text\html. Na koniec, konieczne jest dodanie obu rozszerzeń do plików obsługiwanych przez standardowy isapi filter (aspnet_isapi.dll). Do dalszej konfiguracji należy posłużyć się panelem administracyjnym. 6.2 Obsługa panelu administracyjnego Panel administracyjny jest aplikacją umożliwiającą administratorowi systemu jego wygodną konfigurację i aktualizację zawartości. W dalszej części tego rozdziału przedstawimy zasady obsługi panelu, opisując najważniejsze jego elementy. Wygląd panelu administracyjnego został przedstawiony na rysunku 16. Panel jest przystosowany do współpracy z zewnętrznymi aplikacjami oraz implementacjami interfejsów dostarczonymi z portalem Meridius. Zakładka Konfiguracja pozwala na modyfikację globalnych ustawień systemu oraz mechanizmu VSS. W szczególności umożliwia modyfikację danych do połączenia przez SSH, ustawienia logów (więcej na ten temat w podrozdziale 6.3) i konfigurację ścieżek systemowych: na serwerze Meridiusa, pomocniczym serwerze linuksowym oraz wewnątrz VSS. Poniżej znajduje się omówienie poszczególnych pól: SSH pola zawierają dane niezbędne do zalogowania się na serwer pomocniczy zawierający mechanizm VSS. System, Adres IP zawiera informacje o adresie serwera głównego widocznego z maszyny linuksowej, adres jest przekazywany jako parametr aplikacji Proxy. Dostępne porty definiuje zakres portów, z puli których będzie, podczas rozgrywki, prowadzone nasłuchiwanie komunikatów od aplikacji Proxy. Każda rozgrywka, w której uczestniczy bot, prowadzi nasłuch na jednym porcie, stąd liczba dostępnych portów nie powinna być mniejsza od liczby dostępnych slotów. Dostępne sloty zakres slotów VSS dostępnych dla portalu Meridius. Ścieżka do pliku ścieżka do pliku z logami generowanymi przez system. Pole to nie może być puste. Możliwe jest podanie ścieżki względnej lub bezwzględnej. Zakończenie nazwy pliku symbolem * oznacza, że system automatycznie będzie tworzyć plik z logami o nazwie WpisanaNazwa_data.log za każdym razem, gdy aplikacja zostanie uruchomiona lub rozmiar pliku przekroczy 30 MB. 56

57 Rysunek 16: Widok zakładek panelu administracyjnego. Poziom logowania określa poziom szczegółowości logów po stronie portalu. Ścieżka do gier każda dodawana gra jest kopiowana razem z plikami.xml definiującymi parametry do osobnego folderu w katalogu zdefiniowanym w tym polu. Jest to również ścieżka robocza dla wszystkich rozgrywek. Ścieżka do logów katalog, w którym aplikacja Proxy będzie zapisywać swoje logi na serwerze linuksowym. Opcje logowania ustawienia z jakimi będzie tworzyć logi aplikacja Proxy. Ścieżka do VSS katalog, w którym są wykonywane komendy wewnątrz slotów VSS. Ścieżka do binariów botów po kompilacji, skompilowany kod bota jest przechowywany w podanym katalogu na serwerze pomocniczym. Stąd też jest pobierana podczas uruchomienia rozgrywki jego kopia. Ścieżka do proxy polecenie uruchamiające aplikację Proxy, wywoływane przez SSH. Zakładka Interfejsy zawiera spis implementacji interfejsów wykorzystywanych przez daną instancję systemu. Za pomocą funkcji Rejestruj bibliotekę możliwa jest rozbudowa systemu o niestandardowe interfejsy. Przy pierwszym uruchomieniu lista interfejsów jest pusta. W celu zarejestrowania standardowych bibliotek portalu należy wybrać bibliotekę Meridius.Core.dll, a następnie Meridius.Web.Core.dll, które zawierają moduły do komunikacji z bazą danych oraz niestandardową klasę TurnipEventReceiver. Dopiero po tej operacji będzie możliwe użycie zakładek Gry oraz Języki. 57

58 Zakładka Gry umożliwia zarządzanie umieszczonymi w systemie grami: ich dodawanie, usuwanie oraz aktualizację. Dodanie gry i aktualizacja, odbywają się poprzez podanie ścieżki do pliku.dll z logiką gry. System automatycznie wykryje czy gra ta znajduje się już w systemie. Aby operacja weryfikacji logiki gry się powiodła, w tym samym folderze w którym znajduje się wskazana biblioteka NazwaGry.dll muszą znajdować się pliki konfiguracyjne NazwaGry.start.xml i NazwaGry.end.xml (opisujące odpowiednio startowe i końcowe parametry gry) oraz wszystkie inne pliki wymagane do działania biblioteki. Po dodaniu gry, plik.dll oraz definicje parametrów są kopiowane do oddzielnego katalogu wewnątrz folderu Ścieżka do gier, zdefiniowanego w zakładce Konfiguracja. Pozostałe wymagane pliki muszą zostać skopiowane ręcznie. Konfiguracja wizualizacji gry ma miejsce niezależnie od wprowadzania jej do systemu i również musi zostać wykonana ręcznie. W tym celu należy skopiować niezbędne pliki do katalogu Visualization/NazwaKlasyGry, znajdującego się wewnątrz wirtualnego katalogu aplikacji internetowej. W zakładce Języki znajdują się informacje o zapisanych w bazie, obsługiwanych przez system językach programowania. Dostępne opcje pozwalają zmodyfikować komendy kompilacji i uruchamiania programów wysłanych przez użytkowników, a także określać nazwy plików wykorzystywanych w tych komendach. Kolorowanie składni ma wpływ na sposób wyświetlania kodu źródłowego na stronie internetowej, wchodzącej w skład testowej zawartości systemu. Wpis oznaczony jako Gracz spełnia specjalną rolę języka programowania przypisanego do profili użytkowników wykorzystywanych w grze manualnej. Edycja danych o obsługiwanych językach modyfikuje jedynie wpisy w bazie i nie ma wpływu na realnie wykorzystywane kompilatory. W celu aktualizacji oprogramowania dostępnego wewnątrz wirtualnych slotów, wymagane jest skontaktowanie się z administratorem systemu VSS. 6.3 Monitorowanie działania systemu Monitorowanie działania systemu odbywa się przez analizę logów, opisujących szczegółowo wszystkie podejmowane przez system akcje. W przypadku niepożądanego zachowania Meridiusa, zalecaną reakcją administratora jest prześledzenie wpisów w logach. Ich analiza powinna dostarczyć odpowiedzi na pytanie, jaka była przyczyna zdarzenia. Meridius korzysta z dwóch niezależnych, wzajemnie dopełniających się systemów logowania. Pierwszy wchodzi w rdzenny skład Meridiusa i notuje wydarzenia, w których uczestniczy główny serwer, natomiast drugi, związany z aplikacją Proxy, zapisuje przebieg rozgrywki z punktu widzenia botów uruchamianych po stronie linuksowego serwera pomocniczego. Konfiguracja (zmiana poziomu szczegółów logowania i modyfikacja ścieżek do plików z logami) obu mechanizmów jest możliwa za pomocą panelu administracyjnego opisanego w poprzednim podrozdziale. Aby wspomóc analizę logów Meridiusa powstała aplikacja LogViewer (przedstawiona na rysunku 17). Pozwala ona na filtrowanie wpisów ze względu na ich poziom szczegółowości i typ operacji, a także wyszukiwanie podanego tekstu w treściach wiadomości. 58

59 Rysunek 17: Widok aplikacji wyświetlającej logi systemowe. Do oglądania logów zapisanych przez Proxy również powstała pomocnicza aplikacja logviewer. Poziom szczegółowości logów oznaczony jest przez cztery flagi, których wystąpienie jako parametru oznacza, że dany element podlega zapisowi/wyświetleniu: B komunikaty wysłane przez bota, C komunikaty wysłane przez serwer (tzw. Core), S komunikaty systemowe, T adnotacje dotyczące kontroli czasu wykonania programu. Wyświetlane przez logviewer komponenty są podzielone na: c zawartość, f flagę typu zapisu, t czas wpisu. Przykład działania aplikacji został przedstawiony na rysunku 18. Rysunek 18: Widok aplikacji wyświetlającej logi Proxy. 59

60 7 Podsumowanie Po doświadczeniach nabytych podczas pracy nad grą programistyczną QUAIKE [17] (projekt licencjacki tworzony wraz z Andrzejem Pilarczykiem i Bartłomiejem Gałkowskim), zaczęliśmy rozważać możliwe usprawnienia w procesie tworzenia gier programistycznych. Analizując implementację architektury gry wydzieliliśmy te elementy projektu, które są niezależne od mechaniki rozgrywki i występują we wszystkich grach programistycznych, np. tworzenie i nadzorowanie rozgrywki, obsługa komunikacji z botami, itd. Uznaliśmy, że aby maksymalnie uprościć tworzenie gier, należałoby zaprojektować system udostępniający te elementy tak, aby odciążyć twórców gier od ich implementacji i pozwolić im skupić się jedynie na definiowaniu zasad rozgrywki. Opracowując ideę systemu zarządzającego grami programistycznymi, a więc dostarczającego mechanizmy obsługujące wiele gier programistycznych, określiliśmy główne cechy, które powinien naszym zdaniem posiadać. Cechy te, będące równocześnie założeniami systemu Meridius, to: 1. Obsługa jak najszerszej klasy gier. 2. Sprawne dodawanie nowych gier udostępnione mechanizmy upraszczające proces ich tworzenia. 3. Prosty mechanizm tworzenia programów botów i ich publikacji, bez ujawniania implementacji innym użytkownikom. 4. Zarządzanie botami przez użytkowników możliwość ich aktualizacji, testowania i śledzenia błędów. 5. Generowanie graficznego przedstawienia przebiegu rozgrywek. 6. Archiwizowanie rozgrywek z możliwością ich późniejszego odtworzenia, pozwalającego na szczegółową analizę ich przebiegu. 7. Bezpieczne uruchamianie programów botów. 8. Prostota konfrontacji z programami innych użytkowników. Zaimplementowany przez nas i przedstawiony w tej pracy system Meridius założenia te spełnia. Obsługuje wszystkie skończone i parametryzowane gry turowe (punkt 1 założeń). Proces tworzenia gry, sprowadzony jest do implementacji programu opisującego jej zasady oraz zdefiniowania plików konfiguracyjnych i wizualizacji (punkt 2). System dostarcza twórcom botów standard komunikacji przez wejście/wyjście i pozwala na nadawanie użytkownikom uprawnień, dotyczących wglądu w kody źródłowe botów (3). Programy botów mogą być aktualizowane przez dostarczanie kolejnych wersji kodów źródłowych (stare wersje są zachowywane). Boty mają możliwość wysyłania dodatkowych komunikatów odtwarzanych w czasie rozgrywek, pozwalających zorientować się twórcy w szczegółowym przebiegu działania programu. Twórcom botów przekazywane są szczegółowe treści wszystkich błędów popełnianych przez ich programy (punkt 4 założeń). Meridius udostępnia mechanizm pozwalający grze opisać stan rozgrywki, który następnie jest traktowany jako podstawa do odtworzenia animacji przez zewnętrzny system wizualizacji (5). Wszystkie przeprowadzone rozgrywki są archiwizowane i możliwe jest ich odtworzenie za pomocą zewnętrznego systemu wizualizacji (punkt 6 założeń). Ponieważ programy botów wywoływane są na serwerze z wykorzystaniem zewnętrznych mechanizmów zapewniających bezpieczeństwo, nie stanowią one zagrożenia ani dla pracy serwera, ani dla komputerów użytkowników (7). Wszystkie informacje o graczach i ich botach przechowywane są na globalnym serwerze, więc utworzenie rozgrywki wymaga jedynie ustalenia jej parametrów oraz wybrania uczestników z puli dostępnych botów (punkt 8). Dodatkowo rozwijając ideę zarządzania grami programistycznymi, postanowiliśmy rozszerzyć Meridiusa o następujące cechy: 9. Możliwość gry bez pośrednictwa programu komputerowego (manualnej). 60

61 10. Obsługę wielu języków programowania, automatycznie dostępną dla wszystkich gier w systemie. 11. Obsługę wielu interfejsów użytkownika. Szczegółowy opis wszystkich kluczowych, realizowanych przez system funkcjonalności znajduje się w rozdziale 3, natomiast sposób ich implementacji przedstawiony został w rozdziale 4. Na koniec warto przyrównać możliwości systemu Meridius do przedstawionych w tej pracy (głównie w rozdziale 2) istniejących gier programistycznych. Core War, QUAIKE oraz gry występujące na ITPW, mogą zostać zaimplementowane w sposób umożliwiający bezproblemowe umieszczenie ich w systemie Meridius. Podobnie ma się rzecz z grami zawartymi w portalu kurnik. Włączenie do Meridiusa gry A.I. Wars (The Insect Mind) też jest możliwe, pomimo rozbudowanych zasad rozgrywki i konieczności zaimplementowania w logice wirtualnej maszyny języka CAICL. Gry takie jak RARS i TORCS również mogą bez przeszkód zostać umieszczone w systemie. Jedynie gra manualna na zasadzie płynnej rozgrywki, jaką zapewniają aplikacje tych gier, nie byłaby możliwa ze względu na czas komunikacji pomiędzy poszczególnymi elementami Meridiusa. Gry programistyczne związane z takimi zawodami jak Ms Pac-Man Screen Capture, 2K Bot Prize i StarCraft Competition, wymagają ścisłej interakcji z grami komputerowymi, wykraczają więc poza przyjęte przez system ramy. Nie ma jednak przeszkód, aby stworzyć dedykowane dla systemu Meridius odpowiedniki tych gier komputerowych. 7.1 Perspektywy rozwoju projektu Istnieją dwie główne perspektywy rozwoju Meridiusa. Pierwsza związana jest z jego naturalną rozszerzalnością, spowodowaną modułową architekturą. Dzięki temu możliwe jest rozbudowanie Meridiusa o współpracę z innymi mechanizmami. Na przykład stworzenie alternatywnego interfejsu użytkownika w formie samodzielnej aplikacji lub systemu wizualizacji udostępniającego bardziej naturalny interfejs do gry manualnej, podobny do tych stosowanych w grach komputerowych. Druga perspektywa to rozbudowa systemu poprzez implementowanie dodatkowych funkcjonalności. Wprowadzane modyfikacje powinny zależeć głównie od zapotrzebowania użytkowników oraz usprawniać działanie systemu z punktu widzenia jego twórców i administratorów. Do najważniejszych, planowanych obecnie działań rozwijających projekt Meridius należą: stworzenie środowiska wspomagającego testowanie logik gier bez potrzeby umieszczania ich w systemie; rozwinięcie profilu użytkownika systemu wprowadzenie ról o dodatkowych uprawnieniach i powiązaniach (uczeń i nauczyciel), opcjonalne przypisanie użytkownika do placówki dydaktycznej; umożliwienie automatycznego generowania przez użytkowników szeregu powiązanych ze sobą rozgrywek, tzw. turniejów. W planach są także: rozbudowa systemu parametrów pozwalająca na definiowanie pomiędzy nimi bardziej złożonych zależności; obsługa rozbudowanych programów botów składających się z więcej niż jednego pliku źródłowego; automatyczne tworzenie przez system losowych rozgrywek, w czasie wolnym od zleceń użytkowników; 61

62 przypisanie botom plików z danymi, które będą mogły być przez nie nadpisywane po każdej rozgrywce (umożliwi to efektywne stosowanie przez boty algorytmów uczących się); implementacja metody logiki, która będzie wywoływana dla polecenia bota uznanego za nieprawidłowe w czasie weryfikacji systemowej (umożliwi to stworzenie gry o dowolnej składni poleceń); udostępnianie twórcom botów bibliotek, dedykowanych przez niektóre gry z myślą o wybranych językach programowania (pozwoli to, przynajmniej w części przypadków, odciążyć twórców botów od ręcznego parsowania przekazywanych przez logikę danych). 7.2 Perspektywy wykorzystania systemu Meridius Zadaniem Meridiusa jest popularyzacja gier programistycznych, zwłaszcza jako metody na naukę programowania poprzez zabawę. Chcieliśmy aby udostępniał on gry programistyczne łącząc atrakcyjność gier komputerowych i serwisów społecznościowych z aspektem edukacyjnym, właściwym dla portali z zadaniami programistycznymi. Aby poszerzyć grono potencjalnych odbiorców, duży nacisk został położony na prostotę obsługi systemu i (dzięki urozmaiconemu zbiorowi obsługiwanych gier) różnorodność oferowanych aktywności. Natomiast w celu zainteresowania zagadnieniem osób nie zaznajomionych z programowaniem, wszystkie umieszczone w systemie gry programistyczne mogą być traktowane (wykorzystując mechanizm gry manualnej) jak zwykłe gry komputerowe. W świetle powyższych cech systemu, w dalszej perspektywie, widzimy wykorzystanie portalu Meridius jako miejsca skupiającego m.in. programistów zainteresowanych wzajemną rywalizacją; uczniów i studentów pragnących podnieść swoje umiejętności programistyczne; nauczycieli chcących uatrakcyjnić szkolne lekcje informatyki; wykładowców akademickich wykorzystujących gry programistyczne w ramach zajęć, np. z dziedziny sztucznej inteligencji. Literatura [1] Kathleen Coleman. Gladiators: Heroes of the Roman Amphitheatre. uk/history/ancient/romans/gladiators_01.shtml#three. [2] Alexander K. Dewdney. In the game called Core War hostile programs engage in a battle of bits. Scientific American, 250:14 22, May First.htm. [3] Bartosz Dolecki. Turnip Tutorial zróbmy sobie animację. Wrocławski Portal Informatyczny. [4] Technische Universitat Dortmund. CIG 2011 StarCraft RTS AI Competition. ls11- [5] Jens Gutzeit. History of the 94 No Pspace Hill. 94nop.en.html. [6] Annotated Draft of the Proposed 1994 Core War Standard. icws94.html. 62

63 [7] Core War 88 Standard. [8] Michalis Kamburelis. Wirtualne Bezpieczne Sloty. Wrocławski Portal Informatyczny. [9] Corewars - King of the Hill. [10] Jakub Kowalski and Marek Kembrowski. Dokumentacja systemu Meridius. Dokumentacja gry Kółko i Krzyżyk., [11] Jakub Kowalski and Marek Kembrowski. Dokumentacja systemu Meridius. Dokumentacja gry Robosseum., [12] Jakub Kowalski and Marek Kembrowski. Dokumentacja systemu Meridius. Dokumentacja gry Skarb Labiryntu., [13] Jakub Kowalski and Marek Kembrowski. Dokumentacja systemu Meridius. Dokumentacja gry Wumpus., [14] Jakub Kowalski and Marek Kembrowski. Dokumentacja systemu Meridius. Dokumentacja techniczna kodu., [15] Jakub Kowalski and Marek Kembrowski. Dokumentacja systemu Meridius. Zasady pisania botów., [16] Jakub Kowalski and Marek Kembrowski. Dokumentacja systemu Meridius. Zasady tworzenia gier., [17] Jakub Kowalski, Andrzej Pilarczyk, Marek Kembrowski, and Bartłomiej Gałkowski. Dokumentacja projektu Quaike. Założenia ogólne. materials/06/lpp/projekt/documentation/pdf/zpl/visiondoc.pdf, LPO IIUWr. [18] Jakub Kowalski, Andrzej Pilarczyk, Marek Kembrowski, and Bartłomiej Gałkowski. Dokumentacja projektu Quaike. Zasady gry. materials/06/lpp/projekt/documentation/pdf/client/mechanicdoc.pdf, LPO IIUWr. [19] Sphere Research Labs. Sphere Online Judge. [20] Simon Lucas. Ms Pac-Man Competition. PacManContest.html. [21] 2K Marin. The 2K BotPrize. [22] John Metcalf. Corewar the Ultimate Programming Game. [23] Wangsaw Mintarjo. Intro to Art in 88: Paper - Stone - Scissors Trilogy. co.uk/mintard/index.htm. [24] Tactical Neuronics. A.I. WARS (THE INSECT MIND). content/aiw3dnew.asp. [25] Aleph Null. Computer Recreations : Darwin. Software: Practice and Experience, 2:93 96, January/March [26] John Perry. Core Wars Genetics: The Evolution of Predation. info/evolving_warriors.html. [27] Programming Games Wiki. 63

64 [28] Robot Auto Racing Simulator. [29] John A. Reder Jr. A.I. Wars User s Handbook. Tactical Neuronics, December http: //tacticalneuronics.com/downloads/aiwug_cp_5x8_manual_text.pdf. [30] EPSITEC SA. CeeBot4 User Handbook. [31] EPSITEC SA. Creating Colobot User Levels. [32] EPSITEC SA. CeeBot: Have fun programming. [33] KOTH@SAL. [34] Christian Schmidt. The Corewar Info Page. [35] IEEE Computational Intelligence Society. IEEE Conference on Computational Intelligence and Games. [36] Marek Szykuła. ScriptCraft. Wrocławski Portal Informatyczny. [37] TORCS Team. The Open Racing Car Simulator. [38] Julian Togelius, Sergey Karakovskiy, and Noor Shaker. Mario AI Championship. http: // [39] Barkley Vowk, Sasha Alexander Wait, and Christian Schmidt. An Evolutionary Approach Generates Human Competitive Corewar Programs. [40] Victor A. Vyssotsky, Robert Morris, and M. Douglas McIlroy. Darwin, a Game of Survival of the Fittest among Programs [41] Wikipedia. Elo rating system Wikipedia, The Free Encyclopedia. org/wiki/elo_rating_system#mathematical_details. [42] Wikipedia. Gladiator (2000 film) Wikipedia, The Free Encyclopedia. wikipedia.org/wiki/gladiator_%282000_film%29. 64

65 A Podział pracy System Meridius został stworzony przez dwóch autorów: Jakuba Kowalskiego i Marka Kembrowskiego. Zgodnie z założeniami, podział funkcji pomiędzy autorów wyglądał następująco: Jakub Kowalski (pomysłodawca i kierownik projektu) główny projektant, programista, tester, autor przykładowych gier i botów, autor dokumentacji; Marek Kembrowski główny programista, projektant, tester, twórca interfejsu użytkownika i aplikacji administracyjnych. Ponieważ projekt powstawał przy ścisłej współpracy autorów, w wielu przypadkach nie jest możliwe jednoznaczne określenie osoby odpowiedzialnej za daną część systemu. Wielokrotnie pracowaliśmy nad tymi samymi fragmentami kodu, a rozwiązania zazwyczaj powstawały podczas wspólnych narad. W związku z tym, aby określić przybliżony podział prac, zastosowaliśmy rozwiązanie pokazujące wkład każdego z autorów w rozwój poszczególnych elementów systemu. Każdemu opisanemu elementowi przysługuje odpowiednia do jego wagi i złożoności liczba punktów (oznaczonych jako ). Punkty te są rozdysponowywane pomiędzy autorów w proporcji odzwierciedlającej ich wkład w prace nad danym elementem. Wykonany tym sposobem podział pracy znajduje się w tabeli 2. Element pracy Waga Jakub Kowalski Marek Kembrowski Projektowanie Założenia systemu 7 Obsługa gier programistycznych 4 Architektura komunikacji 4 Architektura bazy danych 4 Wybór technologii i rozwiązań technicznych 4 Testowe gry i boty 3 Testowy interfejs użytkownika 2 Programowanie Jądro systemu (Core) 14 Testowe gry i boty 5 Testowy interfejs użytkownika 5 Proxy 2 Panel administracyjny 2 Testy Funkcjonalne 5 Refaktoryzacja 4 Użyteczności 4 Regresyjne 3 Dokumentacja Dokumentacja techniczna 6 Praca magisterska 10 Tablica 2: Podział pracy między autorów systemu Meridius. B Etymologia nazwy systemu Nazwa Meridius pochodzi od imienia głównego bohatera filmu Gladiator ([42]) w reżyserii Ridleya Scotta, którym jest grany przez Russela Crowe (oskarowa rola) Maximus Decimus Meridius. W tej opowiedzianej z epickim rozmachem historii, Maximus, lojalny generał rzymskiej armii, w wyniku zdrady trafia do niewoli, a następnie, zmuszony do walki jako gladiator, na arenę 65

66 Koloseum, gdzie dokonuje zemsty na odpowiedzialnym za jego tragedię cesarzu-uzurpatorze. Rysunek 19: Maximus Decimus Meridius otoczony przez pretorian. Kadr z filmu Gladiator. Nazwa została nadana jako roboczy tytuł projektu przez jednego z autorów, zafascynowanego filmem. Ponieważ przypadła do gustu także drugiemu twórcy systemu, uzyskała pełną akceptację jako nazwa finalna. Z czasem okazało się, że intuicyjnie nadany tytuł znakomicie wpasowuje się w tematykę projektu i poprzez skojarzenie z filmem może mieć wpływ na odbiór systemu przez użytkowników. Utożsamiając boty z gladiatorami można traktować sam system jako koloseum, na którego licznych arenach odbywają się pomiędzy nimi pojedynki, natomiast użytkownicy wcielają się w rolę trenerów szkolących własne zespoły wojowników. C Schemat bazy danych Zamieszczony w tym załączniku schemat bazy danych, na którym oparta jest opisywana wersja systemu Meridius, ma na celu uzupełnienie przedstawionej w rozdziale 4 architektury systemu. Struktura bazy składa się z części stałej, przechowującej informacje o znaczeniu globalnym dla całego systemu (przedstawionej na stronie 67) oraz tabel generowanych automatycznie na potrzeby każdej z obsługiwanych gier. Tabele te, tworzone na podstawie plików konfiguracyjnych gry, zawierają dane o parametrach rozgrywek oraz wyliczanych przez logikę statystykach. Przykładowy fragment bazy, dotyczący gry Robosseum, znajduje się na stronie