Zagreb, lipanj 2018. SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA DIPLOMSKI RAD br. 1200 EVALUACIJA ISKUSTVENE KVALITETE VIŠEKORISNIČKIH IGARA TEMELJENIH NA VIRTUALNOJ STVARNOSTI Sara Vlahović
Zagreb, lipanj 2018.
SVEUČILIŠTE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
DIPLOMSKI RAD br. 1200
EVALUACIJA ISKUSTVENE KVALITETE
VIŠEKORISNIČKIH IGARA TEMELJENIH
NA VIRTUALNOJ STVARNOSTI
Sara Vlahović
ii
iii
Zahvaljujem svima koji su volontirali za testiranje razvijenih aplikacija tijekom
njihove izrade i sudjelovali u provedenom ispitivanju.
Osobito zahvaljujem izv. prof. dr. sc. Lei Skorin-Kapov i dr. sc. Mirku Sužnjeviću na
vođenju i pomoći u svim fazama izrade ovog rada.
Zahvaljujem i Matiji Švaci na modelima korištenim u izradi aplikacija te Matiji
Manđurovu na korisnim savjetima.
iv
Sadržaj
Uvod ........................................................................................................................................... 1
1. Izazovi prilikom razvoja višekorisničkih umreženih igara temeljenih na virtualnoj
stvarnosti .................................................................................................................................... 3
1.1. Izazovi zajednički svim višekorisničkim umreženim igrama .................................... 3
1.2. Izazovi specifični za višekorisničke igre temeljene na virtualnoj stvarnosti ............. 5
2. Mrežne arhitekture kod višekorisničkih igara .................................................................... 8
2.1. Vrste mrežnih arhitektura ........................................................................................... 8
2.1.1. Autoritativne mrežne arhitekture ....................................................................... 8
2.1.2. Neautoritativne mrežne arhitekture .................................................................. 10
2.1.3. Hibridne mrežne arhitekture ............................................................................. 11
2.2. Protokoli za prijenos podataka ................................................................................. 11
3. Analiza postojeće umrežene višekorisničke igre u virtualnoj stvarnosti ......................... 13
3.1. Prevođenje mrežnih adresa ....................................................................................... 14
3.2. Zaobilaženje NAT-a ................................................................................................. 14
3.3. Prijenos podataka između klijenta i poslužitelja tijekom igre .................................. 15
4. Idejno rješenje za testnu aplikaciju .................................................................................. 17
4.1. Scenarij kooperativne igre (co-op scenarij) ............................................................. 17
4.2. Scenarij igrač protiv igrača (PvP scenarij) ............................................................... 17
5. Korištene tehnologije ....................................................................................................... 19
6. Umrežavanje testne aplikacije .......................................................................................... 22
6.1. Korištena mrežna arhitektura ................................................................................... 22
6.2. Igra zasnovana na sobama ........................................................................................ 23
6.2.1. Komunikacija unutar sobe ................................................................................ 24
6.2.2. Photonov pogled ............................................................................................... 25
6.2.3. Vlasništvo, instanciranje i prijenos vlasništva umreženih objekata ................. 25
6.3. Mrežna simulacija .................................................................................................... 26
7. Izrada scenarija kooperativne igre.................................................................................... 28
7.1. Dizajn scene ............................................................................................................. 28
7.2. Kretanje i korisnička interakcija .............................................................................. 30
7.3. Ostvarenje mehanike igre ......................................................................................... 33
8. Izrada scenarija igrač protiv igrača .................................................................................. 34
v
8.1. Dizajn scene ............................................................................................................. 34
8.2. Kretanje i korisnička interakcija .............................................................................. 35
8.3. Ostvarenje mehanike igre ......................................................................................... 37
9. Metodologija ispitivanja ................................................................................................... 38
10. Rezultati ........................................................................................................................... 41
11. Analiza Rezultata ............................................................................................................. 44
12. Zaključak .......................................................................................................................... 47
13. Literatura .......................................................................................................................... 48
Sažetak ..................................................................................................................................... 53
Summary .................................................................................................................................. 54
Dodatak A: Upitnik za ocjenjivanje iskustvene kvalitete ........................................................ 55
1
Uvod
Industrija igara iz godine u godinu bilježi sve veći rast – u 2018. godini predviđa se da će 2,3
milijarde igrača diljem svijeta na igre potrošiti ukupno 137,9 milijardi američkih dolara, što je
povećanje od 13,3% u odnosu na 2017. godinu [1]. Najveći dio prihoda u 2017. godini
ostvaren je na mobilnim igrama, ali odmah potom slijede besplatne masivne višekorisničke
umrežene igre. Pritom je za besplatne masivne višekorisničke umrežene igre u 2017. godini
očekivan rast od 13% u odnosu na prihod ostvaren u prethodnoj godini. Iako je njihov prihod
još uvijek relativno malen u odnosu na neke druge kategorije igara, dvije kategorije koje
bilježe najveći porast tijekom 2017. godine su kategorija virtualne stvarnosti (engl. Virtual
Reality, skraćeno VR), s očekivanim porastom od čak 259% te kategorija elektroničkih
sportova (engl. eSports), odnosno organiziranih natjecanja u višekorisničkim igrama, s
očekivanim porastom od 26% u odnosu na 2016.-u godinu [2].
Velika popularnost višekorisničkih umreženih igara i rastuće tržište VR igara ukazuje na
potencijal višekorisničkih umreženih igara u virtualnoj stvarnosti. Virtualna stvarnost mogla
bi promijeniti načine na koje doživljavamo različite žanrove i kategorije višekorisničkih igara
i iskustava. Primjerice, glavni argument protiv svrstavanja elektroničkih sportova u „prave“
sportove, unatoč vještini i pripremama igrača, jest manjak fizičkog napora i korištenja
fizičkog igraćeg prostora [3], ali mišljenje javnosti moglo bi se promijeniti nakon što se u
organizirana natjecanja uključe višekorisničke umrežene VR igre koje zahtjevaju kretanje
prostorom i fizičke pokrete. Pojava specijaliziranih prostora namijenjenih višekorisničkom
korištenju VR-a, dovoljno velikih da omoguće sigurno i ugodno iskustvo igre za velik broj
istovremenih korisnika, mogla bi revolucionirati iskustvo igranja ratnih, borbenih i sportskih
igara, a tehnologija za takav oblik zabave već je u razvoju. Tehnologija tvrtke Modal VR
omogućava istraživanje virtualne stvarnosti u velikim prostorima (do 83 613 kvadratnih
metara) zahvaljujući uređaju koji komunicira s posebnim odijelima i zaslonima montiranima
na glavu (engl. head mounted displays, skraćeno HMD) te može pratiti lokaciju, položaj tijela
i glasovnu komunikaciju do 10 igrača, uz mogućnost praćenja većeg broja igrača
povezivanjem putem mreže [4]. Ovakav sustav postavljen u prostoru odgovarajuće veličine
osigurava slobodu kretanja igrača, a može se koristiti za tematska zabavna iskustva u igraćim
arkadama i zabavnim parkovima, interaktivne atrakcije, elektroničke sportove i grupne igre,
2
vizualizacije zgrada i filmskih setova, izložbe te u svrhu sportskog, vojnog i astronautskog
treninga [5].
Međutim, zbog činjenice da je tehnologija virtualne stvarnosti još uvijek nova na tržištu, broj
njenih korisnika je još uvijek relativno malen, kao i broj razvijenih VR igara i aplikacija. Još
je manji broj VR aplikacija koje podržavaju umreženi višekorisnički način korištenja, što
ujedno znači da je riječ o novom i još nedovoljno istraženom području. Zadatak ovog rada je
proučiti utjecaje mrežnog kašnjenja na iskustvenu kvalitetu kod VR aplikacija, kao i izraditi
dvije jednostavne višekorisničke VR aplikacije s kooperativnim i borbenim načinom igre.
Kako bi se pomnije istražio utjecaj mrežnih parametara na korisničko iskustvo u virtualnoj
stvarnosti za potrebe ovog rada proučena je postojeća VR igra Serious Sam VR: The Last
Hope te opisana njena arhitektura. Izrađene su dvije jednostavne višekorisničke VR igre,
jedna sa scenarijem za suradnju i druga sa scenarijem za borbu igrača te je osmišljena i
izvedena korisnička studija za evaluaciju utjecaja različitih iznosa kašnjenja na subjektivne i
objektivne metrike iskustvene kvalitete na primjeru VR igre Serious Sam VR: The Last Hope.
Rad je strukturiran kako slijedi. Nakon Uvoda, u prvom poglavlju, Izazovi prilikom razvoja
višekorisničkih igara temeljenih na virtualnoj stvarnosti, pobliže su objašnjeni različiti
izazovi s kojima se susreću razvijatelji višekorisničkih umreženih VR igara, uključujući
izazove zajedničke svim umreženim višekorisničkim igrama te izazove specifične za VR. U
drugom poglavlju objašnjeni su autoritativni, neautoritativni i hibridni tipovi mrežnih
arhitektura koje se koriste za umrežavanje višekorisničkih igara, kao i korišteni mrežni
protokoli za prijenos podataka. Potom je u trećem poglavlju provedena analiza višekorisničke
umrežene VR igre Serious Sam VR: The Last Hope. U poglavljima 4–8 objašnjen je razvoj
izrađenih aplikacija, od idejnog rješenja i korištenih tehnologija, do dizajna scene i
implementacije funkcionalnosti. Deveto poglavlje opisuje metodologiju ispitivanja provedene
korisničke studije, a rezultati i analiza rezultata te studije nalaze se u poglavljima 10 i 11.
Dvanaesto poglavlje je zaključak, a trinaesto popis literature, nakon čega slijede sažeci rada
na hrvatskom i engleskom jeziku. U dodatku se nalazi Upitnik za ocjenjivanje iskustvene
kvalitete korišten u korisničkoj studiji.
3
1. Izazovi prilikom razvoja višekorisničkih umreženih
igara temeljenih na virtualnoj stvarnosti
1.1. Izazovi zajednički svim višekorisničkim umreženim
igrama
Tijekom višekorisničke igre može doći do nepredviđenih kvarova i pogrešaka vezanih uz
mrežnu povezanost i ispravnost uređaja. Potrebno je dizajnirati igru na takav način da se
minimizira utjecaj kvarova na strani korisnika na virtualni svijet. Distribucija korisnika i
operacija na više poslužitelja igru čini robusnijom i manja je vjerojatnost da će veliki broj
korisnika uopće primijetiti pojavu kvara pojedinog poslužitelja. Stabilnost mrežne
povezanosti postiže se pomoću redundantnih poveznica i mrežnih uređaja te uspostavljanjem
planova za brzi oporavak nakon kvarova [6].
Kod višekorisničkih igara osobito je potrebno paziti na ravnopravnost igrača unutar igre i
zaštitu njihovih podataka. Kod igara koje sadrže transakcije potrebno je osigurati maksimalnu
sigurnost korisničkih podataka te omogućiti povrat ukradenog računa originalnom korisniku.
Prevencija varanja kod višekorisničkih igara bitnija je nego kod igara namijenjenih samo
jednom korisniku zbog negativnog utjecaja na preostale korisnike, zbog čega je potrebno
uvesti mehanizme protiv varanja i transparentnu administraciju unutar igre [6].
Kod višekorisničkih igara s velikim brojem korisnika pojavljuje se problem skalabilnosti.
Skalabilnost je sposobnost sustava, mreže ili procesa da se nosi s rastućom količinom posla ili
naraste sukladno njoj. Prilagodba kapaciteta poslužiteljske arhitekture je kompleksan problem
s obzirom na varijacije u broju igrača tijekom vremena. Kad je broj igrača puno manji od
podržanog dolazi do neiskorištenosti poslužitelja, što znači nepotrebne financijske troškove,
ali kad je broj igrača prevelik može doći do rušenja poslužitelja. Također, skalabilnost se
može promatrati kroz broj korisnika koji se istovremeno mogu nalaziti u virtualnom svijetu
dovoljno blizu da mogu utjecati jedan na drugoga. Igrači se unutar virtualnog svijeta redovito
skupljaju oko jedne ili više točaka grupiranja pa preveliki broj korisnika na jednom mjestu
može dovesti do preopterećenosti poslužitelja. Kod nekih igara taj se problem rješava kroz
4
sam dizajn igre tako da se smanji broj mogućih interakcija svrstavanjem igrača u ograničene
grupe tako da je samo unutar njih moguće međudjelovati [6].
Bitan problem kod umreženih višekorisničkih igara je i širina mrežnog pojasa potrebna za
razmjenu informacija o virtualnom svijetu. Kako bi se svim korisnicima osigurao
konzistentan prikaz šalju se redovita ažuriranja (engl. updates) stanja virtualnog svijeta. Pri
tome potrebna širina mrežnog pojasa ovisi o dinamičnosti virtualnog svijeta, kontekstu igre,
broju korisnika i tipu informacija koje se prenose, pri čemu detaljni podaci o 3D sceni
zahtjevaju veću širinu mrežnog pojasa od prijenosa osnovnih podataka o trenutnim pozicijama
i izvršenim akcijama igrača [6].
Kašnjenje (engl. delay) je vidljivo zaostajanje, usporavanje ili smanjena responzivnost igre.
Do grafičkog kašnjenja dolazi kada sustav ne može proizvesti dovoljno okvira po sekundi
(engl. Frames Per Second ili FPS) da bi iskustvo igre bilo glatko i kontinuirano. Mrežno
kašnjenje (engl. network delay) je vrijeme potrebno za putovanje podatka kroz mrežu od
jednog čvora ili krajnje točke do drugog čvora ili krajnje točke te u umreženim igrama
rezultira primjetnim zaostajanjem između akcija igrača i prezentacije njihovih rezultata koje
nastaju nakon reakcije poslužitelja na tu akciju. Mrežno kašnjenje nikada se ne može u
potpunosti ukloniti, a može dovesti do raznih paradoksalnih situacija unutar igre. Pri tome je
konstantni iznos kašnjenja manje problematičan od kolebanja kašnjenja. Utjecaj kašnjenja na
iskustvo igranja ovisi o tipu igre – primjerice, strateške igre većinom mogu tolerirati veće
kašnjenje u odnosu na brze akcijske igre. Istraživanja [7] su pokazala da korisnici vrlo dobro
toleriraju kašnjenje od 50 milisekundi, čak i kad je riječ o dinamičnim igrama poput trke
automobilima. Kašnjenje od 100 milisekundi dovelo je do primjetnog kašnjenja za taj tip igre,
no za manje zahtjevan tip igre mogao bi biti dovoljno maleno da ne smeta korisnike. Veća
kašnjenja od toga svakako bi trebalo izbjegavati.
Komponente ukupnog kašnjenja kod VR sustava su kašnjenje uzorkovanja senzora (engl.
sensor sampling delay), kašnjenja iscrtavanja okvira, mrežno kašnjenje i kašnjenje
osvježavanja ekrana (engl. display refresh delay) [8]. Zbog toga što je riječ o računalno
zahtjevnom tipu aplikacije, s VR aplikacijom vrlo primjetno kašnjenje može se dogoditi čak i
kada je riječ o igri koja ne zahtjeva više igrača ili mrežnu povezanost. Naime, VR sustavi kao
što su HTC Vive, Oculus Rift i PSVR imaju stanice za praćenje koje izvode računalne
operacije i predviđanje kretanja korisnika 90 ili više puta u sekundi. VR HMD-ovi sadrže dva
ekrana, po jedan ekran prosječne veličine 1080x1200 piksela za svako oko. Za stvaranje
5
realističnog dojma trodimenzionalnosti potrebno je da se slike na ta dva ekrana malo razlikuju
što zahtjeva dvostruko iscrtavanje. Povrh toga, dok većina AAA igara zahtjeva brzine
osvježavanja (engl. refresh rate) između 30 i 60 FPS za ostvarenje glatkog iskustva igre, za
VR igre i aplikacije potrebno je ostvariti oko 90 FPS-a, ali u idealnom slučaju 100 do 110
FPS-a kako bi igra mogla podnijeti padove broja okvira po sekundi (engl. FPS drop) i još
uvijek osigurati dovoljno ugodno korisničko iskustvo [9]. Naime, padovi ispod 90 FPS-a
povećavaju vjerojatnost pojave fizičke neugode pa igre kod kojih dolazi do značajnih padova
ne mogu proći certifikaciju za određene VR sustave (primjerice, kako bi igra bila certificirana
za Sonyjev PSVR njena brzina osvježavanja okvira nikada ne smije pasti ispod 60 FPS-a
[10]). Uz to, kašnjenje između ulaznih podataka (engl. input), primljenih putem VR opreme,
te posljedične vizualizacije smanjuje osjećaj imerzije, što je vrlo bitan faktor za virtualnu
stvarnost.
Zbog velikog utjecaja koji preostale komponente kašnjenja imaju na korisničko iskustvo
prilikom igranja VR igara može se zaključiti da bi dodatak mrežnog kašnjenja kod umreženih
igara u virtualnoj stvarnosti mogao još više narušiti iskustvo igre, te da je za VR igre
postizanje adekvatnih mrežnih performansi i minimalnog mrežnog kašnjenja od još veće
važnosti nego za ostale vrste višekorisničkih igara. Štoviše, mnogi smatraju da su igre u
virtualnoj stvarnosti općenito najosjetljivije na kašnjenje te podnose samo jako mala kašnjenja
[11], pogotovo kad je riječ o kašnjenju između pomaka glave i rezultirajuće promjene prikaza
na ekranu, čiji bi iznos trebao ostati manji od 20 ms [12]. Istraživanja su također pokazala da
kašnjenja iznad 225 ms značajno otežavaju interakciju sa svijetom u virtualnoj stvarnosti [13].
1.2. Izazovi specifični za višekorisničke igre temeljene na
virtualnoj stvarnosti
Višekorisničke VR igre mogu se igrati u istoj sobi ili na daljinu. Kada se višekorisničke igre
igraju na daljinu fizička opasnost za igrača (kolizije, padovi) ista je kao i kad igra igru
namijenjenu samo jednom igraču, ali komunikacija igrača preko mikrofona i slušalica
drugačija je nego komunikacija uživo, što može škoditi imerziji. Ukoliko se višekorisničke
igre igraju u istoj sobi može doći do problema jer igrači vide samo svoje pozicije u
virtualnom, ali ne i stvarnom prostoru, pri čemu može doći do sudaranja i udaraca, zbog čega
je potrebno pripaziti na ograničavanje broja igrača koji odjednom mogu biti prisutni u igri,
6
kako njihov broj ne bi bio prevelik te na regulaciju kretanja i osiguravanje dovoljnog razmaka
između korisnika unutar igre [14].
U višekorisničkim igrama korisnici ponekad moraju provesti kratko vrijeme čekajući sljedeću
partiju, borbu ili meč u sceni koja se naziva višekorisničko predsoblje (engl. multiplayer
lobby) te koja služi za odabir suigrača i opcija igre. Zbog relativno malog broja ljudi koji
posjeduju VR uređaje manji je broj raspoloživih suigrača te korisnici često moraju provesti
dulje vrijeme čekajući u predsoblju u usporedbi s korisnicima igara koje nisu u VR-u.
Korisnici VR-a s headsetom na glavi ne mogu tijekom čekanja međudjelovati s fizičkim
svijetom oko sebe i raditi nešto drugo dok čekaju. Zbog toga je još bitnije omogućiti
korisnicima boravak u višekorisničkom predsoblju s responzivnim i interaktivnim elementima
te im tako osigurati nešto zanimljivije iskustvo čekanja.
Još jedan od problema specifičnih za virtualnu stvarnost jest reprezentacija korisnikovog
fizičkog tijela u virtualnom prostoru. S obzirom na to da objekti kojima je igrač okružen u
virtualnoj igri nisu stvarni fizički objekti ne postoji ništa što bi ga spriječilo da napravi korak
naprijed i prođe kroz zid ili da unatoč neprijateljskom blokiranju njegovog udarca mačem
njegova ruka prođe kroz protivnički štit. Prilikom takvih trenutaka gubi se povezanost između
korisnikova stvarnog tijela i njegovog avatara koji reagira na fiziku virtualnog svijeta unatoč
tome što ona ne može djelovati na korisnikovo stvarno tijelo. Gubitak te povezanosti utječe na
imerziju i kvalitetu iskustva igrača, kao i na tijek igre, te stoga razvijatelji igara moraju
osmisliti načine da se takve pojave minimiziraju. Primjer toga je zacrnjivanje ekrana igrača
kad pokuša proći kroz zid ili korištenje korisničkog sučelja kako bi se korisnika upozorilo da
izbjegava vrste pokreta koji stvaraju nepovezanost između njega i njegovog avatara.
Međutim, čak i kada se igrači pridržavaju takvih savjeta svejedno može doći do problema s
korisničkim avatarom, što je osobiti problem upravo za višekorisničke VR igre i aplikacije jer
one počivaju na činjenici da korisnici moraju moći vidjeti jedni druge u virtualnom svijetu.
Korištenjem VR sustava kao što su Oculus Rift ili HTC Vive mogu se sa dovoljnom
preciznošću pratiti samo glava i šake korisnika, što nije dovoljno informacija da bi se iz njih u
potpunosti mogli ekstrapolirati podaci o položaju i poziciji čitavog tijela, što rezultira
netočnim, neprirodnim i ponekad potpuno bizarnim kretanjem avatara. Rješenje ovog
problema može biti hardversko: dodavanje dodatnih senzora pokreta (primjerice na trup i
noge), korištenje posebnih odijela za praćenje pokreta ili dubinskih senzora kao što je
Microsoftov Kinect. Bez korištenja dodatnih uređaja taj se problem može popraviti
7
korištenjem strojnog učenja za bolje predviđanje pokreta na temelju kutova i pozicija u
kojima se nalaze korisnikovi kontroleri ili headset na glavi. Međutim, najjednostavnije i
najjeftinije rješenje krije se u jednostavnijem dizajnu avatara pomoću kojeg se mogu potpuno
izbjeći dijelovi avatara koji stvaraju probleme [15]. Primjerice, igrač može biti predstavljen
kombinacijom lebdeće biste i lebdećih šaka, kao što se može vidjeti na primjeru Oculus
Avatara (slika 1-1).
Slika 1-1: Primjer Oculus Avatara (slika preuzeta s [16]).
8
2. Mrežne arhitekture kod višekorisničkih igara
2.1. Vrste mrežnih arhitektura
Postoji više različitih mrežnih arhitektura pomoću kojih se može ostvariti višekorisnička igra,
ali ih općenito možemo podijeliti na dvije grupe po raspodjeli autoriteta: autoritativne (engl.
authoritative) i neautoritativne (engl. non-authoritative) [17]. Također, postoje hibridne
arhitekture koje imaju svojstva i jedne i druge grupe.
2.1.1. Autoritativne mrežne arhitekture
Najpoznatija mrežna arhitektura u autoritativnoj grupi je tradicionalna arhitektura klijent–
poslužitelj (engl. client–server architecture). Poslužitelj ima ulogu autoritativne središnje
jedinice koja upravlja stanjem igre na temelju poruka o igračevim akcijama koje dobija od
kliijentskog računala. Na temelju dobivenih podataka poslužitelj izračunava i osvježava novo
stanje igre te šalje podatke klijentu koji na temelju njih osvježava svoj lokalni prikaz stanja
igre [17].
Slika 2-1: Arhitektura klijent–poslužitelj s posvećenim poslužiteljem.
9
Slika 2-2: Arhitektura klijent–poslužitelj gdje jedno od klijentskih računala služi kao poslužitelj.
Na slici 2-1 prikazana je varijanta arhitekture klijent–poslužitelj gdje zasebno računalo
izvršava ulogu poslužitelja (tzv. posvećeni poslužitelj, engl. dedicated server), a na slici 2-2
prikazana je varijanta bez posvećenog poslužitelja gdje jedno od klijentskih računala ujedno
služi kao poslužitelj (engl. client-hosted). Iako je posvećeni poslužitelj obično bolja opcija,
skuplji je i kompleksniji za izvedbu, osobito s obzirom na problem skalabilnosti [18]. S druge
strane, client-hosted arhitekture podložnije su varanju od strane klijenta koji je poslužitelj. U
svakom slučaju računalo koje obavlja ulogu poslužitelja mora se nositi s većom količinom
posla od preostalih računala te većim mrežnim opterećenjem zbog komunikacije sa svim
klijentima [19].
S obzirom da klijent čeka poslužiteljeve odluke mrežno kašnjenje utječe na responzivnost igre
i ulazno kašnjenje (engl. input lag). Taj se problem umanjuje predviđanjem na strani klijenta
(engl. client side prediction). Ako je svijet igre deterministički, odnosno ako uz isto stanje i
iste ulazne podatke dolazi do istog rješenja, klijent može predvidjeti stanje igre nakon
igračevih akcija te tijekom čekanja krenuti iscrtavati njihov rezultat kao da je dobio takvu
informaciju od poslužitelja [20]. Ako je klijentovo predviđanje neispravno bit će ispravljeno
nakon što klijent primi poruku o stvarnom stanju od poslužitelja, ali u većini slučajeva
klijentovo predviđanje odgovarati će stvarnom stanju igre [19].
10
2.1.2. Neautoritativne mrežne arhitekture
Neautoritativne arhitekture su decentralizirane – kod njih ne postoji središnja jedinica nego
svaki od sudionika (engl. peers) kontrolira svoje stanje igre te šalje podatke o svom stanju
ostalim sudionicima, a na temelju podataka koje primi od drugih obavlja simulaciju njihovog
stanja. Takav sustav naziva se sustav s ravnopravnim sudionicima (engl. peer-to-peer,
skraćeno P2P) i prikazan je na slici 2-3.
Slika 2-3: Arhitektura s ravnopravnim sudionicima.
U klasičnom P2P sustavu igrač odmah vidi vlastito stanje igre i nema problema s ulaznim
kašnjenjem, no simulirano stanje svakog ostalog igrača osvježava se nakon što računalo primi
poruku o njegovom stanju, što znači da različita mrežna kašnjenja kod sudionika mogu imati
veliki utjecaj na tijek igre i dovesti do paradoksalnih situacija [17].
Deterministička P2P simulacija (engl. deterministic peer-to-peer lockstep) je P2P model kod
kojeg svi sudionici šalju akcije igrača te igra izvršava simulaciju stanja “u koracima”,
odnosno nakon što prikupi poruke svih sudionika, čime se eliminiraju problemi sa
sinkronizacijom i nekonzistencijom stanja. Međutim, kod ovakve arhitekture može doći do
ulaznog kašnjenja jer se rezultat igračeve akcije prikazuje tek kad se izvrši simulacija.
Deterministički PvP je model prikladniji sporijim igrama i igrama zasnovanim na igranju u
krugovima (engl. turn-based) [18].
11
Uz problem sinkronizacije mana P2P arhitekture je i podložnost varanju (primjerice slanje
lažiranih poruka sudionicima da su pogođeni) zbog činjenice da svaki sudionik preostalim
sudionicima šalje poruke o svom stanju te sudionici “vjeruju” u ispravnost poruka koje
dobivaju. S obzirom da svi sudionici međusobno izmjenjuju poruke ovakav sustav također
podrazumijeva veći ukupni broj paketa koji se šalju putem mreže od modela klijent–
poslužitelj, no izbjegava se koncentrirana opterećenost autoritativnog poslužitelja [19].
2.1.3. Hibridne mrežne arhitekture
Zbog problema arhitektura klijent–poslužitelj i P2P većina stvarnih sustava je hibridna,
odnosno kombinira značajke navedenih arhitektura. U takvim modelima poslužitelj još uvijek
odlučuje o nekim aspektima, ali mu se opterećenje smanjuje tako da se klijentima preda dio
autoriteta (primjerice, klijent ima autoritet za kretanje, a poslužitelj autoritet za dio igre vezan
uz borbu i statistike igrača). Zbog autoriteta danog klijentima varijante hibridne arhitekture
obično su podložnije varanju u odnosu na arhitekturu klijent–poslužitelj [19].
2.2. Protokoli za prijenos podataka
S obzirom da je bitno postići brzu responzivnost igre, podaci koji se trebaju slati kod
višekorisničkih umreženih igara su uglavnom vremenski kritični (engl. time critical) – od
velike je važnosti da stignu do odredišta što je brže moguće. Zbog toga se za prijenos
podataka kod igara uglavnom koristi brzi, ali nepouzdani User Datagram Protocol (skraćeno
UDP). Neke komponente igre mogu tolerirati povremene greške i gubitke u prijenosu
obzirom da će takvo stanje igre ionako ubrzo biti ažurirano nakon sljedećeg pristiglog paketa,
no za neke je komponente igre potreban pouzdaniji prijenos jer gubitak ili krivi redoslijed
paketa može utjecati na rezultate i tijek igre. Za takve slučajeve implementiraju se protokoli
koji su zasnovani na UDP-u, ali sadrže potrebne pouzdane funkcionalnosti [21].
Alternativno rješenje je pouzdani Transmission Control Protocol (skraćeno TCP) koji već
sadrži mehanizme kojima se oporavlja od oštećenja, dupliciranja, gubitaka i krivog
redoslijeda pristizanja paketa, no upravo ga ti mehanizmi čine lošim kandidatom za prijenos
podataka kod višekorisničkih umreženih igara. Primjerice, ako određeni paket ne stigne on se
ponovno šalje, ali tek nakon što istekne vrijeme čekanja. Dok se čeka dolazak ponovno
poslanog paketa ne može se pristupiti podacima ostalih paketa koji su u redoslijedu iza njega.
Do vremena kad izgubljeni paket pristigne informacije koje sadrži su već vrlo vjerojatno
12
zastarjele [21]. Zbog tih problema korištenje TCP-a nije preporučljivo, a razvijatelji koji
inicijalno koriste TCP u svojim igrama kasnije većinom prelaze na korištenje UDP-a. [19].
13
3. Analiza postojeće umrežene višekorisničke igre u
virtualnoj stvarnosti
Za potrebe ovog rada analizirana je arhitektura postojeće umrežene višekorisničke igre u
virtualnoj stvarnosti. Odabrana je igra Serious Sam VR: The Last Hope, koju je razvila
hrvatska tvrtka Croteam, a izdao izdavač Devolver Digital. Serious Sam VR: The Last Hope je
akcijska igra u prvom licu namijenjena platformama Oculus Rift i HTC Vive. Cilj igre je
pobijediti velik broj neprijatelja koji dolaze u valovima, a igrač tijekom igre može razviti
različite sposobnosti i koristiti više tipova oružja. Pri tome je igrač fiksiran na mjestu i ne
može putovati okolišem izvan granica prostora kojim se može kretati na temelju fizičkog
kretanja u stvarnom svijetu [22]. Neprijatelji se pojavljuju na nasumičnim pozicijama na nebu
ili tlu ispred te s bočnih strana igrača. Nakon pojavljivanja neprijatelji nastavljaju hodati,
trčati ili letjeti prema igraču (ovisno o vrsti neprijatelja) te ga napadati, a neki od njih mogu ga
i gađati iz daljine.
Iako je igra inicijalno razvijena za jednog igrača, Croteam je kasnije dodao i opciju
višekorisničke kooperativne igre za dva igrača. Princip igre je isti kao i za samostalnu igru, a
svaki od igrača, koji stoje jedan pokraj drugog u borbi protiv zajedničkih neprijatelja,
predstavljen je ljudskim avatarom ženskog ili muškog spola (po odabiru).
Analiza mrežne implementacije Serious Sam VR: The Last Hope izvršena je na temelju
mrežnog prometa snimljenog alatom za analizu mrežnih protokola Wireshark tijekom kraćeg
igranja igre. Mrežna arhitektura koju je Croteam odabrao za ostvarenje kooperativnog
višekorisničkog načina igre je arhitektura klijent–poslužitelj (opisana u poglavlju 2.1.1), pri
čemu ulogu poslužitelja obavlja jedno od klijentskih računala, a prijenos podataka obavlja se
preko protokola UDP. Međutim, dva korisnička računala koja nisu izravno spojena na Internet
nego se nalaze iza uređaja koji vrše prevođenje mrežnih adresa (engl. Network Address
Translation, skraćeno NAT) ne mogu odmah uspostaviti izravnu UDP komunikaciju, a razlog
tome jest način na koji funkcionira NAT.
14
3.1. Prevođenje mrežnih adresa
NAT se odvija na usmjeritelju (engl. router) koji spaja dvije mreže te prevodi privatne adrese
internetskog protokola (engl. Internet Protocol, skraćeno IP) interne mreže u javnu IP adresu
koju na taj način može dijeliti više uređaja. Pri prolasku kroz usmjeritelj izvorna adresa paketa
koji se šalje s računala mijenja se u javnu adresu, a pri dolasku paketa iz vanjske mreže prema
računalu usmjeritelj odredišnu adresu paketa mijenja u privatnu IP adresu računala [23].
Čvorovi u privatnim mrežama mogu se spajati s drugim čvorovima unutar te privatne mreže, a
najčešće mogu i otvoriti TCP i UDP veze prema dobro poznatim čvorovima s adresama u
globalnom adresnom prostoru. Međutim, najčešće korištena vrsta NAT-a, tzv. tradicionalni
NAT (engl. traditional NAT), dopušta samo sjednice koje je inicirao čvor iz privatne mreže,
odnosno blokira sve pakete koji dolaze iz vanjske mreže ako nisu dio postojeće sjednice koju
je inicirao čvor u privatnoj mreži [24]. Naime, kad čvor u privatnoj mreži započinje sjednicu s
čvorom u javnoj mreži, on mu šalje i broj svojih vrata na koja vanjski čvor treba adresirati
odgovor. NAT će dopustiti prolazak samo onim vanjskim paketima koji su adresirani na ta
vrata (odnosno, vanjskim paketima koji su poslani kao odgovor na sjednicu inicijaliziranu iz
privatne mreže) [23].
Takav način rada odgovara klasičnim mrežnim arhitekturama klijent–poslužitelj gdje se
klijent nalazi u privatnoj mreži, a poslužitelj ima adresu u globalnom adresnom prostoru, ali
radi probleme kad je riječ o arhitekturama gdje se oba računala nalaze u svojim privatnim
mrežama kao što je sustav ravnopravnih sudionika ili klijent–poslužitelj u kojem klijentsko
računalo služi kao poslužitelj (poput Serious Sam VR: The Last Hope). U takvim slučajevima
NAT usmjeritelj jednog računala blokira sjednicu koju je iniciralo drugo računalo u svojoj
privatnoj mreži i obrnuto [24].
3.2. Zaobilaženje NAT-a
Promet između dva računala koja se nalaze unutar privatnih mreža uspostavlja se pomoću
tehnike zaobilaženja NAT-a (engl. NAT traversal) koja se naziva probijanje NAT-a (engl.
NAT punchthrough). Ova metoda koristi vanjski poslužitelj s IP adresom u globalnom
adresnom prostoru s kojim oba računala mogu uspostaviti sjednicu i poslati mu svoju javnu IP
adresu i broj vrata (engl. port) koja žele koristiti u komunikaciji s drugim računalom. Vanjski
poslužitelj služi kao posrednik između računala koji dobiva adresu i broj vrata od jednog
15
računala te ih prosljeđuje drugom i obrnuto, te nakon toga oba računala mogu slati ispravno
adresirane pakete koje NAT neće blokirati [23].
Serious Sam VR: The Last Hope za zaobilaženje NAT-a koristi protokol Session Traversal
Utilities for NAT (skraćeno STUN), koji aplikacijama omogućuje otkrivanje prisutnosti i tipa
NAT-a i vatrozida. Također, STUN poslužitelj na zahtjev otkriva klijentu podatke o njegovoj
javnoj IP adresi i broju vrata koja je NAT alocirao za tokove podataka između aplikacije i
udaljenog računala. Komunikacija između klijenta i STUN poslužitelja vrši se preko UDP-a
(iako se može koristiti i TCP), a za autentikaciju i postizanje sigurne komunikacije koristi se
kriptografski protokol Transport Layer Security (engl. TLS) [25].
3.3. Prijenos podataka između klijenta i poslužitelja
tijekom igre
Klijent i poslužitelj tijekom igre razmjenjuju GiGE Vision Stream Protocol (skraćeno GVSP)
pakete. GVSP je protokol aplikacijskog sloja namijenjen strujanju (engl. streaming)
komprimiranih i nekomprimiranih tokova podataka, baziran na protokolu UDP. Svaki blok
podataka koji se šalju GVSP protokolom sastoji se od tri elementa: paketa koji označava
početak bloka, određenog broja paketa koji prenose podatke (neobrađene podatke, datoteke,
slike...) te paketa koji označava kraj bloka [26]. Grafički prikaz prometa preko UDP-a između
klijenta i poslužitelja, koji je snimljen alatom Wireshark tijekom kraće igre, nalazi se na slici
3-1, pri čemu y os predstavlja broj paketa u sekundi, a x os vrijeme u sekundama. Plavom
linijom prikazana je veća količina prometa koja od poslužitelja teče prema klijentu, a crvenom
manja količina prometa koji teče od klijenta prema poslužitelju.
16
Slika 3-1: UDP promet između klijenta i poslužitelja tijekom igre Serious Sam VR:The Last Hope.
17
4. Idejno rješenje za testnu aplikaciju
Višekorisničke digitalne igre su digitalne igre u kojima istovremeno i u istoj sceni igra više od
jedne osobe. Višekorisničke igre mogu uključivati međusobnu borbu ili suradnju igrača. Za
potrebe ovog rada osmišljena je aplikacija koja omogućuje testiranje dva različita scenarija.
Prvi scenarij funkcionira po principu kooperativne igre (engl. Cooperative Gameplay,
skraćeno co-op). U takvoj vrsti igre igrači surađuju jedan s drugim kako bi ostvarili zajednički
cilj ili pobijedili jednog ili više protivnika kojima upravlja računalo. Načini suradnje između
igrača variraju od igre do igre.
Drugi scenarij funkcionira po principu igrač protiv igrača (engl. Player vs Player, skraćeno
PvP). PvP je vrsta višekorisničke igre u kojoj igrač igra protiv jednog ili više igrača, za
razliku od igara na principu igrač protiv okoliša (engl. Player vs Environment, skraćeno PvE)
u kojima igrači igraju protiv neprijatelja kojima upravlja računalo.
4.1. Scenarij kooperativne igre (co-op scenarij)
Co-op scenarij je zamišljen kao scenarij sporijeg tijeka igre. Od igrača se očekuje rješenje
jednostavnog matematičkog problema u kojemu moraju odabrati dva broja koji zbrojeni daju
zadani rezultat. Nakon što vidi prikaz zadatka svaki igrač mora odabrati jednu od pet pločica s
brojevima. Nakon što su odabrali svoje brojeve igrači se moraju približiti jedan drugome i
prisloniti pločice jednu na drugu, nakon čega se, ukoliko zbroj brojeva na pločicama daje
ispravno rješenje zadatka, prikazuje novi zadatak. Iako scenarij ne zahtjeva brze reakcije
igrača, potrebna je bliska suradnja igrača koji se moraju naći na istom mjestu unutar
virtualnog svijeta i prisloniti objekte jedan na drugi držeći ih u rukama. Kako bi se uspješno
obavio zadatak potrebno je ostvariti istovremenu koordinaciju pokreta između igrača pri čemu
utjecaj mrežnih parametara može loše djelovati na korisničko iskustvo igrača.
4.2. Scenarij igrač protiv igrača (PvP scenarij)
PvP scenarij je zamišljen kao scenarij bržeg tijeka igre. Igrači na raspolaganju imaju objekte
kojima mogu gađati ili udarati jedan drugoga. Oba igrača u početku igre imaju jednaki broj
bodova zdravlja (engl. health points). Kad je igračeva glava pogođena objektom njegov se
18
broj bodova zdravlja umanjuje za iznos štete (engl. damage) koju nanosi objekt. Igrač
preostali iznos bodova zdravlja može pratiti na svom grafičkom indikatoru zdravlja (engl.
health bar). Igrač se ne može kretati po sceni pomoću teleportacije ili neke druge metode
kretanja unutar virtualnog svijeta, ali kako bi izbjegao udarce može se fizički izmaknuti. Na
sceni se također nalaze zakloni iza kojih se igrač može sakriti, od kojih su neki fiksni, a neki
nestaju kad prime pogodak. Scenarij završava kada broj bodova zdravlja jednog igrača padne
ispod nule.
19
5. Korištene tehnologije
Unity [27] je pokretač igara (engl. game engine) odnosno softverski radni okvir (engl.
framework) za izradu računalnih igara namijenjen razvoju digitalnih igara i aplikacija na 27
platformi, uključujući PC, konzole, mobilne platforme i web stranice. Unity se može koristiti
za izradu dvodimenzionalnih i trodimenzionalnih aplikacija te podupire izradu aplikacija za
virtualnu i proširenu stvarnost. Igre se u Unityju izrađuju pomoću intuitivnog sučelja na
principu povuci-i-ispusti (drag-and-drop) te pisanjem skripti u programskom jeziku C#.
Unity sadrži brojne funkcionalnosti kao što su primjerice mapiranja sjena, neravnina,
refleksija i paralaksi, kompresije tekstura i iscrtavanje na teksture te podržava izradu
animacija, pisanje vlastitih programa za sjenčanje, ubacivanje oglasa i analitike u igre, izradu
višekorisničkih igara itd. Za izradu aplikacije korišten je Unity 2017.3.0f3 Personal.
Microsoft Visual Studio [28] je integrirano razvojno okruženje (engl. integrated
development environment, skraćeno IDE) tvrtke Microsoft koje se koristi za izradu računalnih
programa, web stranica i servisa te mobilnih i web aplikacija. Visual Studio podržava više
različitih programskih jezika pri čemu su neki od njih ugrađeni (npr. C, C++, C#, HTML,
CSS), a za preostale (npr. Python, Ruby) je potrebno koristiti priključke (engl. plug-in).
Visual Studio sadrži uređivač koda (engl. code editor) koji podržava isticanje sintakse (engl.
syntax highlighting) i kompletiranje koda koristeći IntelliSense komponentu za kompletiranje
koda. Visual Studio također sadrži program za pronalazak pogrešaka (engl. debugger) te
vizualne dizajnere kao što su Windows Forms Designer, Class Designer, Data Designer i
slično. Za pisanje i izmjenu skripti korišten je Microsoft Visual Studio Community 2015.
SteamVR Plugin [29] je set razvojnih alata (engl. software development kit, skraćeno SDK)
koji razvijateljima VR aplikacija omogućuje jedinstveno sučelje za rad sa svim većim VR
sustavima. SteamVR Plugin omogućuje nadzor pozicije u fizičkom svijetu, pristup praćenim
kontrolerima, prihvaćanje kontrola te iscrtavanje modela kontrolera u virtualnom svijetu, kao i
testiranje aplikacije u virtualnoj stvarnosti koristeći Unityjev režim igre (engl. Play Mode).
VR Toolkit (skraćeno VRTK) [30] je programski alat za brz razvoj VR aplikacija u Unityju.
VRTK se sastoji od kolekcije skripti i koncepata koja rješava probleme kao što su: kretanje
unutar virtualnog prostora, interakcija s Unity elementima korisničkog sučelja,
20
implementacija pokazivača i izbornika, fizikalno ponašanje tijela unutar virtualnog prostora,
doticanje i rukovanje objektima, korištenje objekata kao što su tipke, vrata, ladice i slično te
mnoge druge funkcionalnosti.
Photon Unity Networking (skraćeno PUN) [31] je framework za razvoj višekorisničkih igara
i aplikacija u stvarnom vremenu, na više platformi. Za udomljavanje (engl. hosting) koristi se
Photonov oblak (engl. Photon Cloud) čiji se poslužitelji nalaze u svim većim regijama svijeta
u svrhu minimizacije kašnjenja. Aplikacije su zasnovane na modelu klijent–poslužitelj. PUN
podržava izradu igara zasnovanih na principu soba (engl. rooms) na koje se korisnici mogu
spojiti vlastitim odabirom, pomoću parametriziranih pretraga ili nasumično. Igre razvijene
pomoću PUN-a mogu biti različitih žanrova. Za izradu aplikacije korištena je besplatna
verzija Photon Unity Networkinga.
PlayoVR [32] je manji demo projekt u Unityju koji koristi VR Toolkit za interakciju s
objektima te Photon Unity Networking za umrežavanje. PlayoVR sadrži skripte koje
omogućuju sinkronizaciju stanja (tj. serijalizaciju podataka vezanih uz stanje) korisničkog
avatara i objekata kojima igrač rukuje unutar igre. PlayoVR sadrži i skripte koje služe za
sinkronizaciju stanja zona hvatanja i ispuštanja. PlayoVR skripte korištene u ovom radu
objavljene su pod MIT licencom.
Oculus Rift [33] je headset za virtualnu stvarnost koji sadrži Pentile OLED ekran s
rezolucijom 1080 x 1200 piksela po oku, frekvencijom osvježavanja slike 90 Hz i poljem
pogleda (engl. field of view) od 110 stupnjeva te integrirane slušalice. Pozicija i rotacija
headseta prate se pomoću sustava za pozicijsko praćenje Constellation koji se sastoji od
infracrvenih LED svjetala integriranih u headset te jednog ili više stacionarnih infracrvenih
senzora koji ih prate. Oculus Rift headset može se koristiti uz Oculus Touch, sustav
kontrolera pokreta. Oculus Touch se sastoji od dva kontrolera od kojih svaki sadrži analogni
štapić (engl. analog stick), tri tipke i dva prekidača (engl. trigger). Za izradu i testiranje
aplikacije korišten je Oculus Rift headset uz dva kontrolera i tri stacionarna infracrvena
senzora postavljena na visinu stola, jedan nasuprot preostala dva.
HTC Vive [34] je headset za virtualnu stvarnost koji sadrži dva ekrana s rezolucijom ekrana
1080 x 1200 piksela po oku, frekvencijom osvježavanja slike 90 Hz i poljem pogleda od 110
stupnjeva. HTC Vive headset također sadrži prednju kameru koja omogućuje korisniku da
vidi svoj fizički okoliš bez skidanja headseta te koja prepoznaje objekte u korisnikovom
21
okolišu, što omogućuje korištenje sustava za sigurnost Chaperone koji se aktivira kada je
korisnik previše blizu preprekama. Headset se može koristiti sa odvojenim slušalicama ili
slušalicama integriranim u dodatak headsetu (Vive Deluxe Audio Strap) koji se može
odvojeno kupiti. Pozicija i rotacija headseta prate se pomoću akcelerometra, žiroskopa i
infracrvenih senzora ugrađenih u headset koji primaju infracrvene pulseve koje emitira sustav
za praćenje Lighthouse, sastavljen od dvije bazne stanice. Uz HTC Vive dolaze i dva
kontrolera od kojih svaki sadrži dodirnu pločicu (engl. track pad), bočne tipke za stisak (engl.
grip buttons) i prekidač (engl. trigger). Za izradu i testiranje aplikacije korišten je HTC Vive
headset uz dvije bazne stanice i dva kontrolera.
22
6. Umrežavanje testne aplikacije
6.1. Korištena mrežna arhitektura
Umreženje testne aplikacije postignuto je pomoću besplatnog paketa Photon Unity
Networking uz odabranu opciju korištenja Photonovog oblaka (engl. Photon Cloud) – oblaka
poslužitelja namijenjenih višekorisničkim igrama. Poslužitelji Photonovog oblaka smješteni
su na nekoliko različitih lokacija u svijetu kako bi se omogućila organizacija igrača po
regijama i time smanjio utjecaj mrežnih problema uzrokovanih prevelikom udaljenošću
između igrača [35].
Slika 6-1: Arhitektura Photonovog oblaka.
Arhitektura Photonovog oblaka prikazana je na slici 6-1. S obzirom da sve igre koje koriste
uslugu Photonovog oblaka ujedno koriste iste poslužitelje svakoj je igri dodijeljen jedinstveni
aplikacijski identifikator AppId. Prilikom povezivanja na Photonov oblak klijent prvo
uspostavlja komunikaciju (s Photonovim imenskim poslužiteljem (engl. Name Server), koji
provjerava klijentov aplikacijski identifikator i na temelju klijentove odabrane regije
prosljeđuje klijenta na odgovarajući glavni poslužitelj (engl. Master Server), koji služi kao
23
središte za skup regionalnih poslužitelja [35]. Glavni poslužitelj brine se za raspoložive sobe,
ujednačavanje opterećenja (engl. load-balancing) unutar oblaka i prosljeđivanje klijenata na
odgovarajuće poslužitelje igre (engl. Game Server) [36].
Komunikacija između klijenata odvija se preko poslužitelja u Photonovom oblaku. S obzirom
da korisnici koji koriste Photonov oblak ne mogu pisati proizvoljni kod na poslužitelju, jedan
od klijenata ima ulogu glavnog klijenta (engl. Master Client). Master Client je posebni klijent
koji je odgovoran za logiku koju treba izvesti samo jedan klijent u sobi, kao što je početak
igre kada su svi klijenti spremni ili vlasništvo nad scenskim objektima. Pritom je Master
Client svejedno obični klijent, a ne klijentsko računalo koje ujedno služi kao poslužitelj.
Uloga Master Clienta dodjeljuje se automatski, a ako trenutni Master Client izađe iz sobe
uloga se automatski prebacuje na nekog od preostalih klijenata [37].
Besplatna verzija PUN-a (korištena u implementaciji testne aplikacije) podržava korištenje
prokola UDP i TCP, a za implementaciju je odabran UDP protokol. Kako bi se ostvario
pouzdani prijenos podataka u pravilnom redoslijedu povrh nepouzdanog UDP-a PUN koristi
protokol eNet [38].
6.2. Igra zasnovana na sobama
Photon Unity Networking prilagođen je principu igara zasnovanih na sobama (engl. room-
based games), odnosno igrama kod kojih se igrači povezuju u grupacije s određenim brojem
članova. Igrač može komunicirati s ostalim igračima jedino ako se nalazi u sobi. Igrači unutar
sobe odvojeni su od ostalih igrača koji u isto vrijeme igraju istu igru u drugim sobama – svaki
igrač koji se nalazi unutar sobe ne može komunicirati s nikim tko se ne nalazi u njegovoj sobi
[35].
Klijent može stvoriti novu sobu ili se pridružiti postojećoj. Glavni poslužitelj sadrži sve
informacije o postojećim sobama, a kako bi se sobe razlikovale jedna od druge njihovo se ime
koristi kao identifikator. Postoji nekoliko načina odabira kojoj će se postojećoj sobi pridružiti
klijent. Primjerice, klijent može sam odabrati sobu iz liste raspoloživih soba, pri čemu je soba
raspoloživa ako nije zatvorena ili puna. Igrač također može ući u sobu u kojoj se nalazi njegov
prijatelj. Postoji i opcija da se odabir odgovarajuće sobe prepusti glavnom poslužitelju, koji
korisnika može smjestiti u nasumično odabranu sobu ili sobu odabranu na temelju
proizvoljnih parametara [39].
24
Sobe su organizirane u predsoblja (engl. lobbies). Predsoblja također imaju svoj identifikator:
ime i tip. Kad se pridruže predsoblju klijenti dobivaju listu soba tog predsoblja, ali ne mogu
komunicirati s ostalim klijentima u predsoblju [36]. S obzirom da su aplikacije napravljene u
svrhu ovog rada i namijenjene samo testiranju, a ne stvarnom korištenju, funkcionalnosti
predsoblja nisu korištene, već se pri pokretanju aplikacije automatski ulazi u unaprijed zadanu
sobu.
6.2.1. Komunikacija unutar sobe
Slanje poruka ostalim klijentima u sobi može se obaviti putem sinkronizacije stanja (engl.
State Synchronisation) ili poziva udaljene procedure (engl. Remote Procedure Call, skraćeno
RPC). Sinkronizacija stanja koristi se u situacijama kada je potrebno konstantno osvježavati
vrijednosti preko mreže. Sinkronizacija stanja može se obaviti na objektima igre (engl. Game
Objects) koji na sebi imaju Photonov pogled koji je namješten da promatra (engl. observe)
komponentu u kojoj je obavljena serijalizacija podataka koje je potrebno sinkronizirati.
Serijalizacija podataka obavlja se putem funkcije OnPhotonSerializeView koja se automatski
poziva svaki put kad šalje ili prima podatke pisanjem u tok podataka, odnosno čitanjem s
njega [40].
RPC-ovi su pozivi metode na udaljenom klijentu unutar iste sobe te se koriste za akcije koje
se događaju s vremena na vrijeme. Metoda koja se treba moći pozvati kao RPC mora biti
smještena unutar skripte koja se nalazi na objektu igre koji sadrži komponentu Photonovog
pogleda (engl. Photon View) [41]. Kada se metoda pozove kao RPC ciljani klijenti ju
izvršavaju na umreženom objektu igre kojem pripada odgovarajući Photonov pogled. Odabir
ciljanih klijenata koji će izvršiti RPC bira se pomoću Photonovih meta (engl. Photon Targets)
tako da se mogu odabrati svi (engl. All) ili ostali (engl. Others) klijenti (izuzev klijenta koji je
pozvao RPC). Ako se koristi opcija s međupohranom (engl. Buffered) pozvani RPC ostat će
zapamćen na poslužitelju kako bi ga izvršili i klijenti koji će se tek kasnije pridružiti u igru.
Ako se koristi opcija putem poslužitelja (engl. Via Server) klijent koji je pozvao RPC neće
moći izvršiti RPC odmah, nego tek nakon što dobije obavijest o RPC-u od poslužitelja čime
se stvara ulazno kašnjenje [42].
PUN također sadrži funkcionalnost događaja (engl. Events) koji se mogu slati neovisno o
tome nalaze li se na umreženom objektu s Photonovim pogledom na sebi ili ne. Unutar
događaja može se slati bilo koja vrsta podatka koju PUN može serijalizirati, a kako bi drugi
25
klijent mogao primiti događaj potrebna je implementacija funkcije povratnog poziva (engl.
callback function) za događaj [42].
6.2.2. Photonov pogled
Photon View je komponenta postavljena na objekte igre i predloške (engl. prefabs) koja služi
za slanje RPC-ova i sinkronizaciju stanja. Photon View sadrži polje promatranja (engl.
Observe) namijenjeno komponenti koju želimo pratiti (primjerice položaj nekog objekta ili
skriptu unutar koje se vrši sinkronizacija stanja). Polje opcije promatranja (engl. Observe
Option) služi za odabir opcija slanja ažuriranja. Nepouzdana (engl. Unreliable) ažuriranja
konstantno se šalju, a u slučaju gubitka izgubljene će podatke nadoknaditi sljedeće ažuriranje
koje stigne. Ažuriranja koja su nepouzdana prilikom promjene (engl. Unreliable on Change)
šalju se samo kad se vrijednosti mijenjaju, a kada se prestanu mijenjati pouzdano se šalje
jedno ažuriranje i potom se daljnja nepouzdana ažuriranja prestaju slati do sljedeće promjene.
Kod osvježenja koja su pouzdana i funkcioniraju po principu delta kompresije (engl. Reliable
Delta Compressed) ne šalju se nikakva ažuriranja ukoliko ne dolazi do promjena vrijednosti, a
pri promjenama se šalju pouzdana ažuriranja. Odabrana opcija isključenih ažuriranja (engl.
Off) još uvijek dopušta slanje RPC-ova za taj Photon View [41].
6.2.3. Vlasništvo, instanciranje i prijenos vlasništva umreženih
objekata
Kontrola objekata unutar sobe funkcionira po principu vlasništva (engl. Ownership). Pri tome
svaki objekt može kontrolirati samo jedan klijent, koji piše u tok podataka tog objekta, dok
ostali klijenti mogu samo osvježavati svoja stanja na temelju informacija koje su pročitali s
toka podataka. Ovisno o postavkama vlasništvo objekta može se prenijeti na drugog klijenta
[43].
Kako bi se objekt mogao sinkronizirati preko mreže mora na sebi imati komponentu Photon
View. Photon View može se postaviti na scenske objekte (engl. Scene Objects), odnosno
objekte koji su postavljeni u scenu u samom početku te koje nitko nije instancirao tijekom
igre. U tom slučaju vlasništvo nad objektom ima Master Client, ali ga može prebaciti na
drugog igrača [44].
Objekte koji nisu u sceni u samom početku potrebno je instancirati metodom
PhotonNetwork.Instantiate() uz odgovarajuće argumente. Kako bi se objekt mogao
26
instancirati potrebno je pohraniti njegov predložak, na koji je postavljena komponenta Photon
View, u direktorij resursa, odnosno direktorij imena Resources [44]. Takav objekt u vlasništvu
je klijenta koji ga je instancirao. Postavke eventualnog prijenosa vlasništva nalaze se unutar
komponente Photon View. Ako se odabere opcija fiksnog vlasništva (engl. Fixed) klijent koji
je instancirao objekt ostaje njegov trajni vlasnik. Opcija preuzimanja vlasništva (engl.
Takeover) omogućava da bilo koji klijent preuzme vlasništvo nad objektom, a opcija zahtjeva
(engl. Request) zahtjeva dozvolu trenutnog vlasnika prije prijenosa vlasništva nad objektom.
Ako vlasnik objekta ode iz sobe vlasništvo nad objektom prebacuje se na Master Clienta [43].
Uz vlasnika svaki objekt ima i životni vijek (engl. lifetime) [43]. Životni vijek objekta traje
dokle god je u sobi klijent koji ga je instancirao (čak i ako je u međuvremenu promijenio
vlasnika) te ga ostali klijenti unište kada on izađe iz sobe ako je uključena opcija automatskog
čišćenja igračevih objekata (engl. Auto Clean Up Player Objects). Objekti se također mogu
instancirati kao scenski objekti, tako da ih Master Client instancira metodom
PhotonNetwork.InstantiateSceneObject() [44]. U tom slučaju objekt ostaje u sobi sve dok ima
igrača u njoj (obzirom da se uloga Master Clienta prebacuje na drugog igrača ako prethodni
Master Client napusti igru) [43].
6.3. Mrežna simulacija
Photon sadrži mogućnost simulacije mrežnih problema kako bi se moglo testirati ponašanje
aplikacije u lošijim uvjetima. Kako bi se obavila simulacija potrebno je postaviti komponentu
PhotonNetSimSettingsGui na neki od objekata u sceni. Nakon pokretanja igre na zaslonu
računala prikazuje se prozor s postavkama mrežne simulacije (prikazan na slici 6-2) koji
prikazuje vrijeme obilaska (engl. round-trip time, skraćeno Rtt) te omogućuje paljenje i
gašenje simulacije (okvir za izbor Sim), dodavanje fiksnog kašnjenja u milisekundama svim
ulaznim i izlaznim porukama (klizač Lag), dodavanje kolebanja kašnjenja (engl. jitter) do
odabranog broja milisekundi (klizač Jit) i odabir postotka paketa koji će se izgubiti (klizač
Loss) [45].
27
Slika 6-2: Photonov prozor s postavkama mrežne simulacije.
28
7. Izrada scenarija kooperativne igre
7.1. Dizajn scene
Slika 7-1: Scena kooperativne igre.
Scena (prikazana na slici 7-1) je sastavljena od kombinacije preuzetih besplatnih 3D modela i
3D modela posebno napravljenih za potrebe testne aplikacije. Scenarij je smješten na komad
zelenog terena na kojem se nalazi manja količina drveća. Objekti koje igrači trebaju koristiti
smješteni su unutar prostora u obliku kvadrata ograđenog drvenom ogradom.
Slika 7-2: Štand u sceni kooperativne igre.
29
Dva štanda različitih boja, žute i ljubičaste, smješteni su uz dvije suprotne strane ograđenog
prostora. Na svakom štandu nalazi se pet različitih pločica s brojevima od jedan do pet.
Pločice su iste boje kao i štand na kojem se nalaze. Kad igrač podigne jednu od njih broj
pločice koju igrač ima u ruci prikazuje se na ploči koja se nalazi na tendi štanda. Prikaz
jednog od štandova nalazi se na slici 7-2. Između štandova nalazi se školska ploča (prikazana
na slici 7-3) na kojoj se prikazuje jednostavni matematički zadatak koji igrači moraju rješiti.
Slika 7-3: Školska ploča s prikazom matematičkog zadatka u sceni kooperativne igre.
Kako bi se ostvarilo kretanje, korisnička interakcija i tijek igre na objekte unutar scene
postavljene su skripte koje reguliraju njihovo ponašanje. Bitniji objekti i skripte postavljene
na njih prikazani su na slici 7-4, a pobliže objašnjeni u poglavljima 7.2 i 7.3.
30
Slika 7-4: Prikaz bitnijih objekata u sceni kooperativne igre i skripti postavljenih na njih.
7.2. Kretanje i korisnička interakcija
Za kretanje i korisničku interakciju s okolišem koriste se skripte i predlošci iz paketa VRTK
uz skripte i predloške iz projekta PlayoVR. Kako bi se igrač stvorio u sceni potrebno je spojiti
se u sobu. Unutar scene nalazi se objekt NetworkManager koji na sebi sadrži PlayoVR skripte
MyNetworkManager i PlayerManager, modificirane za potrebe ovog rada, te Photonovu
skriptu PhotonLagSimulationGui, objašnjenu u potpoglavlju 6.3. Skripta MyNetworkManager
odgovorna je za povezivanje s Photonovim glavnim poslužiteljem te za pridruživanje
odgovarajućoj sobi. Prvi korisnik koji pokrene igru kreirat će novu sobu (kapaciteta dva
korisnika) imena „CoopScene“, a drugi korisnik će joj se pridružiti na temelju njezina imena.
31
Slika 7-5: Avatar igrača.
Nakon uspješnog pridruživanja sobi slijedi instanciranje korisnikova avatara na temelju
njegova imena pomoću skripte PlayerManager. Predložak korisničkog avatara zove se
„CoopAvatar“ i nalazi se u direktoriju Resources. Avatar (prikazan na slici 7-5) se sastoji od
tri sfere – velika sfera za glavu i dvije manje za ruke. Velika bijela sfera koja predstavlja
glavu ima na sebi crni kvadar koji predstavlja VR naočale kako bi suigrač mogao vidjeti u
kojem smjeru gleda korisnik. Praćenje položaja korisnika, odnosno HMD-a i kontrolera, u
prostoru ostvaruje se pomoću opreme kamere (engl. CameraRig) iz paketa SteamVR. Nakon
instanciranja avatar se povezuje i sinkronizira s položajem opreme kamere korisnika te se
skupa s njom postavlja na početnu poziciju u sceni pomoću PlayoVR skripti
SetupPlayerAvatar i AvatarCameraRigSync. Kako bi se pozicija, orijentacija i rotacija
korisničkog avatara mogle prenositi preko mreže svaki od njegovih dijelova (glava, obje ruke)
mora na sebi imati skriptu PhotonView, koja je namještena tako da prati serijalizaciju stanja
koja se provodi u PlayoVR skripti NetworkObject.
U scenu je potrebno postaviti odabrane VRTK skripte kako bi se ostvarila što prirodnija
prisutnost, ponašanje i kretanje igrača u virtualnoj stvarnosti. Skripta VRTK_BodyPhysics
brine se ostvarenje prisutnost korisnikovog „nepostojećeg“ tijela unutar virtualnog svijeta
tako da omogućuje reakcije tijela na fiziku, ostvaruje fizikalne interakcije s okolišem i
prevenira prolaženje kroz zidove.
32
Igrač se kreće prostorom pomoću teleportacije. Pomoću skripti VRTK_Pointer i
VRTK_BezierPointer ostvaruje se funkcionalnost stvaranja pokazivača koji se pojavljuje na
pritisak odgovarajućeg gumba na kontroleru. Pritom je na kontrolere potrebno postaviti
skriptu VRTK_ControllerEvents koja služi za registraciju pritisaka na tipke. Pokazivač je u
obliku parabole koja se proteže od vrha kontrolera do tla, pri čemu se na sjecištu parabole i
površine tla nalazi bazni pokazivač. Skripta VRTK_BasicTeleport koristi se kako bi se na
puštanje gumba korisnik teleportirao na poziciju određenu položajem baznog pokazivača.
Pokazivač i bazni pokazivač zelene su boje, ali mijenjaju boju u crvenu kada se bazni
pokazivač nalazi na poziciji na koju se nije moguće teleportirati.
Objekti koje igrač može koristiti su pločice s brojevima. Pločice se nalaze uredno posložene
unutar zona hvatanja i ispuštanja (engl. snap drop zones) koje se nalaze na štandu. Korisnik
može dohvatiti pločicu i izvući je iz njezine zone, pri čemu se ona poveća kako bi omogućila
lakše korištenje. Kako bi korisnik mogao uzeti i nositi pločicu potrebno je koristiti nekoliko
različitih skripti. Na kontrolere je, uz već spomenutu skriptu VRTK_ControllerEvents,
potrebno postaviti skripte VRTK_InteractTouch, kako bi bilo moguće registrirati da je
kontroler ušao u zonu ili dotaknuo predmet, te VRTK_InteractGrab, kako bi korisnik mogao
podići, nositi i ispustiti predmet. Na pločicu je potrebno postaviti skriptu
VRTK_InteractableObject koja omogućuje interakciju s predmetom i namještanje parametara
vezanih uz način interakcije. Pomoću skripte VRTK_InteractableObject odabrano je da se za
interakciju s pločicom može koristiti samo jedna ruka. Također, nakon što je jednom uzeta,
pločica se ne može ispustiti bilo gdje već samo natrag u njezinu zonu kako je korisnici ne bi
slučajno ispustili i onda morali podizati s poda, što se prilikom razvoja aplikacije pokazalo
nepraktičnim. Kao i korisnički avatar, pločice na sebi imaju skripte PhotonView i
NetworkObject kako bi se njihovo kretanje moglo sinkronizirati preko mreže. Kako bi se
vlasništvo nad pločicom prebacilo na korisnika koji ju drži u rukama koristi se PlayoVR
skripta NetworkGrabManager.
Nakon što upotrijebi pločicu kako bi riješio zadatak korisnik ju potom može vratiti na mjesto
tako da je ispusti unutar njezine zone, pri čemu se ona smanji na početnu veličinu, pomakne
nazad i „uhvati“ na svoje početno mjesto. Nakon ispuštanja pločice korisnik može uzeti
sljedeću. Za funkcionalnost zona hvatanja i ispuštanja koristi se skripta VRTK_SnapDropZone
u kombinaciji sa skriptom VRTK_OutlineObjectCopyHighlighter, koja služi kako bi se stvorio
obris pločice kao vizualna indikacija korisniku gdje je treba ispustiti. Kako bi se hvatanje
33
objekta na pravo mjesto te njegovo povećavanje i smanjivanje u ulasku i izlasku iz zone
moglo ispravno sinkronizirati preko mreže potrebno je na objekt (u ovom slučaju pločicu)
postaviti PlayoVR skriptu NetworkSnapManager.
7.3. Ostvarenje mehanike igre
Cilj kooperativnog scenarija je suradnja dvoje igrača u svrhu zajedničkog rješavanja
jednostavnog matematičkog problema koji se svodi na pronalazak i spajanje dvije pločice s
brojevima koji zbrojeni daju zadani rezultat. Zadatak koji je potrebno rješiti ispisuje se na
ploči.
Nakon što igrači pročitaju zadatak svaki odlazi do jednog od štandova s pločicama. Kad igrač
odabere jednu od pločica njena zona hvatanja i ispuštanja registrira da je pločica podignuta i
pomoću skripte SnapDropZoneController javlja skripti StandBoardController o kojem broju
se radi. Skripta StandBoardController nalazi se na maloj ploči koja se nalazi na vrhu štanda te
prikazuje broj koji je igrač odabrao kako bi njegov suigrač s drugog kraja terena mogao na
temelju te informacije odabrati svoj broj bez da se igrači moraju eksplicitno dogovarati.
Skripta NumberController upravlja ponašanjem pločica. Kada pločica s žutog štanda dotakne
pločicu s ljubičastog ispituje se je li njihov zbroj jednak zadanom rezultatu te se točnost
dojavlja skripti BlackboardController koja se nalazi na objektu školske ploče. Boja pločice
mijenja se u zelenu ako je zbroj jednak rezultatu ili crvenu ako nije.
Ponašanje školske ploče regulirano je skriptom naziva BlackboardController. Metoda
ShowIfCorrectBlackboard() na temelju točnosti spojenih pločica poziva RPC metodu koja će
promijeniti boju teksta na ploči u zelenu ako je zadatak ispravno riješen ili crvenu ako nije.
Metoda ChangeBlackboardValueToNewOne u slučaju ispravno spojenih pločica odabire novi
nasumični broj između 2 i 10 kao rezultat sljedećeg zadatka te se tekst na ploči (i njegova
boja) osvježava.
34
8. Izrada scenarija igrač protiv igrača
8.1. Dizajn scene
Slika 8-1: Scena igrač protiv igrača.
Kao i scena kooperativne igre, scena igrač protiv igrača (prikazana na slici 8-1) je sastavljena
od kombinacije preuzetih besplatnih 3D modela i 3D modela posebno napravljenih za potrebe
testne aplikacije te je scenarij smješten na komad zelenog terena na kojem se nalazi manja
količina drveća. Pri tome se objekti koje igrači trebaju koristiti nalaze unutar prostora u obliku
kvadrata ograđenog drvenom ogradom.
Slika 8-2: Stolovi u sceni igrač protiv igrača.
35
Svaki igrač pozicioniran je tako da se nalazi u blizini dva stola, prikazana na slici 8-2. Na
jednom od njih nalaze se drveni sanduci iza kojih se igrač može sakriti. Na drugom se nalazi
objekt unutar kojeg se stvaraju novi projektili, u obliku voća, kojima igrač može gađati
suparnika.
Na objekte unutar scene postavljene su skripte koje reguliraju njihovo ponašanje kako bi se
ostvarilo kretanje, korisnička interakcija i tijek igre. Bitniji objekti i skripte postavljene na
njih prikazani su na slici 8-3, a pobliže objašnjeni u poglavljima 8.2 i 8.3.
Slika 8-3: Prikaz bitnijih objekata u sceni igrač protiv igrača i skripti postavljenih na njih.
8.2. Kretanje i korisnička interakcija
Za kretanje i korisničku interakciju s okolišem koriste se skripte i predlošci iz paketa VRTK
uz skripte i predloške iz projekta PlayoVR. Kao i kod scenarija kooperativne igre za
pridruživanje sobi koriste se skripte MyNetworkManager i PlayerManager, ali kao
identifikator sobe koristi se ime „FightScene“. Avatar koji se koristi u ovom scenariju zove se
„PlayerAvatar“ i nalazi se u direktoriju Resources. „PlayerAvatar“ izgleda isto kao
36
„CoopAvatar“, a sadrži i iste skripte – također se povezuje s opremom kamere pomoću skripti
SetupPlayerAvatar i AvatarCameraRigSync te se njegovo kretanje sinkronizira skriptama
PhotonView i NetworkObject. Za razliku od „CoopAvatara“, „PlayerAvatar“ sadrži dodatnu
skriptu PlayerHealth, pobliže objašnjenu u potpoglavlju 8.3.
Za ostvarenje prisutnosti tijela igrača koristi se skripta VRTK_BodyPhysics. Za razliku od
scenarija kooperativne igre, u scenariju igrač protiv igrača ne postoji mogućnost kretanja
prostorom pomoću teleportacije. Razlog zbog kojeg je izbačena mogućnost teleportacije je
sam princip igre – kada bi se igrač mogao slobodno teleportirati po cijelom terenu bilo bi
prelagano izmaknuti se projektilu drugog igrača, pa čak i potpuno izaći izvan njegova
dometa.Umjesto toga korisnik se može kretati samo onoliko koliko se može pomaknuti
fizički, unutar prostora praćenog senzorima sustava za virtualnu stvarnost. Iako je bez
teleportacije oboje igrača fiksirano na mali dio prostora kojim se mogu kretati, projektil se
može izbjeći pravovremenim saginjanjem ili pomakom u stranu. Posebna pažnja tijekom
razvoja aplikacije posvećena je odabiru točke u kojoj se instancira igrač unutar igre kako bi
mu objekt u kojem se stvaraju projektili bio nadohvat ruke.
Objekti koje igrač može koristiti su projektili u obliku voća. Za razliku od kooperativnog
scenarija projektili nisu unaprijed postavljeni u scenu nego se po potrebi instanciraju tijekom
igre na temelju predložaka pohranjenih unutar direktorija Resources (logika vezana uz
instanciranje projektila pobliže je opisana u poglavlju 8.3). Svaki igrač ima pristup svojem
objektu za stvaranje projektila unutar kojeg se nalazi zona hvatanja i ispuštanja u koju se
projektil automatski postavlja nakon instanciranja kako bi ga igrač lako mogao dohvatiti.
Funkcionalnost zone hvatanja i ispuštanja ostvaruje se pomoću skripti VRTK_SnapDropZone
i NetworkSnapManager.
Kako bi igrač mogao rukovati projektilima na kontrolere su postavljene skripte
VRTK_ControllerEvents, VRTK_InteractTouch i VRTK_InteractGrab, a na predloške
projektila skripta VRTK_InteractableObject. Za razliku od scenarija kooperativne igre,
postavke VRTK_InteractableObject su takve da igrač može uzeti projektil s bilo kojom
rukom, držati ga tako da drži pritisnutim odgovarajući gumb na kontroleru ga ispustiti bilo
gdje (ne samo unutar zone hvatanja i ispuštanja). Za sinkronizaciju kretanja projektila koriste
se skripte PhotonView i NetworkObject, a za prebacivanje vlasništva NetworkGrabManager.
37
8.3. Ostvarenje mehanike igre
Cilj scenarija igrač protiv igrača je poraziti suparnika. Svaki pogodak objektom koji je
označen kao projektil umanjuje broj bodova zdravlja pogođenog igrača. Igrač je poražen kada
njegov broj bodova zdravlja padne na nulu.
Svi predlošci u obliku voća na sebi imaju skriptu FruitProjectile i označeni su kao projektili.
Za instanciranje voća brine se skripta PrinterController. Kada igrač podigne projektil mijenja
se njegovo vlasništvo, a kada ga baci skripta FruitProjectile registrira ispuštanje iz ruke i
aktivira efekt traga koji ostaje za njim dok leti zrakom. Efekt traga napravljen je oblikovanjem
sustava čestica. Kada skripta registrira da je projektil bačen u pod ili u sanduk ona poziva
metodu za samouništenje, DestroyMyself(), koja instancira efekt uništavanja voća i uništava
projektil. Efekt uništavanja specifičan je za svaku vrstu voća, a napravljen je oblikovanjem
sustava čestica te simulira raspadanje mekog voća pri jakom udarcu u tvrdi predmet. Ako je
pogođen sanduk, koji služi kao zaklon iza kojeg se igrač može sakriti, tada se pokreće i
njegovo uništenje. Metoda DestroyMyself() pokreće se i kada projektil pogodi igračevu glavu.
Svaki igrač ima na sebi skriptu PlayerHealth koja registrira ako je igrač pogođen u glavu i na
temelju toga poziva funkciju GetDamaged() koja smanjuje broj bodova zdravlja, pokreće
zacrnjivanje ekrana i provjerava je li broj bodova zdravlja igrača još uvijek veći od nule. Pri
tome se poziva funkcija HealthChange() iz skripte RadialHealthBar koja se nalazi na
kružnom grafičkom indikatoru zdravlja na igračevoj ruci. Funkcija HealthChange() smanjuje
popunjenost indikatora zdravlja te mijenja njegovu boju ako je igračev broj bodova zdravlja
pao ispod propisanih vrijednosti. Ako je nakon izvršavanja funkcije GetDamaged() broj
bodova zdravlja još uvijek veći od nule korisniku se vraća prikaz scene. U protivnom ekran
ostaje zacrnjen, a drugom se igraču šalje RPC o igračevom porazu, te se unutar njegove
lokalne igre na mjestu poraženog igrača aktivira animacija eksplozije. Nakon toga aplikacija
završava s radom.
38
9. Metodologija ispitivanja
Cilj provedenog ispitivanja bio je istražiti kako mrežno kašnjenje utječe na subjektivne i
objektivne metrike iskustvene kvalitete kod višekorisničkih igara u virtualnoj stvarnosti.
Tijekom ispitivanja nije se provjeravao utjecaj gubitaka paketa na iskustvenu kvalitetu jer je
prethodno isprobavanje igre sa simuliranim gubitkom paketa od 1% i 2% pokazalo da nema
primjetne razlike. Ispitivanje je provedeno nad osobama različitih razina igraćeg iskustva,
kako bi se istražilo postoji li razlika u ocjeni iskustvene kvalitete između početnika i
naprednih igrača. Dosadašnjim istraživanjima koja su ispitivala razlike u toleranciji kašnjenja
između početnih i naprednih igrača pokazalo se da napredni igrači isti iznos kašnjenja
doživljavaju izraženijim nego što ga doživljavaju početnici [46], ali i da postoji pozitivna
korelacija između trajanja sjednice igre i vještine igrača, odnosno da napredniji igrači odabiru
dulje igrati igru pri uvjetima s izraženim mrežnim kašnjenjem u odnosu na manje vješte
igrače [47].
Za potrebe ispitivanja odabrana je igra Serious Sam VR: The Last Hope, čija su mrežna
arhitektura i korišteni mrežni protokoli analizirani u poglavlju 3. Za testiranje je korištena
mapa Pharaoh's Dream, prikazana na slici 9-1. Uz činjenicu da je napravljena za korištenje u
virtualnoj stvarnosti, Serious Sam VR: The Last Hope je primjer akcijske igre u prvom licu u
kojoj se igrači bore gađanjem protivnika, što je žanr koji se pokazao osobito osjetljivim na
utjecaj mrežnog kašnjenja [48]. S obzirom da je arhitektura igre klijent–poslužitelj, gdje jedno
od korisničkih računala služi kao poslužitelj, ispitivanje utjecaja mrežnih parametara na
korisničko iskustvo izvedeno je samo na temelju iskustva igre na klijentu.
39
Slika 9-1: Snimka zaslona tijekom igranja igre Serious Sam VR: The Last Hope (mapa Pharaoh's
Dream).
Provođenje ispitivanja izvodilo se na dva računala u laboratorijskom okružju, uz korištenje
dva različita uređaja za virtualnu stvarnost – HTC Vive i Oculus Rift. Kako razlika u VR
uređajima ne bi utjecala na rezultate istraživanja određeno je da će računalo na koje je
priključen HTC Vive uvijek biti poslužitelj, a računalo na koje je priključen Oculus Rift
uvijek biti klijent te će se na njemu vršiti ispitivanje. Ispitivanje se stoga izvodilo na parovima
ispitanika – jedan igrač igrao je igru na poslužitelju, a drugi na klijentu. Igrači su zamijenili
mjesta nakon što je ispitanik na klijentu odigrao i ocijenio sve pokuse.
Prije početka izvođenja pokusa zabilježeni su opći podaci o korisniku – dob, spol i razina
općeg igraćeg iskustva (početno, srednje ili napredno) na temelju samoprocjene korisnika.
Ispitanici su potom dobili kratke upute o tijeku ispitivanja te odigrali jednu igru bez dodatnog
kašnjenja kako bi uz pomoć administratora naučili kontrole igre te dobili uvid u ponašanje i
tijek igre u idealnom slučaju. Tijekom daljnjeg provođenja ispitivanja korisnik je po potrebi
dobivao ponovljena ili dodatna objašnjenja vezana uz kontrole igre i parametre ocjenjivanja.
Svaki ispitanik isprobao je četiri različita pokusa. Svaki pokus igrao se na istoj mapi i istoj
razini (engl. level) igre. Odabrana je mapa Pharaoh's Dream i razina 6. Pokusi su se
međusobno razlikovali po iznosu ukupnog vremena obilaska na temelju ulaznog i izlaznog
kašnjenja simuliranog na poslužitelju pomoću alata Clumsy.
40
Iznosi kašnjenja za pojedini pokus nalaze se u tablici 9-1. Ulazno kašnjenje odnosi se na
kašnjenje ulaznih paketa, odnosno paketa koji se šalju na računalo. Izlazno kašnjenje odnosi
se na kašnjenje izlaznih paketa, odnosno paketa koji se šalju sa računala. Redoslijed izvođenja
pokusa bio je nasumičan za svakog ispitanika te ispitanici nisu upoznati s redoslijedom i
iznosima kašnjenja pokusa.
Tablica 9-1: Iznosi kašnjenja za pojedini pokus.
Ulazno kašnjenje (ms) Izlazno kašnjenje (ms) Ukupno kašnjenje (ms)
Pokus 1 75 75 150
Pokus 2 100 100 200
Pokus 3 125 125 250
Pokus 4 150 150 300
Tijekom svakog pokusa štopericom je mjereno vrijeme scenarija – od trenutka kad su oba
igrača odabrala oružje do kraja scenarija, tj. smrti igrača koji igra na klijentu ili pobjede ako
igrač nije poginuo unutar igre. Također je zabilježeno je li korisnik preživio do kraja igre.
Nakon kraja scenarija ispitaniku su postavljena dva pitanja vezana uz iskustvo igranja. Prvo
pitanje odnosilo se na ukupnu kvalitetu iskustva igranja, koju korisnik može ocijeniti ocjenom
od 1 do 5, pri čemu je 1 jako loša, 2 loša, 3 prihvatljiva, 4 dobra i 5 izvrsna. Potom je
korisniku postavljeno pitanje bi li nastavio igrati igru u ovakvim uvjetima. Upitnik korišten za
ispitivanje nalazi se u dodatku.
41
10. Rezultati
Ispitivanje je provedeno na 24 ispitanika u dobi od 14 do 38 godina, s prosjekom godina
26,54. U ispitivanju je sudjelovalo 10 ženskih i 14 muških osoba. Po razini igraćeg iskustva
osam korisnika pripadalo je početnoj skupini, osam srednjoj, a osam korisnika skupini s
naprednim iskustvom. Testna procedura (uključujući početna objašnjenja) trajala je otprilike
40 minuta za jedan par ispitanika.
Table 10-1: Prosječna ocjena ukupne kvalitete iskustva igranja za pojedini iznos ukupnog kašnjenja.
Ukupno kašnjenje 150 ms 200 ms 250 ms 300 ms
Svi korisnici 4,17 3,96 4,17 4,13
Početnici 4,25 3,63 4,25 4,25
Srednje iskusni korisnici 4,25 4,38 4,63 4,38
Napredni korisnici 4,00 3,88 3,63 3,75
Tablica 10-1. prikazuje prosječne ocjene ukupne kvalitete iskustva igranja za sve ispitanike,
kao i za svaku skupinu ispitanika posebno. Isti su podaci grafički prikazani na dijagramu na
slici 10-1, uz označene 95%-tne intervale pouzdanosti.
Slika 10-1: Prosječna ocjena ukupne kvalitete iskustva igranja za pojedini iznos ukupnog kašnjenja.
1
2
3
4
5
Svi korisnici Početnici Srednje iskusnikorisnici
Napredni korisnici
150 ms 200 ms 250 ms 300 ms
42
Na slici 10-2 grafički su prikazani postotci korisnika koji bi ili ne bi nastavili igru u uvjetima
određenim pojedinim iznosom kašnjenja. Igru s kašnjenjem od 150 ms nastavio bi 21
korisnik, a ne bi nastavila 3 korisnika, od čega jedan srednje iskusan i dva napredna korisnika.
Igru s kašnjenjem od 200 ms nastavilo bi 23 korisnika, a ne bi jedan napredan korisnik. Igru s
kašnjenjem od 250 ms nastavila bi 22 korisnika, a ne bi dva korisnika, od čega jedan početnik
i jedan napredni korisnik. Igru s kašnjenjem od 300 ms nastavilo bi 20 korisnika, a ne bi
nastavilo četvero korisnika, od čega su dva srednje iskusna i dva napredna korisnika.
Slika 10-2: Postotak korisnika koji bi ili ne bi nastavili igru za pojedini iznos ukupnog kašnjenja.
Na slici 10-3 nalazi se dijagram koji prikazuje postotke korisnika koji su poginuli tijekom igre
ili preživjeli do kraja igre (i pritom pobijedili u igri). Scenarij s kašnjenjem 150 ms uspjele su
do kraja odigrati bez umiranja četiri osobe (dva početnika i dva srednje iskusna korisnika), a
preostalih 20 osoba poginulo je unutar igre. Scenarij s kašnjenjem 200 ms bez umiranja
odigrale su tri osobe (dva početnika i jedan srednje iskusni korisnik), a unutar igre je poginuo
21 ispitanik. Scenarije s kašnjenjem 250 ms i 300 ms bez umiranja je odigrala po jedna osoba
(srednje iskusni korisnik za 250 ms i napredni korisnik za 300 ms), a preostala 23 poginuli su
unutar igre.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
150 ms 200 ms 250 ms 300 ms
Korisnici bi nastavili igru Korisnici ne bi nastavili igru
43
Slika 10-3: Postotak korisnika koji su poginuli ili preživjeli do kraja igre.
Na slici 10-4 nalazi se dijagram koji prikazuje prosječna vremena igranja za scenarije s
različitim iznosima kašnjenja. Plavi stupac prikazuje prosječno vrijeme igre (od odabira
oružja do smrti ili pobjede scenarija). Narančasti stupac prikazuje prosječno vrijeme od
odabira oružja do smrti igrača kod osoba koje su poginule unutar igre, a sivi stupac prosječno
vrijeme od odabira oružja do pobjede igrača koji nisu poginuli unutar igre.
Slika 10-4: Prosječna vremena za scenarije s različitim iznosima kašnjenja.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
150 ms 200 ms 250 ms 300 ms
Poginuli unutar igre Preživjeli unutar igre
00:00
00:43
01:26
02:10
02:53
03:36
150 ms 200 ms 250 ms 300 ms
Prosječno vrijeme igre Prosječno vrijeme do smrti unutar igre
Prosječno vrijeme do pobjede scenarija
44
11. Analiza rezultata
Promatrajući ukupne prosječne ocjene kvalitete iskustva igranja za sva četiri scenarija, vidi se
da visina prosječnih ocjena nije sasvim u skladu s očekivanim – korisnici nisu ocijenili
scenarije s nižim iznosom kašnjenja značajno bolje od scenarija s višim iznosom kašnjenja.
Najbolju prosječnu ocjenu (4,17) dobili su scenariji s kašnjenjem od 150 ms i 250 ms, a nakon
njih slijedi scenarij s kašnjenjem 300 ms s prosječnom ocjenom 4,13. Najmanju prosječnu
ocjenu (3,96) dobio je scenarij s kašnjenjem 200 ms. Raspon dodijeljenih prosječnih ocjena je
relativno malen (3,96–4,17), iz čega se može zaključiti da korisnici nisu vidjeli veliku razliku
između scenarija s različitim kašnjenjima. Taj zaključak potvrđuju i preklapanja između 95%-
tnih intervala pouzdanosti, kao i dvofaktorska analiza varijance bez replikacije, koja je
pokazala da ne postoji statistički značajna razlika između četiri scenarija (iznos p-vrijednosti
je 0,79).
Početnici su tri scenarija (kašnjenje od 150 ms, 250 ms i 300 ms) ocijenili istom prosječnom
ocjenom (4,25), dok su scenariju s kašnjenjem od 200 ms dali bitno lošiju ocjenu (3,63).
Srednje iskusni korisnici najvišu su ocjenu dali scenariju s kašnjenjem 250 ms (4,63), a potom
scenarijima s kašnjenjem 200 ms i 300 ms (4,38). Najmanju je ocjenu dobio scenarij s
najmanjim kašnjenjem (4,25).
Raspodjela ocjena kod korisnika s naprednim igraćim iskustvom bila je više u skladu s
očekivanim ocjenama od ocjena ostalih grupacija. Scenarij s najmanjim kašnjenjem (150 ms)
dobio je najvišu ocjenu – 4,00. Potom slijedi scenarij sa sljedećim najmanjim kašnjenjem
(200 ms) s prosječnom ocjenom 3,88. Scenarij s kašnjenjem 300 ms dobio je ocjenu 3,75, a
scenarij s kašnjenjem 250 ms najmanju ocjenu 3,63. Međutim, kao što se vidi na slici 10-1 iz
prethodnog poglavlja, kod naprednih korisnika 95%-tni intervali pouzdanosti prilično su
široki za scenarije s kašnjenjima 150 ms i 300 ms, što ukazuje na nestabilnost, odnosno veće
razlike u ocjenama različitih naprednih korisnika za isti scenarij.
Većina ispitanika (18 od 24 ispitanika) nastavila bi igru usprkos svim testiranim kašnjenjima.
Najveći broj ispitanika (4 od 24) prekinuo bi igru u uvjetima s najvećim testiranim
kašnjenjem (300 ms), ali slijedi ga scenarij s najmanjim kašnjenjem (150 ms), koji bi
prekinulo troje od 24 ispitanika. Dvoje ispitanika prekinulo bi scenarij s kašnjenjem 250 ms.
45
Najviše ispitanika (23 od 24 ispitanika) nastavilo bi igrati scenarij s kašnjenjem 200 ms,
unatoč tome što je upravo taj scenarij dobio najmanju prosječnu ocjenu iskustvene kvalitete.
Broj osoba koje su preživjele scenarij do pobjede objektivni je pokazatelj utjecaja koji je
mrežno kašnjenje imalo na ishod igre u ovom ispitivanju. Naime, u scenariju s najmanjim
kašnjenjem (150 ms) četvero korisnika izdržalo je do pobjede unutar igre, a u scenariju s
kašnjenjem 200 ms troje. Broj osoba koje su preživjele do kraja igre pao je s većim
kašnjenjima, pa je scenarije s kašnjenjima 250 ms i 300 ms preživio samo po jedan igrač.
Takvi rezultati upućuju na to da veće kašnjenje negativnije utječe na uspješnost igrača, unatoč
tome što on sam pritom možda nije svjestan tog kašnjenja i subjektivno ne prepoznaje
nikakvu smetnju. Ipak, broj igrača koji su uspješno završili igru vrlo je malen čak i u
najuspješnijem slučaju, te se na temelju njega ne mogu sa sigurnošću izvući nikakvi zaključci.
Razlog tome je činjenica da je odabrana razina igre relativno teška pa je lako poginuti i bez
ikakvog kašnjenja. Ispitivanje bi stoga trebalo ponoviti na većem broju ispitanika i s
odabranom lakšom razinom igre.
Prosječno vrijeme igre (od uzimanja oružja do smrti ili pobjede) iznosilo je oko 90 sekundi za
sva četiri scenarija, pri čemu je najkraće trajao scenarij s kašnjenjem 200 ms (89 s), a najdulje
scenariji s kašnjenjem 150 ms i 250 ms (98 s). Kod igrača koji su pobjedili prosječno vrijeme
do kraja scenarija iznosilo je nešto više od tri minute za sve slučajeve. Prosječno vrijeme do
pobjede za scenarije s kašnjenjem 150 ms i 200 ms bilo je gotovo jednako (3 minute i 14
sekundi, 3 minute i 15 sekundi). Scenarije s kašnjenjima 250 ms i 300 ms uspio je uspješno
dovršiti samo po jedan ispitanik, ali i ta vremena bila su bliska prosječnim vremenima za
preostala dva scenarija (3 minute i 17 sekundi za scenarij s 250 ms, 3 minute i 7 sekundi za
scenarij s 300 ms). Prosječno vrijeme trajanja scenarija za igrače koji su poginuli unutar igre
nešto je dulje za scenarije s većim kašnjenjima (1 minuta i 33 sekunde za scenarij s
kašnjenjem 250 ms, 1 minuta i 26 sekundi za scenarij s kašnjenjem 300 ms) u odnosu na
scenarije s manjim kašnjenjem (1 minuta i 18 sekundi za scenarij s kašnjenjem 150 ms, 1
minuta i 14 sekundi za scenarij s kašnjenjem 200 ms). Moguće je da je to zbog toga što su
igrači koji su uspješno igrali igru pri kašnjenjima 150 ms i 200 ms uspjeli dovršiti scenarij bez
smrti, pa njihovo dugo vrijeme igranja nije bilo uključeno u ovu statistiku, dok su igrači pri
kašnjenjima 250 ms i 300 ms unatoč dobroj igri ipak poginuli prije kraja igre, ali digli prosjek
vremena proteklog do smrti igrača. Bitno je napomenuti da se izvršena mjerenja mogu
promatrati samo kao okvirni pokazatelj trajanja scenarija, ali nisu izvršena s velikom
preciznošću, obzirom da su izvedena pomoću štoperice.
46
Iako su rezultati pokazali da dodatak mrežnog kašnjenja nije bitno utjecao na subjektivne
parametre iskustvene kvalitete kod igre Serious Sam VR: The Last Hope, moguće je da bi
ishod bio potpuno drugačiji za drugi tip igre. Serious Sam VR: The Last Hope je vrlo brza i
dinamična igra u kojoj se igrač bori protiv nekoliko neprijatelja odjednom. Kako bi se održao
na životu igrač mora brzo reagirati i obično nema vremena pričekati kako bi se uvjerio da je
pogodio protivnika i da je njegov pogodak bio registriran, što umanjuje njegovu mogućnost
da prepozna kašnjenje. Kako bi igrač porazio neprijatelja treba ga nekoliko puta pogoditi
metkom iz svog oružja tako da svi igrači ionako očekuju da jedan njihov pogodak neće bitno
oštetiti neprijatelja, čak i ako ga uspiju pogoditi, pa manjak pravovremene reakcije igre na
njihov pogodak ne tumače kao kašnjenje. Budući da je Serious Sam VR: The Last Hope igra u
kojoj igrač može mijenjati oružje, ispitanici su komentirali da je kašnjenje primjetnije s nekim
vrstama oružja, u odnosu na druge. Vrste oružja kod kojih je kašnjenje bilo vidljivije su one
puške i pištolji iz kojih su izlazili pojedinačni metci, koje je igrač mogao pratiti pogledom i
uočiti kašnjenje u njihovom smjeru i kretanju.
47
12. Zaključak
U ovom radu analizirani su izazovi vezani uz razvoj višekorisničkih umreženih igara te
višekorisničkih igara u virtualnoj stvarnosti. Opisane su najčešće mrežne arhitekture
višekorisničkih umreženih igara – arhitektura klijent–poslužitelj kao primjer autoritativne
mrežne arhitekture, te sustav ravnopravnih sudionika (engl. peer-to-peer) kao primjer
neautoritativne mrežne arhitekture. Analizirana je mrežna arhitektura višekorisničke
umrežene igre u virtualnoj stvarnosti Serious Sam VR: The Last Hope na temelju snimljenog
mrežnog prometa.
Uz korištenje paketa Photon Unity Networking u alatu Unity razvijene su dvije jednostavne
višekorisničke umrežene igre u virtualnoj stvarnosti, od čega jedna ima kooperativan način
igre, a u drugoj igrači igraju jedan protiv drugoga. U kooperativnoj igri igrači se kreću po
sceni i zajedno izvršavaju jednostavni matematički zadatak. U igri igrač protiv igrača igrači su
fiksirani na mjestu, ali pokušavaju poraziti jedan drugoga gađajući se objektima. Obje verzije
napravljene su kao prototipi igara, te bi se kroz daljnji rad mogle poboljšati tako da se isprave
postojeće greške te dodaju nove mogućnosti.
Izvršeno je ispitivanje u kojem se provjeravalo kako kašnjenje (150 ms, 200 ms, 250 ms i 300
ms) utječe na iskustvenu kvalitetu. Za ispitivanje je korištena igra Serious Sam VR: The Last
Hope. Ispitivanje je provedeno na 24 ispitanika u dobi od 14 do 38 godina, s prosjekom
godina 26,54. U ispitivanju je sudjelovalo 10 ženskih i 14 muških osoba. Po razini igraćeg
iskustva osam korisnika pripadalo je početnoj skupini, osam srednjoj, a osam korisnika
skupini s naprednim iskustvom. Testna procedura (uključujući početna objašnjenja) trajala je
otprilike 40 minuta za jedan par ispitanika. Ispitanici su ocijenili iskustvenu kvalitetu ocjenom
od 1 do 5 i odgovorili bi li nastavili igrati igru u takvim uvjetima. Također je evidentirano
jesu li igrači uspjeli prijeći testni scenarij bez da poginu unutar igre te koliko im je vremena
trebalo za to. Unatoč tome što je ispitivanje pokazalo da kod ovakvog žanra igre manje
kašnjenje nije proporcionalno višoj ocjeni iskustvene kvalitete, rezultati upućuju na to da veće
kašnjenje može utjecati na korisnikov rezultat, odnosno ishod njegove igre (pobjedu ili poraz)
te ga staviti u neravnopravan položaj u odnosu na druge igrače. Rezultati ispitivanja specifični
su za testirani tip igre te dovode do pitanja bi li provedba sličnog ispitivanja kod igara s
drugačijom mrežnom arhitekturom i mehanikom igre dovela do drugačijih rezultata.
48
13. Literatura
[1] Wijman, T.: Mobile Revenues Account for More Than 50% of the Global Games Market
as It Reaches $137.9 Billion in 2018, URL: https://newzoo.com/insights/articles/global-
games-market-reaches-137-9-billion-in-2018-mobile-games-take-half/, preuzeto: 26.6.2018.
[2] Trends in Online Playing in 2017 and Beyond, URL: https://plarium.com/en/blog/trends-
online-gaming-2017/, preuzeto: 26.6.2018.
[3] Burns, T.: 'E-Sports' can now drop the 'e', URL:
https://www.aljazeera.com/indepth/opinion/2014/07/esports-can-now-drop-e-
2014724112549724248.html, preuzeto: 26.6.2018.
[4] Metz, R.: Pong’s Inventor Wants to Bring Virtual Reality to Arcades, URL:
https://www.technologyreview.com/s/603562/pongs-inventor-wants-to-bring-virtual-reality-
to-arcades/, preuzeto: 26.6.2018.
[5] Takahashi, D.: Nolan Bushnell’s Modal VR launches next-generation virtual reality
platform for enterprises, URL: https://venturebeat.com/2016/10/12/nolan-bushnells-modal-vr-
launches-next-generation-virtual-reality-platform-for-enterprises/, preuzeto: 26.6.2018.
[6] Sužnjević, M.: Kvaliteta usluge umreženih virtualnih okruženja u novoj generaciji mreža,
URL:
https://www.researchgate.net/publication/228605582_Kvaliteta_usluge_umrezenih_virtualnih
_okruzenja_u_novoj_generaciji_mreza, preuzeto: 26.6.2018.
[7] Pantel, L. & Wolf, L.C.: On the Impact of Delay on Real-Time Multiplayer Games, URL:
https://www.cs.ubc.ca/~krasic/cpsc538a/papers/p23-pantel.pdf, preuzeto: 26.6.2018.
[8] Elbamby, M.S.; Perfecto, C.; Bennis, M.; Doppler, K.: Towards Low-Latency and Ultra-
Reliable Virtual Reality, URL: https://arxiv.org/pdf/1801.07587.pdf, preuzeto: 26.6.2018.
49
[9] Porter, T.: VR Optimization Tips from Underminer Studios, URL:
https://software.intel.com/en-us/articles/vr-optimization-tips-from-underminer-studios,
preuzeto: 26.6.2018.
[10] Hall, C.: Sony to devs: If you drop below 60 fps in VR we will not certify your game,
URL: https://www.polygon.com/2016/3/17/11256142/sony-framerate-60fps-vr-certification,
preuzeto: 26.6.2018.
[11] Glazer, J.; Madhav, S.: Multiplayer Game Programming: Architecting Networked
Games, URL: https://books.google.hr/books?id=RKT-
CgAAQBAJ&pg=PT289&lpg=PT289&dq=networked+vr+tolerance&source=bl&ots=u6PJG
RA64w&sig=yYdoF6VmtdMZnscDOKLpEQbm-
d8&hl=hr&sa=X&ved=0ahUKEwj9xuS5mszbAhUBPVAKHVyADrsQ6AEIbzAI#v=onepag
e&q=networked%20vr%20tolerance&f=false, preuzeto 26.6.2018.
[12] Seam, A.; Poll, A.; Wright, R.; Mueller, J.; Hoodbhoy, F.: Enabling Mobile Augmented
and Virtual Reality with 5G Networks, URL:
http://about.att.com/content/dam/innovationblogdocs/Enabling%20Mobile%20Augmented%2
0and%20Virtual%20Reality%20with%205G%20Networks.pdf, preuzeto: 26.6.2018.
[13] MacKenzie, I.S.; Ware, C.: Lag as a Determinant of Human Performance in Interactive
Systems, in Proceedings of the ACM Conference on Human Factors in Computing Systems -
INTERCHI '93, 488-493. New York, http://www.yorku.ca/mack/CHI93b.html, 26.6.2018.
[14] Davies, S.: What Makes Multiplayer VR A Success And A Challenge?, URL:
https://www.vrfocus.com/2017/09/what-makes-multiplayer-vr-a-success-and-a-challenge/,
preuzeto: 26.6.2018.
[15] Robertson, A.: Why there’s no great VR dueling game — and why you should want one,
URL: https://www.theverge.com/2016/5/27/11795962/oculus-maximus-raw-data-virtual-
reality-swordfighting-video-games, preuzeto: 26.6.2018.
[16] Strange, A.: Oculus Avatars lets you reinvent yourself in virtual reality, URL:
https://mashable.com/2016/12/14/oculus-avatars/#4X1pnVN_Rgqy, preuzeto: 26.6.2018.
50
[17] Bevilacqua, F.: Building a Peer-to-Peer Multiplayer Networked Game, URL:
https://gamedevelopment.tutsplus.com/tutorials/building-a-peer-to-peer-multiplayer-
networked-game--gamedev-10074, preuzeto: 26.6.2018.
[18] van Dongen, J.: Core network structures for games, URL:
http://joostdevblog.blogspot.hr/2014/09/core-network-structures-for-games.html, preuzeto:
26.6.2018.
[19] Hook, B.: Introduction to Multiplayer Game Programming, URL:
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/IntroductionToMultiplayerGameProgra
mming, preuzeto: 26.6.2018.
[20] Gambetta, G.: Fast-Paced Multiplayer (Part II): Client-Side Prediction and Server
Reconciliation, URL: http://www.gabrielgambetta.com/client-side-prediction-server-
reconciliation.html, preuzeto: 26.6.2018.
[21] Fiedler, G.: UDP vs. TCP - Which protocol is best for games?, URL:
https://gafferongames.com/post/udp_vs_tcp/, preuzeto: 26.6.2018.
[22] Carbotte, K.: 'Serious Sam VR' Isn’t A First Person Shooter, It’s A First Person Shoot-
Em-Up, URL: https://www.tomshardware.com/news/serious-sam-vr-fps-shoot-em-
up,32859.html, preuzeto: 26.6.2018.
[23] Johnston, K.: NAT Punch-through for Multiplayer Games, URL:
https://keithjohnston.wordpress.com/2014/02/17/nat-punch-through-for-multiplayer-games/,
preuzeto: 26.6.2018.
[24] Ford, B.; Srisuresh, P.; Kegel, D.: Peer-to-Peer Communication Across Network Address
Translators, URL: http://www.brynosaurus.com/pub/net/p2pnat/, preuzeto: 26.6.2018.
[25] Rosenberg, J.; Weinberger, J.; Huitema, C.; Mahy R.: STUN - Simple Traversal of User
Datagram Protocol (UDP) Through Network Address Translators (NATs), URL:
https://tools.ietf.org/html/rfc3489#page-3, preuzeto: 26.6.2018.
[26] Pellet, P.: Linux Embedded applications in Machine Vision, in: Embedded Linux
Conference – Europe, October 15th 2009, Grenoble, URL:
https://elinux.org/images/7/73/PascalPellet-e2vELC-E.pdf, preuzeto: 26.6.2018.
51
[27] Unity: A feature-rich and highly flexible editor, URL: https://unity3d.com/unity/editor,
preuzeto: 26.6.2018.
[28] Visual Studio: Best-in-class tools for any developer, URL:
https://www.visualstudio.com, preuzeto: 26.6.2018.
[29] SteamVR Plugin, URL:
https://assetstore.unity.com/packages/templates/systems/steamvr-plugin-32647, preuzeto:
26.6.2018.
[30] VRTK: Welcome to VRTK, URL: https://vrtoolkit.readme.io/docs, preuzeto: 26.6.2018.
[31] PUN: The Ease-of-use of Unity's Networking with the Performance & Reliability of
Photon Realtime, URL: https://www.photonengine.com/en-US/PUN, preuzeto: 26.6.2018.
[32] PlayoVR, a VRTK-PUN-Voice Demo, URL: https://github.com/quintesse/PlayoVR,
preuzeto: 26.6.2018.
[33] Oculus Rift, URL: https://www.oculus.com/rift/, preuzeto: 26.6.2018.
[34] Vive VR System, URL: https://www.vive.com/us/product/vive-virtual-reality-system/,
preuzeto: 26.6.2018.
[35] Photon: PUN Introduction, URL: https://doc.photonengine.com/en-
us/pun/current/demos-and-tutorials/pun-basics-tutorial/intro, preuzeto: 26.6.2018.
[36] Photon: PUN Quick Start, URL: https://doc.photonengine.com/en-
us/realtime/current/getting-started/quick-start, preuzeto: 26.6.2018.
[37] Photon: PUN Master Client and Host Migration, URL: https://doc.photonengine.com/en-
us/pun/current/gameplay/hostmigration, preuzeto: 26.6.2018.
[38] Photon: PUN Binary Protocol, URL: https://doc.photonengine.com/en-
us/onpremise/current/reference/binary-protocol, preuzeto: 26.6.2018.
[39] Photon: PUN Matchmaking Guide, URL: https://doc.photonengine.com/en-
us/realtime/current/reference/matchmaking-and-lobby, preuzeto: 26.6.2018.
52
[40] van de Water, J.: How to create an online multiplayer game with Photon Unity
Networking, URL: http://www.paladinstudios.com/2014/05/08/how-to-create-an-online-
multiplayer-game-with-photon-unity-networking/, preuzeto: 26.6.2018.
[41] Photon: PUN Feature Overview, URL: https://doc.photonengine.com/en-
us/pun/current/getting-started/feature-overview, preuzeto: 26.6.2018.
[42] Photon: PUN RPCs and RaiseEvent, URL: https://doc.photonengine.com/en-
us/pun/current/gameplay/rpcsandraiseevent, preuzeto: 26.6.2018.
[43] Photon: PUN Ownership Transfer Demo, URL: https://doc.photonengine.com/en-
us/pun/current/demos-and-tutorials/package-demos/ownership-transfer, preuzeto: 26.6.2018.
[44] Photon: PUN Instantiation, URL: https://doc.photonengine.com/en-
us/pun/current/gameplay/instantiation, preuzeto: 26.6.2018.
[45] Photon: PUN Photon Lag Simulation Gui, URL: https://doc.photonengine.com/en-
us/pun/current/troubleshooting/photon-lag-simulation-gui, preuzeto: 26.6.2018.
[46] Sužnjević, M; Skorin-Kapov, L., Matijašević, M.: The impact of user, system, and
context factors on gaming QoE: A case study involving MMORPGs. Network and Systems
Support for Games (NetGames), 12th Annual Workshop on. IEEE. doi:
10.1109/NetGames.2013.6820606, 2013.
[47] Henderson, T.: Latency and User Behaviour on a Multiplayer Game Server, URL:
https://tnhh.org/research/pubs/ngc2001.pdf, preuzeto: 26.6.2018.
[48] Beigbeder, T.; Coughlan, R.; Lusher, C.; Plunkett, J.; Agu, E.; Claypool, M.: The Effects
of Loss and Latency on User Performance in Unreal Tournament 2003. In: Proceedings of
ACM NetGames, Portland, OG, USA, Sept. 2004.
53
Sažetak
U ovom su radu analizirani izazovi koji se pojavljuju prilikom razvoja umreženih
višekorisničkih igara u virtualnoj stvarnosti te su proučene najčešće mrežne arhitekture i
protokoli za prijenos podataka korišteni prilikom njihova razvoja. Na temelju snimljenog
mrežnog prometa analizirana je mrežna arhitektura postojeće umrežene višekorisničke
aplikacije u virtualnoj stvarnosti.
U alatu Unity razvijena su dva prototipa višekorisničke umrežene igre u virtualnoj stvarnosti:
kooperativni prototip i prototip igrač protiv igrača. Kooperativni prototip temelji se na
međusobnoj suradnji igrača koji zajednički rješavaju jednostavni matematički zadatak.
Prototip igrač protiv igrača temelji se na međusobnoj borbi igrača koji pokušavaju poraziti
jedan drugoga gađajući se objektima. Za umrežavanje izrađenih aplikacija korišten je paket
Photon Unity Networking.
Osmišljeno je i provedeno ispitivanje čiji je cilj utvrditi kako mrežno kašnjenje kod
višekorisničkih umreženih igara temeljenih na virtualnoj stvarnosti utječe na iskustvenu
kvalitetu korisnika i njegovu želju za nastavkom ili prekidom igre, te na vrijeme trajanja i
ishod igre. Ispitivanje je provedeno na primjeru igre Serious Sam VR: The Last Hope, a u
njemu su sudjelovale 24 osobe.
Ključne riječi: virtualna stvarnost, višekorisničke igre, iskustvena kvaliteta, mrežna
arhitektura, mrežno kašnjenje
54
Summary
This thesis analyzes the challenging aspects of developing a networked multiplayer game in
Virtual Reality (VR) and explores the most commonly used network architectures and
networking protocols. An existing networked multiplayer VR game has been analyzed based
on the captured network traffic.
Two networked multiplayer VR game prototypes were created based on different types of
gameplay: cooperative and Player vs. Player. The cooperative prototype requires players to
work together to solve a simple mathematic problem. The Player vs. Player prototype requires
players to fight against each other by aiming objects at each other’s avatars. The game
prototypes were made in Unity, using the Photon Unity Networking package.
A study was designed to assess the effects of networking delay on the quality of experience
for networked multiplayer VR games. The participants were asked to rate their perceived
quality of experience and decide whether they would continue playing the game under the
given circumstances. The duration and the outcome of the game were also noted. The study
was conducted on 24 participants using the game Serious Sam VR: The Last Hope.
Keywords: Virtual Reality, multiplayer games, Quality of Experience, network architecture,
network delay
55
Dodatak A: Upitnik za ocjenjivanje iskustvene
kvalitete
UPITNIK ZA OCJENJIVANJE ISKUSTVENE KVALITETE
Odgovori i podaci prikupljeni ovim upitnikom će se koristiti isključivo za potrebe istraživanja u okviru projekta Evaluacija iskustvene kvalitete višekorisničkih igara temeljenih na virtualnoj stvarnosti. Vaši osobni podaci će ostati anonimni.
OPĆI PODACI
1) Ime i prezime: ___________________________________________
2) Starost u godinama: ______ 3) Spol: M / Ž 4) Razina igraćeg iskustva: početno / srednje / napredno
56
UPUTE ZA PROVOĐENJE ISPITIVANJA
Ispitivanje se provodi na temelju kooperativne višekorisničke igre u virtualnoj stvarnosti
Serious Sam VR: The Last Hope. Arhitektura igre je klijent–poslužitelj, pri čemu jedno od
korisničkih računala služi kao poslužitelj, a drugo kao klijent. Uređaj za virtualnu stvarnost
koji je priključen na računalo koje služi kao poslužitelj je HTC Vive, a na drugom računalu
korištenom za testiranje nalazi se uređaj Oculus Rift. Prilikom testiranja ispitivat će se utjecaj
mrežnog kašnjenja na kvalitetu iskustva igranja na klijentu. Testiranje se vrši u parovima –
jedan igrač na poslužitelju i jedan na klijentu, ali samo osoba koja igra na klijentu odgovara
na pitanja. Igrači zamjenjuju mjesta nakon što je prvi ispitanik odigrao i ocijenio sve pokuse.
Svaki pokus igra se na istoj mapi igre, a razlikuje se po iznosu ukupnog vremena obilaska na
temelju kašnjenja simuliranog na poslužitelju. Redoslijed izvođenja pokusa je nasumičan za
svakog ispitanika. Prije početka izvođenja pokusa ispitanik će odigrati jednu igru bez
dodanog kašnjenja kako bi uz pomoć administratora naučio kontrole igre i imao uvid u
ponašanje i tijek igre u idealnom slučaju (bez kašnjenja).
Pokus se pokreće tako da igrač koji nije trenutni ispitanik u izborniku igre Serious Sam
odabire opciju Arena te potom odabere mapu Pharaoh’s Dream i težinu (engl. difficulty) 6.
Nakon toga može pokrenuti poslužitelja (odabir tipke Start server) i pričekati ispitanika da se
pridruži igri (opcija Join game u izborniku).
Za svaki pokus ručno će se izmjeriti vrijeme igre (od trenutka kad su oba igrača odabrala
oružje do kraja igre). Nakon svakog pokusa zabilježit će se je li ispitanik poginuo unutar igre
te će mu biti postavljena dva pitanja vezana uz iskustvo igre. Prvo pitanje vezano je za
ukupnu kvalitetu iskustva igranja, koju ispitanik može ocijeniti ocjenom od 1 do 5, pri čemu
je 1 jako loša, 2 loša, 3 prihvatljiva, 4 dobra i 5 izvrsna. Nakon toga korisnik će odgovoriti na
pitanje bi li nastavio igrati igru u ovakvim uvjetima.
57
OCJENJIVANJE POKUSA
Broj pokusa: ________
Kako biste ocijenili ukupnu kvalitetu iskustva igranja u ovom pokusu?
□ 1 – jako loša
□ 2 – loša
□ 3 – prihvatljiva
□ 4 – dobra
□ 5 – izvrsna
Biste li nastavili igru u ovakvim uvjetima?
□ da
□ ne
Vrijeme potrebno za izvršenje scenarija: ______________
Jeste li poginuli unutar igre?
□ da
□ ne
Broj pokusa: ________
Kako biste ocijenili ukupnu kvalitetu iskustva igranja u ovom pokusu?
□ 1 – jako loša
□ 2 – loša
□ 3 – prihvatljiva
□ 4 – dobra
□ 5 – izvrsna
Biste li nastavili igru u ovakvim uvjetima?
□ da
□ ne
Vrijeme potrebno za izvršenje scenarija: ______________
Jeste li poginuli unutar igre?
□ da
□ ne
Broj pokusa: ________
58
Kako biste ocijenili ukupnu kvalitetu iskustva igranja u ovom pokusu?
□ 1 – jako loša
□ 2 – loša
□ 3 – prihvatljiva
□ 4 – dobra
□ 5 – izvrsna
Biste li nastavili igru u ovakvim uvjetima?
□ da
□ ne
Vrijeme potrebno za izvršenje scenarija: ______________
Jeste li poginuli unutar igre?
□ da
□ ne
Broj pokusa: ________
Kako biste ocijenili ukupnu kvalitetu iskustva igranja u ovom pokusu?
□ 1 – jako loša
□ 2 – loša
□ 3 – prihvatljiva
□ 4 – dobra
□ 5 – izvrsna
Biste li nastavili igru u ovakvim uvjetima?
□ da
□ ne
Vrijeme potrebno za izvršenje scenarija: ______________
Jeste li poginuli unutar igre?
□ da
□ ne