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:


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):


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


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:


(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):


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:


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:


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:


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):


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:


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.).


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).


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


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:


Č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).


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


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.


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)


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.

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


+++


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


• 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


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).


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.


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


• 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


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


- 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


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


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.


• ???

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


• 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

Documents

TINR Skripta Predavanj 6