Analýza vývoje interaktivních

Mendelova univerzita v Brně Provozně ekonomická fakulta

Analýza vývoje interaktivních výukových aplikací Diplomová práce

Vedoucí práce: Ing. Jan Přichystal, Ph.D.

Bc. Martin Procházka

Brno 2011

Mé poděkování patří vedoucímu práce Ing. Janu Přichystalovi, Ph.D. ze cenné rady a připomínky.

Prohlašuji že jsem tuto práci vypracoval samostatně s použitím literatury uvedené v referencích.

V Brně dne 4. ledna 2011

....................................................

Abstract Procházka, M. Analysis of development of educational interactive applications. Master thesis. Brno, 2011. The master thesis deals with analysing the process of conception, design, and implementation of interactive application focused on teaching economy and human resource management. The thesis provides an overview of the current state of applying new media into education, with emphasis on interactive media and games. The analysis of these resources determines the starting point and identifies the requirements for proposing a solution proposed in the thesis. This solution is conceived of as a game system, wherein a user manages a family farm and organizes virtual characters’s work. The thesis includes implementation and evaluation of the application created. The conclusion deals with comparing advantages of the application with alternative ones, which can be used by teachers in teaching financial literacy.

Abstrakt Procházka, M. Analýza vývoje interaktivních výukových aplikací. Diplomová práce. Brno, 2011. Diplomová práce se zabývá analýzou procesu koncepce, návrhu a implementace interaktivní aplikace zaměřené na výuku hospodaření a řízení lidských zdrojů. V práci je uveden přehled současného stavu aplikace nových médií ve výuce s důrazem na interaktivní média a hry. Analýzou těchto zdrojů je určeno východisko a identifikovány požadavky pro návrh vlastního řešení. To je koncipováno jako herní systém, kde uživatel hospodaří na rodinné farmě a organizuje práci virtuálním postavám. Součástí práce je implementace a zhodnocení vytvořené aplikace. V závěru práce jsou srovnávány přednosti aplikace s alternativami, které učitelé mohou použít při výuce finanční gramotnosti.

4

Obsah 1 Úvod 1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Nová média 2.1 Nová média ve výuce . . . . . . . 2.1.1 E-learning . . . . . . . . . 2.1.2 Konstruktionistické učení . 2.1.3 Memorovací algoritmy . . 2.1.4 Počítačové hry . . . . . . 2.1.5 Sociální sítě . . . . . . . . 2.2 Počítačové hry . . . . . . . . . . 2.2.1 Edutainment . . . . . . . 2.2.2 Serious games . . . . . . . 2.2.3 Výukové hry pro školy . . 2.3 Vývoj počítačových her . . . . . . 2.3.1 Game design . . . . . . . 2.3.2 Přístup k návrhu systému 2.3.3 Platformy . . . . . . . . . 2.3.4 Vývojové nástroje . . . . . 2.3.5 Metodiky řízení vývoje . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

8 8 9 10 10 10 11 11 11 12 13 14 14 14 15 15 16 16 17 17

3 Analýza nového projektu 19 3.1 Finanční gramotnost . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Přehled literatury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4 Metodika 4.1 Specifikace požadavků . . . 4.2 Koncepce hry . . . . . . . . 4.3 Game design . . . . . . . . . 4.4 Evaluace technologií . . . . 4.5 Návrh architektury systému 4.6 Produkční plán . . . . . . . 4.7 Produkce . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

21 21 21 21 21 21 22 22

5 Návrh vlastního řešení 5.1 Specifikace požadavků . . . . . . 5.2 Koncepce . . . . . . . . . . . . . 5.2.1 Volba herních mechanismů 5.2.2 Technické zpracování . . . 5.3 Evaluace framework řešení . . . . 5.3.1 Unity . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

23 23 23 23 24 24 24

. . . . . . .

. . . . . . .

5

5.4

5.5

5.6

5.3.2 Torque3D . . . . . . . . . . . . 5.3.3 UnrealEngine Development Kit 5.3.4 Vyhodnocení . . . . . . . . . . Evaluace komponent herního engine . . 5.4.1 3D engine . . . . . . . . . . . . 5.4.2 3D zvuk . . . . . . . . . . . . . 5.4.3 Vlastní formáty . . . . . . . . . 5.4.4 Perzistence herního stavu . . . 5.4.5 Lokalizace . . . . . . . . . . . . 5.4.6 Skriptovací jazyk pro integraci . Produkce audiovizuálního obsahu . . . 5.5.1 3D modely . . . . . . . . . . . . 5.5.2 Audio . . . . . . . . . . . . . . Game design . . . . . . . . . . . . . . . 5.6.1 Svět . . . . . . . . . . . . . . . 5.6.2 Práce . . . . . . . . . . . . . . . 5.6.3 Postavy . . . . . . . . . . . . . 5.6.4 Výnosy z úrody . . . . . . . . . 5.6.5 Finance . . . . . . . . . . . . . 5.6.6 Scénáře . . . . . . . . . . . . . 5.6.7 Čas . . . . . . . . . . . . . . . . 5.6.8 Odemykání obsahu . . . . . . . 5.6.9 Ovládání . . . . . . . . . . . . .

6 Implementace 6.1 Cíle objektového návrhu . . . 6.2 Podpora data driven přístupu 6.3 Datový model . . . . . . . . . 6.3.1 Content . . . . . . . . 6.3.2 Ranks . . . . . . . . . 6.3.3 Scenario . . . . . . . . 6.4 Objektový návrh . . . . . . . 6.4.1 Systémová část . . . . 6.4.2 Herní objekty . . . . . 6.4.3 Herní mechanismy . . 6.4.4 Uživatelské rozhraní . 6.5 Produkce herního obsahu . . . 6.5.1 Audiovizuální data . . 6.5.2 Pravidla . . . . . . . . 6.5.3 Datový obsah . . . . . 6.5.4 Scénáře . . . . . . . . 6.6 Organizace projektu . . . . . 6.6.1 Verzovací systém . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

25 25 25 25 26 26 26 27 27 27 28 28 28 28 28 29 29 30 31 31 32 32 32

. . . . . . . . . . . . . . . . . .

33 33 33 34 34 34 34 34 34 36 38 40 42 42 43 43 44 44 45 6

6.7

6.6.2 Správa požadavků . . . . . . 6.6.3 Sdílení dokumentů . . . . . Automatizace procesů . . . . . . . 6.7.1 Automatický build projektu 6.7.2 Automatické testování . . .

. . . . .

. . . . .

. . . . .

7 Zhodnocení 7.1 Naplnění požadavků . . . . . . . . . . . 7.1.1 Game design . . . . . . . . . . . 7.1.2 Architektura software . . . . . . . 7.1.3 Minimální hardware konfigurace . 7.2 Zhodnocení přínosu použitých technologií 7.2.1 OGRE3D . . . . . . . . . . . . . 7.2.2 SQLite . . . . . . . . . . . . . . . 7.2.3 irrKlang . . . . . . . . . . . . . . 7.3 Produkce obsahu . . . . . . . . . . . . . 8 Diskuze 8.1 Srovnání s alternativami 8.1.1 Moje Familie . . 8.1.2 The Sims . . . . 8.1.3 SimCity . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

. . . . . . . . .

. . . .

. . . . .

45 45 46 46 46

. . . . . . . . .

47 47 47 47 48 48 48 49 49 50

. . . .

51 51 51 52 52

9 Závěr

53

10 Reference

54

Přílohy

56

A Herní mechanismy

57

B Obrazové přílohy

61

C Seznam elektronických příloh

63

7

1

Úvod

V této práci analyzujeme proces vývoje interaktivní aplikace určené pro podporu výuky hospodaření a řízení lidských zdrojů. Teoretickým východiskem jsou pro nás studie zabývající se aplikací nových médií ve výuce, jejichž přehled poskytujeme v kapitole 2. Analýzu našeho řešení, které vychází z posledních poznatků oboru předkládáme v kapitole 3. Metodika použitá při procesu koncepce, návrhu a implementace našeho řešení je popsána v kapitole 4. Na základě návrhu, představeného v kapitole 5, aplikaci implementujeme a přiblížíme důležité aspekty technického řešení v kapitole 6. Řešení zhodnotíme vzhledem k objektivně stanoveným požadavkům v kapitole 7. Práci uzávíráme diskuzí (kapitola 8), kde předkládáme přínos našeho řešení v kontextu nových médií a srovnáváme s dostupnými alternativami. V kapitole 9 shrnujeme výsledky práce.

1.1

Úvod do problematiky

Za nová média se označují aplikace digitálních technologií, hypertext, komunikace zprostředkovaná sítí, digitalizované fotografie, video, atp. Jedná se o široký termín, který se snaží jednoduše vymezit nová média od starých (knihtisk, televize, atp.). Společným jmenovatelem nových médií je interaktivita a možnost modifikace mediálních objektů. Stará média jsou zase považována za lineární, statická a jsou konzumována pasivně. Nová média jsou nedílnou součástí života mladých lidí narozených v novém tisíciletí (tzv. Net generation) už od malička. Využití těchto médií nejen usnadňuje práci pedagogům, přibližuje zdroje, ale dodává i motivaci pro vzdělání. Výzkumy a experimenty, na které se budeme v práci odkazovat, poukazují na bohaté možnosti přínosu nových médií do procesu vzdělávání. V určitém smyslu představují decentralizaci procesu vzdělávání ze školní budovy do sítě a od učitele mezi studující vzájemně. Dosud nerozšířenější aplikací nových médií je E-learning, který je v ČR prakticky standardem pro vysoké školy. Není ale vzácné, že i základní školy mají Elearningové materiály a učitelé jsou aktivní v nasazení nových médií ve výuce. V této práci přinášíme širší přehled nových médií se zvláštním důrazem na interaktivní média a počítačové hry. Právě hry mají vlastnosti, které jsou vhodné pro výuku předmětů nebo témat, kde jsou tradiční metody výuky neefektivní. Pro účelové zaměření projektu byla zvolena finanční gramotnost, která je součástí Rámcových vzdělávacích programů (RVP) pro základní a střední školy. Předmět je reakcí na akcelerující úroveň zadlužování domácností a obecně nízkou úroveň ekonomických znalostí obyvatelstva ČR. Požadovaným stavem by měl být občan, který je rovnocenným účastníkem na trhu finančních produktů, zodpovědně jednající v otázkách rozpočtu domácnosti, spoření, atd.

8

1.2

Cíl práce

Cílem práce je navrhnout a implementovat interaktivní aplikaci zaměřenou na výuku hospodaření a řízení lidských zdrojů. Výsledná aplikace by měla být využitelná jako aktivita pro podporu výuky finanční gramotnosti na základních školách a měla by předčit alternativní řešení.

9

2

Nová média

Nová média jsou projevem informačních technologií, které již vstoupily do školství na všech úrovních a informatika je vyučována od základních škol. Dosavadní pojetí předmětu informatika na základních a středních školách vychází z představy počítače jako pracovního nástroje a učí uživatelským dovednostem ( práci s kancelářskými aplikacemi, Internetem, atp.). Předchozí směr výuky, jehož pozůstatky jsou ještě patrné, upřednostňoval zase programování a schopnost algoritmizace jako klíčovou znalost v oblasti informačních technologí. S tím jakou úlohu mají nyní digitální technologie v našich životech, je další posun nevyhnutelný. Příští krok využití IT ve školství spočívá nepochybně v plošném vstupu nových médií do ostatních předmětů, kde umožní prohloubit pochopení probírané látky a zefektivní proces vzdělávání.

2.1

Nová média ve výuce

Na území Evropské Unie se inovací vzdělávání pomocí nových médií intenzivně věnuje nezisková organizace Futurelab1 a sdružení European Schoolnet2 . Tyto organizace provádějí výzkum, podporují inovativní projekty, publikují a představují fórum pro názory odborné veřejnosti. Aplikace nových médií ve výuce je předmětem výzkumu již několik desetiletí a existují již velmi úspěšné příklady užití. Zároveň se setkáváme s přístupy, které jsou buď v ranné fázi výzkumu a nasazení, nebo nebyly dostatečně zpopularizovány. Uvádíme přehled přístupů nasazení nových médií do výuky. 2.1.1

E-learning

E-learning je podpora a organizace výuky pomocí materiálů poskytovaných informačními technologiemi. Termín vyznívá jako široký, ale ve smyslu s jakým se dnes používá, je většinou obsažen informační systém s učebními materiály, testy, možností konzultace a dalšími moduly. V kontextu dnešních webových aplikací může působit E-learning jako přímočaré přenesení toho, co běžný uživatel Internetu zná, do procesu vzdělávání. Ve skutečnosti však tato forma podpory výuky existovala před všeobecně dostupnou sítí. E-learning byl mezi prvními aplikacemi hypertextu. Multimediální encyklopedie, které dnes pozbyly na významu, byly v 90. letech velmi atraktivní formou Elearningu. Ze všech aplikací nových médií se jedná asi o nejrozvinutější oblast. Dostupné financování E-learningových projektů, snadnost implementace (webové technologie), všeobecné využití a minimální nutné znalosti uživatelů jsou důvody jeho rozšíření. Současné pojetí E-learningu netvoří revoluci v systému vzdělávání, pouze inovuje způsob distribuce výukových materiálů a komunikaci. 1 2

http://www.futurelab.org.uk http://www.eun.org

10

2.1.2

Konstruktionistické učení

Konstruktionistické učení je směr inovující proces učení, jehož základy položil Seymour Papert a Idit Harel. Svůj přístup vymezují v práci (Harel a Papert, 1991), kde staví na konstruktivistické teorii mentálního modelu. Jedinci si kontinuálně vytvářejí subjektivní mentální model pojímající fungování reálného světa. Konstruktionistické učení staví na myšlence, že tento model je vytvářen efektivněji, pokud budou jedinci aktivně vytvářet libovolné artefakty s použitím předaných znalostí. Za první aplikaci této teorie v nových médiích se považuje programovací jazyk LOGO (první implementace z roku 1967). LOGO je funkcionální jazyk, kterým lze ovládat želvu kreslící geometrické obrazce. Vytvářením malých programů lze jednoduše praktikovat znalosti matematiky. Tento jazyk se dnes v různých implementacích používá v hodinách informatiky jako úvod do programování. Modely postavené na autonomních agentech a systémové dynamice lze vytvářet v prostředí NetLogo3 a vizuálně je simulovat. Touto cestou lze modelovat chemické, biologické, sociologické nebo ekologické procesy. Vytváření takových modelů ve zmíněných předmětech by jistě pomohlo k většímu porozumění. Pro větší rozšíření výuky na systémových modelech jsou zřejmé bariéry. Práce v prostředí vyžaduje alespoň minimální znalost disciplín, které nejsou vyučovány společně s danými předměty (programování, systémová dynamika). Musely by se změnit výukové plány, což se nezdá reálné. Konstruktionistické přístupy jsou zatím v největší míře praktikovány pouze se základním užitím nových médií, kdy učitelé nechávají žáky vytvořit vlastní učební materiály. 2.1.3

