Politechnika Warszawska Wydział Elektryczny Kamil Deryński Nr albumu: 197570 Simple Online GAME Projekt koncepcyjny gry sieciowej. Praca na projekt indywidualny w roku 2007r. Kierunek Informatyka (semestr 4). Praca wykonana pod kierunkiem mgr inż. Konrada Andrzeja Markowskiego, Instytut Sterowania i Elektroniki Przemysłowej. Maj 2007
Streszczenie: W pracy tej przedstawiam koncepcję i konkretny zarys gry sieciowej, która to była tematem projektu indywidualnego. W poszczególnych działach opiszę wybrane technologie użyte podczas realizacji projektu, a także przedstawię powszechnie stosowane schematy konstrukcji takich aplikacji. Następnie opisuję szczegóły programu oraz problemu występujące podczas prac. Wprowadzenie: Gry sieciowe są naturalnym rozszerzeniem gier trybu jednoosobowego. Umożliwiają wspólną rozgrywkę dla więcej niż jednego gracza w tym samym czasie. Wraz z ewolucją i ekspansją Internetu tzw. tryb Multiplayer jest nieodłącznym elementem każdej gry. Popularyzację na szeroką skale gry wieloosobowej przez sieć zawdzięczamy głównie grą typu FPS (First Person Shooter), przedstawicielem takiego gatunku jest Quake, pierwsza część tej gry oferowała już bardzo dużą funkcjonalność dotyczącą rozgrywki wieloosobowej, wydajne serwery umożliwiające grę wielu uczestników jednocześnie dołączanych do gry podczas toczącej się już rozgrywki, a także optymalizowany przepływ danych, co pozwoliło na wymianę wielu danych dla obsługi skomplikowanego środowiska. (QuakeWorld) Weryfikacja wstępnych założeń projektu 1 : Projekt nie został zakończony wykonaniem w pełni działającej gry sieciowej, co jest naturalną implikacją nie spełnienia wszystkich założeń projektu, jednak prace trzymały się głównych przedstawionych wcześniej założeń, które wypunktuję poniżej: Założenia funkcjonalne: 1. Program umożliwia grę 2 osobową 2. Warstwa sieci aplikacji opiera się na modelu klientserwer. 3. Rozgrywka toczy się w czasie rzeczywistym. 4. Zarówno serwer jak i klient wbudowany jest w program, dokonujemy wyboru, jaką rolę będzie pełnić jedna z instancji programu. 5. Budowa gry umożliwia implementowanie typu zręcznościowego. 1 Wstępne założenia projektu dostępne w pliku WstępneZalozenia.pdf 2
Założenia implementacyjne: 1. Język programowania cała aplikacja napisana została z wykorzystaniem języka C++ z użyciem STL (Standard Template Library). 2. Wykorzystane biblioteki w początkowych założeniach miała być to biblioteka Allegro jednak zdecydowałem się ostatecznie na dobrze mi znaną przenośną bibliotekę SDL z pomocą biblioteki, SDL_gfx do rysowania prymitywów graficznych. 3. Warstwa sieciowa - SDL_net jako wraper programowania gniazd sieciowych dający pełną przenośność programu. 4. IDE Microsoft Visual Studio C++ Express wraz z kompilatorem MS dostarczanym w pakiecie. Wprowadzenie do użytych bibliotek oraz narzędzi: Biblioteka SDL: SDL(Simple DirectMedia Layer) to biblioteka ułatwiająca tworzenie gier oraz programów multimedialnych. Posiada oficjalne wsparcie dla ponad 20stu systemów operacyjnych w tym tych najpopularniejszych, czyli MS Windows, GNU/Linux, BSD, a także tych niszowych jak choćby AmigaOS czy też QNX. SDL nie oferuje wysokopoziomowych funkcji, jest raczej warstwą gwarantującą przenośność. Do tego celu właśnie została stworzona (LGPL) w 1998r przez Sama Lantiga z firmy Loki. Przykładowe gry korzystające z SDL: - Battle for Wesnoth - Frozen Bubble - Neverwinter Nights - Quake4 (tylko w wersji pod Linuksa) Ogólny schemat działania, SDL: 3
SDL_gfx biblioteka, która wyewoluowała z kodu SDL_gfxPrimitives obecnie oferuje znacznie więcej niż tylko udostępnianie funkcji do rysowania prymitywów. Biblioteka została napisana przez Andreas Schifflera, przez, którego udostępniana jest na licencji LGPL. Komponenty biblioteki SDL_gfx: Graphic Primitives (SDL_gfxPrimitves.h) Rotozoomer (SDL_rotozoom.h) Framerate control (SDL_framerate.h) MMX image filters (SDL_imageFilter.h) SDL_net biblioteka, dzięki, której można uzyskać przenośność programów sieciowych pisanych z wykorzystaniem gniazd. Uwalnia programistę z konieczności pisania tej samej funkcjonalności sieciowej dwa razy (implementacja socketów POSIX oraz implementacja winsock w MS windows). Microsoft Visual Studio C++ Express w pełni darmowa wersja do użytku komercyjnego środowiska programistycznego firmy Microsoft. Wersja Express jest ograniczona brakiem kilku funkcji oraz innym kompilatorem, który produkuje pliki wykonywalne wymagające pakietu Redistribution na komputerze, na którym chcemy uruchomić skompilowany program. Jednak niedogodność kompilatora można ominąć instalując darmowy Toolkit 2003. Niezaprzeczalną zaletą MS VS jest obecność zintegrowanego bardzo dobrego debugera, który znacznie ułatwia wykrywanie błędów. TortoiseSVN do zarządzania wersjami programu oraz do sprawniejszego panowania nad kodem używałem SubVersion, systemu kontroli wersji. Moje repozytorium jest dostępne w Internecie pod adresem svn://dragon.dust.pl/osg (we wczesnej fazie rozwoju do repozytorium nie ma publicznego dostępu). Do korzystania z SubVersion używam programu TortoiseSVN, który integruje się z interfejsem systemu Windows i umożliwia pełną obsługę możliwości udostępnianych przez serwer SVN. STL(Standard Template Library) standardowa biblioteka zgodna ze standardem ANSI języka C++. Umożliwia programowanie generyczne oraz m.in. dostęp do złożonych typów danych, a także udostępnia cały wachlarz algorytmów oraz dynamicznych struktur danych. 4
Opis enginu gry: Główny engine, na którym opiera się gra zawiera się w pliku engine.h, engine.cpp. Pliki te zawierają opis oraz implementacje klasy silnika gry, który dzieli się na kilka głównych części: 1. Główne zmienne i dane (powierzchnia ekranu, dane okna, zmienna wyjściowa, manager Frame Limitera itd.) 2. Metody głównego enginu: Init, Start, DoRender, DoThink (odpowiadające inicjalizacji bibliotek obsługi, inicjalizacja enginu, podstawowe funkcje renderujące, podstawy obliczeń oraz obsługa defaultowych akcji). 3. Cała gama metod wirtualnych: dzięki nim w klasie dziedziczącej po klasie engine, można definiować specyficzne dla implementacji konkretnej gry cechy). Listing definicji klasy engine (engine.h): #ifndef ENGINE_H #define ENGINE_H #include "SDL.h" #include "SDL_NET.h" #include "SDL_framerate.h" class CEngine { private: int m_iwidth; int m_iheight; bool m_bquit; const char* m_cztitle; SDL_Surface* m_pscreen; FPSmanager* fps_manager; protected: void DoThink(); void DoRender(); void SetSize(const int& iwidth, const int& iheight); void HandleInput(); public: CEngine(); virtual ~CEngine(); void Init(); void Start(); virtual void AdditionalInit () {} virtual void Think ( ) {} 5
virtual void Render( SDL_Surface* pdestsurface ) {} virtual void End() {} virtual void KeyUp (const int& ikeyenum) {} virtual void KeyDown (const int& ikeyenum) {} }; void SetTitle (const char* cztitle); const char* GetTitle(); SDL_Surface* GetSurface(); #endif // ENGINE_H Klasa myengine, która dziedziczy po klasie engine wzbogaca go o m.in. obsługę sieci. W obiekcie klasy myengine powoływane są między innymi obiekty klas CListener oraz CSender, które są interfejsami sieciowymi dla instancji serwera oraz klienta aplikacji. Obiekty te udostępniają metody służące do wysyłania danych oraz odbierania (void mysend(int,int,int) oraz void listen(void)). Realizacja warstwy sieciowej: Realizacja przesyłu danych wykonywana jest przy pomocy gniazd datagramowych, a więc wykorzystywany jest protokół UDP, który jest bezpołączeniową metodą komunikacji w sieci typu IP. Model wykorzystany do rozmowy aplikacji między sobą to tradycyjny klient-serwer. Schemat modelu klient-serwer: W aplikacji został zaimplementowany typowy model aplikacji sieciowej typu klient-serwer. Serwer tworzy gniazdo sieciowe, a następnie przypisuje go do adresu sieciowego komputera oraz do podanego numeru portu, na którym chcemy, aby nasz serwer nasłuchiwał. Po otrzymaniu informacji serwer przetwarza otrzymane dane, a następnie odsyła te dane nadawcy. Klient właściwie nie różni się bardzo od serwera. Jednak elementy odróżniające implementacje klienta od implementacji serwera to: otwieranie losowego portu z zakresu wysokich portów (SDLNet_UDP_Open(0) argument 0 oznacza port losowy), Bindowanie socketu na podany adres serwera oraz jego port ostatnia różnica to zamieniona kolejność wywoływania funkcji wysyłania i odbioru klient najpierw wysyła dane, a następnie oczekuje przetworzonych danych przez serwer, do którego kierował żądanie. 6
socket socket bind bind recv Dane (żądanie) send Przetwarza nie żądania send Dane (odpowiedź) recv Rys. Uproszczony schemat modelu klient-serwer. Definicja klasy właściwego serwera UDP: #ifndef UDP_SERVER_H #define UDP_SERVER_H #include <stdio.h> #include <stdlib.h> #include <string.h> #include "SDL_net.h" class CUDP_server { private: UDPsocket sd; IPaddress srvadd; UDPpacket *p; public: 7
CUDP_server(char* host, int port); char* getdata(); void setdata(char* inputdata); void restart(); }; #endif Opis pakietu UDP typu UDPpacket: p->channel kanał pakietu (priorytety). p->data - dane, które niesie pakiet. p->len - długość danych p->maxlen - maksymalna długość danych - p->address.host - adres hosta p->address.port - numer portu Wydruk z logu serwera gry: UDP Packet incoming Chan: -1 Data: 400;300;0; Data sizeof: 4 Len: 10 Maxlen: 32 Status: 10 Address: a00a8c0 3704 Wydruk pakietu w postaci ASCII wczesna wersja programu. ASCII - @ [CnE$T[l400;300; Po nagłówku pakietu UDP następują dane przesyłane z klienta do serwera (zaznaczone na czerwono). Zrzut ekranu na podgląd pakietu ze snifera (Wireshark) Dlaczego UDP? Protokół UDP jest bezpołączeniowy, a więc nie wykorzystuje się tu mechanizmu połączeń i mechanizmu 3-krotnego uścisku 8
dłoni. Dzięki temu UDP jest znacznie szybsze niż połączenia TCP, szacuje się, że dla rozwiązań wymagających powyżej 4 połączeń na sekundę użycie protokołu bezpołączeniowego jest znacznie korzystniejsze. Jednak najważniejsza wadą UDP jest brak potwierdzenia odbiorcy o właściwym otrzymaniu pakietu. Możliwa jest, więc utrata pakietu bez wiedzy nadawcy. Nie jest to problemem przy nadawaniu kilku pakietów na sekundę, ponieważ informacje nadmiarowe uzupełniające ewentualny brak. Problem pojawia się w przypadku synchronizacji gry dzięki numerowi klatki, w którym wykonywana jest dana akcja. Trzeba, więc używać nie poklatkowej synchronizacji oraz zapewniać podstawową kontrole przepływu pakietów UDP między klientem a serwerem. Oba te warunki gwarantują niezawodne działanie całego mechanizmu. Główne problemy i metody ich rozwiązania: Frame Rate Limiter, problem szybkości? Silnik gry opiera się na głównej ciasnej pętli, której zadaniem jest uaktualnianie danych środowiska gry, wykonywaniem cyklicznych obliczeń, wywoływaniem interfejsów komunikacyjnych oraz renderingu świata gry. Komputer stara się wykonywać program jak najszybciej może, a więc szybkość programu bezpośrednio zależy od częstotliwości taktowania zegara procesora. Wniosek jest prosty i naturalny im szybszy procesor, tym szybciej program będzie działać, a co za tym idzie tym częściej będzie wykonywana główna pętla enginu gry. Gdyby program uruchamiany był zawsze na identycznych maszynach nie było by tego rozdziału, problem by po prostu nie istniał. Twórcy gier z przełomu lat 80 i 90tych często nie zadawali sobie trudu, aby w ogóle ten problem rozwiązywać. Stąd też zjawisko super szybkiego działania niektórych starych gier na współczesnych komputerach, w wyniku powoduje to kompletną nie możliwość gry (trudność opanowania tak szybkiego rozwoju sytuacji przez człowieka). We współczesności problem regulacji szybkości gry jest szczególnie ważny w obliczu ogromnych różnic w mocach obliczeniowych obecnie dostępnych maszyn. Nikogo dziś nie dziwią różnice mierzone w gigahercach, a o procesorach wielordzeniowych nie wspominając. Nie mniej ważnym powodem dla celowości normalizacji szybkości działania gry jest fakt komunikacji różnych instancji programu na różnych maszynach przez sieć. Gdy jeden gracz będzie dysponował mocnym sprzętem, a jego partner słabszym nie może przecież zaistnieć sytuacja, gdy program uruchomiony na szybszym komputerze będzie działać znacznie 9
szybciej, co wtedy z danymi przekazywanymi od gracza ze słabym komputerem? Przesyłanie danych będzie znacznie opóźnione nie z winy gracza. W efekcie jeden z graczy będzie miał nierówne szanse, komunikacja obu programów będzie nie równomierna (szybszy program będzie wysyłał dane z większą rozdzielczością ). Generalizując, już na etapie tego problemu rozgrywka będzie całkowicie zdesynchronizowana, gracze będą grać w dwie różne gry. Oczywiście problem synchronizacji nie opiera się tylko na znormalizowaniu czasu wykonania programu jednak jest ważnym czynnikiem tego zagadnienia. Rozwiązanie problemu normalizacji prędkości wykonywania. Problem ten można rozwiązać wykorzystując niezawodny licznik dostępny w komputerze, a więc licznik taktów procesora do pomiaru czasu i wprowadzeniu na tej podstawie potrzebnych opóźnień do uzyskania pożądanej prędkości. Początkowo pomiar czasu i związane z tym kalkulacje wykonałem na podstawie timerów udostępnianych w podstawowej bibliotece SDL. Obsługa tej funkcji została zaimplementowana w główny engin gry. Możliwe było wtedy mierzenie czasu, który upłynął od ostatniego wywołania metody Think(), a więc od ostatnich zmian w parametrach całego środowiska. Jednak wprowadzanie na tej podstawie opóźnień wykorzystując pustą pętle while lub korzystniejszą funkcję SDL_Delay(int) nie dawało stabilnych i niezawodnych rezultatów. Przy rozważaniach i próbach z timerami implementowałem nawet osobną klasę obsługującą timery w SDLu (timer.h reprezentacja UML tej klasy na rysunku obok - > ). Timer -startticks: int -pausedticks: int -paused: bool -started: bool <<create>>-timer() +start(): void +stop(): void +pause(): void +unpause(): void +get_ticks(): int +is_started(): bool +is_paused(): bool Ostatecznie jednak ze wszystkich powyższych rozwiązań zrezygnowałem na rzecz biblioteki SDL_framerate.h, która wykorzystuje swoistą interpolację opóźnień, daje bardzo dobre i niezawodne wyniki, a jej bardzo proste użycie jest jej niezaprzeczalną zaletą. Bibliotek SDL_framerate.h udostępnia następujące funkcję: void SDL_initFramerate(FPSmanager * manager); int SDL_setFramerate(FPSmanager * manager, int rate); int SDL_getFramerate(FPSmanager * manager); void SDL_framerateDelay(FPSmanager * manager); 10
Jak widać funkcje te operują na wskaźniku na typ FPSmanager, który jest powoływany w części głównej inicjalizacji zmiennych enginu. Zasada działania SDL_framerate: Opóźnienie potrzebne to utrzymania prawidłowego tempa działania programu generuje funkcja SDL_framerateDelay, umieszczamy ją np. w części odpowiedzialnej za renderingu w głównej pętli programu. Jeśli komputer nie może utrzymać narzuconego tempa ustawia opóźnienie na zero i restartuje interpolację opóźnienia. Schemat obliczenia opóźnień w SDL_framerate: Rys. Schemat zaczerpnięty z dokumentacji SDL_gfx. 11
Synchronizacja. Synchronizacja gry sieciowej jest podstawowym zagadnieniem w pisaniu tego typu aplikacji. Przy rozwiązywaniu tego typu problemów trzeba wziąć pod uwagę wiele czynników mogących zdesynchronizować grę np. opóźnienia w przesyłaniu danych przez sieć, różne stany instancji programów działających na różnych komputerach, utrata danych podczas przesyłania itd. Synchronizacja zaimplementowana obecnie w programie opiera się na prostym mechanizmie oczekiwania na transmisję. Jest to zawodny sposób, który gwarantuje jedynie eliminację opóźnień na reakcję drugiego gracza w grze. Jest to, więc nie zupełnie metoda synchronizacji. Jednak zakładając obecnie wysoką częstotliwość informowania drugą instancję programu o zmianach można założyć, że rozgrywka jest synchroniczna. Dalsza rozbudowa synchronizacji będzie polegała na implementacji komunikatów z obsługą ich typów oraz priorytetów. Wtedy synchronizacja będzie opierała się na numerze klatki animacji, w której nastąpiła dana akcja. Jest to powszechnie stosowana praktyka przez programistów gier sieciowych. Konkretnym przykładem zastosowania tego rozwiązania jest popularna gra Starcraft. Rendering: Obecnie rendering całego świata gry realizowany jest prymitywną metodą rysowania prostych elementów w buforze ekranu przy każdym kroku pętli oraz czyszczenia tego bufora przy odświeżeniu. Jest to tymczasowy sposób mający na celu wizualizację dotychczasowych dokonań. Kompilacja projektu: Visual Studio C++ 2005 Express : Kompilacja odbywa się w tradycyjny sposób należy otworzyć plik projektu w VS, a następnie dodać ścieżki do bibliotek linkowanych dynamicznie SDL, SDL_net, SDL_gfx. Pamiętając, że należy ustawić ścieżki dla plików h czyli Include files oraz Library files dla plików z katalogów lib w poszczególnych bibliotekach. 12
Rys. Tool>Options>Project and Solutions> VC++ Directories Po dokonaniu tych ustawień należy zmienić profil, na release, a następnie wcisnąć klawisz, F7, aby skompilować program. Plik binarny znajdzie się w katalogu release. UWAGA: Visual Studio 2005 Express generuje pliki binarne, które uruchamiają się na systemach Windows posiadających odpowiednie pakiety Redistribution Packages oraz odpowiednie wersje C Runtime Library. Na systemach systemach systemach najnowszymi aktualizacjami nie będzie potrzebna żadna ingerencja jednak, na niektórych potrzebne będzie instalacja tych pakietów lub/oraz skopiowanie odpowiednich plików dll. (katalog dodatkowe_dll). Uniwersalne binarki można otrzymać kompilując projekt pełną wersją Visual Studio (oczywiście chodzi o kompilator cl) lub skorzystanie z darmowego Toolkit 2003 obsługiwanego z lini komend (cmd). Parametry z jakimi kompilowany był projekt: /O2 /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W2 /nologo /c /Zi /TP /errorreport:promet Kompilacja na innych systemach : Kompilacja na inne systemy niż windows jest możliwa dzięki zastosowaniu przenośnych bibliotek. Jednak nie kompilowałem projektu w innym środowisku niż windows i VS Express, więc nie będę opisywał tu procesu kompilacji na innych systemach. 13
Uruchomienie: W katalogu z plikiem uruchomieniowym osg.exe muszą znajdować się również pliki z dynamicznie linkowanymi bibliotekami: SDL.dll SDL_gfx.dll SDL_net.dll a, także plik konfiguracyjny o nazwie osg.conf, który musi zawierać: w pierwszej linii adres ip, na którym będzie działał serwer gry, a więc np. 192.168.1.1 w drugiej linii numer portu serwera np. 2000 w trzeciej linii natomiast znajduje się wartość 0 jeśli chcemy, aby aplikacja działała jako klient lub 1 jeśli chcemy uruchomić aplikacje w roli serwera. Przykładowy plik konfiguracyjny: Dla serwera: 192.168.0.1 2000 1 Dla klienta: 192.168.0.1 2000 0 UWAGA: Zalecane jest uruchamiać jako pierwszy kolejności aplikacje serwera, a później aplikacje klienta. Sterowanie: Sterowanie graczem odbywa się przy pomocy kursorów. Gracz reprezentowany jest jako biały kwadrat, a partner jako czerwony kwadrat. Wyjście z programu przy pomocy ESC lub poprzez zamknięcie okna. Dodatkowe uwagi: Po zamknięciu aplikacji w katalogu z plikiem exe zostaną wygenerowane dwa plik stdout.txt i stderr.txt. Zawierają one diagnostyczne listingi konfiguracji programu oraz listing pakietów odebranych przez serwer. 14
Rys. Ekran gry. Uwagi końcowe: Aplikacja nie jest w pełni funkcjonalną grą, a jedynie demonstruje wstępne możliwości uniwersalnego, enginu gry sieciowej, jaki staram się stworzyć. Łatwo można sobie wyobrazić jak proste jest dodanie teraz logiki dla najróżniejszych gier. Sprowadza się to jedynie do wypełniania i rozwijania implementacji w zasadzie 3 metod z klasy my_engin, które odpowiadają za inicjalizacje zmiennych gry, obliczenia i aktualizację parametrów oraz rendering. Oczywiście jak wspomniałem rozwój logiki gry nie jest jedynym zadaniem na przyszłość, trzeba zaimplementować mechanizmy synchronizacyjne oraz zoptymalizować interfejsy sieciowe aplikacji. 15