Vývoj technologií počítačových her

UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Vývoj technologií počítačových her Autor BP: Jan Veselý Vedoucí BP: Ing. David Hartman, Ph.D. 2017 Praha

Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma vývoj technologií počítačových her vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V. dne...

Poděkování Děkuji svému vedoucímu bakalářské práce Ing. Davidu Hartmanovi Ph.D. za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

Vývoj technologií počítačových her Development of computer games technologies 6

Abstrakt Nejtěžší částí na poli herního průmyslu byly vždy technologie. V časech minulých byly herní technologie převážně o nízko-úrovňové optimalizaci, tj. psaní kódu, který na cílové platformě počítačů poběží rychle a efektivně. Nicméně v minulých patnácti letech nabyly hry na komplexnosti a vývoj na složitosti. Dnes je při výrobě hry primárním cílem učinit kód funkční a konečným produktem co nejvíce uspokojit původní vizi projektu. Dříve byli autory převážně jednotlivci nebo drobné skupiny vývojářů pracující převážně na 2D vykreslování. Nejvíce požadovanou vlastností hry byla hratelnost, tedy schopnost zabavit hráče na co nejdelší periodu času. Nyní hry produkují sofistikovaná herní studia, přičemž každé větší studio vlastní svůj herní engine a dokončení projektu trvá měsíce, někdy i roky. Na takovém projektu se podílí větší počet lidí s jasně určenými rolemi. Každá pozice je sama o sobě natolik sofistikovaná a náročná, že v odvětví herního průmyslu máme pouze velmi omezené procento kvalifikovaných lidí. Naprostý nedostatek odborníků je v oblasti game-designu. Game-design je schopnost navrhovat hry tak, aby byly hratelné, zajímavé a hlavně realizovatelné. Nedostatek je rovněž grafických designerů. Náplní práce grafika je kreativně navrhovat herní prostředí a postavy. Vytvořené návrhy dokáží konvertovat do digitální podoby a předat je programátorům, nejčastěji ve formátu 2D spritů, animací nebo 3D modelu. V dnešní době slouží jako jádra her takzvané herní enginy. Jedním z těchto enginů je rychle se rozvíjející Framework Unity. Unity je flexibilní a velmi rozsáhlá platforma pro tvorbu multiplatformních 2D her, 3D her a animací. Jako obrovský a stále rostoucí ekosystém usnadňuje a rozšiřuje možnosti herních vývojářů. Unity je plně podporovanou platformou, kterou lze použít k sestavení her pro prostředí jako je iphone, Mac, Windows a další. Klíčová slova: vývoj, hry, herní engine, unity, game-design, herní technologie 7

Abstract The most difficult part in the field of gaming industry has always been technology. Gaming technologies used to be mostly about low level optimization, i. e. writing code which would run smoothly and efficiently on target group of computers. However, in last fifteen years, games have grown more complex and their development more difficult. Nowadays, the primary goal while developing a game is simply to make the code work and to hold to the original vision of the project as much as possible. Previously, the authors were mostly individuals or small groups of developers working mostly on 2D rendering, and most desired aspect of the game was gameplay i.e. ability to entertain players for the longest time possible. Now there are sophisticated development studios, bigger ones owning their own game engine and the project takes months, sometimes years. These projects involve dozens of people with strictly defined roles. Each role itself is so sophisticated and demanding that the number of qualified people is very low. Complete lack of people is in the field of game design. Game design is an ability to design the games so that they are playable, interesting and above all feasible. There is shortage of graphic designers as well. Graphic designers are people who are able to design game characters and environment. They are of course able to digitize these designs and hand them over to coders in the form of 2D sprites, animations or 3D models. Nowadays, the so-called game engines serve as the game cores. One of these engines is a rapidly developing Framework Unity. Unity is a very flexible and large platform for creating cross-platform 2D games, 3D games and animations. As a huge and evergrowing system, it extends the capabilities of game developers, who can use it as fully supported platform to build games for iphone, Mac, Windows and other environments. Keywords: development, games, game engine, unity, game-design, game technologies 8

Obsah Úvod... 12 1. Historie herních technologií... 14 1.1 Čtyřicátá léta... 14 1.2 Padesátá léta... 15 1.3 Šedesátá léta... 17 1.4 Sedmdesátá léta... 18 1.5 Devadesátá léta a začátek třetího tisíciletí... 23 2. Technologie moderních her... 24 2.1 Herní hardware... 24 2.1.1 Centrální procesorová jednotka... 24 2.1.2 Grafická procesorová jednotka... 25 2.1.3 Využití GPU... 29 2.1.4 GPU Akcelerace... 29 2.1.5 Heterogeneous System Architecture... 32 2.1.6 OpenCL benchmark... 32 2.2 Grafika a 3D Rendering... 35 2.2.1 Kartézská soustava souřadnic základem modelu... 36 2.2.2 Knihovny pro usnadnění vykreslování... 37 2.2.3 Shadery... 37 2.2.4 Funkcionalita základních shaderů... 37 2.2.5 Grafiky, textury a sprity... 39 2.2.6 3D Modelování... 40 2.2.7 Osvětlení... 41 2.2.8 Globální osvětlení... 42 2.3 Fyzika... 43 9

2.3.1 Physics Engine... 44 2.3.2 Rozdělení jader pro fyziku... 45 2.3.3 Vektory... 46 2.4 Hra více hráčů... 47 2.4.1 Lokální hra více hráčů... 47 2.4.2 Rané přístupy k síťovaným hrám... 47 2.4.3 Místní síť... 48 2.4.4 Online hry... 49 2.4.5 Konektivita... 49 3. Herní engine... 51 3.1 Teorie herních enginů... 51 3.2 Unity 5.0... 52 3.2.2 Založení nového projektu a scény... 52 3.2.3 Uživatelské rozhraní a import assetů... 53 3.2.4 Herní objekt... 54 3.2.5 Herní prostředí a šablony objektů... 55 3.2.1 Fyzika s Rigidbody... 56 3.2.2 Player Controller... 57 3.2.3 Animátor a Animace... 59 3.2.4 Programování kamery a rekapitulace... 61 3.3 WEBGL... 62 3.3.1 Základy WEBGL... 63 3.3.2 Immediate-mode API... 63 3.4 Build hry... 64 3.4.1 Kompilace Unity projektu do WebGL... 65 Závěr... 67 10

Summary... 69 Seznam použitých zdrojů... 71 Seznam obrázků... 75 Seznam tabulek... 76 Seznam příloh... 77 11

Úvod Jedním z cílů této práce je upozornit, že herní technologie a jejich rozvoj mají významný podíl na současné podobě IT. Díky poptávce herního průmyslu je stále vyvíjen tlak na výkonnost počítačového prostředí. Společně se zvyšováním požadavků na kvalitu her jsou kladeny vyšší požadavky na kvalitu hardwaru a softwaru, které následně obohacují všechna odvětví informačních technologií. Videoherní průmysl (častěji nazýván herní průmysl) je odvětví zabývající se tvorbou a prodejem videoher. Tato práce se zabývá především tvorbou počítačových her, k jejichž vzniku je zapotřebí desítky specializovaných profesí (příkladem může být herní návrhář, programátor, grafik). Dějiny videoher sahají téměř sedm desetiletí do minulosti a dnes jsou součástí populární kultury. Ačkoliv se v Československu tento trend uchytil až po roce 1989, stal se herní průmysl jedním z nejrychleji rostoucích odvětví v Česku. Jeho obrat se ročně pohybuje v řádech miliard českých korun a stále roste. Zprvopočátku byly na poli herního průmyslu největším problémem technologie. Programování bylo převážně o psaní nízko úrovňové optimalizace, tj. psaní kódu, který na cílové platformě počítačů poběží rychle. Nicméně v posledních patnácti letech se i do průměrných domácností dostaly relativně výkonné počítače, tablety a další elektronika. Nyní již herní studia, jakožto společnosti zabývající se vývojem her, cílí na obrovské množství hráčů s dostatečným výpočetním výkonem. Při vývoji her je proto primárním cílem jednoduše učinit kód funkční a co nejvíce uspokojit konečným produktem původní vizi projektu. Každé větší herní studio si vytvořilo a udržuje svůj vlastní, herní engine. Herní engine je framework, který ulehčuje vývoj počítačových her. V této práci se budeme věnovat hernímu enginu Unity a technologiím, které s vývojem her souvisí. Příkladem mohou být technologie pro sdílení herní relace mezi více hráčů (multiplayer) nebo frameworky pro zobrazení 3D efektů ve webových prohlížečích. V práci bude také věnován prostor procesorovým jednotkám a jejich rozdílům. Dále základům vykreslování 3D grafiky a základním principům fyziky ve hrách. Cílem této práce tedy je předat ucelené informace začínajícím herním vývojářům. Souhrnně podat informace o dějinách vývoje technologií počítačových her. Cílem praktické části je uvedení příkladu práce s Unity a detailní popis rozhraní, které framework nabízí. Výstupem praktické části je prototyp archaické hry Mario. 12

Ve zpracování této bakalářské práce je využito autorových znalostí, znalostí získaných z odborné literatury a z internetových článků. 13

1. Historie herních technologií Videohry jsou jedním z významných fenoménů našeho století a jejich rozmach ve společnosti je stále znatelnější. Videohernímu průmyslu se daří díky neustálému přílivu inovací v odvětví grafických a procesorových čipů, se vzrůstající komunitou herních vývojářů a se zvýšeným využíváním internetu v multiplayerových hrách. Počítačová hra či videohra je program s interaktivním obsahem, který lze spustit na různých elektronických platformách. Příkladem může být osobní počítač, mobilní telefon nebo specializovaná herní konzole jakou je třeba PlayStation. Hry neměly vždy takovou podobou, jakou známe dnes. Tento průmysl se vyvíjel velmi dlouho a měl obrovský vliv na vývoj informačních technologií. Herní vývojář by měl alespoň stručnou historii herního průmyslu znát. Právě této historii se věnuje první kapitola této práce. 1.1 Čtyřicátá léta Leckdo považuje rok 1947 za rok vzniku první hry počítačového světa. Hra "Cathode Ray Tube Amusement Device", vyvinutá Thomasem Goldsmithem a Estlem Mannem, byla vyvinuta na technologii katodových trubic a pracovala velmi jednoduše. Osm katodových trubic bylo využito k simulaci střely odpálené na cíl. Cílem hry bylo trefit raketami, zobrazujícími se jako tečky, cíl svítící na radaru. Hru bylo možné ovládat několika tlačítky (změna dráhy a rychlosti střely). Zařízení používalo čistě analogovou elektroniku. Hra nevyužívala žádnou paměť a nebylo zapotřebí nic programovat. Grafický výstup byl zobrazován pomocí fólie na CRT monitoru. Je to vůbec první známé využití CRT monitoru pro herní účely. Hra byla inspirována radary použitými ve druhé světové válce. Tato hra nebyla nikdy prodána veřejnosti, takže i když je považována za první videohru, neměla na vývoj budoucnosti počítačových her prakticky žádný vliv. 1 1 The 'CRT Amusement Device' that spawned a multi-million dollar industry. New Atlas [online]. Australia: Bridget Borgobello, 2011 [cit. 2016-11-11]. Dostupné z: http://www.gizmag.com/first-videogame/18695/ 14

Obrázek 1: CRT Amusement Device Zdroj: http://www.gizmag.com/ 1.2 Padesátá léta V roce 1952 Alexander S. Douglas na základě tehdejší studie o interakce člověka s počítačem vyvinul hru OXO. OXO byla grafická verze známé hry piškvorky. Hra byla opět veřejnosti nedostupná, neboť používala archaický počítač EDSAC, který byl exkluzivně zkonstruován profesorem Mauricem Wilkesem a jeho týmem na univerzitě Cambridge. EDSAC byl první v praxi využitý počítač pracující s uloženým programem. Používal se převážně k řešení matematických úloh a výstup zobrazoval na CRT monitoru. OXO hrál vždy jeden hráč proti umělé inteligenci EDSACu. Jako vstup hráči sloužila rotační číselnice. Na číselnici hráč zadával číslo, které představovalo pozici ve dvoudimenzionálním poli. 15

