Moja praca magisterska

UniwersytetWarszawski 

WydziałMatematyki,InformatykiiMechaniki 

MichałSłapa 

Nralbumu:201095 

Architektura,projektirealizacja 

sieciowejgryakcjiczasu 

rzeczywistego 

Pracamagisterska 

nakierunkuINFORMATYKA 

grudzień2007 

Pracawykonanapodkierunkiem 

dr.JanuszaJabłonowskiego 

InstytutInformatyki

Oświadczeniekierującegopracą 

Potwierdzam,żeniniejszapracazostałaprzygotowanapodmoimkierunkiemikwalifikujesiędoprzedstawieniajejwpostępowaniuonadanietytułuzawodowego. 

Data Podpiskierującegopracą 

Oświadczenieautora(autorów)pracy 

Świadomodpowiedzialnościprawnejoświadczam,żeniniejszapracadyplomowa 

zostałanapisanaprzezemniesamodzielnieiniezawieratreściuzyskanychwsposób 

niezgodnyzobowiązującymiprzepisami. 

Oświadczamrównież,żeprzedstawionapracaniebyławcześniejprzedmiotemprocedurzwiązanychzuzyskaniemtytułuzawodowegowwyższejuczelni. 

Oświadczamponadto,żeniniejszawersjapracyjestidentycznazzałączonąwersją 

elektroniczną. 

Data Podpisautora(autorów)pracy

Streszczenie 

Wtokupracymagisterskiejmiałemokazjęspróbowaćwłasnychsiłwprzedsięwzięciu,jakim 

jesttworzenieodpostawwłasnejgrykomputerowej.Projektdałmiokazjędoprzyjrzenia 

siębliżejprogramistycznymaspektomelektronicznejrozrywkiizmierzeniasięzestawianymi 

przeznieproblemami.Poniższapracapowstałajakopodsumowaniemojegoprojektuima 

nanaceluprzedstawieniezarównoogólnejproblematykitworzeniaiprogramowaniagier 

komputerowychjakidokładniejsząanalizęwybranychzagadnieńznimizwiązanych.Wcałej 

pracyteoretycznejodnoszęsięnietylkododoświadczeńnabytychprzymagisterskimprojekcie 

realizowanymwramachtejpracy,alerównieżdodoświadczeńzawodowych,gdyżnacodzień 

jestemprogramistągier,dotychczaspracującymprawiedwalatanadniedawnozakończonym 

projektem“Wiedźmin:GraKomputerowa”. 

Słowakluczowe 

grakomputerowa,gradlawielugraczy,serwer 

11.3Informatyka 

Dziedzinapracy(kodywgprogramuSocrates-Erasmus) 

D.Software 

D.1ProgrammingTechniques 

D.1.mMiscellaneous 

Klasyfikacjatematyczna 

Tytułpracywjęzykuangielskim 

Architecture,designandimplementationofmultiplayeractiongame

Spistreści 

Wprowadzenie ....................................... 5 

0.1. Cel.......................................... 5 

0.2. Następnerozdziały................................. 5 

1. Tematykaprojektu .................................. 7 

1.1. Grakomputerowa.................................. 7 

1.1.1. Rynekgierkomputerowych ........................ 8 

1.1.2. Tworzeniegier-zespół .......................... 9 

1.1.3. Tworzeniegier-produkcja ........................ 10 

1.2. Mojagra ...................................... 11 

1.3. Grysieciowe..................................... 11 

1.3.1. Kierunkirozwojurozrywkisieciowej ................... 12 

2. Projekt.......................................... 15 

2.1. Założeniaprojektu ................................. 15 

2.2. MaelstormOnline ................................. 15 

2.3. Wpływwymagańprojektunaarchitekturęgry ................. 17 

2.4. Szerszakoncepcjagry ............................... 18 

3. Implementacja ..................................... 21 

3.1. Projektiśrodowisko ................................ 21 

3.1.1. Historiaprac ................................ 21 

3.1.2. Środowiskoiplatforma........................... 22 

3.1.3. Użytebiblioteki............................... 23 

3.2. Architekturaaplikacji ............................... 25 

3.2.1. Definicjaproblemu............................. 25 

3.2.2. Światgry .................................. 25 

3.2.3. Symulacja.................................. 28 

3.2.4. Synchronizacja ............................... 29 

3.2.5. Wnioski ................................... 32 

3.3. Implementacjawarstwysieciowej ......................... 34 

3.3.1. Wybórprotokołukomunikacyjnego.................... 34 

3.3.2. Serializacja ................................. 34 

3.3.3. Obsługapołączeń.............................. 36 

3.4. Dynamicznewykrywaniekolizji .......................... 37 

3.4.1. Kolizjeobiektów .............................. 37 

3.4.2. Kolizjezgeometriąświata......................... 39 

3.4.3. Wnioski ................................... 40 

3

3.5. Wyświetlaniegrafiki ................................ 41 

3.5.1. Interfejsmoduługraficznego........................ 41 

3.5.2. Animacja .................................. 42 

3.6. Pathfinding-wyszukiwanieścieżek ........................ 45 

3.6.1. Definicjaproblemu............................. 45 

3.6.2. Wydajność ................................. 47 

3.6.3. A*...................................... 47 

3.6.4. Automatycznypodziałpłaszczyzny.................... 48 

3.6.5. Pokoje.................................... 49 

3.6.6. Grafwidoczności .............................. 50 

3.6.7. Punktynawigacyjne ............................ 52 

3.6.8. Dodatkoweelementysystemuwyszukiwaniaścieżek........... 53 

3.6.9. Wnioski ................................... 56 

3.7. Algorytmstadaisztucznainteligencja ...................... 58 

3.7.1. Implementacja ............................... 58 

3.7.2. Wydajność ................................. 59 

3.7.3. Modyfikacjealgorytmu........................... 59 

3.7.4. Zastosowania ................................ 59 

3.7.5. Maelstorm.................................. 60 

3.7.6. Dołączonyprogramdemonstracyjny ................... 61 

3.8. Technikiprogramistyczne ............................. 63 

3.8.1. Alokacjapamięci .............................. 63 

3.8.2. Profilowaniekodu ............................. 64 

4. Podsumowanie ..................................... 67 

4.1. Wnioskidotycząceprojektu ............................ 67 

4.2. Testyaplikacji ................................... 68 

4.2.1. Warunkitechniczneprzeprowadzonychtestów.............. 68 

4.2.2. Wynikitestów ............................... 68 

4.2.3. Horyzontyrozbudowyprojektu ...................... 69 

A.Materiałydostarczonewrazzpracąmagisterską ............... 71 

Bibliografia ......................................... 73 

4

Wprowadzenie 

Mojapracamagisterskapodzielonajestnadwieczęści.Praktyczną,wzakresiektórejopracowałemsieciowągręczasurzeczywistego,skupiającsięprzedewszystkimnaopracowaniu 

uniwersalnegoiskalowalnegosilnikagry.Częśćteoretycznąpracystanowinatomiastniniejszy 

dokument,wktórymskupiamsięnaopisiezagadnieńzwiązanychztworzeniemgierkomputerowych,zktórymispotkałemsięprzedewszystkimwtokupracnadprojektem.Jednocześnie 

konfrontujętuzastosowaneprzezmnierozwiązaniaztymiodnalezionymiwliteraturze,lub 

zktórymimiałemdoczynienia,wtrakciepracyzawodowejnadniedawnowydanymtytułem 

“Wiedźmin:GraKomputerowa”[TW07]. 

0.1. Cel 

Zadaniem,któreprzedsobąpostawiłem,podkątempracypraktycznej,byłostworzenieprototypusieciowejgrykomputerowej,wktórymmiałemzamiarzastosowaćwłasne,myślę,że 

ciekawerozwiązaniawkwestiiarchitekturyaplikacji.Zależałomiszczególnie,nastworzeniu 

wydajnejarchitekturyklientserwerodosyćnietypowymsposobiesynchronizacjisymulacjipo 

obustronach.Problemspójnościświatagrynakilkupołączonychmaszynachniejestbynajmniejbanalnyipierwszeszerokostosowanerozwiązaniazupełnienieskalowałysiędogier,w 

którychgraćmożewięcejniżmaksymalniekilkunastugraczy.Rozwiązania,któreprzyjąłem 

majązapewnićwydajnośćibezpieczeństwoaplikacjiserwera,umożliwićgręmożliwedużej 

liczbygraczy,asamaarchitekturaaplikacjimaułatwićrozbudowęizmianyprojektu. 

Jednocześniewteoretycznejczęścipracy,głównynaciskchciałempołożyćnaanalizęwybranych,najpopularniejszychaspektówprogramowaniagier.Zastanawiamsiętunadrozwiązaniamialgorytmicznymiiprojektowymi,opierającsięnawłasnychprzemyśleniach,literaturzeizaobserwowanychwpraktycerozwiązaniach. 

0.2. Następnerozdziały 

Pracaskładasięzczterechrozdziałówidodatku.Wrozdziale1przybliżamogólnieproblematykęidziedzinęprojektu.Wymaganiaiopisprojektuodstronykońcowegoużytkownika 

przedstawiamwrozdziale2.Sercemmojejpracyjestrozdział3,wktórymskupiamsięna 

zagadnieniachimplementacyjnychkonkretnychmodułówgry,zarównowkontekściemojej 

pracy,jakiprzyszerszymspojrzeniunaproblem.Nakońcuwrozdziale 4opisujęjakwidzę 

ewentualnyrozwójmojejaplikacjiorazpróbujęwyciągnąćzpracnadniąkońcowewnioski.Zamieszczamwnimrównieżwynikiprzeprowadzonychtestówwydajnościowychmojej 

aplikacji. 

5

Rozdział1 

Tematykaprojektu 

Moimprojektemmagisterskimjestprostagrakomputerowa 1 .Niemiałemwintencjiporywaniasięzmotykąnasłońceitworzeniakompletnegoorazrozległegoprojektu.Pisaniegier 

wymagaimplementacjiwieluróżnychmechanizmówibystworzyćprodukt,przykuwający 

odbiorcęnadługiegodzinykoniecznejestwykonanienietylkowielupracprogramistycznych 

nadsamągrą.Potrzebnejeststworzeniezestawunarzędzidoimplementacjimechanikigry, 

jejprojektiimplementacja,stworzeniegrafiki,dźwiękuiostateczniekoordynacjawszystkich 

tychelementów.Mogłemspróbowaćpracowaćnadwszystkimitymielementamijednakowoi 

stworzyćmały,zamkniętyprojekcikoniewielkichmożliwościachrozbudowy.Wolałemjednak 

stworzyćpewienszkieletgry,szczególniedopracowanyodstronyprogramistycznej.Interesuje 

sięgramijakoprogramista,dlategonajbardziejzależałominaimplementacjimocnegosilnika 

2 gry,szczególnieskupiającsięnaaspektachsieciowychorazwydajnościowychaplikacji 

serwera.Oczywiściewmojejpracymamyzarównotrójwymiarowągrafikęjakiprzyjemną, 

choćprostąrozgrywkęsieciową,jednaknienatopołożonybyłgłównynaciskwprojekcie. 

1.1. Grakomputerowa 

Skoromówimyogrzekomputerowej,czymonajestzpunktuwidzeniaprogramisty? 

Pisaniegryjesttworzeniempewnejsymulacjirzeczywistości.Jeślipopatrzymynagręjako 

program,tojejpodstawowymzadaniemjestsymulowaniepewnejwyspecyfikowanejabstrakcjiświata.Wrazzpostępemtechniki,abstrakcjatamożebyćcorazbardziejzbliżona,zarównodoświatarzeczywistego,jakifantastycznychświatówpowstałychwumysłachtwórców.Oczywiścienigdyniebędziemożliwezupełneodtworzenieświataimechanizmównimkierujących 

wgrze,dlategokoniecznebędązawszepewneuproszczeniaiprzybliżenia. 

Choćsymulacjanigdyniebędzie”dokładna”,możnazastanowićsię,czymiarą”jakości” 

gryjestmożliwiedokładneodwzorowanieprzezniąrzeczywistości.Napewnonadajetogrze 

realizmuiumożliwiawiększezaangażowaniesięgraczawprzedstawianyświat,alemoim 

zdaniemnietojestkwintesencjądobregoproduktu.Chodzijednakozabawę,odciągającąna 

kilkachwilodrzeczywistości.Tocopokazujemynaekraniepowinnobyćnietylerealistyczne, 

copoprostuładne,bynierazićgraczaprzyzwyczajonegodowysokiejjakościgrafiki. 

1 Grakomputerowa-rekreacyjnaaplikacja,będącaźródłemrozrywki.Zpowoduosobistegoprzyzwyczajenia,wtokupracynadużywamtegosformułowaniaodnoszącegosięzdefinicjidogierdziałającychnakomputerachosobistych.Prawidłowopowinienemużywaćokreśleniagrawideo.Pierwszegrywideo,topowstaław 

1958”TennisforTwo”iw1962”Spacewar!”. 

2 Silnikgry-implementacjakluczowejmechanikigrywideo,bądźinnejinteraktywnejaplikacjigraficznejczasurzeczywistego.Możeobejmowaćkluczowemechanizmygry,wtymsymulacjęświata,wyświetlanie, 

obsługędźwiękuifizyki,atakżemechanizmyzarządzaniazasobamioraznarzędziadoichedycji. 

7

Jeżeliwięcpopatrzymynagręjakonasymulacjęzauważymy,żenaszymzadaniemprzyjej 

tworzeniu,będziepróbanaśladowaniapewnychmechanizmówprzedstawianegoświata.Sposóbnaszegonaśladowaniatychmechanizmówtylkowniektórychprzypadkachbędzieopartynamodelufizycznym.Zwyklebędziemyopieraćsięnazupełnieniezależnychodniegorozwiązaniachiobserwacjach.Dobrymprzykłademjestnaprzykładmodeloświetleniawgraficekomputerowej.Próbamimikiprawrządzącychświatłemwprogramachkomputerowychwymagazbytdużejmocyobliczeniowejbybyłotowykonywanewczasierzeczywistym.Istniejątechnikiśledzeniapromieni(RayTracing),alekorzystasięznichwyłącznienapotrzebytworzeniastatycznychobrazów,bądźanimacji,którychgenerowaniepochłaniazbytdużoczasu, 

bymogłybybyćtworzonenabieżąco.Trójwymiarowagrafikakomputerowa,wyświetlanaw 

czasierzeczywistym,odpoczątkupowstawaławoparciuouproszczonemodeleoświetlenia 

(Lamberta,modelPonga)itechniki,któredobrzesprawdzałysięwpraktyce,jednaknie 

bazowałybezpośrednionarzeczywistychprawachfizycznych. 

Światmojejgryjestbardzoumowny,alenieoceniałemmojegosilnikapodwzględemtego 

jakrealistycznabędzieopartananimgra.Byumożliwićstworzenieprzyjemnejwodbiorze 

grywmoimsilnikuskupiłemsięnawłasnościachtakich,jakudziałmożliwiedużejliczby 

graczy,przyjednoczesnymzachowaniumodeluzręcznościowejgryakcji. 

1.1.1.Rynekgierkomputerowych 

Grykomputerowekojarząnamsięwszystkimgłówniezzabawą,trzebawięczastanowićsię, 

czymożnazajmowaćsięniminapoważnie.Początkirynkugierkomputerowychdatujesię 

napóźnelatasiedemdziesiąteibyłtowówczasniszowyrynekhobbistyczny,zyskującypopularnośćwrazzdostępnościąkomputerówosobistych.Jeszczewewczesnychlatachdziewięćdziesiątych,największehityniezbytjeszczeupowszechnionej,komputerowejrozrywkipowstawałyczęstorękamisamotnychtwórców.Wtychteżczasach,powstawałypierwszestudiazajmującesięprofesjonalnietworzeniemgierprzeznaczonychnakomputeryosobisteorazswojądziałalnośćrozpoczynalipierwsiwydawcy.Rynekrozwijałsięwrazzrozwojemsprzętukomputerowego,wdużejmierzezresztąsambyłmotoremtegorozwoju.Wciążwykazujeondużąniestabilność.Ciąglepowstająnowiproducenci 

gier,częstonazgliszczachtych,którymsięnieudało.Rynekjednakpowoliosiągadojrzałość, 

adochodyjakienotujepozwalająmujużkonkurowaćzprzemysłemfonograficznym. 

Elektronicznarozrywkazresztąjużodswoichpoczątkówmiałabardzodużywpływna 

rozwójinnychdziedzinprzemysłukomputerowego,szczególniesprzętu.Gryjakoaplikacje 

wykorzystującepełnąmockomputerówosobistychwymuszałyichrozwój,zktóregonastępnie 

korzyściczerpałyinnegałęzieprzemysłu.Pozasiłąprocesorów,miałyszczególnywpływna 

rozwójkartiakceleratorówgraficznych,kartdźwiękowych,czynapędówCD,choćwwypadku 

tychostatnichwciążkluczowąrolęodgrywałprzemysłmuzyczny,anastępniefilmowy. 

Zdoświadczeniawiem,żeprzynajmniejpolskirynekgierkomputerowychbardzopotrzebujedobrychprogramistów.Średniapłacajestniższaodtejjakąoferujesektorbankowy,a 

dotegoniestabilnośćrynkuodbijasięnegatywnienastabilnościzatrudnienia.Zuwagina 

wciążrosnącekosztyprodukcjideweloperzysącorazbardziejuzależnieniodwydawcówiczęstonawetsukcesyprzywydaniukilkutytułówmogąnieuchronićfirmyprzedupadkiemw 

następnychlatach.Dlategoczęstoludziepracującynadgramizmieniająfirmy.Rynekjest 

wciążwyraźnienienasycony,więcnaszczęścieniemaproblemówzeznalezieniemponownego 

zatrudnienia. 

Kolejnymproblememjestniejednolitośćzespołówprodukcyjnych.Tylkoniewielkąich 

częśćstanowiąprogramiści.W”Wiedźminie”naponadsiedemdziesięcioosobowyzespół,programistówzatrudnionychdopracynadgrąbyłookołodziesięciu.Ozbliżonychproporcjach 

8

słyszałemrównieżwodniesieniudoinnychprojektów.Dlategonarynkugier,choćinżynieria 

programowanianiewymagaodprogramistyumiejętnościdialoguzkońcowymklientem,musi 

onpotrafićznaleźćwspólnyjęzykwewłasnymzespole,wktórymrównorzędnymipartnerami 

sądlaniegoludzieniezwiązanizprogramowaniem. 

Warunkipracyprogramistynarynkuelektronicznejrozrywkisąprawdopodobniepowodem,dlaktóregowieluludziwybierasektorfinansowyalbousługowy.Rynekjednakistnieje 

iwykazujerosnącezapotrzebowaniemnanowychludzi.Oferujepracębynajmniejnielekką, 

aledlawielu,wtymdlamnie,ciekawąiwymagającąstawieniaczołaszerokiemuwachlarzowi 

problemówprogramistycznych. 

1.1.2.Tworzeniegier-zespół 

Jakjużwspominałemskalaprzedsięwzięciajakimjesttworzeniegrykomputerowejwrazz 

rozwojemrynkudiametralniesięzwiększyła.Hitypoczątkulatdziewięćdziesiątychtakiejak 

nieśmiertelny”PrinceofPersia”(1989),czy”AnotherWorld”(1991)stworzonebyłyprzez 

samotnychprogramistów.Istniałyjużpierwszezespołydeweloperskie,alebyłyzłożonyz 

kilkuosób.Wrazzrozwojemkomputerówosobistychrozwinąłsięrynek,wrazzrynkiem 

zapotrzebowanienakomputerowąrozrywkę.Wrazzzapotrzebowaniem-zespołypowiększyły 

sięiwyspecjalizowały. 

Wchwiliobecnejliczebnośćzespołupracującegonadjednągrąjestróżnawzależnościod 

klasypowstającejprodukcji.Istniejągrystworzonewciągukilkumiesięcy,nagotowymsilniku.Wichpowstaniebezpośredniozaangażowanychbyłokilkuprojektantówpoziomów,grafikówipojedynczyprogramista,właściwierealizującytylkobieżącezapotrzebowaniazespołu. 

Nadnajwiększymiprodukcjamizaangażowanesąrzeczywiściedużezespoły,naprzykładnad 

grą”GTA4”wRockstarGamespracujeokołostupięćdziesięciuosób.Przy”Wiedźminie” 

pracekoncepcyjnerozpoczęłysięwkilkuosobowymzespole,abypolatachwdecydującej 

fazie,nadprojektembyłozatrudnionychponadsześćdziesiątosób.Wostatnimokresprac, 

przedwydaniemgry,zespółjeszczesiępowiększyłdowspomnianychwyżejsiedemdziesięciu 

osób.Dodatkowobyłaprowadzonawspółpracazzewnętrznymidziałamikontrolijakości.Oddzielnefirmyteżtworzyłyczęśćtrójwymiarowychmodelipostaciorazobiektówotoczenia,a 

takżeanimowanesekwencjefilmowerozpoczynająceikończącegrę. 

Akuratwtymprojekcieliczbadziesięciuprogramistówbyłalekkoniewystarczająca.Stanowiłaproblemwkońcowejfazie,gdyzuwaginadługiczasakomodacjiwprojekcie,nie 

możnabyłozaciągnąćnowychpracowników.Poniżejznajdujesięskróconyopiskompetencji 

pozostałychdziałów,zktórymibezpośredniowspółpracująprogramiściprzyprodukcjigry. 

Projektanci 

Działodpowiedzialnyzaprojektgry.Zarównoodstronymechanikijakifabułyorazprojektu 

konkretnychlokacji 3 czypoziomówgry.Oczywiściedziałtenbardzoróżnisięwewnętrznie, 

wzależnościodrodzajutworzonejgry. 

Napewnomożnawnimwyróżnićdziałmechaniki.Sątoludzie,którzynapoczątku 

projektująmechanikęgry 4 ,następniesąodpowiedzialnizaimplementacjęizbalansowanie 

rozgrywkinapostawiedostarczonychprzezprogramistównarzędzi. 

3 Używamterminu”lokacja”wodniesieniudowirtualnych,spójnychobszarówświatagry,któresątworzone 

wtrakciepracnadgrąjakojednacałość. 

4 Mechanikagry(ang.gameplay).Podtymterminemrozumiemwszystkieaspektyinterakcjigraczazsys- 

tememgry. 

9

Kolejnymelementemjestdziałimplementacji,przyjmującyróżneformywzależnościod 

rodzajutworzonejprodukcji.BardzopopularnewśródpolskichdeweloperówgryFPP 5 zatrudniajątuzwyklekilkuprojektantówpoziomów.Przyprojekcie”Wiedźmina”działtenbyłprzedewszystkimodpowiedzialnyzawymyślenieszczegółowejfabułygryorazjejimplementacjęnaprzygotowanychprzezdziałtechnicznylokacjachgry. 

Działgraficzny 

Natendziałskładająsięartyści,graficydwuwymiarowejitrójwymiarowejgrafiki,animatorzy,dźwiękowcyoraztechnicyodpowiedzialnizaprzygotowanieelementówgryodstrony 

graficznejitechnicznej.Ważnyjestkontaktprogramistówzgrafikami.Trzebapamiętać,że 

nieznająonidokładnejmechanikidziałaniagryiżenaturalnieoceniająproduktfinalnypo 

tymjakwygląda.Ichpracamożemiećbardzodużywpływnawymaganiapamięciowegryi 

jejprędkośćdziałania.Ważnejestbyimtouświadomić.Dobrąpraktykąjesttworzeniedla 

nichnarzędzipomagającychokreślaćkosztwydajnościowyipamięciowytworzonychprzez 

nichzasobów. 

Działkontrolijakości 

Wprodukcjigierniejesteśmywstaniegenerowaćautomatycznychtestówaplikacji,przynajmniejniewpełnymzakresie.Dlategokoniecznyjestsprawnydziałtestów.Napoczątkupracjestonprawiezbędny.Wmiaręzbliżaniasiędokońcaprojektunabieraznaczenia.PółtorarokuprzedzakończeniemWiedźminatesterówbyłodwóch.Przedsamymwydaniemgry 

wewnętrznydziałkontrolijakościWiedźminaliczyłprawiedwadzieściaosób,zczegoczęść 

zostałazatrudnionatylkodoczasupremiery.Dotegowspółpracowaliśmyzdziałamikontroli 

jakościwydawcyAtariorazzewspółzależnąfirmąCDProjektLocalizationCenter,która 

równieżwspierałanaswtestowaniugry. 

1.1.3.Tworzeniegier-produkcja 

Gdymamyjużkompletnyzespół,czaszabraćsięzaprodukcję.Tworzeniegierjestprocesem 

iteracyjnym.Ponieważnaproduktwynikowypracujejednocześniekilkazależnychodsiebie 

zespołów,dosyćszybkopotrzebnajestpierwszadziałającawersja.Bardzodobrąpraktyką 

jestzaczynanieodprototypu-prostegoszkieletugrystworzonegomożliwemałymnakładem 

sił,asprawdzającegopotencjałprojektu.Napodstawieprototypumożnaprzedrozpoczęciem 

rzeczywistejimplementacjiocenićizmodyfikowaćzałożonąmechanikęgry. 

Pracekoncepcyjnepotrzebujązaangażowaniadużomniejszegozespołuniżkońcowaimplementacjaprojektu.Powstającyprzeztrzylatahittegosezonu-graAssassinsCreedwyprodukowanaprzezUbisoftMontrealwpoczątkowejfazieprodukcjibyłatworzonaprzez8osób.Tenzespółtworzyłkoncepcjęgryorazrozpocząłpierwszepracenadsilnikiem.Wdalszychetapachpraczespółbardzoszybkosięrozszerzał,bypodkoniecprodukcjiurosnąćdo 

158osóbpracującychnadprojektem 6 . 

Dokumentacjaprojektowawbranżyrozrywkielektronicznejróżnisięijestsłabiejrozwiniętaniżwoprogramowaniubiznesowym.Rolęklientamożestanowićdystrybutor.WrozmowachznimniesąszerzejstosowanediagramyUML,przynajmniejwedługmojejwiedzy. 

5 GraFPP(FirstPersonPerspective).Rodzinatrójwymiarowychgierakcji,którełączyprezentacjaświata 

zperspektywypierwszejosoby.Graczwidzigręoczamisterowanegobohatera.Prekursoramigatunkubyły 

Wolfenstein3-D(1992)iDoom(1993). 

6 DanezaczerpnąłemzwywiaduzproducentkągryJadeRaymond. 

10

Oczywiściewprojekcieznalazłybyzastosowaniadokumentywizji.Ważnejestprzygotowaniediagramówklas.OdstronyprojektugrygłównymdokumentemjestGameDoc,bardzoszczegółowoopisującycałąmechanikęgry.Częstojegorolęspełniazbiórpomniejszychdokumentówopisującychposzczególneelementyprojektu.Relacjepomiędzyproducentemgryawydawcąróżniąsięodtychjakiepanująmiędzyproducentemaklientembiznesowym.Dokumenacjapełniwgrachdużomniejsząrolęijesttworzonaraczejnawewnętrznepotrzeby 

zespołuprodukcyjnego. 

Kolejnąistotnąrzecząsąnarzędzia.Będąpotrzebneinnymzespołom,dlategomusząpowstawaćszybko,wpoczątkowychfazachimplementacjiabywrazztworzeniemmechanizmów 

gry,powstałyjużnarzędziaumożliwiającewykorzystanieichwykorzystanieiichrozwójprzez 

grafikówczyprojektantów. 

Jakjużwspomniałem,pisaniegrytoprocesiteracyjny.Powstępnychprojektach,możliwieszybkopowinnapowstaćdziałającawersjagry.Wrazzniąpodstawowemechanizmy,naktórychopartabędzierozgrywka,byumożliwićpraceprojektantom.Początkoweetapyprodukcjimogąbyćpominięte,jeżeliproducentzdecydujesięnawykorzystaniugotowegosilnika 