Memorovací algoritmy

Memorovací algoritmy tvoří jádro aplikací pro učení faktických znalostí. Předkládají uživateli pravidelně „kartičkyÿ a získávají v odpovědi, zda si je uživatel pamatuje. Udržují si databázi o časech a úrovních zapamatování pro vyhodnocování dalších kroků. Tato metoda učení je efektivní, protože jsou fakta předkládána podle křivky zapomínání. Uživateli tak stačí věnovat minimum času ve srovnání k nesystematickému učení a míra zapomínání je mnohonásobně menší. Přirozeně se touto metodou dají učit pouze faktické znalosti: slova cizího jazyka, vzorce, termíny, symboly, apod. Původní algoritmus, který zpopularizoval tuto metodu učení je SuperMemo. V současnosti je velmi rozšířená aplikace Anki4 implementující algoritmus SuperMemo2. 2.1.4

Počítačové hry

S nasazením počítačových her ve výuce se experimentovalo již od první poloviny 90. let. Ze všeobecně známých (komerčně vydaných) her nasazených ve výuce můžeme 3 4

http://ccl.northwestern.edu/netlogo/ http://ankisrs.net

11

uvést urbanistickou simulaci SimCity, historickou strategii Europa Universalis a sociální simulaci The Sims. Zmíněné tituly představují komplexní modely reálných systémů a umožňují sledovat dynamiku s jakou se projevují zásahy uživatele. Učitelé je využili jako motivující úvod k probírané látce sociologických nebo dějepisných předmětů a navození kooperativního prostředí mezi žáky (Kirriemuir a McFarlane, 2003). Současný stav nasazování her do výuky v zemích EU shrnuje studie (Wastiau, Kearney a Van den Berghe, 2009), která zaznamenává úspěchy učitelů s nasazením komerčních her ve výuce. Obě studie zmíněné výše, které mapují nasazení her ve školství, shledávají, že největší přínos mají propracované komerční tituly. Podle (Kirriemuir a McFarlane, 2003) je u učitelů nejpoužívanější hrou série SimCity (Electronic Arts, 1989–2007). Hráč, v roli starosty, plánuje výstavbu města, investuje do infrastruktury, nastavuje rozpočet a je nucen reagovat na problémy (kriminalita, znečištění, katastrofy, atd.). Hra spojuje témata několika disciplín v jedné aktivitě (matematika, finance, sociologie, politika, životní prostředí), což zvyšuje množství kontextů, ve kterých lze hru využít. Zároveň je interaktivně aplikována teorie předmětů v modelu komplexního systému, tak jak mají dopad přímo na život žáků. Autor SimCity William Wright5 , který se zabývá hrami i po teoretické stránce, ve své přednášce (Wright, Games for Learning, 2010) upozorňuje na výhody učení chybami, které hry umožňují. Naměřená data z The Sims ukazují, že lidé rádi testují bariéry selhání. Význam armádních simulátorů tkví právě v bezpečném zažití jinak fatálních stavů. Tato metoda učení byla tradiční v minulosti (učňové), ale je v přímém protikladu současného stavu, kdy je upřednostňována teoretická příprava znalostmi. Přínos her je i psychologický. Uživatelé promítají své vlastní hodnoty a charakterové rysy do virtuálního prostředí, což bylo prokázáno experimenty se hrou The Sims 2 v (Thaddeus,). Učitelé tak mohou vědět více o postojích jednotlivých žáků. 2.1.5

Sociální sítě

Sociální sítě jsou nejmladší z nových médií. Jejich přínos pro výuku zatím nebyl zkoumán v takové míře jako u předchozích přístupů. Je zřejmé, že již nyní mohou mít nepřímo pozitivní vliv na proces učení. Fungují jako katalyzátor komunikace, upevňování společenského statusu a konzultační prostor. Míra růstu uživatelů sociálních sítí je pro společnost nečekaná a jejich přítomnost nepůjde ignorovat. Dá se předpokládat, že další výzkumy zaměřené na inovace ve vzdělávání s nimi budou experimentovat. 5

Spoluzakladatel studia Maxis (akvizice Electronic Arts 1997), game designer her SimCity, The Sims, Spore a dalších.

12

2.2

Počítačové hry

Počítačové hry jsou nyní důležitým kulturním médiem, které se rozvinulo z hracích automatů 70. let minulého století. Každou technologickou generaci neustále rozšířují své publikum a dokáží zpracovávat hlubší témata. Práce zabývající se teorií interaktivních médií přejímají pohled na hru a její úlohu pro kulturu z (Huizinga, 1955) jako na „činnost, která probíhá uvnitř určitých hranic času, prostoru a smyslu (magický kruh), ve zřetelném řádu, podle dobrovolně přijatých pravidel, mimo oblast hmotné užitečnosti a nutnosti.ÿ Kompilační práce (Qvortrup, 2000) představuje celistvou ontologii pro nová média a věnuje zvláštní pozornost vymezení interaktivních médií od těch lineárních. Je zde vymezen rozdíl mezi učením pomocí hry a příběhů. Hry umožňují získat aktivní zkušenost se subjektem. Hra učí předmětu experimentováním, objektivizuje, kvantifikuje a předkládá redukovanou realitu v jasných kategoriích. Učení příběhem nebo výkladem je zprostředkované, budí empatii a má tendenci k prohlubování neurčitosti a hledání vazeb mezi subjekty (stírání rozdílů). Rozhodujícím rysem interaktivních médií plynoucí z interaktivity je mentální model (zmíněný v sekci 2.1.2), který si uživatel vytváří o pravidlech virtuálního světa. Tento proces je podvědomý a čím komplexnější je herní svět, tím složitější mentální model si hráč musí vytvořit, aby obsáhl jeho fungování. Optimální strategie není možná bez faktických znalostí, řízení fyzikálních modelů bez senso-motorické znalosti, apod. Hry samozřejmě proces vytváření a retenci mentálního modelu všemožně podporují – formou jednoduchých cílů, odměn a zpětné vazby. Odměny a neurčitost výsledku jsou jedním z rysů, kterým hry dokáží psychologicky budovat zájem. Ze znalosti vzorů (Bjork a Holopainen, 2005) se odměny dělí na vnitřní a vnější. Vnitřní odměny jsou přímou součástí jádra herních mechanismů – tržby z investic, body za vyhraný závod, poklady po poražených nepřátelích, atd. Vnější odměny jsou přidávány pro motivací hraní jako takového. Mohou nabývat podob filmových sekvencí na konci úrovně, veřejně publikovaných úspěchů na sociálních sítích, zkušenostních bodů odemykajících další obsah, atd. Cílem herního designu je strukturování těchto odměn, aby zájem hráče minimálně kolísal. Použití vnějších odměn by mělo být omezené a jejich nasazení ve větším rozsahu je diskutabilní, protože z psychologického pohledu je uživatel de facto manipulován k aktivitě, která by ho vnitřně nezaujala. Ilustrativním příkladem může být nadmíra vnějších odměn v sociálních hrách jako je např. FarmVille. Předkládáme přehled kategorií her, které nemají za primární cíl jen zábavu, ale jsou vytvářeny pro podporu výuky a poznání. Rozdělíme je do kategorií podle způsobu financování vývoje a účelu. Hranice mezi těmito kategoriemi nejsou ostré a některé tituly jsou samozřejmě obtížně zařaditelné. Způsob financování považujeme za důležitý, protože se, až na vyjímky, nejedná o typickou komerční produkci. Finanční zajištění vývoje je problematičtější a silně determinuje podobu výsledných produktů.

13

2.2.1

Edutainment

Zábavný a zároveň vzdělávácí software se obecně označuje jako edutainment. Herní tituly této kategorie jsou většinou určené předškolním dětem a prvnímu stupni základních škol. Komerční výukové hry se již ukázaly jako stabilní tržní segment pro různé platformy (nejčastěji PC). Od konce 90. let lze dokonce sledovat zvyšující se kvalitu obsahu i formy. Nutno dodat, že po obsahové stránce jsou hry triviální – procvičují aritmetiku, gramatiku, slovní zásobu cizích jazyků, atd. Tento tržní segment je z pohledu herního průmyslu naprosto marginální a často převažuje lokální produkce. Studia produkující tento obsah mají ambice spíše směrem k tradičním hrám pro stejnou cílovou skupinu, než jít v edukativních titulech opravdu do hloubky. Zda tato kategorie her může zpracovávat i náročnější témata je diskutabilní. Omezení v podobě nízkých rozpočtů, poměrně nízká rentabilita a požadavky na marketing produktů takové ambice zřejmě tlumí. 2.2.2

Serious games

Zvláštní kategorii v herním průmyslu tvoří serious games, které kladou účel herní aktivity nebo pochopení tématu před čistou zábavu. Tato poměrně mladá kategorie je v současnosti zastoupena krizovými simulátory, trenažéry a hrami zpracovávajícími pohled na společenské problémy. Projekty jsou typicky financovány státními nebo neziskovými organizacemi. Na rozdíl od edutainment produkce jsou tvůrci velmi inovativní v práci s herním médiem a zkušenosti, které chtějí uživateli předat jsou velmi atypické, k tomu co poskytují „zábavníÿ hry. Existují projekty, které zaznamenaly jasně měřitelný úspěch (např. Darfur is Dying6 ). Zdarma šířená hra se jako forma oslovení veřejnosti v prostředí sociálních sítí ukazuje jako neobyčejně efektivní. Učitelé mají možnost tyto hry využít a dělají tak. Nicméně dosavadní produkce této kategorie zasahuje jen velmi malou část klasických osnov vzhledem ke své inklinaci k aktuálním společenským problémům nebo specifickým potřebám organizací (krizové simulátory). 2.2.3

Výukové hry pro školy

Nasazení her ve školách je stále na úrovni experimentů, projektů podpořených sektorovými organizacemi (např. z oblastí financí, energetiky, obrany) nebo je to vlastní iniciativa učitelů. Specializované výukové hry pro školy vznikají pod záštinou státních institucí, grantových programů nebo na zadání. Jsou typicky úzce zaměřené na jeden předmět, který mají hrou přiblížit. Velmi častým jevem je nedostatečná kvalita po stránce vizuálního zpracování, ale především poutavosti či zpracování herního obsahu jako takového. Zatímco kvalita vizuálního zpracování je snadno řešitelný problém a požadavky nejsou tak vysoké, kvalitní herní návrh je úskalím i u profesionálního vývoje. 6

http://www.darfurisdying.com

14

Hra musí představovat funkční a konzistentní systém obsahující zajímavé interakce, což často nelze navrhnout dopředu a v průběhu vývoje je nutné nahrazovat špatná řešení funkčnějšími. Zjednodušeně lze říci, že k dobrém návrhu se vývojáři dostanou spíše v čase po mnoha iteracích. Zjevnou příčinou absence portfolia kvalitních výukových titulů pro školy je zejména podfinancování projektů, které z logických důvodů musí být pořízeny nebo jen podpořeny z neadekvátně stanovených zdrojů a nelze realizovat žádný další příjem skrze trh. Pro běžné herní studio jsou nerentabilní. Nejsou tedy vytvářeny profesionálními herními vývojáři, ale spíše na akademické půdě, začínajícími společnostmi nebo ve web designové firmě. Jedná se tak vlastně o negativní smyčku, kdy většina projektů nemá dostatečný úspěch v pilotním nasazení, nevybuduje důvěru pro širší nasazení ve výuce a v konečném důsledku pak neexistuje podnět pro odpovídající financování následujících projektů.

2.3

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

K vývoji počítačových her nelze přistupovat jako k vývoji obecného aplikačního software bez uvážení značných rozdílů v každém aspektu vývojového procesu. V současných vývojových týmech jsou ve větší míře zastoupeny profese uměleckých disciplín než inženýrských. Kritéria kvality produktů jsou převážně subjektivní a se značnou mírou neurčitosti. Dále existuje velká disproporce ve velikosti týmů stojících za projekty. Na trhu slaví úspěch tituly samostatných všestranných tvůrců nebo malých uskupení jako je např. Braid (Jonathan Blow, 2009), tak produkce profesionálních studií čítajících stovky zaměstnanců. Pro herní odvětví jsou hlavním informačním zdrojem přednášky z Game Developers Conference7 , kde promlouvají respektovaní tvůrci a prezentují své zkušenosti a myšlenky. Nejvlivnější osoby odvětví prakticky nepublikují a záznamy jejich přednášek jsou tak jedinou formou, kde se lze seznámit s jejich prací. 2.3.1

Game design

Game design představuje proces návrhu herních mechanismů (pravidel) a obsahu. V celkovém procesu vývoje se jedná o kritickou činnost umisťovanou před vlastní produkci, ale game designer musí nadále sledovat vývoj a poskytovat řešení nečekaných problémů. Hmatatelným výsledkem bývá game design document, který slouží jako výchozí dokumentace pro technické i umělecké provedení hry. Rozsah a podoba dokumentu je již specifická pro každý projekt. Pozornost je vždy věnována stěžejním aspektům produktu, které jsou kritické pro jeho úspěch. V závěrečné fázi vývoje optimalizuje hratelnost laděním parametrů herních mechanismů. Jednotný jazyk pro formulaci návrhu herních mechanismů je definován formou vzorů v (Bjork a Holopainen, 2005). Autoři v práci definují i vztahy mezi vzory v podobě přejaté z vzorů pro objektový návrh (Gamma a kol., 1994). Se znalostí 7

Archív slidů, audio a video záznamů přednášek z GDC – http://www.gdcvault.com

15

těchto vzorů je možné kriticky nahlížet na kvality game designu, odhalovat slabá místa nebo nechtěné vedlejší efekty jednotlivých prvků návrhu. Zmíněná práce je prvním systematickým pohledem na game design s obecnou platností. Ostatní práce často prezentují subjektivní pohledy autorů a obsahují specifičnosti různých žánrů. Zcela nové myšlenky nebo kombinace herních mechanismů lze otestovat prototypem, který se vytváří se zjednodušenou implementací herních mechanismů a provizorní vizualizací. V případě příliš komplexního světa, lze vytvářet pouze dílčí prototypy, jak tomu bylo při vývoji Spore8 . Vytváření prototypů je ovšem nákladné. Nejen z důvodů programování aplikací určených k zahození, ale také prodlužováním předprodukční fáze. 2.3.2

Přístup k návrhu systému