Obrázek 2: EDSAC a OXO spuštěné v emulátoru. Vpravo 2D pole s pozicemi Zdroj: EDSAC https://wikipedia.org, ostatní vlastní zpracování Za zmínku určitě stojí i nukleární fyzik William Higinbotham, neboť mnoho lidí přiznává vynález videoher právě tomuto muži. V roce 1958 vytvořil hru zvanou Tennis For Two a to proto, aby zabavil návštěvníky v Národní laboratoři Brookhaven v New Yorku. Hra byla postavená na analogovém počítači a grafický výstup byl zobrazen na osciloskopu. Jednalo se o zjednodušený tenisový kurt. Míček musel být odehrán přes zobrazující se síť a to za pomocí objemného ovladače, na němž byla tlačítka pro ovládání trajektorie a odpálení míče přes síť. Jako první tato hra počítala s jednoduchou simulací fyziky, neboť míček podléhal gravitaci. 2 Jednalo se o velmi důležitý milník pro budoucnost videoher, neboť hra byla zpřístupněna veřejnosti a došlo tedy ke styku obyčejného člověka s videohrou. Hra byla následně demontována v roce 1959. Doteď si nadšenci podle zveřejněných schémat tuto hru konstruují. 2 CAMPBELL-KELLY, 2013 16

Obrázek 3: Rekonstrukce hry Tennis For Two 1.3 Šedesátá léta Zdroj: https://scratch.mit.edu Na přelomu šedesátých let už mnoho jednotlivců zkoušelo programovat hry na univerzitních počítačích. Hry byly převážně programovány studenty v jejich volném čase, nicméně z důvodu stále velké nedostupnosti hardwaru bylo těchto her jen velmi málo a většina byla velmi brzy zapomenuta. Taková skupina studentů spolu s osobností významného počítačového vědce Steva Russella vyvinula v roce 1961 hru Spacewar. Hra byla pro dva lidské hráče, každý ovládal jednu vesmírnou loď schopnou pohybu a útočení za pomoci raket. Uprostřed mapy byla černá díra, která k sobě oba hráče vlivem gravitace stahovala. Hra tedy znovu počítala s jednoduchou fyzikou, i když na rakety se gravitace nevztahovala, neboť na to již nezbyl procesorový výkon. Spacewar využívala platformu PDP-1 (Programmed Data Processor-1) od společnosti DEC (Digital Equipment Corporation). Počítač PDP-1 byl vybaven feromagnetickou pamětí organizovanou do slov s poněkud neobvyklou šířkou 18 bitů. Maximální kapacita paměti byla 144 kilobajtů. Počítač byl rovněž vybaven jednotkou pro děrné štítky. Počítačů bylo celkově přes padesát a vlastnili je převážně větší firmy či instituce. V mnoha ohledech se jedná o velmi zajímavý počítač, který zaznamenal hned několik prvenství a jeho vliv nepřímo vedl ke vzniku minipočítačů, operačního systému UNIX i hackerské subkultury. 3 3 PDP-1: počítačový dědeček na cestě k unixu. Root.cz [online]. Praha: Pavel Tišnovský, 2009 [cit. 2016-11-11]. Dostupné z: https://www.root.cz/clanky/pdp-1-pocitacovy-dedecek-na-ceste-k-unixu/ 17

Obrázek 4: DEC PDP-1 Obrázek 5: Spacewar na PDP-1 obrazovce zdroj: http://www.root.cz/ Spacewar byla následně rozvinuta a použita v prvním hracím automatu založeném na mincovém principu. Mincový princip bude dále rozveden v následujících kapitolách. 1.4 Sedmdesátá léta Do této doby bylo ke hraní počítačových her stále potřeba drahých a složitých mainframů. Příkladem může být výše zmíněná hra SpaceWars, kterou bylo možné hrát jen na počítači PDP-1. Vývoj her byl stále o znalostech hardwaru a vyvinout hru tedy, kromě navržení hratelnosti, znamenalo kreslení elektronických schémat a nekonečného pájení součástek. Tento koncept vývoje her se ještě pár let nezměnil. Ovšem potenciál pro masové využití her v domácnostech na tomto mladém trhu byl, odhalil jej Ralph Baer. Grafický výstup byl stále zobrazován CRT monitory, které byly tehdy pro mainframy běžné. Nikoho nenapadlo použít jako grafický výstup to, co bylo tehdy již pro každou domácnost běžné. Použijme slova Ralpha Baera: V roce 1966 bylo okolo čtyřiceti miliónů televizí v domácnostech na území Spojených států amerických. Nemluvě o dalších miliónech televizí ve zbytku světa. Tyto spotřebiče doslova prosily i o jiné využití než jen zobrazování komerčních televizních vysílání. Tento nápad jsem 18

měl již v roce 1955, ale tehdy mi to vedení mé firmy zatrhlo. Od roku 1966 myšlenky na hraní her pomocí televizoru již nešlo zadržet. 4 Ralph Baer tento koncept nazval Televizní hry. Později se televizní hry přejmenovaly na videohry. V roce 1968 vznikl první prototyp herní konzole, na které se po připojení k televizi dalo několik jednoduchých her hrát. Baerovi tehdy asistovali dva další inženýři. Byli to William Harrison a William Rusch. Prototyp odkoupila společnost Magnavox a v roce 1972 jej vydala pod jménem Odyssey. Tento přístroj se tak stal první distribuovanou herní konzolí na světě. Podle webu bmigaming v roce 1971 Nolan Bushnell spolu s Tedem Dabneyem předělali hru SpaceWar. Tento koncept od něj odkoupila společnost Nutting Associates a vyrobila přes 1500 hracích automatů s hrou Computer Space. Tento automat se tak stal prvním masově vyráběným hracím automatem na mince s videohrou v celém počítačovém světě. Prvním podobným automatem, který ovšem nikdy nebyl komerčně prodán, byl automat s hrou Galaxy game. Ten byl nainstalován na Stanfordově univerzitě v Kalifornii. Obě hry byly založené na originální hře Spacewar. Obrázek 4 Computer space automat Zdroj: http://www.bmigaming.com/videogamehistory.htm 4 Genesis: How the Home Video Games Industry Began. Ralph Baer [online]. Rodalben: Ralph Baer, 2013 [cit. 2017-01-10]. Dostupné z: http://www.ralphbaer.com/how_video_games.htm 19

Computer space ve skutečnosti nebyl úspěšný projekt. Veřejnost hře nepropadla. V jednom z pozdějších rozhovorů Bushnell vysvětloval, v čem viděl hlavní problém své první hry: Abyste mohli hrát, museli jste si přečíst návod. Lidé ho nechtěli číst. Abych byl úspěšný, musel jsem přijít s jinou hrou. S takovou, aby lidé věděli, jak ji hrát. Něco tak jednoduchého, že by to mohl hrát i opilec v nějakém baru. 5 Dle sbírky Chantala 6 založil Nolan Bushnell v roce 1972 spolu s Tedem Dabneyem společnost Atari. Svůj herní průmysl nastartovala původní hrou PONG. Hra byla založena na stolním tenise a princip byl jednoduchý: hra byla pro dva lidské hráče, přičemž každý ovládal obdélník v pravé nebo levé straně. Plošinka se pohybovala vertikálně a smyslem bylo nenechat míč proniknout za hranice vaší plochy. Atari prodala přibližně 38 tisíc automatů s hrou PONG. Později se PONG dostal i do domácností jako konzole, kterou bylo možné připojit k televiznímu monitoru. Domácí verze pongu byla ještě úspěšnější než automat. Obrázek 5: Automatová hra PONG Zdroj: http://pongmuseum.com 5 Historie firmy Atari (1972-2002). Historie firmy Atari [online]. Praha: Historie firmy Atari, 2006 [cit. 2016-12-01]. Dostupné z: http://historie.atari.sweb.cz/ 6 All about Pong. Pongmuseum.com [online]. Paris: Sylvain De Chantal, 2001 [cit. 2017-01-10]. Dostupné z: http://pongmuseum.com/faq/ 20

S úspěchem Atari přišel i první soudní spor v dějinách herního průmyslu. Cituji článek z webu zabývajícího se historií společnosti Atari: Zanedlouho po veřejné demonstraci Pongu objevila jeho existenci firma Magnavox a jelikož ji velmi připomínal její vlastní hru TV tenis z konzole Oddysey, následovala soudní žaloba za údajně ukradený nápad a patent. Ať už byl původce myšlenky na Pong kdokoliv, Magnavox měl registrován U.S. patent na "Elektronické hry promítané na televizní obrazovku" a to byl zjevně Bushnellův Pong také. Bushnell se bál jít do otevřeného soudního sporu (prohra by Atari zruinovala) a proto se radši s Magnavoxem dohodl na mimosoudním vyrovnání a zaplatil raději 700 tisíc USD za licence. Magnavox si mimo to vymínil roční exkluzivní práva na všechny případné nové produkty Atari - na což Bushnell reagoval promptně - a vše nové si rok pozdržel. Paradoxně však zřejmě ukradený Pong pomohl oběma stranám. Atari díky němu i přes velkou pokutu slušně vydělávala a Magnavox měl peníze na další obchody se svojí konzolí Oddysey. Další zisk měl Magnavox ostatně z prodeje licence dalším výrobcům her, neb se záhy ukázalo, jak důležitý patent to ve skutečnosti vlastní. 7 Později v roce 1978 vydává konkurenční společnost Taito arkádu Space Invaders. Touto hrou začala ve Spojených státech zlatá léta hracích automatů, neboť hra inspirovala desítky nových výrobců ke vstupu na trh a k vydávání vlastních videoher. Arkádové herní automaty zůstaly obrovským hitem až do konce 80. let. Arkádové hry byly prvním žánrem ve video herním průmyslu. Hrají se nejčastěji na kola, kde každé další kolo je obtížnější než kolo předchozí. Vyznačují se převážně tím, že vyžadují postřeh, hbitost prstů, logické myšlení a trpělivost. Zlatá éra arkádových videoher v sedmdesátých letech byla éra velkých technologických pokroků. Herní vývojáři se stále potýkali s problémy nedostatku procesorových prostředků a velikostí operačních pamětí. Tento nedostatek stále tlačí počítačové technologie kupředu. 8 Počítačové hry se šířily napříč Severní Amerikou, Evropou a Japonskem. Video herní automaty se šířily do supermarketů, barů, likérek, restaurací a dalších podobných podniků. Netřeba podotýkat, že hry si zamilovali hlavně mladí lidé. Průměrný automat v té době dokázal vydělat okolo šedesáti amerických dolarů týdně. 7 Historie firmy Atari (1972-2002). Historie firmy Atari [online]. Praha: Historie firmy Atari, 2006 [cit. 2016-12-01]. Dostupné z: http://historie.atari.sweb.cz/ 8 KENT, 2001 21

Kromě Atari existoval další obrovský gigant zabývající se arkádami. Byla to japonská společnost Namco. Nejprodávanějším titulem společnosti Namco byl v osmdesátých letech Pac-Man. Tyto dvě společnosti zápasily o první místo na trhu mnoho let a existují do dnes. Kromě těchto gigantů vznikly ještě Sega, Nintendo, Capcom, Konami, Cinematronics a další. Hry se stále rozvíjely i v nekomerčním sektoru. Byly to snahy převážně studentů větších univerzitních škol. Většina her se nedochovala z důvodu uložení na tehdejších magnetických páskách, které již dávno zanikly. Z tohoto důvodu se o této kategorii her ví jen velmi málo. Přesto zmiňme některé důležité milníky: 9 Rok 1974: Objevují se tituly, jako Maze Wars (Války v bludišti) první pokusy o trojrozměrné hry z pohledu první osoby. Rok 1975: Objevila se první jednoduchá, neoficiální implementace hry Dungeons and Dragons pojmenována Dungeons. Byla to prakticky první videohra, která spadala do tehdy ještě neexistujícího žánru RPG. Rok 1977: Skupina studentů naprogramovala první, textový, letecký simulátor nazvaný Air. Tato skupina se zasloužila o předchůdce grafických her pro více hráčů. Rok 1980: Vzniká titul Rogue. Následník hry Dungeons a první RPG hra s náhodně generovaným prostředím. Skupina nespokojených programátorů společnosti Atari se v roce 1979 odtrhla a založila vlastní společnost s názvem Activision. Důvodem byly nízké platy herních programátorů tehdejší doby. Zpočátku se zaměřovali na vývoj konzolových her pro herní konzole od Atari. Když začal trh s herními konzolemi upadat, začala se společnost zaměřovat na hry pro domácí počítače. Společnost Activision existuje do dnes. 9 KENT, 2001 22