gry.Przyustalaniuharmonogramupracprogramistycznychnależybraćpoduwagępozostałe 

zespołyizależnośćichpracyodstopniaimplementacji.Choćtoprogramiścijakopierwsi 

rozpoczynająpraceimplementacyjnenadprojektem,ichpracemogątrwaćdosamegojego 

końca. 

1.2. Mojagra 

Jakjużnapisałempowyżejgrykomputerowesączęstobardzodużymiprzedsięwzięciami, 

angażującymigrupęktórejtylkopomniejszączęśćstanowiąprogramiści.Przypisaniupracy 

magisterskiejmojąintencjąbyłowięcstworzeniepewnegoszkieletugry.Próbazmierzeniasię 

zestandardowymiproblemamiprogramistycznymipisaniagierorazstworzenieoryginalnej 

architektury,odpowiadającejspecyficemojegoprojektu.Niechciałemskupiaćsięnatworzeniuzasobówgryiustawianiurozgrywki.Chciałemstworzyćsilnikgrysieciowej,zobaczyć 

jaksprawdząsięwpraktycemojewłasne,oryginalnerozwiązaniawkwestiimechanizmów 

komunikacyjnychipodstawowejsymulacjiświatagrypostronieserwera. 

1.3. Grysieciowe 

Skoromojąpracęstanowigrasieciowa,porapowiedziećtroszkęotejgałęzikomputerowej 

rozrywki.Podpowyższymterminemrozumiewszystkiegrydziałającepomiędzykilkoma 

komputerami,połączonymizapośrednictwemzarównosiecilokalnej(LAN)jakiglobalnej 

(WAN).Stworzeniewydajnejarchitekturygrysieciowejbyłogłównymcelemmojejpracy. 

Możliwościpołączeniakomputerówiwymianyinformacjipomiędzynimi,wczasierzeczywistym,dosyćszybkozostałydostrzeżoneprzezproducentówgier.ZanimobsługasieciLAN 

stałasięstandardemkomputerówosobistych,gryczęstoumożliwiałypołączeniezinnym 

komputeremzapośrednictwemportówszeregowych.Grysieciowerozwijałysięwrazzrozwojempopularnościsiecilokalnych,internetuorazwzrostemszybkościtransmisji.Dziękicoraz 

większejdostępnościłączyszerokopasmowychwrodzajuDSL/ADSLgrysieciowepozwalają 

nazabawęcorazwiększejliczbiegraczyrównolegle.Największeprodukcje,najbardziejrenomowanychwydawców,jeżelinawetniesągramistrictedlawielugraczy,toprzynajmniej 

pozwalająnawspólnągręzapośrednictweminternetu. 

Technologiapisaniaaplikacjisieciowychwciążsięrozwija.Narynekwchodząprodukcje,którychpowstaniejeszczeniedawnobyłoniemożliwe,nietylkozewzględunaszybkość 

11

transmisji,alerównieżzewzględunatechnikitworzeniasamychgier. 

1.3.1.Kierunkirozwojurozrywkisieciowej 

Najczęściejgrasieciowastworzonajestwarchitekturzeklient-serwer(niewielkaczęśćgier 

dlakilkugraczystosowałamodelrównorzędny,wktórymwszyscyuczestnicyrozgrywkibyli 

wspólnieodpowiedzialnizasynchronizację).Serwermożezałożyćjedenzuczestnikówrozgrywkilubmogątobyćdedykowanemaszyny.Większośćgierumożliwiatakżerejestrowaniesięserwerówgrywoficjalnychserwisachwyszukujących.Wówczasgraczemająwgrzemożliwośćwyszukaniadostępnychwdanejchwiliserwerówgry.Nawetnadedykowanychmaszynach 

tylkonielicznegrysąwstanieobsłużyćliczbyrzędu,naprzykład,stupołączeń.Większość 

gierniezezwalanapołączeniewiększejliczbyniżkilkulubkilkunastugraczy,nawetposiadającychszerokopasmowydostępdointernetu. 

Odwielulatnastępujegwałtownyrozwójnowejgałęzigierdlawielugraczy.Massive 

MultiplayerOnline(MMO)togrypozwalającenajednoczesnązabawęnawettysięcyużytkowników.IchpoczątkówmożemydopatrywaćsięwtakzwanychModach,czylitekstowych 

grachRPG 7 ,pozbawionychgrafikiiobsługiwanychnajczęściejzapośrednictwemprotokołu 

telnet.Pierwsze 8 gryMMOumożliwiałyzabawętysięcygraczywewspólnymwirtualnym 

świecie.Byłtobardzodużykrokdlabranżyelektronicznejrozrywki.Nowegrytworzyły 

całąspołecznośćgraczy.Dystrybutor,jakożewymagautrzymywaniaoficjalnychserwerów, 

pobieranajczęściejmiesięczneopłatyodużytkowników.Jednocześnieaspektistnieniaspołecznościgryimożliwośćrozwojustatusugraczawświeciegry-tradycyjnadlagatunku 

gierRPG(najpopularniejużywanegowprodukcjachmassive)zaowocowałybardzodużym 

idługotrwałymprzywiązaniemgraczydoposzczególnychtytułówzgatunkuMMO.Sukceskomercyjnypierwszychprojektówspowodowałrozwójgatunkuipowstaniecałejlawiny 

kolejnychtytułów. 

ZwykledystrybutorgryMMOudostępniazestawoficjalnychserwerówdogry.Częstomamydoczynieniazrozproszonymzbioremserwerówobsługującychposzczególneczęściświata 

gry.SąteżprodukcjetakiejakGuildWars 9 ,wktórejpojedynczyserwerjestwstanieobsłużyćwieleegzemplarzyświatawktórychodbywasięsymulacjagry.Cechąwspólnąnowych 

produkcjiMMOjestuproszczonamechanikagry,pozwalającanaasynchronicznąobsługę 

klientów,jednocześniewbardzoatrakcyjnyispektakularnysposóbwizualizowanapostronie 

klienta. 

WielegierMMOmiałobardzodużeproblemyzbezpieczeństwemrozgrywki.Oszczędny 

protokółkomunikacjizbytdużączęśćmechanikigryrealizowałpostronieklienta(naprzykład 

poruszaniesięiwalkę),cobyłowykorzystywaneprzezgraczypoprzezstosowaniewłasnych 

lubprzerobionychaplikacjiklienta.WieluproducentówwykorzystywałowwalcezoszustwamiwgrzerozwiązaniawrodzajuGameGuard.Byłatoaplikacjapodobnawdziałaniudo 

programówantywirusowych,dołączanadogry.Zzałożeniamiałauniemożliwiaćklientowi 

7 

RPG-Roleplayinggame.Rodzinagierpowstałanapodstawie”papierowych”gierfabularnych. 

8 

Pierwsząwysokobudżetową,komercyjnągrąMMORPG(MultiplayerMassiveOnlineRoleplayingGame) 

byławydanaw1997rokuUltimaOnline. 

9 

Wydanaw2005rokugraArenaNet,napoczątkuopisywanajakoświeżepodejściedogatunkuMMORPG. 

Wpraktycegręciężkosklasyfikować,rozgrywkajestbardzoszybkaiwdużymstopniuzręcznościowa.Toczy 

sięwoddzielnychegzemplarzachświatagry,wktórychwystępowaćmożeodjednegodokilkunastuzdalnych 

graczy.Graczemogąsięjednakspotykaćliczniewobszarach”miejskich”,wktórychniewystępująelementy 

zręcznościowe.Tamłącząsięwgrupyirozpoczynająwłaściwąrozgrywkę.Producentchwalisię,żetechnologia 

sieciowaużytawsilnikujestwyjątkowooryginalnaioszczędnawtransmisji,coumożliwiłoznaczneobniżenie 

kosztówutrzymaniaserwerówizrezygnowaniezopłatabonamentowych.Jestonaowianamgłątajemnicy. 

PewnerozwiązaniazastosowanewmojejpracyczerpałemzrozważańnadimplementacjąGuildWars. 

12

wykorzystanieznanychsposobównadużyciasystemu.Bytoosiągnąćpodejmowaładziałania 

wrodzajuskanowaniaplików,kontrolędziałającychprocesówczyblokowaniewywołańokreślonychfunkcjiDirectXczyWindowsAPI.Osobiścieuważammożliwośćdokonaniatakich 

nadużyćzasłabośćarchitekturygryiprojektującswojągrę,miałemnaceluzapewnienie 

bezpieczeństwarozgrywkijużnapoziomiegłównychzałożeńprojektowych. 

Grysiecioweuważamzaprzyszłośćbranży.Wzrostmocykomputerówniedawnojeszcze 

wydawałsiębardzospowolniony,dopieropopularyzacjamaszynwielordzeniowychspowodowałapewienpowiewświeżościnarynkukomputerówosobistych.Natomiastrozwójszybkościtransmisjiiinfrastrukturyinternetuwciążpostępujeijestdalekiodosiągnięciagranicmożliwościrozwojutechnologicznego. 

SwojągręchciałemumiejscowićgdzieśpomiędzygramiMMO,astandardowymigrami 

sieciowymi.Chciałemdokonaćpewnegoeksperymentuinawłasnejskórzesprawdzićjakwielu 

graczymożeobsłużyćgraakcji.Starałemsięstworzyćbardzowydajnąaplikacjęserwera 

umożliwiającąprzyszybkimłączuidobrej,wielordzeniowejmaszynie,byjednocześniew 

świeciegrymogłasięspotkaćrzeczywiściedużaliczbagraczy. 

13

Rozdział2 

Projekt 

2.1. Założeniaprojektu 

•Planowałemstworzyćprostąiprzyjemnąinternetowągręakcji. 

•Modelsterowaniawzorowałemnaklasykachtakichjak„Asteroids” 1 czykilkuinnych 

grachzaliczanychdo„kosmicznych”gierzręcznościowych.Miałbyćprosty,intuicyjny 

iprzyjemny. 

•Gramiałaumożliwiaćzabawęmożliwiedużejliczbygraczy. 

•Graczmiałwcielaćsięwpilotakosmicznegomyśliwca,realizującegoróżnorodnemisje 

wpasieasteroidów. 

•Realizującpowierzonemuzadaniagraczmiałzarabiaćwirtualnepieniądze. 

•Uczestnicygrymielimiećmożliwośćpodejmowaniasięróżnychmisji.Ichzadaniamiały 

sięodsiebieróżnić.Czasamiichrealizacjamiaławymagaćodnichwspółpracyramię 

wramię,aczasamiprowadzićdonieuchronnejkonfrontacji. 

•Pomiędzyrealizacjąmisjigraczemielimożliwośćrozmowymiędzysobą,rozbudowy 

statkówzazarobionewirtualnepieniądzeorazposzukiwaniazleceńnanowemisjew 

pasieasteroidów. 

•Rozgrywkamiałabyćwizualizowanazwykorzystaniegrafikitrójwymiarowej,choćprostymodellotuzakładałdwuwymiarowąmechanikęgry. 

2.2. MaelstormOnline 

MojągręnazwałemMaelstormOnline.Stworzyłemzgodnyzzaplanowanymiwytycznymi,silniksieciowejgryakcji.Samakoncepcjagrywtrakciepisaniapracyuległapewnymzmianom. 

Zadanietworzeniasilnikagrypochłonęłowięcejwysiłkuipracyniżnapoczątkuzakładałem. 

Uważamgowbieżącejchwilizakompletny,choćzpowoduograniczeńczasowychpewnemu 

uproszczeniuuległywłaściwościsamejrozgrywki. 

Takwtejchwili,wpunktach,mogęprzedstawićcechymojejgry. 

1 Asteroids–grawydanaw1979rokuprzezAtariInc.Polegałanalataniustatkiemwdwuwymiarowej 

przestrzenikosmicznejograniczonejrozmiaremdoekranuiniszczeniukolejnychfalasteroid. 

15

Rysunek2.1:Disasteroids3D.Wersjaklasycznejgryakcji,będącajednązmoichinspiracji. 

•Podstawowaforma,koncepcjaisposóbkontroliorazprezentacjigryzostałyzrealizowane 

zgodniezzałożeniami. 

•Modelsterowaniajestzgodnyzzałożeniami.Obiektyporuszająsięzzachowaniemkierunkuruchuipędu.Mogąobracaćsiędowolnieizmieniaćtrajektorięruchu,przyśpieszającwkierunkuwktórymsązwrócone.Naruchwpływateżsiłatarcia 

2 . 

•Rozgrywkatoczysięwpasieasteroidów.Wświeciecałyczaswystępujezbliżonaliczba 

asteroidów.Namiejscezniszczonychzczasempojawiająsięnowe. 

•Pozalogowaniusiędogry,graczwybierajedenztrzechdostępnychstatków. 

•Dodyspozycjigraczasątrzyrodzajebroni. 

•Zarównostatkigraczajakiasteroidymogązostaćuszkodzonewwynikukolizjibądź 

trafieniapociskiem.Statkiprzedbezpośrednimiuszkodzeniamibronipoleenergetyczne. 

Słabnieonogdyblokujetrafienia,aleodnawiasiępowoliwrazzupływemczasu. 

•Graczewspółzawodnicząnaserwerzedążącdozdobycianajwiększejliczbypunktów. 

•Punktyprzyznawanesąwmałejliczbiezaniszczenieasteroidów.Większąliczbępunktówmożnazdobyćniszczącstatkiinnychgraczy. 

•Gdystatekgraczazostaniezniszczony,możeonponowniewejśćdogrywnowowybranymstatku,alekosztujegotookreślonąliczbępunktów. 

•Graczewiedząktóryznichdysponujenajwiększąliczbąpunktów,dlategoutrzymanie 

przezniegoprowadzeniawpasieasteroidówjestdodatkowoutrudnione. 

2 Mimożewpróżnitarcieniewystępuje,uwzględniłemjewmoimmodeluporuszania,gdyżzwiększaono 

atrakcyjnośćrozgrywki.Powodujeżegraczeniemusząobawiaćsięzbytniegonabieraniaprędkościasama 

rozgrywkaniejesttakchaotycznaiprzypadkowa. 

16

2.3. Wpływwymagańprojektunaarchitekturęgry 

Wymaganiaprojektubyłydecydującymczynnikiemnaetapieprojektowaniaaplikacjiisilnika 

gry. 

•Wgrzebierzeudziałmożliwiewielugraczy—Komunikacjamusibyćoszczędna, 

aaplikacjaserwerabardzowydajna. 

•Gratoczysięwprzestrzenikosmicznej”rzadko”wypełnionejobiektami— 

Towymaganiewpływanaarchitekturęwnastępującychkwestiach: 

–Możemyograniczyćwiedzęgraczyoświeciedoichnajbliższegootoczenia,ato 

wpływanawydajnośćibezpieczeństwoaplikacji. 

–Nietrzebaimplementowaćmechanizmu”wyszukiwaniaścieżek”. 

–Zdarzeniaświatagrymająwpływzwyklenaniewielkiegrupyobiektów.Jeżeli 

przyjdązopóźnieniem,doichpoprawnegoobsłużeniapowinnawystarczyćwstecznasymulacjadotyczącawyłącznieobiektówbezpośredniozwiązanychzezdarzeniem. 

–SystemAIwMaelstormmożnaoprzećoalgorytmstada,przedstawionewrodziale3.7 

•Interfejsgryjestprosty,asamarozgrywka„łatwaiprzyjemna”—Towymagałoumożliwieniawyświetlaniaładnejgrafikitrójwymiarowej,modeliiefektówświetlnych.Światgryjestdwuwymiarowy,alegrafikamusisięprzystępnieprezentować.Zdrugiejstronyaplikacjaklientaniejestspecjalnierozbudowanaadziękiswojejprostocieniemusiałemsięskupiaćnadjejoptymalizacją. 

•Wmodelugryintuicjaitaktykamająbyćistotniejszeodczystejzręczności 

irefleksu—Towsumiejestcechagrywynikłaznałożonychnaniąwymagań.Jej 

implementacjawymaga: 

–Czystyrefleksniemożedominowaćrozgrywki,ponieważdyskwalifikujegraczyo 

większychopóźnieniach. 

–Akcjegraczawykonująsiękrótkiczasporzeczywistymwydaniuprzezgraczapolecenia.Tenczasjestpotrzebnybyinformacjaoakcjidoszłanaserweribyserwer 

rozesłałjądozainteresowanychgraczy. 

•Obiektysąwciągłymruchu,tylkoichniewielkaczęśćjestwspoczynku 

—Towymuszabardzowydajnąarchitekturęsymulacjiporuszaniasięobiektów.Dla 

oszczędnościkomunikacjisymulacjaporuszaniamusibyćniezależnapostronieserwera 

iklientów. 

•Graczemusząmiećprzyjemnośćzzabawywmiaręniezależnieodopóźnienia 

wkomunikacjizserwerem. 

–Odpornośćnaopóźnienia. 

–Wmomencienadejściaopóźnionejwiadomościzserweramusimymóc”cofnąć”w 

czasiezwiązaneznimobiektyiponowniejezasymulowaćporeakcjinazdarzenie. 

•Gramabyćwpełni„uczciwa”inależyuniemożliwićoszukiwanieserwera. 

17

–”Serwermazawszeracje”—symulacjaświatapostronieklientajestodbiciem 

symulacjiświatanaserwerze. 

–Graczwysyładoserwerawyłącznieswojesterowanieorazdodatkowezapytania 

odnośniewidzianychprzezniegoelementówsymulacji. 

Bynietracićskalowalnościiuniwersalnościprojektu,istotnebyłozachowaniewłaściwejmodularyzacjikodu,umożliwiającejłatwąmodyfikacjęizamianęposzczególnychczęści 

silnika.Dlategostarałemsięwmiaręmożliwościniedoprowadzaćdogłębokichzależności 

pomiędzyarchitekturąaplikacjianastępującymiwłaściwościamigry: 

•Dwuwymiarowyświatgry.Powinnabyćmożliwośćstworzeniaproporcjonalniemałymkosztemzupełnienowegoświatagry. 

•Użyteprotokołykomunikacyjne. 

•Sposóbgraficznejprezentacjiświata. 

2.4. Szerszakoncepcjagry 

TworzącMaelstormchciałemspróbowaćswoichsiłwimplementacjigrydlawielugraczydostępnejzapośrednictweminternetu.Taknaprawdęmiałemwzamyśledużoszersząkoncepcję 

rozgrywki.ChciałembyMaelstrom,wpostacizbliżonejdoobecnej,byłelementemwiększego, 

rozproszonegosystemu.Zakładałem,żegraalbobędziemogłaobsłużyćidącąwsetkiliczbę 

graczy,alboobsługamniejszejichliczbybędzienatylemałokosztowałaaplikacjęserwera, 

żebędziemożnanapojedynczymkomputerzeuruchomićkilkajejinstancji. 

WówczasmożnabyMaelstormrozbudowaćododatkowąaplikację,tworzącąspójnyświat 

grywktórymkluczowymelementembyłabyspołecznośćgraczy.Ta”graspołeczna”symulowałabyrozległyświatstacjikosmicznych,wktórychgraczeprzebywalibypomiędzymisjami 

wypełnionymiakcją.Mogłabybyćbardzouproszczonaipozwalaćgraczomnawydawanie 

zarobionychpieniędzy,interakcjęzinnymigraczamiorazpodejmowanienowychwyzwańrealizowanychnaserwerzegryakcji(czyliMaelstromwjejaktualnejpostaci).Głównaaplikacjaniepotrzebowałabytrójwymiarowejgrafikiczyefektownegomodeluakcji.Niemiałabyelementówzręcznościowychipostronieserwerabyłabyzrealizowanajakoaplikacjabazodanowa. 

Serwermógłbywięcobsługiwaćcałąwirtualnąspołecznośćgraczy. 

Byłabytowłaściwiezupełnienowagra,obardzodużejmożliwościrozbudowy,będąca 

spoiwemzapewniającymcałejrozgrywceatrakcyjność.Wrazzgrąakcji,którejsilnikzaimplementowałem,umożliwiłabystworzenieżywejspołecznościgraczy.Jejmożliwośćrozbudowyiwłasnościzależałybywyłącznieodmożliwościimplementacyjnych.Mogłabyumożliwiać 

stworzenieekonomiiświatanaktórywpływmiałybyakcjerealizowaneprzezgraczyiktóry 

pozwalałybygraczomnazabawęwhandelwirtualnymidobrami.Możnabyteżzaimplementowaćsystemorganizacjiwktórychskładmoglibywchodzićgracze.Organizacjeoczywiście 

prowadziłybywłasnąpolitykęfinansów,sojuszyiwojen.Tobyłbybardzomocnymechanizm 

społeczny,którypozwalałbynanadaniedodatkowegowymiaruzmaganiomgraczywprzestrzenikosmicznej.Całośćtakiejaplikacji,jakjużmówiłem,ograniczajątylkomożliwościimplementacyjneewentualnegoautoraiwyobraźnia.WwynikujejpowstaniacałagrastałabysięrzeczywiścieprodukcjąMassiveMultiplayerOnline.Wątpiębyistniałarealnaszansa 

natakąrozbudowęprojektu,alechciałemwyrazićswojąwizjęimarzeniastanowiąceojego 

koncepcji. 

PiszącMaelstormzakładałemtaknaprawdę,żetworzęelementtakiejwłaśnierozproszonej 

aplikacji.Stądnaprzykładpojawiłysiępomysływczytywaniacałejkonfiguracjirozgrywki, 

18

łączniezidentyfikatoramigraczy,zplikówxml,któremogłybybyćwysyłanenaserwergry 

akcjiznadrzędnegoserweragryspołecznej.Możliwośćwyboruserwera,swobodnegologowaniasiędogryorazzasadyrozgrywki(niszczenieasteroidówiinnychgraczy)zostałydodanew 

końcowymetapieimplementacji,bypracanabrałapełnegokształtu.Byłytojednakelementy 

doktórychniepodchodziłemztakąpieczołowitościąisercemjakdopodstawowegosilnika 

gry. 

19

Rysunek2.2:MaelstormOnline. 

20

Rozdział3 

Implementacja 

WtokupracnadMaelstormOnlinemiałemmożliwośćzmierzeniasięzdużąliczbązagadnień 

związanychztworzeniemgier.Poniżejopisałemrozwiązaniaużyteprzezemniewtokuprac 

nadprojektem.Mocnywpływmiałananiespecyfikamechanikimojejgry.Pozaczystym 

opisempracimplementacyjnych,mojąintencjąbyładyskusjamożliwychsposobówpodejścia 

doomawianychproblemów.Swojeinspiracjeczerpałemztokupracnadprojektem,literatury, 

pracyzawodowejizaobserwowanychwpraktycerozwiązań. 

3.1. Projektiśrodowisko 

3.1.1.Historiaprac 

Pracenadprojektemzacząłemwroku2004,będącnaczwartymrokustudiówwramach 

przedmiotu”ProgramowaniePraktyczne”prowadzonegoprzezdr.RobertaMarona.Miałem 

wciągurokuzaprojektowaćizaimplementowaćkompletnąaplikację-ibyłotomojepierwsze 

podejściedotejkonkretnejgrysieciowej. 

Doprojektuzabrałemsięwdosyćnietypowysposób-zaczynającodstworzeniagryna 

jednegogracza,zupełnieniedzieląckodunaaplikacjęserweraiklienta.Mogłemsobienato 

pozwolićdziękizastosowaniuspecyficznegoprotokołukomunikacjiiarchitektury,aleotym 

napiszęwdalszejczęścipracy.Wciągupołowyrokuotrzymałemprostysilnikgrydlajednego 

gracza,bywciągunastępnegosemestruwykonaćprostyprotokółkomunikacjiiuruchomić 

gręnadwóchkomputerach.Grajednakbyławyraźnieniekompletna-pozasamąkonfiguracjąrozgrywki,zabrakłobardziejzaawansowanejmożliwościtworzeniagrysieciowej.Istniał 

właściwieszkieletgry,któryczekałnawypełnieniedanymiorazzamianęczęścimodułówna 

końcowąimplementację. 

PostanowiłemuczynićMaelstormOnlinemojąpracąmagisterską.Bogatszyodoświadczeniarokupracnadprojektem,zdecydowałemsięnabardzodużezmianywistniejących 

jużmechanizmach.Dziękimodularnejkonstrukcjimogłemzupełniepodmienićdużączęść 

modułówgry,wtymporuszaniesię,wykrywaniekolizjiiwyświetlaniegrafiki.Wpierwszej 

wersjiMaelstromwyświetlałemgrafikęwykorzystującbibliotekęOpenGL,jednakzdecydowałemsięnawykorzystaniewtymcelugotowejbibliotekiOgre3dicałkowiciepodmieniłem 

modułgraficzny.Tosamospotkałonapisanyzupełnienanowomodułporuszaniasię.Zmiany 

byłyzwiązaneznowymmechanizmemcofaniaruchów,koniecznymdoimplementacjimojego 

protokołukomunikacyjnego.Zmianieuległoteżsamosercesymulacjiorazwiększośćmechanizmów.Znowujednak,byumożliwićszybszestworzenieprototypugry,zrezygnowałemze 

wspieraniaarchitekturysieciowej. 

21

Wtrakciepracnadprojektemnapoczątkupiątegorokustudiówrozpocząłempracęzawodową,cobyłoprzyczynąpoważnegoopóźnienia,alejednocześniepozwoliłominakonfrontację 

własnychrozwiązańipomysłówztymi,stosowanymiwkomercyjnychprojektach. 

Wsierpniu2007roku,ponownieutworzyłemsilnikgrydlajednegogracza,bezpodziału 

naaplikacjęklientaiserwer.Polegałemjednaknauprzedniodobrzesprawdzonymsposobie 

podziałuaplikacji.Rozwójpraktycznejczęścipracymagisterskiejtrwałdolistopada. 

Rysunek3.1:Wczesnawersjaprojektu.DziałającawśrodowiskuLinuxiopartaointerfejs 

OpenGL. 

3.1.2.Środowiskoiplatforma 

MaelstormzostałnapisanywcałościwjęzykuC++.Choćnieuważałemtegozapriorytet, 

grępisałemodpoczątkuzzałożeniemprzenośnościkodupomiędzyplatformamiLinuxiWindows.Niewymagałotobynajmniejspecjalnychnakładówpracy.Jedynymiograniczeniamidlamnie,byłakoniecznośćużywaniaprzenośnychbibliotekoraznieużywaniefunkcjisystemowychbezpośredniowkodziegłównejaplikacji.GręprzezdwalatatworzyłempodLinuxem,korzystajączdarmowejwtyczkiC++doedytoraEclipseorazzestawuskryptówiprogramówautomake/autoconfdoautomatycznejkonfiguracjikompilacji.Jednocześnieniezależnie 

poznałemśrodowisko.Netiskuszonyjegoprostotą,funkcjonalnościąiwygodąużytkowania 

postanowiłemprzenieśćprojektnaplatformęWindows.ZajęłotojedendzieńijedynymproblememdlamniebyłakompilacjaużytejwgrzebibliotekiXercesCwśrodowisku.Net.To 

dobralekcja,bopokazujejakłatwopisaćprzenośnykod.Większośćgierwideonakompu- 

22

teryosobistepowstajewyłącznienaplatformęWindows,ewentualnierównieżnakonsole.Z 

punktumarketingowegotylkonatychplatformachopłacasięsprzedażgier,jednakjaksię 

okazujenakładyzwiązanezwydaniemgrynainnąplatformęmogąbyćpraktyczniepomijalne 

-przyzałożeniu,żekorzystamyzprzenośnychbibliotek.Ituwychodzipodstawowyproblem 

