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