1.5 Devadesátá léta a začátek třetího tisíciletí Devadesátá léta a počátek třetího tisíciletí přinesl mnoho vylepšení souvisejících s herním průmyslem. Mezi ně patří: Popularizace uložišť založených na CD-ROM a lepší distribuce softwaru. Popularizace operačních systému s grafickým rozhraním (Microsoft Windows, Mac OS,...) Pokročilejší 3D grafiku a masivní adaptaci grafických karet do osobních počítačů. Zdokonalení a sofistikace CPU. Miniaturizace hardwaru a mobilních zařízení, které vedlo k hrám pro mobilní přístroje. Během tohoto období vzniklo několik nových, herních konzolí. Tyto konzole byly později rozděleny do takzvaných čtvrtých, pátých a šestých generací. Čtvrté generace byly převážně 16-ti bitová zařízení a známým zastupitelem je například Game Boy od společnosti Nintendo. Game Boy se stal nejprodávanější konzolí devadesátých let. Za pátou generaci herních konzolí jsou považována herní zařízení vyvinuté mezi lety 1994 a 2000. Byly to již 32 a 64 bitové počítače. Mezi hlavní představitele patří Nintendo 64, PlayStation od společnosti Sony a Sega Saturn vyráběn společností Sega. Toto období je převážně významné expanzí herní grafiky do třetího prostoru. 2D sprity tak byly nahrazovány polygony a ty byly zobrazovány ve 3D prostoru. Tyto technologie budou dále popsány v dalších kapitolách. 10 Dvacátá léta začala prosazovat nutnost zavedení a popularizace internetu, který se ke konci druhého tisíciletí stal základem pro síťované a online hry. Video herní průmysl generoval světově tržby ve výši téměř 20 biliónů amerických dolarů. 10 The History Of Video Arcade Games. BMIGaming.com [online]. Florida: BMIGaming, 2012 [cit. 2017-01-10]. Dostupné z: www.bmigaming.com/videogamehistory.htm 23

2. Technologie moderních her Nové tisíciletí s sebou přineslo nové termíny a postupy. Informační technologie začaly být standardizovány a postupně na každou IT oblast vznikaly frameworky, které práci s danou problematiku ulehčovaly. Společnosti zabývající se programováním her začaly být nazývány herní studia a postupně se z garáží přesunuly do vlastních sídel. Herní studia dále vyvinula vlastní frameworky pro usnadnění tvorby videoher. Těmto frameworkům se začalo říkat Game Engines neboli herní jádra a s jejich pomocí se vývoj her zefektivnil a takřka standardizoval. Tituly vydané za pomoci jednoho jádra byly jasně rozeznatelné od titulů postavených na jiných enginech. V této práci jsme si jako příklad herního frameworku vybrali open-sourcový projekt Unity. Herní vývojář by nejdříve měl pochopit základní funkcionality, které Unity a jiná herní jádra musí řešit, než se do vývoje her sám pustí. Následující kapitoly se věnují právě této problematice. 2.1 Herní hardware Abychom dále mohli rozebrat jednotlivé herní technologie, frameworky a práci s 3D grafikou, musíme nejdříve porozumět nejnižší úrovni celého modelu. V následujících kapitolách se budeme věnovat rozdíly mezi centrální procesorovou jednotkou, grafickým procesorem a možnostmi akcelerace výkonu aplikací za využití grafických procesorů. V kapitole jsou pro příklady používány procesorové jednotky, drivery a jiný software od firmy Intel a společnosti NVIDIA. 2.1.1 Centrální procesorová jednotka Centrální procesorová jednotka (zkratka CPU, anglicky Central Processing Unit) vykonává základní strojové instrukce, ze kterých je složen počítačový program a obsluhuje jeho vstupy a výstupy. Historicky CPU obsahoval mnoho elektronických součástek, avšak s příchodem integrovaných obvodů byly všechny potřebné obvody sloučeny právě do jednoho integrovaného obvodu, který je označován jako mikroprocesor. Každá architektura procesoru definuje svůj vlastní strojový jazyk. Vyšší programovací jazyky jako je JAVA, C# a mnoho dalších jsou za pomocí překladačů nebo interpretů do strojového jazyka překládány. 11 11 PATTERSON, 2013 24

Moderní procesory obsahují více fyzických jader. Příkladem je procesor INTEL CORE i5 obsahující čtyři fyzická jádra. Některé procesory podporují takzvaný Hyper- Threading, který umožňuje fyzická jádra virtualizovat a zvýšit tak jejich počet virtuálně na dvojnásobek. Takovým procesorem je například INTEL CORE i7. Takový procesor zvládne obsluhovat až osm vláken paralelně. Maximální výkon procesoru se tak sice dramaticky zvýší, ale je třeba mít na paměti, že počet fyzických jader zůstává stejný. Z toho jasně vyplývá, že nelze očekávat zvýšení výkonu lineárně. Centrální procesorová jednotka zastává takzvaný SISD (Single Instruction, Single Data). Tyto procesory jsou dobré ve vykonávání operací typu: načíst vstup, provést s ním operaci, přesunout ho jinam, zapsat výsledek a tak dále. Vykonávají jednoduché operace, které načtou jeden nebo více vstupů a vrátí jeden výsledek. Tyto operace jsou vykonávány sekvenčně. 2.1.2 Grafická procesorová jednotka Grafická procesorová jednotka (zkratka GPU, anglicky Graphic Processing Unit) je specializovaný mikroprocesor, který zajišťuje rychlé grafické výpočty a změny obsahu framebufferu, které jsou posléze zobrazovány na displeji. Moderní grafické procesory jsou dnes již využívaný i pro jiné druhy výpočtů než jen ty grafické. Výkonu grafických čipů využívá například obor kryptoanalýzy. V dalších kapitolách tyto možnosti probereme. Operace GPU jsou dobře paralelizované a manipulují grafickými daty velmi rychle. Termín GPU byl poprvé představen firmou NVIDIA v roce 1999, kdy byl představen produkt GeForce 256, jakožto první grafický mikroprocesor. 12 Grafická procesorová jednotka zastává takzvaný SIMD (Single Instruction, Multiple Data) přístup, což znamená, že stejná operace je vykonávána na větším množstvím dat paralelně. Příkladem takové operace může být následující: Mějme na vstupu 128 hodnot X1- X128 a 128 hodnot Y1-Y128. Tyto hodnoty mezi sebou vzájemně v párech vynásobme a vraťme 128 výsledků. Procesor, který zastává SISD přístup by musel provést 128 operací (+ I/O operace do paměti). SIMD procesory to dokážou v jednotkách kroků. Záleží na tom, kolik čísel se jim vejde do registru. 13 12 ŠILC, 1999 13 NAM, Byeong-Gyu a Hoi-Jun YOO, 2014 25

GPU je typicky implementováno jako vykreslovací řetězec neboli pipeline, kde v datech dochází k přechodu z jednoho stavu do stavu druhého. Grafická pipeline reprezentuje celý proces zpracování 3D scény a její reprezentace ve 2D obrazu. Může být hrubě rozdělena do tří velkých fází: Aplikační fáze Geometry fáze Fáze rasterizeru Obrázek 6: Fáze grafické pipeline (zpracování 3D obrazu) Zdroj: Vlastní zpracování Aplikační fáze stojí na samém počátku a jejím vstupem jsou informace o scéně. Tyto data obsahují informace o tvarech objektů, zdrojích světla, kameře a tak dále. Tvary objektů jsou složeny z primitivních typů. Tato fáze reprezentuje všechny činnosti, které se musí stát, než se zpracovávání scény posune grafickému hardwaru. Geometry fáze je složena z mnoha menších operací. Je zodpovědná za zpracování a manipulaci dat předaných scénou z aplikační fáze. Jejím výstupem jsou data, jimiž lze scénu a její objekty reprezentovat 2D obrazem. Příklady operací, které se v této fází provádějí: 14 Aplikace transformací pro umístění objektů na správné místo ve scéně Aplikace pohledových transformací z důvodu renderování jen toho kusu scény, který bude zobrazen (umístěny kamery ve scéně). Vypočítat množství světla, které dopadne na každý bod viditelného kusu scény. Adaptace a reprezentace 2D obrazu na základě rozlišení displeje. Fáze rasterizace funguje trochu jako tiskárna. Vstupní data z geometry fáze obohatí o barvy a stará se o aplikování textur. Další důležitou operací je setřídění objektů podle vzdáleností, ve kterých se nacházejí od kamery. 14 14 MÖLLER, 2008 26

Všechny dosud zmíněné operace musí probíhat rychle, protože je potřeba je provést pro každý snímek obrazovky zvlášť. Z tohoto důvodu jsou operace grafické pipeline rozděleny tímto způsobem a zpracovávány paralelně. Výhodou této architektury je fakt, že pokud například výpočet fyzikálních vlastností skončí a zpracovávání snímku se předá komponentě pro zpracovávání osvětlení, tak můžou začít výpočty pro fyzikální vlastnosti dalšího snímku. Tím je zajištěna maximální efektivita využití grafické procesorové jednotky. Rozvržení komponent pro GPU pipeline je znázorněné na obrázku 8. Když jsou grafická data v řetězci zpracována dochází k jejich uložení do framebufferu. Framebuffer je paměť, která obsahuje informace, které jsou potřebné k zobrazení obrazu na displeji. Fyzicky může být tato paměť lokalizována i jinde. Například může být součástí hlavní operační paměti, ale moderní grafické karty mívají tuto komponentu separovanou a blízko u GPU čipu, aby byl umožněn co nejrychlejší přístup k datům. Framebuffer se většinou skládá ze tří dalších různých sub-bufferů. Prvním z nich je Color Buffer. Tento typ bufferu si lze představit jako obdélníkové pole reprezentující každý pixel na obrazovce. Tyto informace uchovává v RGB nebo RGBA formátu. Tento buffer má určité množství bitů vyhrazené pro každý pixel. Tento počet bitů se nazývá barevná hloubka color bufferu. Nejmenší buffery tohoto typu mají vyhrazeno 16 bitů pro jeden pixel a znamená to tedy, že jsou schopni zobrazení 2 16 = 65536 barev. 15 Z-Buffer je také označován jako depth buffer neboli hloubková pamět. Tento buffer uchovává informace o vzdálenosti objektu od místa pohledu na scénu. Tyto informace přitom uchovává pro stejný počet pixelů jako Color Buffer. Společně tak 3D prostor dokáží reprezentovat jako 2D obraz. Zjednodušený model komponent GPU lze vidět na obrázku dále: 15 MATSUDA, 2013 27

Obrázek 7: Zjednodušený model grafických komponent a jejich součinností Zdroj: Vlastní zpracování podle autora Matsuda, Kouchi. Kniha WebGL programming guide: interactive 3D graphics programming with WebGL (str. 9) Obrázek 8: Rozvržení GPU pipeline komponent Zdroj: gamedevs.org 28

Tento model fungování grafické pipeline za pomocí vnitřních shaderů je platný od roku 2006. Představila jej nová verze Direct3D 10. Herní vývojáře by mělo především zajímat, jakým způsobem fungují Vertex, Geometry a Pixel shadery. Tyto shadery jsou, jak už ukazuje obrázek výše, programovatelné. Tedy je nabízené rozhraní pro jejich implementaci, například pomocí DirectX. 16 Více o shaderech v kapitole 2.5.3. Grafická pipeline a celá operace převedení 3D scény do 2D obrazu je velmi složitý proces, který je téměř nemožné shrnout do pár odstavců této práce. Pro opravdové zájemce programování grafických operací doporučujeme třetí vydání knihy Real-Time Rendering od Tomase Mollera uvedenou v referencích této práce. 2.1.3 Využití GPU SISD procesory pracují skvěle pro většinu běžných situací, protože většina těchto situací vyžaduje sekvenční přístup. Existují algoritmy, které vyžadují zpracování stejnorodých operací na velkém množství dat. Příkladem může být vykreslování grafiky na displej a renderováním videí. Další zajímavé případy užití přineslo jednadvacáté století. To přineslo úlohy související s prolamováním hesel brute-force přístupem. Tento přístup spočívá v pokusech o prolomení šifer tak, že se ve velkých počtech pokusů pokusíme odhadnout klíč nebo jinou klíčovou vlastnost šifry. Této problematice se věnuje vědecký obor nazývaný kryptoanalýza. Finanční sektor přinesl další případ užití, a to těžení bitcoinů. Těžení bitcoinů spočívá v propůjčení výkonu počítačové stanice třetím stranám, které jej využívají pro operace složité na výpočet. V posledních letech se o využití hlásí i umělá inteligence v autech, dronech a dalších robotech. 2.1.4 GPU Akcelerace GPU-Akcelerace je založena na kooperaci grafického procesoru spolu s CPU s cílem urychlit náročné aplikace. Poprvé byl tento pojem představen v roce 2007 společností NVIDIA a nyní je tato praktika využívána v mnoha vládních laboratořích, univerzitách, velkých podnicích po celém světě. Pro urychlení aplikací za pomocí GPU akcelerace je klíčová správná identifikace částí aplikačního kódu vhodného pro paralelní zpracování. 16 MÖLLER, 2008 29