Role návrhu systému v procesu herního vývoje sice nabývá na významu, rozhodně však není na takové úrovni jako u ostatních oborů vývoje software. V případě programování leží kritéria kvality často v použitých algoritmech pro vizualizaci a umělou inteligenci, ve fyzikálních modelech a jiných dílčích subsystémech. U řady žánrů není vyžadována komplexní objektová struktura aplikace. Dlouhá tradice vývoje her v malých týmech, poměrně krátké vývojové cykly a absence nutnosti udržovat kód v delším čase, nevytvořily prostředí, kde by bylo na objektový návrh nahlíženo jako na důležitou složku vývoje. S postupným nárůstem velikosti vývojových týmů a příchodem her jako on-line služeb, které musí být udržovány několik let, se situace mění. Především ve spojitosti se současnou (od cca 2005) generací konzolí vývojové týmy čítají desítky, někdy i stovky osob. Tato studia se většinou specializují na jeden herní žánr. V extrémním případě jsou zavedeny na jediný titul a každý rok vydávají nový díl série (např. sportovní tituly). Metody vývoje takových projektů už často upřednostňují kontinuální integraci, automatizované testování a agilní vývojové metodiky. Některé z těchto zásad se pak prosazují i v prostředí menších týmů. 2.3.3

Platformy

Konzole9 jsou nyní majoritní herní platformou. Společnost Nintendo, která má majoritní podíl na trhu současné generaci domácích konzolí (od 2007), je následována Microsoftem (konzole Xbox) a Sony (PlayStation). Jedná se o nejziskovější sektor a pro publikování obsahu jsou zde značné finanční i technické bariéry. V oblasti osobních počítačů a mobilních zařízení (iOS, Android) je naopak práh vstupu na trh nízký a v jistém směru začínají zařízení obecnějšího užití postupně konzole nahrazovat. Z pohledu naší práce je zajímavé, že digitální distribuční kanály pro mobilní zařízení (zejména AppStore) jsou již nyní plné obsahu určeného dětem, který se má výukový nebo výchovný potenciál. 8

Zveřejněné protypy z vývoje Spore – http://www.spore.com/comm/prototypes Termínem konzole se označuje specializovaný hardware určený výhradně k hraní, případně přehrávání médií. 9

16

Nejrychleji rostoucím segmentem poslední doby jsou on-line hry a hraní ve webovém prohlížeči s technologiemi AJAX nebo Adobe Flash. Hry jsou provázané s prostředím sociálních sítí a inovují i způsoby placení za obsah. Vůdčí společností na trhu s mobilními zařízeními je nyní Apple, která v roce 2010 uvedla na trh tablet iPad. Nyní ji následují ostatní společnosti s výkonnějšími a cenové dostupnějšími produkty. Tablety se ovládají dotykovým displayem, mají praktické rozměry, delší výdrž baterie než notebooky a především jsou levnější. Je možné, že se stanou běžným IT vybavením škol. 2.3.4

Vývojové nástroje

Vzhledem k různorodosti platforem a tlaku na snížování nákladů se ve vývoji prosazuje použití frameworků a licencovaných technologií. Za framework se považuje systém, který integruje potřebné komponenty (vizualizace, fyzika, zvuk, vstupy, podpora skriptování, atd.) do run-time prostředí a zároveň obsahuje produkční nástroje pro práci s projektovými daty. Vývojový tým je pak zodpovědný čistě za implementaci herní logiky a produkci audiovizuálního obsahu. Na poli frameworků pro 2D grafiku dominuje Adobe Flash. Hlavní předností je míra penetrace plug-inu ve webových prohlížečích (téměř 100%). Vizualizace 3D prostředí je obecně komplikovanější vzhledem k vazbě na hardware a nutnosti poskytnout efektivní běhové prostředí pro náročné algoritmy. Na trhu nalezneme více různých produktů, které mají své silné i slabé stránky. Pro přehled odkážeme na sekci ??, kde budeme evaluovat dostupná řešení. Nejrozšířenějším programovacím jazykem je C++ pro efektivitu zkompilovaného kódu. Maximální využití výkonu hardware je příznačné pro herní průmysl. Aplikace nejnovějších a nejnáročnějších technik 3D vizualizace byly vždy velkou konkurenční výhodou. Zároveň se jedná o všeobecně rozšířený programovací jazyk ve vývoji software, což je velká výhoda v množství dostupných knihoven. Majoritní většina takových projektů je open source, což snižuje riziko neudržovanosti nebo nemožnosti odhalit chyby. 2.3.5

Metodiky řízení vývoje

Produkce interaktivních děl je multidisciplinární proces, ve kterém je programování pouze dílčí složkou. Většina rozpočtu projektů je určena pro tvorbu obsahu: 3D modely, animace, zvuky, atd. Na řízení takových projektů je ale nahlíženo jako na vývoj software a používají se obdobné metodiky jako ve software vývoji. Vývoj po milnících je nejstarší metodikou řízení produkce. Profesionální herní vývoj byl vývojářskému studiu jako nezávislé entitě financován vydavatelem, který byl zodpovědný za definování produktu a kontrolu kvality. Aplikovaná metodika vývoje byla obdobou vodopádopádového cyklu známého z počátků softwareového inženýrství. Produkce je rozdělena na podrobně definované milníky (typicky měsíční), které jsou postupně předávány ke kontrole, zda splňují smluvně daný

17

obsah. Dokumentace a výtvarné koncepce jsou součástí prvního milníku, funkční aplikace druhého atd. Takový proces vývoje trpí na nečekané problémy a nedostatek prostoru je řešit. Segment video her, který byl takto financován je nyní konsolidován a vydavatelé už zřídka financují vývoj externí entitě. Milníky se však nadále vyskytují ve smlouvách. Ve své původní podstatě je tato metodika použita pouze v případě velké míry zkušenosti s žánrem nebo v případě navazujícího vývoje na již vydaný produkt. Iterativní vývojový cyklus byl k nalezení u studií, která sama financovala vývoj a měla proto mnohem vyšší nároky na kvalitu produktu. Typickými zástupci jsou studia 3D Realms a Blizzard (před fůzí s Activision). V profesionálních studiích dnešní velikosti je už neaplikovatelný, protože neposkytuje nástroje pro organizaci velkých týmů. Je s výhodou aplikovatelný spíše pro malé týmy a projekty menšího rozsahu. Iterace jsou pro vývoj přínosné v odhalování slepých cest v zaměření hratelnosti a precizování produktu. Základním požadavkem je, aby měli vývojáři kontrolu nad cykly a měli určitou volnost v čase nutném k dokončení. Agilní metodiky vývoje jsou ve velké míře používány i v herním průmyslu. Jinak by bylo nemyslitelné organizovat opravdu velké týmy čítající desítky až stovky lidí. Rozdělení do menších samostatných jednotek, jak požaduje metoda Scrum, se nabízí i kvůli specializaci. Vedení může lépe monitorovat vývoj, řídít požadavky na kvalitu a dodržet termíny. Agilní metodiky jsou nyní převládající u velkých studií, což je doložitelné z portfolia společnosti Hansoft, která poskytuje software pro management vývoje specializovaný na herní průmysl.

18

3

Analýza nového projektu

Hospodaření a management obecně je schopnost. Pouze teorie nestačí a je nutné zprostředkovat zkušenost. Ze směrů, kterými se nová média do výuky aplikují, se jeví nejvhodnější konstruktionistický přístup představený v sekci 2.1.2 a hry, jejichž vlastnosti byly zevrubně představeny v sekci 2.2. Tyto směry mají společný konstruktivistický pojem mentálního modelu. Cílem je poskytnout prostředí, kde by mohli uživatelé bezpečně a zajímavě selhat, jak bylo rozvedeno v sekci 2.1.4, ale zároveň byli dostatečně motivování k úspěchu. Počítačové hry jsou silné ve vytváření motivace, ta by u čistě konstruktionistického řešení chyběla. Futurelab ve své zprávě (Bober, 2010) uvádí motivace pro aplikaci her ve vzdělávání a přehled elementů, které by měly obsahovat: výzva, příběh, role, cíle, sociální aspekty a pravidla.

3.1

Finanční gramotnost

Rámec pro zaměření výukového cíle projektu nám poskytuje finanční gramotnost. Dle dokumentu (MF, MŠMT a MPO, 2008) je finanční gramotnost strukturovaná na tři složky: peněžní, cenovou a rozpočtovou. Je definovaná jako specializovaná součást ekonomické gramotnosti. V našem projektu se zaměříme na rozpočtovou dovednost, která je důležitá při hospodaření. Podle (Smrčková, 2009) by zájem žáků měl být podpořen atraktivní formou podání ekonomických poznatků, což je sice v kompetenci učitele, ale na druhou stranu nelze přenést veškerou odpovědnost jen na pedagogy.

3.2

Přehled literatury

Při návrhu řešení a implementaci budeme používat literaturu pro software vývoj a některé práce specializované na herní průmysl. Dekonstrukce virtuálního světa na topologie, dynamiku a implementační paradigmata přednesená v (Wright, GameTech, 2010) ukazuje jak přistupovat k provázanosti herních mechanismů a technického řešení. Zásady pro návrh architektury systému pomocí jazyka UML čerpáme z (Fowler, 2004). Obecné UML vzory objevující se na aplikační vrstvě jsou představeny v (Eriksson a Penker, 2000). Pro objektový návrh lze využít znalost návrhových vzorů (Gamma a kol., 1994). Autoři předkládají soubor problémů řešených pomocí objektových konstrukcí označovaných jako vzory. Lze tak zabránit redundanci a zvýšit konzistentnost kódu. Vlastní metodika vývoje bude vycházet z moderních přístupů k řízení vývoje. Agilní vývojové metodiky představuje (Kadlec, 2004). (Kniberg, 2007) se zabývá metodou Scrum a extrémním programováním, které využíváme pouze okrajově. Vývoj 3D aplikací vyžaduje dobrou znalost lineární algebry, algoritmů pro vykreslování počítačové grafiky a částečně i hardware (Verth a Bishop, 2004). V práci budeme implementovat dobře známé a popsané algoritmy používané v herním

19

průmyslu. Navigace postav v 3D prostředí, datově orientované architektury a další herně-specifické řešení jsou popsané v kompilaci (DeLoura, 2000). Autonomní pohyb agentů lze řešit algoritmem boids popsaným v (Reynolds, 1987).

20

4

Metodika

Prezentujeme zde vlastní metodiku, kterou jsme navrhli na základě analýzy. Metodika vychází z tradičního přístupu k vývoji počítačových her, jak je na něj pohlíženo v sekci 2.3. Kde uznáváme za vhodné, volíme vlastní přístup.

4.1

Specifikace požadavků

Objektivně specifikujeme požadavky na základě potřeb, které jsou identifikovány analýzou.

4.2

Koncepce hry

Vývoj započneme vytvářením herního konceptu. Tento dokument v rozsahu 5 až 10 stran stručně popisuje základní herní mechanismy, ovládání hry, příběh nebo prostředí a další detaily. Využíváme srovnání s obdobnými tituly, na které se odkazujeme (poskytují funkční provedení prvků, které použijeme). Dokument musí být podrobný do té míry, aby byla podstata a možné provedení hry komunikovatelné. Navrhujeme technické řešení, stanovujeme minimální požadavky na hardware a možné cílové platformy. Na základě tohoto dokumentu by mělo jít odhadnout rozpočet, hodnotit proveditelnost a plánování vývoje.

4.3

Game design

Po uzavření koncepční fáze vytváříme game design document, který slouží jako výchozí dokumentace pro technické i umělecké provedení hry. Rozsah a podoba dokumentu je již specifická pro každý projekt. Pozornost je vždy věnována stěžejním aspektům projektu, které jsou kritické pro jeho úspěch.

4.4

Evaluace technologií

Před technickým provedením projektu je nutné evaluovat a zvolit technologie, knihovny programovacího jazyka a další komponenty. Výměna nevhodně zvolené komponenty bývá v pozdějších fázích projektu nákladná nebo prakticky nemožná, proto je této fázi nutné věnovat zvláštní pozornost. Naším základním požadavkem je nezávislost na operačním systému a pokud možno open source licence. V případě uzavřeného řešení existují rizika, že naše problémy nebudou vůbec nebo příliš pozdě řešeny.

4.5

Návrh architektury systému

Na základě game design dokumentu lze navrhnout datový model části systému, který představuje statickou část systému. Spadají sem entity herního obsahu a podpora

21

herních mechanismů. Objekty dynamické části systému budeme modelovat v jazyce UML. Dekomponujeme problém shora dolů ve statickém diagramu tříd.

4.6

Produkční plán

Stručný popis a přehled vytvářeného obsahu je stanoven v produkčním plánu. Tento soubor dokumentů představuje podklad pro organizaci produkce 3D modelů, textur, animací a zvuků. Vycházíme zde z game design dokumentu, který popisuje jednotlivé kategorie herních objektů a jejich chování. Plán průběžně aktualizujeme.

4.7

Produkce

Pro řízení vývoje budeme používat vlastní metodikou vycházející z iterativního přístupu a zásad agilních metodik, jak byly popsány v sekci 2.3.5.

22

5

Návrh vlastního řešení

K návrhu vlastního řešení přistupujeme podle metodiky představené v kapitole 4.

5.1

Specifikace požadavků

Na základě analýzy v kapitole 3 vyplynulo, že je požadována systémová „hračkaÿ – zábavná hra postavená na metaforách představující model komplexního systému, která zapojuje prvky z osnov finanční gramotnosti. • Finační toky musí být viditelné a kategorizované, aby podporovaly rozpočtovou dovednost. • Pro případ selhání existují pružné bariéry, aby bylo podpořeno učení chybami. • Musí existovat jasné a obtížně dosažitelné kritérium pro úspěch (sociální aspekt). • Pro podporu motivace jsou požadovány vnitřní i vnější odměny. • Aplikace musí být provozuschopná i na starším hardware. • Aplikace musí být otevřená pro modifikace a rozšíření obsahu, aby ji šlo přetvořit pro různé kontexty s minimem nákladů.

5.2

Koncepce

Za jádro hry, které pokrývá požadované disciplíny, volíme zjednodušené podnikové hospodaření. Tato činnost má herní charakter sama o sobě, vyžaduje strategické uvažování a umožňuje soutěž mezi žáky. Jako prostředí volíme rodinnou farmu. Je to srozumitelné a atraktivní prostředí, kde lidské zdroje hrají hlavní roli. Zároveň zde nalezneme v dobře prezentovatelné formě ekonomický systém, na kterém se lze naučit naprosté základy podnikového hospodaření (bilance, výdaje, investice, výnosy z rozsahu, atp.). Úspěchy ve hře jsou odměňovány vnitřně (expanzí farmy, možnostmi nákupu zvířat, dekorací, apod.) a postup vnější odměnou (zpřístupněním nových plodin, plemen, apod.). 5.2.1

Volba herních mechanismů

Herní žánr, který spočívá v ekonomické simulaci, budování podniku nebo celého obchodního impéria se nazývá tycoon. Za nejvýznamnější tituly tohoto žánru lze považovat Transport Tycoon (MicroProse, 1994), Capitalism (Interactive Magic, 1995) a Theme Hospital (Electronic Arts, 1997). Tento žánr je v současnosti spíše okrajový a obdobně významné tituly jsou vydávány už jen zřídka. Přesto v druhé polovině 90. let minulého století patřily tycoon hry k těm nejprodávanějším, protože umožňovaly hráčům řešit reálné problémy. Téma hospodaření nebo vedení podniku se nyní ve velmi zjednodušené, téměř triviální podobě, objevuje v casual 10 hrách 10

