VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMA ČNÍCH TECHNOLOGIÍ ÚSTAV PO ČÍTA ČOVÉ GRAFIKY A MULTIMÉDIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA
VÝVOJ INDIE GAME
DIPLOMOVÁ PRÁCE MASTER'S THESIS
AUTOR PRÁCE BC. MICHAL ZACHARIÁŠ AUTHOR
BRNO 2011 VYSOKÉ U ČENÍ TECHNICKÉ V BRN Ě BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMA ČNÍCH TECHNOLOGIÍ ÚSTAV PO ČÍTA ČOVÉ GRAFIKY A MULTIMÉDIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA
VÝVOJ INDIE GAME INDIE GAME DEVELOPMENT
DIPLOMOVÁ PRÁCE MASTER'S THESIS
AUTOR PRÁCE BC. MICHAL ZACHARIÁŠ AUTHOR
VEDOUCÍ PRÁCE ING. RUDOLF KAJAN SUPERVISOR
BRNO 2011 ZADÁNÍ DIPLOMOVÉ PRÁCE Abstrakt
Tato diplomová práce se zabývá vývojem indie game - tedy nezávislé vyvinuté hry. Popisuje d ůležité momenty v historii po číta čových her. Objas ňuje pojmy jako zlatý v ěk videoher a krach herního pr ůmyslu roku 1983. Dále vysv ětluje historii a vznik fenoménu indie game . Stru čně popisuje n ěkteré rozdíly p ři vývoji nezávislé a komer ční hry. V další části uvádí hlavní rysy n ěkterých z herních engin ů a nástroj ů, které lze použít pro tvorbu indie games . Nakonec popisuje návrh a implementaci jednoduchého herního enginu a hry na n ěm postavené.
Abstract
This master’s thesis deals with development of indie game - independently-developed game. It describes important moments in computer games history. It clarifies terms like golden age of video arcade games and video game crash of 1983. Further it explains history and origin of indie game phenomenon. It describes some of the differences between independent and commercial game development. In next chapter it presents some game engines which are suitable for independent game development. And in the last chapter it describes the design and implementation of game engine and game running on it.
Klí čová slova historie videoher, indie game, vývoj po číta čových her, zlatá v ěk videoher, krach herního pr ůmyslu v roce 1983, unreal engine, torque engine, xna, real-time strategy
Keywords video games history, indie game, computer games development, golden age of video arcade games, video game crash of 1983, unreal engine, torque engine, xna, real-time strategy
Citace
Zachariáš Michal: Vývoj indie game, diplomová práce, Brno, FIT VUT v Brn ě, 2011 Vývoj indie game
Prohlášení
Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatn ě pod vedením Ing. Rudolfa Kajana. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal.
…………………… Michal Zachariáš 23. kv ětna 2011
Pod ěkování
Děkuji svému vedoucímu Ing. Rudolfu Kajanovi za poskytnutý čas a odbornou pomoc p ři práci na mém projektu. Také d ěkuji mým týmovým koleg ům Davidu Jozefovovi a Martinu Wilczákovi za výbornou spolupráci na h ře FireFighters: Whatever it takes .
© Michal Zachariáš, 2011 Tato práce vznikla jako školní dílo na Vysokém u čení technickém v Brn ě, Fakult ě informa čních technologií. Práce je chrán ěna autorským zákonem a její užití bez ud ělení oprávn ění autorem je nezákonné, s výjimkou zákonem definovaných p řípad ů. Obsah
Obsah ...... 1 1 Úvod ...... 2 2 Historie videoher ...... 3 2.1 Pr ůkopnická léta ...... 3 2.2 Zlatý v ěk videoher ...... 4 2.3 Moderní v ěk ...... 6 2.4 Sou časné videohry ...... 7 3 Indie game ...... 9 3.1 Samotný pojem ...... 9 3.2 Vznik a historie ...... 9 3.3 Sou časné trendy ...... 11 4 Vývoj nezávislé a komer ční hry...... 14 5 Nástroje pro tvorbu indie game ...... 15 5.1 Aplika ční rozhraní ...... 15 5.2 High-level nástroje pro tvorbu her ...... 19 6 Tvorba enginu ...... 25 6.1 Návrh enginu ...... 25 6.2 Implementace enginu ...... 31 7 Tvorba hry ...... 46 7.1 Návrh hry ...... 46 7.2 Implementace hry ...... 50 8 Záv ěr ...... 55
1 1 Úvod
Tématem této diplomové práce je vývoj indie game - tedy vývoj nezávislé hry. Zmín ěná nezávislost se p ředevším vztahuje na finan ční podporu n ěkteré velké herní spole čnosti nebo distributora. Hry jsou většinou financovány z úspor samotných vývojá řů , a tudíž nemají velký rozpo čet. Fenomén nezávislé hry se objevil pom ěrn ě nedávno a práv ě te ď zažívá rapidní rozvoj. Následující kapitola Historie videoher obsahuje stru čný p řehled historie po číta čových her jako celku a zahrnuje období od 50. let 20. století až po sou časnost. Čtená ř se dozví o prvních po číta čových hrách, které byly více laboratorními pokusy než snahou o vytvo ření plnohodnotné hry, avšak inspirovaly nemalé množství dalších vývojá řů . Dále ho seznámí s pojmy zlatý v ěk videoher a krach herního pr ůmyslu v roce 1983. Přiblíží rozmach herních konzolí a osobních po číta čů v moderním v ěku a nakonec se zmíní o prvních 3D grafických kartách, násilí ve hrách a vzniku spole čností jako ESRB, které se specializují na hodnocení vhodnosti her. Ve t řetí kapitole Indie game si řekneme, co tento pojem v ůbec znamená, jak vznikl a jaká je jeho historie. Zmíníme první nezávislé herní projekty, které však ješt ě nenesly ozna čení indie game , osv ětlíme, co je demoware a shareware , období izolovaných herních engin ů a pokusíme se ur čit, kdy vznikl samotný pojem indie game . Také se dozvíme, jaký je nej čast ější zp ůsob distribuce t ěchto her. Čtvrtá kapitola Vývoj nezávislé a komer ční hry stru čně popisuje rozdíly mezi vývojem nezávislého a komer čního herního projektu a čeho by se m ěl vývojá ř indie game vyvarovat. Pátá kapitola Nástroje pro tvorbu indie game obsahuje p řehled nejrozší řen ějších grafických aplika čních rozhraní - DirectX a OpenGL. Také obsahuje popis dvou herních engin ů, se kterými je možné vytvá řet indie games - Torque Game Engine Advanced a Unreal Engine. Nakonec ukáže, jak pracuje XNA Game Studio spole čnosti Microsoft. Šestá kapitola Tvorba enginu podrobn ě popisuje návrh a implementaci enginu postaveného na frameworku XNA Game Studio 4.0. Detailn ě rozebere jednotlivé komponenty, které lze využit především pro tvorbu her v žánru Real-time strategy . Poslední kapitola Tvorba hry vysv ětluje návrh a implementaci částí d ůležitých pro vývoj hry FireFighters: Whatever it takes , která byla p řihlášena do sout ěže Imagine Cup , po řádanou spole čností Microsoft a to konkrétn ě do kategorie game design.
2 2 Historie videoher
V této kapitole se nachází stru čný p řehled historie videoher. Popisuje pouze hry, vývojáře, konzole a události, které byly d ůležité pro vývoj herního pr ůmyslu do stavu, jaký známe te ď. Především se zabývá pr ůkopnickými léty herního pr ůmyslu, kdy byly hry spíše jen pokusy, které m ěly otestovat výkon sálových po číta čů až na hranice možností. Dále pak tzv. zlatým v ěkem videoher , kdy herní automaty dosáhly vrcholu a staly se velmi populární mezi americkou ve řejností. Moderním v ěkem videoher , ve kterém se herní konzole a osobní počíta če dostávají do domácností a nakonec popisuje trendy, které se objevují v sou časných videohrách .
2.1 Pr ůkopnická léta
Historie po číta čových her a videoher zahrnuje již více než padesát let. Do pov ědomí širšího okruhu lidí se však dostaly až v polovin ě sedmdesátých let a v tehdejším Československu se po číta čové hry objevily až po revoluci, tedy po roce 1989. V úplných po čátcích b ěžela v ětšina po číta čových her na sálových po číta čích amerických univerzit a byla vyvíjena jednotlivci jen jako koníček. Přístup k těmto sálovým po číta čů m byl velmi omezen, a tudíž takovýchto her nevzniklo mnoho a byly pov ětšinou zapomenuty [1]. V roce 1947 byla již televize v Americe pom ěrn ě rozší řená a tak vznikl nápad umožnit na ní lidem hrát hry. Thomas Goldsmith a Estle Mann, zam ěstnanci televizní spole čnosti Dumont, vymysleli za řízení, které nazvali Cathode-Ray Tube Amusement Device a které mělo lidem umožnit virtuáln ě odpalovat rakety na cíl a řídit jejich trajektorii. V témže roce tento nápad také patentovali, avšak Dumont jej nikdy neza čal vyvíjet, natož prodávat [2]. Roku 1952 byla dokon čena první grafická po číta čová hra OXO (také známá jako Noughts and Crosses ), což byla v podstat ě známá hra Tic-Tac-Toe . Byla ovládána telefonním rota čním číselníkem a výstup hry se zobrazoval na CRT s rozlišením 35×16 pixel ů (viz obrázek 2.1).
Obrázek 2.1: Vlevo grafický výstup hry OXO, vpravo vektorový zobrazovací systém s hrou Spacewar!
3 Hra Spacewar! je považována za první „st říle čku“ a také jako první využívá vektorový zobrazovací systém (viz obrázek 2.1). Byla vytvo řena studenty univerzity MIT Martinem Greatzem, Stevem Russellem a Waynem Wiitenem, kte ří ji vytvo řili na mini-po číta či DEC PDP-1. Tato hra inspirovala mnoho dalších vývojá řů , jako byli Bill Pitts a Hugh Tuck. Ti roku 1971 na strandfordské univerzit ě sestrojili první automatovou hru na mince – Galaxy Game . K masové produkci však nikdy nedošlo, nebo ť hardware stál přibližn ě 20 tisíc dolar ů. V strandfordském kampusu však byla velmi oblíbená a z ůstala zde až do roku 1979, kdy byla odstran ěna, kv ůli poškozeným displej ům. Inspirováni Galaxy Game naprogramovali Nolan Bushnell a Ted Dabney automatovou hru Computer Space (viz obrázek 2.2), která je považována za první komer čně prodávanou hru v ůbec. Zajímavostí je, že nepoužívá žádný mikroprocesor, ROM ani RAM. Celý systém je založen na principu kone čného automatu a je sestaven ze 74 TTL čip ů.
Obrázek 2.2: Automat hry Computer Space
2.2 Zlatý v ěk videoher
Anglicky ozna čovaný jako Golden age of video arcade games . Různé zdroje se liší v názoru, kdy p řesn ě zlatý v ěk zapo čal. Webový portál The History of Computing Project jeho po čátek datuje od roku 1971, kdy byl vytvo řen první herní automat [4]. Avšak Steven L. Kent, ve své knize The Ultimate History of Video Games , umístil toto období do let 1979 až 1983 [3]. Rok po vydání Computer Space, tedy v roce 1972, založili Bushnell a Dabney firmu Atari , jejíž první hrou byl Pong (viz obrázek 2.3). Díky této h ře se za mén ě než šest m ěsíc ů stala z neznámé firmi čky vedoucí firma herního pr ůmyslu. Pong se brzy stal velmi populární a jen v Americe se prodalo p řes 500 tisíc kus ů. Pong také inspiroval řadu tv ůrc ů a to nejen v oblasti po číta čových her. Inspirací byl prý i pro režiséra slavného sci-fi filmu Tron Stevena Lisbergera. Po číta čové triky vznikaly na po číta čích s 2 megabajty pam ěti a postprodukce zam ěstnala p řes 500 animátor ů a grafiků – přesto snímek nedostal nominaci na Oscara za speciální efekty, protože akademie považovala použití po číta čů za podvád ění [13].
4
Obrázek 2.3: Obrázek ze hry Pong
V tomto období dochází p ředevším k rapidnímu vývoji hardwaru specializovaného na herní automaty, snížení výrobních náklad ů a tedy i k masovému rozší ření herních automat ů mimo obvyklé herny a to do nákupních st ředisek, restaurací, čerpacích stanic atd. Také vznikly první cenov ě dostupné herní konzole, které mohli lidé p řipojit ke svým televizním stanicím a zahrát si v pohodlí svého domova. Poprvé tak lidé mohli ovlivnit to, co se na televizní obrazovce d ěje a ne jen sed ět a přepínat kanály. První takovou hrou byl mini-Pong (viz obrázek 2.4), což byla domácí verze výše zmi ňované hry Pong. Na Vánoce roku 1976 se t ěchto konzolí prodalo v Americe 13 milión ů kus ů.
Obrázek 2.4: Konzole spole čnosti Atari mini-Pong
Na konci 70tých let p řicházejí mikroprocesory, které zjednodušily a zp řístupnily vývoj herních konzolí širšímu okruhu vývojá řů . Vzniklo velké množství různých herních konzolí napodobujících mini-Pong, ale také řada originálních. Jelikož byl hardware té doby stále velmi omezený, museli se vývojá ři zam ěř ovat p ředevším na výbornou hratelnost a znovuhratelnost. Díky tomuto faktu vznikaly hry, jejichž odkaz dote ď nacházíme v mnoha moderních hrách. Existuje nespo čet remak ů herních klasik jako Pong , Space Invaders, SpaceWars! , Asteroids nebo Lunar Lander .
5 2.3 Moderní v ěk
V roce 1983, kv ůli nestálému hernímu trhu a klesajícímu zájmu o po číta čové hry v ůbec, nastává tzv. krach herního pr ůmyslu, anglicky Video Game Crash . Částe čně byl také zp ůsoben sérií špatných her a tedy snížením zisk ů distributor ů, kte ří postupn ě o hry ztráceli zájem. Dalším d ůvodem byl nár ůst popularity osobních po číta čů (PC), protože mnoho rodi čů v ěř ilo, že lepší investicí je koup ě za řízení, jež má širší využití, než jen hraní her. Nicmén ě tyto skute čnosti a obavy nezasáhly Japonsko a herní pr ůmysl zde dále vzkvétal. To je také d ůvod, pro č je japonská spole čnost Nintendo ozna čována za otce moderního v ěku videoher. Prvním obrovským úsp ěchem spole čnosti bylo vydání jejich 8bitové herní konzole Famicom (pozd ěji známý jako Nintendo Entertainment System nebo zkrácen ě NES ). Velký podíl na úsp ěchu m ěla hra, která se s touto konzolí prodávala - Donkey Kong (viz obrázek 2.5). [4]
Obrázek 2.5: První hra herní konzole Famicom - Donkey Kong
Za zmínku stojí hra I, Robot (viz obrázek 2.6) vyvinutá v roce 1983 spole čnosti Atari, konkrétn ě Davidem Theurerem, který se podílel i na d řív ějších herních projektech, jako Tempest a Missile Command . Je to vůbec první 3D polygonová hra, která absolutn ě p ředb ěhla svou dobu, nebo ť další 3D polygonové hry za čaly vznikat až okolo roku 1991.
Obrázek 2.6: Revolu ční hra I, Robot
6 V moderním v ěku videoher také vznikají první 16, 32 a dokonce 64bitové platformy a konzole. Jednou z nich je nap říklad Super Famicom (v Americe a Evrop ě známý jako Super Nintendo Entertainment System nebo také zkácen ě SNES ), další je dodnes známý PlayStation od spole čnosti Sony. To umožnilo vytvá řet složit ější a výpo četn ě náro čnější hry, nemluv ě o p řechodu z 8bitové barevné hloubky na vyšší. Toto období trvá p řibližn ě do roku 1995 a vzniklo v n ěm velké množství herních legend, mezi které pat ří nap říklad Dungeon Master , The Sims , SimCity , Myst , Donkey Kong Country a mnoho dalších.
2.4 Sou časné videohry
Období sou časných videoher se datuje od roku 1995 a vznikají v n ěm stále nové 32, 64 a 128bitové systémy. Osobní po číta če se masivn ě rozši řují z kancelá ří a firem i do domácností. Dále nar ůstá popularita online hraní, online sázení (nap ř. kasína, sportovní událost atd.) a sociálních sítí. Rapidn ě se zkracují období mezi objevováním nových technologií a s tím souvisejícím vydáváním nových her, které tyto technologie využívaly.
Obrázek 2.7: První grafická karta s 3D akcelerací Voodoo
Objevují se první grafické karty s 3D akcelerací, jejichž asi nejznám ější zástupce je Voodoo od spole čnosti 3DFX (viz obrázek 2.7), které však musely být dopln ěny o VGA kartu, nebo ť nepodporovaly 2D výstup. Pozd ěji na trh p řichází kanadská ATI a kalifornská Nvidia , která koupila všechen majetek firmy 3DFX a získala tak množství výborných zam ěstnanc ů a jejich know-how . Tento pokrok umožnil tv ůrc ům her navrhovat hry s daleko reáln ějším prost ředím, modely a efekty. Poprvé v historii bylo možné vícemén ě reáln ě zobrazit násilí, hororové scény a sexuální obsah (viz obrázek 2.7), což v důsledku zp ůsobilo nár ůst po čtu her, jejichž cílové obecenstvo byli dosp ělí lidé – nap ř. Resident Evil , Tomb Raider , Final Fantasy VII , Metal Gear Solid , Soldier of Fortune a Silent Hill . Proti t ěmto hrám se samoz řejm ě zvedla vlna odporu a nevole ze strany rodi čů , puritán ů a pacifist ů. V USA se dokonce uvažovalo o zavedení zákona, který by úpln ě zakazoval násilí v po číta čových hrách. V této dob ě však vzniká první spole čnost hodnotící hry ESRB (Entertainment Software Rating Board ) a zákon tedy nebylo nutné dále prosazovat. Evropa opožd ěně (až v roce 2002) následovala p říkladu a vzniká spole čnost PEGI (Pan-European Game Information ), jejíž
7 hodnotící systém je dnes v Evrop ě nejrozší řen ější. Tato hodnocení jsou výhodná jak pro rodi če, kte ří se mohou na jejich základ ě rozhodnout, zda hru svému dít ěti koupí, tak pro vývojá ře a vydavatele, kte ří tak zajisté ušet ří spoustu pen ěz za p řípadné soudní spory s rozzlobenými rodi či [6]. Rozvoj internetu, sociálních sítí, mobilních telefon ů, online hraní, nar ůstající softwarová i hardwarová podpora pro herní vývojá ře a především nechu ť n ěkterých vývojá řů pracovat na h ře jen kv ůli zisku dala vzniknout zcela novému odv ětví herního pr ůmyslu – indie game .
8 3 Indie game
Tato kapitola popisuje fenomén nezávislých her – indie game . Podrobn ěji vysv ětluje samotný pojem , dále pak vznik a historii a nakonec sou časné trendy tohoto fenoménu.
3.1 Samotný pojem
Independently-developed game (zkrácen ě Indie game ) je taková hra, která vzniká bez finan ční podpory n ěkteré z velkých herních spole čností nebo distributor ů. Hra v ětšinou nemá velký rozpo čet, nebo ť vývojá ři často čerpají peníze z vlastních úspor. Tým se zpravidla skládá jen z malého po čtu lidí, n ěkdy na h ře pracuje dokonce jen jednotlivec. Vývoj od základu do konce m ůže trvat n ěkolik let, ale není výjimkou, že je celá hra vytvo řena v řádu dní nebo dokonce hodin – záleží na složitosti projektu, zkušenostech a dovednostech vývojového týmu a mnoha dalších faktorech. Tyto hry si nezakládají na high-end grafickém zpracování a efektech, ale p ředevším na originálnosti a hratelnosti [8].
3.2 Vznik a historie
3.2.1 První nezávislé herní projekty
Za první nezávislé herní projekty lze ozna čit hry, které vznikaly již koncem 70. let, kdy žádný ucelený herní pr ůmysl neexistoval, a všechny hry byly vytvá řený malým týmem nadšenc ů, kte ří nehled ěli na zisk, ale cht ěli dále rozvíjet herní pr ůmysl a tvo řit hry podle svých p ředstav. Mezi takové hry lze za řadit nap říklad SpaceWars! (viz kapitola 2.2). Komer ční spole čnosti, které pozd ěji za čaly vznikat, tyto programátory vyhledávaly a zam ěstnávaly, nebo ť m ěli s tvorbou her nemalé zkušenosti [8][9].
3.2.2 Shareware a demoware
Na konci 80. a za čátku 90. let je prodejní model v ětšiny indie her založen na shareware nebo demoware . To znamená, že část hry je zadarmo, ale za zbytek musí hrá č zaplatit. Hry, které tento model používaly, byl slavný Doom a Commander Keen (viz obrázek 3.1). Tento systém hrá če motivoval ke koupi i zbytku hry, protože velmi často byla zdarma jen první epizoda a další již byly placené.
Obrázek 3.1: Screenshoty z her Commander Keen a Doom
9 3.2.3 Vlna izolovaných herních engin ů
V období od roku 1985 do roku 2004 vznikalo velké množství nezávislých herních engin ů, kdy většina z nich byla vytvo řena pro velmi populární 8bitový domácí po číta č Commodore 64 (zkrácen ě C64). První hry byly v ětšinou ztraceny, protože neexistovala žádná možnost komunikace mezi jednotlivými vývojá ři a žádný zp ůsob jejich distribuce. Takové hry si mohli zahrát jen samotní vývojá ři a lidé okolo nich. Nicmén ě i dnes lze na Internetu najít sbírky t ěchto her a je možné si je zahrát na n ěkterém z emulátor ů. Jeden z prvních populárních nástroj ů, které umož ňovaly vytvá řet po číta čové hry bez rozsáhlých znalostí programování, byl ZZT vytvo řený Timem Sweenym (zakladatel spole čnosti Epic Megagames). Pomocí tohoto nástroje byly vytvo řeny tisíce her a s příchodem Internetu bylo snadn ější je mezi hrá če distribuovat. Dalšími známými i mén ě známými herními enginy byly nap říklad RPGMaker , Inform , ClickTeam , MegaZeux nebo Game Maker . Poslední zmín ěný je dodnes jeden z nejoblíben ějších nástroj ů pro tvorbu her a používán množstvím indie vývojá řů . Je to především pro jeho jednoduchý drag&drop systém a jednoduchý proprietární programovací jazyk – Game Maker Language (GML) [10].
3.2.4 Vznik pojmu indie
Komunita okolo indie her byla p říliš rozt říšt ěná. Skládala se z velkého množství subkomunit, které se vždy utvá řely okolo ur čitého enginu (nap ř. subkomunita okolo Game Makeru, subkomunita okolo ClickTeamu atd.). Nedocházelo k žádné vým ěně nápad ů, post řeh ů a zkušeností. Hry se nedostávaly mimo svou subkomunitu a byly hrány jen jejími p říznivci. To se zm ěnilo v roce 2006 sérií událostí. Některá nezávislá herní studia se za čala ozna čovat jako indie developers – jedno z nejznám ějších je studio Introversion , mezi jejichž nejznám ější po činy pat ří Uplink (viz obrázek 3.2), ve které se hrá č stal hackerem a plnil r ůzné úkoly pro mezinárodní organizace. Tyto úkoly zahrnovaly hackování po číta čových systém ů konkuren čních spole čností, krádeže údaj ů z výzkumu, sabotáže ostatních spole čností, praní špinavých pen ěž, mazání d ůkaz ů nebo podstr čení falešných d ůkaz ů [13]. Mezi další velmi úsp ěšné hry spole čnosti pat ří Multiwinia , DEFCON a Darwinia (viz obrázek 3.2) [12].
Obrázek 3.2: Screenshoty z her Uplink a Darwinia
10 V roce 2006 se od velké komer ční spole čnosti Electronic Arts (zkácen ě EA) odtrhli dva vývojá ři, Ron Carmel a Kyle Gabler , kterým se nelíbil tlak spole čnosti, jaký na své zam ěstnance vyvíjela, a její hon za ziskem na úkor zábavnosti a hratelnosti her. Tito dva muži založili nezávislé dvou členné herní studio, které nazvali 2D Boy . Aby minimalizovali náklady na vývoj, používali jako kancelá ře San Franciské kavárny s bezplatným připojením k Internetu. Kdyby se n ěkdo o n ěco takového pokusil o p ět let d říve, tak by zajisté neusp ěl, nebo ť jediná možnost, jak tehdy dostat hru k zákazníkovi bylo skrze komer ční distribu ční sí ť. Avšak v roce 2006 bylo již pokrytí širokopásmovým Internetem dostate čně velké, aby bylo možné hry distribuovat i tímto způsobem. Mezi jejich hry pat ří nap říklad World of Goo (viz obrázek 3.3) [2].
Obrázek 3.3: Screenshot ze hry World of Goo
3.3 Sou časné trendy
3.3.1 Typy indie game
Sou časná nezávislá herní scéna se dělí na dv ě základní v ětve - casual a hard-core [20]. Dva protikladné žánry se zam ěř ením na jiné cílové publikum.
Casual Jedná se o velmi nenáro čné hry s jednoduchým ovládáním, jasným cílem a nesložitým p říb ěhem (pokud n ějaký v ůbec má). Hrá č nemusí studovat složité manuály, aby si takovouto hru zahrál. Složitost úrovní se zvyšuje jen velmi pozvolna a dává hrá či dost času na pochopení principu hry. Z těchto d ůvodu jsou v ětšina casual hrá čů ženy. Marketing je u t ěchto her minimální, v ětšinou je sta čí jen prodat distributorovi nebo je umístit na n ěkterý z games-on-demand portál ů (viz kapitola 3.3.2).
11 Hard-core Hard-core hry jsou pravým opakem casual . Často nemají triviální ovládání a jsou ur čeny pro hrá če s ur čitou úrovní herních zkušeností. N ěkdy jsou dokonce tak komplikované, že je pot řeba do hry implementovat tutoriál nebo alespo ň nápov ědu. Obtížnost u t ěchto her neroste pozvolna, ale již první úrovn ě bývají dosti obtížné. Mohou také obsahovat prvky násilí, krev a sexuální obsah, což m ůže zp ůsobit odmítnutí n ěkterých portál ů a distributor ů.
3.3.2 Zp ůsob distribuce
V nedávné dob ě se objevil nový zp ůsob distribuce po číta čových her mezi zákazníky, který jim umož ňuje streamovat nebo stáhnout hru p římo do jejich po číta če. Tento systém je nazýván games-on- demand (zkrácen ě GoD). Díky n ěmu si m ůže uživatel koupit a obdržet hru z pohodlí svého domova bez nutnosti navštívit kamenný obchod nebo si hru nechat posílat poštou. Tento zp ůsob má však i své nevýhody (nap ř. absence krabicové verze) a je na hrá či, zda p řeváží nad výhodami [14]. Naprostá většina indie her je distribuována práv ě pomocí systému games-on-demand .
Existují čty ři hlavní kategorie systému games-on-demand , lišící se podle typu her, které distribuují, a zp ůsobem, jak je distribuují:
• Streamování her p řes webové prohlíže če – většinou se jedná o malé hry napsané na platformách jako Java, Shockwave nebo Flash. Díky malé velikosti her (v ětšinou okolo 1 megabajtu) mohou hrá či za čít hrát v podstat ě okamžit ě. Dnes již hry v této kategorii zasahují do všech herních žánr ů, ale zpo čátku byly takto distribuovány p ředevším r ůzné puzzle hry.
• Hry, které jsou distribuovány jen p řes Internet – tyto hry nejsou streamovány p řes webové prohlíže če, ale celý jejich obsah je stažen na uživatel ův po číta č. V ětšinou tyto hry nelze koupit v kamenném obchod ě. Práv ě takovýmto zp ůsobem je distribuována drtivá většina indie her.
• Hry, které se prodávají v kamenných obchodech a jako dopl ňkový prodej i p řes Internet – pro tyto hry existují dv ě hlavní kategorie:
• Obsah hry je stažen kompletn ě – hrá č nemusí mít p ři hraní p řístup na Internet.
• Hybridní – ze hry je stažena jen část a zbytek je stahován podle pot řeby až p ři hraní. Hrá č musí mít po celou dobu hraní p řístup na Internet.
Vybral jsem p ět poskytovatel ů služby games-on-demand , které jsou v dnešní dob ě nejvíce vývojá ři a hrá či využívány a stru čně jsem shrnul jejich klady a zápory:
App Store Na tomto portálu lze nalézt jen aplikace na za řízení spole čnosti Apple, tedy iPhone, iPod Touch nebo iPad. Než za čne vývojá ř publikovat své aplikace, musí zaplatit poměrn ě vysoký vstupní poplatek 100 dolar ů. Výrobky spole čnosti Apple jsou velmi rozší řené, a proto je zde šance, že se aplikace dostane k velkému množství lidí. Toto m ůže být zárove ň výhoda i nevýhoda, nebo ť se také m ůže stát, že se vaše aplikace mezi kvanty ostatních jednoduše ztratí.
12 Android Market Tento portál se specializuje na prodej aplikací pro mobilní telefony s opera čním systémem Android spole čnosti Google. Jako u App Store je i zde vstupní poplatek, ale zna čně menší - jen 25 dolar ů. Okolo Androidu existuje velká komunita vývojá řů i hrá čů a je tedy snadné nalézt pomoc p ři řešení problému. Tomu také dopomáhá velmi slušná dokumentace celého opera čního systému. Android podporuje 2D i 3D grafiku, akcelerometry, dotykové displeje a další moderní technologie, a proto je vhodný i pro tvorbu her.
Wiiware Jak již napovídá název, je tento portál zam ěř en na hry, které b ěží na herní konzoli Nintendo Wii. I když jejich manaže ři prohlašují, že Wii podporuje indie game vývojá ře [18], je získání Wii Development Kitu tém ěř nemožné. První barierou je jeho cena, která se m ůže vyšplhat až na 10 tisíc dolar ů. Další podmínkou je, aby m ěli vývojá ři p ředchozí zkušenost s vývojem kvalitních her. A poslední absurdní požadavek je, že kancelá ře spole čnosti nesmí být v dom ě, ve kterém některý z vývojá řů bydlí [17]. Nicmén ě Wii je velmi rozší řen a pokud již člov ěk kit získá, tak na tom ur čit ě neprod ělá.
Stream Stream se zam ěř uje na platformu PC a nedávno svou p ůsobnost rozší řil i na Mac. Ke stahování her je zapot řebí mít nainstalovanou aplikaci Stream Store a založený uživatelský ú čet u spole čnosti Valve. Stream vývojá řů m nabízí řadu API, které mohou implementovat do své hry a tím umožnit hrá čů m lepší komunikaci, získávání achivement ů, zobrazovat herní statistiky aj.
13 4 Vývoj nezávislé a komer ční hry
Vývoj indie game se od vývoje komer čních her zna čně liší. První z rozdílu je ve velikosti týmu. Na komer čních AAA hrách (velmi kvalitní hra s vysokým rozpo čtem [22]) může pracovat až n ěkolik stovek vývojá řů . Naopak u indie game je pravidlem, že by se na projektu nem ělo podílet více než 5 lidí. Dalším d ůležitým prvkem p ři vývoji indie game je totiž efektivita a p ředevším rychlost, které samoz řejm ě s nar ůstajícím po čtem dalších lidí klesá. V takto malém týmu se nemá cenu zdržovat vybíráním vhodného vývojového modelu a podobných v ěcí. Pro velmi malé týmy (1-2 lidé) není dokonce ani pot řeba sepisovat rozsáhlý Game Design Document (zkrácen ě GDD), ale sta čí jen pár poznámek a komunikovat osobn ě [21]. Je pot řeba vytý čit si milníky a striktn ě je dodržovat. Tyto milníky musí být splnitelné, proto není rozumné vytvá řet nap říklad 3000 typ ů nep řátel, když máme k dispozici jen jednoho grafika, a to jen na polovi ční úvazek. Bohat ě nám budou sta čit 3 typy [20].
Nezávislý vývojový tým Komer ční vývojový tým
Po čet pracovník ů 1-5 Desítky až stovky
Hraje velkou roli, zisk ze hry Pochopiteln ě i zde jsou velmi není tak velký, aby si tým mohl důležité, ale tým si m ůže Rychlost a efektivita dovolit strávit vývojem velké dovolit jít s ur čitými problémy množství času. více do hloubky a jejich řešením strávit více času.
Pro tak malý tým je nepot řebný Naopak pro tak velký tým je Model vývoje a jeho vypracování by zbyte čně velmi d ůležitý a je vhodné do zabralo p říliš mnoho času. něj investovat peníze a čas.
U velmi malého týmu (1-2 lidé) Velmi d ůležitý. Tvo řen není pot řeba. Avšak pokud se simultánn ě více lidmi ( game Game Design Document jedná o složit ější projekt, či designer , level designer a větší tým, je dobré jej sepsat. další). Mohou obsahovat až stovky stran.
Tabulka 1: Srovnání nezávislého a komer čního vývoje
14 5 Nástroje pro tvorbu indie game
Tato kapitola obsahuje přehled grafických aplika čních rozhraní (anglicky Application Programming Interface a zkrácen ě API), herních engin ů a nástroj ů, které m ůže vývojá ř použit p ři tvorb ě nezávislé hry.
5.1 Aplika ční rozhraní
Aby bylo možné využít potenciálu dnešního grafického hardwaru, musíme mít možnost s tímto hardwarem pohodln ě pracovat. Samoz řejm ě by nebylo p říliš pohodlné pracovat p římo s instrukcemi grafických karet, a proto existují API vyšší úrovn ě, která nad t ěmito instrukcemi vytvá řejí jistou úrove ň abstrakce. Toto dnes umož ňují p ředevším dv ě nejrozší řen ější aplika ční rozhraní - DirectX a OpenGL . V této kapitole si stru čně popíšeme jejich historii a vlastnosti.
5.1.1 DirectX
DirectX je vlastn ě souhrn aplika čních rozhraní, jejichž primárním ú čelem je práce s multimédii. Je zam ěř en především na programování her a práci s videem. Celý DirectX je uzav řený standard a je vyvíjen a spravován pouze jedinou firmou - Microsoft.
HARDWARE HARDWARE
APPLICATION WINDOWS 95
MS-DOS APPLICATION
Obrázek 5.1: Srovnání komunikace hardwaru s opera čním systémem. Vlevo MS-DOS, vpravo Windows 95.
V roce 1994 byl vydán nový opera ční systém Microsoft Windows 95. Na rozdíl od předchozího opera čního systému spole čnosti Microsoft, MS-DOS, neumož ňovaly Windows 95 p římý přístup k periferiím po číta če, jako je myš, klávesnice, zvuková za řízení nebo grafické karty (viz obrázek 5.1). V ětšina herních vývojá řů proto dále vyvíjela hry pro MS-DOS a na Windows 95 se
15 dívala skepticky. Microsoft musel p řijít se zp ůsobem, jak jim tento p řístup umožnit, avšak bez narušení chrán ěného pam ěť ového modelu nového opera čního systému. Řešení byl DirectX, jehož první verze (tehdy ješt ě pod ozna čením Windows Games SDK) byla vydána v zá ří roku 1995 (viz obrázek 5.2). Microsoft poté zahájil intenzivní vývoj DirectX, protože v n ěm vid ěl možnost, jak ke svému opera čnímu systému p řitáhnout nejen velké množství herních vývojá řů a studií, ale posléze i samotných hrá čů . P řibližn ě každý rok Microsoft vydává novou vylepšenou verzi. Aktuální verze je již DirectX 11.
HARDWARE
WINDOWS 95 DIRECTX
APPLICATION
Obrázek 5.2: Řešení problému s p řístupem do chrán ěné pam ěti pomocí DirectX
DirectX je uzav řený standard, a tudíž nepodporuje rozši řování své funkčnosti pomocí extenzí, což byla zpo čátku nevýhoda oproti OpenGL, nebo ť podpora nových funkcí grafických karet je přidána vždy až s novou verzí. Dnes již Microsoft úzce spolupracuje s výrobci grafických karet a jiných periferních za řízení a nové verze jsou vydávány sou časn ě, nebo dokonce d říve, než hardware, který tyto funkce implementuje [24][25]. Na rozdíl od aplika čního rozhraní OpenGL je DirectX kompletn ě objektov ě orientovaný a je zam ěř en pouze na opera ční systém Microsoft Windows. Existují však snahy o jeho implementaci i na jiných systémech (nap ř. Wine pro Linuxové systémy). Jak již bylo zmín ěno výše, je DirectX souhrn aplika čních rozhraní. Jednotlivá aplika ční rozhraní se ozna čují jako komponenty. Skladba komponent se v jednotlivých verzích často liší. Většinou mezi verzemi dojde ke spojení nebo vypušt ění n ěkterých komponent. Následující tabulky ukazuje a stru čně popisuje komponenty verzí 9.0, 10.0 a 11.0 [26].
16 DirectX 9.0 Komponenta Popis DirectDraw Vykreslování 2D grafiky, zastaralé, jen kv ůli zp ětné kompatibilit ě. Direct3D Vykreslování 3D grafiky. Podstatná část celého DirectX. DirectPlay Obstarává sí ťovou komunikaci. DirectInput Zpracování uživatelského vstupu (myš, klávesnice, gamepad...). DirectX Media Přehrávání multimediálního obsahu, streamování, akcelerace videa. DirectMusic Nahrávání a p řehrávání hudby (mp3, ogg...). DirectSound Nahrávání a p řehrávání zvuk ů (wav...). DirectSound3D Přehrávání prostorového zvuku. DirectX Media Objects Obsahuje kodeky, audio a video efekty. DirectSetup Pomocná komponenta pro instalaci sou částí DirectX, detekci verze...
Tabulka 2: Komponenty DirectX 9.0
DirectX 10.0 a 11.0 Komponenta Popis DirectGraphics Tato komponenta slu čuje komponenty, které mají na starost grafiku. Jsou to DirectDraw, Direct2D, Direct3D, DXGI a DirectWrite. DirectCompute Komponenta pro obecné výpo čty na GPU. DirectPlay Zam ěněný za Games for Windows neboli Live. XInput Náhrada za DirectInput. Podporuje i next-get ovlada če. Ostatní komponenty z ůstaly stejné.
Tabulka 3: Komponenty DirectX 10.0 a 11.0 5.1.2 OpenGL
OpenGL (Open Graphics Library) bylo poprvé ve řejnosti p ředstaveno v roce 1992 spole čností Silicon Graphics (zkrácen ě SGI) a byla p ůvodn ě vyvinuta pro opera ční systém Irix. Vlastnictví sice náleželo spole čnosti SGI, ale o vývoj se starala OpenGL Architecture Review Board (zkrácen ě ARB), která se skládala z předních hardwarových a softwarových firem. Ty se pravideln ě scházely, aby probraly zm ěny ve specifikaci OpenGL a schválily sm ěr jeho dalšího vývoje [27]. V roce 2006 převedla firma SGI kontrolu nad vývojem na konsorcium Khronos Group, do které však pat ří skoro všechny spole čnosti p ůvodní ARB. Cílem tohoto grafického aplika čního rozhraní byla hned od po čátku nezávislost na platform ě, hardwaru a programovacím jazyce [23]:
17 • nezávislost na platform ě - Jak již bylo zmín ěno, OpenGL byl p ůvodn ě vytvo řen pro opera ční systém Irix, ale díky jeho multiplatformní architektu ře je dnes dostupný na v ětšin ě opera čních systém ů (Widnows, Unix, Linux, Irix, Sun...)
• nezávislost na hardwaru - OpenGL dokáže na rozdíl od DirectX veškeré funkce provád ět i softwarov ě, bez p řítomnosti grafického hardwaru, který by tyto funkce vykonal. V d ůsledku to znamená, že není pot řeba ov ěř ovat, zda dostupný grafický hardware tuto funkci zvládne, či nikoli.
• nezávislost na programovacím jazyce - Aby bylo dosaženo nezávislosti na programovacím jazyce, je na rozdíl od DirectX OpenGL procedurální (protože ne všechny jazyky podporují objektov ě orientovaný model). Dnes je OpenGL použitelný tém ěř v každém jazyce - C, C++, Fortran, ObjectPascal, Java, Ada, assemblery apod.
Tyto vlastnosti jsou hlavním d ůvodem, pro č se OpenGL využívá v oblastech jako je Computer-aided design (CAD), architektura nebo filmový pr ůmysl.
DISPLAY LIST
PER-VERTEX OPERATIONS PER-FRAGMENT EVALUATOR RASTERIZATION OPERATIONS PRIMITIVE ASSEMBLY
TEXTURE FRAMEBUFFER MEMORY
PIXEL OPERATIONS
Obrázek 5.3: Vykreslovací řet ězec OpenGL
OpenGL obsahuje p řes 250 funkcí a jejich p řetížení pro r ůzné datové typy. Většina z t ěchto funkcí je ur čena bu ď k odeslání primitiva (bodu, úse čky, polygonu p řípadn ě pixmapy nebo bitmapy) do vykreslovacího řet ězce (viz obrázek 5.3) nebo ke zm ěně jeho stavu. Tento stav platí pro všechna primitiva poslaná do řet ězce, dokud není op ět zm ěněn. OpenGL je tady rozsáhlý a komplikovaný stavový stroj [27].
18 5.2 High-level nástroje pro tvorbu her
Aplika ční rozhraní popsaná výše umož ňují práci p římo s grafickým hardwarem na pom ěrn ě nízké úrovni abstrakce. Programátor sice nepoužívá p římo instruk ční sadu konkrétního grafického hardwaru, ale je mu velmi blízko a m ůže takto řídit i ty nejnižší vlastnosti a funkce. Tato nízká úrove ň abstrakce však v ur čitých oblastech vývoje není výhodná nebo je dokonce nežádoucí. Jedna z těchto oblastí je práv ě vývoj her. Jelikož je tvorba her velmi specializovaná oblast vývoje, je nasnad ě, že existuje velké množství specializovaných nástroj ů usnad ňujících vývojá řů m jejich práci - jsou ozna čovány jako herní enginy (anglicky game engines ). Často poskytují b ěžné stavební bloky, ze kterých se skládá v ětšina her - komponenty starající se o uživatelské rozhraní, fyzikální chování objekt ů, částicové systémy, hierarchické uspo řádání objekt ů ve scén ě (graf scény), zvuk, uživatelské vstupy, sí ťovou komunikaci (pro multiplayerové hry), um ělou inteligenci a mnohé další. Obsahují také pomocné struktury pro práci s grafikou, jako jsou 2D a 3D vektory, quaterniony, matice, 2D a 3D textury, obalová tělesa (bounding volumes) a tak dále. Herním vývojá řů m tak usnad ňují jejich práci, nebo ť nejsou nuceni vytvá řet tyto základní bloky a struktury pro každou hru znovu.
5.2.1 Torque Game Engine Advanced
Torque Game Engine (zkácen ě TGE) je dnes již zaniklý 2D a 3D herní engine, který byl p ůvodn ě vyvinut spole čností Dynamix v roce 2001 pro hru Tribe 2. Velká část vývojá řů z týmu podílejícím se na tvorb ě této hry odešla z Dynamix a založila spole čnost GarageGames. TGE si vzali s sebou, přepracovali jej, aby využívala nejnov ější technologie a nakonec jej p řejmenovali na Torque Game Engine Advanced (zkrácen ě TGEA). GarageGames byla pozd ěji odkoupena spole čností InstantAction. Velmi rychle se stal oblíbených nástrojem pro vývoj nezávislých her, nebo ť cena za licenci byla 75 dolar ů na programátora, pokud spole čnost nevyd ělávala p řes 250 tisíc dolar ů ro čně. Pokud ano, tak byla cena 2250 dolar ů na programátora, což byla (v porovnání nap říklad s Unreal Enginem 2, jehož licence stojí 350 tisíc dolar ů) nadále velmi nízká částka. Dne 11.11.2010 však InstantAction oznámilo, že zastavuje všechny své aktivity a tím pádem i vývoj TGEA. V sou časné dob ě stále hledá pro TGEA kupce, který by v jeho vývoji pokra čoval [30].
Hlavní rysy Torque Game Engine Advanced se d ělí na n ěkolik variant, které se liší v platform ě, na kterou jsou navrženy a zda jsou ur čeny pro 2D nebo 3D hru. Následuje jejich seznam:
• Torque 3D a 2D - Tyto varianty jsou ur čeny pro vývoj her na PC a Mac.
• iTorque 2D - Jak již první písmeno názvu napovídá, je tato varianta ur čena pro vývoj na platformách iPhone, iPad a iTouch. Zatím existuje jen 2D verze a jelikož je další vývoj enginu pozastaven, není ani jisté, zda bude n ěkdy 3D verze existovat.
• Torque X - Tato varianta umož ňuje vývoj na PC a Xbox 360. Na rozdíl od p ředchozích je napsána v jazyce C# a je postavena na Microsoft XNA Game Studio.
19 Torque je velmi rozsáhlý a propracovaný herní engine, proto zde zmíníme jen ty nejd ůležit ější hlavní rysy, které z n ěj d ělají tak žádaný engine:
• Vykreslování 2D a 3D grafiky pomocí nejmodern ějších metod. • Skriptování, sí ť, zvuk. • Vestav ěné editory: terén, řeky a cesty, částicové systémy, materiály, úrovn ě. • Pokro čilé metody osv ětlení: Per-pixel osv ětlení, normal & parallax occlusion mapping , volumetric fog a volumetric light . • Integrace fyzikálního enginu spole čnosti NVidia - PhysX. • Velmi nízká cena za licenci. • Pokrytí skoro všech platforem, na kterých lze vyvíjet a hrát hry. • Obsáhlá a velmi kvalitní dokumentace.
Screenshoty Ukázky z některých her, které byly vytvo řeny pomocí herního enginu Torque Game Engine Advanced.
Obrázek 5.4: Screenshoty ze hry Dreamlords od společnosti Lockpick Entertainment
Obrázek 5.5: Screenshoty ze hry Buccaneer: The Pursuit of Infamy spole čnosti Stickman Studios
20 5.2.2 Unreal Engine
Unreal Engine je herní engine vyvíjený spole čností Epic Games. Jeho první verze byla použita v roce 1998 v FPS ( First Person Shooter ) h ře Unreal. Stala se také základem pro další hry, jako jsou Unreal Tournament, Deus Ex, Turok a další. I když byl tento engine p ůvodn ě vytvo řen pro FPS hry, byl úsp ěšn ě použit i v jiných žánrech, nap říklad v MMORPG (Massive(ly)-Multiplayer Online Role- Playing Game) hře Vanguard: Saga of Heroes. Jelikož je jeho jádro napsáno v C++ a podporuje zobrazování pomocí DirectX i OpenGL, je velmi snadno p řenositelný na r ůzné platformy. Jeho nejnov ější verze (Unreal Engine 3) je schopna fungovat na platformách Microsoft Windows, Linus, iOS, Mac OS, dále pak i na řad ě konzolí - Dreamcast, Xbox, Xbox 360, Playstation 2 a Playstation 3. Obsahuje řadu pomocných nástroj ů, které vývoj hry velmi usnad ňují. Skoro veškeré programování probíhá v proprietárním skriptovacím jazyce UnrealScript a není tak pot řeba významn ě zasahovat do jádra enginu. Pro vytvá ření jednotlivých úrovní se používá edita ční nástroj nazvaný UnrealEd, který se velmi snadno ovládá a designer okamžit ě vidí, jak bude úrove ň ve h ře vypadat. Unreal Engine již existuje ve své t řetí verzi a jsou na n ěm postaveny hry jako je Bioshock, Bioshock 2, Gears of War (všechny t ři jeho díly), XIII, Unreal Tournament 3 a další. Je zajímavé vid ět porovnání vykreslovacích schopností této verze s p ředchozími (viz obrázek 5.6).
Obrázek 5.6: Porovnání vykreslovacích schopností Unreal Enginu 1, 2 a 3 na modelu herní postavy Malcom
V zim ě roku 2009 uvolnilo Epic Games verzi Unreal Enginu, která je pro nekomer ční užití kompletn ě zdarma - nazvalo ji Unreal Development Kit (UDK). V p řípad ě komer ční hry musí vývojá ři zaplatit pouhých 99 dolar ů a poté 25% ze zisku, pokud p řesáhne 5000 dolar ů. Epic Games se tak snaží rozší řit sv ůj engine i mezi indie game vývojá ře, nebo ť tato nízká částka (vzhledem k tomu, jak je Unreal Engine propracovaný) je pro n ě dosažitelná. Epic Games oznámilo, že další verzi Unreal Enginu neplánují d říve, než se na trhu objeví nová generace herních konzolí. Jakmile se tak stane, bude Unreal Engine 4 vytvo řen exkluzivn ě jen pro tyto konzole a s implementací na jiné platformy se nepo čítá [33].
21 Hlavní rysy
• Velmi robustní herní engine, který obsahuje vše, co může vývojá ř pot řebovat. • Pro nekomer ční užití od listopadu roku 2009 zdarma. • Proprietární skriptovací jazyk UnrealScript - podstatná část vývoje probíhá práv ě v n ěm, bez nutnosti zasahovat do jádra enginu. • Editor úrovní - UnrealEd - se velmi snadno používá. Designer okamžit ě vidí, jak bude úrove ň vypadat ve h ře. • Velké množství zabudovaných nástroj ů - UnrealCascade (částicové systémy, exploze, ohn ě…), UnrealMatinee (in-game videa), UI Editor (uživatelské rozhraní), Sound Cue Editor (zvuk a hudba) a další.
Screenshoty Ukázky z her, které byly na Unreal Enginu postaveny. Konkrétn ě se jedná o hry Unreal Tournament ve svých verzích 2004 a 3.
Obrázek 5.7: Screenshoty ze hry Unreal Tournament 2004
Obrázek 5.8: Screenshot ze hry Unreal Tournament 3
22 5.2.3 Microsoft XNA Game Studio
XNA Game Studio je sada knihoven a nástroj ů, zam ěř ená na usnadn ění tvorby po číta čových her. Je to uzav řený produkt a o jeho vývoj se stará pouze spole čnost Microsoft, což zajiš ťuje výbornou podporu a dokumentaci. XNA je jednotná platforma pro vývoj na PC, Xboxu a dokonce i na Windows Phone 7. Jedná se v podstat ě o zapouzd ření funkcí rozhraní DirectX 9.0 s vysokou úrovní abstrakce. Avšak pokud se k tomu programátor rozhodne, má stále možnost p římo pracovat s nejelementárn ějšími funkcemi grafického hardwaru. Celé XNA je vystav ěno na .NET frameworku 2.0 a tak lze k vývoji her teoreticky použít kterýkoli z jazyk ů kompatibilních s .NET (nap říklad Visual Basic, Visual J# nebo Visual C++), avšak jen Visual C# je oficiáln ě podporován a navíc je jako jediný integrován do Visual Studia tak, aby p ři vývoji XNA hry programátorovi napomáhal p ři psaní zdrojového kódu. Základem každého projektu je instance t řídy Game , která obsahuje virtuální metody, jež XNA volá automaticky v následujícím po řadí. Do t ěchto metod vývojá ř implementuje v ětšinu zdrojového kódu [35].
• Initialize - Volá se jako první a slouží k inicializaci všech negrafických zdroj ů (nap ř. otev ření soubor ů, inicializace pomocných struktur atd.). Je zavolána jen jednou po spušt ění hry. • LoadContent - Tato metoda je zavolána p římo z metody Initialize a slouží k na čtení veškerého grafického obsahu hry (nap ř. model ů, textur atd.). Je zavolána jednou p ři spušt ění hry a pak vždy, když je pot řeba znovu načíst grafické zdroje, nap říklad p ři restartu grafického za řízení. • Update - Aktualizuje herní mechanismy (nap ř. fyziku, pohyb hrá če, stav jeho zdraví atd.) • Draw - V této metod ě probíhá vykreslování scény. • UnloadContent - Metoda je zavolána p ři ukončení hry a má za úkol uvolnit všechny na čtené grafické zdroje.
I když XNA tvorbu her velmi usnad ňuje, nelze jej ozna čit za plnohodnotný herní engine. Neobsahuje v podstat ě žádné obecné herní komponenty, jako jsou nap říklad graf scény nebo podpora uživatelského rozhraní. Je však možné vytvá řet herní komponenty a služby, které lze poté bez velkého úsilí zakomponovat do jakéhokoliv XNA projektu. K vytvo ření komponenty sta čí naimplementovat svou t řídu, která d ědí z XNA t řídy GameComponent nebo DrawableGameComponent (pokud má komponenta n ěco p římo vykreslovat do scény - nap říklad komponenta zobrazující aktuální po čet snímk ů za sekundu). Takto vytvo řená třída má pak stejné metody jako t řída Game a již ji sta čí jen zaregistrovat, aby byly tyto metody automaticky volány. Jakákoli t řída m ůže implementovat rozhraní, které poté m ůže nabízet jako službu. Tuto službu musí, podobn ě jako u komponent, zaregistrovat u hlavní t řídy Game . Poté m ůže kterákoli t řída s přístupem k objektu Game požádat o poskytovatele této služby a využívat jej bez nutnosti mít jakýkoli vztah s jeho konkrétní t řídou [34].
23 Hlavní rysy
• High-level zapouzd ření knihoven DirectX 9.0 • Multiplatformní - snadná konverze mezi platformami PC, Xbox, Zune a Windows Phone 7 - většinou sta čí velmi málo úprav. • Integrace do Visual Studia - velmi usnad ňuje a urychluje vývoj. • Neobsahuje základní herní komponenty - nap ř. graf scény, fyziku atd. • Podporuje jen platformy kompatibilní s Windows. • Velmi vysoká znovupoužitelnost kódu díky herním komponentám a službám.
Screenshoty
Obrázek 5.9: Screenshoty z her Schizoid a Culture
Obrázek 5.10: Screenshot ze hry Racing Starter Game
24 6 Tvorba enginu
Engine vznikal vícemén ě sou časn ě s hrou a reflektoval požadavky a pot řeby, které p ři jejím vývoji vznikaly. Jako celek jej lze proto bez v ětších úprav použít jen pro tvorbu her stejného žánru - tedy Real-time strategy (dále jen RTS). Nicmén ě v ětšinu jednotlivých komponent lze samostatn ě znovupoužít i v ostatních herních projektech s jiným žánrem. Engine, který bude v následujících kapitolách popsán, je vystav ěn nad platformou XNA Game Studio 4.0 , jejíž použití je jednou z podmínek sout ěže ImagineCup , kam byla hra p řihlášena.
6.1 Návrh enginu
Před samotným vývojem hry by se m ěli vývojá ři zamyslet a uvážit, zda není jejich hra natolik jednoduchá, že žádný složitý engine vlastn ě ani nepot řebuje. V takovém p řípad ě je lepším řešením vytvo řit kód specifický jen pro danou hru a s vývojem obecného enginu neztrácet čas. Dalšími kriterii, která mohou ovlivnit toto rozhodnutí, jsou čas a prost ředky, které má tým k dispozici. Prost ředky se zde nemyslí jen ty finan ční, ale nap říklad i po čet a zkušenosti vývojá řů . Vzhledem k rozsáhlosti našeho projektu se nedalo o "bezenginové" variant ě ani uvažovat. Problémem však byl čas, kterého nebylo nazbyt, a necht ěli jsme skon čit jako mnoho ostatních tým ů, které sice vytvo řily velmi obecné a rozsáhlé enginy, avšak jim již nezbyl čas na vytvo ření a dolad ění samotné hry. Z t ěchto d ůvod ů jsme zvolili kompromis mezi obecností a časovou náro čností a vytvo řili malý kompaktní engine, který byl vystav ěn na míru naší h ře. Krom ě základních komponent, vznikala většina funkcí až podle aktuálních pot řeb a požadavk ů p ři vývoji. Dále jsme se rozhodli využít systém komponent a služeb, které XNA nabízí a nevytvá řet centrální t řídu, která by jako své členy m ěla jednotlivé části enginu. Místo toho je každá část zděděna z XNA komponenty nebo služby. Takto si m ůže vývojá ř, používající náš engine, snadno a podle svých pot řeb zvolit, které části využije a které ne. Sta čí naši komponentu přiřadit hře jako aktivní. Má pak i větší volnost ve volb ě po řadí updatování a vykreslování jednotlivých komponent.
6.1.1 SceneManager
Velmi d ůležitou části každého herního enginu je komponenta, která reprezentuje takzvaný graf scény. Je to kolekce uzl ů (anglicky nodes ) uspo řádaná do nějaké hierarchické struktury, nej čast ěji však do grafu nebo stromu. Jednotlivé uzly jsou spojeny hranami a dohromady tak vytvá řejí hierarchii scény. Uzly mohou reprezentovat r ůzné typy entit, které se v každé h ře mohou více či mén ě lišit. Existuje však několik základních typ ů, které jsou ve v ětšin ě her stejné, nap ř. předdefinované 3D objekty (krychle, válec…), libovolný animovaný/neanimovaný 3D objekt nebo různé zdroje sv ětla [36]. Vyjma ko řenového uzlu, který je vstupním bodem grafu scény, má každý uzel svého rodi če. Ty, které mohou mít potomky, nazýváme skupinové ( group ) a ty které nemohou, jsou listové ( leaf ). Při návrhu našeho grafu scény jsme však tuto možnost zanedbali a všechny naše uzly vytvo řili jako skupinové. Tímto opat řením se implementace velmi zjednodušila a p řitom byly zachovány všechny funkce grafu s listovými uzly. Hierarchické uspo řádání uzl ů není zvoleno jen kv ůli snadn ějšímu a rychlejšímu hledání konkrétního uzlu, ale také proto, že jakákoli zm ěna rodi če se projeví stejn ě i na jeho potomcích. Díky
25 tomuto lze snadno sdružovat části jednoho objektu do skupin, které lze m ěnit a ovládat jako celek, a přitom si zachovat kontrolu nad jednotlivými podobjekty. Nejlépe to popisuje obrázek 6.1, na kterém vidíme jednoduchou stromovou hierarchickou strukturu, která popisuje vozidlo Humvee. Z obrázku je patrné, že se skládá z hlavního objektu, ke kterému jsou p řipojeny čty ři kola, kulomet a částicový systém, který je aktivován, pokud je vozidlo zni čeno (exploze). Jednotlivé části mají také své potomky. Každé kolo má částicový systém generující za jízdy vozidla prach, kulomet má částicové systémy dokonce dva - jeden simuluje ohe ň u hlavn ě p ři st řelb ě a druhý generuje prázdné nábojnice. Toto rozd ělení nám dává dostate čný stupe ň kontroly nad jednotlivými částmi Humvee a zárove ň m ůžeme ovládat vozidlo jako celek. Pokud nap říklad pooto číme kola tak, aby sm ěř ovala ve sm ěru jízdy, upraví se i pozice a nato čení připojeného částicového systému. Také je možné nato čit kulomet požadovaným sm ěrem bez toho, aby bylo nutné rotovat s celým vozidlem. P řipojené částicové systémy budou samoz řejm ě rotovat s kulometem a zachovají si tak správnou pozici.
ROOT NODE
3D OBJECT HUMVEE
3D OBJECT 3D OBJECT 3D OBJECT 3D OBJECT WHEEL WHEEL WHEEL WHEEL
PARTICLE SYSTEM PARTICLE SYSTEM PARTICLE SYSTEM PARTICLE SYSTEM DUST DUST DUST DUST
PARTICLE SYSTEM 3D OBJECT EXPLOSION E MACHINE GUN (DEATH)
PARTICLE SYSTEM PARTICLE SYSTEM FIRE AT TIP CARTRIDGES
Obrázek 6.1: Ukázka jednoduchého grafu scény
6.1.2 ScreenManager
Většina her se skládá z r ůzného po čtu obrazovek, mezi kterými se hrá č svou interakcí pohybuje. Pojem obrazovka zde není chápán jen jako hlavní menu nebo obrazovka s nastavením, ale m ůže se jednat i samotnou hru - herní logika m ůže být naprogramována p římo v jedné obrazovce. Tato komponenta byla navržena tak, aby umož ňovala vývojá ři takovéto obrazovky vytvá řet, spravovat a
26 přepínat mezi nimi. Tento návrhový vzor jsme p řevzali z ukázkové aplikace spole čnosti Microsoft [37].
INTRO MAIN MENU OPTIONS
save options
start game pop-up MAIN MENU GAME GAME MENU
return to game
win/lose exit game GAME MISSION END MAIN MENU
Obrázek 6.2: Ukázka hypotetického screen-flow diagramu
6.1.3 Input
I takto malý engine by m ěl být schopen poskytnout vývojá ři snadný a intuitivní p řístup k uživatelským vstup ům. Ty je však pot řeba zpracovávat na r ůzných místech hry. Bylo by nepohodlné si tuto komponentu neustále p ředávat a ukládat v každé t říd ě zvláš ť, a proto jsme se implementovali Input jako XNA službu. Dále jsme se rozhodli nepodporovat Xbox, a tudíž jsme se soust ředili jen na myš a klávesnice.
Tato služba by m ěla být schopná zachytávat následující standardní události:
• Stisknutí, držení a uvoln ění klávesy • Stisknutí, dvojklik, držení a uvoln ění tla čítka myši • Získat a nastavit pozici myši • Získat pooto čení kole čka myši
Dále jsme cht ěli vývojá ři zajistit n ějakou kontrolu nad pohybem myši, a proto jsme do návrhu za řadili i následující funkce:
• Uzamknutí pozice myši na ur čitém míst ě obrazovky • Uzamknout pohyb myši v ur čité oblasti obrazovky - většinou v okn ě hry • Zjišt ění, u kterého okraje/rohu obrazovky je myš - pro pohyb kamery v RTS hrách
6.1.4 GUIManager
Velmi d ůležitou sou částí každé hry je grafické uživatelské rozhraní ( Graphical User Interface , dále jen GUI), pomocí kterého hrá č hru ovládá, p řípadn ě mu hra skrze n ěj poskytuje r ůzné informace o
27 stavu hry. Navrhli jsme proto komponentu GUIManager , která se o vše okolo GUI stará. Dop ředu jsme si vytipovali prvky, které budeme bezpodmíne čně pot řebovat a zahrnuli je do návrhu:
• Container - nemá žádné grafické znázorn ění a slouží jen jako kontejner pro ostatní prvky • Button - klasické tla čítko, jehož grafické znázorn ění se m ůže m ěnit podle jeho stavu - normal , hovered , disabled a clicked • Image - obrázek, lze jej použít nap říklad pro zobrazení statických částí GUI • Scrollbar - posuvník, často používaný na posouvání čteného textu nebo pro nastavení hodnoty z n ějakého rozsahu • Label - jednoduché textové pole s možností standardního zarovnávání textu, v četn ě zarovnání do bloku • NinePatch – libovoln ě roztažitelný obrázek, který se skládá z 9 menších obrázk ů (4 rohy, 4 hrany a vnit řní část)
Každý prvek je p římo, či nep římo zd ěděn z obecného prvku. Tímto se eliminuje nutnost znovu a znovu opakovat tentýž kód pro parametry, které jsou u všech prvk ů totožné, nap ř. pozice nebo velikost. Dalším d ůležitým bodem bylo navrhnout hierarchickou strukturu, ve které by byly prvky uloženy. Vytvo řením takovéto struktury se velmi usnadní práce se skupinami navzájem souvisejících prvk ů, nap ř. prvky jedné obrazovky. Abychom obrazovku skryli, museli bychom skrýt každý prvek zvláš ť. V hierarchické struktu ře však sta čí skrýt jejich spole čného rodi če, což velmi zjednoduší a zp řehlední implementaci herního GUI. Princip je velmi podobný jako u grafu scény popsaného v kapitole 6.1.1. Následn ě bylo pot řeba vy řešit řízení po řadí vykreslování jednotlivých prvk ů. Standardní a nejjednodušší metoda je využití již existující hierarchické struktury a vykreslovat prvky v po řadí v jakém byly p řidány. Zm ěnu po řadí pak lze realizovat p řesunem prvku na za čátek, resp. na konec seznamu potomk ů ( bring to front , resp. send to back ). Druhá varianta je nezávislá na po řadí p řidávání, avšak je náro čnější, a to jak z hlediska výkonu, tak z hlediska implementace. Každému prvku je p ři vytvá ření p řiřazena hloubka, kterou však lze za běhu kdykoli zm ěnit. Prvky jsou pak podle této hloubky se řazeny a následn ě vykresleny. I zde je však nutné brát v potaz hierarchii, a tedy hloubky rodi čů . Nejjednodušší se ukázalo zvyšovat hloubku o konstantu s každou úrovní zano ření v hierarchické struktu ře. Je z řejmé, že herní GUI musí být interaktivní a zachytávat alespo ň základní události, jako jsou MouseDown , MouseMove , MouseUp , MouseWheel , MouseEnter a MouseLeave . V n ěkterých případech je výhodné p řesm ěrovat všechny zachycené události jen jednomu konkrétnímu prvku (mouse capture ), nap ř. p ři tažení scrollbaru se často stane, že myš opustí oblast posuvníku a tím se tažení p řeruší. Toto lze vy řešit aktivací p řesm ěrování do scrollbaru p ři za čátku tažení a následného zrušení p řesm ěrování p ři ukon čení tažení.
6.1.5 CutsceneManager
Pro vytvá ření p ředem p řipravených in-game anima čních sekvencí - cutscén - jsme navrhli komponentu nazvanou CutsceneManager . Tyto sekvence lez využít nap říklad k uvedení hrá če do d ěje konkrétní mise nebo vytvo ření tutoriálu. Každá cutscéna je rozd ělena do n ěkolika sekvencí, které se dále d ělí na akty. Sekvence m ůže být dvojího typu - lineární nebo paralelní. Pokud je lineární, jsou akty této sekvence vykonány
28 postupn ě za sebou, v p řípad ě paralelní sekvence jsou spušt ěny všechny akty v jeden okamžik. Na obrázek 6.3 je první sekvence paralelní, a tedy se kamera za čne pohybovat ve stejnou chvíli, v jaké se objeví titulky. Druhá sekvence je totožná s první až na to, že je lineární. To znamená, že titulky se zobrazí až po tom, co kamera ukon čí sv ůj pohyb.
CUTSCENE
PARALLEL LINEAR SEQUENCE SEQUENCE
CAMERA MOVE CAMERA MOVE SUBTITLES ACT SUBTITLES ACT ACT ACT
Obrázek 6.3: Ukázkové schéma cutscéna
Následující seznam ukazuje několik typ ů akt ů, které jsou obecné a je možné je použít v kterémkoli žánru:
• Move camera - plynule přesune kameru na zadané sou řadnice • Move camera look at - plynule p řesune kameru tak, aby se dívala na zadané sou řadnice • Wait - vy čká po zadaný časový úsek • Play sound - přehraje zadaný zvuk
Vývojá ř si samoz řejm ě m ůže velmi snadno vytvo řit specifické akty, které jeho hra pot řebuje. Nap říklad pro žánr RTS jsme navrhli tyto další akty:
• Move RTS camera - plynule p řesune kameru na zadané sou řadnice, p řičemž zachová přiblížení RTS kamery • Show target marker - na zadaných sou řadnicích zobrazí na terénu zna čku • Wait for unit selection - vy čká, dokud hrá č neozna čí jednotku daného typu
6.1.6 Camera
Další nepostradatelná komponenta jakéhokoli enginu je bezesporu kamera. Bylo pot řeba vytvo řit abstrakci nad projek ční a pohledovou maticí, nebo ť s t ěmito entitami se člov ěku velmi špatn ě pracuje a t ěžko si je p ředstavuje. Daleko p řirozen ější je pro n ěj kameru chápat jako bod s pozicí a rotací v prostoru. Všechny operace spojené s vytvá řením a manipulaci s ob ěma výše zmín ěnými maticemi pak komponenta ud ělá skryt ě. Musí být také schopná po čítat i další užite čné a často využívané parametry kamery, nap ř. vektor, podél kterého se kamera dívá ( forward vector ), pohledové t ěleso ( viewing frustum ) atd.
29 Jelikož bude tato kamera používána v ětšinou ve hrách, je nutné, aby s ní mohl hrá č v prostoru pohybovat. K tomu je zapot řebí možnost nastavení maximální rychlosti pohybu a maximální rychlosti rotace. Nakonec je pot řeba umožnit vývojá ři nastavení kláves, které budou kameru ovládat. Každý žánr, a n ěkdy dokonce i dv ě r ůzné hry stejného žánru, mají na kameru r ůzné požadavky. Z tohoto d ůvodu byla tato část enginu navržena co možná nejobecn ěji a nejjednodušeji, aby z ní bylo možné podle pot řeby d ědit a vytvá řet tak specializované kamery. Prozatím jsme navrhli tyto:
• Free camera - kamera nemá žádná omezení a hrá č ji m ůže pomocí kláves a myši p řesunout na libovolné místo prostoru • RTS camera - pohyb kamery se ovládá pomocí kláves, ale také najetím myši k okraji okna. Otá čením kole čka myši je možné kameru p řibližovat a po stisknutí prost ředního tla čítka je možné kamerou rotovat okolo bodu, na který se práv ě dívá.
6.1.7 Cursor
V dnešních opera čních systémech je b ěžné, že se kurzor myši m ění podle situace a dává tak uživateli informaci o tom, co se práv ě d ěje, p řípadn ě, co se p ři kliku stane či nestane. Ve hrách tomu není jinak, ba dokonce má tato funkce často d ůležit ější úlohu než v desktopových aplikacích - lze nap říklad ihned poznat, kdo je nep řítel, či p řítel, zda s p ředm ětem pod kurzorem jde provést n ějakou akci atd. V neposlední řad ě je kurzor estetická záležitost a existuje jen málo her, které by nem ěly vytvo řené své vlastní, slad ěny s grafickým stylem hry. Navrhli jsme tedy velmi jednoduchou službu, která by se o zm ěny kurzoru starala a která by jej dokázala v p řípad ě pot řeby i skrýt a znovu zobrazit.
6.1.8 Audio
Aby byla hra kvalitní a konkurenceschopná, musí krom ě dobrého vizuálního vjemu poskytovat i kvalitní zvuky a hudbu. O to by se m ěla starat práv ě komponenta Audio , která musí být schopná pomocí jednoduchého rozhraní p řehrávat zvuky, umis ťovat je do trojrozm ěrného prostoru a v p řípad ě pot řeby je p řehrávat v nekone čné smy čce. V XNA existují dv ě možnosti, jak na číst a p řehrát zvuk. První z nich se hodí na jednoduché přehrávání typu fire-and-forget , takže není velmi vhodná pro složit ější hry, které vyžadují úplnou kontrolu nad přehráváním. Tato komponenta byla proto hned od za čátku zamýšlena jako zjednodušení a zapouzd ření pon ěkud kostrbatého a t ěžkopádného rozhraní knihovny Cross-platform Audio Creation Tool (dále jen XACT).
6.1.9 DebugOutput
Pro výpis pomocných text ů a po čtu snímk ů za sekundu (Frames Per Second , dále jen FPS) při lad ění hry jsme navrhli t řídu DebugOutput , která tyto informace zobrazuje do levého horního rohu obrazovky. Tato t řída není XNA komponenta jako v ětšina části našeho enginu, ale je zděděna z XNA služby. Výpis pomocných text ů je totiž podobn ě jako p řístup k uživatelským vstup ům pot řeba v mnoha místech enginu a hry.
30 6.2 Implementace enginu
V této kapitole naleznete konkrétní postupy p ři implementaci výše navržených komponent a služeb. U většiny naleznete napravo hned pod nadpisem tabulku, které p ředstavuje rozhraní dané komponenty. Obsahuje však jen d ůležité metody a položky. Měla by pomáhat v pochopení n ěkterých implementa čních postup ů. Před samotnou implementací je vhodné dohodnout, jak budete kód strukturovat, rozd ělit úkoly a vytvo řit milníky. Dobrou praxí je zvolit vedoucího projektu, který se bude mimo jiné starat o administrativu okolo vývoje - plánování, rozd ělování úkol ů, komunikaci s exernisty atd. Pro vým ěnu, synchronizaci a verzování kódu je dobré použít n ěkterou metodu Source Code Managementu - nap ř. SVN nebo Mercurial. Osv ědčilo se také založení projektové wikipedie pro zapisování poznámek, nápad ů a TODO list ů. V p řípad ě, že vlastníte sv ůj server, existuje hned n ěkolik bezplatných wiki balí čků, nap ř. MediaWiki . Pokud server nemáte, m ůžete využít n ěkterou z bezplatných online služeb a wiki si založit u nich, nap ř. Wikidot .
6.2.1 SceneManager
ů ě I když se jedná o jednu z nejd ležit jších SceneManager částí našeho enginu, je jeho základní implementace pom ěrn ě jednoduchá. Graf Node RootNode ; scény jsme se rozhodli implementovat jen StaticMeshNode AddStaticMeshNode (Model č jako jednoduchý strom, jelikož dosta oval model, Vector3 position, Node parent); pro ú čely naší hry. Nepot řebovali jsme BillboardNode AddBillboardNode (Texture2D nap říklad, aby m ěl jeden objekt více rodi čů billboard, Node parent, Vector3 position); nebo aby byly uzly provázány jinak než A další… vztahem rodi č-potomek. K přidávání uzl ů r ůzných typ ů slouží metody, které za čínají slovem Add a kon čí slovem Node , nap ř. AddStaticMeshNode , která p řijímá jako parametr 3D model a pozici. Další takovou metodou je AddPointLightNode , která navíc ješt ě p řijímá parametry sv ětla (barva, utlumení atd.). Každá tato metoda má navíc parametr, který ur čuje, ke kterému uzlu bude navázána jako potomek. Při každém updatu je tento strom rekurzivn ě Node procházen a každý uzel je aktualizován. Vstupním bodem této rekurze je ko řenový uzel, který není Vector3 Position ; reprezentován žádným objektem, avšak hraje velmi Quaternion Rotation ; důležitou roli, nebo ť každý uzel si udržuje pole svých Vector3 Scale ; bool Visible ; ů č potomk a tento není výjimkou. Slouží totiž jako rodi Node Parent ; objekt ům nejvyšší úrovn ě scény. Každý uzel je p ři List
AbsoluteMatrix . Takto lze vytvá řet i složité systémy void AddChild (Node node); provázaných objekt ů. Pro získání nebo zm ěnu pozice, bool RemoveChild (Node node); rotace a škály, relativní k rodi či, lze použít položky void RemoveFromParent ();
31 Position , Rotation a Scale , které má každý typ uzlu. U n ěkterých typ však n ěkteré položky nemají význam – nap ř. rotace u všesm ěrového sv ětla. Bylo by zbyte čné vykreslovat objekty scény, které nejsou vid ět. Proto jsme implementovali velmi jednoduchý algoritmus, který p římo p ři vykreslování ur čuje, zda je objekt v záb ěru kamery, či nikoli. V XNA je implementace velice snadná, nebo ť zde existují p ředp řipravené struktury pro obalová t ělesa ( BoundingShpere , BoundingBox a další), která mají metody na zjišt ění vzájemného pr ůniku a také, zda jedno t ěleso obsahuje druhé. Ke zjišt ění viditelnosti modelu pak již jen sta čí tyto metody zavolat a jako parametry jim p ředat pohledové t ěleso kamery (viz obrázek 6.5) a obalové těleso modelu. Pokud jsou v prostoru pohledového t ělesa, nebo jej jen protínají, jsou vykresleny běžným zp ůsobem. V opa čném p řípad ě je jejich vykreslování p řesko čeno. Tato metoda se nazývá view frustum culling . Pro další zvýšení rychlosti by bylo možné implementovat jeden z algoritm ů pro d ělení 3D prostoru, nap říklad často používaný a oblíbený octree . Pro zvýšení p řesnosti detekce kolizí lze použít hierarchii obalových t ěles ( Bounding Volume Hierarchy ).
6.2.2 ScreenManager
Tuto komponentu jsme implementovali podle ScreenManager návrhového vzoru p řevzatého z ukázkových ř ů p íklad k XNA Game Studio 4.0 [citace]. Její List
32 6.2.3 Input
Tuto službu lze implementa čně rozd ělit do t ří částí. První, resp. druhá část obstarává zachytávání uživatelských vstup ů z klávesnice, resp. myši. Poslední část zajiš ťuje vývojá ři možnost omezení pohybu myši.
Klávesnice ř Platforma XNA dokáže pomocí t ídy Keyboard a její metody Input GetState zjistit aktuální stav celé klávesnice v daném moment ě. keyboard My ovšem pot řebujeme zjistit stav pouze jedné klávesy a navíc ě ě ě bool KeyDown (); rozlišit práv stisknutou klávesu ( KeyDown ), práv uvoln nou bool KeyDown (Keys key); klávesu ( KeyUp ) a úsek mezi t ěmito dv ěma událostmi ( KeyHold ). bool KeyHold (Keys key); Pro zjišt ění práv ě stisknuté klávesy se nám nabízí využít bool KeyUp (Keys key); přímo metodu GetState a z vráceného seznamu zjistit, zda je v něm i námi požadovaná klávesa. Tento p řístup však selže v p řípad ě nízkého FPS, kdy m ůže hrá č stisknout a uvolnit klávesu v časovém úseku mezi dv ěma updaty a tak v ůbec nedojde k rozpoznání události. Problém také nastane, pokud hrá č klávesu podrží delší dobu, než trvá jeden update. Input totiž nemá žádnou informaci o tom, že klávesa již byla v minulém updatu stisknuta a událost KeyDown rozpozná znovu, p řestože by m ělo být rozpoznáno KeyHold . Je jasné, že tímto zp ůsobem nelze ani zajistit správnou funkci události KeyUp . Z t ěchto d ůvod ů jsme implementovali velmi jednoduchou, avšak ú činnou metodu, která minimalizuje tyto neduhy. Metoda si po provedení updatu uloží stav klávesnice, což jí v následujícím updatu umožní porovnat starý stav s tím aktuálním a vyhodnotit tak, která událost mezi updaty nastala. Vyhodnocení probíhá podle následujícího schématu:
Je klávesa stisknuta? Předchozí update Aktuální update
KeyDown NE ANO KeyHold ANO ANO KeyUp ANO NE
Tabulka 4: Schéma vyhodnocování události klávesnice
Rozhraní je velmi intuitivní a jednoduché - vývojá ři sta čí jen zavolat metodu KeyDown , KeyUp nebo KeyHold , jako parametr jí p ředat klávesu, která jej zajímá a metoda vrátí, zda tato událost pro tuto klávesu nastala. Ve hrách všech žánr ů se často vyskytuje notoricky známá pobídka ke stisku libovolné klávesy. Aby vývojá ř nemusel testovat všechny klávesy přímo v kódu své hry, vytvo řili jsme také bezparametrovou metodu KeyDown , která tuto práci ud ělá za n ěj.
33 Myš ř I pro práci s myší existuje t ída Mouse s metodou Input GetState , která vrací aktuální pozici ukazatele a mouse stav tla čítek. A i zde nastal stejný problém se správným rozpoznáváním událostí jako u klávesnice. byte MouseButtonsPressed ; ě ř EdgeFlag EdgeFlags ; Našt stí lze tento problém vy ešit velmi podobným int EdgeWidth ; zp ůsobem. Jediný rozdíl je v tom, že t řída, kterou float DoubleClickTime ; vrací metoda Mouse.GetState , má pro každé tla čítko zvláštní položku a neexistuje žádná metoda, Point GetMousePosition (); void SetMousePosition (int x, int y); jež by jako parametr brala nap říklad číslo tla čítka a bool MouseDown (); vracela jeho stav. Našt ěstí je tla čítek na myši bool MouseDown (MouseButtons button); pom ěrn ě málo a zkontrolovat všechny tyto položky bool MouseHold (MouseButtson button); ř č ě bool MouseUp (MouseButtons button); není p íliš náro né. Necht li jsme však toto int GetWheelScroll (); nepohodlí p řenášet i na uživatele našeho enginu, a bool MouseDoubleClick (); proto jsme rad ěji vytvo řili vý čtový typ (enumeration ) MouseButtons , jehož hodnoty reprezentují jednotlivá tla čítka. Tyto hodnoty pak vývojá ř m ůže předat jako parametr jedné z metod MouseDown , MouseHold nebo MouseUp , které se chovají stejn ě jako jejich klávesové ekvivalenty. I pro myš jsme se rozhodli implementovat bezparametrovou metodu MouseDown , která reaguje na libovolné tla čítko, a uleh čit tak vývojá řů m práci. Každé oto čení kole čka myši nahoru, resp. dol ů zm ění hodnotu delta o +120, resp. -120. V případ ě, že uživatel vlastní myš, která umož ňuje plynulé otá čení kole čka, nemusí být hodnota rovna násobku čísla 120. Podle MSDN [http://msdn.microsoft.com/en- us/library/system.windows.forms.control.mousewheel.aspx] může aplikace reagovat na jiné hodnoty než na násobky 120 a tím zjemnit reakci, ale m ěla by vždy zachovat pom ěr v ůč i tomuto číslu. Metoda GetWheelScroll tuto hodnotu nezm ěněnou vrací a tím nechává na vývojá ři, jak s ní naloží. Pro rozpoznání dvojkliku se ukládá, jaké tla čítko bylo stisknuto poslední a kdy bylo stisknuto. Při dalším stisku stejného tla čítka se ode čte uložený časový údaj od aktuálního času. Zda je výsledek menší než DoubleClickTime , a tedy zda se jedná o dvojklik, může vývojá ř ov ěř it pomocí metody MouseDoubleClick . Hodnotu DoubleClickTime lze snadno m ěnit a tím p řizp ůsobit délku dvojkliku pot řebám hry. První tři položky vypsané v rozhraní jsou spíše pomocné a nejsou pro tuto komponentu st ěžejní, avšak poskytují vývojá ři další usnadn ění práce a zvýšení komfortu. MouseButtonsPressed je bitové pole reprezentující stisknutá tla čítka. Input kontroluje, zda je myš u okraje okna a do EdgeFlags ukládá, který okraj či roh to je. Ší řka okraje jde nastavit pomocí položky EdgeWidth .
34 Omezení pohybu myši ě č N kdy je vhodné omezit pohyb myši jen po ur itém Input prostoru, nej čast ěji je tento prostor okno aplikace, ale mouse fix může se jednat i o n ějaký herní prvek a donutit tak uživatele zam ěř it na n ěj svou pozornost. V p řípad ě void FixMouseBounds (); omezení do okna je ú čel jasný - hrá č tak v herním void FixMouseBounds (Rectangle b); void UnfixMouseBounds (); zápalu neopustí myší okno a nep řeruší tak hru. Toto void FixMouse (); omezení je vhodné aplikovat i v p řípad ě, že hra b ěží void FixMouse (int x, int y); přes celou obrazovku ( fullscreen ), nebo ť pokud je k void FixMouseAtCurrentPosition (); ř ů ů č void UnfixMouse (); PC p ipojeno více monitor m že hrá myší opustit Point GetMoveFromFix (); monitor, na kterém hru hraje. Metoda FixMouseBounds uzamkne myš v zadaném obdélníku, její bezparametrové p řetížení myš uzamkne v okn ě hry. Uvolnit tento zámek lze pomocí metody UnfixMouseBounds . Ve hrách jako First-Person Shooter (dále jen FPS) nebo leteckých simulátorech chceme, aby pohled kamery reagoval na pohyb myši. Avšak okno hry není nekone čné a časem bychom se dostali na jeho okraj a už bychom nemohli pokra čovat dále v pohybu. Řešení jsou dv ě, ale v praxi se používá jen jedno. První řešení p ři kontaktu myši s okrajem p řesune kurzor na opa čnou stranu obrazovky. Toto řešení se však skoro v ůbec nepoužívá. Druhé, které implementuje náš engine, zafixuje myš na ur čitý bod obrazovky (b ěžn ě st řed) a pro výpo čet velikosti pohybu kamery využívá odchylky od tohoto bodu, které vznikají pohybem myši. Zafixovat myš na ur čitý bod lze pomocí metody FixMouse , p řípadn ě FixMouseAtCurrentPosition . Bezparametrová verze metody FixMouse zafixuje pozici myši na st řed obrazovky. Odchylky od fixního bodu lze získávat voláním GetMoveFromFix .
6.2.4 GUIManager
Pro prvky jakéhokoli GUI je charakteristické, že GUIManager mají vždy velké množství parametr ů. N ěkteré parametry jsou d ůležit ější než ostatní a n ěkteré Control HoveredControl ; chceme často ponechat ve výchozím nastavení. Control MouseCaptured ; ř ů float ToolTipDelay ; Pokud bychom k vytvá ení prvk použili metody, string ToolTipText ; jejichž parametry by odpovídaly p řesn ě parametr ům bool UseShortcuts ; prvku, museli bychom vždy uvést i ty, které pro nás List
35 Pro každý typ GUI prvku jsme tedy vytvo řili ControlParams strukturu, která reprezentuje jeho parametry. P ři ř jejím vytvá ení jsou v konstruktoru nastaveny Vector2 Position ; všechny parametry na výchozí hodnoty. Vývojá ři Vector2 RotationOrigin ; pak jen sta čí zm ěnit ty, které se od t ěch výchozích float Rotation ; ř Vector2 Scale ; mají lišit. Po vytvo ení parametrové struktury, je pro Vector2 Size ; přidání prvku do scény nutné zavolat odpovídající float Depth ; metodu, která zkontroluje správnost hodnot ve int Id ; struktu ře a následn ě prvek vytvo ří. Tyto metody object Tag ; bool Enabled ; vždy za čínají slovem Add a pokra čují názvem bool ShowTooltip ; odpovídajícího prvku. Vracejí vytvo řený a Tooltip Tooltip ; inicializovaný prvek, který si m ůže vývojá ř uchovat ě ě ě ě MouseEventHandler MouseDownHandler ; a pozd ji jeho parametry m nit za b hu. Krom MouseEventHandler MouseMoveHandler ; obvyklých ( Position , Rotation , Scale , Size , MouseEventHandler MouseEnterHandler ; Enabled atd.) jsou zde i mén ě obvyklé, nap ř. Tag , MouseEventHandler MouseLeaveHandler ; ů MouseEventHandler MouseUpHandler ; který m že obsahovat jakýkoli objekt, který si MouseEventHandler MouseWheelHandler ; vývojá ř zvolí. Jeho využití je zcela v jeho rukou. Dalšími položkami jsou delegáti metod, které zpracovávají události spojené s akcemi uživatele. Nap říklad pokud uživatel klikne na prvek, je zavolána metoda, jejíž delegát je uložen v položce MouseDownHandler .
(6.1) 9 =
Stejn ě jako u SceneManageru jsou i zde prvky uloženy jako stromová struktura. D ůvody jsou velmi podobné jako u 3D objekt ů. Proto má každý prvek uložen svého rodi če a seznam svých potomk ů. Toto uspo řádání umož ňuje snadn ější tvo ření celk ů z jednotlivých souvisejících prvk ů GUI. GUIManager si musí neustále udržovat informaci o tom, který prvek je pod kurzorem myši. Řešení tohoto problému je pom ěrn ě triviální, ale lze aplikovat n ěkterá vylepšení, která by m ěla celý proces urychlit. P ři každém updatu je rekurzivn ě procházen celý strom, pozice a rozm ěry každého prvku jsou porovnány s pozicí myši. V případ ě, že prvek leží pod myší, je p řidán do seznamu. Takto je postupn ě vytvo řen seznam všech prvk ů pod kurzorem. Ten je následn ě vzestupn ě se řazen podle hloubky (od nejbližšího, po nejvzdálen ější) a první prvek je uložen do položky HoveredControl . V případ ě, že je seznam prázdný (pod myší není žádný prvek) je HoveredControl nastaven na nedefinovanou hodnotu ( null ). Po zjišt ění a nastavení HoveredControl je již snadné správn ě zpracovávat události uživatelských vstup ů. Všechny akce, které uživatel ud ělá, jsou vztaženy práv ě na aktivní prvek pod myší. Nap říklad pokud hrá č pohne myší, je zavolána metoda, která je reprezentována delegátem v HoveredControl.MouseMoveHandler . U delegát ů je vždy nutné ov ěřit, zda n ějakou metodu vůbec obsahují. Vývojá ř ji totiž nemusel definovat, čímž pravd ěpodobn ě zamýšlel, že danou akci nechce zpracovávat. P ři zm ěně prvku v HoveredControl jsou voláni delegáti MouseEnterHandler a MouseLeaveHandler – na nov ě aktivovaný prvek je zavolána první jmenovaná a na p ůvodní ta druhá.
36 Zasílání událostí se chová pon ěkud jinak, pokud je aktivní p řesm ěrování na jeden prvek (d ůvody pro toto chování jsou popsány v kapitole 6.1.4). Místo aby byly volány metody HoveredControlu , jsou volány metody prvku nastaveného v MouseCaptured . Ten lze nastavit pomocí metody CaptureMouse , která jako parametr p řijímá prvek, do kterého se má p řesm ěrovávat. Toto platí, dokud není p řesm ěrování zrušeno voláním metody ReleaseMouse .
Následuje krátký popis n ěkterých základních a n ěkterých zajímavých prvk ů GUI:
Label Základní prvek každého GUI. Obsahuje statický text, kterému je možné nastavit r ůzné barvy, font a zarovnání. Celý text nemusí mít stejnou barvu – pomocí zna čky
Button Tla čítko m ůže nabývat jednoho ze čty ř stav ů – normal , hovered , clicked a disabled . Pro každý tento stav m ůže vývojá ř ur čit tla čítku jinou podobu. Stav disabled lze zjistit p římo z položky Enabled , avšak ostatní stavy lze poznat jen porovnáním s odpovídajícími položkami v GUIManageru . Nap říklad tla čítko je ve stavu hovered jen tehdy, pokud je nastaven v položce GUIManager.HoveredControl . Jako jediný prvek GUI m ůže mít tla čítko p řiřazenou klávesovou zkratku ( shortcut ). Aby nebylo pot řeba p ři každém stisku klávesy procházet všechna tla čítka a zjiš ťovat, zda má n ěkteré tla čítko na klávesu reagovat, je už p ři p řiřazení klávesy zaregistrována do zkratek, které udržuje GUIManager . Zkratku lze kdykoli zrušit nebo se zruší sama, pokud je prvek odebrán ze scény.
NinePatch Jde o libovoln ě roztažitelný prvek, který je složen z 9 menších obrázk ů, kde každý reprezentuje jeden ze čty ř roh ů, čty ř hran nebo st ředu (viz obrázek 6.4). Rozm ěry roh ů nejsou m ěněny, hrany jsou roztaženy nebo opakovány jen podél jedné ose (vertikální nebo horizontální) a st řed je vždy roztažen případn ě opakován v obou t ěchto osách.
Obrázek 6.4: Zv ětšená ukázka rozd ělení obrázku na NinePatch
37 6.2.5 CutsceneManager
V první fázi bylo nutné definovat, v jakém formátu CutsceneManager budou jednotlivé cutscény uloženy. Kv ůli vestav ěné podpo ře v .NET jsme se rozhodli pro XML. Pomocí void LoadCutscene (string name); XmlTextReaderu je na čítání soubor ů velmi snadné a void PlayCutscene (string name); void StopCutscene (string name); ušet ří mnoho práce, která by vznikla p ři zavedení svého void ResetCutscene (string name); proprietárního formátu. P ři na čítání XML lze do jisté void UnloadCutscene (string name); omezené míry kontrolovat jeho správnost, avšak pro naprostou p řesnost bychom museli vytvo řit Document Type Definition (dále jen DTD), která by definovala uspo řádání všech entit a jejich atributy. Z časových d ůvod ů jsme zvolili kompromis a kontrolujeme XML jen na nep řítomnost d ůležitých zna ček. O toto na čítání se stará metoda LoadCutscene , Cutscene která jako sv ůj parametr p řijímá název XML souboru s cutscénou. Jak je soubor postupn ě na čítán, je vytvá řena void Load (XmlTextReader reader); stromová struktura t říd Sequence a Act , která popisuje void AddSequence (Sequence seq); cutscénu uloženou v souboru. Jako vstupní bod (ko řen) bool HasNextSequence (); Sequence GetNextSequence (); ř každé této struktury slouží t ída Cutscene (viz obrázek void Unload (); 6.3). Každá z t ěchto t říd má metodu Load , která na čítá void Reset (); data a vytvá ří z nich své t ělo. Takovéto rekurzivní využití objekt ů velmi zp řehlednilo zdrojový kód. Implementace veškerého na čítání do jedné metody, nap ř. CutsceneManager.LoadCutscene , by vedla ke zmatk ům a nep řehlednosti. Vždy po na čtení celého aktu, respektive sekvence se zavolá metoda AddAct , resp. AddSequence a tím se p řiřadí svému rodi či. Metoda PlayCutscene přijímá také jako Sequence parametr název XML souboru s cutscénou. Soubor však neotevírá a jen ov ěř í, zda již byl na čten metodou void Load (XmlTextReader reader); LoadCutscene . Tímto rozd ělením jsme umožnili void AddAct (Act act); bool HasNextAct (); vývojá ři odd ělit časov ě náro čnější na čítání souboru od Sequence GetNextAct (); spušt ění scény. Nevzniká tak žádná prodleva mezi void Unload (); zavoláním metody PlayCutscene a zahájením void Reset (); cutscény. Při spušt ění jsou cutscéna a její první sekvence Act nastaveny jako aktivní. Pokud se jedná o paralelní sekvenci, jsou všechny její akty ozna čeny jako aktivní. bool Finished ; č ř ě V opa ném p ípad (sekvence je lineární) je takto void Load (XmlTextReader reader); ozna čen jen první akt. void Unload (); V každém updatu cutscény jsou aktualizovány void Reset (); všechny aktivní akty. Ty p řestávají být aktivní až ve chvíli, kdy splnily sv ůj ú čel, což indikuje položka Finished – nap ř. p řesun kamery byl dokon čen, hrá č splnil zadaný úkol atd. Jakmile nezbude žádný aktivní akt ke zpracování, je pomocí metody HasNextAct ov ěř eno, zda má aktivní sekvence ješt ě n ějaké další akty, které nebyly vykonány. Pokud má, je následující získán voláním metody GetNextAct a je nastaven jako aktivní. Toto se opakuje, dokud má sekvence alespo ň jeden nezpracovaný akt. Poté je, stejn ě jako u akt ů, ov ěř eno, zda existuje ješt ě další sekvence, a pokud ano, je nastavena jako aktivní. Tentokrát však pomocí
38 metod HasNextSequence a GetNextSequence . Tento postup se opakuje, dokud v cutscén ě existuje n ějaká nezpracovaná sekvence. Cutscénu je možné p řerušit, znovuspustit nebo uvolnit z pam ěti metodami StopCutscene , ResetCutscene a UnloadCutscene . V posledních dvou p řípadech jsou rekurzivn ě volány odpovídající metody sekvencí a akt ů dané cutscény.
6.2.6 Camera
ě ů ě Ve scén m že být v jeden okamžik umíst n Camera libovolný po čet kamer, avšak jen jedna z nich může být aktivní. Složit ější p řípad více aktivních static Camera ActiveCamera ; kamer (nap ř. hlavní obrazovka zobrazuje pohled Vector3 Rotation ; Vector3 Position ; na silnici p řed závodním vozem a menší BoundingFrustum ViewFrustum ; obrazovka p ředstavuje zadní zrcátko) je nad Vector3 Forward ; rámec této diplomové práce. Implementovali CameraControls Controls ; jsme tedy položku ActiveCamera . Pro float MaxSpeed ; float MaxRotationSpeed ; usnadn ění p řístupu k aktivní kame ře odkudkoli z Vector3 Velocity ; enginu nebo hry jsme ji vytvo řili jako statickou. float RotationSpeed ; První vytvo řená kamera je automaticky bool MoveEnabled ; ř Matrix Projection ; nastavena jako aktivní. Pokud chce vývojá Matrix View ; aktivní kameru zm ěnit, sta čí, aby do položky ActiveCamera přiřadil jinou instanci a vše Ray GetRayFromScreen (Point screenPos); ostatní za n ěj ud ělá engine. Při vytvá ření kamery je automaticky vytvo řena projek ční matice, nebo ť ta se na rozdíl od pohledové matice nem ění v závislosti na pozici a rotaci kamery. K jejímu vytvo ření je nutné uvést úhel zorného pole ( field of view ), pom ěr stran ( aspect ratio ) a vzdálenost p řední a zadní o řezové plochy ( near/far clipping plane ). V našem enginu jsme se rozhodli neumožnit vývojáři tyto hodnoty měnit. Jsou použity hodnoty, které jsou b ěžné a které by m ěly být vyhovující pro v ětšinu typ ů her. Pokud však p řece jenom bude tuto zm ěnu vyžadovat, m ůže si tuto funkcionalitu velmi snadno doplnit. Aktuální projek ční a pohledovou matici m ůže vývojá ř získat dotazem na položky Projection a View . Vektor rovnob ěžný s pohledem kamery a pohledové t ěleso (viz obrázek 6.5) jsou po čítány v každém updatu, nebo ť jsou závislé na pozici a rotaci kamery. Vektor rovnob ěžný s pohledem kamery (forward vector ) lze vypo čítat následujícím vzorcem:
sin − . ∙ cos . (6.2) = sin . cos − . ∙ cos .
Jedna možnost, jak získat pohledové t ěleso, je vypo čítat pr ůse číky p řední a zadní o řezové plochy s paprsky, které procházejí rohy obrazovky a objektivem kamery. Poté pomocí t ěchto bod ů vyjád řit plochy, které t ěleso definují. Toto je však pom ěrn ě výpo četn ě náro čné a p ředevším zbyte čné, nebo ť XNA nám nabízí daleko jednodušší řešení. Obsahuje totiž t řídu BoundingFrustum , která ve svém jediném konstruktoru p řijímá jako parametr tzv. kombinovanou matici - sou čin pohledové a
39 projek ční matice (v tomto po řadí). Takto vzniklý objekt obsahuje položky reprezentující všech šest ploch, které pohledové t ěleso tvo ří ( Top , Bottom , Left , Right , Near , Far ). Také implementuje metody, které zjiš ťují, zda obsahuje nebo protíná n ěkterá další obalová t ělesa ( bounding volumes ). Vývojá ř m ůže pohledové t ěleso získat z položky ViewFrustum .
Obrázek 6.5: Pohledové t ěleso s ozna čenými hlavními plochami
Často je pot řeba vybrat pomocí myši n ějaký objekt p řed kamerou. Tomuto úkonu se anglicky říká picking . V trojrozm ěrném prostoru se v ětšinou provádí tak, že se vypo čítá paprsek (polop římka), který za číná v objektivu kamery a prochází bodem, na který hrá č klikl. Poté se zkontroluje, zda paprsek protíná n ěkterý objekt nebo jeho obalové t ěleso. Abychom však tento bod získali, musíme provést tzv. unprojection , což je p řevod obrazových sou řadnic ( screen space coordinates ) do sou řadnic v trojrozm ěrném prostoru ( world space coordinates ). Pak již jen sta čí od takto získaného bodu ode číst pozici kamery a výsledný vektor normalizovat. V našem enginu lze tento paprsek získat zavoláním metody GetRayFromScreen . Aby bylo možné ovládat pohyb kamery pomocí klávesnice, CameraControls implementovali jsme abstraktní t řídu CameraControls . Každé ř ř ř ř nové kame e je p i azena instance této t ídy inicializovaná public Keys Forward; výchozími klávesami. Pokud se vývojá ř rozhodne, že chce kameru public Keys Backward; ovládat jinými klávesami, m ůže vytvo řit vlastní instanci, public Keys Left; public Keys Right; inicializovat ji svými klávesami a p řiřadit ji kame ře jako položku Controls . Výhoda toto p řístupu je, že není pot řeba pro každou klávesu vytvá řet v kame ře položku. Pro základní kameru, kde jsou jen čty ři klávesy (vp řed, vzad, doleva a doprava) by to nebyl tak velký
40 problém, ale vývojá ř m ůže chtít vytvo řit kameru, která t ěchto kláves má daleko více. Takto mu sta čí vytvo řit potomka t řídy CameraControls a implementovat si vlastí inicializaci a položky odpovídající jednotlivým klávesám.
Free camera Pro testování a lad ění je výhodné, aby kamera nebyla omezena žádnými limity a vývojá ř se tak mohl podívat na kteroukoli část scény z kteréhokoli úhlu. Kamera má i novou dvojici tla čítek, která ovládá její pohyb nahoru a dol ů, což dále zvyšuje její stupe ň volnosti.
RTS camera ř Jako rozší ení standardní kamery jsme implementovali CameraRTS kameru, jejíž primární použití je v RTS hrách. Nejdůležit ější věcí, která p řibyla, je propojení s terénem, jelikož kamera Vector3 MinBounds ; pot řebuje p ři maximálním p řiblížení kopírovat terén a nesmí Vector3 MaxBounds ; ITerrain Terrain ; se dostat pod n ěj. Terén implementuje metodu Vector2 Position2D ; GetTerrainHeight , které sta čí p ředat pozici kamery nad terénem, a ona vrátí maximální výšku, do které se kamera void LookAt (Vector2 target); může p řiblížit. V RTS nás velmi často zajímá pozice n ějakého objektu (v tomto p řípad ě kamery), avšak nezajímá nás jak je vysoko. Pro tento p řípad je zde položka Position2D , která reprezentuje pozici kamery, ovšem bez t řetí složky – výšky. Jednotlivé herní úrovn ě v RTS hrách jsou často čtvercového nebo obdélníkového p ůdorysu. Za okraje toho prostoru by se kamera nem ěla nikdy dostat. Z toho d ůvodu jsme do tohoto typu kamery přidali omezení reprezentované dv ěma položkami MinBounds a MaxBounds , které ozna čují nejzazší body, kam se kamera m ůže dostat. Do ovládání kamery p řibylo tla čítko pro rotaci kamery a tla čítka, která ovládají p řibližování a oddalování terénu.
6.2.7 Cursor
Při vývoji jsme zkusili implementovat dv ě varianty této služby a porovnat jejich výhody a nevýhody. Varianta B se ukázala jako výrazn ě lepší řešení, a proto byla za řazena do našeho enginu.
Varianta A - kurzor jako sprite Varianta spo čívá ve vykreslování spritu (malý dvojrozm ěrný obrázek), který představuje kurzor, na pozici myši. XNA má velmi dobrou podporu sprit ů, a proto se tato varianta sama nabízí. Má však pom ěrn ě velké množství nevýhod, a tudíž jsme se rozhodli ji neimplementovat.
Výhody: • Transformace (rotace, zm ěna rozm ěrů…) jsou možné přímo za b ěhu programu.
Nevýhody: • Při nižším FPS je pohyb kurzoru trhaný nebo zpomalený, nebo ť nastavování jeho pozice probíhá ve stejném vlákn ě jako zbytek hry. Tento problém by samoz řejm ě šlo eliminovat přesunem na samostatné vlákno, avšak to by bylo zbytečně časov ě náro čné.
41 • Pot řeba definovat další t řídu pro reprezentaci r ůzných kurzor ů, která by uchovávala všechny parametry kurzoru - rozm ěry, animaci, aktivní bod (anglicky hotspot , což je bod na kurzoru, který je použit p ři kliku; tento bod m ůže být u každého kurzoru jiný, viz obrázek 6.6)
Obrázek 6.6: Ukázky r ůzných hotspot ů u r ůzných kurzor ů
Varianta B - systémový kurzor ř č Tato varianta využívá t ídu Cursor , která je sou ástí .NET SystemCursor a dokáže p římo manipulovat se systémovým kurzorem Windows. Její použití je velmi snadné a vytvo řit kurzor ze Cursor Cursor ; souboru je otázka jednoho řádku kódu. bool Visible ;
Má ovšem jednu zásadní nevýhodu a to, že Cursor LoadCursor (string file); konstruktor, který jako parametr p řijímá cestu ke kurzoru, void Hide (); nedokáže na číst soubory ve formátu ani (animovaný void Show (); kurzor) [39].Našt ěstí existuje alternativní řešení - pomocí PInvoke importovat WinAPI funkci LoadCursorFromFile , která jako sv ůj jediný parametr p řijímá cestu ke kurzoru a po na čtení vrací ukazatel do pam ěti. S tímto ukazatelem už si konstruktor t řídy Cursor poradí a bez problém ů na čte animovaný kurzor. Naše služba tuto funkcionalitu zapouzd řuje a nep řenáší toto nepohodlí na vývojá ře. Sta čí jen kurzory na číst pomocí metody LoadCursor a položku Cursor nastavit na jednu z vrácených hodnot. Metody Hide a Show slouží k jednoduchému nastavení vlastnosti Visible .
Výhody: • Poté, co jsme zjistili, jak obejít omezení p ři na čítání ani kurzor ů, byla implementace daleko jednodušší a rychlejší než u varianty A. • Pro pohyb kurzoru je využíváno zachytávání zpráv, které je p římo vestav ěné ve formulá řích systému Windows a které navíc b ěží na zvláštním vlákn ě. Tím se odstranil problém se zpožd ěním pohybu, jenž vzniká p ři nízkém FPS. • Existuje velké množství bezplatných, ale p řesto velmi mocných, aplikací pro tvorbu ani kurzor ů. Lze takto snadno odd ělit vývoj hry a vytvá ření grafického designu kurzor ů. • Není pot řeba implementovat žádné další t řídy. O animaci, rozm ěry, hotspot a další se stará přímo opera ční systém.
Nevýhody: • Nelze za b ěhu aplikace m ěnit rozm ěry a rotaci. To však lze částe čně nahradit vytvo řením více kurzor ů s r ůznou animací.
42 6.2.8 Audio
Pro jednoduché p řehrávání typu fire-and-forget , které se hodí jen do velmi jednoduchých her, obsahuje XNA t řídu SoundEffect . Vytvá ří se na čtením zvuku z obsahu hry. Poté již jen sta čí zavolat metodu Play , která se postará o p řehrání zvuku. Tímto však nad ním vývojá ř ztrácí veškerou kontrolu a nem ůže jej zastavit, posunout nebo zm ěnit hlasitost. Tato metoda tedy není vhodná pro v ětší projekty, kde vývojá ř pot řebuje mít absolutní kontrolu nad parametry zvuku v reálném čase. Našt ěstí XNA podporuje i komplexn ější práci se zvukem pomocí utility Cross-platform Audio Creation Tool (XACT). Tu Microsoft navrhl, aby odd ělila práci programátora od práce zvuka ře. XACT umož ňuje snadnou organizaci zvuk ů do tzv. wave bank , což je v podstat ě jeden soubor obsahující více zvuk ů (podporované formáty jsou wav, aiff a wma). Wave banky lze komprimovat metodou ADPCM na Windows a XMA na Xbox 360, jejich kompresní pom ěr je však pom ěrn ě nízký, jen 4:1. Další úrovní organizace jsou s ound banky , které odkazují na zvuky v jedné nebo více wave bancích . K těmto odkaz ům p řidávají další dopl ňující informace o zvuku, jako je nap říklad hlasitost nebo výška ( pitch ). Posledním stupn ěm d ělení jsou cues . Názvy t ěchto front jsou rozhraním mezi XACTem a hrou (jsou používány p římo ve zdrojovém kódu). M ůže obsahovat více zvuk ů ze sound banky a také je možné ur čit po řadí, v jakém se budou p řehrávat. Nap říklad cue s názvem „kaboom“ m ůže obsahovat čty ři mírn ě rozdílné zvuky výbuchu, jako po řadí p řehrávání zvolíme náhodu bez opakování stejného zvuku dvakrát po sob ě. Nyní každé spušt ění cue „kaboom“ p řehraje jeden náhodný zvuk ze seznamu. Tato náhoda dodá h ře na v ětší realisti čnosti, než kdyby byl jeden zvuk p řehráván stále dokola.
Obrázek 6.7: Ukázka aplikace XACT
XNA samoz řejm ě implementuje API pro práci se soubory vytvo řenými XACTem. Toto rozhraní má však pár omezení, která je možné p řekonat jen implementací vlastní obálky. Jedno z těchto omezení spo čívá v tom, že nejsme schopni vytvo řit cue tak, aby byla p řehrávána stále dokola ve smy čce. Nekone čné p řehrávání lze nastavit jen u konkrétního zvuku dané cue , což není p řesn ě to, co pot řebujeme. P ředstavme si kácení lesa, p řičemž vývojá ř chce, aby sekyra p ři dopadu ud ělala pokaždé trochu jiný zvuk. Zvuka ř tedy vytvo ří cue se zvuky sekyry. Vývojá ř však nemá možnost přehrávat tuto cue ve smy čce, dokud je les kácen.
43 Nezbývá než p ři každé aktualizaci Audio kontrolovat, zda již cue skon čila, a v případ ě, že ano, ji znovu spustit. Toto nepohodlí bylo SoundBank AddSoundBank (string name, důvodem, pro č jsme vytvo řili komponentu string filename); Audio , která se o tyto kontroly m ěla starat bez WaveBank AddWaveBank (string name, ř č ř string filename); p ílišné náro nosti pro vývojá e. Prvním SoundCue PlayCue (string soundBank, krokem je pomocí metod AddWaveBank a string cue, bool repeat); AddSoundBank přidat pot řebné banky. Aby SoundCue3D PlayCue3D (string soundBank, string cue, IPosition pos, bool repeat); nemusel vývojá ř p ři dalším odkazování na tyto banky neustále zadávat kompletní cestu void Pause (); k souboru, m ůže si bank pojmenovat n ějakým void Resume (); krátkým výstižným jménem. Pak již jen sta čí zavolat metodu PlayCue a p ředat ji, ve kterém sound banku se nachází cue , kterou chceme p řehrát, její jméno a zda se má p řehrávat ve smy čce. Varianta PlayCue3D navíc p řijímá pozici odkud má zvuk vycházet a vytvá ří tak prostorový zvuk.
6.2.9 Helpers
I když je XNA velmi mocný nástroj pro tvorbu po číta čových her, nachází se v něm pár nelogi čností a nedod ělk ů – jako v každém takto rozsáhlém projektu. Našt ěstí C# (a také Visual Basic) poskytuje možnost vytvo řit takzvané rozši řující metody ( extension methods ), což umož ňuje přidat metodu již existujícímu typu bez nutnosti vytvá řet zd ěděný typ, rekompilovat nebo jinak m ěnit p ůvodní typ. Z pohledu vývojá ře není ve volání obvyklých a rozši řujících metod žádný rozdíl [37]. Následuje pár p říklad ů t ěchto metod, které jsme v našem enginu implementovali, aby vývojá ři usnadnily práci.
Převod Vector2 na Vector3 a naopak Tento p řevod je pom ěrn ě často pot řeba (zvlášt ě u RTS) a v XNA neexistuje žádný snadný a elegantní zp ůsob, jak to provést. Proto jsme pro t říprvkový vektor vytvo řili metodu ToVector2 a pro dvouprvkový metodu ToVector3 .
Ukázka implementace první zmín ěné metody. Je zde uvedena, nebo ť je tento zp ůsob rozši řování málo známy, a p řitom je velmi jednoduchý a ú činný. Povšimn ěte si p ředevším klí čového slova this , které ur čuje, jaký typ budeme rozši řovat.
public static Vector2 ToVector2 (this Vector3 v) { return new Vector2(v.X, v.Z); }
Zdrojový kód 6.1: Implementace rozši řující metody ToVector2
44 Přidání bodu do BoundingBoxu Takováto základní operace asi vývojá řů m XNA unikla a nám nezbylo nic jiného, než že jsme si ji museli vytvo řit sami. Op ět následuje ukázková implementace (ze stejných d ůvod ů jako výše).
public static BoundingBox AddPoint (this BoundingBox bb, Vector3 v) { bb.Min = Vector3.Min(bb.Min, v); bb.Max = Vector3.Max(bb.Max, v);
return bb; }
Zdrojový kód 6.2: Implementace rozši řující metody AddPoint
45 7 Tvorba hry
Praktickým výsledkem této diplomové práce je RTS FireFighters: Whatever it takes , která byla přihlášena do sout ěže Imagine Cup , po řádanou spole čností Microsoft a to konkrétn ě do kategorie game design. V dob ě psaní této práce již FireFighters postoupili do semifinále mezinárodního kola a vyhráli první místo v národním kole. Tato kapitola popisuje návrh a implementaci hry, která je vytvo řena na enginu popsaném výše.
7.1 Návrh hry
Jak již bylo zmín ěno výše, byla tato hra zapsána do sout ěže Imagine Cup, jejíž motto a zárove ň zadání zní " Imagine a world where technology helps solve the toughest problems". Čili hra by m ěla ší řit pov ědomí o jednom z tzv. Millennium Development Goals (dále jen MDG) a snažit se u hrá če zvýšit zájem o řešení tohoto problému. Z t ěchto d ůvod ů jsme navrhli hru, k de hrá č koordinuje jednotky hasi čů a snaží se rychle a efektivn ě uhasit lesní požár a tím zachránit co možná nejv ětší plochu lesa a životy ohrožených lidí. Zam ěř uje se tedy na MDG číslo 7 - Ensure Environmental Sustainability . Logo tohoto MDG je na obrázku vpravo.
7.1.1 Reprezentace lesa
V první fázi bylo pot řeba navrhnout zp ůsob vytvá ření a uložení lesa. Cht ěli jsme, aby les spl ňoval tyto požadavky:
• Pot řebovali jsme, aby bylo možné vytvo řit jakýkoli les, p řesn ě n a požadované místo terénu. • Stromy musí bý t rozmíst ěny realisticky, čili nesmí být p říliš blízko sebe, natož aby se jejich modely p řekrývaly, a u okraj ů les a by m ěly být menší a mén ě husté. • Les musí být v dané misi při každém spušt ění stejný, takže nep řichází v úvahu náhodné generování až p ři spu št ění mise . Vše musí být vypo čítáno p ředem a n ějakým zp ůsobem uloženo.
7.1.2 Ší ření ohn ě
Vytvo řit ší ření ohn ě na základ ě skute čných fyzikálních model ů není kv ůli jejich náro čnosti dost dob ře možné. V p řípad ě, že by se nám to p řece jenom poda řilo, bylo by řešení všech souvisejících diferenciálních rovnic velmi výkonnostn ě a pam ěť ov ě náro čné. Toto si samoz řejm ě ve h ře nem ůžeme dovolit, a proto jsme navrhli jednodušší variantu , která je však stále velmi realistická . Není evidentn ě tak p řesná, jako fyzikální model, a le pro naši hru je více než dosta čující. Návrh po čítá s tím, že si každý strom uchovává informace o svém stavu - velikost, množství paliva, vlhkost a produkované teplo. Množství paliva a vlhkost lze také ozna čit jako zdraví a štít stromu - v analogii k b ěžným RTS hrám.
46 7.1.3 Herní obrazovky
Navrhli jsme také jaké obrazovky (ve smyslu popsaném v kapitole 6.1.2) budeme pot řebovat a jakému ú čelu budou sloužit:
• VideoScreen - Zobrazení loga týmu a hry p ři spušt ění hry. • MainMenuScreen - Hlavní menu hry i s nastavením, výb ěrem misí, titulky a dalšími podobrazovkami. • GameplayScreen - Nejd ůležit ější obrazovka celé hry. Zde je implementována podstatná část logiky samotné hry. Stará se slou čení jednotlivých komponent hry - jednotky, les, oheň, upgrady a další. • GameMenuScreen - Jedná se menu, které m ůže hrá č zobrazit b ěhem hraní. P ři zobrazení musí zapauzovat hru. • OverviewScreen - Před každou misí si zde hrá č nakupuje vybavení pro své hasi če. V druhé části této obrazovky si tyto hasi če také rekrutuje. • MissionEndScreen - Obrazovka, která se objeví na konci každé mise. Informuje hrá če o úsp ěchu, či neúsp ěchu mise
7.1.4 Jednotky
Jako v každé RTS, i v té naší je velmi d ůležité mít k dispozici pestrou škálu jednotek. Museli jsme navrhnout, jak tyto jednotky reprezentovat, jak uložit jejich vlastnosti a jak s nimi vykonávat r ůzné akce. Následující obrázek ukazuje navrženou stromovou strukturu jednotek:
UNIT
VEHICLE FIREFIGHTER
FIRETRUCK GF
HUMMER MEDIC
DOZER ENGINEER
CHIEF
Obrázek 7.1: Stromová struktura jednotek
47 Tato hierarchie je výhodná, nebo ť každá jednotka musí obsahovat informace o svém zdraví, rychlosti, odolnosti v ůči ohni a mít uložen sv ůj model. Vozidla, na rozdíl od hasi čů , mají informaci o volném po čtu míst, zda jsou zdroji vody a jestli je řídí autopilot. Hasi či mají také specifické vlastnosti, nap ř. polom ěr hašení, síla hašení, nebo zda je v dosahu Chiefova povzbuzování. Avšak navíc má každá jednotka další speciální vlastnosti podle svého typu. Nap říklad Firetruck musí mít informaci o tom, kolik mu v nádrži ješt ě zbývá vody nebo Medic jak rychle a ú činn ě dokáže lé čit.
Hasi či (firefighters)
General Firefighter Nejodoln ější a umí nejlépe hasit, ale je pomalý. Jako jediná p ěší jednotka umí provád ět výsek.
Medic Nejrychlejší p ěší jednotka a umí lé čit ostatní hasi če. Jako jediný dokáže evakuovat civilisty.
Engineer Může opravovat poškozená vozidla a zvyšuje rychlost vozidel, která řídí.
Chief Zvyšuje schopnosti ostatních hasi čů v jeho okolí. Jednou za čas dokáže p řivolat letadlo s retardanty.
Vozidla (vehicles)
Firetruck Nejd ůležit ější vozidlo, nebo ť obsahuje hlavní zásoby vody pro ostatní hasi če.
Hummer Malý ale rychlý, vhodný pro p řevážení p ěších jednotek. Po upgradu m ůže mít vlastní zásobu vody a po krátkou dobu pomáhat s hašením.
Dozer Velmi pomalá a velmi odolná jednotka sloužící pro rozsáhlý výsek lesní plochy v oblastech blízko požáru.
Zvláštním typem jednotek jsou civilisti. Ti nejsou p římo hrá čem ovladatelní, ale je pot řeba je evakuovat pomocí medika. Po čet p řeživších civilist ů je jedním z kriterií úsp ěšného ukon čení mise.
48 7.1.5 Databáze znalostí
Cht ěli jsme do hry implementovat databázi znalostí o lesních požárech obecn ě a o r ůzných zp ůsobech boje s nimi. Také m ěla obsahovat popis jednotek, misí a herních strategií - tedy herní manuál Proto jsme museli navrhnout zp ůsob reprezentace jednotlivých článk ů a jejich za řazení do kategorií. Op ět jsme se rozhodli pro použití XML, nebo ť .NET nabízí velmi propracovanou podporu pro tento formát. Rozhodli jsme se rozd ělit definici struktury encyklopedie od obsahu jednotlivých článk ů. Proto vznikly dva souborové formáty - cyc a tex .
Souborový formát cyc Tento typ reprezentuje celou encyklopedii a její strukturu. Na následující ukázce je encyklopedie, která obsahuje dv ě kategorie Causes a Prevention . První je dále rozd ělena na dv ě podkategorie Nature a Human . Podkategorie Nature obsahuje dva odkazy typu text (tedy články), každý odkaz musí mít nadpis, v tomto p řípad ě Lightning a Fuel . Druhá podkategorie však neobsahuje článek, ale přímý odkaz na obrázek.
Zdrojový kód 7.1: Ukázka souborového formátu cyc
Souborový formát tex Pot řebovali jsme navrhnout souborový formát, který by byl schopný d ělit článek na odstavce s nepovinným nadpisem a zárove ň ke každému odstavci p řiřadit libovolné množství obrázk ů. Obrázky by m ěly být textem obtékány, ale vývojá ř musí mít možnost ur čit alespo ň základní zarovnání (doleva, doprava).
Suspendisse purus tellus, scelerisque eu interdum nec, pellentesque vel justo
Zdrojový kód 7.2: Ukázka souborového formátu tex
49 7.2 Implementace hry
V této kapitole se zam ěř íme p ředevším na části, které jsou specifické pro naši hru - reprezentace lesa, ší ření ohn ě. Nebudeme vysv ětlovat, jak vytvo řit GUI, jak naprogramovat pathfinding pomocí algoritmu A* apod. Řešení t ěchto problém ů již zkušený čtená ř ur čit ě zná a pro mén ě zkušeného by k vysv ětlení nesta čil rozsah této práce.
7.2.1 Reprezentace lesa
Abychom splnili všechny požadavky, které jsme si definovali v kapitole 7.1.1, museli jsme p řijít s jednoduchým zp ůsobem, jak ozna čit zalesn ěnou část mapy. Důležité také bylo n ějak ur čit, jak moc je daná část zalesn ěna a jak velké stromy v této oblasti rostou. Nejjednodušší se nakonec ukázalo vytvo řit obrázek o stejné velikosti, jako výšková mapa, kde hodnota jednoho jeho kanálu (v našem případ ě zeleného) ur čovala velikost strom ů v daném míst ě (viz obrázek 7.2). Takto lze snadno ur čit, kde mají být stromy menší a kde naopak v ětší. Lehce tak splníme požadavek na to, aby p ři okrajích lesa byly menší stromy. Bylo pot řeba také ur čit, kde ohe ň zapo čne. Tuto informaci jsme p řidali do jiného kanálu obrázku (my se rozhodli pro červený). Hodnota ur čuje, jaký je po čáte ční žár na tomto míst ě. Zelený a červený kanál a jejich kombinaci ukazuje následující obrázek.
Obrázek 7.2: Zelený kanál ur čuje velikost strom ů, červený po čáte ční žár, kombinace je vstupem pro ForestCreator
Takto už bychom byli schopni p řed každou misí vytvo řit les na správném míst ě a se správnou velikostí strom ů. Avšak tento les by pokaždé vypadal jinak. To by šlo samoz řejm ě vy řešit tak, že by měla každá mise uloženo semínko ( seed ) a generátor náhodných čísel by jím byl vždy inicializován. To by však bylo pom ěrn ě časov ě náro čné a hrá č by tak musel na každé na čtení hry dlouho čekat, zvlášt ě na pomalejších strojích. Vytvo řili jsme proto program ForestCreator , který vše pot řebné p ředpo čítá a uloží v binární podob ě do souboru (viz obrázek 7.3). Generování strom ů probíhá následovn ě:
1) Vygeneruj náhodn ě bod v prostoru obrázku. 2) Zkontroluj, zda není bod p říliš blízko n ěkterému stromu, pokud ano, jdi zp ět na bod 1), jinak pokra čuj.
50 3) Zjisti hodnotu v kanálu s velikostí stromu. Pokud je tato hodnota nižší než práh, pokra čuj na bod 1), jinak vytvo ř podle této hodnoty odpovídající strom. P řidej jej do seznamu vygenerovaných strom ů. 4) Zjisti hodnotu v kanálu s po čáte čním žárem. Tuto hodnotu nastav stromu. 5) Pokra čuj na bod 1) dokud není vygenerován požadovaný po čet strom ů a nebo již došlo k velkému množství marných pokus ů.
Rozpracovaný projekt lze uložit a vrátit se k n ěmu pozd ěji, vývojá ř si tak nemusí zapisovat parametry p ři dola ďování finální podoby lesa.
Obrázek 7.3: Rozhraní programu ForestCreator s vygenerovaným lesem
Soubor vytvo řený ForestCreatorem je pak p ři na čítání mise otev řen a uloženými daty jsou napln ěny t řídy reprezentující jednotlivé stromy. Každá mise má seznam model ů strom ů a každý strom má normalizovaný rozsah velikosti, p ři kterém je použit. Nap říklad model bush má rozsah od 0,0 po 0,6 a model tree od 0,5 po 1,0. To znamená, že pro všechna místa, kde je velikost v rozsahu 0,0 až 0,5 budou jen modely bush , v rozsahu 0,6 až 1,0 jen tree a v p řekryvu 0,5 až 0,6 bude bu ď bush , nebo tree . Tímto lze zajistit odpovídající velikost pro správné modely. P řekryvem je pak vytvo řen plynulý přechod mezi t ěmito modely.
51 7.2.2 Ší ření ohn ě
Pro naši hru bylo velmi d ůležité, abychom vytvo řili Tree realistické a uv ěř itelné ší ření ohn ě, které by však zárove ň bylo výpo četn ě nenáro čné. Jak již bylo short X, Y; vysv ětleno v kapitole 7.1.2, použití skute čných float BaseHealth ; float Health ; fyzikálních model ů není možné. Proto má každý float InitShield ; strom uloženo své palivo, vlhkost, produkovaný žár float Shield ; a žár, který je pod stromem. Pokud strom ho ří, tak float Size ; produkuje žár, který je p římo úm ěrný množství float Heat ; ě ř float HeatUnderTree ; paliva, které stromu ješt zbývá. Tento žár p edává List
Obrázek 7.4: Míra ovlivn ění stromu (zelený) stromy v okolí (žluté)
52
Obrázek 7.5: Ší ření ohn ě - ran ější fáze
Obrázek 7.6: Ší ření ohn ě - pozd ější fáze
53 7.2.3 Jednotky a jejich akce
ř Každá jednotka je reprezentována vlastní t ídou, Unit která obsahuje vlastnosti specifické jen pro ni. Vlastnosti, které jsou stejné pro stejnou skupinu float BaseHealth ; jednotek (vozidla nebo hasi či) jsou implementovány float Health ; ř float Speed ; v obecných t ídách Vehicle a Firefighter . Tyto float CurrentMoveSpeed ; dv ě t řídy jsou ješt ě zd ěděny ze t řídy Unit , ve které float RotationSpeed ; jsou nejobecn ější vlastnosti, jež jsou spole čné pro bool IsDead ; float FireResistance ; všechny jednotky. Task CurrentTask ; Pokud hrá č ozna čí jednotku, zp řístupní tak Queue
Obrázek 7.7: Screenshot ze hry Firefighters ukazující všechny typy jednotek
54 8 Záv ěr
Cílem této diplomové práce bylo čtená ře seznámit s nedávno vzniklým fenoménem nezávislého vývoje po číta čových her, který dnes zažívá rapidní rozvoj. Stru čně čtená ři popsala historii po číta čových her jako celku, vysv ětlila základní historické pojmy jako zlatý v ěk videoher a krach herního pr ůmyslu roku 1983. Vysv ětlila samotný pojem indie game , co vedlo k jeho vzniku a jakými zp ůsoby se tyto hry nej čast ěji distribuují. V p řehledné tabulce stru čně popsala některé rozdíly mezi vývojem nezávislého a komer čního herního projektu. V následujících kapitolách popsala návrh a implementaci jednoduchého herního enginu založeného na platform ě XNA Game Studio 4.0 . Vysv ětlila jak navrhnout a implementovat graf scény, grafické uživatelské rozhraní, získávání uživatelských vstup ů, r ůzné druhy kamer, in-game anima ční sekvence a v neposlední řad ě, jak vytvo řit komponentu spolupracující s Cross-platform Audio Creation Tool . Nakonec se zam ěř ila na d ůležité sou části námi vyvíjené hry FireFighters: Whatever it takes - reprezentace lesa, ší ření ohn ě, herní obrazovky, systém jednotek a jejich akce. Tato hra v dob ě odevzdávání práce vyhrála národní kolo a postoupila do sv ětového kola sout ěže Imagine Cup , z čehož je z řejmé, že i malý tým dokáže v krátkém čase vytvo řit konkurence schopný produkt, pokud je pro jeho tvorbu opravdu zapálen.
55 Literatura
[1] Bellis, Mary: Computer and Video Game History [online]. [cit. 2010-12-27]. Dostupné na URL: http://inventors.about.com/library/inventors/blcomputer_videogames.htm [2] Donovan, Tristan: Replay: History of video games . Yellow Ant, Lewes, 2010, 138 stran. ISBN 978-0-9565072-2-8. [3] Kent, Steven L.: The Ultimate History of Video Games: From Pong to Pokémon . Three Rivers Press, 2001. ISBN 0761536434. [4] Stahl, Ted: Timeline of Video Games [online]. Aktualizováno 2010-03-17 [cit. 2011-01-09]. Dostupné na URL: http://www.thocp.net/software/games/games.htm [5] Kolektiv autor ů: Pong-story [online]. Aktualizováno 2011-01-04 [cit. 2011-01-05]. Dostupné na URL: http://www.pong-story.com/intro.htm [6] Šulc, Tomáš: Rating závadnosti po číta čových her - jeho vývoj a dnešní praxe [online]. Aktualizováno 2007-07-19 [cit. 2011-01-05]. Dostupné na URL: http://pctuning.tyden.cz/multimedia/hry-a-zabava/9102- rating_zavadnosti_pocitacovych_her-jeho_vyvoj_a_dnesni_praxe [7] McMillen, Edmund: Indie Game Development: 16 Do's and Don'ts [online]. Aktualizováno 2010-04-22 [cit. 2011-01-05]. Dostupné na URL: http://www.gamepro.com/article/features/214865/indie-game-development-16-dos-and- donts/ [8] Hall, Steve: What Are Indie Games? [online]. Aktualizováno 2008-10-31 [cit. 2010-11-15]. Dostupné na URL: http://www.indiegamereviewer.com/what-are- indie-games/ [9] Kolektiv autor ů: History of Independent Games [online]. Aktualizováno 2009-11-16 [cit. 2010-11-15]. Dostupné na URL: http://tig.wikia.com/wiki/History_of_Independent_Games [10] Kolektiv autor ů: Game Maker [online]. Aktualizováno 2009-11-16 [cit. 2010-11-15]. Dostupné na URL: http://tig.wikia.com/wiki/Game_Maker [11] Kolektiv autor ů: Uplink game features [online]. [cit. 2010-11-15]. Dostupné na URL: http://www.introversion.co.uk/uplink/ [12] Kolektiv autor ů: Introversion Software Limited [online]. [cit. 2010-11-15]. Dostupné na URL: http://www.giantbomb.com/introversion-software-limited/65-543/ [13] Franta, Dalibor: Recenze Tron Evolution - Perský princ v latexu . Level, 2010, 199, s. 14- 17. [14] Cai, Yuanzhe : Games-on-Demand: the Reality and Future [online]. 2004, 11 stran. Dostupné na URL: http://www.parksassociates.com/free_data/dofwnloads/parks-games_on_demand.pdf [15] Gril, Juan: The State of Indie Gaming [online]. Aktualizováno 2008-04-30 [cit. 2011-01- 05]. Dostupné na URL: http://www.gamasutra.com/view/feature/3640/the_state_of_indie_gaming.php [16] Langley, Ryan: In-Depth: Xbox Live Indie Games Sales For 2009, Plus Some Perspective [online]. Aktualizováno 2010-01-25 [cit. 2011-01-05]. Dostupné na URL: http://www.gamerbytes.com/2010/01/indepth_xbox_live_indie_games.php [17] Kolektiv autor ů: To become an Authorized Developer for Wii, WiiWare and/or Nintendo DS/DSi [online]. Aktualizováno 2011-01-09 [cit. 2011-01-05]. Dostupné na URL: http://www.warioworld.com/apply/
56 [18] Kohler, Chris: Nintendo Taps U.S. Talent in Search of WiiWare Hits [online]. Aktualizováno 2008-05-10 [cit. 2011-01-05]. Dostupné na URL: http://www.wired.com/gamelife/2008/05/for-wiiware-nin/ [19] List of Game Development Tools & Game Engines. Dostupné na URL: http://indiegametools.com/ [cit. 2011-01-06] [20] Geršl, Vladimír: Game Design: Pro po číta čové a mobilní hry [online]. Aktualizováno 2010-06-05 [cit. 2011-01-08]. Dostupné na URL: http://herakles.zcu.cz/education/ph/slide/PH-10-Gamedesign.ppt [21] Michael , David: The Indie Game Development Survival Guide . Charles River Media, 2003. ISBN: 1-58450-214-2 [22] Juuso: What Are AAA Titles? [online]. Aktualizováno 2006-05-26 [cit. 2011-01-06]. Dostupné na URL: http://www.gameproducer.net/2006/05/26/what-are-aaa-titles/ [23] Kršek, P., Špan ěl, M.: Základy po číta čové grafiky: OpenGL [online]. Aktualizováno 2008 [cit. 2010-12-20]. P řístupné student ům FIT VUT v Brn ě. [24] Mungler, Steven: Just what is DirectX? [online]. Aktualizováno 2004-09-21 [cit. 2011-01-05]. Dostupné na URL: http://www.d-silence.com/feature.php?id=254 [25] Herout, Adam: Srovnání OpenGL a Direct3D [online]. Aktualizováno 2006 [cit. 2010-12-26]. P řístupné student ům FIT VUT v Brn ě. [26] Kajan, Rudolf: DirectX, Direct3D [online]. Aktualizováno 2010 [cit. 2010-12-26]. Přístupné student ům FIT VUT v Brn ě. [27] Herout, Adam: Historie a Standardizace OpenGL a dalších… [online]. Aktualizováno 2007 [cit. 2010-12-26]. P řístupné student ům FIT VUT v Brn ě. [28] Wright, Richard: OpenGL SuperBible . Sams, 2004, 1173 stran. ISBN: 978-0672326011. [29] Domovská webová stránka Torque Game Enginu. Dostupné na URL: http://www.torquepowered.com [30] Preisz, Eric: November Update [online]. Aktualizováno 2010-11-11 [cit. 2011-01-05]. Dostupné na URL: http://www.torquepowered.com/community/blogs/view/20495 [31] Kolektiv autor ů: Unreal Development Kit [online]. Aktualizováno 2010-11-27 [cit. 2011-01-05]. Dostupné na URL: http://developer.nvidia.com/object/udk.html [32] Domovská webová stránka Unreal Technology. Dostupné na URL: http://www.unrealtechnology.com [33] Sweeney, Tim: Unreal Engine 4.0 aims at next-gen console war [online]. Aktualizováno 2008-03-12 [cit. 2011-01-05]. Dostupné na URL: http://www.tgdaily.com/business-and-law-features/36436-tim-sweeney-part-3-unreal- engine-40-aims-at-next-gen-console-war [34] Kolektiv autor ů: XNA Game Studio 4.0 [online]. Dostupné na URL: http://msdn.microsoft.com/en-us/library/bb200104.aspx [35] Ewald, M.: Game Components and Game Services [online]. Aktualizováno 2006-11-01 [cit. 2011-01-04]. Dostupné na URL: http://www.nuclex.org/articles/4-architecture/6-game-components-and-game-services [36] Walsh, Aaron E.: Understanding Scene Graphs [online]. Aktualizováno 2002-07-01 [cit. 2011-05-19]. Dostupné na URL: http://drdobbs.com/java/184405094 [37] Kolektiv autor ů: Extension Methods (C# Programming Guide) [online]. Aktualizováno: 2010-10-01. Dostupné na URL: http://msdn.microsoft.com/en-us/library/bb383977.aspx
57 [38] Kolektiv autor ů: Game State Management [online]. Aktualizováno 2007-04-26 [cit. 2011-04-12]. Dostupné na URL: http://create.msdn.com/en- US/education/catalog/sample/game_state_management [39] Kolektiv autor ů: Cursor Constructor [online]. Aktualizováno 2008-01-06 [cit. 2011-04-11]. Dostupné na URL: http://msdn.microsoft.com/en- us/library/kkw8k45d.aspx
58