Rozdělení aplikačního kódu je patrné z obrázku níže. Vhodného kódu pro zpracování na straně GPU můžou být jen jednotky procent, ale vliv na výkon aplikace může být obrovský. 17 Obrázek 9: Jak funguje akcelerace GPU Zdroj: http://www.nvidia.com Tento přístup k programování s sebou nese potíže, které nemusí být na první pohled zřejmé. Jedním z největších problémů tohoto přístupu je sdílení výsledků mezi oběma architekturami. Předpokládejme standartní situaci, kdy CPU a GPU paměť nesdílí. V takových situací jsou obě paměti připojené na PCI-Express bus a i když je tato sběrnicí duplexní, tedy umožňuje přenos v obou směrech, tak přenos informací celý proces velmi zpomalí. Synchronizace dat mezi GPU a CPU je velmi složitá a velmi nízko-úrovňová problematika, proto existují knihovny třetích stran, které programátora od těchto potíží odstíní. NVIDIA na svých stránkách uvádí velké množství frameworků buď z dílny NVIDIA anebo z dílen třetích stran, které NVIDIA podporuje. Tabulka níže uvádí výčet těch nejpoužívanějších. 17 17 GPU Computing [online]. [cit. 2017-05-02]. Dostupné z: http://www.nvidia.com/object/what-is-gpucomputing.html 30

Tabulka 1: Frameworky pro GPU akceleraci Framework Podporované jazyky a IDE Popis CUDA TOOLKIT C/C++ Komplexní řešení pro C a C++ vývojáře pro tvorbu GPU akcelerovaných aplikací. OpenACC C/C++/Fortran Poskytuje jednoduché, ale přesto robustní řešení pro GPU akceleraci. Existující kód může být před kompilaci označen pragmami a speciálním kompilátorem překompilován tak, aby vyhovoval paralelnímu zpracování na GPU. PyCUDA Python Zpřístupňuje CUDA funkcionality pro Python MathWorks Matlab NVIDIA Nsight Matlab Visual Studio, Eclipse Matlab má nativní podporu pro CUDA funkcionality Mocný nástroj pro analýza heterogenních aplikací. Poskytuje debuggovací a profilovací nástroje pro některé IDE nástroje. Optimalizace kódu a analýza úzkých hrdel aplikací. QuantAlea.NET / Mono Starší nástroj pro vývoj GPU procesů. Crossplatform nástroj pro Windows/Linux/ OS X. Vychází z CUDA pro C/C++ a Fortran. Pro nové implementace již není používaný. OpenCL C / C# OpenCL (Open Computing Language) je nízkoúrovňové API pro programování heterogenních systému využívajících CPU, APU, GPU. Zdroj: Vlastní zpracování 31

2.1.5 Heterogeneous System Architecture Aplikacím, které pro svoje funkcionality využívají více druhů procesorových jednotek, se postupem času začalo říkat heterogenní systémy. Heterogenní systémy mají stále spoustu nedostatků. Hlavním nedostatkem je, že vývojář, který o implementaci heterogenního systému uvažuje, musí mít velkou sadu znalostí. Programátor musí znát nízko-úrovňové jazyky, architekturu koncových stanic a mít obecné povědomí o fungování procesorových jednotek, pro které kód píše. Současným trendem programování je právě od těchto problémů programátory odstínit. Za tímto účelem vznikla nezisková organizace Heterogenous System Architecture neboli HSA. 18 Dle autora Wen-Mei HWU se HSA snaží o standardizaci přístupu k programování heterogenních systémů. Do tohoto konsorcia patří mnoho významných IT subjektů. Patří mezi ně například: AMD, ARM, SAMSUNG, HUAWEI, UBUNTU a mnoho dalších. Tito členové se za společné spolupráce snaží o vytvoření lepšího ekosystému pro heterogenní aplikace, který by ubral na celkové složitosti HSA řešeních. Snaží se rozvoj výpočetní síly tlačit k tomu, aby přemýšlel nad tvorbou rozhraní, která by usnadnila spolupráci s ostatními výpočetními jednotkami. Sami tvoří mnoho frameworků, které se snaží vývojáře odstínit od problémů na nejnižších úrovních jako je například výše zmíněné sdílení paměti dvou a více druhů výpočetních jednotek. Jednou z důležitých abstrakcí bylo vydefinování jazyka HSAIL (Heterogeneous Systém Architecture Intermediate Language). HSAIL je mezi-kód, do kterého je překládán kód vyšších programovacích jazyků pro HSA aplikace. Tento kód je následně za pomocí virtuálního stroje vykonáván na cílových platformách a tím je zajištěno odstínění od strojových kódů konkrétních platforem. Problematice heterogenních aplikací se věnuje kniha Heterogeneous system architecture: practical applications for industry od autora HWU. Tato práce HSA již dále probírat nebude. 2.1.6 OpenCL benchmark V této kapitole se budeme věnovat benchmarku jednoduchého algoritmu pro hledání prvočísel na jednotlivých procesorových platformách. Pro experiment využijme knihovnu třetí strany OpenCLib.dll, která zjednodušuje práci s procesorovými jednotkami a jejich pamětí. Tato knihovna je postavena nad OpenCL a její zdrojové kódy mohou být nalezeny 18 HWU, Wen-Mei, 2015 32

na codeproject.com. Knihovna dále využívá Nuget balíček Cloo, který je využíván pro volání OpenCL. Projekt samotný nabízí tři třídy: EasyCL (Pro volání jednoho druhu Kernelu) MultiCL (Pro volání všech Kernelů podporovaných OpenCL) OpenCL (Pro získání informacích o Kernelu) Pro experiment bude využita třída EasyCL, pomocí které zkusíme algoritmus spustit na jednotlivých procesorových platformách. Na konci experimentu využijeme MultiCL, která bude distribuovat instrukce mezi všechny Kernely dostupné na počítači. Od tohoto maximálně efektivního přístupu očekáváme nejlepší výsledky. Mějme situaci, kdy potřebujeme analyzovat prvočísla ve velkém vstupním poli. To co s výsledkem budeme dále dělat není podstatné. Kód pro paralelní zpracování pole čísel by mohl vypadat třeba takto: Obrázek 10:Příklad C# funkce pro prvočísla Zdroj: Vlastní zpracování Stejný kód přepišme do OpenCL C podoby, aby mohl být za pomoci OpenCL přeložen pro jednotlivé procesorové architektury. 33

Obrázek 11:Příklad OpenCL C funkce pro prvočísla Zdroj: Vlastní zpracování Následující metoda byla využita pro měření výkonu jednotlivých procesorových architektur. Metoda využívá OpenCLib pro zjednodušení práce s architekturami procesorů. Obrázek 12: C# funkce pro měření výkonu za pomocí OpenCLib Zdroj: vlastní zpracování 34

Tabulka 2: Výsledky benchmarku procesorových architektur Architektura Výkon (Přirozená čísla v miliónech / sec) CPU 4,811 GPU 9,009 Multi (CPU+GPU) 13,644 Zdroj: vlastní zpracování Tabulka výsledků ukazuje výkon jednotlivých architektur. Číslo je reprezentováno jako počet zpracovaných prvočísel v milionech za sekundu. Z výsledků jasně vyplývá, že pro paralelní zpracování algoritmu pro prvočísla bylo GPU lepší, než CPU. Z tabulky dále vyplývá, že pokud obě architektury spolupracují, tak je dosaženo maximálního výkonu a počet zpracovaných prvočísel by byl největší. Tím je dokázán pozitivní vliv heterogenní spolupráce na výkon aplikací. Projekt využitý k benchmarku procesorových architektur je k nalezení v přílohách. 2.2 Grafika a 3D Rendering Základním principem 3D hry je vykreslování (renderování) statických snímků v reálném čase. Snímky jsou tvořeny na základě 3D modelů, textur a osvětlení. Tyto snímky jsou vykreslovány v rychlém sledu za sebou a rychlost jakou jsou vykreslovány se měří v FPS (Frame-per-second). Počet snímků za sekundu výrazně ovlivní celkový herní zážitek. Pro lidské oko se již při cca 25fps jeví výstup jako plynulá sekvence a jednotlivé snímky nezaznamená, na tomto principu je postaven film. Od zhruba 60fps výše již není člověk schopen rozpoznat rozdíly ve výstupu. Hlavní uplatnění této technologie je v počítačových hrách, dále pak v simulacích a návrhářských programech. 19 Klasický výpočet (offline rendering) jednotlivé snímky (ať už v sekvenci nebo samostatné) vykreslí podle předem nastavených parametrů a s výsledkem uživatel již nemůže interagovat. Tento druh renderingu používá k vykreslování složitější postupy (např. raytracing) díky kterým má realističtější výstupy, využívá se např. pro tvorbu animovaných filmů a digitálních efektů pro filmy klasické. Při zpracování snímků na základě 19 AKENINE-MÖLLER, 2008 35

uživatelských vstupů (např. myš, klávesnice) je pro dojem interaktivity důležitý také reakční čas, tedy za jakou dobu se uživatelský vstup projeví v renderovaném obrazu. Hlavní výhodou výpočtu 3D scén v reálném čase je interaktivita a nevýhodou kompromis v realističnosti výsledných snímků kvůli potřebě jejich rychlé obměny. 20 2.2.1 Kartézská soustava souřadnic základem modelu Ať už chceme 3D prostor v počítači definovat za účelem studia zvuku či obrazu, musíme disponovat použitelným modelem k reprezentaci vytvářených či upravovaných objektů ve třech rozměrech, jimiž jsou délka, šířka a hloubka (či výška). Takový model existuje a vychází z kartézské soustavy souřadnic. Tuto soustavu souřadnic by měl herní vývojář předpokládat v každém modelovacím nástroji nebo herním enginu. Proto zde kartézskou soustavu souřadnic zmiňujeme. Obrázek 13:Bod v 3D prostoru reprezentován souřadnicemi Zdroj: http://www.fotoroman.cz/ 20 Animace, osvětlení a výpočet v reálném čase 3D prostoru [online]. Praha: 3.0 Česko, 2014 [cit. 2017-04-27]. Dostupné z: https://wikisofia.cz/wiki/ 36

2.2.2 Knihovny pro usnadnění vykreslování Pro vykreslování 3D scény v reálném čase je potřeba velké množství složitých výpočtů. Tyto výpočty probíhají uvnitř GPU a aby se vývojář znovu nepotkal s nízko úrovňovou problematikou hardwaru, vznikly API, které tuto práci usnadňují. OpenGL a DirectX jsou dva nejrozšířenější průmyslové standardy. OpenGL je vyvíjena neziskovou organizací Khronos a je multiplatformní. Lze ji využít na operačních systémech typu Windows, Linux a Mac. Existuje i zjednodušená verze OpenGL ES, která je určena pro ios, Android a herní konzole jakou je například PlayStation. DirectX je vyvíjen společností Microsoft a obsahuje pokročilejší vykreslovací postupy a efekty, než je tomu u OpenGL. 2.2.3 Shadery Pokud chceme na obrazovku vykreslit jakýkoliv objekt, tak ho budeme vykreslovat pomocí primitivních typů nebo pomocí mřížky (anglicky mesh), která se z primitivních typů skládá. Tento grafický úkon samozřejmě přísluší grafickému čipu a částím, které grafický čip obsluhují. O vykreslení se postará několik specializovaných programů, které se nazývají shadery. Shader je program obsluhující jednotlivé části programovatelného grafického řetězce (dále jako pipeline) grafického procesoru. Shadery jsou psané ve vyšších programovacích jazycích, které se také nazývají shader jazyky. Příkladem je jazyk GLSL pro OpenGL, Cg od společnosti NVIDIA nebo HLSL vyvinutý společností Microsoft s podporou DirectX. Shaderů existuje několik typů v závislosti na tom, pro kterou část pipeline jsou určeny. Shadery se dělí na: Vertex Shader Pixel (Fragment) Shader Geometry Shader Compute Shader Tesselation Shader 2.2.4 Funkcionalita základních shaderů Dříve existovaly pouze tři druhy základních shaderů, a to vertex, pixel a geometry shader. Pokud bychom tedy chtěli vykreslit objekt, tak tento objekt bude reprezentován primitivními typy. Primitivním typem je myšlen bod, přímka a trojúhelník. GPU musí zpracovat jednotlivé body těchto primitivních typů. O body se stará vertex shader (vrcholový 37

shader). Vstupem pro jednu operaci shaderu je balíček informací o jednom konkrétním vrcholu (např. pozice a barva). Výstupem je modifikace těchto vstupů a další data, která jsme od shaderu požadovali. Výstup vertex shaderu míří k rasterizeru, který se postará o takzvanou rasterizaci. Úkolem rasterizace je, pro vektorová data získaná od vertex shaderu, najít příslušné pixely, na které bude objekt vykreslen. Proces popisuje obrázek níže: Obrázek 14: Proces rasterizace Zdroj: http://www.lighthouse3d.com/ Data získaná rasterizerem jsou předána na vstup pixel shaderu, který podobným způsobem jako vertex shader zpracovával vrcholy, zpracuje jednotlivé pixely. Výstupem jsou informace, které pomůžou k vykreslení pixelů na displej. Tady se pozastavme. Všechny doposud probrané operace shaderů jsou přímo ukázkovým případem pro paralelní zpracování. Pokud bychom tyto jednoduché operace prováděli sekvenčně na CPU, trvalo by jejich provedení moc dlouho. I tak si je třeba uvědomit, že zpracování těchto paralelních operací není triviální a čím více pixelů je na obrazovce, tím déle budou operace trvat. Konfigurace rozlišení obrazovky má proto asi největší vliv na celý výkon hry. Herní vývojář má možnost vytvořit si shadery sám. Některé herní enginy jako je například Unity nabízí možnost implementovat takzvaný surface shader. Tento typ je abstrakcí obou dvou typů předchozích a je jednoduší na implementaci. Surface shader je následně přeložen (vygenerovaný kód) do vertex i pixel shaderu. Vývojář tak nemá plnou kontrolu nad kódem, ale je od této problematiky odstíněn. K shaderům je možné definovat takzvané sub-shadery. Sub-shader umožňuje definovat rozdílná chování podle typu hardwaru na kterém je spuštěn. 38