Kategorie jednoduchých a přístupných her pro občasné hráče.

23

time management žánru. Po hráči se v nich požaduje plánování různě časovaných akcí, ze kterých se skládá produkce zboží nebo obsloužení zákazníka v restauraci. Požadovaný game design by měl stát na více žánrech. Čas hraje při organizaci práce důležitou roli a time management hry jsou dnes populární vzhledem k uživatelské přístupnosti. To však zpravidla není rys tycoon her, tudíž se nabízí spojení obou zmíněných žánrů. 5.2.2

Technické zpracování

Jako metoda vizualizace bylo zvoleno plné 3D zobrazení vykreslované v reálném čase. Jednoduché 2D zpracování je sice levnější z pohledu produkce a je podporováno i na starším hardware, nicméně působí zastarale, staticky, neumožňuje práci se světlem, skládání animací apod. V současnosti je hardware podporující rozhraní pro 3D vizualizaci standardem i u mobilních zařízení. Rozdíly ve výkonu a potřebné funkcionalitě (např. vertex/fragment programy) jsou samozřejmě značné, tudíž je potřeba zvolit skupinu zařízení nebo počítačových konfigurací, na které se bude cílit. Cílovou platformou je dnes nejrozšířenější Windows PC, případně operační systémy MacOS X a GNU/Linux. V čase se ovšem může aplikace nasazovat i na dosud neznámé nebo zatím málo výkonné (zejména mobilní) platformy. Primární skupinou zařízení byly zvoleny stolní a přenosné počítače vyjma tzv. netbooků s grafickým chipsetem Intel (před Intel Atom Pineview). Ty jsou sice velmi rozšířené, ale výkonem patří k té nejnižší kategorii na trhu a nebudou mít dlouhou životnost.

5.3

Evaluace framework řešení

V první fázi jsme zvažovali použití celého frameworku. Jak bylo zmíněno v sekci 2.3.4, jedná se o nákladově výhodnější řešení za cenu určitých kompromisů. 5.3.1

Unity