gierdlasystemówUnix,którymjestbrakdostępnegotylkonaplatformieWindowspakietu 

DirectX.Oferujeonbardzodużemożliwościwwyświetlaniugrafiki3D.ProducenciprzedkładająkomfortpracyzwiązanyzużywaniemDirectXnadutrzymywaniemwieloplatformowościkodu.ZamnienaszczęścietenproblemzałatwiałabibliotekaOgre3dodpowiedzialnazagrafikę,apotrafiącaobsługiwaćzarównointerfejsDirectXjakiOpenGL.Zastosowałemnietypowepodejściedorozłącznychaplikacjiklientaiserwera.Nietworzyłemosobnychklasdlaobuaplikacji,ajedyniezaznaczałemwkodzieróżnicezapomocą 

dyrektywkompilatora#if#ifdef.Obieaplikacjechodziływięcwoparciuotensamkod, 

wymaganawięcbyładwukrotnakompilacjategosamegoprojektuwróżnychkonfiguracjach. 

MojerozwiązanietegoproblemupodLinuxembyłobardzoniefunkcjonalne.Wśrodowisku 

.Netpoprostustworzyłemnowe,kompilowanedoosobnychkatalogów,konfiguracjeprojektu. 

3.1.3.Użytebiblioteki 

Mojąintencjąbyłoskupieniesięnaimplementacjisilnikamechanikigrysieciowej.Wmiarę 

możliwościimplementacjępobocznychmodułówpozostawiłemwgestiizewnętrznychbibliotek. 

•Bibliotekinarzędziowe—WpracachnadprojektemwykorzystywałembibliotekiSTL 