2.2.5 Grafiky, textury a sprity Fyzický svět je plný obrazů. Povrch jakéhokoliv viditelného objektu je ve své podstatě textura. Záleží jen na pozorovatelově poloze, a tedy měřítku objektu. Slovo textura tedy odpovídá všem vlastnostem povrchu objektu jako je velikost, tvar, hustota, uspořádání základních částí. Textura bývá často popisována vlastnostmi jako hladká, hrubá, měkká, tvrdá, jemná, matná a tak dále. Dobře vytvořená textura musí dát pozorovatelovi pocit jako by daný objekt za sklem displeje opravdu existoval. Pro tvorbu textur existuje mnoho grafických nástrojů. Příkladem může být MARI, BodyPaint 3D, ZBrush nebo Photoshop. Dobrý návrhář ovládá více než jeden grafický nástroj, neboť jeden nástroj může být dobrý na tvorbu hrubého modelu a druhý může být zase vhodnější pro dodělaní detailů. Praktická část této práce je věnována vývoji prototypu hry Maria. Než přijde na řadu vývoj v prostředí herních enginů, tak je za potřebí práce grafického návrháře herní obsahu. Úlohou herních grafiků na počátku projektu je dodat takzvané návrhy neboli sketche. Tyto návrhy přibližují prostředí a postavy, které se budou ve hře nacházet. Tyto kresby pomáhají ostatním členům herního týmu k tomu, aby si představili, v jakém prostředí se hra nachází. Lidé, kteří například navrhují herní příběhy si pak lépe představí, o čem mají psát. Tyto podklady často slouží i pro nalezení potencionálních investorů. Pro účely prototypu hry Maria nám bude stačit mnohem jednoduší koncept grafiky. Jedná se o takzvané sprity, které se využívají například i v prostředí webových aplikací. Grafický vývojář navrhne veškeré pohyby postav na jednom 2D obrázku, který je následně nahrán jako celek. Aplikace, v našem případě Unity, si tento obrázek následně rozseká na jednotlivé obrázky a ty použije pro zobrazení na určených místech. Kompletní zdroje pro vývoj hry Mario jsou k nalezení v přílohách této práce. 39

Obrázek 15: Ukázka 2D Spritu pro hru Mario Zdroj: Vlastní zpracování 2.2.6 3D Modelování 3D modelování se stalo nedílnou součástí všech moderních her. Zatímco u 2D her si vystačíme s texturami vytvořenými v programech jako je Adobe Photoshop, tak u 3D her potřebujeme většinou více nástrojů. Vytvoření kompletního 3D modelu se skládá z pěti fází: Úvodní modelování (hrubý model) Detailní modelování (vyhlazení modelu) Materiální modelování (shadery) Osvětlování Animace V prvním kroku modelování (Initial Modeling) je vytvořen základní model a jeho UV texturová mapa. Vytvoření UV mapy je proces promítnutí 3D modelu do 2D prostoru. Pro tyto základní úkony se hodí programy jako jsou Maya, MAX, Lightwave nebo Silo. Z těchto programů je model většinou vyexportován a pro účely detailního modelování importován do programů jako jsou ZBrush nebo Mudbox. Model s relativně nízkým rozlišením je v těchto programech vyhlazen a následně jsou do modelu vytesány a dokresleny detaily. Celý tento proces se dá představit jako práce sochaře. Nejdříve do kvádru kamene vytesá hrubý model 40

obličeje za pomocí dláta a kladiva. Když je spokojen, tak odloží tyto nástroje a vezme si místo nich malé rašple a štětečky a dodělá detaily. Proces materiálního modelování je činnost, kde si vývojář vybírá z dostupných shaderů ten, který se nejvíce hodí pro jeho model. Tímto vývojář předá modelu informaci, z jakého materiálu se skládá jeho povrch. Nejvíce důležitým parametrem pro tento výběr je vlastnost, s kterou má povrch reagovat na světlo. Povrch může být například velmi matný a světlo pohlcovat, nebo může být naopak velmi lesklý a světlo odrážet. Model se může skládat z více shaderů, ale vývojář musí mít na paměti, že čím více objektů ve scéně lze vykreslit za pomocí jednoho shaderu, tím bude scéna pravděpodobně plynulejší. Tvorba dobrých modelů a výběr správných shaderů má velký vliv na výkon hry. 2.2.7 Osvětlení Výpočet osvětlení probíhá na úrovni pixelů, vrcholů nebo jejich kombinaci. Hru omezuje pouze výkon cílového hardwaru a naše požadavky na kvalitu. Při výpočtech osvětlení se stejně jako při jiných výpočtech před vykreslením zanedbávají objekty v pozadí. Stínování u vzdálených objektů neprobíhá na úrovni pixelů, ale třeba až vrcholů. Tím se šetří hardwarové zdroje. K výpočtům osvětlení probíhá při rasterizaci objektu. Pro výpočty osvětlení jsou potřeba informace o 3D scéně (vzdálenosti objektů od zdrojů světel). Z těchto objektů je proveden výpočet osvětlení, a nakonec jsou 3D objekty rasterizovány a zobrazeny na monitoru. Tento způsob funguje pro jeden i více zdrojů světla. Limitací je pouze výkon a schopnosti hardwaru. Shader, který se stará o výpočty, naplníme informacemi o všech zdrojích světla a tento shader zkombinuje osvětlení zpracovávaného pixelu či vrcholu se všemi světly. Občas bývají z důvodu šetření výkonu zanedbávány vzdálené zdroje světel. Tím sice dochází k výraznému šetření zdrojů, ale mohou se vyskytovat vykreslovací chyby. Pokud například pro osvětlení objektu použijeme striktně jen tři nejbližší světelné zdroje, tak mohou být zanedbány důležité světelné zdroje v pozadí. Příkladem je situace v místnosti, kde jsou čtyři světelné zdroje: žárovka a tři slabé svíčky. Pokud objekt stojí nejblíže slabým svíčkám, tak silný zdroj světla, tedy ona žárovka, může být zanedbána. Dalším problémem může být zanedbání čelního zdroje světla (z pozorovatelovi perspektivy). Tak by do výpočtu byly zaneseny zadní zdroje světel, ty by přitom nebyly ani vykresleny, ale přední světelný 41

zdroj by nebyl brán v potaz. Objekt by tak z pozorovatelovi perspektivy působil tmavě. Pozorovatel, tedy kamera, musí být ve výpočtech také zahrnut. 21 Obrázek 16: Osvětlení Zdroj: vlastní zpracování Na obrázku výše je vykreslení stejné scény ve čtyřech různých případech. V prvním je objekt osvícen všemi zdroji světla. Ve druhém došlo k zanedbání horního zdroje světla (lampičky). Ve třetím došlo k chybě, kdy byl zanedbán přední zdroj světla (přední svíčky). Poslední obrázek je ideální situace. Zadní svíčka byla zanedbána ve výpočtech, ale scéna z pozorovatelovi perspektivy vypadá stejně, jako kdyby byly použity všechny čtyři světelné zdroje. 2.2.8 Globální osvětlení Globální osvětlení ve scéně mají na starost algoritmy, které simulují fyzikální šíření světla scénou. Tyto výpočty zahrnují vlastnosti povrchů jako reflexe, absorpce, přenášení a rozptýlení světelných paprsků. Snaží se tedy o fyzikálně realistický vzhled scény. Opakem tohoto principu je takzvané přímé osvětlování (direct lighting). To spočívá v tom, že paprsky se od povrchu již dále nešíří (viz. obrázek XY). Na rozdíl od algoritmů přímého osvětlení, které tedy uvažují pouze světlo přímo dopadající ze světelného zdroje, počítají metody 21 ZUCCONI, 2016 42

globálního osvětlení s odraženými nebo lomenými paprsky. Vstupem těchto algoritmů jsou informace o geometrii, materiálech a světelných zdrojích ve scéně. 22 Existují dva přístupy k implementaci nepřímého osvětlování. Prvním je point sampling jehož nejznámějším zástupcem je metoda ray tracing. Ray tracing spočívá v sledování každého paprsku světelného zdroje a výpočtech toho, jak se zachová při dopadu na různé druhy povrchů. Tato metoda je velmi složitá na výpočet, protože světelné zdroje tvoří obrovské množství takových paprsků. Ve hrách se používají jen velmi zjednodušené verze takových výpočtů. Druhou metodou pro globální osvětlování je radiozita. 22 Obrázek 17: Rozdíly mezi metodami osvětlení 2.3 Fyzika Fyzika je velmi důležitá součást moderních her. Žádná akční střílečka se bez fyziky neobejde a tento trend se začíná šířit i do žánrů her, které fyziku původně nevyžadovaly. Tato poptávka byla většinou uspokojena produkty, které nabízely třetí strany ve formě middleware implementací, které poskytovaly výkonné fyzické simulace. Cena těchto komerčních produktů byla často velmi vysoká a vývojářům her neumožnovala potřebnou flexibilitu. Implementace vlastních fyzických jader vyžadovala spousty matematiky a znalostí, které nejsou obecně dostupné. Proto spousta frameworků pro podporu fyziky skončila po velkých skandálech v koši. 22 Global ilumination [online]. [cit. 2017-05-10]. Dostupné z: Zdroj: http://www.makinggames.biz/feature/which-global-illumination-technique-isbest-for-your-game,9520.html http://www.makinggames.biz/feature/which-global-illumination-technique-is-best-for-yourgame,9520.html 43

Fyzika je velká disciplína a v akademickém světě má stovky odvětví. Každé odvětví se věnuje jinému aspektu fungování fyzického světa. Některé tyto odvětví lze využít ve hrách. Například optika k simulaci cesty paprsku a způsobu jakým se odráží od různých druhů povrchů. Tato technika se ve hrách nazývá ray-tracing a přestože je velmi náročná na výpočet, tak se v některých herních titulech objevila. Některé druhy fyziky naopak nebereme v potaz. Takovým příkladem je asi nukleární fyziky, pokud by se jí hra přímo nevěnovala. Pokud chceme mluvit o fyzice ve hře, tak budeme především uvažovat klasickou mechaniku. Naším cílem je ve hře vytvořit umělý pocit reality, kdy se z vznášejících objektů stanou pevné věci s hmotností, které podléhají fyzikálním zákonům: gravitaci, setrvačnosti, odrazivosti a dalším. 23 2.3.1 Physics Engine První pokusy o simulace fyziky jsou staré již přes třicet let. V počátcích si každá hra fyziku implementovala dle svých požadavků. Pokud ve hře hráč střílel z luku a nic jiného, tak se napsal malý kus kódu, který simuloval trajektorii šípů. Hmotnost šípu byla jasně dána a ve veškerých výpočtech zahrnujících hmotnost byly konstanty. Takový kód byl nepoužitelný, pokud se hra rozšířila i o jiné druhy střelných zbraní. Čím jsou požadavky na abstrakci větší, tím je těžší dosáhnout uvěřitelnému pocitu z herního zážitku. V titulu Half- Life z roku 1998 bylo možné interagovat se spoustou objektů, ale abstrakce se občas nepovedla a způsob jakým například hráč posouval krabice nebyl moc reálný. Nelze sice moc mluvit o jádru pro fyziku, nicméně tato hra se určitě může pochlubit povedenou implementací, která byla následně znovu použita v dalších herních titulech od stejné společnosti. Právě znovu použitelnost je jeden z cílů physics engine. Další výhodou je spolupráce komponent. Pokud by existovaly různé simulátory pro vodu, vzduch a oblečení na postavě, tak by musely vzniknout i obtížné implementace mostů mezi nimi. Jinak se bude chovat kabát na postavě, pokud vlaje ve větru a jinak se bude ten samý kabát chovat, pokud je postava na půl ponořena ve vodě. Tyto kolize mezi různorodým prostředím musí mít kvalitní jádro pro fyziku vyřešeno nativně. 25 23 MILLINGTON, 2007 44