Unity je vývojové prostředí a run-time platforma s širokou podporou cílových operačních systémů a zařízení (Windows PC, MacOS, iOS, konzole současné generace a další). Vysoká míra přenositelnosti aplikací je umožněna integrací projektu Mono jako exekučního prostředí přeloženého kódu uživatelské aplikace. Aplikační logika se tedy programuje v jednom z .NET jazyků (C#, Boo, JavaScript). Aplikační logika by tedy měla zpracovávat události, využívat maximálně funkcí platformy a neobsahovat algoritmicky náročné části. Při evaluaci nastaly pochybnosti zda je Unity vhodné pro tak rozsáhlý projekt, jelikož i triviální demonstrativní aplikace měly nízký framerate a vzhledem k složitosti zobrazované scény poměrně vysokou paměťovou náročnost. Dále, zda půjde vystačit se zjednodušeným pojetím 3D grafiky. Ex post můžeme tuto pochybnost potvrdit. V závěru projektu se ukázalo jako klíčové instanciovat geometrii a tím snížit počet renderovacích dávek, což by s tímto řešením nebylo možné. 24

5.3.2

Torque3D

Torque engine je oblíbený mezi nezávislými vývojáři pro malé a nenáročné tituly. Běhové prostředí je nezávislé na operačním systému, k dispozici jsou 3D editory, debugger integrovaného skriptovacího jazyka a další nástroje. V čase evaluace však působil zastarale a nebyla jasná jeho budoucnost, vzhledem k akvizici tvůrce Garage Games společností IAC, která se orientuje na Internetové služby a mohla by ukončit podporu tomuto produktu. 5.3.3

UnrealEngine Development Kit

UnrealEngine je v herním průmyslu etalon kvality v žánru akčních her z prvního pohledu. Byl použit jako základní technologie u projektů s rozpočty v desítkách miliónů dolarů. Nyní je UDK volně dostupný k použití i nezávislým vývojářům. V našem případě je ale nevýhodou specializace na konkrétní žánr akčních her z pohledu první nebo třetí osoby. 5.3.4

Vyhodnocení

Z evaluovaných frameworků nevyhovoval žádný plně našim potřebám nebo jsme nebyli plně přesvědčeni o jeho vhodnosti pro řešení projektu. Upozorňujeme však, že situace na tomto trhu se rychle mění a již v době dokončování projektu některé nevýhody Unity nebyly platné. Od evaluované verze 2.6 k dnešní verzi 3 prošel produkt značnými změnami po všech stránkách.

5.4

Evaluace komponent herního engine

Rozhodli jsme si sami integrovat požadované komponenty do vlastního systému. Jako implementační jazyk bylo zvoleno C++, které je v herním průmyslu standardem. Umožňuje psát vysoce výkoný a portabilní kód. Nespornou výhodou je také široký výběr prověřených knihoven. Pro hru bylo zvoleno plné 3D zobrazení, což znamená vyšší složitost na straně implementace i produkce obsahu. Vizualizační subsystém je tak jednou z hlavních a nejkomplexnějších komponent. S inovacemi v oblasti 3D renderingu narostla náročnost na architekturu a výkon vrstvy (tzv. 3D engine) mezi nízkoúrovňovým API (OpenGL nebo Direct3D) a aplikační logikou do takové míry, že se nevyplatí budovat si vlastní řešení pokud jsou požadavky standardní. Další komponenty, které je nutné integrovat pro potřeby projektu, jsou prostorový zvuk, vstupní formáty a zajištění datové perzistence. Pro potřeby implementace herního konceptu potřebujeme 3D engine podporující charakterové animace, snadnou práci s materiály a efekty, optimální vykreslování scény, širokou podporou formátů, atd. Z dalších komponent je to zejména audio, které v případě 3D provedení není triviální na implementaci a bylo by vhodné využít hotový middleware. Framework řeší i problém s různými kategoriemi dat, které je 25

potřeba pro reprezentaci a dynamiku herního světa. Tyto formáty a nástroje si musíme zvolit a integrovat sami. 5.4.1

3D engine

OGRE3D11 je považován za nejpokročilejší 3D engine vyvíjený stabilní komunitou pod otevřenou MIT licencí. Je nezávislý na platformě díky abstrakci na několika úrovních. Renderovací subsystém je tak implementován pro různá nízkoúrovňová API (Direct3D 9, OpenGL 2.0 a OpenGL ES 2.0). Výhodou je plně objektově orientovaná architektura, která se ještě v nedávné době zdála jako přítěž vzhledem k značné paměťové režiji. Jednotlivé subsystémy jsou tak ale snadno zaměnitelné nebo rozšiřitelné. K dispozici je třeba několik různě specializovaných implementací třídy SceneManager, RenderSystem, MovableObject a plug-inů. Kolem projektu je soustředěna velká komunita, která vytváří i nástroje. Některé nástroje jsou dokonce komerční a poměrně kvalitní. Lze tak mít editor pro materiály, částicové systémy, exportéry do 3D modelovacích prostředí, atd. 5.4.2

3D zvuk

Zvukový engine irrKlang byl zvolen na základě předchozí zkušenosti a je využit v mnoha nezávislých hrách. Jednoduchým objektovým rozhraním lze umístit v prostoru zvukové zdroje, které jsou přehrávány s intenzitou podle pozice a orientace posluchače. Jedná se o middleware, který zjednodušuje práci se zvukem a abstrahuje od konkrétního systémového API. Implementace existuje pro platformy Windows (využívající DirectSound 8), MacOS X a Linux (ALSA). 5.4.3

Vlastní formáty

Značkovací jazyk XML se v herním vývoji používá zejména pro reprezentaci metadat k binárním formátům, podporu datově řízeného přístupu k aplikační logice, apod. Knihovna TinyXML12 byla pro parsování XML vybrána na základě předchozí zkušenosti. Její předností je jednoduché a praktické objektové rozhraní, se kterým byli řešitelé projektu zvyklí pracovat. Nutno dodat, že rychlost je vykoupena jednoduším parserem, který nijak neupozorňuje na chyby ve struktuře dokumentu. Pro odhalení chyby je v takovém případě XML dokumenty nutné validovat proti schématu. V některých případech existují požadavky na strukturovanou reprezentaci dat a zároveň na stručnost tak, aby mohli uživatelé soubory editovat obyčejným textovým editorem a rychle se orientovat v jeho obsahu. XML značky představují zbytečný obal kolem vlastních dat a snižují přehlednost. YAML je velmi stručný značkovací 11 12

Open Graphic Rendering Engine – http://www.ogre3d.org http://www.grinninglizard.com/tinyxml/

26

jazyk nabízející alternativu k XML. Cíleně řeší tento nedostatek zachováním strukturní síly formátu za minimálních metadat. Tento přístup je vhodný zejména pro konfigurační soubory. Pro parsování jsme použili implementaci libYAML13 . 5.4.4

Perzistence herního stavu

Hledáme řešení pro podporu serializace objektů herního stavu včetně vazeb. Jazyk C++ totiž standardně nepodporuje automatickou metodu uložení a obnovy instancí tříd. Těmto požadavkům vyhovuje knihovna projektu Boost14 , který si klade za cíl rozšířit standardní výbavu jazyka C++. V jmeném prostoru boost::serialization nalezneme šablonové funkce, s kterými lze snadno implementovat serializační metodu pro každou třídu. Stav lze uložit binárně, textově nebo do XML. Stavy herních sezení a uživatelské profily by bylo vhodné fyzicky ukládat do jediného souboru formou souborové databáze. Pro uchování dat na disku byla zvolena relační databáze SQLite15 . S výhodou lze souborovou databázi využít i pro parametrizaci herního obsahu. Relační schéma lze využít pro zachování konzistence a usnadnění manipulace s tabulkovými daty. 5.4.5

Lokalizace

Texty musí být uloženy jako data mimo zdrojové kódy a je nutné uvažovat o lokalizaci do dalších jazyků. Pro ukládání textů byl zvolen standardní formát TMX16 , který je zdokumentovaným XML dialektem a tudíž je s ním snadná manipulace. Pro překladatele je dostupných několik editačních nástrojů, z kterých si mohou vybrat. Jedním z nich je zdarma dostupný Olifant Translation Memory Editor17 . 5.4.6

Skriptovací jazyk pro integraci

S vlastním projektem je nutné ještě vyvíjet vlastní specifické nástroje, integrovat nástoje jiných dodavatelů, nebo jen transformovat a validovat data. Populárním skriptovacím jazykem pro systémovou integraci je Python18 . Tento jazyk je syntakticky stručný a má volnou typovou kontrolu, tudíž zvyšuje produktivitu. 13

http://code.google.com/p/yaml-cpp/ http://www.boost.org 15 http://www.sqlite.net 16 Translation Memory specifikace – http://www.lisa.org/Translation-Memory-e.34.0.html 17 http://okapi.sourceforge.net 18 http://www.python.org 14

27

5.5

Produkce audiovizuálního obsahu

Produkce audiovizuálního obsahu hry vyžaduje množství specializovaných nástrojů a technických postupů. Samotná problematika je mimo zaměření této práce, proto ji představíme pouze stručně. 5.5.1

3D modely

OGRE3D náčítá 3D modely a animace z vlastního binárním formátu, do kterého jsou data exportovány z 3D modelovacích prostředí. Podporovány jsou prakticky veškeré používané aplikace tohoto druhu (Maya, 3D Studio Max, Blender) – je tedy na grafikovi, který si vybere pro práci a pro naši aplikaci to nehraje roli. Žádné meziformáty nejsou součástí systému. Materiály reprezentující povrch modelů se skládají z textur (obrazových dat). Textury jsou načítány v komprimovaném formátu DDS19 , který dokáže hardware v reálném čase dekódovat. Transformovat do tohoto formátu lze běžné obrazové formáty nebo lze exportovat z grafických editorů. 5.5.2

Audio

Z komprimovaných zvukových formátů podporuje irrKlang MPEG3 a Ogg Vorbis. Pro zvuky i hudbu byl zvolen svobodný formát Ogg, který je široce podporován aplikacemi. Výběr aplikací pro zpracování zvuku je na dodavateli zvukových stop. Stejně jak u vizuálních dat platí, že meziformáty nejsou součástí systému.

5.6

Game design

Ve stručnosti zde seznámíme s game designem ve finální podobě, která se dotvořila v průběhu vývoje. Pojetí herních mechanismů je inspirováno deskovými hrami, což znamená výhodu transparentnosti a možnost jednoduše prezentovat herní stav. Zároveň je usnadněn proces balancování hratelnosti (menší stupeň volnosti) a nabízí se větší volnost pro vyjádření metafor. Důležité tabulky parametrizující výpočty herních mechanismů, které nejsou uvedeny v této kapitole jsou součástí příloh. 5.6.1

Svět

Herní svět se skládá z několika uskupení čtvercových políček (tile), které jsou zasazeny do vymodelované krajiny. Statický model terénu rozrušuje pravidelnost a tvoří kulisy, aby svět nepůsobil uměle. Hráč má tak k dispozici jasně ohraničenou a kvantifikovatelnou hrací plochu. Tato políčka se aktivují umístěním objektů, které vrámci projektu označujeme tile content. Rozloha těchto specializovaných kontajnerů pro další herní objekty může být různá (rozměry nad 1 tile uvedeny ve výčtu). K aktivaci těchto objektů je nutná práce a v některých případech i finanční investice. 19

Direct Draw Surface – standardní formát využívající ztrátový kompresní algoritmus S3TC

28

• • • • • •

zeleninový záhon - pěstuje se zde zelenina, může zarůst plevelem pole - místo pro pěstování polních plodin (2 × 1) ovocný sad - zasazený strom roste a musí se prořezávat ohrada - lze zde chovat dobytek (2 × 1, 2 × 2, 2 × 3) kurník - místo pro drůbež, snáší vajíčka park - odpočinkové místo, lze osázet květinami a dekoracemi Políčka jsou seskupena do oblastí po dvou až šesti. Vzdálenější oblasti mohou být zalesněné – vyžadují vymýtit les a odklidit kameny. Expanze farmy tak vyžaduje investici v podobě práce. Důležité místo ve světě zaujímá dům s kuchyní. Dům lze s investicí peněz i práce rozšířit, aby mohl pojmout více osob. Na záhony lze umisťovat zakoupené květiny a dekorace. Nabízí se tak možnost esteticky zkrášlit prostředí obyvatelům farmy. Množství květin a dekorací má přímo úměrný vliv na pracovní morálku postav. 5.6.2

Práce

Hráč musí v omezeném čase stihnout maximum prací příslušného období. Cílem je, aby měl hráč více práce než lidských zdrojů a byl tak nucen dělat operativní rozhodnutí. Povaha prací se snaží přiblížit realitě. Na jaře se sází zelenina, seje pole, prořezávají stromy, v létě zase sklízí a oře. Práce se zvířaty, vymýcení lesa, stavění, atd. se může provádět v každém období. Výnos z prací je rozdílný, stejně jako požadavky na schopnosti a namáhavost (viz tab. 10 v přílohách). 5.6.3

Postavy

Postavy jsou středem pozornosti, protože vykonávají veškerou práci na farmě, kterou hráč neplánoval nebo sama vznikla. Farma je obydlena rodinou, která se může rozrůst o nové členy, když farma prosperuje. Postavy jsou charakterizovány několika atributy: podoba (model hlavy, vlasy), talenty, schopnosti a potřeby (hlad, odpočinek). Agregovaným atributem je pracovní morálka, která je součtem několika efektů a determinuje pracovní výkonnost (tab. 3). Postavy nacházející se na farmě jsou definovány ve scénáři. Nově narozená postava se generuje. Talent je celočíselný atribut na škále < 0, 8 > modelující odlišné vlastnosti lidí. Muži mají při generování postavy bonus (náhodné číslo z intervalu < 0, 2 >) pro sílu, ženy obdobně pro šikovnost. Hráč může dočasně zvýšit některý talent bonusem z jídla. Při stárnutí postavě klesá vitalita (tab. 9). • síla – určuje únavu získanou při práci (využito v tab. 4) • šikovnost – určuje jak rychle roste úroveň schopností (tab. 8) • vitalita – rychlost regenerace únavy (tab. 5) Schopnosti umožňují postavám být efektivní v pracích, které vyžadují specializaci. Úroveň schopnosti je v intervalu < 0, 6 > a roste podle tabulky 7. Schopnost 29

morale 6 5 4 3 2 1 0 -1 -2 -3 -4 -5 -6

efficiency 100 100 100 100 100 100 100 90 80 70 60 50 0

anim speed 140 130 120 115 110 105 100 95 90 85 80 75 0

Tabulka 1: Vliv morálky na efektivitu práce a rychlost provedení. determinuje efektivitu pracovního výkonu (tab. 3). Efektivitu modelujeme časem stráveným danou činností dvojím způsobem: vkládáme „nešikovnéÿ animace (např. vypadnutí nástroje z ruky a jiné přerušení práce) nebo měníme rychlost animací. Některé práce umožňují zlepšení předmětu činnosti formou kritického úspěchu – metafora pro dobře uvařené jídlo, zkultivovanou půdu, apod. Čím vyšší je úroveň schopnosti, tím vyšší je šance na tento úspěch. • obdělávání půdy – úspěch je zlepšení úrodnosti políčka • rostliny – úspěch jsou vyšší výnosy z úrody • zvířata – úspěch je zvýšení hodnoty zvířete • těžké práce • vaření - úspěch jsou vyšší bonusy k talentům Členové rodiny se zkušeností zlepšují ve schopnostech, zatímco nádeníci, najímaní za mzdu, přichází s fixní (nízkou, nevyváženou) úrovní schopností. Významným nákladem spojeným s postavami je jídlo, které se musí připravovat. Hlad postupně snižuje morálku (až −3). Postavy mohou maximálně dvě období hladovět, jinak se rok opakuje. Jídla jsou různě náročná na dobu přípravy a cenu. Podle toho mají pozitivní vliv na morálku (dočasné zvýšení o < 0, 3 >). Pro ozvláštnění mají některá jídla speciální efekty (např. špenát zvyšuje sílu). 5.6.4

Výnosy z úrody

Nejdůležitou složkou příjmů jsou výnosy ze zeleniny, polních plodin a ovoce. Výnos z úrody je determinován kvalitou úrody (procentuální hodnota). Kvalita úrody je výsledkem několika vlivů vážených citlivostí rostlin na jednotlivé vlivy: úrodnost půdy, počasí a dodatečné práce. Modelujeme tak různorodost rostlin. Podle

30

tabulky 2 se pak interpolují hodnoty rozdělení pravděpodobnosti a náhodou se rozhodne, zda bude výnos nulový, špatný, dobrý nebo vynikající. quality P(none) 0 0,2 0,1 0,15 0,2 0,1 0,3 0,05 0,4 0,01 0,5 0 0,6 0 0,7 0 0,8 0 0,9 0 1 0 1,1 0 1,25 0

P(bad) 0,8 0,75 0,75 0,75 0,69 0,59 0,48 0,35 0,2 0,1 0 0 0

P(good) 0 0,1 0,15 0,2 0,3 0,4 0,5 0,6 0,7 0,75 0,8 0,7 0,5

P(super) 0 0 0 0 0 0,01 0,02 0,05 0,1 0,15 0,2 0,3 0,5

Tabulka 2: Pravděpodobnostní rozdělení výnosů určené kvalitou.

5.6.5

Finance

Pojetí financí si klade za cíl upevňovat kategorie finančních toků a jejich povahu: provozní výdaje, investice, náklady na dluh, atd. Na závěr roku se ukazuje výsledková listina, které ukazuje přehled těchto finančních toků a srovnání s minulým rokem. Pojetí úvěru je zjednodušené na jednoroční půjčku. V případě nedostatku financí lze financovat provozní výdaje farmy za fixní sazbu. Na konci roku musí být půjčka splacena, jinak se musí rok opakovat znovu. Nádeníci jsou najímáni za mzdu a jídlo. Jako pracovní síla jsou ve srovnání s členy rodiny dražší. Musí být proto zapojeni do prací, které mají vysokou návratnost. Nechat je krmit drůbež nebo sbírat lesní plody by bylo ztrátové. 5.6.6

Scénáře

Hra je strukturovaná do scénářů definujících prostředí, postavy, podnebí, výchozí podmínky a cíl, který by měly být dosažen do několika let. Jiné situace vyžadují odlišné strategie. Je tím možné demonstrovat jaký rozdíl představuje riziko neúrody, výše mezd, úrokových sazeb a jiných nákladů. Hráč si musí experimentováním a vlastní úvahou vytvořit optimální strategii. Při tomto procesu si indukuje model vlivu těchto podmínek na hospodaření. Hlavním cílem scénáře je dosažení cílové hodnoty farmy. Expanze je tedy hlavním cílem a lze na ní doložit úspěšnost hráčovy strategie.

31

5.6.7

Čas

Rok je rozdělen na dvě stejně dlouhá období – jaro a léto. Jeden den je metaforou pro roční období. Čas hraje důležitou roli a pro hráče je takto lépe uchopitelný. Jedna herní hodina trvá 40 sekund reálného času. Čas lze zrychlit a období předčasně ukončit. 5.6.8

Odemykání obsahu

Plodiny, zvířata, recepty, dekorace a další objekty tvoří obsah, který je postupně dosahováním úrovní (rank) hráči zpřístupňován. Body pro odemknutí další úrovně jsou získávány především z prací, které mají nepřímou návratnost (např. přeorání pole, vymýcení políčka). Jedná se tak o vnější odměnu. 5.6.9

Ovládání

Vstupním zařízením je výhradně myš a při návrhu bylo přihlédnuto i k možnosti přenést hru na zařízení s dotykovým displayem. Klávesnice je použita pouze pro zkratky a vstup. Vlastní hra je rozdělena do několika režimů, mezi kterými se plynule přechází. Režimy určují způsob navigace v prostředí, skrývají nerelevantní objekty a mění grafické uživatelské rozhraní (dále GUI). • Manažerský režim – organizace práce • Plánovací režim – umisťování objektů • Stěhovací režim – přemisťování dobytka mezi ohradami • Dekorační režim – sázení kytek a aranžování dekorací • Přemisťovací režim – přemístění malých objektů (např. tác s jídlem) GUI herní obrazovky se skládá z ikon a panelů doplňující pohled na farmu, které se kontextově mění podle režimu. V dekoračním režimu je např. zastavený čas, tudíž jsou hodiny skryty. • Herní obrazovka – hodiny, panel, status, atp. • Katalog – výběr plodin, zvířat, stromů k zakoupení • Kuchařka – výběr jídel a stav vaření • Rozšíření domu – současná kapacita, cena rozšíření • Roční shrnutí – ekonomický výsledek, srovnání s minulým rokem

32

6 6.1

Implementace Cíle objektového návrhu

Projekt se snaží modelovat komplexní svět, kde má návrh význam pro logičtější uspořádání systému, odstranění redundancí a umožnění maximální rozšiřitelnosti a parametrizace. Při práci nad návrhem se budeme snažit identifikovat a aplikovat návrhové vzory z (Gamma a kol., 1994). Vzhledem k předchozí zkušenosti s herním vývojem mají řešitelé k dispozici i vlastní specifické návrhové vzory, které v projektu naleznou uplatnění. Vytvořený game design nebyl tak úplný, aby ho šlo použít k detailnímu návrhu systému. Takový postup není ani vhodný, vzhledem k nejistotám, zda budou některé prvky funkční. Funkčnost herních mechanismů sice lze dokázat prototypem, ale tato metodika je vhodná pro jednoduché hry. V případě komplexnějších projektů se vytváří protypy na jednotlivé části hry. Takový přístup ovšem nebyl možný vzhledem k časovým možnostem projektu. Východiskem je tedy maximální zachování flexibility a podchycení nejpodstatnějších herních objektů, které jsou v čase rozšiřovány. Při správném přístupu k návrhu systému by malé změny v game designu neměly vyvolávat rozsáhlé změny v implementaci.

6.2

Podpora data driven přístupu

Termín data driven označuje přístup vedoucí k oddělení funkční (algoritmické) a obsahové (datové) části aplikace, aby byl kód dobře udržovatelný a neobsahoval příliš specifických závislostí. Tento přístup je popsán v (DeLoura, 2000). Základním principem je oddělení výkonného kódu od závislostí na obsahu. Často nelze vystačit pouze se statickými daty a v tom případě se využívají skriptovací jazyky integrované do běhového prostředí. Integrování interpretru skriptovacího jazyka přináší výhody v rychlosti změn (není nutné překompilovat zdrojové kódy), možnému oddělení kompetencí (role programátora a designera) a rychlosti vývoje. Daní za to jsou značné komplikace při refaktorizacích. Kódová báze je hůře kontrolovatelná, protože skriptovací jazyky nejsou staticky typované a pro integraci se často vytváří rozhraní využívající řetězce (např. získávání objektů přes jeho jméno). Vzhledem k malé velikosti týmu, očekávání častých refaktorizací kvůli neúplnému zadání a náročnosti vytvoření dobrého vývojového prostředí pro ladění skriptů bylo upuštěno od integrace skriptovacího jazyka. Tuto funkci budou plnit specializované třídy, které budou implementovat logiku obsahu. Zůstává nutnost konfigurace a parametrizace. Řešení bude trojí pro každou kategorii dat: vlastní XML formáty pro objektová a neortogonální data a relační databáze nebo soubory pro tabulková data. V případě XML lze validovat schéma XSD šablonou, což zaručuje pouze formální správnost – dodržení schématu. Další kontrola je nutná při načítání. Schéma a konzistence je přímo vlastností používané relační databáze. Vynutit nebo zkontrolovat konzistenci těchto dat je tak snadné.

33

6.3

Datový model

Datový model lze zkonstruovat na základě entit, jejich atributů a vztahů, které se vyskytují v herním návrhu. Budeme takto modelovat statickou část dat, která je uložena v souborové databázi. Tyto data jsou určena pro řízení aplikační logiky a herní obsah. ERD zachycující úplný datový model je na obrázku 1. 6.3.1

Content

Databázová tabulka contents pokrývá společné vlastnosti herních objektů, které se umisťují na políčka. Neortogonální vlastnosti jsou v tabulkách vegetables, flowerbed props, livestock a yields, které obsahují atributy podtypů a jsou vázány 1:1. 6.3.2

Ranks

Hráč si zpřístupňuje obsah sbíráním bodů. Stupnice je stanovena touto tabulkou. Na id se odkazují entity, které jsou odemykatelné (contents, foods). Vazba vyjadřuje odemknutí dané entity na této úrovni. 6.3.3

Scenario

V databázi ukládáme pouze zástupné entity scénářů, které obsahují vazby na okolí. Detailní popis scénáře obsahuje množství neortogonálních atributů, což by nebylo praktické pro uložení v databázi. Tabulka scenario contents představuje mapování obsahu na scénář – definuje, které herní objekty budou ve scénáři dostupné.

6.4

Objektový návrh

V analýze budeme postupovat shora dolů. Již byly zmíněny použité komponenty pro vizualizaci, audio, práci s daty, atd. Ty bude nutné integrovat do jednoho systému. Prvotní dekompozice bude na systémovou část (integrace komponent), herní objekty, mechanismy a uživatelské rozhraní. Uživatelské rozhraní je v případě her velmi náročným subsystémem. Ze zkušenosti víme, že vzhledem k měnícím se podobám a herním situacím je kód týkající se uživatelské interakce často mnohonásobně objemnější než se čekalo. Bylo by vhodné dekomponovat vždy po vzoru model-viewcontroller. 6.4.1

Systémová část

Za systémovou část považujeme balík tříd, který zajišťuje inicializaci a běh aplikace. Řadíme sem především třídy jejichž životnost je spojena s životem celé aplikace. Kořenová třída AppRoot je singleton (vzor z (Gamma a kol., 1994)) instanciovaný ve vstupní funkci main(). Zde ji jsou předány parametry příkazové řádky a 34

Obrázek 1: ERD datového modelu.

35

Obrázek 2: Objektový diagram kompozice třídy AppRoot. spuštěna hlavní smyčka. Odpovědností třídy je inicializovat komponenty (OGRE3D, irrKlang), načíst soubory s konfigurací a daty pro herní logiku. Hlavní smyčka zpracovávající zprávy od operačního systému a aktualizující členy třídy je umístěna zde. Zjednodušený náhled na tuto kompozici tříd ukazujeme diagramem na obrázku 2. Řízení z hlavní smyčky je předáváno do instance třídy implementující jednoduché rozhraní Run prostřednictvím členské třídy RunManager. Konkrétní instance je zvolena na začátku (implicitně nastavenou lze změnit parametrem příkazového řádku). Motivací pro toto řešení je možnost rychle vytvářet různé menší aplikace a testy vrámci projektu bez psaní repetitivního kódu a nutnosti ho udržovat. Na nižší úrovni (běhu) lze instanciovat třídu SessionManager, která umožňuje řídit přechody mezi stavy sezení. Řízení pak předává aktivnímu stavu sezení (SessionState). Odvozené třídy implementují chování aplikace např. v hlavním menu a během hry. 6.4.2

Herní objekty

Herní objekty jsou třídy modelující entity herního světa. Řadíme sem i třídy vzoru builder, které slouží k jejich konfiguraci. Je ctěno pravidlo, že každý objekt má svého manažera, který je zodpovědný za životní cyklus objektu. Kořenovým objektem vlastnícím herní objekty skrze jejich manažery je Farm. Tato třída zároveň reprezentuje celkový stav herního sezení a je tak kořenem pro serializaci a následné obnovení. Sestavení a konfiguraci této třídy z XML souborů (scéna, 36

scénář) provádí FarmBuilder. Kompozice nejdůležitějších členů třídy je zachycena v diagramu na obrázku 3.

Obrázek 3: Objektový diagram kompozice třídy Farm (méně podstatné třídy byly vynechány). Statický herní svět je tvořen uskupením tříd Terrain, NavGraph, NavNode, FieldSet a Tile. Vybudování tohoto uskupení z XML souboru a hran statického modelu terénu provádí TerrainBuilder. Terén poskytuje informaci o výšce v bodě, obsahuje navigační graf používaný pro hledání cesty a strukturu herního světa – definovaná čtvercová políčka. TileContentManager spravuje objekty TileContent, které se rozkládají na terénu. Třída TileContentPlan představuje vazbu mezi Tile a TileContent, jelikož některé objekty se rozkládají na více polích (viz obr. 4). Jednotlivé objekty, které se vyskytují na farmě jsou odvozené třídy TileContent: Patch, Field, Corral, atd. Specifické objekty jsou vybudovány třídou TileContentFactory. CharacterManager vytváří a spravuje postavy – Character. Účelem této třídy je implementovat logiku přehrávání skeletárních animací a ovládání seskupení modelů, ze kterých se skládá postava (tělo, hlava, vlasy). Hráčem ovladatelní pracovníci jsou reprezentováni třídou Worker (viz obr. 5), která spojuje vlastnosti a stav postavy (CharacterTraits), její vizualizaci (Character) a současnou náplň práce (WorkerAssignment). Spolu s Workplace jsou instance spravovány třídou WorkManager. Cílem bylo maximálně oddělit postavy od předmětu činnosti, tak aby byl velký prostor pro přidávání dalších prací a činností. Workplace poskytuje informace o umístění, počtu pracovníků a aktuální práci (Job). Naplňuje tak v tomto smyslu návrhový vzor mediator. Změny předmětu práce na průběh činnosti, příchozí/odchozí pracovníky, apod. jsou oznamovány prostřednictvím rozhraní WorkplaceListener. 37

Obrázek 4: Objektový diagram tříd postavených na tilech. Konkrétní práce, kterou postavy vykonávají představuje instance třídy Job, která se skládá z dílčích činností Activity. Aktivita je umístěná (ActivitySpot), nepřerušitelná akce jedné postavy s animacemi a průběhem definovaným v ActivityTypeInfo. Činnosti lze eventuálně seskupit do skupin (ActivityGroup), což má význam především na vyšší úrovni. Různé přemistitelné nebo klikatelné objekty jsou souhrně označovány jako prop (např. stůl, tác s jídlem, kolébka, atd.). Tyto herní objekty jsou používány v různých kontextech a poskytují minimální různou úroveň funkcionality. Byl navržen jednotný způsob jejich vytváření a konfigurace, aby se zamezilo redundantnímu kódu. Definice těchto objektů je uložena v databázi (soubor s modelem, akční body, jméno controlleru, atd.). PropManager spravuje obejekty typu Prop, které jsou vytvářeny kompozicí z jednotlivých implementací PropController a pokud jsou interaktivní obsahují PropActiveEntity. Building reprezentuje dům, který se skládá z několika částí a může být stavební prací rozšířen. Hráč může dekorovat záhony (FlowerBed) spravované třídou FlowerBedManager. Jsou to předpřipravené oblasti s pravidelně rozmístěnými body (FlowerSpot), na které lze umístit kytku nebo dekoraci (Flower). Další třídy tohoto balíku nejsou podstatné pro pochopení systému. 6.4.3

Herní mechanismy

Balík s herními mechanismy lze dále dekomponovat na třídy obsahující statická data, celkový stav, chování systému a výpočty výsledků akcí. 38

Obrázek 5: Rozhraní implementované třídou Worker a její kompozice. GameDesignData je singleton, který seskupuje obecná herní data načtená z různých zdrojů. V XML jsou definované aktivity (ActivityTypeInfo). Ze souborové databáze jsou prostřednictvím třídy ContentDbLoader načteny tzv. obsahová data – parametry herních objektů, které vystupují v katalogu (ContentTypeInfo, FoodTypeInfo), atd.) nebo jsou nutné k vytváření objektů (PropTypeInfo). Parametry pro výpočty herních pravidel jsou uloženy ve formátu Microsoft Excel 2003, který je poměrně stručným XML dialektem, aby mohla být prohlížena tabulkovým editorem. Jednotlivé tabulky jsou načítány jednoúčelovými třídami implementující rozhraní RuleTableFeeder, které jsou vytvářeny tovární metodou na základě nalezeného jména tabulky při procházení dokumentu. Třída RuleTables pak poskytuje pohodlné rozhraní k tabulkovým datům, kdy jednotlivé řádky jsou buď struktury (JobAttribs) nebo skalární hodnoty. Scénář určuje nastavení, výchozí podmínky a cíle herní epizody. Je definován v XML a načte se jako třída Scenario Stav a řízení událostí scénáře je úlohou třídy ScenarioState. Některé hodnoty vlastností jsou přenositelné mezi scénáři, ty jsou součástí profilu (Profile). Vykonávání akcí scénáře, tedy vlastní operace nad herními objekty byly delegovány na rozhraní ScenarioExecutor. Důvodem byla snaha o systémově čisté třídy bez specifických řešení. V tomto případě by právě nastupoval skriptovací jazyk. Výpočty používané na různých místech kódu jsou soustředěny jako statické metody třídy GameRules. Tato centralizace kódu částečně nahrazuje absenci skriptování vzhledem k tomu, že čas k rekompilaci v případě změny vzorce je malý. 39

