of 33 /33
TINR @ FRI, draft v09, Peter Peer ++ 97 Poglavje #6 (meniji in zvok) (Bojan Klemenc++) Aktualne škatlice: infrastruktura o meniji shranjevanje (dodatek k poglavju 4) zvok o 2D zvok o 3D zvok o glasba 1. Meniji Vmesnik Vmesnik je mreža komponent, ki omogočajo igralcu interakcijo z igro:

TINR Skripta Predavanj 6

Embed Size (px)

DESCRIPTION

games

Citation preview

Page 1: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   97  

Poglavje #6 (meniji in zvok) 

(Bojan Klemenc++) 

Aktualne škatlice:  

 

• infrastruktura  o meniji 

• shranjevanje (dodatek k poglavju 4) • zvok  

o 2D zvok  o 3D zvok  o glasba 

1. Meniji 

Vmesnik 

Vmesnik je mreža komponent, ki omogočajo igralcu interakcijo z igro: 

 

Page 2: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   98  

Sam vmesnik sicer igre ne more narediti dobre, vendar slab vmesnik lahko hitro odvrne igralce, da bi ponovno posegli po njej. 

Grafični uporabniški vmesnik (GUI, angl. graphical user interface) 

Načini, kako lahko uporabniki sodelujejo (interakcija) z računalniki, pridobivajo informacije in, da lahko te informacije koristno in učinkovito uporabijo, so eden glavnih elementov v razvoju programske opreme. Uporabniški vmesnik (UI, angl. user interface) je glavna vez med računalnikom (in programom) ter uporabnikom. Grafični vmesniki (predvsem v primerjavi z tekstovnimi ukaznimi vrsticami – CLI, angl. command line interface) omogočajo komunikacijo in nadziranje računalnika preko grafičnih elementov (vizualni indikatorji, ikone). Grafične elemente neposredno manipuliramo in rezultati se nam prav tako prikažejo neposredno preko grafičnih vmesnikov. Grafični vmesniki so intuitivni, kar največkrat dosežemo s preslikovanjem realnosti (recimo namizje), hkrati pa animiranje akcij daje takojšnjo informacijo o tem, ali akcija vodi k željenemu cilju ali ne (opazovanje napredka, recimo ob kopiranju datotek). 

Za izdelavo dobrega grafičnega vmesnika je potrebno poznati principe grafičnega oblikovanja. Besedilo in vizualni elementi morajo biti organizirani na tak način, da omogočajo uporabniku preprosto pridobivanje, urejanje in hrambo podatkov. Grafični uporabniški vmesniki osnovne ideje grafičnega oblikovanja nadgradijo tudi z interaktivnostjo in zvokom. Najboljši uporabniški vmesniki so nevpadljivi in za uporabnika »neopazni«. Obratno velja, da so slabi vmesniki precej opazni in gredo lahko uporabniku precej na živce. Pogosto velja, da je najboljši minimalističen pristop k izgradnji vmesnika. Po potrebi lahko potem dodajamo bolj kompleksne elemente, če je nujno potrebno. 

Nekaj principov grafičnega oblikovanja 

Vizualna uravnoteženost (simetrična in asimetrična): zagotavlja sliki stabilnost nasprotujočih si sil, pri tem je skupna teža majhnih objektov pri asimetrični postavitvi ustrezno skoncentrirana: 

 

Ritem: s ponavljanjem različnih elementov ustvarimo vzorec, ki ustvari red in omogoča napovedljivost, predvidljivost (glej spodnjo levo sliko). 

Poudarek: kadar se gibanje ali vzorec prekine, dobimo točko, na katero preusmerimo fokus (to lahko naredimo z barvo, obliko, velikostjo, teksturo): 

Page 3: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   99  

 

Skladnost prvin in enotnost izgleda: vse sestavine se ujemajo in tvorijo enotno celoto – celoten uporabniški vmesnik ima enoten izgled (temo). 

Glavni elementi grafičnega oblikovanja: 

 

(K tem elementom lahko dodamo vsaj še barvo.) 

Principi načrtovanja uporabniškega vmesnika 

Kaj moramo upoštevati? 

Preprostost: Najbolj učinkovite in najlažje za uporabo so preproste rešitve. 

Konsistentnost: Navada lahko zelo pospeši uporabo vmesnika – če vemo kje se bo pojavilo kakšno okno, kje se bo pojavil kakšen gumb (primer: OK, Cancel), kje se v meniju kakšna stvar nahaja, lahko precej hitreje in učinkovito navigiramo po vmesniku. V nasprotnem primeru se mora uporabnik v vsakem oknu na novo naučiti vmesnik, kar povzroča neučinkovitost in je precej neprijazno do uporabnika (nezaželena področja frustracije, glej poglavje 4). 

Poznavanje ciljnega uporabnika: Vmesniki za otroke bodo precej drugačni od vmesnikov za odrasle. Predvideti moramo, kakšno je znanje in kakšne so potrebe, pričakovanja končnega uporabnika (tudi recimo pričakovanja, ki izvirajo iz različnih kultur). 

Uporaba barv: Določene podatke lahko poudarimo z barvami, vendar naj barva ne bo edini pokazatelj kritičnih informacij. Ob tem vzamemo v zakup tudi lastnosti barvne slepote. Potrebno je pravilno uporabljati kontraste, še posebej, kadar želimo, da je besedilo berljivo (izogibamo se recimo 

Page 4: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   100  

veliki količini svetlega teksta na temni podlagi). V povezavi s poznavanjem uporabnika je potrebno upoštevati, da imajo v različnih kulturah različne barve lahko drugačen pomen. 

Povratne informacije: Vidne in slušne povratne informacije povedo uporabniku kako sodeluje z vmesnikom. Na primer gumb lahko ima različni ikoni, odvisno od tega, ali se miškin kazalec nahaja nad gumbom  in tako uporabnik ve, da je tam točka interakcije. Ko kliknemo, se ikona lahko spet spremeni, dobimo pa še zvočno povratno informacijo. Če nalaganje vsebine traja več kot nekaj sekund, je koristno dodati nek pokazatelj poteka (npr. odstotki), ker drugače izgleda kot da se vmesnik ne odziva. V splošnem igralec, uporabnik implicitno sprašuje »Hočem narediti to. Ali lahko?«, vmesnik pa se mora ustrezno odzvati na en od dveh načinov: »Zahteva izvršena,« ali »Tega ne moreš narediti«. Slab odziv v igrah povzroči občutek cenenosti le‐teh. 

Elementi načrtovanja uporabniškega vmesnika 

Začnemo s spiski informacij, ki bi jih igralec, uporabnik lahko želel vedeti. Nato jih uredimo, postavimo prioritete ter predstavimo v obliki miselnih vzorcev (mind maps): 

 

Uporabniški vmesnik lahko nato lepo predstavimo z diagrami poteka (prehodi med stanji po zaključeni aktivnosti) in diagrami stanj (prehodi med stanji ob dogodkih).  

Primer diagrama poteka za glavni meni v igri: 

Page 5: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   101  

 