2.3.2 Rozdělení jader pro fyziku Existuje několik přístupů k implementaci jader pro fyziku. Podle těchto přístupů lze jádra dělit. Prvním přístupem k aplikaci fyziky na objekt je takzvaný rigid-body (tuhé těleso) přístup. Tuhé těleso je objekt, jehož tvar ani objem se účinkem libovolně velkých sil nemění. Síly, které na těleso působí, mají jen pohybové účinky. Veškeré deformační účinky se zanedbávají a řeší se pouze pohyb a rotace objektu. Opakem je engine, který počítá s jednotlivými komponentami, které jsou k sobě nějakým způsobem přidělány. Tento typ enginu je většinou jednodušší na implementaci. Celý objekt rotuje přirozeně jako výsledek lineárního předávání sil z jedné komponenty na druhou. 24 Druhým druhem rozdělení je podle zpracování kolizí. Během jednoho snímku dochází k desítkám až stovkám malých kolizí mezi dvěma objekty. Tyto kolize mohou být zpracovány buď jedna po druhé. Tomu se říká iterativní přístup a jeho výhodou je rychlé zpracování každé kolize. Celý set kolizí může být vyřešen velmi rychle, ale mohou vzniknout situace, kdy jedna kolize ovlivní nepříznivě jinou a dojde k nesprávnému výpočtu celkového efektu na objekt. Těchto přístupů existuje více. Zmíníme si tu ještě jeden, který je více realistický k reálnému světu. To je takzvaný Jacobian-based přístup. Tato metoda spočívá v tom, že se jádro pokusí vyřešit všechny silové efekty na základě všech kolizí, které v danou chvíli vznikly. Jak už napovídá popis, tento přístup je velmi náročný na výpočet. Systém během kalkulace musí vyřešit stovky až tisíce rovnic a některé situace prostě nemívají jasné řešení. Tyto neřešitelné rovnice bohužel nastávají velmi často a vývojář si s nimi musí poradit svým vlastním kusem kódu. Tento přístup není v herních enginech moc využíván, a proto jej dále rozebírat nebudeme. 25 Posledním typem rozdělení je podle způsobu, jakým jsou kolize po zpracování vyřešeny. Existují dva typy těchto řešení. Force-based přístup, který je nejčastěji využívaný právě s Jacobian-based přístupem řešení kolizí. A další možností je impulse based přístup. Představme si knihu položenou na stole. Na tuto knihu působí síla gravitace směrem dolů. Kdyby v opačném směru, tedy od stolu, nevzniklo působení síly stejné velikosti, tak by se kniha prostě protlačila do onoho stolu. Pokud bychom aplikovali přístup založený na impulsech, tak by v každém snímku na knihu působila síla o určitě velikosti, která by knihu držela na stole. Tato síla se vypočítá podle průměrného počtu snímků za sekundu a pokud 24 MILLINGTON, 2007 25 MILLINGTON, 2007 45

by došlo k výraznému výkyvu počtu snímků, tak by kniha mohla nepříznivě vibrovat na povrchu stolu. Force-based metoda aplikuje konstantní působení síly v každém okamžiku. 26 2.3.3 Vektory Praktickým využitím vektorů v našem případě je reprezentace souřadnic v prostoru. Pokud bychom chtěli reprezentovat pozici částice v 3D prostoru, tak by náš vektor a obsahoval tři složky: a = [x, y, z]. Každý vektor specifikuje jednu unikátní pozici v prostoru. Většina game enginů obsahující některé jádro pro fyziku, využívá vektory pouze k této reprezentaci objektů v prostoru. 25 Obrázek 18: Částice v 3D prostoru reprezentovány vektorem (souřadnicemi) Zdroj: MILLINGTON, Ian. Game physics engine development (str 16.) Další interpretace vektorů v prostředích physics enginů je reprezentace změny pozice částice v prostoru. Vektor následně neobsahuje pevnou pozici v prostoru, ale obsahuje deltu (změnu) oproti původní pozici objektu. Pokud částice a ležela v prostoru dle a = [1,1,1], tak její změnu na pozici a = [1, -2, 7] můžeme popsat vektorem b jako b = [0, -3, 6]. 26 TANAYA, 2016 46

2.4 Hra více hráčů Hra více hráčů neboli multiplayer v posledních letech stále více přitahuje pozornost široké veřejnosti. Hlavním cílem této technologie je umožnit více hráčům sdílet identický, synchronizovaný svět a dát hráčům možnost vzájemné interakce. Tato kapitola se věnuje převážně síťovaným principům her pro více hráčů. Tedy zajímá nás replikování a synchronizace herního stavu napříč větším množstvím počítačů. Opakem síťované metody sdílení herního obsahu je přístup takzvané lokální hry pro více hráčů. Implementace multiplayeru se v každé hře liší diametrálně. V podstatě neexistuje žádný jednoznačný návod na to, jak multiplayer do hry implementovat. Snadno si představíte, že vytvořit multiplayer pro 2D skákací hru, kde jediným problémem bude pravděpodobně synchronizace polohy hráčů, je jednodušší než implementace stejné funkčnosti do 3D střílečky. V tak složitém programu je poloha hráčů teprve začátek. Je potřeba vyřešit sdílení složitějších herních objektů, synchronizaci herního času, rozhodovat, zda byl hráč zasažen či nikoliv. A to stále není vše. Každé herní studio si své znalosti a principy implementované ve svých produktech chrání a neprozrazuje. 2.4.1 Lokální hra více hráčů Jedná se o metodu implementace multiplayeru, která byla navržena tak, aby spolu jeden nebo více hráčů hráli na jednom zařízení. Některé lokální hry pro více hráčů jsme si představili již v kapitole 1. Konkrétně hry Tennis for Two (1958) a Spacewar! (1962). Implementace lokálních her vícero hráčů se moc neliší od implementací her pro jednoho hráče. Jediným rozdílem je například rozdělená obrazovka nebo podpora více připojených zařízení pro herní vstup. 2.4.2 Rané přístupy k síťovaným hrám Hlavní rozdíl oproti lokálnímu přístupu hry více hráčů je ten, že v síťovaném přístupu jsou k sobě propojeny jeden nebo více počítačů během jedné aktivní herní relace. První opravdu síťované hry byly hostované v malých sítích na mainframech. Jedna z prvních takovýchto sítí byl PLATO systém, který byl vyvinut na univerzitě v Illinois. Právě na PLATO systému byla realizována první síťovaná hra Empire (1973). Joshua Glazer (2015) ve své knize dále zmiňuje titul Maze War, který vznikl přibližně ve stejné době. Není zcela jasné, který z těchto dvou titulů vznikl první a stal se tak otcem síťovaných her. 47

Joshua Glazer (2015) ve své knize dále uvádí, že s příchodem osobních počítačů v raných osmdesátých letech museli vývojáři přijít s nějakou konvenční metodou pro synchronizaci herní relace. Jako vyhovující se ukázala komunikace přes sériové porty. Počítače tehdy obsahovaly sériové porty pro komunikace s tiskárnami nebo modemy. Sériové porty umožňují propojení a vzájemnou sériovou komunikaci dvou zařízení. Jednotlivé bity dat jsou vysílány postupně za sebou (v sérii) po jednom páru vodičů v každém směru. Toto umožňovalo vytvořit jednu herní relaci sdílenou více osobními počítači, což vedlo k prvním síťovaným hrám. Obrovská nevýhoda této komunikace spočívala v tom, že počítače měly maximálně dva sériové porty. Bylo-li zapotřebí propojit více počítačů dohromady, tak se musely volit složitější topologie zapojení sítí. Příkladem mohou být kruhové nebo hvězdicové topologie. 2.4.3 Místní síť Místní síť neboli LAN (local area network) je termín, který označuje několik zařízení propojených dohromady v relativně malé oblasti. Příkladem může být místnost nebo budova. Do kategorie místních sítí spadaly i komunikace přes sériové porty zmíněné v kapitole 2.1.2. Nicméně termín místní sítě a vůbec zájem o tento druh sítí raketově vzrostl až s příchodem Ethernetu. Dovolme si znovu zmínit prvního a nezpochybnitelného zástupce tohoto typu her a tím je Doom (1993). David Kushner (2003) ve své knize Masters of Doom popisuje obrovský vliv tohoto titulu nejen na celý vývoj technologií her jako takových, ale i na rozvoj místních sítí pro využití v celém herním průmyslu. Doom umožňoval propojení až čtyř hráčů. Se stále vzrůstajícím počtem her podporujících technologii LAN rostl i počet hráčů vyžadujících multiplayer. V této době vznikl termín Lan Parties, který označoval shromáždění hráčů na jednom místě. Posledním problémem tak zůstávala nutnost shromáždění hráčů na jednom místě a převoz počítačových stanic z místa na místo. Tento nedostatek odstranil až příchod internetu a jeho zavedení do běžných domácností. Většina novějších her podporujících technologii LAN zároveň podporuje i technologii Online multiplayeru. 48

2.4.4 Online hry Krátce po místních sítích hry začaly podporovat multiplayer přes internet. V podstatě se ničím nelišily od místních her. Vývojáři si pouze museli poradit s vyšší odezvou, než na jakou byli zvyklí u ethernetu. Tyto typy her zde dále nebudeme rozvádět. V této kategorii existují mnohem zajímavější herní modely. Jedním z nich je model masivních online her pro více hráčů. Tento termín je lépe znám pod termínem massively multiplayer online games (MMOs). Tento koncept je ze všech modelů pro hry více hráčů nejkomplexnější. MMO hry hostují i tisíce hráčů najednou a pro všechny nabízejí zcela sdílený a perzistentní svět. David Miler 27 ve své práci uvádí, že perzistence je dosaženo za pomocí herní databáze což pro MMO servery znamená, že se jejich architektura podobá tradiční třívrstvé architektuře pro weby. Škálování se v tomto konceptu provádí několika způsoby. Každý hráč bývá serverem informován jen o ději v jeho nejbližším okolí. Tak dochází k částečné úspoře v komunikaci mezi serverem a klientem hráče. Často bývá aplikace škálována i horizontálně a to tak, že existuje více serverů, které se starají o každou lokaci zvlášť. Servery si tak předávají herní relace tím způsobem, že hráč například přejede do jiné lokace plavidlem. Objeví se nahrávací obrazovka a spustí se logika na transfer relace. Další možností, jak uspořit výkon na straně serveru je přesunout část logiky a výpočtů na stranu klienta. Tento způsob má několik omezení. Zvyšujeme tím požadavky na hardware klienta a zároveň otevíráme naší aplikaci a klienti mají možnost aplikační logiku narušit či nepříznivě ovlivnit průběh hry. Třeba za pomoci cheatingu. Cheating má několik podob implementací. Jedná se o způsob jak si dopsat nebo použít existující metody administrátorů k získání nadměrných práv nebo vlastností ve hře. 2.4.5 Konektivita V předchozí kapitole jsme si prozradili, že pro hry více hráčů je v současné době využíván převážně internet. Jedno z nejdůležitějších technických rozhodnutí, které bude mít obrovský dopad na finální podobu produktu, je výběr protokolu pro komunikaci na transportní vrstvě. Naneštěstí se toto rozhodnutí projeví až v koncové fázi produktu pod velkou zátěží uživatelů, jejichž připojení bude mít ke všemu abnormální odezvy. V podstatě existují jen tři možnosti: protokol TCP, UDP a kombinace obojích. TCP je spolehlivý protokol, u kterého si můžeme být jistí, že jednotlivé pakety dorazí, a navíc 27 MILER, 2015 49