6.4.4

Uživatelské rozhraní

OGRE3D poskytuje jen velmi základní prostředky pro tvorbu 2D uživatelského rozhraní (GUI) překrývající 3D pohled. Navrhnuté řešení dělí prostředky pro tvorbu uživatelského rozhraní do tří úrovní. Jako celek pak tvoří view z návrhového vzoru model-view-controller. V případě návrhu tohoto subsystému jsme vycházeli z praktické zkušenosti a nechali se inspirovat architekturou dosud poznaných GUI knihoven a frameworků. Základní úroveň GUI jsme umístili do samostatného jmenného prostoru, protože se jedná o samostatnou a obecnou část projektu. Základní třídou je GuiPlatform. Zobrazované prvky jsou seskupeny do vrstev Layer, které určují pořadí vykreslovaní a tedy překrývání. Všechny vykreslované prvky jsou potomkem třídy Element, která obsahuje jméno, prostorovou transformaci, referenci na předka a další základní atributy. Elementy tvoří stromovou strukturu, která slouží k zřetězení transformací a překrytí hodnot atributů (skrytí rodiče se přenáší i na potomky). Specializované třídy TextElement a PictureElement pak implementují vykreslení textu a textur (viz obr. 6).

Obrázek 6: Bázová třída Element a její specializace. Funkční prvky uživatelského rozhraní jsou tvořeny na vyšší vrstvě. Základní Třídou je Control, který přijímá události od vstupních zařízení. Implementované prvky jsou tlačítko Button, vstupní textové pole TextBox a záložka Tab. Kontajnerem těchto prvků je Widget (okno, panel), který zároveň představuje vazbu s nižší úrovní přes kořenový element. Implementace chování specifických oken v potomcích vyžaduje programově navázání (bind) prvků nižší vstvy a vytvoření funkčních prvků. WidgetManager spravuje instance takto vytvořených kontajnerů,

40

které jsou vybudovány ihned po načtení z XML souboru. Tuto činnost provádí třída InterfaceBuilder. Uživatelské rozhraní je tedy předpřipravené na základní úrovni.

Obrázek 7: Třída okna Widget a její kompozice. Uživatelské rozhraní u tak rozsáhlého projektu je z hlediska množství kódu velmi objemné a vysoká provázanost s aplikační logikou by znesnadnila údržbu kódu a refaktorizace. Z toho důvodu bylo cílem oddělit reprezentaci (view) od logiky. Toho bylo dosaženo prostřednictvím tříd odvozených od UIActivity, které představují model a controller vzoru model-view-controller. Widget dostává při aktivaci přidělenu instanci UIActivity, kterou si přetypuje na specifický typ. Konkrétní třída pak obsahuje reference na potřebné herní objekty a její metody zapouzdřují akce. Formátování textových řetězců, transformace na zástupné objekty a další logika za uživatelským rozhraním je tak umístěna zde. Tato mezivrstva představuje marginální výkonovou a pracovní režii, přitom umožňuje jasnější organizaci kódu. Nápověda, která se objevuje u kurzoru je řešena spoluprácí základních tříd HintBubble a HintProvider od kterých jsou odvozovány specifické implementace. Také v tomto případě je oddělen model od reprezentace, ovšem z jiného důvodu. Rozhraní odvozená od HintProvider jsou často implementována aktivními objekty, které tak ukazují svůj stav. Součástí uživatelského rozhraní jsou i herní objekty zasazené do 3D scény. Uživatel pohybem kurzoru přes objekt a klikem vyvolává události, které jsou předávány. Tyto objekty implementují třídu ActiveEntity. Podoba uživatelského rozhraní se při hře mění podle kontextu a tím i význam akcí nebo dostupné možnosti. Jednotlivé stavy rozhraní jsou implementovány jako potomci ToolMode (viz obr. 8). Uživatel plánuje plodiny PlanTool, organizuje postavy ManagerTool, dekoruje záhony FlowerTool nebo přemisťuje zvířáta MoveTool. Při aktivaci stavu se ukazují příslušné widgety, nastavují filtry na ActiveEntity a při deaktivaci skrývají.

41

Obrázek 8: Rozhraní ToolMode a jeho implementace.

6.5

Produkce herního obsahu

Termínem obsah je označována část aplikace spočívající v datech. Jsou to jak modely, animace, zvuky, tak i soubory řídící herní logiku (zmíněný data-driven přístup). Právě těm se budeme věnovat v následující kapitole. Obsahová data parametrizující herní mechanismy by se dala rozdělit na dvě skupiny – statická herní pravidla a databázi popisující herní objekty jejichž kvantita není omezena. 6.5.1

Audiovizuální data

O produkci audiovizuálního obsahu už bylo pojednáno v souvislosti s výběrem technologií v sekci 5.5. Aplikace používané k produkci dat této povahy nejsou součásti systému a při běhu jsou načítány až konečné formáty. V OGRE3D jsou označovány souhrně jakou resource. Konfiguračním souborem se určují adresáře a komprimované soubory formátu ZIP, kde jsou resource soubory vyhledávány. Po startu jsou zaregistrovány a inicializovány (parsování materiálových a efektových skriptů). Důvodem této organizace je flexibilita (dohledatelnost pomocí jména – nezávislost na fyzickém umístění). Finální sestavení aplikace obsahuje většinu souborů v komprimovaných balících, které se z pevného disku snáze načítají. Důvodem je využití vlastnosti souborových systémů, které se zpravidla snaží držet jeden soubor v blocích za sebou a v případě pevných disků tak nedochází k častému přemisťování hlavy, což je nutné v případě mnoha malých souborů. Snížení doby načítání bylo cca trojnásobné. Tento faktor lze brát pouze jako orientační, protože se bude lišit v závislosti na fragmentaci disku, operačním systému, parametrech pevného disku a mnoha jiných vlivech. Nutno dodat, že pro NAND paměť používanou jako úložiště v mobilních zařízeních bude tato optimalizace přístupový čas zvyšovat pouze marginálně.

42

6.5.2

Pravidla

Algoritmy herních mechanismů obsahují vzorce parametrizované tabulkovými hodnotami. Tyto tabulky označujeme termínem pravidla pro vnější podobnost s pravidly deskových her. Pro uložení tabulek byl zvolen formát Microsoft Excel 2003 a soubor tak lze editovat tabulkovým editorem. Forma byla zvolena vzhledem k přehlednosti a snadnosti editovat data. V prostoru mimo tabulky mohou být umístěny komentáře a kontrolní výpočty, které nejsou načítány. Editace je rychlejší než v případě uložení do souborové databáze. Tyto tabulky byly vytvořeny jako součást designu před započetím vývoje. Hodnoty v nich uvedené šlo určit dopředu pouze reprezentativně odhadem. Během vývoje a především ve fázi balancování hratelnosti se hodnoty měnily. Rozhodně však ne v takové míře jako data v souborové databázi. Svou roli zde sehrály malé domény atributů (např. práce může být lehká, středně, velmi těžká) nebo počet řádků tabulek (např. schopnosti mají jen sedm úrovní). Pravidla představují základní mechanismy, a proto byla jednoduchost a stabilita důležitá. Přirozeně platí, že i malé zásahy do hodnot těchto tabulek mohou mít velké důsledky pro herní systém. V příloze uvádíme nejdůležitější tabulky popisující herní pravidla. 6.5.3

Datový obsah

Pro reprezentaci dat byl zvolen relační model, který umožňuje udržovat konzistenci relací mezi objekty a standardizovanou manipulaci s daty. Zvolená souborová databáze SQLite nepodporuje referenční integritu jako takovou, ale umožňuje ji snadno přidat, kde je požadována (omezení CHECK nebo kontrola vrámci trigger funkce). Práce s databází byla prováděna prostřednictvím konzolového programu sqlite3, grafickými aplikacemi (SQLite Database Browser20 ) nebo pomocí vlastního specializovaného nástroje. Cílem bylo zvolit správné množství obsahu v každé kategorii a jednotlivé objekty od sebe odlišit zajímavými vlastnostmi modelujícími realitu jako jsou silné a slabé stránky. Pro hráče tak např. volba plodin, které vysadí, představuje rozložení rizika. Některé plodiny by měly být extrémně závislé na počasí s vysokými výnosy v případě dobrých podmínek a katastrofálními v opačném případě, apod. Vážným nedostatkem je tzv. rozbití hry, kdy hráč odhalí postup, který mu opakovaně a s jistotou přináší výhodu s minimem nákladů nebo rizika. • Recepty: 16× • Druhy zeleniny: 16× • Plemena dobytka: 27× • Dekorace: 20× • Květiny: 20× • Ovocné stromy: 10× • Polní plodiny: 8× • Drůbež: 9× 20

http://sqlitebrowser.sourceforge.net

43

Pro analýzu hodnot atributů byly vytvořeny databázové pohledy, nad kterými by teoreticky šlo pracovat, protože materializované pohledy jsou v SQLite umožněny prostřednictvím trigger funkce, ale tuto funkcionalitu nepodporovaly uvedené grafické aplikace (považují pohledy za neměnné). Použití databázových pohledů bylo nevyhnutelné, protože umožňují požadovanou perspektivu na data. Provádět změny pomocí SQL dotazů na základě zjištění z pohledů je zdlouhavé. Bylo nutno vytvořit nástroj umožňující efektivně vykonávat specifické úlohy. • uspořádání objektů – na každé úrovni se odemknou 3–4 objekty (plodina, recept, plemeno, apod.) • balancování plodin – balancování vlastností plodin a jejich výnosů (zajímavé odlišnosti) • scénáře – povolené položky ve scénářích (plodiny, zvířata) Aplikace byla implementována v jazyce Python s využitím modulu CherryPy21 a pomocné JavaScriptové knihovny jQuery22 jako webová aplikace. CherryPy obsahuje vlastní HTTP server, tudíž je aplikace spustitelná lokálně a využívá webového prohlížeče pro grafické rozhraní. Podařilo se tak dobře oddělit logiku aplikace od prezentační vrstvy a díky zvolenému jazyku se v minimálním čase implementoval modulární a snadno udržovatelný nástroj. 6.5.4