iBOOST(http://www.boost.org).Sąonemocnozintegrowanezkodemaplikacji.STL 

wykorzystywałemgłówniedoreprezentacjistrukturdanych-rozszerzalnychtablic,zbiorów,słownikówikolejekpriorytetowych.DodatkowowykorzystywałemzaimplementowanewSTLsortowanieiobsługęstrumieni.BibliotekaBOOSTskładasięzwielu 

niezależnychmodułów.JawykorzystywałemgłówniemodułnarzędziowyBIND 1 imodułdoobsługiwielowątkowościthread.Szczególnieprzypadłmidogustuinterfejstegomodułu.Jestonmocnoopartyoszablonyiwwiększościwypadkówopierasięnainicjalizacjiobiektówwkonstruktorze.Naprzykładmutexjestpodnoszonyizwalnianywkonstruktorzeidestruktorzecoznacznieupraszczakodaplikacjiizapobiegastandardowymbłędom. 

•Bibliotekagraficzna—Zpoczątkuplanowałemsamemustworzyćmodułwyświetlaniaaplikacjiklienta,opartyoOpenGLibibliotekęSDL[bSDL](SimpleDirectMediaLayerhttp://www.libsdl.org).Pierwszawersjamodułuwyświetlaniachoćtrójwymiarowa,reprezentowałaobiektyzapomocądwuwymiarowych,obracanychobrazów. 

NapisałemprostymodułwczytywaniamodelizformatuMD2 2 .Gdyuczyniłemprojektmojąpracąmagisterskąuznałem,żeilośćpracy,którąmusiałbymwłożyćwmodułgraficzny,jestzbytdużaicałewyświetlanieoparłemnasilnikugraficznymOgre 

3D[bOGR](http://www.ogre3d.org).Ogreokazałsiębyćpotężnąbibliotekągraficzną, 

którawbardzoprostysposóbumożliwiłamireprezentacjęobiektówgrywpostacitrójwymiarowychmodeli,dodawanieefektówspecjalnych,zarządzaniezasobamigraficznymiiwyświetlanie.ŚwiatgrywOgrejestreprezentowanywpostacidrzewa.Wszyst- 

1 ModułBINDbibliotekiBOOSTwspieraprogramowaniefunkcyjnewC++.Udostępniaszablony,które 

umożliwiajątworzeniewskaźnikówdometod,któremogąbyćtraktowanejakwskaźnikidozwykłychfunkcji. 

Dziękitemumożnaichużywaćwargumentachwywołaniafunkcjiprzyjmującychwskaźnikidofunkcji. 

2 Formatmodelu3DużytywgrzeQuake2.JesttojednazkultowychgierFPPstworzonaprzeidSoftware. 

Wydanawgrudniu1997rokuprzezActivision. 

23

kieobiektygraficznesąwięcprzypisanedojegowierzchołków.Zmieniającparametry 

wierzchołków,przesuwając,obracającalboskalującje,możemywpływaćnazachowanie 

całejhierarchiiobiektów.DowyświetlaniaiobsługiGUI(GraphicalUserInterface)użyłembibliotekiCEGUI[bGUI](CrazyEddie’sGuiSystemhttp://www.cegui.org.uk).JestonapolecanadoużytkuwprojektachopartychobibliotekęOgreibardzodobrzesięzniąintegruje.Jednocześniepozostajezupełnieniezależnaimożnajejużyć 

wpołączeniu,zpraktyczniedowolnyminnym,systememwyświetlania.Użytewniej 

podejścieirozwiązaniadotyczącetworzeniaikonfiguracjiinterfejsuużytkownikabardzodobrzepasujądoprojektugry.NiestetybibliotekaCEGUIjestwtrakcierozwoju. 

Standardoweschematygraficzneinarzędziadołączonedobibliotkiwymagająjeszcze 

rozwinięcia.Aplikacjaserweramawyłączonewyświetlaniegrafiki3D.Byzrobićdla 

niejprostyinterfejsużytkownikaużyłembibliotekipdCurses(PublicDomainCurses 

http://pdcurses.sourceforge.net),czyliwieloplatformowejwersji,znanejspodLinuxabibliotekincursesdoniskopoziomowejobsługiwyświetlaniatekstowegowkonsoli. 

•Bibliotekasieciowa—Poszukiwałemwmiaręniskopoziomowej,wieloplatformowejbibliotekisieciowej,obsługującejprotokółTCP.NajpierwwybrałembibliotekęSDLnet, 

jakożecałyprojektopierałemnabiblioteceSDL.Bibliotekamiałapewnebraki,ale 

wydawałosię,żejestwtrakcierozwoju.Projektjednakbyłjużmartwyigdyponownie 

zabrałemsięzatworzeniewarstwysieciowejużyłemtymrazembibliotekiASIO[bAIO] 

(http://asio.sourceforge.net).Nazwębibliotekimożnatłumaczyćjako”asynchronous 

inputoutput”.SamabibliotekajestbardzomocnozintegrowanazbibliotekąBOOST. 

Jestbardzowygodnawzastosowaniu,całyjejkodznajdujesięwplikachnagłówkowych, 

dlategoichdodaniejestjedynączynnościąwymaganądodołączeniajejdoprojektu. 

Opartajestoszablonyijejskalowalnaiuniwersalnaobsługakomunikacjisieciowejw 

bardzociekawysposóbprzesłanianiskopoziomowąimplementacjęobsługiprotokołów 

TCPiUDP.Dodatkowobibliotekawbardzowygodnysposóbobsługujeasynchroniczny 

odbiórdanychwspierającsięmetodamiprogramowaniafunkcyjnego.Asynchroniczny 

odczytalbozapispakietuzwiązanyjestzwywołaniempowiązanejzoperacjąfunkcji.Bardzoeleganckimrozwiązaniemtejbibliotekijestklasaioserviceprzesłaniająca 

obsługęzbiorugniazdsieciowychiułatwiającawielowątkoweprzetwarzanieichżądań. 

•BibliotekaXML—Postanowiłemwczytywaćkonfiguracjęgryzapośrednictwemplików 

XML.DoobsługitegoformatuwykorzystałembibliotekęXercesC(http://xerces.apache.org). 

TorozległaibardzofunkcjonalnabibliotekaobsługującazarównomodeleDOM 3 iSAX 4 , 

pozwalającatakżenawalidacjędokumentówXML.JawykorzystałemwyłączniefunkcjonalnośćdoobsługimodeluSAX,chociażwpraktyce,odczytującdokumentzapomocąinterfejsSAX,tworzyłemwłasnedrzeworeprezentacji. 

3 DOM–DocumentObjectModel.Obiektowy,uniwersalnyinterfejsprogramistycznydoprzeglądaniado- 

kumentówXMLwcałościwczytywanychdopamięci. 

4 SAX–SimpleAPIforXML.ModelzdarzeniowyodczytudokumentówXML. 

24

3.2. Architekturaaplikacji 

Wcałymprojekcienajważniejszymelementembyłostworzeniebardzowydajnejarchitektury 

grysieciowej.Byłtodlamnierzeczywiściepriorytetiwteelementyaplikacjiwłożyłemchyba 

najwięcejserca.Silnikgryjestmożliwieuniwersalny,mimomocnegooparciaozałożenia 

projektu. 

3.2.1.Definicjaproblemu 

PrzyprojektowaniuMaelstormOnline,przedewszystkimkierowałemsięzałożeniem,by 

umożliwićstworzeniesieciowejgryobardzowydajnejkomunikacjipomiędzyserweremiklientem.Liczbęprzesyłanychwobiestronyinformacjinależałowięcograniczyćdominimum. 

Jednocześnie,ponieważtworzyłemgręzręcznościową,szczególnieistotnabyłaodpornośćna 

opóźnieniatransmisjisieciwaplikacjiklientaiserwera. 

Kolejnąkwestiąbyłaskalowalnośćprojektu.Maelstormwchwiliobecnejjestmalutkągrą 

akcji,chciałemjednakstworzyćinfrastrukturęnaktórejmożnabybyłooprzećdużobardziej 

rozbudowanąizróżnicowanągrę.Starałemsiębyprojektbyłelastycznywrozbudowieoraz 

umożliwiałłatwązamianęużytychrozwiązańdziękidużejmodularyzacjikodu. 

3.2.2.Światgry 

Nacałokształtdynamicznegoświatagryskładająsięobiektygry 5 MapObjectigraczePlayer. 

Gracztoabstrakcyjnyobiektreprezentującyobiektdecyzyjny,sterującyobiektemgryizbierającyoniminformacje.Playermożenaaplikacjiklienckiejreprezentowaćgraczalokalnego.Możebyćgraczemzdalnym,zktórymjesteśmybezpośredniopołączeni(tasytuacjawystępujenaaplikacjiserwera),bądźjedynieabstrakcjągracza,zktórąniemożemysiębezpośredniokomunikować(innigraczenaaplikacjiklienckiej).MożetoteżbyćgraczAIsterującyobiektem.Wsilnikuzostawiłemteżfurtkę,byzaimplementowaćsterowaniewieluobiektówgryprzezpojedynczyobiektgracza,couprościtworzeniezorganizowanejgrupyprostychobiektów.Oczywiścieniekażdyobiektgrymusibyćsterowany.Prosteobiektynieanalizująceotaczającegojeśrodowiska,jakpociskiczyszczątkiasteroidyniemająprzypisanegoimgracza. 

Rysunek3.2:”Światgry” 

5 Terminuobiektgrybędęużywałwdalszejczęścipracywodniesieniudopodstawowegoelementubiorącego 

udziałwsymulacjiświatagry.Wzależnościodgry”obiektemgry”mogęnazwaćbiorącewniejudziałpostacie, 

reaktywneelementyotoczeniaczynaprzykładpojazdy. 

25

Akcjeświatagry 

KlasaWorldActionreprezentujeakcjeświatagry.Sątobardzoulotneobiekty,okrótkim 

czasieistnienia.Akcjesątrzymanewkolejcepriorytetowej,wktórejpanujeporządekzupełny,toznaczyakcjenawetwjednejdyskretnejjednostceczasurozpatrywanesąwzadanej 

kolejności.Każdaakcjapotrafisię”wykonać”.Każdeistotnezdarzeniegry,którezależyod 

interakcjipomiędzyobiektamialboreakcjigracza,aniejesttylkonaturalnymnastępstwem 

wewnętrznegostanuobiektu,jestreprezentowaneprzezakcjęświata.Poniżejopiszętenprocesdokładniej.Akcjegrysąjedynymiobiektamigrybezpośrednioprzesyłanymiprzezsieć, 

pouruchomieniupełnejkomunikacjipomiędzyklientemaserwerem. 

Ponieważoperacjetworzeniaiusuwaniaobiektówakcjipotencjalniemogłybyćwąskim 

gardłemaplikacjistworzyłemwłasnycyklicznyalokatordlanich.Ponieważsątoobiektyo 

krótkimczasieżycia,alokatormożeużyćdopasowanejdoichsposobuużyciastrategiiprzydzielaniaizwalnianiaichpamięci.Szczegółynatematkonstrukcjialokatoracyklicznegoznajdująsięwrozdziale3.8.1. 

Obiektgry 

Rysunek3.3:Diagramklasdlahierarchiireprezentującejobiektgry. 

Chciałemuniknąćtrzymanianadmiarowychinformacjiwobiektachgry,przyjednoczesnym 

zachowaniuskalowalnościprojektu.Woczywistysposóbwiązałosiętozmechanizmamiobiektowymi,główniedziedziczeniem.Takwięcobiektposiadałtylkopotrzebnemudane,przynajmniejjeżelichodzioinformacje,któremogłybyćprzesyłanewkomunikacjiklient-serwer.Tooczywiściezagrażałoskalowalności.Przypuśćmy,żebędziemymieliklasynieruchomychobiektów(którychstanopisujetylkopozycja)iporuszającychsięorazklasęobiektówpowiedzmy 

26

strzelającychinieaktywnych.Wówczasjeżelibędziemywszystkieteinformacjechcielizapisać 

wjednejklasie,posiadającejfunkcjonalnośćobiektustrzelającegoinieruchomego,naturalnymrozwiązaniembędziewielodziedziczenielubkopiowaniekodu.Wielodziedziczeniewtakichsytuacjachjestskomplikowaneiosłabiaskalowalnośćprojektu.Moimrozwiązaniembyło 

rozbicieobiektugrynazestawpołączonychobiektówopisującychkolejnejegocechy.Poniżej 

opisujęklasyobiektówściślezwiązanychzobiektemklasyMapObject. 

•Stats—Nazwaklasyjestzaszłościązdługiejhistoriiprojektu.Jesttoklasaobiektów 

odpowiedzialnychzareakcjęnazdarzeniagry.Wpraktycetooneodpowiadajązainterakcjezinnymiobiektamigry,czyliwkonsekwencjizazachowanieobiektugryod 

stronymechanikirozgrywki. 

•Controler—Klasaobiektówodpowiedzialnychzaruch.Konkretne,opartenaszablonach,podklasykontrolerapozwalająnaspamiętywanieokreślonejliczbyruchówwtył, 

cobędzieistotneprzysynchronizacjiklient-serwer.Kontrolersprawujepieczęnad 

modyfikacjąstanufizycznego-PhysicState,któryzkoleiprzechowujewszystkiepotrzebneinformacjeowykonywanymprzezobiektruchu.Samruchjestwykonywany 

przezpodklasyPhysicAction,którajestszablonem,wykonującymprzekształceniana 

obiekciezadanejklasystanu. 

•PhysicData—Klasa,którejobiektyprzechowująstałefizyczneobiektugry.Jegorozmiar,masę,czywartościtarciapotrzebnedookreśleniaparametrówruchu.Koncepcyjnieklasatamiałatworzyćnapodstawieswoichparametrówakcjeprzemieszczania 

PhysicAction,jednaktakafunkcjonalnośćniebyłapotrzebawtrakcieimplementacji 

gry,choćbyćmożebędzienależałojązaimplementować. 

•Player —Ewentualnywskaźnikdoobiektugracza,jeżelitakijestpotrzebny.Tylko 

obiektyklasyActor,będącejpodklasąMapObject,mogąbyćkontrolowaneprzezgracza. 

•Graphic—Postronieserweraklasatareprezentujeidentyfikatorzasobugraficznego. 

Waplikacjiklientataklasasłużyzawarstwękontrolerapomiędzymodułemgraficznym 

amodelemgryistanowiuchwytdoobiektugraficznego.Możeonkontrolowaćpozycję 

obiektugryorazreagowaćnazdarzeniaanimacyjnegry. 

•CollisionProxy—Obiekttejklasyjestreprezentacjąobiektugrywsystemiekolizji.Nie 

jestserializowanyijesttworzonyniezależnienakomputerzeklientaiserwera,ajego 

działaniejestzdeterminowaneprzezobiektStatsiewentualniekontrolującegogracza. 

Wtejchwilisystemkolizjidziaławaplikacjiserweraiwaplikacjiklienckiej,choć 

wgrzeniejestzaimplementowanysystemkontrolikolizjipostronieklienta.Niejest 

onpotrzebny,choćmógłbysięprzydaćdotestowaniasynchronizacji,jeżelikolizjepo 

stronieserweraiklientabysięniepokrywały,woczywistysposóbdowodziłobyto 

problemówzsynchronizacją. 

Takareprezentacjaobiektugryzwiększyłaskalowalnośćiuniwersalnośćcałegoprojektu. 

Jakoprzykładpodamzmiany,którychdokonałempopierwszejiteracjiprojektu,gdypostanowiłemuczynićgomojąpracąmagisterską.Udałomisiępodmienićsamtylkomodułfizyki,nanowy,opartyoobiektkontrolera.Tosamospotkałocałysilnikgraficznyimechanizmkolizji.Wszystkietezmianytylkowniewielkiejczęściwymagałymodyfikacjiwinnych 

modułachgry.Klasyreprezentująpewnązamkniętąfunkcjonalność,definiującąkonkretny 

aspektfunkcjonowaniaobiektu. 

Kolejnąkorzyściąwynikającązpowyższejreprezentacjijestmożliwośćdokonywaniabardzooszczędnejserializacjiobiektu.Byzapisaćobiektdobuforadanych,wystarczyumieścić 

27

wnimkolejnejegoobiektyskładowe.Każdyznich,jakożejestreprezentantemkonkretnej 

klasy,wiedokładniejakiedanebędąpotrzebne,byodtworzyćlubzaktualizowaćjegostan 

przyodczyciezbufora. 

Równieżdefiniowanieobiektówodstronydanychgryjestbardzouproszczonedziękipowyższejreprezentacji.Każdaskładowaodpowiadazapewienaspektfunkcjonowaniaobiektu. 

Definiującwięcobiektmusimyoddzielnieokreślić-wjakisposóbobiektsięporusza,jak 

reagujenazdarzeniainterakcjizinnymiobiektamiiewentualnie,ktojestodpowiedzialnyza 

jegokontrolę.Pozwalanamtona: 

•Użycieróżnychsposobówporuszaniadlaobiektówotymsamymzachowaniu.Dlaprzykładupozwalanamtonastworzenieobiektureprezentującegostandardowystatekkontrolowanyprzezgracza,anastępniedostosowaniesposobujegoporuszaniadonapędu 

konkretnegopojazdu. 

•Rozdzielenielogikiporuszaniaodjegoimplementacji.Wtejkwestiitodyskusyjnerozwiązanie,wymagająceprzemyślanegointerfejsumodułufizyki. 

•Uwzględnienieaspektówsieciowychwprojektowaniuobiektów.Fizykajestwcałości 

poprawniesymulowanawaplikacjiklienckiejijedyniezdarzeniakontrolimająwpływ 

naprzebiegsymulacji.Obiektyreakcjinazdarzeniawwiększościwypadkówwymagają 

przesyłuwiadomościwodpowiedzinazdarzeniagry.Inaczejujmując,obiektyfizyki, 

statystykczykolizjireprezentująfunkcjonalnościwymagająceróżnegotraktowaniaw 

mechanizmiesynchronizacji. 

3.2.3.Symulacja 

Serwerdokonujesymulacjigryużywającdyskretnejjednostkiczasu.Zestałączęstotliwością 

dokonujekrokusymulacjiświatagrywykonująckolejno: 

1.Ruchuwszystkichobiektówgrywzadanejkolejności. 

2.Ruchwszystkichgraczy,cowiążesięzdodaniemnowychakcjidokolejkigry. 

3.Rozstrzygnięciawszystkichkolizji,cowiążesięzdodaniemnowychakcjigrydokolejki 

priorytetowej. 

4.Wykonaniaakcji,któresązaplanowanenatenstanzegaragry. 

Wtrakcieruchuposzczególnychobiektówoddzielnierozpatrywanyjestruch(przezobiekt 

kontrolera),symulacjaupływuczasuobiektureakcji(turaobiektuStats)orazinnewewnętrznemechanizmykontroliobiektu(jakakcjewewnętrzneobiektu).Jesttoistotneponieważwiększośćobiektówjestwciągłymruchu,wdużymstopniuniezależnymodinnychpodejmowanychprzeznieakcji. 

Niemającdoświadczeniawszacowaniukosztuobsługitransmisjisieciowejiwykonywania 

głównejpętligry,przezcałyprojektzachowałemmożliwośćkonfiguracjiczęstotliwościczasu 

trwaniajednejturygry,jednaktensamczasmusiałamiećturagrynaserwerzeinakliencie. 

Istotnejest,żeserwerwłaściwiezkażdąswojąturąmusizmieścićsięwzałożonymczasie. 

Gdywczasiekolejnychturprzestaniesięmieścićwdanejjednostceczasusynchronizacja 

możezupełniezawieść.Dobrymrozwiązaniemewentualnegoproblemu,możebyćimplementacjamechanizmówzmniejszającychszczegółowośćsymulacjiświatawmomenciegdyserwerzaczynabyćprzeciążony(rzadkietestykolizji,ewentualniewstrzymanieprzetwarzanianiektórychzapytańsieciowych,uniemożliwienielogowaniasięnowychklientów,wyłączenieAI). 

28

Drugimmechanizmemktórypowinienemtuzaimplementowaćjestczasowewstrzymywanie 

symulacji,rozłączanienadmiarowychgraczyiwznawianiesymulacjiporozwiązaniuproblemu.Jako,żesątobardzouciążliwewimplementacjiitestowaniumechanizmy,ramyczasowe 

mojejpracymagisterskiejniepozwoliłyminaichimplementację. 

Klientsynchronizujesięzaplikacjąserweraiczaspłynieuniegomożliwietaksamo.Bardzoobawiałemsiętejpełnejsynchronizacjiczasu,czyniebędzietoprzyczynąewentualnejklęskitegoprotokołukomunikacyjnego.Turygrynaklienciesąpodzielonetakąsamądyskretnąjednostkączasu.Wtrakcieobrotugłównejpętligrymodułgraficznyinterpolujestan 

obiektówgrypomiędzyaktualnąturąapoprzedniąinajegopodstawiejewyświetla. 

Napowyższymodelsymulacjiszczególnywpływmiałaspecyfikamojegoprojektu.W 

ustaleniumodelusymulacjiistotnybardzobyłdeterminizm.Właściwyporządeksymulacjizapewniał,żemimoopóźnieńwprzybyciuakcji,któreniszcządeterminizmświata,przyużyciu 

kilkudodatkowychmechanizmówmożnazapewnićdostatecznąsynchronizacjęgrypomiędzy 

klientemaserwerem.Całasymulacjamusiodbywaćsięwokreślonejkolejnościidentycznej 

postronieklientaiserwera.Towłaśniewymaganiewymusiłonaprzykładopóźnienierozstrzyganiaefektówkolizjidoczasuobsługizdarzeńgry. 

Wtrakcieprojektowaniasystemunajwiększąjednakuwagępoświęciłemzagadnieniom 

sieciowymitoichaspektymiałykluczowywpływnaprocessymulacji. 

Aplikacjaklientaiserwera-różnicewsymulacji 

Symulacjagrypostronieklientaiserweraróżniąsięodsiebiewkilkukwestiach.Rozwijając 

aplikacjeserweramożemyukrywaćprzedklientempewnewłaściwościobiektówsymulacji. 

Częstonietylkoniepotrzebujeonwszystkichdanychdotyczącychtychobiektów,alemógłby 

onjewykorzystaćdonadmiarowejwiedzy,októrejniepowinienwiedziećgracz.Waktualnej 

implementacjiMaelstormnieskorzystałemztejfunkcjonalności,alepierwszawersjagry 

zawierałapostronieklientadużomniejsząliczbęinformacjioobiektachreakcji(Stats). 

Zdrugiejstronymamyaplikacjęklienta.Zajmujesięonatylkoniewielkimpodzbiorem 

obiektówgry,dlategozpunktuwidzeniawydajnościowego,mogęsobiepozwolićnadużo 

większąrozrzutność.Zdarzeniagrypostronieklientamogąwywoływaćzdarzeniaanimacji 

obiektów,któreprzekładająsięnawizualnyefekt.Mogąteżbyćgenerowanespecjalneobiekty 

gry,znajdującesięwyłączniepostronieklientaareprezentującenaprzykładefektygraficzne. 

3.2.4.Synchronizacja 

Efektem,którychcieliśmyuzyskaćjestzapewnienie,żewszyscypodłączenikliencibędądysponowaliusiebieograniczonymobrazemtegosamego,wirtualnegoświata,któregopełnareprezentacjajesttrzymanaprzezaplikacjęserwera.Byłowielezagrożeń,którebrałempoduwagęrozpoczynającprojektowaniesystemusynchronizacji.Popierwsze,widzianeprzezklientaobiektymogąwchodzićwinterakcjęzobiektamiprzezniegoniewidzianymi.Podrugie,jeżelidowiemysięozmianiestanudanegoobiektuzopóźnieniem,tookażesię,żedostajemy 

wiedzęnatematprawdopodobnienieaktualnegojużstanuobiektu,zprzedkilkujednostek 

czasu.Natejpodstawiebędziemymusielipróbowaćwywnioskowaćjakijestaktualnystan, 

bynieobciążaćserweraniepotrzebnymiprośbamioaktualizacjędanych.Kolejnymewentualnymproblememmogłybyćkwestiebezpieczeństwa,takbyjużnapoziomieprojektowym 

zapewnić,żeżadnaaplikacjapodającasięzaklientagry,niebędziewstaniewykonaćakcji 

niedostępnychzwykłymużytkownikomizaburzającychrozgrywkę. 

Zaimplementowałemfunkcjonalnośćumożliwiającąprzesyłanieobiektówgryprzezsieć. 

Jednakwysyłaniecałegostanuwewnętrznegoobiektuprzeczyłozałożeniomstworzeniawy- 

29

dajnejkomunikacjiimożliwościobsługibardzodużejliczbygraczy. 

Byzapewnićefektywnośćkomunikacjiistotnebyłozminimalizowanieprzesyłudanych,potrzebnychdozapewnieniaspójnościświatagrypostronieaplikacjiserweraiklienta.Ponieważ 

grajestsymulowanapoobustronachwdokładnietensamsposób,teoretycznieprzynajmniej, 

wpływnajejprzebiegmogłymiećwyłączniezdarzeniawywołaneakcjąużytkownika,bądź 

interakcjąobiektów. 

Synchronizacjanapodstawiezdarzeń 

Istotąkomunikacjijestwięcsynchronizacjanapoziomiekolejkipriorytetowejzdarzeń(obiektówklasyWorldAction).Zdarzeniadzieląsięmiędzyinnyminalokalneiwspółdzielonezapośrednictwemsieci.Każdezdarzeniemożedotyczyćmaksymalniekilkuobiektówgry.Współdzielonezdarzeniazostająrozesłanezserweradowszystkichklientów,którychreprezentacja 

naserwerze(obiektklasyUserPlayerposiadającyprzypisanyobiektklasyActor)”widzi” 

jedenzobiektówgry,któregodotyczyzdarzenie.Tenprostyiczytelnymechanizmzapewnia, 

żeklientjestinformowanyozdarzeniachdotyczącychwidzianegoprzezsiebiewycinkaświata 

ijednocześnieniedostajenadmiarowychinformacjioobiektachgryniebiorącychudziałuw 

symulacjipojegostronie. 

Wdrugąstronęaplikacjaklienckamożeserwerowiwysyłaćwyłączniezdarzeniaokreślająceakcjeużytkownika.Takiepodejściesamowsobiewpływanabezpieczeństwoserwera, 

ponieważklientniemożewykonaćwnimakcji,naktórąniezezwalainterfejsudostępniony 

przezklasęgracza(wszystkieakcjeużytkownikawyłącznieodwołująsiędointerfejsuklasy 

UserPlayer). 

Oczywiścienapodstawiesamychzdarzeńnigdyniezapewnimywstuprocentachsynchronizacjiświatabezużyciadodatkowychmechanizmów.Zawszenaszeakcjemogąpoprostunie 

przejść,alboprzybyćdoklientazparosekundowymopóźnieniem.Takichsytuacjimożenie 

dasięuniknąć,alemoimnadrzędnymcelembyłozapewnienie,bysamaarchitekturaaplikacji 

pomagaławporadzeniusobiezproblememspójnościświataisynchronizacji. 

Cofanieruchów 

Podstawowymproblememwsynchronizacjiświatapoobustronachsąopóźnieniawkomunikacjiorazniedokładnośćwsynchronizacjikolejkigry.Byzminimalizowaćproblemyztym 

związanerzeczywistyruchklientawykonywanyjestokreślonyczaspowciśnięciuprzezgracza 

przycisku.Czastenpowinienwystarczyćnaprzesłanieinformacjioakcjigraczanaserwer,a 

następnierozesłaniejejdoinnych,obserwującychnasgraczy.Nigdyjednakniemamypewności,żekomunikatyzostanąwysłanewwymaganymczasie.Rozwiązaniem,którezastosowałem,byporadzićsobiezzaistniałąsytuacją,jestcofanieruchów.Wpierwszejimplementacjisystemustworzyłemmodelodwrotnejkinematyki,czylikażdaakcjaporuszaniapotrafiłasięrównieżwycofywać.Niestetytorozwiązanieokazałosięproblematyczne.Wbrewpozorom,błędyzaokrągleńmiałybardzodużywpływna 

synchronizację.Ponieważwsymulacjiruchuwykorzystywałemmodelfizykinewtonowskiej 

wykorzystującejtarcie,prędkośćwtrakcieprzyśpieszaniamiałaograniczeniegórne,doktóregopowolizbiegała.Cofającruchprzyśpieszający,którybyłjużbliskogranicyzbieżności, 

zuwaginaniedomiarwartościzmiennoprzecinkowych,zupełnietraciliśmyspójnośćświata 

postronieklientaiserwera.Byłtopierwszyproblemtegorodzaju,naktórysięnatknąłem, 

alepokazywałonjużsłabąstronętejmetody.Postanowiłemwięcprzepisaćmodułfizyki 

nanowo.Tymrazempojedyncząklasęfizykizastąpiłemkontrolerem,tablicąpamiętanych 

stanówfizycznychiakcjąfizycznąokreślającąmetodęiparametryruchu.Hierarchiaklas 

30

związanazobsługąporuszaniajestprzedstawionawdiagramie3.4.Wużytymrozwiązaniu 

obiektspamiętujepewnąliczbęruchówwtył.Jeżelizażądamyodniegocofnięciasiędalej, 

grazażądaaktualizacjipozycjipostronieklienta(zarównojeżelicofaliśmyobiektjednejalbo 

drugiejaplikacji). 

Jeżeliwięcdoklientaprzychodziakcja,którapowinnabyćwykonanawjednejzpoprzednichturgry,klientcofaruchpowiązanychzniąobiektów,następniewykonujeakcje 

iponowniesymulujefizykęobiektów.Jeżeliobiektyniemogązostaćwycofanedodanego 

momentu,wówczasklientprosiserweroichaktualizację. 

Serwerotrzymujewyłącznieakcjeruchugracza.Uznałemzabezpiecznerozwiązanie,w 

którymserwerwmomenciedotarciadoniegookilkaturspóźnionejinformacjioruchugracza 

samaktualizujejegostanusiebie.Jeżelijednakinformacjabędziezbytspóźniona-wyśle 

klientowiżądanieanulowaniawykonanegoruchuiaktualizacjistanuobiektu. 

Niezawodność 

Rysunek3.4:Obsługaporuszaniasięobiektów. 

Powyższysystem,choćzapewniadosyćdobrąsynchronizację,niegwarantujeoczywiściepełnejniezawodnościsieci.Cofanieruchówiopóźnieniawobsłudzewiadomościniszcządeterminizmsymulacjiiwkonsekwencjiichefektysąbardzotrudnedoprzewidzenia.Moimcelembyłotakiezaprojektowaniesystemu,bymożliwerzadkotrzebabyłodokonywaćpełnejaktualizacjiobiektów.Wpraktycejednakrozwiązaniejestwaktualnejwersjigryabsolutniewystarczające.Grającitestującaplikacjęzgrupąznajomychniespotkałemsięzpoważniejszymiproblemamisynchronizacji.Oczywiściemusiałemstworzyćmechanizmy,którezapewniałybymożliwośćodzyskaniasynchronizacjinawypadekjejbraku.Jestgotowerozwiązanie 

31

wktórymgraczemożliwerzadkomogąotrzymywaćaktualizacjęobiektów,symulowanychod 

relatywniedługiegoczasu.Niejestonewobecnejwersjiaplikacjikonieczne.Gdybyjednak 

trzebabyłokiedyśjezastosować,troszkęlepszymrozwiązaniem,alewymagającymimplementacjibardziejskomplikowanegomechanizmu,byłobyproszenieserweroaktualizacjęobiektów 

wmomenciezauważeniarozspójnieniagry.Możnabytostwierdzaćnaprzykładanalizując 

pokrywaniesiękolizjipostronieklientaiserwera.Tociekawerozwiązaniedoimplementacji 

wkolejnychwersjachprojektu. 

Dlabranżygiertypowejest,żeniejesteśmywstanietworzyćautomatycznychtestów 

większościfunkcjonalności.Niemożemyteżwformalnysposóbudowodnićpoprawnościwielumechanizmów,zwłaszczażesamiczęstoświadomiedecydujemysięnamałeoszustwai 

przybliżenia.Jedyniewyczerpującetestyorazopiniezadowoleniagraczymogąpotwierdzić 

poprawnośćzastosowanychrozwiązań. 

3.2.5.Wnioski 

WMaelstormaplikacjaklientamaprzedgraczemukrytewyłączniedane,którychniepowinienonznać,alboktóresąmuzupełniezbędne.Światgrypojegostroniewistotnychdla 

niegokwestiachjestodzwierciedleniemświatagrynaserwerze.Odstandardowegopodejścia 

różnisiętotym,żeklientjestlustrzanymodbiciemaplikacjiserwera,zamiastpozostawać 

jedynieprogramemwizualizującym.Jestjeszczeinnepodejście,stosowanewgrachMMO, 

gdziemamyrozdziałnamechanikęwykonywanąpostronieserweraipostronieklienta.Wymagaonotytanicznejpracybyzapewnićprzynajmniejwpodstawowymzakresieuczciwądla 

wszystkichgraczyrozgrywkę.Istniejewielezaletmojegopodejściadoroliklientawgrze. 

Dlaprzykładu,wsilnikuAurora,naktórymbazowałWiedźmin,serwerbezpośredniorozkazywałobiektowiodtwarzaćdaneanimacjeorazdokonywaćustalonegoruchu.Problememw 

tymrozwiązaniujestto,żeobiektypostronieklientataknaprawdęniewiedząjakączynność 

właściwiewykonują,mająwiedzętylkootymjaktączynnośćprzedstawić.Możetomiędzy 

innymiprowadzićdowysyłaniaaplikacjiklienckiejdodatkowych,nadmiarowychinformacji. 

Stosująctopodejście,wyobraźmysobiedlaprzykładusytuacjędrwalarąbiącegodrzewow 

świeciegry.Bypoinformowaćotymaplikacjeklienckąmusimywysyłaćoddzielnieinformacjedotyczącekoniecznościwyekwipowaniadrwalawsiekierę,następnieustawićmupozycję,kierunekianimację.Terazustawiamyodpowiedniąanimacjęnaścinanymdrzewie.Noizarazpotemkolejnaseriainformacjigdydrwalścinadrzewo...Drzewoupada...Drwalzbiera 

rozrzuconedrewno...Wreszciewrzucajenataczkę,drapiesiępogłowieiidziedodomu... 

Wszystkieteczynnościdrwalamożnabyłoprzewidzieć,znająctylkosposóbwjakimbędzie 

sięzachowywał. 

Obsługaakcjiobiektupoprzezbezpośredniąkontrolęserweranakładateżbardzoduże 

ograniczenienaprogramistów.Piszącaplikacjęklientamusząoniokreślaćstanobiektuna 

podstawietakichwłasnościjak,dlaprzykładu,jegoanimacja.Pomyłkaibrakpełnejkorelacjipomiędzystanemrzeczywistymobiektu,awłasnościąnapodstawiektórejpróbujemy 

gookreślić,prowadzidobardzociężkichwwyśledzeniuinaprawiebłędów.WMaelstorm, 

ponieważklientprowadziwłaściwietakąsamąsymulacjęświata,jakadziejesięnaserwerze, 

mamynanimdostępdowiększościinformacjiifunkcjonalnościzwiązanychzmechanikągry. 

Dużotrudniejtuobłędneokreśleniestanuobiektu.Jeżelitakibłądwystąpi,oznaczaon 

brakspójnościdanychgryijesttodużobardziejjednoznaczneiklarownewodnalezieniui 

naprawie. 

Chciałemteż,bydziękitemu,żemamydoczynieniazjednymsilnikiemgrypoobu 

stronachsieci,ułatwionebyłoprogramowanienowychfunkcjonalności.Implementującnowewłasnościgrytworzylibyśmyjewpewnymoderwaniuodmechanizmówsieciowych.Nie 

32

jesttoniestetytakieproste.Choćmechanizmy,któretworzymyniemuszaodwoływaćsię 

bezpośredniodosieci,ciągletrzebamiećnauwadzesposóbwjakizostaniezapewnionaich 

synchronizacja.Architekturazapewnianammocnąbarieręabstrakcjipomiędzytworzeniem 

nowychfunkcjonalnościaobsługątransmisjidanychizdarzeńzniązwiązanych,jednakna 

każdymetapieimplementacjimusimypamiętać,żetworzymygręsieciowąikażdamodyfikacjasymulacjigrybędziemiałaswojenastępstwawprocesiekomunikacjiizapewnienia 

synchronizacji.Wpraktycedyskusyjnejestczyniełatwiejszymwtejkwestiipodejściemjest 

standardowerozwiązanie,wktórymtoserwerjestodpowiedzialnyzarealizacjemechanikia 

klientwyłączniezawyświetlanie.Wtymkonkretnymaspekcie,standardowepodejściemoże 

byćprostsze,ponieważprojektującnowąfunkcjonalnośćpostroniemechanikigry,istnieje 

mniejszaszansanato,żewpłynieonanaaspektyzwiązanezsynchronizacjąaplikacji. 

Kolejną,pozytywnącechąprojektujestskalowalność.Właściwiewkażdymjegoaspekcie 

uważam,żejestdobrzeprzystosowanydoewentualnejrozbudowyczywprowadzanianawet 

gruntownychzmian.PróbującdlaprzykładustworzyćnapodstawiesilnikaMaelstormgrę 

dlajednegogracza,wystarczytylkowyłączyćobsługęsieciipodpiąćmodułwyświetlający 

grafikędoaplikacjiserwera.Skalowalnośćarchitekturyudowodniłemczęściowopodmieniając 

wtrakciepracnadprojektemcałekluczowemodułygry(fizykę,kontrolęobiektów,obsługę 

sieciorazkilkukrotniemodułgraficzny).Uzyskałemjądziękistosowaniuwirtualnegointerfejsudlaużywanychbibliotekzewnętrznychorazwmiarętrafnemupodziałowiobiektugry 

naelementyskładowe,decydująceoróżnychaspektachrozgrywki. 

Dyskusyjnymaspektemtechnicznym,jestkompilacjazarównoaplikacjiserweraiklienta 

napodstawietegosamegokodu.Wymagatostosowaniadyrektywkompilatoradooddzieleniafragmentówdotyczącychtylkojednejzaplikacji.Zmniejszatoczytelnośćkodu,zwłaszczagłównejaplikacjigry.Mógłbymtenprocesznaczącouprościćtworzącwspólnyinterfejsgłównychklassterującychprzebiegiemgry(GameiWorld)iimplementującgooddzielniepostronieserweraiklienta.Mojerozwiązaniezastosowałembyprzyśpieszyćpracenadprojektem, 

poprawićwydajność,byuniknąćnadmiarowegokopiowaniakoduorazdlaautomatycznego 

zapewnienia,żesymulacjapoobustronachprzebiegazgodnie. 

33

3.3. Implementacjawarstwysieciowej 

Implementacjaprotokołukomunikacjibyładlamniebardzociekawymdoświadczeniem.Osobiścieporazpierwszyzmierzyłemsięzzagadnieniamiimplementacjipełnejobsługisieciwgrzekomputerowej.Decydującsięnawybórokreślonychprotokołówkomunikacyjnychitechnologii,opierałemsięnaopiniachznalezionychwartykułachnaktórenatrafiłemwinterneciei 

literaturze.Wponiższympodrozdzialechciałempodzielićsięzczytelnikiemdoświadczeniami 

iprzemyśleniamizwiązanymiztworzeniemwarstwysieciowejgryMaelstorm. 

3.3.1.Wybórprotokołukomunikacyjnego 

Wczasachmodemówotransmisji56Kb/sstandardembyło,żegryakcjiwykorzystywałydo 

komunikacjiprotokółUDP 6 .Towymuszałoimplementacjęwłasnychmechanizmówzapewnienianiezawodnościsieci.Dopasowanadomechanikigryimplementacjatychmechanizmów 

mogłabyćwydajniejszaniżstosowanawTCP 7 ,azuwaginamałąprzepustowośćinternetu 

należałojemaksymalniewykorzystać.Minęłojednaktrochęczasu.Zuwaginapopularność, 

protokółTCPjużnietylkogwarantujeniezawodnośćtransmisji.Ponieważjestnajpopularniejszymprotokołeminternetowymmabardzomocnewsparcieodstronyarchitekturysieciowej,serwerów,routerówiobsługiścianogniowych.Właściwiewewszystkichopracowaniach 

dotyczącychoprogramowaniasieciwgrachsłyszałempodobneargumentyprzemawiająceza 

wyboremprotokołuTCPzamiastUDP.Jakociekawostkępodamfakt,żemojewątpliwości 

dodatkowopomógłrozwiaćfakt,żeGuildWars,wspominanauprzedniograMMOoprawdopodobnienajwydajniejszejkomunikacjisieciowej,równieżkorzystazprotokołuTCP. 

3.3.2.Serializacja 

Możliwośćserializacjiideserializacjiobiektówbyłapodstawowąfunkcjonalnością,któraumożliwiłamistworzeniebarieryabstrakcjipomiędzyobiektowymmodelemgryaobsługąsieciopartąostrumienioweprzesyłaniepakietówdanych.WzorowałemprojektsystemunarozdzialeJasonaBeardsleya,któryznalazłemwPerełkachProgramowaniaGier[DLo3]. 

Przedstawionanadiagramie3.5klasaSerializersłużydozapisuiodczytuobiektówprzed 

wysłaniemipoodebraniuichzsieci.Przeciążamwniejmetodyput()iget(),doobsługi 

wszystkichpodstawowychtypówwykorzystywanychprzezobiektygry.Dziękitemuserializacjaobiektusprowadzałasiędowywołaniatejsamej,przeciążonejmetody,naprzesyłanych 

przezsiećatrybutach.KlasaSerializablereprezentujeobiektygry,któreostateczniechcemy 

przenosić.Ponieważdoimplementacjijednolitegointerfejsudozapisuiodczytutychobiektów 

przezobiektySerializerużywamszablonów,niemogęużyćdlanichprzeciążonychoperatorów 

put()iget().Wywołaniemetodzapisuiodczytuobiektówautomatyczniedobierzewłaściwe 

parametrydlaszablonów,więccałośćjestrównieprostawobsłudze.Obiektysąodczytywane 

przezSerializerzapomocąklasygry,implementującejinterfejsUnSerializer.Napodstawie 

identyfikatoratypu(oznaczającegorodzinęobiektówdziedziczącychniekonieczniebezpośredniopotejsamejnadklasiegry)orazklasy(identyfikującegokonkretnąklasędanegotypu) 

jesttworzonyobiektbędącyczystąinstancjądanejklasy.Następnieobiektwczytujeswoje 

6 UserDatagramProtocol.Wydajnyprotokółwarstwytransportuwysyłającywiadomościwformiedatagramów.Niegwarantujetego,żewiadomościzostanąodczytanewkolejnościwysłania,mogąteżzostać 

odczytanepodwójnielubwogóleniedotrzećdocelu. 

7 TransmissionControlProtocol.Protokółwarstwytransportowejwysyłającydanewpostacistrumieniowej. 

Nailetomożliwezapewniadostarczeniedanychorazgwarantuje,żezostanąoneodczytanewkolejności 

wysłania. 

34

Rysunek3.5:Interfejsklasodpowiedzialnychzarealizacjęserializacjiobiektówgry. 

atrybutyzbuforadanych,reprezentowanegoprzezobiektklasySerializer.Jestmożliweobsługiwaniepostronieaplikacjiserweraiklientaodczytuwyłącznietychklasobiektów,któredanaaplikacjarzeczywiściemożeodebraćzsieci,cododatkowozwiększabezpieczeństwokomunikacji(ograniczamyjakieklasyobiektówmogązostaćwczytanezapośrednictwemsieci 

waplikacjiserweralubklienta). 

Powyższymechanizmserializacjimaprostyiskąpyinterfejs.Zajegopośrednictwemmogę 

przenosićzłożoneobiektypomiędzyaplikacjąserweraikliencką.Mechanizmwykorzystywałemrównieżwjeden,dyskusyjnysposób.Ponieważzwyklewiempoktórejstronieobiektjest 

zapisywanyapoktórejodczytywany,kilkakrotniepozwoliłemsobiekorzystaćztejwiedzy. 

Częśćobiektówserweraprzyzapisiedobuforaniezapisujeczęścidanych,którychniechcemyudostępnićklientowi.Torozwiązanieograniczatroszkęskalowalnośćprojektu,alejego 

ewentualnapodmiananaogólniejszejestprosta. 

Systemserializacjisprawdziłsięwpraktyceznakomicie.Działabezzarzutu,jestbardzo 

prostywrozwojuorazwyszukiwaniubłędów.Byłobecnywpierwszejiteracjiprojektui 

właściwieodtegoczasuniewielesięzmienił.Funkcjezapisuiodczytutworzysiębardzo 

szybkoidziękiprostociewstosowaniubłędywnichzdarzająsięrzadko. 

35

3.3.3.Obsługapołączeń 

DecydującsięnatworzeniuwarstwyobsługisiecimusiałemzdecydowaćsięcodosposobuobsługipołączeńTCP.Ponieważgramożewzałożeniuobsługiwaćpowyżejsetkipołączeń,nie 

mogłemsobiepozwolićnaichsynchronicznąobsługę-cowymuszatworzenieosobnegowątku 

doobsługikażdegopołączenia.Zkoleibałemsięjakporadzisobiepojedynczyzbiórgniazdz 

obsługąrzeczywiściedużejliczbypołączeń.ZnalazłemartykułwPerełkachProgramowania 

Gier[AKi4]dotycząceobsługiserwerawgrachdlabardzodużejliczbygraczy.Autorsugerowałwnim,żegdymusimywgrzeutrzymywaćrzeczywiściedużeliczbypołączeń,najlepszym 

rozwiązaniemjestasynchroniczneprzetwarzanieżądańprzezkilkaniezależnychwątków.Dla 

liczbypięciusetdotysiącapołączeńmówiłtuopięciuwątkach.Niemającdoświadczeniaw 

tejkwestiioczywiściezastosowałemdokładnietorozwiązanie.Połączeniasątrzymaneprzez 

obiektyklasyConnectionHandler,będąceabstrakcjądlaprocesuobsługującegoichżądania. 

Gdytworzymynowepołączeniesprawdzamyczywszystkieistniejąceprocesyobsługująjuż 

pewnąminimalnąliczbępołączeń.Jeżelitakjestorazliczbaprocesówjestmniejszaodmaksymalnieustalonej,wówczastworzonyjestnowyobiektConnectionHandler,uruchamiający 

nowyprocesprzetwarzaniapołączeń.Winnymprzypadkunowepołączeniadystrybuowane 

sąpomiędzyprocesamitakbyzrównoważyćichrozkład. 

36

3.4. Dynamicznewykrywaniekolizji 

Potencjalnie,wąskimgardłemmechanikigrymożebyćsystemuporuszaniaiwykrywania 

kolizjiobiektów.Zwykletoruchjestnajczęściejwykonywanąprzezobiektyakcjąizwykle 

związanyonbyćmusiwłaśniezwykrywaniemkolizji.WprojekcieMaelstormmogłemsię 

ograniczyćwyłączniedowykrywaniemkolizjipomiędzyobiektamigryoraztestowaniemwi- 

docznościobiektówgryprzezgraczy.Zwyklejednaknawykrywaniekolizjiskładasięcały 

zbiórmechanizmów,ściślezależnychodświatagry.Implementacjatychmodułówmakluczo- 

weznaczeniedlaaspektówwydajnościowychmechanikigry. 

3.4.1.Kolizjeobiektów 

Wwypadkutestówkolizjipomiędzyobiektami,naszymzadaniemjeststwierdzenie,żew 

danympunkcielubnadanejliniiobiektniekolidujezinnymi.Zwyklesamtestkolizjidwóch 

obiektówjestwmiaręprostywimplementacji,ponieważobiektyreprezentowaćmożemyw 

przybliżonysposób.Postaciemogąbyćwtrójwymiarowymświeciewalcamiopodstawiekoła. 

Jeślipotrzebujemydokładnychkolizji,dowolnychtrójwymiarowychobiektów,zbudowanychz 

siatkitrójkątów,równieżdlaprzyśpieszeniapodstawowegotestu,przybliżamyjenajpierwza 

pomocąprostej,symetrycznejbryły,takiejjaksześcianalbokula.Jeślibryłyobiektówbędą 

kolidowaćzesobą,szczegółowąkolizjęsprawdzamyszukającprzecięćtrójkątówzktórych 

zbudowanesąobiekty. 

Wtejczęścichciałemskupićsięraczejnasposobachograniczenialiczbyobiektówtesto- 

wych.Jeżelidlakażdegoobiektubędziemyprzeprowadzaćtestkolizjizewszystkimipozosta- 

łymi,czassamegosprawdzaniakolizjiwturzegrybędziezależnyconajmniejkwadratowood 

liczbyobiektów. 

Dotestówkolizjiobiektówgrymożnapodejśćdwojako,wzależnościodtegojakiewyma- 

ganiafunkcjonalnenakładamynasilniknaszejgry.Możemyliczyćjewszystkieraznaturęgry 

wkonkretnymmiejscupętli.Toutrudnia(alenieuniemożliwia)zintegrowaniesystemukolizji 

zsystememsztucznejinteligencjiiwykonywanychakcjiobiektów,aleupraszczawymuszenie 

determinizmuwnaszejsymulacji 8 .Obiektygrymogąteżsprawdzaćkolizjewewłasnymza- 

kresie,cojestdobrymrozwiązaniem,gdypoprostuniechcemywpuścićobiektówwswoją 

przestrzeńosobistąiniechcemybybyłysprawdzanekolizjedlaobiektówpozostającychw 

spoczynku. 

WWiedźminiezastosowanezostałotodrugiepodejście.Obiektyporuszającsięsprawdza- 

łyczyniktniestoiimnadrodze.Ewentualnakolizjapowodowałapróbęominięciaprzeszkody 

bądźzatrzymaniesię.WMaelstormpołączyłemobarozwiązania.Obiektywykrywająkolizje 

wswojejturzeruchu.Wykrytakolizjajestodkładanadotablicykolizji,oileniespowodował 

jejwcześniejobiektzktórymkolidujemy.Powtarzaniesiękolizjijestsprawdzanenapodstawie 

tablicymieszającej,biorącejpoduwagęwartościfunkcjimieszającejobuobiektóworazturę 

gry(czylitablicaautomatycznieresetujesięcoturęgry).Wszystkiekolizjerozpatrywanesą 

kolejnowokreślonejczęściturygry. 

Sortowanieobiektów 

Prostymrozwiązaniemoograniczonejskutecznościjesttrzymanieobiektówgrynaposorto- 

wanejwzględemkonkretnejwspółrzędnejliście.TorozwiązaniezostałoużytewWiedźminie, 

8 Determinizmwgrzejestistotnąwłasnością,jeżelizdecydujemysięjązapewnićistotnejestuwzględnienie 

tegonaetapieprojektowaniapodstawowegosilnikagry.Determinizmmożebyćistotnywsystemachsymulacji 

fizyki,grachsieciowychtakichjakMaelstorm,wgrachumożliwiającychzapisywanieprzebiegurozgrywki,czy 

cofanieczasugryalboinnemodyfikacjejegoprzebiegu. 

37

gdzieliczbaobiektówgryzwyklenieprzekraczałastujednocześniesięporuszających.Oczywistesąograniczeniategorozwiązania.Najczęściejjakolistyużywamyposortowanejtablicy, 

przezcododawanieiusuwanieelementówtablicyodbywasięwczasieliniowym.Wzamianza 

toinneoperacjezyskująnawydajności(wyszukiwanieelementuiprzeglądanieposortowanej 

tablicydziałaszybciejod,dlaprzykładu,implementacjizbiorówang.setzbibliotekiSTL). 

Aktualizacjapołożeniawtablicyodbywasięwoczekiwanymczasielogarytmicznym,choć 

niemożnawykluczyć,żewpesymistycznymprzypadkuczastenbędzieliniowy.Torozwiązanieprzedstawiłemzuwaginajegoprostotę,niewielkikosztpamięciowyiwwypadkuwielu 

projektów,wystarczającąskalęspodziewanejoptymalizacji. 

Zastosowaniesiatki 

Byzminimalizowaćzbiór,branychpoduwagęprzytestowaniukolizjiobiektów,możemyzastosowaćpodziałświatagrynasiatkę(dlauproszczeniaprzyjmijmy,żejestonadwuwymiarowa)kwadratowych,jednakowychpól.Wkażdejkomórcesiatkiznajdujesięlistaobiektów 

mającawniejswójśrodek.Rozmiarkomóreksiatkijesttakdobranydorozmiaruobiektów 

gry,żetestkolizjizadanegoobiektu,wymagaprzejściawyłącznielistznajdującychsięwjego 

komórceorazkomórkachprzyległych. 

Tobardzoskutecznerozwiązanie,problememmożebyćwnimtylkoreprezentacjawiększychobiektów.Możnatozrobić,zmuszającjebyzajmowałyonewiększąliczbękratek,coostateczniemożespowolnićzarównoaktualizacjęjakiwyszukiwaniewidoczności.Jesttodobrerozwiązaniedlagier,wktórychobiektówwiększychodstandardowegobędziezzałożenia 

bardzomało. 

Drugimsposobemnaobsługęobiektówróżnychrozmiarówjestzastosowanieróżnychpoziomówszczegółowościsiatkikolizji.Najlepiejjestprzyjąć,żekażdypoziomszczegółowości 

madwukrotniedłuższąkrawędźpodziałki 9 .Wówczasobiektjestzaznaczanynasiatceodpowiadającejjegowielkościiwszystkichmniejszczegółowych(zwiększąpodziałką).Obiekttestująckolizjęsprawdzająnaswoimpoziomieszczegółowości,poczymtestujejąnawyższychpoziomach,zobiektamiorozmiarachimodpowiadających. 

TegorozwiązaniaużyłemprzyimplementacjisystemukolizjiwgrzeMaelstorm.Istnieje 

wniejzadanaliczbapoziomówszczegółowościsiatki.Obiektporuszającsięsprawdzakolizjezobiektamiwystępującymiwswoimiprzyległychpolachsiatki.Rozwiązaniewydajesiędziałaćbardzoskutecznie.Podobnegomechanizmuużyłemdosprawdzaniawidoczności.Implementacjasiatkiwidocznościróżnisięmałymiszczegółami.Wposzczególnychkomórkach 

siatkitrzymamobiektywinnejstrukturzedanychniżwsiatcekolizji(wzbiorzezamiast 

wtablicy).Drugąróżnicąimplementacjisystemuwidoczności,jestfunkcjonalność,wktórej 

obiektyniezmieniająswojegopołożeniawsiatce,jeżelitylkominimalnieprzechodząnainną 

komórkę(zuwaginadłuższyczasdodawaniaiusuwaniaelementówzwypełnionychobiektamizbiorów).Minusemtegorozwiązaniajestdużezapotrzebowanienapamięć.Szczególnie 

tyczysiętosytuacji,gdypróbujemyzastosowaćmałąpodziałkęsiatki,dladużegoświata 

gry.Węzełsiatkizwykleniekonieczniejestprostąstrukturąizprzyczynwydajnościowych 

powinienmiećzaalokowanąpewnąpamięćnaewentualneobiektywnimprzebywające. 

Rekurencyjnegrupowaniewymiarami 

Wrócimyterazjeszczenachwilędopomysłusortowaniaobiektów.Opierasięnanimalgorytm 

rekurencyjnegogrupowaniawymiarami(RDCRecursiveDimensionalClustering).Dlakaż- 

9 Ogólniewodniesieniudosiatkikolizjiistotnejestbyjejkrawędźbyłapotęgądwójki.Dziękitemuwyznaczeniepolasiatkidladanejpozycjisprowadzasiędoprostychoperacjiprzesunięciabitowego. 

38

degowymiaruwjakimrozpatrujemyzderzeniabędziemydynamicznietworzyliposortowaną 

tablicę.Tablicabędziezawierałaminimalneimaksymalnewspółrzędnenajakichrozpostarte 

sąrozpatrywaneobiektygry.Konstrukcjatejtablicyodbywasięwczasieliniowym,sortowaniewczasieO(nlog(n)).Poutworzeniuprzeglądamytablicępróbującwyszczególnićwniejgrupy-czylizbioryobiektówktórychpoczątkiikońcenasiebienachodzą.Tenkrokmożebyćwykonanywczasieliniowym.Następniedlakażdejgrupyrekurencyjniewykonywany 

jestkrokRDC,sortującyobiektytymrazemwedługinnejwspółrzędnej.Algorytmzostaje 

przerwany,jeżelirozpatrywanagrupajestjednoelementowa,bądźniezostałapodzielonana 

mniejszewzględemżadnejzewspółrzędnych. 

AlgorytmRDC(RecursiveDimensionalClustering)dlaprzestrzenidwuwymiarowejdziała 

wnastępującysposób: 

1.Nawejściuzbiórwszystkichobiektówtraktujemyjakogrupę. 

2.Tworzymylistęgranicobiektówwedługaktualnierozpatrywanejwspółrzędnej. 

3.Sortujemylistęgranic. 

4.Napodstawielistygranicdzielimyrozpatrywanągrupęnamniejsze. 

5.Dlakażdejodnalezionejgrupyrekurencyjniezałączamyalgorytmanalizująckolejną 

współrzędną.Jeżeliniedokonaliśmynowegopodziału,analizujemywedługkolejnej 

współrzędnejgrupęwejściową.Jeżelinieudałonamsięrozpatrywanejgrupypodzielić 

wedługżadnej,kolejnorozpatrywanejwspółrzędnejkończymydziałaniealgorytmu. 

Oczekiwanyczasdziałaniaalgorytmu,dlanobiektów,jestzbliżonydoO(nlog(n))–jeżeli 

założymy,żemożemyograniczyćzgóryśredniągłębokośćnajakąalgorytmsięzagłębia.W 

pesymistycznymprzypadkumożewzrosnąćdoO(n 2 log(n)),jednakdotyczytosytuacji,które 

niepowinnymiećmiejscawrzeczywistychzastosowaniach. 

AlgorytmRDCradzisobiedobrzewsytuacjach,wktórychobiektysąwmiaręrównomiernierozrzuconepoświeciegry.Możnagoteżużyćwodniesieniudoobiektówstatycznych,by 

grupowaćje,comożebyćnastępnieużytewtworzeniustrukturwspomagającychsprawdzanie 

znimikolizji.Algorytmźleradzisobiewmomenciegdywszystkieobiektykolidujązesobą 

wzajemnie.Wówczasrekurencjamożeschodzićbardzogłębokoaalgorytmniejestwstanie 

rozdzielićobiektównagrupy.Niemiałempraktycznejstycznościzpowyższymalgorytmema 

najegodokładneopracowanienatknąłemsięwPerełkachProgramowaniaGier[DLo2] 10 .W 

internecieznalazłembardzoróżnorodneopinienajegotemat(odwmiarępozytywnych,do 

bardzonegatywnych),dlategowspominamonimgłówniebypokazaćalternatywęwpodejściu 

doproblemuwyszukiwaniakolizji.Myślę,żejestdobrymrozwiązaniemdlaprojektów,wktórychobiektysąwciągłymruchuakolizjewykrywamyraznaturęwokreślonejprocedurze. 

Przykłademdobrymdowykorzystaniategopodejściamożebyćsilnikfizyczny 11 . 

3.4.2.Kolizjezgeometriąświata 

Istotnymelementemomawianegomodułujestfunkcjonalnośćtestowaniakolizjiobiektówz 

geometriąświata.SzczęśliwiewMaelstormuniknąłemimplementacjitegomechanizmu,jednakmiałemznimsporostycznościwtrakciepracnadWiedźminem.Trzebapamiętać,że 

10 

Inne opracowanie algorytmu można znaleźć na stronie: http://lab.polygonal.de/articles/recursivedimensional-clustering 

11 

Oboksilnikówgraficznych,fizykajestmodułemgrynajczęściejimportowanymodzewnętrznychdystrybutorów.NarynkukomercyjnymnajbardziejznanymisąsilnikiHavokPhysicsorazPhysXfirmyAGEIA. 

39

geometriaświatagryjesttworzonazwyklezmyśląowyświetlaniujejiwpraktycemożebyć 

bardzoskomplikowana.Światgryskładasięzwyklezolbrzymiejliczbyopisującychgotrójkątów,któretylkowniewielkimstopniusądlaprowadzonegoprzezgraczabohaterapodłogąalbościaną.Testowaniekolizjiztakskomplikowanągeometriąmożebyćstanowczozbytkosztowne.Dlategowgrachpopularniewprowadzasiędodatkowągeometrię,generowanąbądź 

tworzonąprzezgrafików.Najczęściejmaonapostaćsiatkinawigacyjnej.Jesttogeometria 

złożonaztrójkątów,którawyznaczapowierzchniępoktórejmogąporuszaćsięobiektygry. 

Możejąwyznaczaćdokładnie,takżepozycjaznajdującychsięnaniejobiektówjestustalanawyłącznienapodstawiegeometriinawigacyjnej.Wysokośćmożebyćteżpobieranazz 

bardziejszczegółowejgeometriiświata.Torozwiązaniejestpreferowane,ponieważpozwala 

nauproszczeniegeometriinawigacyjnej.Wkonsekwencjiprowadzitodoprzyśpieszeniapozostałychoperacjiwykonywanychnaniejorazułatwiajejwyznaczanieprzezprojektantów 

gry. 

Dlakażdegotrójkątamusimymócpodaćwczasieliniowymtrójkątyznimsąsiadujące. 

Wówczas,dziękizastosowaniugeometriinawigacyjnejkolizjepostacizkrawędziamiświata 

możnaliczyć,biorąctrójkątsiatkinawigacyjnej,naktórymznajdujesiępostać.Następnie 

przeszukujesięwszerztrójkątysiatkinawigacyjnejleżącepodobrysempostaci.Jeżelinatrafimyna”dziurę”(braksąsiada),bądźtrójkątpoktórymniepowinniśmychodzić,oznaczato,że 

wychodzimypozaświat.KosztczasowytakiegorozwiązaniajestrzęduO(log(n)+mlog(m)), 

gdzientoliczbatrójkątówsiatkinawigacyjnej(kosztwyszukaniastartowegotrójkąta),amto 

liczbatrójkątówleżącychpodtestowanymobszarem(kosztprzeglądaniawszerzalgorytmem 

Dijkstry). 

Zastosowaniegeometriinawigacyjnejtooczywiściepewnadodatkowapraca,którąmusiwykonaćdziałprzygotowującylokacje,naktórychtoczysięgra.Jednakdziękiniejpoza 

przyśpieszeniemwykrywaniakolizji,uzyskujemymożliwośćkontrolowaniaobszarupojakim 

zezwalamyporuszaćsięgraczowiorazunikamyproblemówzwiązanychzniewłaściwąinterpretacjągeometriiświataprzezsilnikgry. 

WWiedźminiesiatkanawigacyjnabyłatworzonaprzezgrafikówiokreślałaobszarpo 

którymmożnasięporuszać.Wysokośćpostaciwdanympunkciebranabyłajednakzgeometriikolizyjnejświata,ajejodległośćodgeometriinawigacyjnejwpioniemogławynosićco 

najwyżejpółmetra(wmetryceświatagry). 

3.4.3.Wnioski 

Nieomówiłembynajmniejwszystkichaspektówzwiązanychzwykrywaniemkolizji.Starałemsięprzybliżyćparępodstawowych,popularniestosowanychrozwiązań.Implementacja 

sprawnego,dostosowanegodoświatagryiwymagańprojektu,systemukolizjijestbardzo 

istotna.Gdyużyjemynarzędziprofilujących,pozwalającychśledzićczaswykonaniakonkretnychfunkcjiwczasiedziałaniagry,zobaczymyżewydajnośćmodułówwyszukiwaniaścieżek 

iporuszaniajestzwykleściślezależnaodsystemukolizjizktóregokorzystają.Systemkolizji 

jestnierozerwalniepowiązanyzreprezentacjąświatagrywkodzie.Dlategotworzącambitny 

projektistotnejestbyoprzećgonamocnychpodstawach,awichskładwchodziwłaśnie 

odpowiedniowydajnysystemwykrywaniakolizji. 

40

3.5. Wyświetlaniegrafiki 

ModułwyświetlaniagrafikiMaelstormOnlineniebyłdlamnienajistotniejszymelementem 

gry.Niesiliłemsięnaoptymalnewykorzystaniemocyobliczeniowejprocesoraorazdostępnej 

pamięcioperacyjnej.Piszącgostarałemsiębybyłmożliwieskalowalnyiniezależnyodpozostałejczęścikodu.Starałemsięuczynićinterfejspomiędzymechanikągryajejwyświetlaniem 

możliwieprostyijednoznaczny,jednocześnieumożliwiającjegopodmianęorazrozbudowę. 

Rysunek3.6:Interfejspomiędzygrąazewnętrznymibibliotekami. 

3.5.1.Interfejsmoduługraficznego 

Założeniem,któregoprzestrzegałemwimplementacjiMaelstormbyłomaksymalneograniczenieinterfejsuzewnętrznychbibliotekzkodemaplikacji.Wyjątekstanowiłybibliotekinarzędziowe(BOOSTiSTL)ibibliotekasieciowaasio.Importującpozostałebibliotekitworzyłem 

klasęgrymającąmaksymalnierozbudowanąuniwersalnąfunkcjonalnośćipozostawiającą 

wirtualnyinterfejs,którypowinienbyćzdefiniowanyprzezkonkretnąbibliotekę.Wkodzie 

gryodnosiłemsięwyłączniedoabstrakcyjnejklasyprzesłaniającejfunkcjonalnośćopartą 

ozewnętrznebiblioteki.Diagramklas3.6przedstawiametodologięimplementacjibibliotek 

którązastosowałemwkodzieaplikacji. 

Taarchitekturasprawdziłasięjużwielokrotnie.Proporcjonalniebardzomałymnakładem 

41

siłpodmieniałemjużcałymodułwyświetlania.Najpierwpierwsząimplementacjęsystemu 

wyświetlanianamodułOgre3d.Późniejzprzyczynwydajnościowychzredukowałemwyświetlaniestanugrynaserwerze,dotekstowegowyświetlaniawkonsolizapomocąbiblioteki 

pdCurses. 

3.5.2.Animacja 

SystemanimacjiwMaelstormpowstałwkońcowymokresiepracnadprojektem.Projektując 

gomiałemnauwadzebłędyleżąceupodstawanalogicznegosystemuwgrzeWiedźmin.Był 

onpozostałościązAurory,staregojużsilnikaktórystanowiłbazęgry.CałymechanizmwyświetlaniawWiedźminiezostałnapisanynanowo,leczpewneelementystarejarchitektury 

pozostały.Jednymznichbyłwłaśniesystemanimacji.AurorabyłasilnikiemNeverwinter 

Nights,chybapierwszejwpełnitrójwymiarowejgryRPG.Byłatograoferującamożliwość 

grywieloosobowej,takwięcwkodziemieliśmyaplikacjęnapisanąwarchitekturzeklientai 

serwera.TenrozdziałzostałzachowanywWiedźminie.Zpoczątku,byumożliwićewentualne 

stworzeniegrywieloosobowej.Późniejgdyprojekturósł,byłozbytpóźnonamodyfikacjetak 

fundamentalnychelementówsilnika.Dziękitemu,mimożeniepracowałemnadWiedźminem 

odpoczątku,miałemstycznośćzrozwiązaniamikwestiigrydlawielugraczyużytymiwNeverwinterNights.Systemanimacjibyłprojektowanyzuwzględnieniemkoniecznościobsługi 

wydajnejkomunikacjisieciowej. 

Chciałemwięcuniknąćbłędówprojektowychsystemuanimacji,zktórymimiałemstycznośćwpracyzawodowej.Pierwszymznichbyłoustawianieanimacjiobiektówklientaprzez 

serwer.Tąkwestięomówiłemdokładniejwsekcji3.2.Kolejnymproblememwystępującym 

wWiedźminiebyłasamareprezentacjaanimacji.Zdarzenieanimacjiwysyłanesieciąmiałopostaćliczbycałkowitej,identyfikującejkonkretnąanimację.Niestetyniestworzyliśmy, 

żadnegospójnegosystemupobieraniadodatkowychdanychdotyczącychanimacji,zadanej 

wpostaciidentyfikatora.Toprowadziłodotego,żesprawdzeniedodatkowychinformacjio 

animacji,określonejliczbącałkowitą,implikujewywołaniejednejzfunkcjiwypełnionychalbo 

gigantycznymblokiemswitchalbociągiemniepotrzebnychporównań.Ponieważpewneanimacjemusiałybyćtraktowanewsposóbwyjątkowy,funkcjeustawiającejepostronieklienta 

byłyniesłychanieskomplikowane,wypełnionepotężnąliczbąporównań,częstopoczęścijuż 

niepotrzebnych.Wsystemieniesposóbbyłoodróżnićmartwy,nieużywanykododrzeczywistychrozwiązańrzadkowystępującychbłędów.Jakiekolwiekzmianywogólnymsystemie 

animacjibyłyniemożliwe,ponieważniktniepanowałnadjegokodem.Każdamodyfikacja 

groziłazawszepoważnymibłędami,mogącymiwystąpićwzupełniewyjątkowychsytuacjach. 

Systemanimacjibyłtunagranicyskalowalności,ewentualnepróbyjegonawetnajmniejszej 

rozbudowybyłybardzotrudnedoprzeprowadzenia. 

Wymaganiasystemuanimacji 

Projektującmójsystemchciałemwięcbybyłon: 

•Jaknajbardziejczytelnyiskalowalny. 

•Chciałembyodstronymechanikigryjegoobsługabyławyjątkowoprostaijednoznaczna. 

•Jednocześnieobciążałemtensystemdużąodpowiedzialnościąodnoszącąsiędograficznejstronymojejgry.Interfejsanimacjimiałumożliwićuzyskaniewjednolitysposób 

bardzoróżnorodnychefektówgraficznych.Odstandardowejobsługianimacjimodeli, 

42

przezprzezroczystośćdowolnychobiektówgraficznychażdowyświetlaniaefektówcząsteczkowychwrodzajueksplozji. 

•Chciałemteż,bynaobiekciemogłydziałaćnarazróżneanimacje,ajednocześnieniektóreznichpowinnysięwykluczać. 

Realizacja 

Rysunek3.7:DiagramklasprzedstawiającysystemanimacjiMaelstorm. 

WMaelstormOnlineanimacjesąidentyfikowanezapomocąliczbycałkowitej.Diagramna 

ilustracji3.7przedstawiapodstawowąhierarchięklasodpowiedzialnązaimplementacjęsystemuanimacji.ObiektyAnimationsązgrupowanewtablicyanimacjiaidentyfikatoranimacji 

jestwniejindeksem.Potrafiąonetworzyćkonkretnąreprezentacjęanimacji,działającejna 

obiekcie.Przechowująteżogólnedanedotyczącereprezentowanegotypuanimacji.ObiektyRunningAnimationnatomiastsąinstancjamianimacjinaobiekciegraficznym.Potrafią 

naniegodowolniewpływać,nawettworzącinneobiektygraficzne.Dlaprzykładu,animacja 

efektucząsteczkowegotworzyobiektefektuwmiejscuwktórymznajdujesięposiadającyją 

obiektgraficzny. 

Korzyścijakiepłynązpowyższejarchitektury: 

•Dziękiobiektowejstrukturzeizastosowaniudziedziczeniamożnabardzołatwoobsłużyć 

wspecjalnysposóbnietypoweanimacje,wymagającespecjalnegotraktowania. 

•Byuprościćinterfejsmodułuanimacjiobiektygrywpływająnaanimacjęinformując 

swojąreprezentacjęgraficznąozdarzeniuanimacyjnym.Możebyćonoobsłużoneprzez 

43

odpowiadającymuobiektgraficzny.Tozawężainterfejsanimacjidowywołaniajednej 

tylkofunkcji. 

•Animacjemogąwywoływaćsięnadowolnychobiektachgraficznych.Dziękizastosowaniuszablonówmogąteżkorzystaćzichspecyficznej,niewirtualnejfunkcjonalności. 

•Naobiekciemożenarazdziałaćwieleanimacji.Jednocześnieanimacjamożeposiadać 

referencjędozbioruanimacjiwykluczanych,którebędąwówczaszdejmowanewrazz 

jejaplikacjądoobiektu. 

44

3.6. Pathfinding-wyszukiwanieścieżek 

Wyszukiwanieścieżektoistotnymechanizm,zktórymmusząuporaćsięprogramiściwiększościgier.WMaelstormOnlineświatemgryjestotwartaprzestrzeńkosmiczna,wktórejbrakwiększychprzeszkód”terenowych”,awzajemneomijaniesięobiektówopartejestnaprostychmechanizmach,októrychnapiszęwdalszejczęścipracy.Wtensposóbominęłamnie 

koniecznośćimplementacjimodułuwyszukiwaniaścieżek,będącaczęstobardzopracochłonna 

ikosztowna. 

JednakwprojekcieWiedźmin[TW07]osobiścieodpowiedzialnybyłemszczególniezasystemwyszukiwaniaścieżek.Wtymrozdzialechciałemwięcpodzielićsięwiedząiprzemyśleniamizdobytymiwtrakciepracyzawodowejorazwtokuwłasnychposzukiwańdotyczących 

całościowegorozwiązaniaomawianegoproblemu. 

3.6.1.Definicjaproblemu 

Stajemyprzedproblememwyszukaniaścieżkidladanegoobiektugry,pomiędzydwomapunktamiwprzestrzeni,lubstwierdzenia,żeścieżkajestniemożliwadouzyskania.Trzebatujednak 

pamiętać,żeświatygryróżniąsiępomiędzysobą,wdodatkucechujejezwykledynamika.W 

dodatkuzupełnieinnymproblememwpraktycemożeokazaćsięominięciestojącegonamna 

drodzestołu,ainnym,przeprowadzeniepostacipomiędzydwomapunktaminaprzeciwległych 

krańcachwirtualnejlokacji.Inaczejujmującsystemwyszukiwaniaścieżekmożeskładaćsięz 

kilkuróżnychmechanizmów,skutecznychwróżnychsytuacjach,przyróżnychdługościachi 

stopniachkomplikacjiścieżkiwynikowej. 

Częstozuwaginazłożonośćświatagrysystemwyszukiwaniaścieżekmusibyćmocnozintegrowanyzsystememsztucznejinteligencjiikonfigurowalnyzapomocąnarzędziiskryptów 

gry.Oewentualnejpotrzebiekonfiguracjisystemunapiszęwtrakcierozważańnadaspektami 

ocenyrozwiązań,tujużjednakchciałbymzaznaczyć,żewyszukiwanieścieżekniejestwyłącznieproblememalgorytmicznym,aleczęstozwiązanejestzdodatkowąorganizacjąprocesu 

pracynadlokacjamiświatagryiimplementacjąfabuły. 

Aspektyocenyrozwiązania-realizm 

Podstawowymkryterium,wjakimsystemwyszukiwaniaścieżekoceniaćbędziekońcowyużytkownikjestintuicyjnośćznalezionychprzezniegorozwiązań.Gdygraczgdzieś”kliknie”,to 

liczy,żepostaćpójdziedotegomiejscawtensamsposóbjakonsambytozrobił.Będzietood 

programistywymagałowzięciapoduwagęwieluróżnychczynników.Popierwsześcieżkamusi 

byćintuicyjniewygładzonaipozbawionanagłych,nienaturalnychzwrotów.Owygładzaniu 

ścieżeknapiszęponiżejkilkasłów.Kolejnymistotnymelementembędzienapewnoukształtowaniaterenu,czynawierzchni.WWiedźminienaprzykładproblemem,którywyszedłw 

trakcieprac,byławoda.Wsilnikubyłaonawyłącznieefektemgraficznym,niemającym 

wpływunamechanikęgry.Brodzeniepowodzieprzezkorowodypostaciwyglądałojednak 

wyraźnienienaturalnie.Trzebabyłotouwzględnićipostacie,nailetobyłomożliwe,chodziłypostałymgruncie,wybierającwodnąlokacjętylko,gdymogłotowyraźnieskrócićdrogę.Czynnikówtakichwkażdejprodukcjimożeznaleźćsiębardzodużo.Mogątobyćnaprzykładdrogi,którychpostaciepowinnysiętrzymać,mimożemogąoneniemiećkonkretnego 

wpływunaporuszaniesiępostaci.Mogątoteżbyćprzeszkody,którychpokonanienietylko 

zabieradodatkowyczas,aleintuicyjniedlagraczazwiązanejestzwysiłkiem.TudlaprzykładurównieżkłaniasięWiedźmin.Wgrzemożnasiębyłowspinaćnaniewielkiewzniesienia. 

Animacjawspinaniabyłaszybka,jednakzbytczęstewspinaniesięczyzeskakiwaniewyglą- 

45

dałopoprostunierealistycznie.Dlategotrzebaichbyłounikaćbardziej,niżwynikałobytoz 

samegospowolnieniamarszu. 

Ważnemożebyćteżwieledodatkowychmechanizmów.Jakoprzykładpodamefektpo- 

ruszaniasiępostaciprawąstronądrogiczychodnika.Zastosowanietakiegorozwiązaniaw 

miastachnietylkowpływanawrażenierealizmuświatagry,alerównieżzmniejszaczęstotli- 

wośćomijaniaikolizjipostaci,cowperspektywiemożemiećwpływnapoprawęwydajności 

gry. 

Aspektyocenyrozwiązania-konfiguracja 

Zastanówmysięteraznaddynamikąświatagry.Stwarzaonaproblemy,którewwiększości 

powinnyzostaćprzewidzianeirozwiązanejeszczewtrakcieprojektowaniasystemuwyszuki- 

waniaścieżek.Naprzykładprzywyszukiwaniuścieżeknawiększyodkilkukrokówdystans, 

niepowinniśmyzupełniebraćpoduwagęinnychpostaci-gdyżgdyznajdziemysięwich 

sąsiedztwieonezdużymprawdopodobieństwembędąwzupełnieinnympołożeniu.Skoro, 

niebierzemydynamicznieporuszającychsiępostacipoduwagę,topojawiasiękolejnynie- 

trywialnyproblemdorozwiązania,amianowiciestworzeniemechanizmuomijania.Topewien 

dodatkowyelement,istotnyszczególnie,gdyprzestrzeńgryjestgęstowypełnionapostaciami. 

Aletoniejedynyproblemzwiązanyzdynamicznąnaturąświatagry. 

Byopisaćbardzoistotnywwieluprodukcjachaspektproblemu,przyjrzyjmysięabs- 

trakcyjnej,hipotetycznejsytuacji.Wyobraźmysobie,żejesteśmywbudynku,naparterze. 

Chcemydostaćsiędopokojunapiętrze.Jednakklatkaschodowajestzamknięta,ijedynym 

sposobemnadostaniesięnakolejnepiętrojestwinda.Amożejestwłaśnienaodwrót...Roz- 

wiązanieproblemuwydajesięproste-naszsystemwyszukiwaniaścieżekpowinienwiedzieć 

jakdziaławindaidokądmożenasprzenieśćorazbraćpoduwagęfakt,żedrzwimogąbyć 

zamknięte.Acojeśliwindajestzepsuta?Oczywiściesystemiztymmusisobieporadzić.Ele- 

mentówpodobnychwdziałaniudonaszejwindymożebyćwgrzebardzodużoiwieleznich 

możebyćzaimplementowanychprzezprojektantówpoziomównapodstawiedużobardziej 

ogólnychmechanizmów.Działanietakichobiektówmożeopieraćsięnaskryptach,awówczas 

ichefektciężkoprzewidziećwkodziegry.Możeonotakżepowodowaćtrójwymiarowyruch 

obiektów,któregokonsekwencjeteżmogąbyćpraktycznieniemożliwedoprzewidzenia.W 

praktycezdarzasię,żemającwkodziesamobiektwindy,nietylkoniebędzietrywialneokre- 

ślenieczytawindadziała,aletakżezorientowaniesięjakonadziała,gdziemożenasprzenieść 

iczywogólepowinnabyćbranapoduwagęwsystemiewyszukiwaniaścieżek.Praktyczny 

przykładpowyższejsytuacjimożnaznaleźćwsilnikuUnrealEngine 12 .Obiektyinteraktywne 

sąwnimreprezentowanejakoruchomageometria,którapodwpływemzdarzeńgryporu- 

szasięwdowolnysposóbwtrójwymiarowymśrodowisku.Ichruchmożebyćspowodowany 

akcjądowolnego,wywoływanegowgrzeskryptu.Niedość,żewtakimsystemieciężkojest 

stwierdzićcowłaściwierobiobiektwindy(trzebawpaśćnato,żenależywejśćdojejśrodka), 

tojeszczewłaściwienierozwiązywalnymproblememjestanalizawspółzależnościobiektówi 

skryptówgry. 

Ważnymaspektemocenysystemuwyszukiwaniaścieżekjestmożliwośćjegokonfiguracji 

zapośrednictwemnarzędzi.Wgruncierzeczy,jesttopodstawowerozwiązaniepostawionego 

wyżejproblemu.Popierwszemożenamtoumożliwićspecjalnetraktowanieobiektówtakich 

jakwspomnianaprzeznaswindaizamkniętedrzwi.Dobrzenapisanysystemwyszukiwania 

ścieżekpowinienumożliwićprojektantowipoziomuwpływanienaswojedziałaniezuwzględ- 

12 UnrealEngine—silnikgry,produkcjiEpicGames.KolejnegeneracjeUnrealEngiepowstająnabieżąco 

istanowiąawangardęnowychtechnologiiwdziedziniekomputerowejrozrywki.Aktualniejestdostępnana 

rynkutrzeciageneracjasilnika-UnrealEngine3. 

46

nieniemsytuacjifabularnychorazmechanikąfunkcjonowaniaobiektówetapu-oczywiście 

jeżelitakiemożliwościoferujenaszagra. 

Jestjeszczejedenproblem,którywynikazbrakumożliwościkonfiguracjisystemu.System 

jakotakibędziemusiałdziałaćwcałejgrze,adoprogramistynadchodzićbędąbłędydotyczącespecyficznychmiejscświatagryisytuacji.Poprawienietychbłędówspowodujezmiany 

globalne,dlategomożliwejestpojawieniesięnowychproblemów.Błędyzresztąmogąnieleżeć 

postronieprogramisty.Możliwe,żebłędnesąnaprzykładdanegeometrycznelokacjigry,ale 

jeżeliprojektanciitesterzyniedostanąnarzędzipomagającychimkonfigurowaćiobserwować 

działaniesystemuścieżek-błędyzakażdymrazembędąprzechodzićprzezprogramistę. 

Niedotyczytojednakwszystkichprodukcjiispecyfikasystemuwyszukiwaniaścieżekoraz 

użyterozwiązaniapowinnybyćdopasowanedoświatagryorazmechanikirozgrywki.Konfiguracjasystemuścieżekjestpotrzebnawgrach,wktórychporuszaniepostacijestkluczowym 

elementem,iwktórychświatgryjestściślezależnyodprojektantówlokacjigry,aniejesttak 

prostokonfigurowalnyprzezgracza.Szczególniewgrach,wktórychporuszamysiępootwartychprzestrzeniachimamydużąswobodąruchu,konfiguracjasystemuwyszukiwaniaścieżek 

jestdyskusyjna.Nakładanietakiegoobowiązkunaprojektantówiimplementacjanarzędzido 

tegoceluwydająsięwówczaszupełnieniepotrzebne. 

3.6.2.Wydajność 

Wyszukiwanieścieżekpotencjalniemożebyćwąskimgardłemwydajnościaplikacjigry.Jeżeli 

dużoobiektówporuszasiępolokacjigryjednocześnie,każdycojakiśczasbędziewymagał 

uwagisystemuwyszukiwaniaścieżek.Dodatkowo,tejuwagiobiektymogączęstowymagać 

właśniejednocześnie-gdyjakaśgrupaobiektówjestwpodobnejsytuacjiinajejpodstawie 

decydujesiępodjąćakcjęzwiązanązporuszaniem.Ważnejestwięc,byzapewnićmechanizmy 

równoważąceobciążenieobliczeniowewywołanedziałaniemsystemuwyszukiwaniaścieżek. 

Dwapodstawowerozwiązania,zktórymimiałemwtejkwestiistycznośćto: 

1.Wielowątkowość—systemwyszukiwaniaścieżekdziaławewłasnymwątku.Dostaje 

odobiektówgryzlecenianawyszukiwanieścieżekirealizujejeniezależnieodgłównej 

pętligry.Pozaprostotą,dodatkowązaletątegorozwiązania,szczególnieteraz,gdystandardemstająsięmaszynywielordzeniowe,jestmożliwośćwykorzystaniadodatkowychjednostekobliczeniowych.Naniekorzyśćtegorozwiązaniaprzemawiazaśto,żebezimplementacjidodatkowychmechanizmów,tosystemoperacyjnybędziedecydował,ile 

czasunaszaaplikacjapoświęcinawyszukiwanieścieżek. 

2.Ograniczonyczasruchu—torozwiązaniebyłoużytewWiedźminie.Obiektgry 

dostajeograniczonąjednostkęczasunawykonanieruchu.Jeżeliwyszukiwanieścieżek 

niezmieścisięwnim,stanwyszukiwaniajestzapamiętywanyiobiektrozpoczniewyszukiwanieodtegomomentuwnastępnejramce.Minusemtegorozwiązaniajestfakt,żejestonoszczególniezależneodprędkościkomputerainasłabszymsprzęcieprzydzielanyczasmożepozwalaćnamniejsząliczbękrokówalgorytmu,coprzymniejszejliczbie 

klatekpowodujeczasamiolbrzymiwzrostdługościczasuwyszukiwaniaścieżek. 

3.6.3.A* 

PodstawąwiększościsystemówwyszukiwaniaścieżekjestalgorytmA*,sprowadzającysię 

dowyszukiwaniewszerzalgorytmemDijkstry,gdziewierzchołkamigrafuwyszukiwaniasą 

punkty,bądźobszaryprzestrzenigry.Algorytmdziałaczęstonakilkuróżnychpoziomach 

wzależnościodtegojakieodległościrozpatrujemy.Ometodziereprezentacji,tworzeniai 

47

konfiguracjigrafuwyszukiwanianawiększeodległościnapiszęwnastępnychpodrozdziałach. 

Tunatomiastchciałbymwspomniećjeszczekilkasłównatematwyszukiwaniaścieżkina 

stosunkowomałychodległościach,gdymusimyodnaleźćdokładnądrogę,którąmusiprzebyć 

postaćzuwzględnieniemwszystkichprzeszkódterenowych. 

Dlauproszczeniaprzyjmijmy,żewyszukujemyścieżkęnapłaszczyźniedwuwymiarowej,do 

czegozresztą,zwykleproblemjestsprowadzany.Jakowęzływyszukiwaniamożemyużyćsta- 

łegoirównomiernegopodziałupłaszczyzny,naprzykładsiatkikwadratowej,lubnawigacyjnej 

(patrzrozdział3.4.2).Innymrozwiązaniemjestutworzenielogicznej,leniwej 13 przestrzenidla 

danegowyszukiwania(wktórejreprezentacjawęzłówgrafuwyszukiwaniapowstajedopierow 

momenciewzięciaichpoduwagęprzezalgorytmprzeszukiwania,jakoewentualnenastępni- 

ki).Najprościejjestwówczasprzyjąćpunktpoczątkowyikońcowywyszukiwanejścieżkijako 

punktyodniesieniadlatworzonejprzestrzeni.WierzchołkigrafuwyszukiwaniaA*będąlogicz- 

nieprzyporządkowanepunktomterenuznajdującymsięnakratownicyozadanejpodziałce. 

Wierzchołkimogąmiećleniwąreprezentację,toznaczymogąpowstawaćdopierowmomen- 

ciedojściadonichalgorytmuwyszukiwania.Pomiędzywierzchołkamigrafuwyszukiwania 

będzieistniałakrawędź,jeślibędziemywstanieprzeprowadzićpomiędzyreprezentującymi 

jepunktamiobiektdlaktóregowyszukujemyścieżkę.Wielkośćpodziałkimożnadostosować 

dowymaganejszerokościdrogi,odległościpunktówkrańcowychczyukształtowaniaterenu. 

Jesttobardzoważnywybór,ponieważtoodwielkościpodziałkizależyrozmiarprzestrzeni 

wyszukiwania.Stosujączbytdużykrokpodziałkialgorytmmożenietrafićnawłaściweroz- 

wiązanie.Problempojawiasię,gdyświatgryjestzróżnicowanyimamydoczynieniazarówno 

zwąskimiprzejściami,ciasnymipomieszczeniamiorazrozległymiotwartymiprzestrzeniami. 

Bardzoprostym,askutecznymrozwiązaniem,którezastosowałemwWiedźminie,byłady- 

namicznazmianawielkościpodziałki.Użyłemprostejheurystyki,którąoczywiściemożna, 

myślę,zastąpićcelniejszą.Zakażdymrazem,gdyalgorytmodniósłsukceszwiększałemdwu- 

krotniepodziałkę.Gdyalgorytmnieznalazłścieżkipodziałkazmniejszanabyładwukrotnie, 

ażdoustalonegolimitu,aszukaniebyłopowtarzane.Ponieważkażdykrokzwiększał,bądź 

zmniejszałwykładniczoprzestrzeńwyszukiwaniaczaswyszukiwaniarozwiązaniaprzywięk- 

szejpodziałcebyłpomijalnywstosunkudodokładnegowyszukiwania.Heurystykaniebyła 

idealna,bonieuwzględniałanaprzykładsytuacji,wktórychpostaćniemogładojśćdocelu 

gdyżpodziałkabyłazamała(byłlimitliczbyodwiedzonychprzezprzeszukiwaniewęzłów), 

aleogólniedobrzesprawdzałasięwpraktyce.Dodatkowymproblememjakiczasamipowo- 

dowałbardzodużykrokpodziałkibyłynienaturalneścieżki.Przydużejpodziałcealgorytm 

mógłpominąćbardziejnaturalnądrogędocelu.Pókiniedotyczyłotopostacigraczanie 

byłotoproblemem,aużywaniewmiaręmożliwościdużychpodziałekznacznieprzyśpieszało 

wyszukiwanieścieżek. 

3.6.4.Automatycznypodziałpłaszczyzny 

Czaszająćsięwyszukiwaniemścieżkinawiększeodległości.Dlawieluprojektównajlepszym 

rozwiązaniem,będzieautomatycznypodziałświatagrynarejony,pomiędzyktórymiprzeli- 

czanesą(leniwiebądźprzywczytywaniu)połączenia.Szukającdroginajpierwsprawdzamy 

przezjakierejonykolejnoprzejdziemy,adopieropóźniejwyszukujemykonkretneścieżkina 

przejściewichobrębie.Takiepodejścienadajesiędostosowaniaszczególniewgrach,wktó- 

rychświatgryjestbardzodynamiczny(zmieniasięwtrakciedziałaniagry)lubgeometria 

świata,bądźmodelporuszaniasąproste.Plusemtegorozwiązaniajestto,żeniewymaga 

13 Leniweobliczanietotechnikaprogramistycznaodwlekaniaobliczeńdoczasu,ażichwynikbędziepotrzeb- 

ny.Dokorzyściwynikającychzleniwegoobliczanianależyzaliczyć:zwiększeniewydajności,dziękiuniknięciu 

niepotrzebnychobliczeńimożliwośćtworzenianieskończonychstrukturdanych. 

48

żadnejpracyzestronyinnychosóbpozaprogramistą.Utrudniaonojednakmożliwościzewnętrznejkonfiguracjisystemuorazjegosilnąintegracjęzsystememsztucznejinteligencji.Wpraktycejesttodobrerozwiązaniewprojektach,wktórychzzałożenianasystemiewyszukiwaniaścieżekniespoczywawiększaodpowiedzialność.Jeżelinienakładamyograniczeńna 

geometrieświata,rozwiązanietomożebyćbardzoproblematyczne.Możnasobiewyobrazić 

wielesytuacji,którychautomatycznypodziałświataniebędziemógłobsłużyćbezdodatkowych,skomplikowanychmechanizmów.Dużotrudniejteżjestzachowaćrealizmiintuicyjność 

ścieżek.Trzebateżpamiętać,żepodziałpłaszczyznymakluczoweznaczeniedlawydajności 

wyszukiwaniaścieżeknaniższympoziomie-aprzyprzypadkowympodzialeniemamynato 

wpływu. 

WsilnikugryNeverwinterNights 14 użytebyłowłaśnietopodejście.Wyszukiwanieścieżek 

odbywałosięnatrzechpoziomach.Najpierwpomiędzy”lokacjami”(ang.Area)gry,odpowiadającymijednemuspójnemuetapowi.Dlagraczaprzejściepomiędzy”lokacjami”wymagałoprzeładowania,stanowiływięconedużeobiekty.Nadrugimpoziomiewyszukiwanieprzechodziłoprzez”kafelki”(ang.Tile),będącekwadratowymiobszaramiozadanejwielkości,na 

którepodzielonabyłalokacja.Następnienanajniższympoziomieścieżkaliczonabyłajuż 

pomiędzykonkretnymi”kafelkami”. 

3.6.5.Pokoje 

Zamiastautomatycznegopodziałupłaszczyznymożemyzastosowaćpodziałręcznyna”pokoje”.Pociągatozasobąkoniecznośćstworzenianarzędziadoichustawianiaorazręcznegoichwyznaczeniawlokacjachgry.Znającmechanizmdziałaniasystemuwyszukiwaniaścieżekuzyskujemywpływnapoprawnywybórprzezpostaciewyszukiwanejdrogi.Wwyniku 

tegorozwiązaniamożemyuzyskaćznacząceprzyśpieszeniewyszukiwaniaścieżek 15 aścieżki 

wyliczonebędądużologiczniejszeilepiejdopasowanedogeometriiispecyfikilokacji.Ztym 

podejściemsązwiązanejednakpewneproblemy.Popierwszewymagaonenakładupracyproporcjonalniedużego,wporównaniudopozostałych,prezentowanychprzezemnierozwiązań. 

Podrugiejestnieintuicyjneiwyrobieniezasadpodziałunapokojewymaganauki.Potrzecie 

-zmianawsystemiewyszukiwaniaścieżekmożewymusićzmianęustawieniapokoilokacjiw 

grze...Wszystkich. 

TorozwiązaniezostałoużytewWiedźminie.Niestetyprzyniosłosporoproblemów.Podstawoweznichleżąniepostroniesamegoalgorytmicznegorozwiązania,leczprocesupracy 

nadlokacjągry.Systemwyszukiwaniaścieżekjestkonfigurowanypoprzezpodziałprzestrzeni 

poruszanianapokoje.Jestonrobionywprogramie3DStudioMaxprzezgrafika.Natymetapiepracmamylokacjęgry,aleniejesteśmywstaniepowiedziećjakrozmieszczonebędąwniejobiektyiprzeszkody.Byporadzićsobiezestatycznymiprzeszkodamiumieszczanymiwlokacji,trzebabyłonapisaćskomplikowanysystemsprawdzającyspójnośćpokoiorazpołączeń 

pomiędzynimi,awszczególnychprzypadkach,gdycałelokacjegrypokrytebyłybarykadami, 

specjalnieustawiać”naoko”krawędziepokojówbydopasowaćjedoprzeszkód.Projektanci 

implementującyfabułęniemielidostępudokonfiguracjisystemuścieżek,wpraktycewięc 

nierozumieligo,nieznalijegosłabościiniewykorzystywalijegomożliwości.Toniejedyne 

14 JednazpierwszychkomputerowychgierRPG(roleplayinggame)prezentowanazperspektywytrzeciej 

osoby,wpełnitrójwymiarowymświecie.NapisanaprzezBiowareInteractiveiwydanawpołowie2002roku 

przezInfogames(dzisiajwystępującejakoAtari).SilnikAurora,naktórymbyłaoparta,byłpodstawądo 

stworzeniapolskiego”Wiedźmina”. 

15 Wiemy,pomiędzyktórymipunktamibędziewyszukiwanaścieżka.Możemyzapewnić,żewwiększości 

przypadkówwierzchołki,pomiędzyktórymiścieżkaprzezdanepokojebędziewyszukiwanabędąpołączone 

prostąlinią.Tozkoleimożekończyćpracęalgorytmuwpierwszymkroku,bezpotrzebyodpalaniaalgorytmu 

A*. 

49

problemyjakiesprawiałtenpodział.WpraktycewWiedźminiesystemwyszukiwaniadziała 

myślęprzyzwoicie,jednakzostałotoosiągniętezupełnienieproporcjonalnymnakłademsił. 

Poniżejomawiamrozwiązanieopierającesięnazastosowaniupunktównawigacyjnych.Choć 

algorytmiczniesprowadzasiędoomawianego,tozpunktuwidzeniaprocesupracynadgrą 

jestmyślędużolepsze. 

Przykładużyciapodziałunapokojeorazsiatkinawigacyjnejmożnazaobserwowaćna 

ilustracji 3.8. 

Rysunek3.8:ŚwiatWiedźminaijegosiatkanawigacyjnazzaznaczonymkolorempodziałem 

napokoje 

3.6.6.Grafwidoczności 

Najskuteczniejszymrozwiązaniem,októrymsłyszałem,automatycznietworzącymreprezentacjęświatawsystemiewyszukiwaniaścieżek,jestgrafwidoczności.Zastosowanieopartegootąstrukturęalgorytmuzapewniabardzoefektywnewyszukiwanieścieżkizarównonamałejakidużeodległości,choćwymagadokonaniapewnejprekalkulacjilokacjiświatagrywktórejtoczyćsiębędzierozgrywka.Jesttodoskonałerozwiązaniedlaskomplikowanejgeometrii.Choćniemiałemznimbezpośredniejstyczności,sprawiaonowrażanietrudnegow 

implementacjialeniewymagadodatkowejpracyodresztyzespołuprojektowego. 

Spójnączęśćświatagrymożemyabstrakcyjniereprezentowaćjakowielokątdowolnego 

kształtuposiadającywsobiepusteobszary,którychbrzegirównieżstanowiąwielokątyo 

dowolnymkształcie.Wówczaswęzłamigrafuwidocznościmogąbyćwierzchołkileżącena 

krawędziwielokątaświataipustychobszarówwjegownętrzu.Dwawierzchołkitegografusą 

połączone,jeżeliistniejepomiędzynimiprostalinianieprzechodzącaprzezwnętrzepustego 

obszaruinieprzecinającakrawędziświata.Mającutworzonytakigrafjesteśmywstaniew 

bardzoszybkimczasieznaleźćnajkrótsząłamanąłączącądwadowolnepunktyświata.OpierającsięnawiedzyzwykładuGeometriaObliczeniowaprowadzonegonanaszymwydziale 

przezdoktoraMirosławaKowaluka,wiemżegrafwidzialnościjesteśmywstaniestworzyć 

wpesymistycznymczasieO(n 2 ),gdzienjestliczbąkrawędziświata.Jesttojednocześnie 

pesymistycznymrozmiarstruktury.WyszukiwaniewnimdrogipomiędzydwomapunktamiodbywasięwpesymistycznymczasieO(nlog(n)+m),gdziemtoliczbakrawędzigrafu 

widoczności.Wpraktyceprzyodpowiednimdostosowaniualgorytmudospecyfikiprojektu 

możemyotrzymaćbardzouproszczonąreprezentacjęprzeszukiwanejprzestrzeni. 

50

Wierzchołkigrafuwidocznościmożnawyznaczyćautomatyczniewinnysposób,umieszczającjewyłącznieprzybrzegachspójnychobszarówświata.Tominimalizujeprzestrzeńwyszukiwania.PodstawowewprowadzeniedozastosowaniagrafuwidocznościwsystemiewyszukiwaniaścieżekznalazłemwrozdzialenapisanymprzezSteveaRobinawpierwszymtomie 

PerełekProgramowaniaGier[DLo1]. 

Zzastosowaniemtejmetodywiążąsięjednakpewnetrudności. 

•Reprezentacjadynamicznychprzeszkód–czylipostaci(cozwykleitaksprowadzasiędoodrębnegoproblemu)iruchomejgeometriiorazobiektówstatycznych.By 

reprezentowaćdynamiczneobiektywtymsystemiewyszukiwaniamożemywtrakcie 

działaniatworzyćichreprezentacjęwgrafiewyszukiwaniaścieżekimodyfikowaćgraf 

wzależnościodniej.Ewentualnie,jeżelijesteśmywstanieokreślićwszystkiemożliwe 

stanytychobiektów(np.drzwimogąbyćotwartelubzamknięte),alboprzynajmniejje 

sparametryzować,możnaużyćparametrycznejreprezentacjipołączeńgrafu,którebędą 

aktywnewzależnościodstanudynamicznejprzeszkody. 

•Rozmiarobiektów–połączeniasątestowanaprzezprowadzenieprostejliniipomiędzy 

punktami.Uwzględnienierozmiaruobiektówwwyszukiwaniujestprzytympodejściu 

nietrywialne. 

•Zależnośćodgeometrii–czasami,jeżeliniezastosujemydodatkowych,heurystycznychoptymalizacjiiuproszczeńgeometriinawigacyjnej,rozmiargrafumożezupełnie 

niepotrzebnieurosnąć.Wyobraźmysobiekwadratowypokój,naśrodkuktóregojest 

bardzodokładniewymodelowanaokrągłakolumna-wrzeczywistościbędącan-kątem 

foremnym,dlawysokiegon.Liczbawypukłychobszarówwtymświeciebędzierówna 

liczbiewierzchołkówkolumny.Wrazzichliczbąbędzierosławielkośćgrafuwidoczności. 

Rozszerzonageometria 

Wgrafiewidocznościpołączeniamamywyznaczonewformieliniiprostych,conieuwzględnia 

kształtuirozmiaruobiektów.Przybliżmykształtobszarukolizjiobiektupewnąfigurągeometryczną.NazwijmyrozszerzonągeometriąsumęMinkowskiego 

16 geometriiświataikształtuprzybliżającego.Grafwidocznościrozszerzonejgeometriiświatareprezentujemożliwość 

przemieszczaniakształtuprzybliżającego.Niebierzemytupoduwagęobrotów,należywięc 

przybliżyćobiektgrymożliwieprostą,symetrycznąfigurą.Najczęściejmożemysobiepozwolićbyobiektygryreprezentowaćwdwuwymiarowejprzestrzeniwyszukiwaniaścieżekjakokoło.Jakonaszkształtbudującyrozszerzonągeometrięnajlepiejnadawaćsiębędzieopisanynaokręgukolizjikwadrat,ewentualnieośmiokątforemny,aleliczbawierzchołkówgrafuwidocznościjestliniowozależnaodliczbykrawędzikształtuprzybliżającego.Stosującrozszerzonągeometriędostajemygrafwidoczności,którydobrzeopisujeprzestrzeńwyszukiwania 

obiektuozadanymrozmiarze.Możemyzastosowaćparametrycznąreprezentacjęrozszerzonej 

geometriibywygenerowaćprzestrzeńwyszukiwaniaścieżekdlaróżnegorozmiaruobiektów. 

16 DefinicjaSumyMinkowskiego.RozpatrzmywielokątyAiBjakozbiorywektorówowspółrzędnychodpowiadającychwspółrzędnympunktównależącychdotychwielokątów.WtedySumęMinkowskiegomożemy 

określićnastępująco. 

A+B={x+y:x∈A∧y∈B} 

51

Uproszczonygrafwyszukiwania 

Metodatworzeniagrafuwyszukiwania,opisananapoczątkumożezostaćznaczącozoptymalizowana,podkątemminimalizacjigrafu.Interesujenasgrafpunktówprzestrzenitaki,żez 

każdegomiejscawświeciewidzimyconajmniejjedenztychpunktówaobszarypunktów, 

któremożemyprzypisaćdodanegowierzchołkasąspójne.Wbrewpozoromproblemtennie 

jestproblememgaleriisztuki 17 ,choćprawdopodobniezrozwiązańtegoproblemumożnawyciągnąćwielewnioskówdotyczącychoptymalizacjigrafuwidocznościwgrzekomputerowej. 

Implementującgrafwidocznościistotąoptymalizacjibędzieminimalizacjawierzchołkóworaz 

krawędzigrafu.Trzebamiećnawzględzie,żepraktycznezastosowanietegoalgorytmubędzie 

wiązałosięzkoniecznościąwprowadzeniawielumechanizmówoptymalizacyjnych. 

Wrozważaniachnatematgrafuwyszukiwaniaopierałemsięnarozdziałachautorstwa 

ThomasaYoungaPerełekProgramowaniaGier[DLo2].ZnalazłemtamszczegółowoprzedstawionemetodyoptymalizacjigrafuwidocznościorazopisalgorytmówzwiązanychzzastosowaniemrozszerzonejgeometriiitworzeniusumyMinkowskiego. 

3.6.7.Punktynawigacyjne 

Punktynawigacyjnemożemyuznaćzarównoważnegrafowiwidoczności,wktórymręcznie 

wstawiamywierzchołkigrafu.Sąonejednocześniebardzozbliżonedorozwiązaniaopartego 

o”pokoje”.Wlokacjigryzostająręcznierozstawionepunktynawigacyjne.Mogąonebyć 

obiektamigry,reagującyminazdarzeniaikontrolowanymiprzezogólnemechanizmygry 

oraznaprzykładpoleceniajęzykaskryptowegoobsługiwanegoprzezgrę.Punktynawigacyjne 

tworzągraf,poktórymwyszukiwanesąścieżki.Pomiędzydwomawierzchołkamigrafuistnieje 

połączenie,jeżelipomiędzyreprezentującymijepunktaminawigacyjnymiistniejeprzejściew 

liniiprostej.Wpraktycewstawiającpunktynawigacyjnewedytorzemożemyzobaczyćjak 

wpływająonenasystemwyszukiwaniaścieżek.Każdyztychpunktówmożemyopisaćzbiorem 

parametrówpozwalającymnamkontrolowaćichdziałanie. 

•Ktomoże,aktonieużywaćtegopunktuwwyszukiwaniuścieżek. 

•Możemyprostoobserwowaćlub”ręcznie”modyfikowaćwartościowaniewęzłówgrafu 

wyszukiwaniaścieżek. 

•Mamypełnąkontrolęnad”aktywnością”punktunawigacyjnegowsystemiewyszukiwaniaścieżek. 

•SilnaintegracjazsystememAI.Możemyzdefiniowaćwartośćstrategicznądanegopunktu.Możebyćonarównieżheurystyczniewyliczona.Punktynawigacyjnemogąokreślać 

miejsca,wktórychwartowypatrywaćprzeciwnika,przygotowywaćzasadzkę,kryćsię 

czydoktórychniemożnadopuścićinnychpostaci. 

•Punktnawigacyjnymożebyćpowiązanyzobiektamigryktórychstanmożedecydować 

ojegoaktywności. 

•Możemyzłatwościątworzyćróżne,specjalnerodzajeprzejśćjaknp.drogiookreślonej 

szerokości(poktórychprowadziścieżka,nawetjeśliwygładzaniepozwoliłobyjąskrócić), 

drogijednostronne(pisałemjużwyżejokorzyściachwutrzymaniuprawostronnego 

ruchunadrodze),przejściawymagająceużyciaobiektówotoczenia(winda). 

17 GaleriasztukitoznanyNP-trudnyproblemgeometriiobliczeniowej.Celemjestznalezienieminimalnego 

zbioruobserwatorówpotrzebnychbypokryć”wzrokiem”całąpowierzchnięwirtualnejgaleriisztuki. 

52

Wpraktycerozwiązanieto,przydobrejimplementacji,sprowadzasięwdziałaniudosystemu 

pokoi.Potrzebujewiększegowsparciaodstronynarzędziiparudodatkowychelementóww 

implementacji.Jestzatodużowszechstronniejsze,skalowalne,bardziejintuicyjne,prostsze 

wedycjiiwymagająceodresztyzespołumniejszegonakładupracy.Jednocześniejesttowykorzystaniegrafupokoistworzonegoprzezprojektantów.Byćmożejesttowspaniałaszansa 

dlastworzeniahybrydowegosystemuwyszukiwaniaścieżek.Możemykorzystaćzalgorytmów 

automatycznych,gdyniemamyopisanejprzestrzenilubtworzyćautomatyczniekonfiguracje 

systemu,któranastępniemogłabybyćręczniemodyfikowana. 

3.6.8.Dodatkoweelementysystemuwyszukiwaniaścieżek 

Chciałemjeszczewspomniećodwóchelementachsystemuwyszukiwaniaścieżek.Niemająone 

większegowpływunaarchitekturęsystemujakocałości,alesąpodstawowymimechanizmami, 

którychimplementacjamabardzodużywpływnagrę. 

Wygładzanie 

Wygładzanieścieżekjestbardzoistotnąkwestią.Dobrzenapisaneściągawieleodpowiedzialnościzpodstawowegosystemuwyszukiwania.WwynikuwyszukiwaniaA*dostajemyzwykle 

listępunktów,którełącząsięwścieżkępełnąkątówprostych,nagłychzwrotów,częstomałych 

nielogiczności.Wygładzaniedziałanatychpunktachzapewniającdwiepodstawowerzeczy. 

Nailetomożliwezmniejszaliczbęwęzłów,łączącte,pomiędzyktórymimożemyprzeprowadzićprostą.Drugimzadaniemwygładzaniajestdopilnowaniebywmiaręmożliwościnaścieżceniebyłoostrych,nienaturalnychzwrotów-tozkoleiwymagazwykledodaniadodatkowychwierzchołków. 

ImplementacjawygładzaniawWiedźminiewyglądanastępująco.Najpierwnaścieżce 

wstawianesąwrównychodstępachdodatkowewierzchołki-byumożliwićskrócenieścieżki. 

Następniealgorytmprzechodzipowierzchołkachścieżki.Dlabadanegowierzchołkawybiera 

następnik,ułożonymożliwienajdalejnaścieżce,adoktóregomożnadojśćzniegowprostej 

linii.Wszystkiewierzchołkipomiędzybadanymajegonastępnikiemsąodrzucane,aalgorytm 

wykonujesięponowniedlanastępnika,ażdotrzedokońcaścieżki.Potem,jestdokonywane 

wygładzanieostrychkrawędzipoprzezdodawaniedodatkowychwierzchołkóworazprzesuwanieistniejących.Niejestemautoremtegomechanizmu.Osobiściedosystemuwygładzania 

dodałemtylkododatkowymechanizmłączącydwiegładkieścieżki.Potrzebnybyłon,gdy 

dołączanodoaktualniewyliczonejścieżki,kolejnyjejfragment,przechodzącyprzeznastępny 

pokój. 

Kosztczasowywygładzaniajestwłaściwiepomijalnywstosunkudoczasuodnalezienia 

ścieżki.Efektjestjednakbardzodobry.Ścieżkisąnaturalnieproste,pozbawioneostrych 

zwrotów,ajednocześnieoptymalniebliskoprzechodzągładkimłukiemprzyprzeszkodach. 

Efektużyciawyszukiwaniaijegowpływnawyliczoneścieżkiprzedstawiamnailustracji 3.9. 

Omijanieobiektów 

Ponieważśrodowiskogryjestdynamiczne,jestdużaszansa,żewyliczonaprzeznasścieżka 

zostaniezablokowanaprzezinnyporuszającysięobiekt.Rozwiązanietegoproblemujest 

bardzoistotneiczęstonietrywialne.Dlagraczabardzoirytującemożebyć,gdyniebędzie 

mógłprzedostaćsięprzeztłumszarychprzechodniów,przypadkowapostaćzablokujemu 

wąskieprzejścielubzobaczydwóchniemogącychsięwyminąćprzechodniów. 

53

Rysunek3.9:Wpływwygładzanianaścieżkę 

Powyższyproblemmożnarozwiązaćnawieleróżnychsposobówiwpraktyce,najlepszejestwłaśnierównoległewykorzystaniewieluznich,coniepowodujeugraczawrażenia 

powtarzalnościipozwalaobsłużyćbardzociężkiedorozwiązaniasytuacje. 

•A*—Jednymzpodstawowychrozwiązańjestwyszukanieścieżkiobchodzącejprzeszkodę.Wynajdujemybezpiecznąpozycjęnanaszejdrodze,wktórejniekolidujemyzżadnądynamicznąprzeszkodą,anastępniewłączamywyszukiwanieA*.ZależnieodtegojakustawimywyszukiwanieA*,metodatamożewiązaćsięzpewnymiproblemami. 

Popierwszewyszukiwaniepotencjalniemożebyćdosyćdrogie,ajednocześniepowinno 

byćliczonewjednejramcegry.Zdrugiejstrony,jeśliograniczymyjedojednejramkii 

przeznaczymynanieograniczonyczas,bądźliczbęwierzchołków,jegozasięgiużytecznośćmogęucierpieć.Kolejnympotencjalnymproblememjestwielkośćpodziałki.Przy 

mniejszejpodziałceniemaproblemuzzauważaniemwęższejdrogi,natomiastwiększa 

podziałkaznaczącozwiększazasięgprzeszukiwania. 

•Przewidywaniekolizji—Nakolizjepowinniśmyreagowaćzanimsiępojawią.Istniejąbardziejskomplikowanealgorytmy,alewWiedźminiezastosowaliśmyprostyidosyć 

skutecznymechanizm.Idącapostaćtestowała,czynajejścieżce,bezpośrednioprzed 

nią,nieznajdująsięinnepostacie.Jeślitak,włączaławyszukiwanieA*byominąć 

je.Wyszukiwaniebyłoograniczoneczasem,alebyłopowtarzanewkolejnychramkach. 

Oczywiścietakiepodejścieniezałatwiwielusytuacji,gdyktośnaprzykładnaglewbiegnienamnadrogę,alewpraktycesprawdzałosiędostateczniedobrzeiwpołączeniuz 

innymimechanizmamiomijaniadawałokomfortporuszania. 

•Przewidywanieruchu—Problememobupowyższychrozwiązańjestfakt,żedziałały 

54

dlastatycznegośrodowiska.Wyszukującścieżkę,któraokrążałaporuszającąsiępostać 

bardzoczęstomogłosięzdarzyć,żejużpochwiliznowuzniąkolidowaliśmy.Ważnąrze- 

cząjestwięcbyzdawaćsobiesprawęzruchuobiektówprzyliczeniudrogijeomijającej. 

Istniejązaawansowanetechnikiuwzględniająceprzyliczeniuścieżkiomijającejwartość 

czasuipozycjęobiektówwdanejjednostceczasu,jednakniemiałemznimiwiększej 

stycznościiniebyłemwstaniezgromadzićwiarygodnychmateriałównaichtemat. 

Bardzoprostymrozwiązaniem,adającymwymierniedobrerezultaty,jestwyłączenie 

zwyszukiwaniaA*krótkiegowycinkaścieżkiomijanychobiektów.Jegodługośćmoże 

byćzdefiniowanaodgórnie,zależnaododległościodgracza,bądźprędkościporuszania 

sięobiektu.Rezultatjestzauważalnyiprzyzwoity,akosztdziałaniatejmetodywgrze 

orazczasjejimplementacjisąnieznaczne. 

•Algorytmystada—Dobrympodejściemjestwykorzystaniedoomijaniarozwiązań 

podobnychjakteużytewalgorytmiestada. 18 Gdyobiektyporuszająsiędostatecznie 

bliskosiebie,naichruchzaczynaoddziaływaćsiłaodpychającajeodinnych,zależna 

odichbliskości.Wefekciewbardzonaturalnyiintuicyjnysposóbgrupypostacimogą 

niejakowymijaćsięwzajemnienawetwrozległymtłumie. 

•IntegracjazgrąiAI—Pamiętajmy,żejeżeliodpowiedniowizualnieimechanicz- 

nietozamodelujemy,możespowodować,żepostaciebędąsięwzajemnieprzepuszczać, 

przepychaćczyczekaćparęchwilażdrogabędziewolna.Możemypokusićsięointegra- 

cjęomijaniazsystememAIitworzenierozwiązań,wktórychpostaciebędąwzajemnie 

nasiebiereagować.Jeżelidobrzezamodelujemytakierozwiązania,mogąonetchnąć 

dużożyciawświatgry,spowodować,żebędziewyglądałbardziejnaturalnie.Tuzno- 

wuposłużęsięprzykłademWiedźmina.Jednymzgorszychmechanizmówomijania, 

stosowanymwprzypadkach,gdyniemogliśmywykorzystaćinnych,byłoprzepycha- 

niepostaci.Postać,którastałanadrodzeinnej,wyszukiwałasobiebezpiecznemiejsce 

obokścieżkiiporuszałasiędoniego.Drugapostaćpoparuchwilachkontynuowała 

ruch.Wyglądałotonienaturalnie,dlategorozwiązanietobyłowykorzystywanebardzo 

rzadko,gdyinnesposobyrozwiązaniaproblemuzawiodły.Wystarczałojednaktroszkę 

mocniejzintegrowaćtenmechanizmzgrą.Zostałondelikatniezmodyfikowany.Postać 

odpychającamiaławłączanąanimacjęręki,którąprzesuwaładrugąosobę.Tazkolei 

równieżwykonywałaspecjalnąanimację”byciaodepchniętą”.Dotegododałemmałe 

smaczkitakiejakprostodefiniowanyparametr”godności”,świadczącyotymktokogoi 

wjakichsytuacjachmożewtensposóbodepchnąć.Implementacjategobyłanaprawdę 

szybkaiprosta.Poprawiłotoomijanie,ponieważbyłtomocnymechanizmwyglądający 

natyleładnie,żestarałemsięrozsądnieczęstowykorzystywaćtenefekt.Wdodatku 

pozwoliłotonadodaniewieluprostych,aładnychsmaczkówdogry,takichjaknaprzy- 

kładpostacieowysokimpriorytecie,dlaprzykładubogacimieszczanieczyrycerstwo, 

niewymijającepospólstwaibiedoty,tylkobrutalnierozpychającywchodzącychimw 

drogę. 

•Oszustwa—Gratonieaplikacjabankowaituczasamiprogramistamożetroszkęoszu- 

kać.Wartoztegokorzystaćzpewnymumiarem.Jeżeligraczeniewidząbezpośrednio 

zdarzenia,omijaniemożemysprowadzićdoczystejteleportacji.Wartootympamiętać, 

bomożenamtowyraźniewpłynąćnawydajnośćcałegomechanizmu.Kolejnąokazją 

dooszustwsąsytuacje,wktórychpostacie,zgodniezmechanikągrypoprostuniesą 

wstaniesięwyminąć.Wartowtedypomyśleć,czyczasaminiewartonagiąćwówczas 

18 Algorytmstada(ang.flock)-dokładneinformacjeonimznajdująsięwrodziale3.7. 

55

zasadygryinaprzykładpozwolićpostaciomnawzajemneprzenikanie.Takierozwiązaniapowinnybyćstosowanewyłączniewostateczności,gdywszystkieinnezawiodą. 

Jeżeliniebędziemymoglipoświęcićwiększegoczasunastworzenierozwiązaniatakiej 

sytuacji,opartegoosystemsztucznejinteligencjialbospecjalnezachowaniepostaci, 

wówczaswartorozważyćwprowadzeniemałegooszustwa. 

•Niedeterminizm—Dobrąpraktykąprzywszystkichpowyższychpodejściachjest 

zastosowaniepewnegoniedeterminizmu.Szczególnietyczysiętorozwiązańopartych 

ozachowania,sztucznąinteligencjęianimacje.Jeżeligraczprzyzwyczaisiędotego, 

żepewnesytuacjesązawszejednakoworozwiązywane,możetoprowadzićdołatwego 

spowszednieniatychmechanizmówiwkonsekwencjiosłabićefekt,którywywrąone 

nagraczu.Jeżelizasadydoborumetodyomijaniabędąbardzopłynne,intuicyjneale 

ciężkiedopełnegowyśledzenia,bądźpoprostuzależećbędąwograniczonysposóbod 

przypadku,możetowpłynąćpozytywnienaodbiórprzezgraczazachowaniasiępostaci 

wgrze. 

Rysunek3.10:Omijanie.Poprawej:przykładużyciaprzewidywaniakolizji(niebieskielinie). 

Polewej:ciężkasytuacjarozwiązanaprzezinterakcjeobiektów(przepychanie). 

3.6.9.Wnioski 

Najlepszewyszukiwanieścieżek,totakiektóregokońcowyużytkownikniezauważy.Totakie 

też,któreniebędziezauważalnewkontekścierozważaniawydajnościaplikacjiorazktórezafundujenajmniejsząilośćpracyzespołowipracującemunadgrą.Systemmusibyćzaprojektowanywodniesieniudogry,funkcjonalnościjakąodniegooczekujemyorazodpowiedzialnościjakąnaniegochcielibyśmyzłożyć.Bardzoczęstomodułwyszukiwaniaścieżekstanowiintegralnączęśćsystemusztucznejinteligencji.Jużwtrakcieprojektowanianależyprzewidzieć 

jakwpłynieonnacyklpracynadlokacjamiifabułągry.Zaprezentowałemkilkaznanych 

rozwiązań.Doproblemuwyszukiwaniaścieżekmożnapodejśćjednakjeszczenawieleinnych 

sposobów.Szczególniedelikatniepotraktowałemsystemyautomatycznegopodziałuprzestrzeni,jakożewtejkwestiimammniejszedoświadczenieorazwichprzypadku,implementacja 

56

modułusprowadzasiędorozwiązaniaalgorytmicznego.Zestawiajączesobązaprezentowane 

rozwiązania,chciałemuczulićczytelnikanaaspekty,którewymagająuwagijużnaetapie 

projektowaniasystemu. 

57

3.7. Algorytmstadaisztucznainteligencja 

Algorytmstadazostałzaprezentowanyw1987rokuprzezCraigaReynoldsawreferacie 

”Flocks,Herds,andSchools:ADistributedBehaviorModel” 19 .Przedstawiałonmodelreprezentacjiobiektówsymulacji.Wjegopodejściuobiektybyłyautonomicznymiagentami,znającychwyłącznieswojedynamiczne,lokalneotoczenie.Agenciprzestrzegająckilkupodstawowych,intuicyjnychzasadwykazywalizbiorowezachowaniasymulującestadaptaków, 

owadów,czyławicęryb.Tezasadyto: 

•Separacja—zapobieganiezbytniejbliskościobiektówznaszegootoczenia. 

•Wyrównanie—obiektdopasowujesiędośredniegokierunkuitempaporuszania 

obiektówlokalnejgrupy. 

•Spójność—obiektjeststerowanywkierunkucentrumlokalnejgrupy. 

•Unikanie—dodanapóźniejzasada.Agentstarasięunikaćprzeszkódorazinnych, 

szczególniewrogich,obiektów. 

Agenciwchodząwinterakcjęwyłączniezobiektamiznajdującymisięwichbezpośrednim 

otoczeniu.Niekomunikująsię,nieplanują,nieprzechowujądodatkowychinformacjiostadzie 

czyśrodowiskuwktórymsięznajdują.Ichdziałanieopartejestwyłącznieopercepcję. 

DozasadnaktórychoparłsięCraigReynoldsmożnadodaćoczywiściewłasne.Przypisując 

impriorytetywbardzointuicyjnysposóbmożemymodelowaćzachowanieobiektów. 

Rysunek3.11:IlustracjeCraigaReynoldsadotyczącekolejnoseparacji,wyrównaniaispójności. 

3.7.1.Implementacja 

Dlauproszczeniaprzyjmijmy,żenaszobiektznajdujesięwtrójwymiarowejprzestrzeni.W 

danejjednostceczasujestskierowanywpewnymkonkretnymkierunkuorazposiadaskierowanywtąstronęaktualnywektorruchu. 

Algorytmwkażdymkrokumodyfikujewektorruchu,poprzezdodaniedoniegowektora 

modyfikacji.Wektormodyfikacjitworzymysumującwektorypotrzeb,którychdługośćjest 

mnożonaproporcjonalniedopriorytetupotrzeby(specyficznegodladanegoobiektu).Wektory 

potrzebzkoleisąimplementacjąstosowanychzasadstadnych(np.separacji,wyrównaniai 

spójności). 

Nawejściedlaalgorytmubędziemymusielizdefiniowaćmechanizmwidoczności.Obiekt 

musiwidziećznajdującesięwkołoobiektygry.Powinienmócokreślićnajbliższyznichoraz 

uśrednionepołożeniewidzianychprzezniegoczłonkówstada. 

Potrzebęseparacjimożemyzaimplementowaćsprawdzającodległośćmiędzyrozpatrywanymobiekteminajbliższym,widzianymczłonkiemstada.Jeżeliodległośćtajestmniejszaod 

pewnejzałożonej,tworzymywektorpotrzebyseparacji.Skierowanyonbędzieodwidzianego 

19 Dostępnypodadresemhttp://www.red3d.com/cwr/papers/1987/boids.html 

58

obiektudoobiekturozpatrywanegoijegodługośćjestzależnaodwspółczynnikabliskości 

obiektów(czymbliżejtymmocniejszeoddziaływanieodpychające).Jednocześniemożemy 

teżprzyciągaćobiektdonajbliższego,jeżeliodległośćjestwiększaodpewnejzałożonej,choć 

przynajmniejjaniewidziałemdlategooddziaływaniadobregozastosowania. 

Wektorpotrzebywyrównaniamożemyzkoleiutworzyć,biorącpoprostuznormalizowany 

wektorruchunajbliższegoobiektu. 

Wektorspójnościmożebyćreprezentowanyjakoznormalizowanywektorskierowanyod 

rozpatrywanegoobiektu,dośrodkastada. 

Unikanieobiektówmożemyzaimplementowaćnawzórfizycznejsiłyodpychania,kwadratowoprzybierającejnasilewrazzezmniejszaniemsięodległości.Wszystkiepowyższewektorymnożymyprzezpriorytetypotrzebjakiereprezentują.Następniesumujemyje,aotrzymanywektormożemypoddaćdodatkowymprzekształceniomnaprzykładograniczyćjegomaksymalnądługość.Następniewektorzostajeużytywsterowaniuiwpływanazmianęaktualnegowektoraruchuobiektu. 

3.7.2.Wydajność 

Podstawowaimplementacjaalgorytmuwymagabykażdyczłonekstadawykonałconajmniej 

liniowąliczbęczynnościzwiązanychzjegoobsługą.Głównymproblememjesttuzapewnieniewidoczności.Ponieważczęstoalgorytmstadajeststosowanydoimplementacjiprostych 

obiektów,będącychraczejtłemgryiniewpływającychnapodstawowąmechanikęrozgrywki, 

szkodaczasempoświęcaćmuzbytwielezasobówgry.Podstawowąoptymalizacjąjestuproszczeniemechanizmówwidoczności.Możemystworzyćprzedefiniowanestada,wktórychobiektywidząsiębezpotrzebywykonywaniadodatkowychtestów.Możetobardzoprzyśpieszyćalgorytm,ponieważrównieżtestywidocznościzinnymiobiektamistadomożewykonywaćjakocałość.Niestetytakiestadastracąswojąpodstawowąfunkcjonalność,jakąjestautonomicznośćagentów.Przestanąsięonełączyć,dzielić,oddziaływaćwzajemnienasiebie,acałość 

stracinawiarygodności.Kolejnąmożliwościąjestuproszczeniemechanizmówwidoczności. 

Podzielmynaprzykładświatnakratkiipowiedzmy,żewszystkieobiektystadnewdanej 

kratcesięwidzą.Torównieżprosteiskutecznerozwiązanie,sprawiającejednak,żeobiekty 

stadneczasamibędąwobecsiebieślepe,cołatwodostrzeżeuważnyobserwator.Gdywięc 

rozpoczynamyimplementacjęalgorytmuwartodostosowaćjądozadańjakiemupowierzamy 

iichpriorytetuwprojekcie. 

3.7.3.Modyfikacjealgorytmu 

NastronietwórcyalgorytmuCraigaReynoldsa 20 [CR]znajdziemyodnośnikidowieluprzykładówjejwykorzystaniaimodyfikacji.Stosującomawianąmetodologięiustawiającodpowiedniezasadysterującemodelemmożnauzyskaćbardzoróżnorodnemodelesterowania 

obiektami.Zastosowanewalgorytmierozwiązaniasączęstotylkobaządotworzenianowych 

rozwiązańzupełnieróżnychproblemów.Przykłademmożebyćtutajzupełnienieprzypadkoweodniesieniedoalgorytmustadaprzyokazjiomawianiamechanizmówomijaniaobiektów 

wsekcji3.6. 

3.7.4.Zastosowania 

Algorytmznajdujeszczególnezastosowaniewgrach.Wwieluprodukcjachbyłużywanydo 

reprezentowaniamałychżyjątekwchodzącychwskładśrodowiska.Owadów,ptakówrybczy 

20 Aktualnyadres:http://www.red3d.com/cwr/ 

59

innychprostychorganizmówreprezentującychraczejtłowydarzeń.Możebyćjednakużywanydoreprezentacjibardziejskomplikowanychiistotnychelementówrozgrywkijaktłumczy 

oddziałypostaci.WWiedźminiealgorytmstadazostałużytydoopisaniazachowaniamałych 

zwierzątekbudującychnastrójidodającychrealizmuświatagry,aleniemającychżadnego 

wpływunarozgrywkę.Dziękitemu,żekonfiguracjazachowaniazwierzątekwczytywanabyła 

zzewnętrznychskryptówLUA 21 ,byłyoneustawianeprzezprojektantów,bezbezpośredniego 

udziałuprogramisty.Możliwośćparametryzacjizachowaćumożliwiłaoparcienatymmechanizmiezwierząttakichjak:ptaki(czasamiobsiadającegniazda,bądźzwłokiiodlatującegdyktośsięzbliżał),żywyinwentarz(naprzykładkuryigęsi)lubinnemałestworzenia(żaby,myszyikoty),czynawetniekoniecznienależącedokrólestwazwierząt,psotliwegnomy. 

Szczególnieciekawebyłyjednaknietoperze,którenawidokwiedźminawzbijałysiędolotu,i 

przelatywałyobokniego,wyrzucanenastępniesiłąodpychającąleciałydalekowkierunkuz 

któregoprzyszliśmy,byjużniepowrócić.Wszystkietezachowaniaimplementowałjeden,w 

miaręspójny,mechanizm. 

Rysunek3.12:ZwierzątkaopartenaalgorytmiestadawgrzeWiedźmin.Czywypatrzysz 

przyczajonegowtrawiekota? 

3.7.5.Maelstorm 

NaalgorytmiestadaplanowałemoprzećsztucznąinteligencjęwMaelstorm.Algorytmjest 

bardzoprostykoncepcyjnieorazimplementacyjnie.Jegozastosowaniejestbardzointuicyjne 

iszczególnienadajesiędootwartegoświatawjakimtoczysięmojegra.Jedynąrzecząjaka 

stanęłaminadrodzebyłczasrealizacjicałegoprojektu.Niestetyniezdążyłemrozpocząć 

implementacjisztucznejinteligencjiwMaelstormibędzietojednazpierwszychrzeczyktórą 

zaimplementujęwprzyszłychpracachnadprojektem. 

21 Obiektowyifunkcyjnyjęzykprogramowania,stosowanyczęstowgrachjakojęzykskryptowylubdo 

definiowaniaGUI.Więcejinformacjimożnaznaleźćnastronieprojektu:http://www.lua.org/ 

60

Nowościąbyłabypróbazamodelowaniawoparciuoalgorytmstadabardziejskomplikowanychakcji,jakatakowanie,unikaniewystrzałówczyrealizacjacelów.Wymagałobyto 

oczywiściewpewnychsytuacjachodejściaodbezstanowegocharakterualgorytmu.Kolejnym 

problemembyłabyimplementacjazachowaniastadnegoobiektów,któreniemogąbezpośredniozmieniaćswojegowektoraruchuidlaktórychtakazmianawymuszazastosowanieserii 

akcji(naprzykładobrótstatkuwkonkretnymkierunkuiwłączeniesilników/hamulców).Te 

problemyjednaktymbardziejmotywujądopróbyeksperymentowaniazrozwiązaniemopartymoalgorytmstadaipodjęciemsięstworzeniaciekawejlogikirozmytej,kontrolującejstatki 

kosmicznekomputerowegogracza. 

3.7.6.Dołączonyprogramdemonstracyjny 

PonieważnieudałomisięzawrzećimplementacjialgorytmustadawMaelstorm,dołączyłemdopracymagisterskiejinny,niewielkiprogrammojejprodukcji.Demonstracja”Park” 

toprostyprogramsymulującypewnezamknięteśrodowisko.Kontrolawiększościobiektów 

symulacjiopartajestnaalgorytmiestada.Wświeciegry”żyją”: 

•Robot—obiektgracza.Swobodnieporuszamysiępoparkuiobserwujemycosiędzieje 

naokoło. 

•Świetliki—małepasożyty.Trzymająsięwstadach.Rozmnażająsięmiędzysobą 

bezpłciowoiżerująnarosnącychwparkuroślinach.Uciekająprzeddrapieżnymisępami. 

•Sępy—ptaki.Nielubiąswojegotowarzystwaijeżeliakuratniemająochotysięrozmnażać,woląniewchodzićsobiewstrefęłowiecką.Bojąsięteżrobota.Żerująna 

świetlikach. 

•Rośliny—rosnąipowolutkusięrozmnażają.Sązjadaneprzezstadaświetlików. 

Byuzyskaćwiarygodnezachowanieświetlikówisępówużyłemnastępującychzasad: 

•Utrzymujwysokość—obiektystarająsięleciećnakonkretnejwysokości.Świetliki 

latajądelikatnienadziemiąbynieprzegapićroślinekioszczędzaćsiły.Sępynatomiast 

latająwysokobylepiejwidziećzwysokościswojeofiary.Gdysągłodnenurkująwdół 

naofiarę. 

•Unikajłowców—obiektyuciekająodłowców.Stadaświetlikówrozpierzchająsięwe 

wszystkiestronygdywpadniewniesęp,atenzkoleimusibyćkrytyczniegłodnyby 

zbliżyćsiędostadaświetlikówpilnowanegoprzezrobota. 

•Poluj—gdyobiektpoczujegłód,zaczynacorazbardziejpragnąćzbliżyćsiędoswojego 

pożywienia. 

•Szukajpartnera—cojakiśczasobiektymająmożliwośćprzedłużyćswójgatunek. 

Niespełnionepragnieniaoczywiściesiępotęgują. 

•Poruszajsię—pewną,lekkąpotrzebąbyłoporuszaniesięzokreślonąprędkościąw 

aktualnymkierunku.Dziękitemuświatnabrałdynamiki.Sępypatrolowałyokolicę,a 

stadaświetlikówszukałynowychźródełpożywienia. 

•Utrzymujdystans—podstawowezałożenieseparacjizpierwszychimplementacji 

CraigaReynoldsa.Utrzymujemyodpowiedniąodległośćodnajbliższegoczłonkastada. 

61

•Utrzymujkierunek—założeniewyrównania.Tutajrealizowaneprzeznaśladowanie 

prędkościikierunkunajbliższegoczłonkastada. 

•Podążajzastadem—założeniespójności.Świetlikidążądośrodkaciężkościwidzianegoprzezniestada.Sępygounikają. 

Wpowyższymopisiechciałemzwrócićuwagęnaintuicyjnośćstosowanychzasad.Intensywnośćzjakązasadawpływanaruchjestoczywiściezależnaodnatężeniadanegopragnieniaijegopriorytetu.ProgramParkpisałemprzezpółtoratygodnia,alealgorytmstadazadziałałwłaściwieodrazu.Pierwszadziałającawersjasymulacjizzaimplementowanymalgorytmemstada,wktórejpoprawionebyłypodstawowebłędyprogramistyczne,miałapoprawniedziałającysystemsztucznejinteligencji.Prostotategopodejściaumożliwiabardzołatwą 

konfiguracjęsystemu.Ponieważpracujemywśródwartościciągłychkonfiguracjaumożliwia 

intuicyjnetworzeniedosyćzróżnicowanychzachowańnapodstawiejednegosystemu.Gdybymmiałdalejrozwijaćdemonstrację”Park”,myślałembyeksperymentalniezróżnicować 

wmałymzakresieobiektydanegogatunku(lekkoróżnepriorytetypotrzeb)iwprowadzić 

możliwośćdziedziczeniacechprzezpotomków.Wbogatym,stabilnymśrodowiskupowinno 

toprowadzićdoewolucyjnejkonfiguracjiobiektów. 

Rysunek3.13:Demonstracja”Park”. 

62

3.8. Technikiprogramistyczne 

3.8.1.Alokacjapamięci 

Alokacjapamięcijestbardzoistotnąkwestiąwodniesieniudogierkomputerowych.Popierwszegrykomputerowepotencjalniesąaplikacjamiobardzodużymzapotrzebowaniunapamięć,zuwaginakoniecznośćprzydziałuzasobówpotrzebnychdowyświetlaniagrafiki.Drugąkwestiąjestiteracyjnycharakteraplikacji,któraprzetwarzaobiektywirtualnegoświatawielokrotniewtrakciesekundy.Jakiekolwiekbłędyzgubieniemalokowanychwskaźnikównasilająsięlawinowoiprowadządoutratystabilności.Dodatkowo,jeżeliwtrakcieturygrybędziemydokonywalidużejliczbyalokacjiizwalnianiapamięci,pozaoczywistymspowolnieniemaplikacji,pojawiąsięproblemyzfragmentacjądostępnejpamięcioperacyjnej.WtrzydziestodwubitowymsystemieWindowsXPpojedynczyprocesmadodyspozycjiniewięcejjakdwagigabajtypamięcioperacyjnej.WWiedźminiebyłybardzodużeproblemyzwystępowaniembrakupamięci.Oczywiściewszystkiekończyłysiębłędemkrytycznymizamknięciem 

aplikacji. 

Graczęstoniewykorzystywaławięcejjakgigabajtpamięci,alesystemniemógłjużprzydzielićjejspójnegoblokuwiększejdługości.Powodemtegobyławłaśniefragmentacja.Ją 

zkoleipowodowałazbytczęstaalokacjamałychblokówpamięciwciąguprzeciętnejtury 

gry.Usunięcietegoproblemuwymagałobardzodużejpracyisukceszostałosiągniętytylko 

częściowo,ponieważgrawchwiliwydaniamiaławciążpewneproblemyzestabilnością. 

Jednymzrozwiązańczęściproblemówzzarządzaniempamięciąjeststosowaniewłasnych 

lubzewnętrznychfunkcjialokacji.Szczególnietyczysiętosytuacjigdyprojektjestwzaawansowanymstadiumamymamyproblemyzestabilnościąlubwydajnością.Przykładem 

popularniestosowanego,zewnętrznegoalokatorajestnaprzykładbibliotekapoolwchodząca 

wskładdystrybucjiomawianejjużbibliotekiBOOST.Częstowłasnefunkcjealokacjisąw 

pewnymstopniuograniczonewstosunkudostandardowejimplementacjimalloc,alezdrugiej 

stronymogądziałaćdużoszybciejlubprzeciwdziałaćfragmentacji. 

ByobiektyklasyC++przyalokacjikorzystałyzespecjalnychmetodalokacjinależy 

przedefiniowaćdlanichoperatorynew()idelete().Otoprzykład: 

classWorldAction:publicSerializable{ 

public: 

void*operatornew(size_tsz){returng_ActionAllocator.AllocGeneric(sz);} 

voidoperatordelete(void*p){g_ActionAllocator.FreeGeneric(p);} 

virtualvoiddoAction()=0; 

... 

}; 

classWorldActionAddObject:publicWorldAction{ 

public: 

void*operatornew(size_tsz) 

{returng_ActionAllocator.Alloc();} 

voidoperatordelete(void*p) 

{g_ActionAllocator.Free((WorldActionAddObject*)p);} 

voiddoAction(); 

... 

}; 

Naszoperatornew()wywołasięzakażdymrazemgdybędziemytworzyćobiektdanejklasy.W 

powyższymprzykładziejednak,jeżelibędziemyniszczyćobiektwirtualnejklasyWorldAction, 

63

należącywrzeczywistościdoWorldActionAddObject,wówczasjeżelidestruktorklasybazowejniebędziezadeklarowanyjakowirtualny,tojejoperatorzwalnianiazostaniewywołany. 

Inaczejujmująctrzebapamiętać,żeoperatorzwalnianiajestwywoływanyprzezdestruktor 

klasy. 

WMaelstormnaobecnymetapieprojektu,niemusiałemprzejmowaćsięproblemamialokacji.Dlawłasnejsatysfakcjiinaukinapisałemjednakswójalokatoripodpiąłemgodogry 

byprzydzielałpamięćdlaobiektówakcjigry.Todobrerozwiązanie,ponieważichalokacja 

byłapotencjalnymwąskimgardłemaplikacji.Ilośćpowstającychakcjibyłazależnaodliczbyobiektówgryigraczy,comogłoprowadzićdotego,żemocnoobciążonagramiałabypo 

pierwszeolbrzymieproblemyzfragmentacjąpamięci,apodrugiesamaalokacjazajmowała 

bybardzodużączęśćturygry.Rozwiązaniemktórezastosowałembyłonapisaniecyklicznego 

alokatora.Pomysłpewnieniejestoryginalny,alebyłwcałościmój.Alokatorposiadatablicę 

pozycjiktóremożeprzydzielić.Rozmiarjednostkialokacjijestdopasowanydośredniejwielkościnajczęściejalokowanychobiektówakcji.Jeżeliobiektwymagawiększejilościpamięci,rezerwujesobiekilkajednostekalokacji.Pamięćprzydzielanajest”pokolej”.Przechodzęzaalokowanynapoczątkuobszarpamięciprzydzielająckolejnejednostkialokacjiiodnotowując 

wdodatkowejtablicyktóreznichsązajęte.Gdydojdędokońcategoobszaru,zaczynam 

przydzielanieznowuodjegopoczątku.Ponieważakcjesąobiektamiozwykledosyćkrótkim 

czasieżycia,zakładamżeprzyponownymprzechodzeniutablicywiększośćpozycjibędziejuż 

ponowniewolna.Opisałemtorozwiązanieniezpowodujegowyjątkowości,aleraczejżeby 

pokazać,żeindywidualnaalokacjapamięcipowinnabyćdostosowanadospecyfikizarządzania 

obiektami. 

3.8.2.Profilowaniekodu 

Niewcześniejniżjakieśpółrokuprzedwydaniemgry,pracującynadWiedźminemzespół 

zorientowałsię,żegramazdecydowaniezbytwysokiewymaganiasprzętowe.Ponieważdystrybutornalegał,zresztąsłusznie,nakoniecznośćobniżeniaminimalnychwymagańgry,mały 

zespółprogramistów,wtymrównieżja,zostałdedykowanynakrótkiokresdopracwyłącznie 

narzeczoptymalizacjigry.Bardzoistotnymelementemtejpracybyłoznalezienieelementów 

mającychdecydującywpływnawydajnośćcałejaplikacji.Wielefunkcji,mimoewidentnej 

rozrzutnościobliczeniowejokazywałosięwywołanyminatylerzadko,żeniewartobyłopoświęcaćczasunaichpoprawę.Pierwszymużytymdotegocelumechanizmembyłozastosowaniewykresówwydajności.Zostałzdefiniowanyzbiórmakrodefinicjiktórewłączałyiwyłączałypomiarczasudlazdefiniowanegomechanizmuorazprostyzestawkomendpozwalającywłączyćiwyłączyćwyświetlaniewykresówwgrze.Wynikizbieranebyłycorundęgryiprezentowanenaekraniewformiezestawuprostychwykresów(patrzilustracja3.14).DziękizastosowaniumakrodefinicjikompilatoraC++możemyusunąćzupełniefunkcjonalnośćwykresówwydajnościwwynikowymkodzieaplikacji.Uzyskanezapomocątejmetodywynikiokreślajączasdziałaniakluczowychmechanizmówgry.Możnanajejpodstawiewyprowadzićpewneogólniejszewnioski.Brakujejednakszczegółowejwiedzy,codokładniestanowiłookoszciedanychmechanizmów. 

Wznalezieniusłabychpunktówaplikacjipodstawowąpomocąbyłprogramprofilujący, 

umożliwiającyzebraniedanychstatystycznych,natematczasuiczęstotliwościwywołańfunkcjizdefiniowanychwkodziegry.Przykorzystaniuzprogramuprofilującegoistotnebyłoby 

samprocesprofilowaniagryizbieraniadanychniezaburzałwyników.Wielokrotniespowalniał 

onwykonaniekodugry.Uruchamianynanormalnejkonfiguracjigry,powodował,żedziałała 

onazczęstotliwościąklatkinakilkasekund.Wynikiwówczasopisywałyzupełnieekstremal- 

64

Rysunek3.14:WykresywydajnościwgrzeWiedźmin. 

nąsytuację,któranigdyniemiałabymiejscawrzeczywistości.ByprofilowaćWiedźmina 

tworzonabyłakompilacja,wktórejfunkcjaliczącaprzepływczasubyłakilkudziesięciokrotniespowalniana.Beztejprostejfunkcjonalności,przeprowadzonetestypozbawionebyłby 

jakiejkolwiekużyteczności. 

Kolejnymistotnymelementembyłakoniecznośćodpowiedniodobranegomomentuprzeprowadzaniatestu.Programprofilującyzaczynałdziałaćdopierojakiśczaspowłączeniurozgrywkiorazprzejściukilkupierwszychkroków,takbyfunkcjedoczytująceelementylokacjigryniezdominowałyiniezaburzyływynikówtestu.Wtrakciejegodziałaniastaraliśmy 

sięsterowaćpostaciągry,omijającelementyrozgrywki,któremogłybyzaburzyćwynikitestu. 

Naprzykładistotnebyłobynierozpoczynaćdialogów,którychwystąpieniemiałoglobalny 

wpływnasymulacjęmechanikigryorazwyświetlanie. 

Wynikitestówdawałynambardzodokładnąwiedzęnatematkażdejfunkcjiwkodziegry. 

Mieliśmyinformacjenatemattegoilerazybyławywołana.Wiedzieliśmyileczasuaplikacja 

poświęciłanawykonaniejejkoduorazwywołaniekażdejzfunkcjiwniejzagnieżdżonych 

zosobna.Napodstawietakichdanychmogliśmyjużnietylkostwierdzićjakiemechanizmy 

miałynajwiększynegatywnywpływnawydajnośćgry,alerównieżznaleźćtegoprzyczynyi 

prawdziwewąskiegardłaaplikacji. 

65

Rozdział4 

Podsumowanie 

Mojapracamagisterskabyłdlamnieokazjądozdobyciadodatkowegodoświadczeniaoraz 

własnychposzukiwańiprzemyśleńdotyczącychprogramowaniaawszczególnościtworzenia 

gierkomputerowych.WtokupracnadprojektemMaelstormOnline,którerozciągałysięna 

przestrzenitrzechlat,jakoprogramistastarałemsięrozwijaćindywidualnieizawodowo.Sam 

projektbyłmimożliwościądowielueksperymentówprogramistycznychikontaktuznowymi 

dlamnieproblemami. 

Wczęściteoretycznejpracychciałempokrótceprzedstawićtematykętworzeniagieroraz 

przybliżyćkilka,wybranychaspektówzniązwiązanych.Wprezentowanychwrozdziale3rozwiązaniachpopularnychproblemówprogramistycznychtworzeniagier,starałemsięprzedstawićwłasnerozwiązaniatychkwestiiorazpróbowałemprzeprowadzićdyskusjęróżnorodnych 

sposobówpodejściadoproblemu.Starałemsięprzytympokazaćjakbardzoistotnyjest 

świadomydobórużytychrozwiązańnapodstawiespecyfikitworzonejgry,przymożliwym 

zachowaniuichuniwersalności. 

Grykomputerowesądosyćspecyficznymdziałemprogramowania.Otym,żemożnasię 

nimizajmowaćzawodowoprzekonywałemwrozdziale1.Osobiścieuważamtworzeniegier 

zaszczególnieinteresującezprogramistycznegopunktuwidzenia,zuwaginabardzoszeroki 

wachlarzproblemówjakistawiająprzedprogramistą.Wciążdlawiększościznichniema 

idealnychizawszeskutecznychrozwiązań.Istniejejeszczebardzodużepolemanewrudo 

tworzeniazupełnienowychtechnikprogramistycznych,wzorcówprojektowychialgorytmów. 

Choćtworzeniegiersprowadzasięzwykledopodobnegoprocesu,niemożnasobiepozwolić 

napowtarzanieutartychschematów.Kolejneprodukcjezarównopodwzględemprojektujak 

iimplementacjipoprostumusząsięzmieniać.Tak,byzakażdymrazemmócprzyciągać 

uwagęgraczykuszącichnowąjakościąizaskakującnowymielementamirozgrywki. 

4.1. Wnioskidotycząceprojektu 

MaelstormOnlinewchwiliobecnejjestmałąiprostągrąakcjidlawielugraczy.Możliwajest 

dalekoidącąrozbudowaprojektuistworzenienajegosilnikudużobardziejskomplikowanej 

rozgrywki.Założeniaprojektu,któreprzyjąłemnapoczątku,zarównotedotyczącewizjifunkcjonalnościprojektuorazarchitektury,wciążuważamzaaktualne.Mechanizmsynchronizacji 

woparciuozdarzeniagrywdużymstopniusprawdziłsięwpraktyce.Implementacjawydajnej 

izapewniającejsynchronizacjękomunikacjibyłazapośrednictwemtejmetodydużoprostsza 

wporównaniudostandardowegopodejściaimplementacjisieci.OczywiścieMaelstormOnline 

odstronymechanizmówrozgrywkibyłbardzoprostymprojektem,dlategopozostajeotwartympytaniejakrozwiązanietobędziesięskalowaćdosystemówwktórychobiektywchodzą 

67

wdużobardziejskomplikowanąinterakcjęmiędzysobą. 

4.2. Testyaplikacji 

AplikacjaMaelstormOnlinebyłatestowanawkonfiguracji,którazostałaoddanazpracą 

magisterską.Pozapróbągryprzezinternetbyłatestowanawydajnośćsilnikagryaplikacji 

serwera.Chciałemodnaleźćzależnościorazlimitydotyczącekomplikacjisymulowanegoświata.Ilośćobiektów,któremożeonobsłużyćizależnośćwydajnościodrozmiaruprezentowanego 

świata. 

4.2.1.Warunkitechniczneprzeprowadzonychtestów 

GratestowanabyławyłączniepodsystememWindowsXP.Najsłabsząkonfiguracjąnajakiej 

byłauruchamianaaplikacjakliencka,byłkomputerklasyPentiumIV2.8MHzwyposażony 

w512MBpamięciRAMorazkartęgraficznąATIRadeon9550.Aplikacjadziałałanatej 

konfiguracjisprzętowejbezzarzutówiwydajesię,żepowinnadziałaćrównieżnasłabszych 

komputerach.WtrakcietestówaplikacjaklienckadziałałanakomputerzeklasyIntelCore 

2QuadQ66002.4MHzwyposażonymw2GBpamięciRAM.Serwerpodłączonybyłz 

internetemzapośrednictwemrouterasiecilokalnej.ŁączezinternetembyłołączemADSL 

udostępnianymwramachusługiNeostradazpasmemodbioruokoło2Mb/s,awysyłaniem 

256Kb/s.Innekomputeryłączyłysięzserweremzapośrednictwemsiecilokalnejorazza 

pośrednictweminternetu.Łączącesięzapośrednictweminternetukomputerydysponowały 

łączemADSLoprędkośćodbioruconajmniej1Mb/s,choćturównieżwydajesię,żedo 

płynnejgryiwydajnejsynchronizacjistarczyćpowinnodowolnełączeklasyDSL/ADSL 

bądźszybsze. 

4.2.2.Wynikitestów 

Podstawowetestypolegałynagrzepomiędzytrójką,bądźdwójkągraczypołączonychzapośrednictweminternetu.Testyoceniamdosyćpozytywnie,wnormalnychwarunkachopóźnieniaspowodowanekomunikacjąniewpływałynarozgrywkę.Występowałyjednaksporadyczneproblemyzwiązanezsynchronizacjązegara.Wichwynikuakcjeprzychodziłyzaplikacjiklienckiejzkilkusekundowymopóźnieniemcodanemugraczowiuniemożliwiałogrę.Pozostałe,pomniejszebłędyzsynchronizacjązostaływyłapaneipoprawione,wwiększościjeszczew 

trakcieprowadzonychtestów. 

Testywykazałypoprawnośćzastosowanegomechanizmu.Wtrakciepracnadgrąregularniebyłaonasprawdzanawdziałaniuprzezsiećlokalną.Niebyłempewienjakgrazachowasię 

podwpływemwiększychibardziejprzypadkowychopóźnień.Testywtejformieniestetynie 

odpowiadająnapytanie,odnośniepotencjałuiskutecznościzastosowanychrozwiązań.Potrzebnesątestyaplikacjiprzydużymobciążeniukomunikacyjnymzsieciinternet.Należałoby 

przeprowadzićtestyaplikacjiserwerawsytuacjigdypodłączonabędziedoniejbardzoduża 

ilośćzdalnychkomputerów.Takietestysądosyćtrudnedozaplanowaniaiprzeprowadzenia. 

Niestetyniezdołałemichwykonaćprzedoddaniemniniejszejpracy. 

Drugimrodzajemprzeprowadzonychtestówbyłytestywydajnościmechanikigry.Ichrezultatybyłybardzozadowalające.Naserwerzegrybyłyregularnie,copięćklatektworzone 

noweobiektyasteroid,poruszającesięzlosowąprędkościąwlosowymkierunku.Byłustalony 

naichliczbęodgórnylimittrzechtysięcy.Światgrybyłnieduży,takbyczęściejdochodziło 

dointerakcjiasteroid(obiektycałyczaszderzałysięzesobą).Aplikacjaserwerawykonywała 

szesnaściekrokówsymulacjinasekundę.Tomyślęjestoptymalnaczęstotliwośćsymulacjii 

68

przytakiejteżpracowaławtrakcietestówprzezsieć.Przytrzechtysiącachobiektówaplikacja 

serweradziałabezzarzutuwłaściwienieobciążającsystemu.Działałateżbardzorównoiani 

razuniezdarzyłojejsięwyjśćpozaprzypisanynaklatkęserweraczas.Zapierwszymrazem 

uruchomiłemjąwnormalnejkonfiguracjigry.Wwynikukolizji,którepowodowałyuszkodzeniaiwkonsekwencjiniszczenieobiektówgry,ichilośćprzestałaprzyrastaćokołopoziomu 

1900asteroid.Mimociągłejdestrukcjiitworzeniaobiektówcoświadczyłoodosyćmocnym 

obciążeniumechanikigryrozpatrywaniemkolizji,aplikacjadziałałaswobodniewykorzystując 

bardzomałąilośćzasobówsystemowych.Około10MBpamięcioperacyjnejorazminimalnie 

wykorzystującsiłęobliczeniowąprocesorów,mniejniżwieleinnychdziałającychprocesów. 

Następniewłączyłemzadawanieuszkodzeńijeszczerazrozpocząłemtest.Przytrzechtysiącachobiektówzalogowałemsięnaserwerwłączającaplikacjękliencką.Obiektybyłybardzociasnoułożone.Niektórepowolisięporuszałyaleodrazuprowadziłotodozderzeń.Niestetytestbyłmiarodajnytylkowograniczonymzakresie.Wielepotencjalniekosztownych 

mechanizmówdziaławyłączniewodniesieniudozdalnychgraczypołączonychzserwerem. 

Przykłademjesttusprawdzaniewidocznościorazkontrolarozsyłaniaakcjiwyłączniedowidzącychjegraczy. 

Wynikitestówskłaniajądowniosku,żeprzynajmniejjednozzałożeńwydajnościowych, 

stawianychprzedgrąmożebyćspełnione.Nawetjeżeli,niebędzieonawstanieobsłużyć 

ponadstupołączeń,wyglądanato,żezasobykomputerapotrzebnedoobsługimniejszej 

ilościgraczy,będąpozwalałynauruchomieniewielujejegzemplarzy. 

Rysunek4.1:AplikacjaserweraMaelstormwtrakcietestówwydajnościowychmechaniki. 

4.2.3.Horyzontyrozbudowyprojektu 

Jestwieleelementówktóreniezostałyzaimplementowanezuwaginaograniczeniaczasowe 

projektu.Większośćznichnaobecnymetapieniebyładofunkcjonowaniagryniezbędna. 

Przyrozwojuprojektuwpierwszejkolejnościnależałobysięzająć: 

•Możnapoprawićwydajnośćkomunikacji.Przykłademjestprzesyłaniemałychobiektów, 

takichjakpociski,przezsieć.Częśćobiektówmożebyćwczytywanadogryzarównopo 

stronieklientajakiserwera. 

•Należypoprawićbezpieczeństwoaplikacjiserweranawypadekpróbpołączeniasięprogramówklienckichwykorzystującychsłabościjegoimplementacji. 

69

•Brakujeinteligentnychobiektówniezależnych.Żałuję,żeniemiałemmożliwościimplementacjisztucznejinteligencji. 

•Graczepowinnimóctworzyćstatkizdużowiększądowolnością.Graczpowinienmóc 

konfigurowaćkażdywchodzącywskładmyśliwcapodsystem.Podsystemypowinnymieć 

widocznywpływnawyglądstatku. 

•Potrzebyjestrozwójmodułuwyświetlania,noweefektywizualneianimacjeorazprzyjemniejszadlaokaszatagraficznaGUI. 

•Kodpowinienzostaćtakzorganizowanybyrozdziałnaaplikacjęklienckąiserwerabył 

dużoprostszyiczytelniejszy,jednocześniezachowującpozytywneaspektyobecnego 

rozwiązania.Aktualnerozwiązaniezzastosowaniemmakrodefinicjimożenieskalować 

siędowiększegoprojektu. 

•Słabympunktemmojegosilnikamożebyćpełnasynchronizacjazegarapostronieaplikacjiklienckiejzzegaremserwera.Różnicewpomiarzeczasupomiędzykomputeramimogąwkonsekwencjiprowadzićdoutratysynchronizacjigry.Natknąłemsięjużnaciekawerozwiązaniategoproblemu.MiędzyinnymikompletneopracowaniedotyczącetejkwestiimożnaznaleźćwartykulePropagationofVisualEntityPropertiesUnderBandwidth 

Constraints,napisanymprzezOlivieraCado,opartymnadoświadczeniachwpracynad 

komercyjnymigramiMMORPG.Artykułjestdostępnynaserwisiegamasutra[GS]pod 

adresemhttp://www.gamasutra.com/view/feature/1421/propagationofvisualentity.php. 

Jakjużwspominałemwrozdziale2.4tworzącmojąpracęmagisterskąmiałemnauwadze 

dużowiększyprojekt,któregoelementemskładowymbyłabygraMaelstormwformiezbliżonejdoobecnej.Projektującaplikacjęchciałembymogłaonastaćsięczęściąrozproszonego 

systemugrydlabardzodużejliczbygraczy(MassiveMultiplayerOnline).Zakładałem,że 

jeżeliwMaelstormbędziemogłonarazspotkaćsiępowyżejstugraczy,lubjeżelinapojedynczymkomputerze,będziemożnauruchomićkilkaaplikacjiserweraobsługującychróżnerozgrywkidlamniejszejliczbygraczy,wówczasgramogłabystworzyćarchitekturęrozproszoną.Centralnympunktemtejarchitekturybyłbyserwergry”społecznej”.Byłabytozupełnie 

nowaaplikacja,pozbawionaelementówzręcznościowychiwswoimdziałaniudużobardziej 

przypominającaserwisinternetowyopartynabaziedanych.Aplikacja”społeczna”symulowałabyfunkcjonowanierozmieszczonychwpasieasteroidówstacjikosmicznych.Graczezajej 

pośrednictwemmoglibyszukaćnowych,wypełnionychakcjązadańorazwydawaćzarobione 

wtrakcieichrealizacjipieniądze.Opowiadaćoszerszejkoncepcjiprojektumożnabydługo. 

Chciałempoprostuzaznaczyć,żeprojektMaelstormOnlinewswojejobecnejpostacinie 

powinienbyćtraktowanyjakoostatecznyprodukt.Tokompletnysilnikumożliwiającyimplementacjędużobardziejrozbudowanejrozgrywki.Maperspektywyrozwoju,którychrealizacja 

umożliwiłabystworzenienaprawdęatrakcyjnejgry. 

70

DodatekA 

Materiałydostarczonewrazzpracą 

magisterską 

Opróczniniejszegoteoretycznegoopracowania,domojejpracymagisterskiejdołączonajest 

płytaCD.Zawieraonamiędzyinnymirealizacjępraktycznejczęścipracymagisterskiejwpostacikoduźródłowegoorazbinarnej,skompilowanejwsystemieWindows.Otospiszawartości 

dołączonejpłytyzgrą: 

•/maelstorm/source/—KodźródłowygryMaelstormOnline.Wrazzkodemdołączone 

sąplikiprojektuVisualStudio2005.Wtymśrodowiskuzalecamewentualnąkompilację 

kodu. 

•/maelstorm/binary/ —ArchiwumzawierająceskompilowanąidziałającąnaplatformieWindowsgręMaelstormOnline.Byjąuruchomić,należyuprzedniorozpakować 

archiwumnanośnikomożliwościzapisuiodczytu(najlepiejdysktwardy).Szczegóły 

dotyczącekwestiiużytkowaniagryznaleźćmożnawplikureadme.txt. 

•/documentation/pracamagisterska.pdf—Niniejszapracamagisterskawwersjielektronicznej. 

•/documentation/source/—KatalogzawieraplikiźródłowewformacieLaTeX,napodstawiektórychzostałwygenerowanydokumentpracymagisterskiej. 

•/additional/WizjaMMOAsteroids.pdf —Dokumentwizji,którypowstałw2004roku 

idotyczyłprojektumojejprzyszłejpracymagisterskiej. 

•/additional/Prezentacja27.V.2007.ppt —Prezentacjapracymagisterskiejdotycząca 

jejstanuzdnia27.V.2007roku. 

•/additional/illustrations/ —Katalogzawierającywysokiejrozdzielczościilustracjedo 

pracymagisterskiej. 

•/additional/flocking/source/—Kodźródłowyaplikacjisymulującejzachowaniestada, 

októrejwspominałemwrozdziale3.7. 

•/additional/flocking/binary/—Skompilowanawersjademonstracyjnegoprogramusymulującegozachowaniestada. 

71

Bibliografia 

[DLo1]MarkDeLoura,PerełkiProgramowaniaGiertomI,2002Helion. 

[DLo2]MarkDeLoura,PerełkiProgramowaniaGiertomII,2002Helion. 

[DLo3]MarkDeLoura,PerełkiProgramowaniaGiertomIII,2003Helion. 

[AKi4]AndrewKirmse,GameProgrammingGems4,2004CharlesRiverMedia. 

[TW07]Wiedźmin:GraKomputerowa(ang.TheWitcher:Role-PlayingGame),2007CD 

ProjektRED.http://www.thewitcher.com 

[GS]SerwisinternetowyGamasutrahttp://www.gamasutra.com 

[bOGR]Ogre3D,bibliotekagraficznahttp://www.ogre3d.org 

[bGUI]CEGUI Crazy Eddie’s Gui System, biblioteka interfejsu użytkownika 

http://www.cegui.org.uk 

[bAIO]ASIO,AsynchronousInputOutput,bibliotekasieciowahttp://www.libsdl.org 

[bSDL]SDLSimpleDirectMediaLayer,bibliotekamultimedialnahttp://www.libsdl.org 

[CR]CraigRaynolds,stronapoświęconaalgorytmowistadahttp://www.red3d.com/cwr/ 

73

Moja praca magisterska

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?