dorazí ve správném pořadí. Takový typ spojení se hodí na situace, kdy si nemůžeme dovolit ovlivnit herní zážitek tím, že server nebo uživatel nedostane informace o hráčově akci. Příkladem může být zmáčknuté tlačítko, které nevyvolá žádnou reakci. Nejhorším případem je situace, kdy se odpověď na uživatelovu interakci nedostane zpět na klienta. V takových případech může dojít k naprosté desynchronizaci mezi serverem a klientem. UDP na druhou nezaručuje doručení všech paketů a je celkově méně spolehlivý. Tento protokol se používá například pro stream videa. Mezi pozitiva UDP protokolu patří nižší odezvy přenosu. Tento protokol se skvěle hodí třeba pro data o pozicích hráčů. Pokud se paket s pozicí hráče nenávratně ztratí, tak každý další paket, který dorazí nám pozici hráče aktualizuje na správnou hodnotu. UDP se zkrátka hodí pro situace, kdy nám nezáleží na doručení všech paketů včas a v pořadí za sebou, ve kterém jsme jej odeslali. David Miler 28 ve své práci Multiplayer mód v počítačových hrách dále rozvádí technologie, jak hru pro více hráčů optimalizovat. Tato práce se této problematice již dále nevěnuje. 28 MILER, 2015 50

3. Herní engine V předchozích kapitolách jsme si ukázali několik problematik, se kterými se herní vývojář při své práci potká. Herní frameworky existují právě z důvodu, aby žádnou z těchto složitostí herní návrhář nemusel znovu vymýšlet. Poslední část této práce je věnována herním frameworkům a práci s jedním z nich. Svět herních vývojářů se v posledních letech potkal s mnoha velkými novinkami. Velká herní studia a vlastníci předních herních enginů se dohodli, že vypustí nové verze svých nástrojů téměř souběžně, a navíc zvolili zajímavou strategii zpřístupnili je začínajícím herním vývojářům zdarma. Na trhu již sice existovali herní frameworky, které nabízeli vývojářům svoje funkcionality zdarma, ale až přechod velkých a uznávaných enginů do tohoto nového obchodního modelu, spustil zlatou éru moderního herního vývoje. Konkurence v tomto odvětví působí velký tlak na tvůrce enginů. Pro zachování konkurenceschopnosti musí neustále reagovat na nové požadavky svých uživatelů. Mezi přední enginy například patří Unreal Engine 4 od Epic Games, CryEngine od společnosti Crytek, Source 2 od Valve a nová Unity 5. 3.1 Teorie herních enginů Herní engine je softwarový framework navrhnutý pro tvorbu a údržbu videoher. Vývojáři je používají pro tvorbu her na konzole, mobilní zařízení a osobní počítače. Mezi hlavní funkcionality nabízené herním enginem patří vlastní renderovací jádro pro 2D i 3D prostředí, jádro pro počítání kolizí mezi objekty (tedy fyzika), zvuky, animace, přístup k implementacím hry více hráčů a alokace paměti. Každý engine podporuje různé druhy vyšších programovacích jazyků pro skriptování nad herními objekty. Herní frameworky dále nabízí svá prostředí pro zjednodušení práce s animacemi, zvukem, lokalizací a práci s videem pro cut-scény. Správné využití herního enginu vede ke znuvupoužitelnosti herních objektů ve více produktech. Standardem se staly už i vlastní diagnostické nástroje pro profilování herních scén. Herní engine je uprostřed celého procesu vývoje her. Často dochází k chybnému výkladu, že v herním enginu probíhá vývoj celé počítačové hry. Velká část vývoje spočívá v modelování objektů a charakterů v externích nástrojích jako je Maya, 3Ds Max, Photoshop a další. Tyto modely jsou následně importovány do enginu ve formě tzv. herních assetů. Tyto 51

assety se pak stávají součástí vznikající hry, které se musí v konkrétním enginu dále naprogramovat. 3.2 Unity 5.0 Začátkem roku 2015 byla vydána nová verze Unity 5.0. Hlavní předností tohoto nástroje je jeho multiplatformní využití pro jednotlivé mobilní formáty. Unity lehce zvládne převádět hru na platformy ios, Windows Phone, Android a BlackBerry. Samozřejmostí je i vývoj pro PlayStation, Xbox One a PC. Nicméně zatím se stále dá říct, že se jedná především o engine vhodný pro vývojáře her na mobilní zařízení. Do Unity lze snadno naimportovat assety ze studia Maya, Cinema 4D nebo Blender. Dále má skvělé nástroje pro import 2D assetů pro vývoj dvoudimenzionálních titulů. Studio samo nenabízí moc dobré rozhraní pro tvorbu vlastních assetů, za to nabízí vlastní Unity Asset Store, kde lze zdarma či za nízké částky nakoupit mnoho kvalitních assetů. Jedná se o výborné prostředí pro začínající jednotlivce, kteří nemají velké zkušenosti s tvorbou vlastních assetů. Unity je ke stažení na svých oficiálních stránkách unity3d.com ve třech různých edicích, Unity Personal, Plus a Pro. Začínající herní vývojář si vystačí s edicí Unity Personal, která je dostupná zdarma do ročního výdělku až sto tisíc amerických dolarů. 3.2.2 Založení nového projektu a scény Při spuštění unity dojde k zobrazení úvodní obrazovky s možnostmi přihlášení ke svému uživatelskému účtu a založení nového projektu. Uživatel si může zvolit výchozí cestu pro ukládání svých projektů. Nový projekt se skládá z nové scény s prázdnou paletou pro herní objekty. Scéna je základní pracovní prostor pro objekty hry. Scény mohou být použity pro menu, jednotlivé úrovně hry a cokoliv dalšího. Nejčastěji má hra dvě a více scén. Jednu scénu pro hlavní menu a další scény, které se posléze spouští pro jednotlivé levely. Přechod mezi těmito levely je řízen převážně v kódu. Například kontroler pro objekt hráče může kdykoliv hru navigovat do hlavní nabídky, pokud hráč umře. Každá herní scéna obsahuje objekty prostředí, překážek, nepřátel, dekorací, světel a dalších. S vytvořením nového Unity projektu dojde ke vzniku nové scény. Tato scéna není pojmenována a není ani nijak uložena. Scéna je obvykle prázdná až na výchozí objekty, které se v ní mohou předem vygenerovat. Výchozími objekty jsou kamera a přímý zdroj světla. Prototyp Maria neobsahuje úvodní scénu pro menu. Skládá se z jedné scény pojmenované Overworld. Tato scéna obsahuje postavu hráče, kameru, několik nepřátel Goombas, prostředí prototypu a UI prvky. 52

Obrázek 19: Kompletní scéna pro prototyp Maria Zdroj: Vlastní zpracování 3.2.3 Uživatelské rozhraní a import assetů Unity nabízí rozsáhlé uživatelské rozhraní pro práci se scénou a herními objekty. Vývojář by měl při seznamování s rozhraním věnovat čas do rozvržení oken dle svých zvyklostí. Prostředí se dá nastavit na podobné rozvržení jako má například Visual Studio (bez grafických designerů). Prvním krokem k tvorbě herních objektů je import assetů potřebných pro implementaci hry. Tyto assety lze získat z Unity Assest store, od grafického designera nebo stažením z internetu. Assety potřebné pro tvorbu 2D hry Mario se nachází v příloze této práce. Obrázek níže ukazuje rozvržení projektu zvoleného pro praktický příklad prototypu Mario. Projekt se skládá z: Animations (složka s animacemi charakterů) Prebas (předpisy herních objektů) Scenes (složka se scénami hry) Scripts (skripty ke hře Mario) Sounds (zvuky) 53

Textury, případně složka se sprity. Obrázek 20: Rozvržení projektu prototyp Mario Zdroj: Vlastní zpracování 3.2.4 Herní objekt Když jsou herní assety naimportovány v prostředí Unity, můžeme pokračovat v tvorbě herních objektů. Herní objekt (GameObject) je tím nejdůležitějším prvkem v celém Unity Editoru. Každý objekt ve hře je typu GameObject. Nicméně, tato entita ve své úvodní podobě neumí nic. Je to jen jakýsi kontejner, pod který můžeme přiřazovat vlastnosti, komponenty a skripty. Až následně se z abstraktního herního objektu může stát charakter, prostředí, zdroj světla, zvuk nebo jiný speciální efekt. Podle toho, jakého typu herního objektu chceme dosáhnout, musíme přiřadit kombinaci komponent a vlastností. Unity má spousty nativních komponent, které můžeme využívat. Vývojář samozřejmě není nijak omezen a může si vytvořit svou vlastní komponentu a implementovat ji pomocí Unity Scripting API. 29 Po přetažení textury do scény se automaticky vytvoří nový objekt pojmenovaný po textuře. V tomto konkrétním případě se vytvoří objekt mario_big_normal_create. Po kliknutí na jméno objektu v hiearchii scény dojde k zobrazení inspektoru se všemi 29 BLACKMAN, 2013 54

komponentami, které herní objekt obsahuje. Na obrázku níže si můžeme všimnout, že objekt obsahuje komponentu Transform, která spravuje pozici, rotaci a velikost objektu ve scéně. Další komponentou, která se automaticky přidala, je Sprite Renderer. Tato komponenta se stará o vykreslení objektu ve scéně. Obrázek 21: Detail herního objektu Maria Zdroj: Vlastní zpracování 3.2.5 Herní prostředí a šablony objektů Než herní postavu obohatíme o další komponenty a vytvoříme z ní tak plnohodnotnou hlavní postavu, tak do scény připravíme malé herní prostředí. Prostředí Maria se skládá z bloků velikosti 0.16 x 0.16 unity jednotek. Tyto bloky jsou k nalezení mezi texturami dodaných v příloze. Stejným způsobem jako s postavou Maria přetáhneme texturu bloku do scény. Tyto bloky vytvoří prostředí, po kterém bude postava chodit. Objekty, které vznikají, mají stejné vlastnosti jako postava Maria. Jediným rozdílem je jejich počet. Scéna běžně obsahuje mnoho opakujících se herních objektů. Jednoduché kopírování objektů vytváří duplikáty, které se od určitého množství mohou jen velmi obtížně spravovat. Obrázek 22: Vložené bloky pod postavu Zdroj: Vlastní zpracování 55

Scéna hry Maria obsahuje mnoho bloků, které tvoří plochu, po které Mario postupuje. Tyto objekty mají společné textury, komponenty, animace a chování. I v prostředí Unity existuje jednoduchý a elegantní způsob pro řízenou tvorbu šablon objektů a jejich následné instancování. Tento předpis objektu se v Unity terminologii nazývá Prefab. Prefab obsahuje herní objekt s kompletním výčtem jeho komponent a podřízených elementů. Prefab se chová jako šablona, ze které lze vytvářet jednotlivé instance herních objektů. Jakékoliv změny vlastností v tomto předpisu povedou ke změně vlastností ve všech instancích z něho odvozených. Jednotlivé instance lze po vytvoření odtrhnout od předpisu a zbavit je tak jeho předka. Prostředí Maria je postavené z bloků a každý tento blok má svůj předpis. Stejně tak nepřátelé a mince, se kterými se ve hře postupně setkáme. 3.2.1 Fyzika s Rigidbody Do této kapitoly jsme využívali pouze základní vykreslovací schopnosti Unity. V tuto chvíli není hra nic víc, než jen statický obraz. Aby hra ožila je potřeba vnést do prostředí Maria trochu fyziky. Naším hlavním herním objektem je charakter hráče, tedy postava Maria. Mario je typu GameObject a zdědil tak základní komponentu Transform používanou pro umístění herního objektu ve scéně. Tuto komponentu budeme dále používat pro pohyb postavy po herní scéně. Přidáním komponenty Rigidbody k objektu dojde k jeho zaregistrování pod modul kontrolující fyziku v Unity. Objekt je nyní zahrnut ve výpočtech fyziky a začnou na něj automaticky působit fyzikální vlastnosti scény. Takovou vlastností je například gravitace. Další důležitou vlastnost, kterou objekt získá, je schopnost kolidovat s ostatními objekty, pokud má na sobě komponentu Collideru. Je nesmírně důležité, aby i objekty, se kterými má naše postava kolidovat (například po nich chodit) obsahovaly komponentu Collideru. Rigidbody dále poskytuje API, které umožní vývojáři aplikovat na objekt fyzikální síly. Takto můžeme pohybovat objektem v kterémkoliv směru za pomoci vektorů reprezentujících sílu a směr pohybu. Běžným problémem při manipulaci s Rigidbody objekty je situace, kdy scéna vypadá, jako by probíhala ve zpomaleném čase. Unity vývojář se musí seznámit s jednotkami a měřítkem používaných frameworkem. Unity předpokládá, že jedna unity jednotka ve vzdálenosti představuje jeden metr ve skutečnosti. Pokud bychom importovali modely, které by byly velké sto unity jednotek, tak si sice můžeme přizpůsobit měřítko dle importovaných modelů, ale jádro fyziky se k nim bude chovat jako k obrovským předmětům. Je rozdíl, 56