(https://wiki.abertay.ac.uk/display/logicgate/Overview) 

Spodnja slika predstavlja diagram stanj za sistem menijev (meni "Multiplayer"). Sistem menijev je avtomat, kjer se prehodi med posameznimi stanji (meniji/zasloni) vršijo ob ustreznih dogodkih (izbira/klik na posamezno postavko v meniju) (primerjaj z agenti s stanji v poglavju 5): 

Page 6: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   102  

 

S pomočjo diagrama poteka in diagrama stanj lahko ugotovimo napake v funkcionalnosti vmesnika. To je še posebej pomembno, kadar estetsko (izgled) in funkcionalno oblikovanje delata dve različni osebi. Tako uporaba diagrama izloči funkcionalne napake preden začnemo udejanjati izgled. Popravljanje napak v fazi, ko je vmesnik grafično precej dodelan, je drago. 

Ko imamo jasno sliko, kaj uporabniški vmesnik mora ponuditi, kako mora delati, pripravimo skice, ki funkcionalne zahteve umestijo v izgled. Pri tem moramo vse kontrole ustrezno umestiti v temo igre (game theme), da zagotovimo enoten izgled: 

 

Preprost vmesnik je potreben tudi zato, ker človekov kratkoročni spomin hrani učinkovito le od 5 do 7 elementov. Večina funkcij naj se aktivira po največ 3 do 5 akcijah uporabnika (npr. klikov). Podobne funkcije naj bodo grupirane skupaj. Tako uporabniku ni potrebno skakati od enega konca ekrana do drugega, kar lahko povzroči, da se izgubi. 

Mreža: Za vmesniki je pogosto definirana mreža, ki služi kot logična struktura oziroma ogrodje, na katero pripnemo elemente vmesnika:  

 

Page 7: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   103  

Večstopenjski meniji (tiered menus): Meniji se prilagajajo potrebam/zahtevam uporabnika. Bolj naprednemu uporabniku recimo ponudimo več možnosti. Uporabnik lahko sam nadzoruje količino ponujene informacije. 

Lokalizacija: Ob načrtovanju mislimo na prevod vmesnika v druge jezike. Besedila nikoli ne vstavljamo neposredno v kodo, ampak med podatke. Besedilo naj bo sestavljeno iz znakov (bodisi kot pisava TrueType, bodisi kot pisava Bitmap) in ne v celoti kot slika. Kadar je besedilo vsebovano v sliki, naj bo slika sestavljena iz slojev. Okoli besedila vedno rezerviramo dovolj prostora (okoli 30%) za jezike, kjer so besede dolge (npr. Nemščina). Pisave ne smejo biti premajhne, splošno pravilo pravi, da ne gremo pod 12 slikovnih točk. 

Izbira pisave: 

Izberemo pisavo, ki je dobro berljiva. Pri tem se moramo zavedati, da človek razpoznave oblikovne enote, sklop črk, ne posamezne črke. Posamezne črke razpoznavamo le v primeru teksta, kjer je vse zapisano z velikimi tiskanimi črkami, kar je tudi razlog, da je branje težje, da beremo počasneje. 

Pisave s serifi so lažje berljive, saj dodajajo horizontalno strukturo, ki jim oči lažje sledijo skozi besedo, vendar jih ločljivost ekrana včasih ne dopušča. Ker igre navadno nimajo velike količine teksta, ta lastnost serifov v igrah nima enake teže kot pri tekstu v recimo dokumentih. 

Kadar delamo z mislijo na lokalizacijo, se prepričamo, da pisava, ki smo jo izbrali, podpira črke, ki se uporabljajo v drugem jeziku. Uporabljamo tudi ustrezno kodiranje znakov (unicode – za zapis znaka uporablja od enega do štiri bajte, kar naj bi zadoščalo za zapis večine svetovnih jezikov vključno z Japonščino in Kitajščino).  

Če je možno, poskrbimo, da so črke vizualno enako oddaljene ena od druge (kerning). Razmak med črkami nastavimo tako, da se del ene črke oziroma njena omejujoča površina (bounding box) prekriva z delom naslednje. Tako dosežemo večjo kompaktnost besed in večjo berljivost. 

Za prikaz na ekranu lahko uporabljamo poseben postopek (hinting), ki spremeni izgled znaka pred samo konverzijo v bitno sliko. Glavni namen postopka je zagotavljati berljivost, tudi pri manjših pisavah. 

Osnovne značilnosti pisav: 

 

Page 8: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   104  

Neposredna uporaba pisav (TrueType fonts) zahteva več pomnilnika in poseben tretma znotraj kode, vendar so rezultati lepši (kerning, različne velikosti, matematičen opis). Če ne moremo uporabiti takšnih pisav, naredimo teksturo na katero izrišemo vse možne črke (bitmap fonts) – mreža celic s črkami mora imeti dovolj prostora med črkami, da lahko brez težav izrišemo vsako črko (kerning navadno ni omogočen).  

Pri določenih pisavah je potrebno poskrbeti za licence, zato lahko ustvarimo tudi svoje, vendar je to časovno zelo potratno.  

Prototipiranje:  

Načrtovalec lahko naredi prototip uporabniškega vmesnika (še posebej menijev) z različnimi orodji, tako testira vmesnik še preden ga programerji implementirajo in odkrije morebitne napake. Preprosto testiranje zajema analizo diagrama poteka, lahko tudi preprosto realizacijo v HTML‐ju ali Flash‐u. 

Elementi grafičnega vmesnika 

Z elementi grafičnega vmesnika sestavljamo posamezne zaslone grafičnega vmesnika. Grafične elemente lahko delimo na [en.wikipedia, Graphical_user_interface_elements, 2010]: 

(a) strukturne elemente – prikazujejo informacije in vizualno predstavljajo vmesnik, omogočajo interakcijo z uporabniki. Odzivajo se na vhode, ki jih posredujemo preko interakcijskih elementov. 

(b) interakcijske elemente – elementi vmesnika, ki omogočajo operacije in spremembe. 

Področje grafičnih vmesnikov je precej široko področje in nima veliko standardnih rešitev. Vendar pa so nekatere rešitve kar precej pogoste. Pogostejši elementi grafičnega uporabniškega vmesnika so: 

Strukturni elementi: 

Okno je zaokroženo področje na zaslonu, kjer se prikazujejo informacije neodvisno od ostalih delov zaslona. Okna so lahko zelo specializirana: vsebniki, podokna, okna s sporočili, terminalska okna (CLI – command line interface). 

Meni je seznam ukazov s katerega lahko uporabnik (s pomočjo neke vrste kazalca) izbere primeren ukaz (v primerjavi s CLI, kjer se ukazi pišejo). Meniji so lahko organizirani hierarhično. Specializirani meniji:  

• menijska vrstica – vsebuje več spustnih (pull‐down) menijev 

• kontekstni meni – se prikaže, ko uporabnik s kazalcem izvede določen dogodek (npr. desni klik) v določenem kontekstu. Pogosto se prikaže na mestu, kjer se je zgodil dogodek. Meni se lahko prikaže kot navadni seznam ali pa krožni meni (pie menu). Prednost krožnega menija je, da so vse možnosti enako oddaljene in po možnosti vedno na istem mestu, kar poveča učinkovitost dostopa. Vendar pa krožnega menija vedno ne moremo uporabiti (npr. Zaradi preveč postavk). 

Navadni in krožni kontekstni meni: 

Page 9: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   105  

           

Ikone so sličice, ki predstavljajo objekte (npr. datoteke, programe, spletne strani, ukaze).  

Nadzorni elementi (kontrole): 

• grafična predstavite kazalca • vpisno polje (text box) • gumb (button) • hiperpovezava (hyperlink) • spustni seznam (drop‐down list) • seznam (list box) • kombinirano polje (combo box) • stikalo/potrditveno polje (check box) • radijski gumb (radio button) • podatkovna mreža (datagrid). 

 Interakcijski elementi: 

Kazalec (pointer, cursor) ter selekcija/označba (selection). Slednja je seznam/označba elementov, nad katerimi se lahko izvrši neka akcija. 

Podobnost med samo igro in meniji 

Podobno kot so elementi igralnosti na sceni igre, so elementi grafičnega vmesnika na sceni grafičnega uporabniškega vmesnika. Odzivajo se na vhodne naprave, lahko jih animiramo, izvajamo fiziko kakršno smo izvajali v sami igri (na primer pritiskanje na gumbe lahko izvedemo z detekcijo trkov med kazalcem in kontrolo). Pogon igre torej lahko zelo podobno obravnava menije in dejansko igro. 

Poleg WIMP‐a (window, icon, menu, pointing device – okno, ikona, meni, kazalec) se v računalniških igrah uporabljajo tudi drugačni grafični uporabniški vmesniki, na primer zaslon HUD. 

HUD (head‐up display) 

HUD je prosojen zaslon, ki prikazuje podatke v vidnem polju uporabnika in s tem prepreči, da bi uporabnik moral pogledati vstran in s tem zgrešil kakšen pomemben dogodek (npr. pilotu ni potrebno gledati navzdol na kazalce naprav): 

Page 10: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   106  

 

V igrah HUD pogosto prikazuje stanje igralca: • energija in življenja • sposobnosti/zmožnosti igralca • podatki o predmetih v lasti igralca • podatki o napredku: točke, soba • meniji • mini zemljevidi • kontekstno odvisni podatki (sporočila, analize objektov igre). 

 Načini, kako so podatki prikazani, se precej razlikujejo od igre do igre: lahko so številski, črte, ikone itd. Nekatere igre predstavijo HUD v kontekstu sveta igrane igre, npr. dirkaške simulacije imajo notranjost avtomobila. 

Dogodkovno voden vmesnik 

Najbolj pogosto se interakcijo med uporabnikom in grafičnim uporabniškim vmesnikom implementira z dogodki (dogodkovno vodeno programiranje). Uporabniški vmesnik je v nekem stanju in ob določenem dogodku (npr. klik miške na določen gumb) se zgodi neka akcija, ki nas pripelje v novo stanje.  

Model–pogled–krmilnik (Model–View–Controller – MVC) [en.wikipedia, Model–View–Controller, 2010] 

Uporabniški vmesnik lahko zgradimo tudi po principu MVC. MVC je oblika arhitekture programske opreme, ki loči logiko aplikacije od uporabniškega vmesnika (vhodi in prikaz) in s tem omogoči neodvisen razvoj vsake komponente posebej: 

Page 11: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   107  

 

Model rokuje s podatki na nivoju aplikacije, se odziva na zahteve o posredovanju stanja (od pogleda) in se odziva na ukaze za spremembo stanja (od krmilnika). V dogodkovno vodenih sistemih model obvesti opazovalce (poglede), da so se podatki spremenili, tako da lahko opazovalci ustrezno reagirajo. 

Pogled predstavi model v takšni obliki, da je primeren za interakcijo: elementi uporabniškega vmesnika. Več pogledov lahko obstaja za isti model, vsak od pogledov ima lahko različne namene uporabe.  

Krmilnik sprejema vhode in jih posreduje kot ukaze modelu in pogledu. 

Javin Swing (del Java Foundation Classes – JFC) skoraj v celoti gradi komponente vmesnika kot sisteme MVC. 

2. Shranjevanje in nalaganje  

Shranjevanje ali serializacija je postopek pretvarjanja podatkovne strukture v pomnilniku (objekt, njegovo stanje) v obliko, ki jo je mogoče shraniti (na primer v datoteko ali medpomnilnik) ali pa prenašati preko omrežne povezave. Kasneje lahko to serializirano obliko ponovno deserializiramo na istem ali drugem računalniku, torej naložimo nazaj v pomnilnik. Pri shranjevanju in nalaganju stanja igre, nastavitev in rezultatov igre, gre tako za serializacijo (shranjevanje) in deserializacijo (nalaganje). 

Mnogo objektno usmerjenih programskih jezikov (Java, Objective‐C, PHP, Python, Ruby, Smalltalk in jeziki iz družine .NET) neposredno podpira serializacijo bodisi v sintaksi, bodisi imajo definiran standardni vmesnik za serializacijo. Pri drugih (npr. C++) lahko dobimo knjižnico s katerimi si lahko pomagamo [en.wikipedia, Serialization, 2010]. 

V Objective‐C se serializacija in deserializacija imenujeta archiving/dearchiving. V Javi mora objekt implementirati vmesnik java.io.Serializable in Java poskrbi za serializacijo. Če želimo napisati svojo kodo za serializacijo in deserializacijo lahko uporabimo vmesnik java.io.Externalizable. 

Glede na to v kakšno obliko se shranijo serializirani objekti ločimo: 

• binarno serializacijo 

• tekstovno serializacijo 

• strukturirano tekstovno serializacijo (serializacijo v XML, JSON, YAML, Property List ipd.). 

Page 12: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   108  

Rezultatov binarne serializacije ljudje ne moremo brati direktno (ker jo težko dekodiramo), zato so se pojavili formati, ki jih lahko ljudje direktno beremo. Na drugi strani pa mora biti tak format še vedno berljiv tudi za računalnike – pojavili so se strukturirani serializacijski formati (npr. XML), ki hranijo podatke v strukturirani tekstovni obliki. Vendar pa so rezultati takšne serializacije precej večji kot pri binarni serializaciji. Ta problem se rešuje z dodatnim stiskanjem strukturiranih tekstovnih oblik (npr. binarni XML) ali pa z uporabo kakšnega drugega formata (npr. JSON), ki ima bolj kompakten opis strukture. 

Primerjava JSON in XML (http://www.scriptol.com/ajax/json‐xml.php): 

JSON  XML[ { "menu": "File", "commands": [ { "value": "New", "action":"CreateDoc" }, { "value": "Open", "action": "OpenDoc" }, { "value": "Close", "action": "CloseDoc" } ] } ]

<?xml version="1.0" ?> <menubar> <menu name="File"> <command value="New" action="CreateDoc" /> <command value="Open" action="OpenDoc" /> <command value="Close" action="CloseDoc" /> </menu> </menubar>

[true, null, -42.1e7, "A to Z"] <array> <element type="boolean">true</element> <element type="null"/> <element type="float">-42.1e7</element> <element type="string">A to Z</element> </array>

 3.  Zvok 

Zvok je bil prisoten v računalniških igrah že od časa Pong‐a, vendar pa je bilo v zadnjih tridesetih letih na tem področju precej napredka. V osemdesetih letih se je večina zvoka in glasbe digitalno sintetizirala (na začetku bolj v obliki piskov) s pomočjo zvočnih kartic. V 90‐ih letih je kapaciteta pomnilniških medijev narasla, pojavil se je CD‐ROM in s tem se lahko namesto sintetizirane glasbe, uporabilo pravo posneto glasbo. Zvoki zvokov ni bilo potrebno več sintetizirati, ker so se lahko posneli vnaprej. Predvajalo se je lahko tudi več zvokov naenkrat (»več kanalov«).  

Primer napredka zvočnih kartic: »Evolution of PC Audio ‐ As Told by Secret of Monkey Island.flv« 

Z naraščanjem kapacitet se je pojavila možnost uporabe sinhronizatorjev za govorjeno besedilo. Možno je postalo prostorsko predvajanje zvoka (angl. surround). Z dodatno strojno opremo in boljšimi procesorji je postalo možno obdelovati zvok v živo: dodajanje odmevov, odbojev, izračun okluzije. S tem so igre precej pridobile na realizmu, saj so zvoki odražali dogajanje in vzdušje na sliki. 

Z naraščanjem kompleksnosti so tudi ekipe zadolžene za zvok naraščale. Na začetku je bil za zvok odgovoren kar programer sam. Sedaj lahko to delo opravlja več ekip: za zvok, za sinhronizacijo, za glasbo. V primerjavi s filmom, kjer zvok spada v post‐produkcijo, je pri igran nanj potrebno misliti že vse od začetka. Če pri zvoku v igri naredimo napako, se lahko zgodi, da bo le‐to igralec moral v najslabšem primeru poslušati ure in ure (slaba glasba, ponavljajoči se zvočni učinki).  

Page 13: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   109  

 

Preden opremimo igro z zvokom, je potrebno po razumeti osnove zvoka. 

Kaj je zvok? 

Zvok je valovanje medija (tipično takšno valovanje narišemo kot amplitudo v odvisnosti od časa: Slika 1). Medij je lahko trdnina ali tekočina (kapljevina ali plin). V trdninah se pojavlja tako vzdolžno valovanje, kot tudi prečno, medtem ko se pri tekočinah pojavlja samo vzdolžno. Pri zvoku navadno mislimo na valovanje zraka (plin – torej obravnavamo samo vzdolžno valovanje) s frekvencami (nihljaji na sekundo) med 20 in 20000 Hz, kar je tudi zaznavni razpon človeškega slušnega sistema. Čeprav se zvok v samem zaznavnem sistemu (Slika 2) prenese tudi skozi druge medije, z vidika programiranja zvoka to ni tako važno. 

 

Slika 1. Amplituda v odvisnosti od časa pri sinusnem valovanju 

 

 

 

Za predvajanje zvoka navadno uporabljamo zvočnike ali slušalke, ki vsebujejo membrano, ki niha s frekvencami, ki so v zvočnem zapisu. Ti vzdolžni valovi pridejo do bobniča, ki je tudi membrana in zaniha z istimi frekvencami.  

Frekvenca in spekter 

Frekvenca zvoka in zaznava višine tona sta tesno povezana. Če vzamemo sinusni ton, potem pri naslednjih frekvencah slišimo takšne tone:  

 

Slika 2. Skica človeškega slušnega sistema: od zvočnih valov, preko bobniča, koščic v polža in kot signal v možgane

Page 14: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   110  

Tabela 1. Frekvence in glasbeni toni 

 

Višje frekvence zaznamo kot višje tone (če ima nek ton 2x večjo frekvenco kot nek drug ton, rečemo, da je za eno oktavo višji). Vendar pa so v naravi zveni sestavljeni iz velikega števila tonov z različnimi frekvencami. Prav tako so glasbeni toni sestavljeni iz več tonov, vendar so pri glasbenem tonu frekvence teh tonov celoštevilski večkratniki frekvence nekega osnovnega tona – le ta določa tudi njegovo višino. Izkaže se, da tudi, če frekvenca tega osnovnega tona ni prisotna v zvoku, možgani manjkajoči ton rekonstruirajo. To se s pridom izkorišča pri majhnih zvočnih, ki zelo težko reproducirajo nizke frekvence (Slika 3). 

 

Slika 3. Velikosti zvočnikov in frekvenčni razpon 

Spekter zvena je porazdelitev frekvenc tonov, ki sestavljajo ta zven. Zveni in glasbeni toni z različnim spektrom imajo različno »barvo« zvoka. Na podlagi te »barve« zvoka lahko ločimo glasbila med seboj. 

Amplituda in glasnost 

Jakost (lahko tudi moč) zvoka merimo v dB (1/10 bela). Izračunamo jo takole: 

Page 15: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   111  

 

Če povečamo amplitudo za dvakrat, se jakost zvoka poveča za 4x. Decibeli merijo relativno jakost zvoka (glede na neko referenco, ker imamo amplitudi 0 neskončno decibelov). Zaznava glasnosti narašča linearno, če vzamemo, da jakost narašča logaritmično: 

Če imamo dvakratno povečanje glasnosti, potem je jakost za 10*log10 (2) = 3,01 dB večja (pogovorno za 3 dB bolj glasno). 

Včasih decibele uporabljamo direktno na amplitudi: 

Če se amplituda poveča za dvakrat 20*log10 (2) = 6,02 dB večja (pogovorno za 6 dB bolj glasno). 

Če se glasnost uporablja kot absolutna skala, se vse primerja z najtišjim možnim zvokom, ki ga človek zazna: pritisk 20 mikro pascalov. Pri igrah nas zanima predvsem relativna vrednosti, ker uporabnik regulira končno glasnost. 

Ker je lažje delati z intervali med 0 in 1 ter linearnimi skalami, raje delamo v linearni skali (v decibele za amplitudo): 

 

Vzorčenje 

Da bi lahko zvok shranili kot podatek na računalnik, je potrebno analogno valovanje spraviti v digitalno obliko. Najbolj pogosto to naredimo z vzorčenjem zvoka. Digitalizacijo zvoka imenujemo tudi ADC (angl. analog to digital conversion), nasprotno je pri reprodukciji – zvočnikih, kjer imamo DAC (digital to analog conversion). V določenih časovnih intervalih (z določeno frekvenco) zajamemo amplitudo valovanja (Slika 4). Kako natančno merimo amplitudo, je odvisno od tega s koliko biti jo zapišemo (angl. bit depth).  

 

Page 16: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   112  

 

 

Napaka, ki nastane zaradi razlike med shranjeno amplitudo in dejansko amplitudo imenujemo kvantizacijska napaka (angl. Quantization Error):  

 

Koliko šuma smo vnesli s premajhnim številom bitov za zapis amplitude lahko izračunamo kot razmerje signal‐šum (angl. Signal‐to‐quantization‐noise ratio). Računamo z amplitudo: 

 

Natančnost je navadno med 4 in 24 biti – vendar večina ljudi ne zazna razlike med 16 in 24 biti, je pa razlika precej opazna med 8 biti (256 vrednosti, SQNR ~48 dB) in 16 biti (65536 SQNR ~96 dB, meja zaznava človeškega ušesa je ca. 100 dB). 

Pri frekvenci vzorčenja je potrebno upoštevati, da je za pravilno reprodukcijo zvoka z neko frekvenco zajemati zvok z vsaj dvakratnikom njegove frekvence (Nyquistova frekvenca). V nasprotnem primeru ne bomo dobili precej popačeno krivuljo (Slika 5) .  

 

Slika 5. Premajhna frekvenca vzorčenja (levo, sredina) in zadostna (desno) 

Glede na omejitve človeškega sluha je frekvenca vzorčenja največ 44kHz. Frekvenca vzorčenja precej bolj vpliva na kakovost kot natančnost zapisa amplitude. 

Predvajanje zvoka in mešanje 

Pot od digitaliziranega zapisa do predvajanja zvoka (Slika 6):  

Slika 4. Vzorčenje 

Page 17: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   113  

Zvočni podatki se najprej preberejo iz medija in se shranijo v pomnilnik. Potem zvok dodelimo zvočnemu kanalu (angl. sound channel). Zvočni kanal je koncept, ki predstavlja pot, na kateri se izvajajo določene operacije nad zvokom. Pogoste operacije: sprememba glasnosti (volume), višine (pitch), pozicioniranje zvoka levo ali desno pri mono zvoku (pan). Ko se vsak posamezen kanal obdela, se zmešajo skupaj (angl. mix), opravijo se procesiranja na vseh podatkih skupaj.  

 

Slika 6. Od zapisa do predvajanja zvoka 

Podatke lahko za obdelavo v pomnilnik prenašamo na več načinov: 

- pri majhnih vzorcih v celoti v pomnilnik - pri večjih se naloži samo del 

 Tok zvoka (streaming audio) 

Uporabimo, kadar moramo večjo datoteko po delih nalagati v pomnilnik. Poznamo dve različici (Slika 7). Pri medpomnilniku s čakalno vrsto imamo dva medpomnilnika: iz enega beremo, medtem v drugega pišemo (polnimo) z diska. Ko prvega preberemo, mora biti drug pripravljen, potem samo zamenjamo medpomnilnika in začnemo brati iz drugega, medtem ko polnimo prvega. Pri krožnem medpomnilniku pišemo in beremo isti medpomnilnik hkrati. Pri čemer moramo poskrbeti, da vedno preberemo dovolj podatkov, da bralni kazalec nikoli ne prehiti pisalnega. Navadno beremo iz diska celotne bloke: konec prebranega in v pomnilnik zapisanega bloka označimo z podatkovnim kazalcem. Ko se bralni kazalec preveč približa podatkovnemu kazalcu, se proži branje bloka. 

 

Page 18: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   114  

 

Slika 7. Primerjava krožnega medpomnilnika in medpomnilnika s čakalno vrsto 

Navadno zvok, ki ga prenesemo v pomnilnik po angleško imenujemo sample (rahlo nerodno poimenovanje, ki se prekriva z vzorčenjem – lahko bi mu rekli instanca). Ponavadi se sampli hranijo v medpomnilniku in hkrati imamo lahko naloženih več tisoč. En kanal lahko »meša« največ en sample. Število kanalov pa je bilo včasih omejeno zaradi stojnih omejitev, danes pa se vrši na programskem nivoju, kjer je teh omejitev manj. 

Kompresija 

Zvočni zapisi na disku se lahko shranjujejo v originalni nestisnjeni obliki (wav  ‐ IBM/Microsoft in aiff – MAC). Ker pa zavzamejo ogromno prostora, so se pojavili različni načini stiskanja. V grobem poznamo dve vrsti: 

• z redukcijo bitov • z  izkoriščanjem psiho‐akustičnih lastnosti zvoka 

 Redukcija bitov – npr. ADPCM (Adaptive differential pulse‐code modulation) 

• hitrejša kot psihoakustični • neizgubno stiskanje • stiska v razmerju 1:4 • se uporablja pri PSP, Nintendo Wii, Nintendo DS 

 Z izkoriščanjem psiho‐akustičnih lastnosti: 

• izgubni, vendar pri ustreznih parametrih izguba razlika skoraj neslišna • stiskanje od 1:5 do 1:25  (dobra kakovost do 1:10) • dva znana formata sta MP3 (če uporabimo v igri imamo problem glede licence) in Ogg Vorbis 

(prost format) 

Page 19: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   115  

Kako programiramo? 

Ni potrebe po pisanju nizkonivojskih mešalnikov (mixer), tako se lahko osredotočimo na programiranje na srednjem nivoju (angl. Middle‐level programming). Imam različne programske vmesnike (API‐je) za različne sisteme: 

• XAudio; prosto dostopen za Win, Xbox; nadomesti DirectSound • OpenAL, kot zvočni ali slišni ekvivalent OpenGL‐ju; na več platformah • SDK‐ji za specifične platforme: PS3, Wii • drugi komercialni API‐ji ‐ pogosto poenostavijo uporabo kakšnih funkcij, uporabno na 

več platformah  Splača se pregledati in spoznati več API‐jev. 

Trendi 

Iz strojne opreme se obdelovanje zvoka seli na programsko opremo: 

- moderni večjedrni procesorji so sedaj dovolj močni, da izvajajo vse zahtevane operacije (pogosto samo na enem jedru) 

- glavna prednost je konsistenca: ni nam potrebno skrbeti ali bo proizvajalec strojne opreme podpiral I3DL2 ali EAX 

- fleksibilnost: programabilni cevovod, lažja uporaba filtrov za post‐procesiranje; nemogoče v večini strojne opreme s fiksno funkcionalnostjo 

- Windows Vista opustil strojno mešanje, moderne konzole Xbox360, PS3 naredijo večino operacij nad zvokom na programskem nivoju 

 Skriptiranje zvoka in integracija v pogon igre 

Programerji naj ne bi (več) programirali zvoka (direktno). Pogon igre mora podpirati izvajanje zvočnih prožilcev in skript. Programerji in pogon igre se torej ukvarjajo samo s skriptami in ne neposredno z zvoki. 

Problemi, povezani z zvokom, ki jih je potrebno rešiti, ko dodajamo zvok v igro: 

• različne variacije zvoka pri ponavljajočih zvokih (npr. koraki) • prekomerno ponavljanje zvoka je potrebno omejiti (npr. 50 hkratnih ali prekrivajočih virov 

zvoka – pri bitki) • sestavljeni ponavljajoči se zvoki (zvoki strojev so pogosto krožno ponavljajoči, vendar se 

zanka zvoka ne začne iz nič, ampak imajo nek uvodni zvok in zaključni zvok; primer dvigala) • narediti relistično ozadje (ambient) z dovolj variacije, da zveni naravno 

 3D zvok 

Človek zazna lokacijo v prostoru, od koder prihaja zvok, na podlagi razlik istega zvoka, ki pride do obeh ušes (časovni zamik, razlike v glasnosti, frekvenci) ‐ Slika 8. 

Page 20: TINR Skripta Predavanj 6

TINR @ FR

Slika 8. Lok

Torej bi laod obeh use na zvoč

Lažja rešitzvočnikih.njegove kpreslikamkamere). 

Odmev (e

Zvok lahk(odboj) pr

Slika 9. Ne

RI, draft v09, 

kacija zvoka v 

ahko te razlikeušes: HRTF (hčnikih ne obn

tev: sistemi z . Ta problem koordinate in mo koordinate

echo) in odbo

o v prostoru reden nas dos

eposreden zvok

Peter Peer ++

prostoru 

e za posamezead‐related tnese dobro in 

več zvočniki reši za nas zvvektor poglede vira v koordi

oj (reverberat

do nas potujeseže (Slika 9)

k, odmev in od

 

zno uho simutransfer functdeluje samo 

(npr. 5.1, 7.1vočni sistem. da (analognoinatni prosto

tion) 

e neposredno.  

dboj 

lirali na slušation) ‐ prenosza enega pos

). Potem je pNajprej je po kameri). Potr poslušalca (

o, lahko pa se

 

lkah ali zvočnsna funkcija, rslušalca. 

otrebno zvoktrebno definiem umestimoanalogno koo

e odbije enkra

nikih, enako orelativna na g

ke samo še poirati poslušalco v prostor tuordinate polig

at (odmev) ali

11

odstranjenih glavo. Vendar 

orazdeliti po ca v prostoruudi vir zvoka igona v prosto

i pa večkrat 

16

: n or 

Page 21: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   117  

 

 

 

+++ 

Page 22: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   118  

 

Slika 10. Amplitudna ovojnica odmeva in odboja glede na podani zvok 

Okluzija/zastiranje (occlusion) ter obstrukcija (obstruction):  

 

Okluzija se zgodi, kadar je med poslušalcem in virom neka ovira, ki samo delno prepušča zvok (npr. samo določene frekvence z zmanjšano amplitudo). (»EAX_Occlusion_Demo.mp4«) 

Upoštevanje pojavov kot so odmev, odboj in okluzija – skupno jih imenujemo učinki okolja (environmental effects) ‐ precej poveča realističnost igre (»EAX Demonstration.flv«). Njihov izračun pa ni preprost, zato so se dolgo časa lahko izvajali samo na ustrezni strojni opremi (zvočne kartice z podporo za EAX). 

EAX in I3DL2 

EAX (Environmental Audio Extensions) in I3DL2 sta standarda za strojno implementacijo učinkov okolja. EAX lahko npr. uporabimo v API‐jih kot sta DirectSound in OpenAL. 

Glavni poudarki EAX‐a so: 

• Odboj (reverberation) in odmev v različnih okoljih 

Page 23: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   119  

• Okluzija (occlusion) in obstrukcija (obstruction):  o okluzija ‐ fizična ločitev vira in poslušalca (nizki toni gredo boljše skozi zidove kot 

visoki) o obstrukcija ‐ oba v istem prostoru, ovira med njima  

• Smer zvoka (Source Directivity) ‐ če zvok usmerimo, ni v vseh smereh enak (nizkim zvokom težko določimo smer, visokim lažje) 

 Kako integriramo zvočne učinke okolja? 

• Učinki so določeni z oblikami sob in materiali (npr. velike kamnite dvorane odmevajo ‐ Slika 11). 

• Ali jih lahko določamo avtomatsko? Poznamo geometrijo objektov, materiale, torej bi lahko izračunali. 

• Ker pa postajajo svetovi vse večji, postaja problem izračuna vse bolj kompleksen. 

 

Slika 11. Določanje učinkov okolja glede na sobe 

Dinamična okluzija 

Dodaten problem se pojavi, ker so svetovi v igri spremenljivi in se pogoji za okluzijo in obstrukcijo dinamično spreminjajo: 

• primer: dinamično spreminjajoča okolica (npr. vrata ‐ Slika 12) • rešujemo lahko z iskanjem poti zvoka, »streljanje žarkov« (ray tracing) • problem kako izračunati v realnem času 

 

 Slika 12. Dinamično okolje in okluzija 

Page 24: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   120  

Glasnost glede na razdaljo (attenuation) 

Poleg zgoraj naštetih učinkov okolja, k realizmu v igrah doprinese tudi upoštevanje drugi lastnosti zvoka, kot na primer padanje glasnosti z razdaljo. Jakost zvoka se zmanjšuje za kvadrat razdalje, vendar ni enaka za vse frekvence. Visoke frekvence se v zraku prej absorbirajo (primer: »Test attenuation of sound at some distance from the soundzone.flv«). 

Dopplerjev pojav 

Frekvenca zvoka se spreminja, če se gibamo proti ali stran od vira ter, če se vir giba proti ali stan od nas. Spremenjeno frekvenco lahko izračunamo po formuli (velja za manjše hitrosti od hitrosti zvoka v mediju): 

 

kjer je: 

f  … opazovana frekvenca 

f0 … oddana frekvenca 

v  … hitrost zvoka v mediju 

vr … hitrost sprejemnika relativno na medij (pozitivna, če se prejemnik premika proti viru) 

vs … hitrost oddajnika relativno na medij (pozitivna, če se vir oddaljuje od medija) 

Frekvenca je višja, ko se nam vir približuje in nižja, ko se od nas oddaljuje (primer: Slika 13). 

Dopplerjev pojav lahko uporabimo npr. v dirkaščinah. 

 

Slika 13. Dopplerjev pojav pri konstantni hitrosti vira, v odvisnosti od razdalje do vira 

Glasba 

Glasba lahko ustvari pravo vzdušje v igri ali pa dá ritem. Glasba lahko igra v ozadju, lahko pa je tudi v ospredju: obstaja več iger, kjer je glasba glavni element igralnosti (npr. Dance Dance Revolution, Guitar Hero). 

Page 25: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   121  

V grobem dva načina zapisa glasbe: 

• digitalni zvočni zapis (CD audio, MP3) • zapis v MIDI‐obliki (in sorodnih oblikah) 

 MIDI (Musical Instrument Digital Interface) in sinteza zvoka 

Tukaj nimamo zvočnega zapisa, ampak je glasba zapisana z dogodki, kot so začetek tona, konec tona, menjava glasbila itd. MIDI‐dogodke posredujemo sintetizatorju zvoka, ki potem ustrezno sintetizira zvok. 

Poznamo dva načina sinteze zvoka: 

• sinteza s frekvenčno modulacijo (angl. FM Synthesis) • sinteza na podlagi obstoječih zvočnih zapisov (angl. Wave Table Synthesis) 

 

 

 

Pri frekvenčni modulaciji zvok poskušamo matematično opisati. Pri sintezi na podlagi obstoječih zvočnih zapisov pa obstoječe zapise spreminjamo in mešamo.  

Page 26: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   122  

Pri sintezi zvoka moramo poleg frekvenc določiti tudi amplitude. Če gledamo zvok v celoti je torej potrebno določiti amplitudno ovojnico (14). Parametri ADSR (attack, decay, sustain, release) opisujejo to ovojnico:  

Attack – čas začetnega dviganja amplitude 

Decay – čas padca amplitude preden se le‐ta stabilizira 

Sustain – amplituda na kateri ostane zvok daljši čas 

Release – čas, od točke, ko se igranje tona zaključi, do točke ko ton dokončno izzveni 

ADSR 

 

 Prednosti MIDI‐ja: 

‐ velikost je zanemarljiva ‐ preprosto je nadzirati, spreminjati in celo generirati MIDI v realnem času 

Slabosti MIDI‐ja: 

‐ težko narediti visoko kakovostno glasbo ‐ učinkovito samo, če vsepovsod dosežemo enako predvajanje,za kar je potreben isti nabor glasbil 

Zaradi problema enakega predvajanja je potrebno poskrbeti za isti nabor glasbil (npr. DLS, SoundFont). DLS (DownLoadable Sound) je standardiziran format za definiranje glasbil, vendar se ne uporablja veliko. 

Da bi lahko imeli zapis glasbe, glasbila (DLS) in zvočni zapis v eni datoteki, se je pojavil predlog standarda za vsebnik iXMF (Interactive eXtensible Music Format). Predvsem naj bi bil namenjen interaktivni glasbi. 

Digitalni zvočni zapis 

Je pravo nasprotje MIDI‐zapisa. Nekaj prednosti zvočnega zapisa: 

Slika 14. Amplitudna ovojnica in ADSR 

Page 27: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   123  

• odlična reprodukcija zvoka je zagotovljena  • skladatelji lahko delajo kakor in s čimer želijo (posnamejo zvoke kakor želijo) 

 Slabosti: 

• slabša interaktivnost (vendar še vedno lahko kreiramo segmente in jih med seboj povezujemo) 

• velike datoteke  Interaktivni glasbeni sistem / dinamična glasba 

Glasba se lahko prilagaja dogajanju v igri, lahko pa z dinamično glasbo zgolj preprečujemo prekomerno ponavljanje melodije.  

Predpogoj za dinamično glasbo je, da lahko skladbo razdelimo na segmente in, da lahko segmente postavljamo v čakalno vrsto. Realiziramo lahko z MIDI‐jem ali z zvočnim zapisom. Vendar se sploh pri slednjem pojavi problem, ker moramo imeti posebne tranzicije med vsakima posameznima deloma (teh je lahko precej). Primer uporabe: 

 

Dinamično menjavanje pesmi   Igra izvede prehod med dvema različnima pesmima ob spremembi okolja, stopnje ali ob spremembi stanja v igri (npr. mirno/boj, normalno igranje/energija pod 10%/do konca le še 30 sekund itd.)   Dinamično menjavanje delov pesmi   Igra izvede prehod med različnim delom iste pesmi, tako da se ohranja tema trenutno predvajane pesmi. Pesem je lahko razdeljena na več delov, ki se lahko ponavljajo – deli so urejeni po intenziteti (mirno, hitrejše, akcija, skrivanje itd.). Dodatno je potrebno še poskrbeti za prehodne dele (npr. uvod, prehodi med intenzitetami).  Dinamično generiranje/komponiranje glasbe 

Igra povsem dinamično sestavlja celotno pesem. Tukaj ne gre več za klasično komponiranje, kjer skladatelj točno določi sestavo določene pesmi, temveč z uporabo različnih okolij za dinamično komponiranje sestavi statistični model skladbe. Primer je igra Spore, kjer so uporabili okolje 

Page 28: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   124  

PureData, s pomočjo katerega so generirali glasbo v odvisnosti od dogajanja v igri (»Spore Music‐Space.flv«). 

Sinhronizacija ustnic z govorom 

Glede na to, da imamo lahko zelo realistične izrise obrazov, potrebujemo tudi realistične animacije govora. V najslabšem primeru se lahko animacija govora sinhronizira na amplitudo zvočnega zapisa. Ta rešitev deluje presenetljivo dobro – še posebej če gledamo od daleč. Obstajata še dve naprednejši metodi s simulacijo izgovarjave posameznih glasov: 

o kombiniramo besedilo, ki je znano v naprej, in zvok o uporabimo izključno analizo zvoka (univerzalno: lahko uporabimo za vse jezike) 

 Napredna uporaba govora 

Predvsem športne igre morajo podpirati komentiranje dogajanja v igri. Ker seveda ni možno vnaprej posneti vsake igre. Poseben problem je vstavljanje imena v komentar, brez da bi se slišalo skupaj zlepljeno. Še težji problem je generiranje govora. 

Prepoznavanje zvoka 

Lahko zaznavamo posamezne besede in besedne zveze ali pa zaznavamo celoten govor. Na ta način lahko računalnik prepozna ukaze in s tem pridobimo še en komunikacijski kanal do računalnika (vendar glede na povratne informacije od igralcev ni najbolj popularno). 

Produkcija zvoka, skupine in vloge 

Zvok je postal v igrah precej pomemben, hkrati so se povečale tudi ekipe in proračuni za realizacijo zvoka. Tako se lahko nekatere igre že primerjajo s filmsko produkcijo. Vendar pa obstajajo pomembne razlike. Pri filmu je zvok je del post‐procesiranja, pri igrah pa želimo, da je zvok integriran v svet, torej ga je potrebno načrtovati od začetka. Proračuni za zvok nekaterih igre presega filmskega: orkestri za veliko količino glasbe, sinhronizacija. 

Kljub temu, da mora biti zvok del igre že od začetka, ne želimo, da je del kode (torej, da je igra podatkovno vodena) in da je možno, da zvok obdelujejo tudi nepoznavalci tehnike. 

Tako imamo pri izdelavi zvoka lahko več ekip: 

• ekipa za glasbo • ekipa za zvok • ekipa za dialoge 

 Pri manjših podjetjih lahko igra ena oseba več vlog. Včasih je bil za vse vloge zadolžen navadno en programer (»un, ki ima zvok čez«). 

Ekipa za glasbo 

Vodja glasbene ekipe (Music Director) 

- ime nadzor nad vsemi visokonivojskimi odločitvami - odloča kakšno glasbo naj se ustvari, koga najeti 

Page 29: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   125  

- ima kontakte glasbenikov, založnikov - odgovoren za licenciranje obstoječih skladb, pesmi - lahko problem, če se ne odloča objektivno (kakšna glasba mu je všeč preveč vpliva na 

njegove odločitve)  Skladatelj 

- piše lastno glasbo (lahko jo tudi snema in meša) - navadno najet za trajanje projekta - pri večji projektih ima pomočnike 

 Glasbeni producent 

- ima vizijo - zagotavlja, da se posnetki »pretakajo« med načrtovalci, glasbeniki in programerji - vendar pa so pri igrah vseeno redki 

 Snemalni tehnik (Recording Engineer) 

- poskrbi za fizični zajem zvoka - pogosto načrtovalec zvoka (angl. sound designer) 

 Mešalni tehnik (Mix Engineer) 

- izenačuje glasnost posameznih posnetkov  Mastering Engineer 

- posluša vse posnetke in išče napake - naredi zadnjo različico - igra pomembno vlogo, če imamo različne proizvajalce zvoka 

 

Ekipa za zvok 

Vodja zvočne ekipe 

- vodi ekipo (ali ekipe) - ime pregled nad resursi in terminskimi plani - izvršuje vizijo producenta (kakšen naj bo zvok in kakšni naj bodo dialogi) 

 Načrtovalec/oblikovalec zvoka (Sound Designer) 

- nepogrešljiv član ekipe - dodajo zvoke: jih ustvarijo ali prenesejo iz resničnega okolja - oblikovalci so največkrat zadolženi tudi za postavitev spiska zvočnih dogodkov, ki preslika 

posamezne zvoke v dogodke igre ali vmesnika  

Page 30: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   126  

 

Implementer 

- doda zvoke okolju, likom, dogodkom - pogosto je kar načrtovalec ali pa v najslabšem primeru programer 

 Ekipa za dialoge 

Agent za sinhronizatorje (Casting Agent) 

‐ je navadno najet ‐ mora imeti kontakte, hitro priskrbeti primerne sinhronizacije za projekt 

 

Vodja sinhronizacije (Voice‐Over Director) 

‐ skrbi za kvaliteto sinhronizacije 

Sinhronizatorji 

‐ sinhronizirajo enega ali več likov ‐ morajo biti dovolj kakovostni 

Urednik dialoga (Dialog Editor) 

‐organizira hrambo datotek posnetih glasov posameznega sinhronizatorja ‐nadzor kakovosti 

Nasveti glede zvoka v igrah 

• O zvoku se odločamo v predprodukciji • Najamemo vodjo ekipe za zvok in naredimo proračun ter terminski plan • Razdelimo naloge na podprobleme in jih razdelimo ustreznim izvajalcem (npr. skladatelji ne 

delajo zvočnih učinkov) • Če je možno imamo pokrite naslednje vloge (ne nujno za celotno trajanje projekta):  

▫ vodja ekipe za zvok, skladatelj, načrtovalec zvoka, zvočni tehnik • Ne ponavljamo zvoka, razen glasbene teme, vendar tudi tam uporabimo variacijo • Glasba naj se sklada z dogajanjem na zaslonu • Glasba naj se sklada s tipom igre 

Page 31: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   127  

 Nasveti za pretepaščine 

• Ne ponavljamo glasbe, zvokov udarcev • Veliko naj bo zvokov za poškodbe, saj se bodo pogosto predvajali • Lahko uporabimo tudi glasbo z besedilom • Glasba naj se sklada z premiki igralcev, energijo itd. 

 Nasveti za dirkaščine 

• Uporabimo prilagodljivo glasbo ▫ Sprememba npr., če igralca lovi policija ▫ Aktiviranje glasbe ob določenih dogodkih ▫ Lik v igri lahko posluša radio  

• Pri zvoku lahko uporabimo resnične in sintetizirane zvoki skupaj  Nasveti za igre z ugankami 

• Prilagodljiva glasba glede na težavnost • Preprečujemo ponavljanje, vključno z zvoki za poteze (vendar ne preveč) 

 Nasveti za športne igre 

• Glasba se spreminja glede na dogodke in stanja (npr. goli, kazni) • Lahko uporabimo glasbo, ki se v resnici uporablja ob prekinitvah • Publika naj zveni čim bolj realistično • Komentator naj se sliši kot po radiu ali televiziji 

 Nasveti za akcijske in pustolovske igre 

• Uporabljamo zvoke okolja in z njimi ustvarimo ustrezno vzdušje • Uporabimo prostorski zvok 

 Dodatni viri: 

[1] Joe Kowalski, Video Games and the User Interface, UX (User Experience) Week 2010: http://www.youtube.com/watch?v=hQe_TS5opu8, 16 min. (Working as a user interface designer in the games industry presents some unique opportunities to engage players. So why are memorable interfaces a rarity? Joe will attempt to answer that question, and he'll offer his perspective on the industry, show some of his work from major titles, and talk about what inspires him.) 

[2] Virtusphere 3D Game Interface: http://www.youtube.com/watch?v=NmpOQZgHUMo, 5 min. (Virtusphere a hollow sphere, which is placed on a special platform that allows the sphere to rotate freely in any direction according to the users steps. Transmitting a virtual environment to our wireless head mounted display, users can move freely 360 degrees creating the most immersive virtual experience. Our innovation will change how we train and entertain people.) 

Naloga na vajah:  

• Za obvezno domačo nalogo tokrat v igro vključite zvoke.  

Page 32: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   128  

• ??? 

 

Povzetek: 

Meniji 

• grafični uporabniški vmesnik (GUI)  o zelo zapleteno področje z malo standardnimi rešitvami  o en velik del so meniji  o drug manjši del je HUD (heads‐up display) ‐ GUI med samim igranjem  o GUI je dodatna scena, ki prav tako potrebuje svoj update za interakcijo in draw za 

izris o najpogosteje se reagiranje na interakcijo implementira z dogodki (event driven 

programming), čeprav s povečevanjem števila kontrol in odvisnosti med njimi postane zelo kompleksen  

o alternativa je MVC pristop, kjer ima kontroler bolj monolitičen nadzor nad prehodi med stanji  

variant MVCja je še veliko   zaenkrat najboljše branje na to temo: 

http://martinfowler.com/eaaDev/uiArchs.html • različne kontrole (gumbi, izbirniki, seznami ipd.)  

o z njimi sestavljamo posamezne zaslone  o kar so elementi igralnosti na sceni igre, so kontrole na sceni GUIja  o odzivajo se na vhodne naprave, lahko jih animiramo ipd.  o za sam pogon je praktično vseeno, ali izvaja fiziko nad igralci v igri ali nad kontrolami 

v meniju  o recimo pritiskanje na gumbe lahko izvedemo z detekcijo trkov med kurzorjem in 

kontrolo • avtomat stanj  

o skrbi za premikanje med različnimi zasloni  o v fazi dizajna ga predstavimo z grafom stanj in prehodov 

Shranjevanje 

• namen • pristopi 

2D zvok 

• zvoki, zvočne instance (sound cue)  • lastnosti zvočnega kanala (glasnost, usmerjenost (pan))  • efekti (spreminjanje višine (pitch shift), dsp efekti (reverb ... )) 

3D zvok 

• pozicioniranje zvokov  • glasnost glede na razdaljo (attenuation), dopplerjev efekt 

Glasba 

Page 33: TINR Skripta Predavanj 6

TINR @ FRI, draft v09, Peter Peer ++   129  

• oblike glasbe  o v notni obliki ‐ določeno katere note igra kateri inštrument (midi, musicXML, mod)  

za predvajanje potrebno uporabiti nek sintetizator ali pa sampler zvokov o v zvočni obliki ‐ pesmi so že posnete kot zvočni signal (mp3, wma ...) 

• glasba kot zvočna instanca  o streaming namesto, da je naložen v celoti v ramu 

• dinamična glasba  o dinamično menjavanje pesmi  

igra izvede prehod med dvema različnima pesmima   ob spremembi okolja, stopnje   ob spremembi stanja v igri  

mirno/boj   normalno igranje/življenje pod 10%/do konca le še 30 

sekund ... o dinamično menjavanje delov pesmi  

igra izvede prehod med različnim delom iste pesmi, tako da ohranja temo trenutno predvajane pesmi  

pesem razdeljena na več delov, ki se lahko ponavljajo   deli urejeni po intenziteti (mirno, hitrejše, akcija, skrivanje ... ) 

dodatno so tu še prehodni deli (uvod, prehodi med intenzitetami ... )   včasih je tak način podpiral DirectMusic, danes ni več v uporabi, namesto 

tega se dela direktno z  o dinamično komponiranje  

igra povsem dinamično sestavlja celotno pesem   ne gre več za klasično komponiranje, kjer skladatelj točno določi sestavo 

določene pesmi, temveč z uporabo različnih okolij za dinamično komponiranje sestavi statistični model skladbe.  

primer   Spore, v urejevalnikih