Scénáře

Scénáře představují konkrétní příběh, který hráč rozvíjí. Scénář je vázán na konkrétní model terénu. Jeden model prostředí je tak možno použít vícekrát vrámci několika scénářů obměňujících detaily. Scénáře jsou definovány v XML a částečně v databázi (povolené plodiny a zvířata). XML bylo zvoleno pro množství objektových dat a možnost ruční editace. Uvádíme výčet atributů scénáře, které je nutné nastavit se stručným popisem. • Oblasti v terénu – zda jsou zalesněné, počáteční úrodnost • Dům – model domu, cena rozšiřování • Postavy – výchozí postavy (podoba, talenty, úroveň schopností) • Hotovost – stav konta na startu • Počasí – množství slunných, oblačných a deštivých období • Cena pracovní síly – náklady na najmutí nádeníka • Cíl – typicky valuace farmy • Časový limit – maximální počet let do splnění cíle

6.6

Organizace projektu

Vývoj probíhal v týmovém prostředí, což bylo nutné podpořit nástroji, centralizovanými službami a datovými úložišti. Volba konkrétních řešení vychází z požadavků týmu, kde se jen velmi málo překrývají práce na jediném zdroji. 21 22

http://www.cherrypy.org http://jquery.com

44

6.6.1

Verzovací systém

Jako verzovací systém pro zdrojové kódy a data byl zvolen Subversion23 . Je vhodný pro malé týmy a obecné použití. Jedná se o open source projekt, tudíž lze těžit z jeho podpory v jiných otevřených systémech. Na pracovních stanicích byla nasazena klientská aplikace TortoiseSVN. Repository obsahuje zdrojové kódy a data v oddělených adresářích s podadresáři Trunk, Branches a Tags. Aktivní vývoj probíhá v Trunk, kam přispívají změnami všichni členové týmu. Branches slouží pro oddělené větve, které je nutno udržovat. V našem případě jde o atypické verze, které se v některých aspektech odchylují od kořenové, a je nutné je dále aktualizovat. Tags slouží pro pojmenované revize, např. milníky. Verzovací systémy jsou primárně postavené pro spravování verzí textových souborů (typicky zdrojových kódů). Konflikt v případě slučování dvou verzí souboru nastává v případě, kdy byl v obou verzích měněn stejný řádek. Kromě textových dat bylo nutné verzovat i binární a XML data. XML je textový formát, ale některé aplikace ukládají data ve zhuštěné formě, kdy je na jednom řádku více elementů. Je tedy nutné v aplikacích nastavit způsob ukládání po řádku nebo takové soubory před vstupem do verzovacího systému transformovat. V opačném případě jsou konflikty časté a tato místa v souborech se musí slučovat ručně. Binární soubory jsou pochopitelně neslučitelné a není tedy možné, aby probíhala současně práce na jednom souboru. To byl problém v případě souborové databáze, u které bylo třeba umožnit souběžné změny. Aplikované řešení spočívalo ve využití funkce TortoiseSVN – automatického spuštění uživatelského skriptu při události. Pomocí konzolového programu sqlite3 se příslušnými parametry provedl tzv. dump databáze do formy skriptu jazyka SQL, který je textový a tedy slučitelný. Po skončení procesu aktualizace lokálních dat se opět automaticky spustil skript a uložil databázi do binární podoby. 6.6.2

Správa požadavků

Požadavky vzniklé plánováním nebo hlášením o chybách byly spravovány v systému Trac24 určenému pro management software projektů. Trac je modulární systém webových aplikací v jazyce Python. Integrovali jsme jej se Subversion repository, takže zde bylo možné sledovat změny v zdrojových kódech v souvislosti s požadavky. 6.6.3

Sdílení dokumentů

Dokumenty ukládané jako soubory byly součástí repository. K opravdovému sdílení dokumentů, u kterých je nutno pohled více stran (např. plánování) byla použita webová služba Google Docs. Jako nástěnka pro trvalé odkazy na zdroje a pracovní postupy byl využíván wiki modul systému Trac. 23 24

http://www.subversion.org http://trac.edgewall.org

45

6.7

Automatizace procesů

K automatizaci některých procesů bylo nutné přistoupit zejména pro úsporu času. Bylo nutné, aby mohl mít kdokoliv k dispozici zkompilovanou aplikaci z nejaktuálnějších zdrojových kódů, která je otestovaná alespoň na úrovni základní funkcionality. Ostatním zapojeným stranám je hra distribuována v balíku, do kterého je nutné dát jen vybraná data, zvláštní konfigurační soubory, apod. 6.7.1

Automatický build projektu

Do systému Trac byl integrován také modul Bitten, který je určený na automatizované úlohy prováděné na základě XML souboru s akcemi. Ve své podstatě se jedná o zjednodušený MS Build. Na dedikovaném stroji byl spuštěn slave proces, který pravidelně sleduje zda nebyla změněna revize zdrojových kódů. Pokud tak nastane, aktualizuje si zdrojové kódy, spustí kompilaci a případně testy. Při úspěchu posílá spustitelný soubor na repository. Sestavování balíků určených pro distribuci vyžaduje vyexportování dat z repository, komprimaci souborů s médii a transfer výsledného souboru na server v prostředí Internetu. Tato úloha je časově náročná, proto se prováděla až po ustálení revize (číslo revize se nezměnilo několik desítek minut) až nakonec byla spouštěna manuálně, vzhledem k vysokému zatěžování sítě. 6.7.2

Automatické testování

Testovat složité interaktivní aplikace není dobře možné pomocí unit testů. Není možné dobře rozdělit aplikaci na omezené moduly a také nelze tímto způsobem testovat uživatelské rozhraní. Právě uživatelské rozhraní je nutné testovat, protože velká míra systémové komplexity je umístěna zde. Řešení problému testování spočívalo v přidané funkcionalitě – záznam uživatelských akcí do souboru a možnost spustit aplikaci s tímto záznamem. Bylo nutné vyřešit determinismus, který je porušen použitím náhodných čísel (musí se shodně inicializovat generátor náhodných čísel) a časování (kolísání počtu snímků za sekundu). Tyto testy bylo nutné nahrazovat v případě změn a jejich užitečnost byla – jak vývoj postupoval – nízká. Nemohly posloužit na odhalení chyb, které jsou vidět jen lidským okem. Z procesu kontroly zkompilovaného souboru byly posléze vyřazeny.

46

7

Zhodnocení

V této kapitole zhodnotíme jak naše řešení vyhovuje požadavkům. Dále budeme hodnotit návrh a implementaci našeho řešení vzhledem k objektivně posouditelným vlastnostem. Zhodnotíme i přínos použitých technologií.

7.1

Naplnění požadavků

Dle našeho názoru naše řešení vyhovuje všem stanoveným požadavkům specifikovaným v sekci 5.1. Vytvořený herní systém může být nasazen jako motivační aktivita pro výuku finanční gramotnosti. 7.1.1

Game design

Game design celkově splnil požadavky stanovené v sekci 5.1. Hra představuje komplexní systém s vnitřními i vnějšími odměnami a při selhání se opakuje jen poslední rok Abychom se snadněji dostali do tohoto stavu, bylo vhodné vybudovat alespoň dílčí prototyp omezený jen na jeden uživatelský režim. Přínos prototypu manažerského režimu, který by umožňoval testovat časování (vhodnou délku provádění činností) a kvantity (ovládáním kolika postav je hráč plně zaměstnán), by byl značný. Získaly by se znalosti, které by pomohly spíše v procesu vývoje než v návrhu. Tyto zkušenosti by pomohly lépe zaměřit úsilí v počátečních fázích vývoje. Nutno dodat, že volba prototypem řešených prvků je diskutována ex post. 7.1.2

Architektura software

Požadavek snadno rozšiřitelného obsahu byl splněn použitím data driven přístupu: lze vytvářet nové scénáře, parametrizovat obsah specializovanými nástroji, přidávat nové objekty, lokalizovat texty, apod. Je ale třeba přiznat i nedostatky, které snížily potenciál projektu nebo by byly předmětem budoucích refaktorizací. Jedním z nedostatků objektového návrhu je nedostatečné vyvarování se tzv. world modellingu. Jedná se o zásadu nepromítat příliš těsně game design do objektového návrhu. Game design je jiné paradigma a malá změna tak může způsobit nutnost velkých zásahů do architektury systému. V případě projektu jsou zbytečně oddělené některé herní objekty jako odlišné, ale přitom mohly sdílet společný základ a být konfigurovány kompozicí. Negativním důsledkem je redundantní kód a snížení budoucího potenciálu kódové báze projektu. Vzhledem k modelovanému prostředí plného živých objektů by bylo vhodné implementovat emergent behaviour25 , kde je to možné, což se dělá těžko při vysoké specializaci tříd. Chování postav řešené třídami odvozenými od WorkerAssignment a ostatními spolupracujícími třídami není dostatečně flexibilní. Některé prvky funkcionality 25

Vzory komplexního chování postavené na jednoduchých pravidlech interakcí agentů systému.

47

musely být navržené v reakci na vzniklé vyjímky, které bylo nutné pokrýt. V průběhu vývoje jsme se pokusili dekomponovat chování postav dále na WorkerTask, čímž se snížila redundance kódu v jednotlivých implementacích WorkerAssignment. V kompilovaném jazyku jakým je C++ je nutno brát v potaz i kompilační čas. Pro sestavení celého projektu je třeba několik minut. Tento čas lze ovšem uspořit využitím oddělené kompilace. Důležitou roli pak hrají závislosti mezi soubory a tedy vkládání hlavičkových souborů. Velmi často vkládanou hlavičkou je např. ScenarioState.h obsahující deklaraci důležité a často modifikované třídy. Volající kód ji využívá k notifikacím nebo pozměnění stavu scénáře. Tyto metody lze vymezit jako omezené rozhraní a implementovat ho. 7.1.3

Minimální hardware konfigurace

Požadavek na toleranci staršího hardware používaného na školách jsme museli splnit kompromisem. Pravděpodobně se ve školách stále používají PC sestavy, které budou nevyhovující, ale zároveň je třeba myslet na životnost projektu a možné snížení atraktivity na základě těchto omezení. Nároky na systémovou paměť jsou nejlépe kvantifikovatelným požadavkem. Dle našeho názoru jsou tyto nároky poměrně nízké ve srovnání se současnými hrami. Přidělená paměť aplikaci se pohybuje v pásmu 150–200 MB. PC s minimální konfigurací by tedy mělo mít alespoň 256 MB, nejlépe však 512 MB RAM. Nejmíň výkonné CPU, na kterém byla hra testována je Intel Atom s kódovým označením Pineview (1,66 GHz, 512 KB L2 cache). Výkon tohoto mobilního CPU je srovnatelný s generacemi řešení pro stolní počítače uváděných na trh těsně po roce 2000. Klíčovou komponentou nutnou k provozu aplikace je grafická karta s GPU podporujícím shader model 2.0, což je standard podporovaný grafickými kartami od roku 2002. Nutno dodat, že nejstarší GPU s tímto standardem nemají dostatečný výkon. Bohužel neexistuje jednoznačný ukazatel a v praxi se uvádějí nejnižší možné řady jednotlivých výrobců. V našem případě to je nVidia GeForce řady 6000 a ATi Radeon X800 (obě uvedeny na trh v roce 2004). Nižší řady nebyly testovány.

7.2

Zhodnocení přínosu použitých technologií

Zvolené technologie a knihovny byly integrovány bez zásadních problémů. Zhodnotíme jejich přínosy i slabé stránky. 7.2.1

OGRE3D

Mezi nejsilnější stránky OGRE3D patří rozsáhlost funkcionality, kterou obsahuje. Rozhraní poskytuje vysokou úroveň abstrakce od implementovaných problémů, takže programování bylo efektivní. Engine se skládá ze subsystémů, což umožňuje

48

dobrou orientaci a eventuální nahraditelnost některých částí (scene manager, pluginy). Již bylo zmíněno řešení resource managementu, které je umožňuje flexibilní organizaci dat a rychlý přístup za běhu. Nepostradatelnou součástí se staly projekty OGRE3D komunity, které jsme v podobě aplikací nebo plug-inů využívali. Tyto produkty jsou zdarma nebo za zanedbatelnou cenu, nicméně se musí podrobit zevrubné evaluaci. Nemalá část projektů obsahuje jen základní funkcionalitu, postrádá stabilitu a ve vývoji již nikdo nepokračuje. Kvalitou provedení určitě vystupuje Particle Universe26 – plug-in pro částicové systémy, který je dodáván s vizuálním editorem umožňujícím velmi efektivní modelování těchto efektů. Byl jím nahrazen standardní částicový subsystém, kde se musí ručně editovat textové soubory se skripty. Mezi nedostatky by se dalo započítat řešení geometry instancingu – shluknutí dočasně statických objektů do jedné dávky, čímž se snižuje režie přechodu mezi souvislou činností GPU (musí se změnit transformační matice, textura, atd.). Implementované řešení není příliš sofistikované. Lze shluknout objekty jen se stejným materiálem bez skeletárních animací a neumožňuje je snadno zase rozdělit. Bylo nutné vytvořit vrstvu spravující shluky instancovaných objektů a výsledek není tak optimální, jak by mohl být. Funkcionalita engine jde nad rámec 3D vizualizace a obsahuje i zajištění proti chybnému uvolňování paměti. Na to jsou bohužel použity různé alokátory paměti a memory tracker v případě zachycení této chyby nedodává dostatečné informace (pouze jméno třídy). 7.2.2

SQLite

SQLite usnadnilo manipulaci s relačními daty, které byly stále v jediném formátu. Umožnilo bez konverzí přecházet mezi různými nástroji, což se ukázalo jako velmi efektivní. Verzování databázového souboru bylo bezproblémové. Ke konfliktům docházelo velmi zřídka. Alternativním řešením by bylo použít centralizovanou databázi a data z ní pro použití v aplikaci exportovat. Použití souborové databáze, právě díky přímočarému způsobu verzování, toto řešení výhodami převyšuje. 7.2.3

irrKlang

Zvuková knihovna irrKlang, implementuje nezávislost na platformě využíváním specifických API. V budoucnu bude pro audio prosazovat jako standard nízkoúrovňové rozhraní OpenAL, přítomné na všech operačních systémech a platformách. V současné době se ještě vyskytují problémy s jeho implementací a není podporováno všemi výrobci audio hardware. Pro budoucí projekt bychom spíše zvážili vlastní nebo cizí řešení postavené na OpenAL. Samozřejmě bude stále platit, že knihovna irrKlang se velmi snadno 26