pokud aplikujete silový vektor na objekt velký jeden metr, anebo na objekt veliký sto metrů. Unity online dokumentace vybízí vývojáře k opatrnosti, pokud manipuluje se samotnou podstatou rigidbody. 30 3.2.2 Player Controller Skriptování je základním stavebním kamenem ve všech hrách. Dokonce i ta nejjednodušší hra vyžaduje určitý set scriptů, které obslouží vstup od hráče a postará se o obsluhu všech druhů událostí, které mohou nastat. Kromě toho mohou být skripty použity pro tvorbu grafických efektů, kontrolu nad chováním objektů nebo pro implementace umělých inteligencí (AI) pro charaktery ve hře. Teď když náš objekt díky Rigidbody nebude propadávat texturami, je na čase mu přidat řídící skript, který bude obsluhovat pohyb hráče a komponentu animátoru. Každý Unity script musí dědit z třídy MonoBehaviour. Monobehaviour je základní předek pro všechny implementace obsluhující herní objekty. Má svůj životní cyklus, kterým prochází každý objekt z něho dědící. Mezi metody tohoto cyklu patří například metoda Awake (volaná při inicializaci), dále Update a FixedUpdate (metody volány před vykreslením každého snímku). Životní cyklus obsahuje i metody obsluhující kolize a mnoho dalších funkcionalit Unity. Unity automaticky skenuje přidanou třídu pro její veřejné vlastnosti, které posléze vykreslí v UI designeru. Pomocí těchto vygenerovaných vstupních polí může vývojář snadno, třeba za pomoci drag-and-drop přístupu, přiřadit do těchto vlastností hodnoty. Příkladem může být reference na jiný GameObject. Pokud vytvoříme veřejnou vlastnost typu GameObject, tak můžeme v designeru vytáhnout jakýkoliv objekt ze stromečku herních objektů a přiřadit jej do této veřejné proměnné. Situaci ukazuje následující obrázek: 30 DOCS [online]. 2017 [cit. 2017-05-01]. Dostupné z: https://docs.unity3d.com/scriptreference/rigidbody.html 57

Obrázek 23: Veřejné proměnné PlayerControlleru, mapované do designeru Zdroj: Vlastní zpracování Přidejme tedy hlavní postavě komponentu reprezentující nový skript. Jako jazyk pro obsluhu herních objektů je v této práci zvolen C#. Veškeré zdrojové kódy k objektům hry Mario jsou v příloze. Za zmínku stojí implementace metody FixedUpdate, která je v životním cyklu volána před renderováním každého snímku a aplikací fyzických vlastností. V této metodě chceme získat informace o vstupu od uživatele, zda se pohybuje a kterým směrem. Následně je potřeba předat pohybový vektor komponentě Rigidbody. Metoda dále řeší otočení objektu ve směru, kam se postava podle uživatelského vstupu pohybuje. Poslední blok kódu předává animátoru informaci, aby ukončil animaci skoku, pokud právě probíhá. Animátoru se věnuje následující kapitola. 58

Obrázek 24: Kód metody FixedUpdate v PlayerControlleru Zdroj: vlastní zpracování 3.2.3 Animátor a Animace Je zcela běžné, aby herní objekty měly mnoho odlišných animací, které korespondují s tím, co konkrétní objekt právě dělá. Například může herní postava dýchat, pokud se nehýbe. Pokud chodí tak se tělo pohybuje ve směru chůze a pokud postava padá, tak může například v hrůze zvedat ruce. Dveře se mohou otevírat nebo zavírat. Unity nabízí animační nástroj nazývaný Mecanim. Mecanim je vizuální komponenta, která se podobá designeru pro flow-chart diagramy, které reprezentují stavy herního objektu. Vývojář si namodeluje stavy, kterými může jeho objekt procházet a nastaví pravidla pro přechod z jednoho stavu do druhého. O obsluhu animátoru se stará komponenta AnimatorController. 59

Obrázek 25: Jednoduchý flow-chart diagram animací Maria Zdroj: vlastní zpracování Z obrázku výše vyplývá, že po startu scény dojde k okamžitému přechodu do stavu mario_idle. Z diagramu je jasné, že z tohoto stavu může herní postava přejít do stavu mario_run nebo mario_jump. Hráč může z jakéhokoliv stavu přejít do stavu mario_dead. Z tohoto stavu již nelze přestoupit na stav jiný. I herní logika je připravená na to, že scéna s přechodem do tohoto stavu končí. Tabulka 3: Podmínky přechodu stavů animací hlavní postavy Počáteční stav Podmínky přechodu Konečný stav Mario_idle Mario_idle && Input.GetButtonDown("Jump") && this.grounded Mario_jump Mario_jump Mario_idle Mario_jump && this.grounded Mario_idle && Input.GetAxis("Horizontal")! = 0 Zdroj: Vlastní zpracování Mario_idle Mario_run Tyto podmínky jsou vyhodnoceny pokaždé, když animace skončí. Animace pro běh nebo skok postavy Maria by proto měly být co nejkratší. Ideálně by neměly být delší než jednu sekundu. Jinak by postava působila dojmem, že například běží i pokud už několik stovek milisekund stojí na místě. Tvorbu animací má na starosti většinou grafik se 60

zkušenostmi cílového herního enginu. Animace pojmenovaná running se skládá ze dvou snímků obsahující záběry postavy v běhu a je dlouhá zhruba 0.2 sekundy. To znamená, že animátor se každých 0.2 sekundy podívá na stavy hry a pokud je postava stále v režimu running tak animaci zopakuje. Jinak animátor dle flowchart diagramu přejde do stavu mario_idle či mario_jump, pokud byla klávesa pro skok stisknuta. Obrázek 26: Animace "running" v detailu Zdroj: Vlastní zpracování 3.2.4 Programování kamery a rekapitulace V tuto chvíli projekt Maria vykazuje základní charakteristiky, které ho definují jako hru. V projektu existuje hlavní postava, na kterou působí gravitace, a která se pohybuje po statickém povrchu. Postava vykazuje základní prvky animace. Umí se otočit ve směru pohybu a pokud se pohybuje, tak dochází ke spuštění animace running ve stylu nekonečné smyčky. Než budeme hru moci sestavit pro konečnou platformu a vyzkoušet tak základní funkčnosti, zbývá doprogramovat poslední důležitý prvek hry. Tímto prvkem je herní kamera. Objekt herní kamery existoval ve scéně již od vytvoření scény, tedy od inicializace projektu. Mario od kamery nevyžaduje žádné sofistikované chování. Jejím primárním úkolem by mělo být pouze sledování herní postavy po ose X. Pohyb kamery po ose Y není vyžadován. Kamera dále nesmí posunout svoji pozici za hranice objektů na ose X. To tedy znamená, že kamera nesmí zobrazit více než poslední objekt úplně vlevo a úplně vpravo na Obrázek 27: Implementace chování kamery 61

ose X. Na objekt kamery tak přidáme novou komponentu reprezentující C# script, jehož implementace je znázorněna na obrázku 27. Zdroj: Vlastní zpracování V tuto chvíli kamera pronásleduje hráče stejným způsobem, jako sledovala kamera hráče v originální hře. Nezbývá nic jiného než zkusit první build aplikace Mario na cílovou platformu. Jako cílová platforma byly v této práci zvoleny webové prohlížeče a z tohoto důvodu se v následující kapitole zaměříme na webové technologie pro hraní her v prohlížečích. 3.3 WEBGL Tradičně byla 3D grafika v hrách určena jen pro dedikované herní konzole a vyžadovala komplexní programování. Nicméně s rozvojem osobních počítačů a standardizací technologií pro prohlížeče bylo možné vzít některé dostupné webové technologie a zpřístupnit 3D obsah na internetu. Unity překládá svůj obsah do 62

JavaScriptových programů, které využívají funkcionalit HTML5 a za pomoci WebGL zobrazují svůj obsah ve webových prohlížečích. 3.3.1 Základy WEBGL WebGL je technologie umožňující vykreslování, zobrazování a interakci sofistikované 3D grafiky v internetových prohlížečích. Poskytuje nízko úrovňové API ke grafickým komponentám počítače. Je založená na OpenGL ES 2.0 a poskytuje podobné funkcionality k renderování obrazu jako OpenGL pouze s jediným rozdílem, vykresluje jej za pomocí HTML5 a Javascriptu. HTML5 nabízí jako plochu k renderování element canvas, který byl původně určen k vykreslování 2D obrazu. Canvas měl být využívaný například pro grafy anebo jiné widgety používané standardně v administrátorských rozhraních webových stránek. Tuto technologii může každý zdarma a libovolně využít k publikaci 3D obsahu na svých stránkách. Není potřeba žádné instalace zásuvných modulů do prostředí klientů. 31 Knihovny podobného typu bývají navržené dle dvou různých přístupů k implementaci grafických API: Retained-mode API Immediate-mode API 3.3.2 Immediate-mode API WebGL je navržené dle Immediate-mode API. Při tomto typu rozhraní musí být celá scéna překreslena při každém snímku. Nezáleží na tom, zda se změnila. Grafické knihovny, které poskytují rozhraní tímto způsobem, neukládají žádné informace o stavu modelu scény ve svých vlastních strukturách. Místo toho si správu modelu musí obsluhovat aplikace, která knihovnu využívá. Z předchozích vět jasně vyplývá, že výhodou tohoto přístupu je daleko větší flexibilita a kontrola aplikace nad stavem scény. Na druhou stranu to rovněž znamená větší práci pro aplikaci. Vývojáři takových aplikací musí myslet na architekturu scén, inicializaci a úklid paměti. Diagram níže zjednodušeně ukazuje jak immediate-mode API funguje 14. 31 ANYURU, 2012 63

Obrázek 28:Immediate-mode API Zdroj: vlastní zpracování Retained-mode má na druhou stranu model scén uložen v grafických knihovnách. To má za následek nižší kontrolu nad modelem ze strany vývojáře, a tak omezenost celkového řešení. Tato architektura je vyhovující převážně pro jednoduchá řešení. 3.4 Build hry Za cílovou platformou pro build prototypu hry Mario jsme si vybrali webové prohlížeče. Chceme proto využít nativní podpory pro WebGL, které Unity nabízí. Než se WebGL stalo standardem pro webovou grafiku, mělo Unity svůj vlastní zásuvný modul, který musel být do prohlížečů instalován. Tomuto doplňku se říkalo Unity Web Player a jeho podpora byla oficiálně ukončena s vydáním verze Unity 5.0. Unity nabízí přehledné rozhraní pro výběr cílové platformy a následné konfigurace buildu. V případě buildu pro WebGL je vývojáři umožněno sestavit aplikaci v takzvaném Development Buildu. Ten je sice mnohem větší, než by byl release build, ale umožňuje například použití profileru a dalších funkcionalit, které jsou dostupné jen pro build v režimu development. 64

Obrázek 29: Nastavení buildu pro Unity projekt Zdroj: Vlastní zpracování 3.4.1 Kompilace Unity projektu do WebGL Aby hra mohla být spuštěna v prohlížeči, musí být všechen kód přeložen do JavaScriptové podoby. K překladu herního kódu (v našem případě C#) používá Unity technologii nazvanou IL2CPP 32. Tato technologie byla vyvinuta vývojáři z Unity, aby pomohla s buildem aplikací na platformy podporující jazyk C++. IL2CPP vezme.net bytecode a přeloží ho do zdrojových kódů C++, které jsou posléze dále přeloženy jinými nástroji do JavaScriptu. K tomuto převodu Unity používá emscripten compiler 33 což je 32 IL2CPP [online]. 2017 [cit. 2017-05-01].Dostupné z: https://docs.unity3d.com/manual/il2cpp.html 33 Emscripten [online]. 2015 [cit. 2017-05-01]. Dostupné z: http://kripken.github.io/emscriptensite/index.html 65

nástroj další třetí strany pro překlady C a C++ kódu do JavaScriptu. Technologie běžně používáné při buildu hry v Unity ukazuje následující obrázek: Obrázek 30: Technologie používané pro build her z Unity Zdroj: www.docs.unity3d.com Il1CPP komponenta na svém vstupu přijme kompilované knihovny z Mona nebo z kterýchkoliv jiných kompilátorů. Následně vygeneruje C++ zdrojové kódy, které jsou následně přeloženy za pomocí jiných překladačů pro konkrétní platformu. Mario bude přeložen pro WebGL a HTML5. 66