http://fxpression.com

49

integruje a rozhraní postavené na referenčním čítání odkazů usnadňuje spravování životnosti zvukových objektů.

7.3

Produkce obsahu

Vytvořený obsah (modely, animace, scény) je přesný a realistický. Detailnost přidává na vizuální kvalitě, byla ovšem i přítěží a vynucovala omezená nebo nadmíru komplikovaná řešení. Herní svět je statický, předpřipravený a výroba scénářů je tak poměrně náročná a nelze ji delegovat na méně zkušené vývojáře. Alternativní řešení by bylo vytvořit si editor, který by umožnil vytvářet nový obsah i hráčům. Prekvizitou je ovšem jednodušší obsah.

50

8

Diskuze

Aplikace nových médií do výuky se děje postupně a nenucenou formou, často vlastní iniciativou učitelů. Zastánci konstruktionistického přístupu k učení kladou důraz na pochopení reality skrze tvorbu artefaktů, ale prostředky, které učitelům nabízí, se v současném stavu nemohou příliš rozšířit. Vyžadují znalosti jiných disciplín a jejich použití ve výuce je komplikované. Naproti tomu hry jsou mnohem vhodnější pro širší rozšíření – mohou obsahovat komplexní systémy a přitom pracují se srozumitelnými metaforami, jsou uživatelsky přívětivé a motivují k hraní. Dá se předpokládat, že je učitelé začnou sami používat, protože se začnou objevovat tituly, které k tomu budou vhodné. Jejich kvalita bude patrně velmi vysoká. Komerční hry, které již prokázaly svůj přínos, patří ke špičce ve svých žánrech. Pro návrh a implementaci byly důležitými zdroji jak vědecké práce, tak myšlenky aktivních profesionálů v herním odvětví. Shledáváme, že výzkumné práce se z velké části zaobírají popisovaním aspektů média a experimentují s hotovými produkty v různých kontextech. Představu o budoucí podobě a možnostech média lze lépe získat od samotných tvůrců. Naše řešení je hrou na hospodaření, která byla vytvářena podle nejlepších zásad média. Má výukový přesah v tom, jaké mentální modely upevňuje. Finanční toky jsou dohledatelné a kategorizované. Význam talentů, schopností, únavy a dalších životních reálií propojuje lidské zdroje a pracovní prostředí v jeden celek. Pokud bychom rádi někoho naučili, „ jak vyjít s penězi,ÿ je hospodaření na farmě nejlepším modelem. Představa je sdílená (každý ví z čeho farma sestává) a nevyvolává nevhodné diskuze o výši příjmů rodičů. Osnovy finační gramotnosti dle našeho názoru kladou příliš důraz na konkrétní dovednosti související se správou financí a finačními produkty. Tyto dovednosti jsou pro žáky základních škol ještě dlouho nepoužitelné. Považujeme za přínosné doplnit učební materiály aktivitou, která poskytuje jinou perspektivu. Pohled z jiného úhlu či role je hrám vlastní a místo učitele je právě zde – při procesu interpretace.

8.1

Srovnání s alternativami

Budeme srovnávat naše řešení s tituly, které by se prakticky nebo teoreticky daly aplikovat ve výuce finační gramotnosti. 8.1.1

Moje Familie

Výuková hra Moje Familie27 (Enteron pro OVB, 2010) dle našeho názoru objektivně selhává v naplnění svého cíle podpořit výuku finační gramotnosti. Design si klade za cíl modelovat finance v domácnosti, ale příliš rychle abstrahuje od reality do několika málo uživatelských akcí a finančních toků (jídlo, nákup skateboardu, 27

http://www.mojefamilie.cz

51

pobyt v lázních, atd.). Herní mechanismy tak nepředstavují stabilní systém odrážejíci realitu, což si hráč uvědomí po několika akcích a následné konsekvence nepůsobí reálně. Nejzávažnějším problémem je absence prvků ostatních disciplín (finanční matematika, ekonomie). Finanční gramotnost je tak redukována na rozdíl součtu účtů a příjmů. 8.1.2

The Sims

V současné produkci lze najít jen jedinou předlohu herního systému, který představuje zábavnou simulaci reálného života a obsahuje i finanční stránku domácnosti a tou je série The Sims (Electronic Arts, 2000–2010). Hráč se stará o potřeby svých postav, vybavuje byt, dohlíží na plnění povinností, apod. Stejně jako v případě hry Moje Familie je problém příliš triviální pojetí financí. Postavy chodí do práce, aby mohly nakupovat a tím je koloběh peněz uzavřen. Dále hra dává velkou volnost v směřování života postav, což je v tomto případě spíše na škodu a pro učitele by bylo obtížné dosáhnout užitečnosti této herní aktivity. 8.1.3

SimCity

Urbanistická simulace SimCity je jako hra velmi vzdálená našemu řešení. Jak bylo řečeno v sekci 2.1.4, vzhledem k svým přednostem ji učitelé řadí mezi nejpoužívanější hry. Jako aktivita pro podporu výuky finanční gramotnosti ji dle našeho názoru nelze doporučit. Sledujeme zde ekonomický rozvoj města na makro úrovni, což je už příliš vzdálené finanční povaze domácnosti. Další nevýhodou je neohraničenost obsahu a hraní s otevřeným koncem. V našem řešení jsou krátké i dlouhé scénáře s jasně určenými cíly. Učitel tak může stanovit cíle a naplánovat hrací dobu.

52

9

Závěr

Cílem práce bylo navrhnout a implementovat interaktivní aplikaci zaměřenou na výuku hospodaření a řízení lidských zdrojů. Kladli jsme si za cíl, aby mohlo naše řešení posloužit pro podporu výuky finanční gramotnosti. Práci jsme zahájili studiem dostupných zdrojů zabývajících se problematikou aplikace nových médií ve výuce. Dále jsme nastudovali teoretické práce zaměřené na interaktivní média a počítačové hry, které nám přinesly vhled do vlastností média a specifik vývoje těchto aplikací. Analyzovali jsme jednotlivé kategorie nových médií a vybrali jsme počítačové hry jako nejvhodnější pro naplnění cíle. Z analýzy vyplynuly požadavky, které jsme pak objektivně specifikovali v návrhu našeho řešení. Při koncepci jsme zvolili vhodné herní mechanismy a technické řešení ze znalosti aktuálních trendů v herním průmyslu. Pro technické řešení projektu jsme evaluovali framework řešení, která se ukázala jako nevhodná. Byla navržena architektura vlastního herního engine, pro který jsme vybírali komponenty k integraci. Rámcový game design byl k dispozici v podobě tabulek a vzorců od začátku vývoje, ale až během jednotlivých iterací byl herní systém dopracován. Implementaci jsme zahájili datovým a objektovým modelováním systému. V průběhu vývoje bylo nutné zajistit služby pro týmovou spolupráci a integraci nástrojů použitých při produkci herního obsahu. Postupy použité v této části jsou lehce přenositelné i do obecného vývoje aplikací. Navržené řešení bylo úspěšně implementováno a vyhovuje požadavkům specifikovaným v návrhu. Vývoj na projektu bude pokračovat i v budoucnu. Vytvořená aplikace může být nasazena jako aktivita při výuce finanční gramotnosti. Srovnávali jsme naše řešení s alternativními aplikacemi, které se nyní učitelům nabízí a dle našeho názoru je naše řešení nejvhodnější. Cíl práce tedy považujeme za úspěšně splněný.

53

10

Reference

Bober, M. Games-Based experiences for learning Bristol: Futurelab, 2010. Bjork, S. a Holopainen, J. Patterns in Game Design. Charles River Media, 2005. ISBN 1-58450-354-8. DeLoura, M. (ed.) Game Programming Gems. Charles River Media, 2000. 600 s. ISBN 15-8450-049-2. Eriksson H. a Penker, M. Business Modeling with UML : Business Patterns at Work. New York: John Wiley & Sons, 2000. 19 s. ISBN 0-471-29551-5. Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, 2004. ISBN 0-321-19368-7. Gamma, E. a kol. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. 416 s. ISBN 02-0163-361-2. Harel, I. a Papert, S. Constructionism. Ablex Publishing, 1991. 518 s. ISBN 08-9391-786-9. Huizinga, J. Homo ludens; A Study of the Play-element in Culture. Boston: Beacon Press, 1955. ISBN 97-8080-704-681-4. Kadlec, V. Agilní programování: metodiky efektivního vývoje softwaru. Brno: Computer Press, 2004. 278 s. ISBN 80-251-0342-0. Kirriemuir, J. a McFarlane, A.. Use of Computer and Video Games in the Classroom. Utrecht: Proceedings of the Level Up Digital Games Research Conference, 2003. Kniberg, H. Scrum and XP from the Trenches. Stockholm: Lulu.com, 2007. ISBN 978-1-4303-2264-1. MF, MŠMT a MPO Sytém budování finanční gramotnosti na základních a středních školách. Společný dokument Ministerstva financí ČR, Ministerstva školství, mládeže a tělovýchovy ČR, Ministerstva průmyslu a obchodu ČR vypracovaný na základě usnesení vlády č. 1594 ze dne 7. prosince 2005, aktualizovaná verze a v souladu se Strategií finančního vzdělání z prosince 2007. [on-line] 9.1.2008, [cit.] 26.12.2010 Elektronická adresa: http://www.msmt.cz/uploads/soubory/zakladni/SP SBFG 2007 web.pdf. Qvortrup, L. (ed.) Virtual Interaction: Interaction in Virtual Inhabited 3D Worlds. Springer, 2000. 455 s. ISBN 18-5233-331-6. Reynolds, C. Flocks, herds and schools: A distributed behavioral model. SIGGRAPH ’87: Proceedings of the 14th annual conference on Computer graphics and interactive techniques. Association for Computing Machinery, 1987. ISBN 0-89791-227-6. Smrčková J. Ekonomická gramotnost jako součást všeobecného vzdělání v ČR [on-line] 16.11.2009, [cit.] 26.12.2010 Elektronická adresa: http://clanky.rvp.cz/clanek/c/Z/7157/ekonomicka-gramotnost-jako-soucast-vseobecneho-vzdelani-v-cr.html/. Thaddeus, G. Self-Portrayal in a Simulated Life: Projecting Personality and Values in The Sims 2. Game Studies vol. 6, 2006. ISSN 1604-7982. 54

Wastiau, P., Kearney, C. a Van den Berghe, W.How are digital games used in schools? Brussels: European Schoolnet, 2009. 174 s. Van Verth, J. a Bishop, L. Essential Mathematics for Games and Interactive Applications: A Programmer’s Guide. Morgan Kaufmann, 2004. 676 s ISBN 15-5860-863-X. Wright, W. Why games are good for learning [on-line] 13.9.2010 [cit.] 23.12.2010 Streamované video: http://vimeo.com/14940963. Wright, W. GameTech 2010 conference keynote [on-line] 6.5.2010 [cit.] 23.12.2010 Streamované video: http://www.youtube.com/watch?v=fulyfB0c CQ.

55

Přílohy

A

Herní mechanismy skill 0 1 2 3 4 5 6

efficiency 50 60 75 80 85 90 100

breaks 2 2 1 1 0 0 0

anim speed 100 105 110 125 140 145 150

Tabulka 3: Vliv úrovně schopnosti na efektivitu práce.

strength 0 1 2 3 4 5 6 7 8

job difficulty (fatigue points per hour) light medium hard 200 300 450 150 200 325 100 150 250 90 125 200 80 100 175 70 90 150 60 80 125 40 70 100 20 50 75

Tabulka 4: Vliv síly na rychlost únavy z různě namahavé práce.

57

vitality FP regenerated 0 80 1 90 2 100 3 120 4 145 5 165 6 180 7 190 8 200 Tabulka 5: Vliv vitality na rychlost regenerace únavy.

level morale 0 0 1 0 2 -1 3 -2 4 -2 5 -3 6 -3 Tabulka 6: Vliv stupně hladu na pracovní morálku.

skill level experience points 0 0 1 100 2 250 3 400 4 600 5 850 6 1150 Tabulka 7: Množství zkušenosti pro jednotlivé úrovně schopnosti.

58

dexterity experience 0 15 1 20 2 25 3 30 4 35 5 40 6 45 7 50 8 55 Tabulka 8: Vliv šikovnosti na rychlost sbírání zkušenosti.

seasons 0 1 2 4 10 14 18 24

age vitality effect A NEWBORN 0 A BABY 0 A CHILD 0 A YOUTH -1 A ADULT 0 A MATURE -1 A OLD -2 A RETIRED 0

Tabulka 9: Modifikátor vitality k stáří postavy.

59

work W COOK W CLEAR TREES WILD W CLEAR STONES WILD W BUILD HOUSE W HARVEST FISH W HARVEST BUSH W BUILD CORRAL W MAINTAIN CORRAL W BUILD COOP W MAINTAIN COOP W BUILD ORCHARD W PLANT ORCHARD W MAINTAIN ORCHARD W HARVEST ORCHARD W PLANT PATCH W HARVEST PATCH W BUILD PATCH W PLOUGH PATCH W WEED PATCH W WATER PATCH W SOW FIELD W SOW FIELD EXTRA W PLOUGH FIELD W HARVEST FIELD W BUILD FIELD W CARE BABY W REST W EAT

skill difficulty critical effect S COOK light CE FOOD S HARDWORK hard CE NONE S HARDWORK hard CE NONE S HARDWORK hard CE NONE S NONE light CE NONE S NONE light CE NONE S HARDWORK hard CE NONE S ANIMALS medium CE NONE S HARDWORK medium CE NONE S NONE light CE NONE S PLANTS medium CE NONE S PLANTS medium CE NONE S PLANTS medium CE FITNESS UP S NONE light CE NONE S PLANTS light CE NONE S PLANTS medium CE YIELD UP S TILTH medium CE NONE S TILTH medium CE FITNESS UP S TILTH medium CE NONE S TILTH medium CE QUALITY UP S PLANTS light CE NONE S PLANTS light CE QUALITY UP S TILTH hard CE FITNESS UP S TILTH medium CE YIELD UP S TILTH hard CE NONE S NONE CE NONE S NONE CE NONE S NONE CE NONE

Tabulka 10: Vlastnosti prací: vyžadovaná schopnost, namáhavost, typ úspěchu.

60

B

Obrazové přílohy

Obrázek 9: Snímek ze hry – sklizeň obilí

61

Obrázek 10: Snímek ze hry – oběd a sklízení zeleniny

62

C

Seznam elektronických příloh

V UIS jsou u práce vedeny následující přílohy. • Farm.zip – aktuální verze aplikace v době odevzdání práce. • Concept.pdf – koncept hry z předprodukční fáze vývoje. • SourceSample.zip – balík s vybranými zdrojovými soubory aplikace. Zdrojové kódy jsou majetkem společnosti Hammerware, s.r.o. Přikládáme s povolením jen soubory, co jsou zmíněny v práci.

63