Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra Softwarového inženýrství

Bakalářská práce

Uživatelské rozhraní strategické tahové hry Sepulcher Barbora Červenková, DiS.

Vedoucí práce: Ing. Jiří Daněček

22. května 2012

Poděkování Před třemi lety bych neřekla, že takovouto práci budu vůbec schopna vytvořit. Děkuji tak své rodině za podporu v průběhu celého studia, mému příteli a také všem kantorům, kteří se nás po ty tři roky snažili něco naučit.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 22. května 2012

..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Barbora Červenková. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Barbora Červenková. Uživatelské rozhraní strategické tahové hry Sepulcher: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract The aim of this study was to create a library of graphical user interface elements using XNA 4.0 framework and using this library to implement a user interface for a strategic game Sepulcher. The first part deals with the general analysis of user interface, description of selected classes XNA, and also principle of creating software components, such as a library of GUI elements. In the second part can be found a description of the actual implementation. The result is a comprehensive work, whose product may be used for support of the course Computer games and animation. This work is not a study of player’s preferences about appearance of the game interface. Keywords XNA 4.0, framework, user interface, computer games

Abstrakt Cílem této práce bylo vytvořit knihovnu grafických uživatelských prvků za použití frameworku XNA 4.0 a s pomocí této knihovny implementovat uživatelské rozhraní pro strategickou logickou hru Sepulcher. První část práce se zaobírá obecnou analýzou od návrhu uživatelského rozhraní her, přes popis vybraných tříd XNA, až po zásady vytváření softwarových celků, jakým je například knihovna grafických uživatelských prvků. V druhé části práce lze 9

nalézt samotný popis implementace. Výsledkem je ucelená práce, jejíž produkt může být využíván například pro podporu výuky předmětu Počítačové hry a animace. Práce není studií hráčských preferencí na vzhled herního rozhraní. Klíčová slova XNA 4.0, framework, uživatelské rozhraní, počítačové hry

10

Obsah Úvod 17 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Cíle práce - shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Členění práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1 Analýza 1.1 Co to je uživatelské rozhraní a jaké 1.2 Analýza herních UI . . . . . . . . . 1.3 XNA 4.0 . . . . . . . . . . . . . . . 1.4 Volba jazyka . . . . . . . . . . . . 1.5 Zásady vytváření API . . . . . . .

jsou zásady jeho vytváření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 21 26 29 34 36

2 Návrh a realizace knihovny 41 2.1 Návrh tříd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.2 Realizace - jmenné prostory . . . . . . . . . . . . . . . . . . . . 45 2.3 Budoucí vývoj . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3 Návrh a realizace uživatelského rozhraní Sepulcher 65 3.1 Obrazovky - Screen . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.2 Tenký klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4 Testování 71 4.1 Statická analýza kódu a testování funkčnosti . . . . . . . . . . 71 4.2 Testovací scénáře Sepulcher . . . . . . . . . . . . . . . . . . . . 71 4.3 Testovací scénář Knihovna . . . . . . . . . . . . . . . . . . . . . 72 Závěr 77 Další rozvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Osobní přínos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 11

Literatura

79

A Seznam použitých zkratek

81

B Obsah přiloženého DVD

83

C Analýza herních UI C.1 Výběr her . . . . . . . . . C.2 Sledované aspekty hry . . C.3 Slovníček . . . . . . . . . C.4 Hry . . . . . . . . . . . . C.5 ZÁVĚR ANALÝZY HER

85 85 85 86 86 93

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

D Instalační příručka

95

E Příklad použití knihovny

97

F Uživatelská příručka hry F.1 Spuštění hry . . . . . F.2 Main menu . . . . . . F.3 Multiplayer menu . . . F.4 Hra . . . . . . . . . . .

Sepulcher . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

105 105 105 106 106

Seznam obrázků 1.1 1.2 1.3 1.4 1.5 1.6 1.7 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20

Příklad specifikace checkboxu, tlačítka a menu v HIG Windows . . zdroj:pc.hrej.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . zdroj:pc.hrej.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . zdroj:pc.hrej.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Herní smyčka XNA, zdroj:http://domynation.com/ . . . . . . . . . Ukázka jednoho z dostupných řešení NuclexGuiDemo, zdroj: https: //devel.nuclex.org/framework/wiki/NuclexUserInterface . . Todo list k návrhu knihovny . . . . . . . . . . . . . . . . . . . . . .

23 27 27 27 31

Nákres třídy Spinner . . . . . . . . . . . . . . . . . . . . . . . . . . Postup generalizace . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchie tříd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jmenný prostor XnaGuiElements . . . . . . . . . . . . . . . . . . . Třída TextureCrate a TextureHelepr ze jmenného prostoru Utils . Jmenný prostor Elements . . . . . . . . . . . . . . . . . . . . . . . Jmenný prostor Base . . . . . . . . . . . . . . . . . . . . . . . . . . Třída AbstractElement . . . . . . . . . . . . . . . . . . . . . . . . Border . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Třída WithTextElement . . . . . . . . . . . . . . . . . . . . . . . . Třída Label a výčtový typ LabelAnchor . . . . . . . . . . . . . . . Třída AccessibleElement, výčtové typy HitStrategy a ElementState Realizace rozhraní InputAccess, třídy MouseAccess a ExternalAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Třída AbstractButton . . . . . . . . . . . . . . . . . . . . . . . . . Třída Button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Třída CheckBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . Třída InputTextElement . . . . . . . . . . . . . . . . . . . . . . . Třída TextField . . . . . . . . . . . . . . . . . . . . . . . . . . . . Třída Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchie Layout . . . . . . . . . . . . . . . . . . . . . . . . . . .

42 43 44 45 46 46 47 48 48 49 50 51

13

34 39

52 52 53 54 55 56 57 58

2.21 2.22 2.23 2.24 2.25

Třída Menu . . . . . . Třída Spinner . . . . . Třída MoveButton . . . Třída ToolTipText . . . Class diagram Renderer

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

59 60 61 61 62

3.1 3.2 3.3 3.4

Náčrt 1 . . . . . . . . . . . . . . . . . . . . . Princip překrytí obrazovek v herní obrazovce Hierarchie ChooseHeroeCompnent . . . . . . Komunikace server-klient . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

66 67 68 69

4.1 4.2 4.3

Test 1: zadání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test 2 komponenta: zaškrtávací seznam . . . . . . . . . . . . . . . Test 2 komponenta: výběr hrdiny . . . . . . . . . . . . . . . . . . .

73 74 74

C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8

C.12 C.13

zdroj:pc.hrej.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 zdroj:pc.hrej.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 zdroj:pc.hrej.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Gatlin Gears, zdroj:www.ea.com . . . . . . . . . . . . . . . . . . . 88 Worms, zdroj:games.tiscali.cz . . . . . . . . . . . . . . . . . . . . . 88 Hra Flatout Zdroj:games.tiscali.cz . . . . . . . . . . . . . . . . . . 88 Hra Far Cry, zdroj:games.tiscali.cz/far-cry-3-14177/galerie . . . . . 89 Menu hry Far Cry, zdroj:www.bjorn3d.com/Material/ReviewImages/Far_ Cry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Hra Aliens: Colonial Marines, zdroj:games.tiscali.cz/aliens-colonialmarines-12259/galerie . . . . . . . . . . . . . . . . . . . . . . . . . 90 Hra Might and Magic, zdroj:might-and-magic.ubi.com/heroes-6/engb/media/screenshots . . . . . . . . . . . . . . . . . . . . . . . . . 91 Menu hry Might and Magic, zdroj:might-and-magic.ubi.com/heroes6/en-gb/media/screenshots . . . . . . . . . . . . . . . . . . . . . . 91 Menu hry Civilization, zdroj:www.civ4.com/images/22.jpg . . . . . 92 Menu hry Civilization, zdroj:www.civ4.com/images/22.jpg . . . . . 92

E.1 E.2 E.3 E.4 E.5 E.6 E.7 E.8

Nový projekt Game Studia . . . . . . . . . Přidání reference . . . . . . . . . . . . . . . Vybrání projektu . . . . . . . . . . . . . . . Přidání reference v projektu . . . . . . . . . Přidání reference v projektu . . . . . . . . . Přidání reference na třídu Renderer . . . . Přidání obrázků . . . . . . . . . . . . . . . Grafický výstup příkladu, zdroj obrázku lva:

C.9 C.10 C.11

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

14

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . 97 . . . . . . . . . . . . . 98 . . . . . . . . . . . . . 99 . . . . . . . . . . . . . 99 . . . . . . . . . . . . . 100 . . . . . . . . . . . . . 101 . . . . . . . . . . . . . 102 grafický manuál ČVUT104

Seznam tabulek

15

Úvod V pátém semestru svého bakalářského studia jsem absolvovala volitelný předmět Počítačové hry a animace (zkráceně PHA). Na tomto předmětu jsme měli jako semestrální projekt vymyslet a vytvořit 3D hru pomocí frameworku XNA. Jednalo se o práci v týmech, které byly rozděleny po čtyřech studentech. V polovině semestru jsme ovšem zůstali na tuto poměrně obsáhlou práci sami dva – já a můj kolega Václav Starý. K mé původní roli grafika jsem přibrala roli programátora herního UI, včetně úvodních menu a obrazovek. Jelikož se zbylí dva kolegové rozhodli od společné práce upustit těsně před odevzdáváním důležitého kontrolního bodu, probíhala moje implementace ve značné časové tísni. Pro naši hru bylo vcelku důležité uživatelské rozhraní. Marně jsem ovšem hledala v XNA jednoduchou třídu reprezentující tlačítko, popisek nebo textové pole. Hledala jsem tedy nějakou knihovnu na internetu, ale všechny oficiální dostupné řešení v té době směřovaly ke komplexním knihovnám typu Swing. Jednoduché tlačítko poskytující obyčejné „click“ jsem nakonec vytvořila. Jak to ovšem u rychlých řešení bývá, kód se mi nezdál zcela ideální. Od té doby mně v hlavě nepřestala vrtat myšlenka na vytvoření nějaké jednoduché knihovny, která by snad v budoucnu mohla pomoci studentům s implementací a uvolnila jim tak ruce k vytváření kreativní části hry. Jak jsem tedy obšírně naznačila, výstupem mé práce je kromě uživatelského rozhraní naší hry Sepulcher i knihovna jednoduchých prvků uživatelského rozhraní. Tato by měla dále sloužit pro potřeby studentů z ČVUT (a to především z Fakulty elektrotechnické a informačních technologií) v předmětu Počítačové hry a animace (či předmětům tomuto předmětu podobným) k usnadnění a urychlení vývoje her v prostředí XNA 4.0. Nutno podotknout, že hra Sepulcher je koncipována jako multiplayer a její serverová část a protokol pro komunikaci je součástí bakalářské práce „Herní server strategické tahové hry Sepulcher“"studenta Václava Starého. Implementace herního serveru a design dokument k této hře je přílohou na DVD této práce. 17

Úvod Demonstrace využití UI je možná i v autonomním módu (bez herního serveru), který ovšem nenabízí plnou hratelnost samotné hry Sepulcher.

Motivace Svoji prvotní motivaci jsem již o několik řádků výše popsala. Když jsem se pro toto téma rozhodovala, tak se ovšem vynořily i další aspekty, které pro mě byly rozhodující. Tedy: • Vytvořit knihovnu grafického uživatelského rozhraní v XNA 4.0 tak, aby byla nadále využívána studenty ČVUT v předmětu Počítačové hry a animace. • Rozvoj naší hry Sepulcher. • Získání zkušeností při návrhu softwarové knihovny. • Prohloubení znalostí jazyka C# a frameworku XNA 4.0.

Cíle práce - shrnutí Konkrétní výstup práce: • Knihovna grafických uživatelských prvků v XNA 4.0. • Tenký klient hry Sepulcher pro multiplayer včetně implementovaného uživatelského rozhraní. • Testovací projekt pro demonstraci využití prvků knihovny. • Dokumentace knihovny.

Členění práce Práce je rozdělena do několika částí. V první části jsou zahrnuty úkony, které slouží především k ujasnění, co by mělo být obsahem knihovny, jaké technologie k tomu použijeme a jakým způsobem bude veden návrh. V prvním kroku této části budou objasněny pojmy týkající se grafického uživatelského rozhraní a zásadami tvorby uživatelského rozhraní. Tento krok obsahuje rovněž studii reálných GUI her a je zde ujasněno, jaké konkrétní prvky GUI budou v knihovně. V druhém kroku je představen framework XNA, jakým způsobem pracuje a jsou zde uvedeny vybrané třídy, které jsou klíčové pro tvorbu knihovny. Uvedeny jsou také některé důležité aspekty jazyka C#, který jsem zvolila pro implementaci. 18

Členění práce Třetí krok se věnuje návrhu software a API obecně. Zde se pokouším najít odpovědi jak knihovnu implementovat z hlediska návrhu, efektivnosti, znovupoužitelnosti, atp. Druhá část práce využívá poznatků z části první a v kombinaci s prostředky softwarového inženýrství je přetvařuje v reálné výstupy. Nalezneme zde mimo diagramů a popisů tříd také metody a postupy, které byly uplatněny při vývoji, problémy, které vznikly při návrhu a jejich řešení. Poslední částí je část testování. Práce obsahuje také několik příloh, a to: Analýza herních UI - výtah z této analýzy je uveden v práci Instalační příručka - popis jak si nainstalovat IDE Visual Studio a framework XNA Uživatelská příručka - popis spuštění a ovládání hry Sepulcher Příklad použití knihovny - popis jak si založit projekt, jak přidat referenci na knihovnu, jak přidat grafický obsah do projektu a krátká ukázka kódu použití tříd z knihovny Uživatelská příručka hry Sepulcher

19

Kapitola

Analýza 1.1

Co to je uživatelské rozhraní a jaké jsou zásady jeho vytváření

1.1.1

Uživatelské rozhraní

Rozhraní obecně zprostředkovává komunikaci mezi dvěma nebo více subjekty. Co se týče uživatelského rozhraní, jak už název napovídá, jsou těmito subjekty uživatel/uživatelé a nějaký systém. Samotné uživatelské rozhraní je sada prvků a pravidel, které uživatel využívá k dosažení požadovaného cíle a kterými se systém závazně řídí. Systémem můžeme rozumět nějaký počítačový software (aplikace, operační systém, informační systém..), přístroj či zařízení (ovládání pračky, zařízení v kokpitu letadla,.. ) nebo zcela komplexní systém (výrobní linka).1 Ve své práci se zaobírám pouze počítačovým uživatelským rozhraním, a to ještě konkrétněji grafickým uživatelským rozhraním, které tuto komunikaci umožňuje díky vizuálním interaktivním prvkům a, aby té specifikace nebylo málo, v kontextu počítačových her. Pro uživatelské rozhraní se pro větší přehlednost textu dále používá zkratka UI (z angl. User Interface) nebo také GUI (Graphical User Interface). V dnešní době je grafické rozhraní pro všechny aplikace téměř samozřejmostí, proto píšu-li v textu o UI, je tím myšleno rozhraní grafické a nikoliv například textové.

1.1.2

Co to je HIG a proč se jím zabývat?

HIG neboli Human Interface Guidelines je soubor oficiálních pravidel a doporučení pro vytváření grafického uživatelského rozhraní na konkrétní platformě. Těmito pravidly by se měli řídit vývojáři aplikací pro danou platformu, není 1

Definice je vytvořena na základě učebního textu Martina Dostála(8) a Wikipedie.

21

1

1. Analýza to ovšem závazné. Uživateli ovšem tento unifikovaný přístup k vývoji ulehčuje orientaci a způsob používání aplikací. Pro jednoduchý příklad jsem vybrala některá obecná doporučení pro tvorbu UI přímo z Windows User Experience Interaction Guidelines (ke stažení viz. (2)). • Vytváříte zcela novou koncepci? Proč? Je to nutné? • Méně je někdy více. • Je jasné, co vše mohou uživatelé dělat? • Ať je radost vaše UI používat. • Ať je radost se na vaše UI dívat. • Tvořte UI tak, aby prostě a jednoduše fungovalo. • Tvořte UI jednoduše. • Postupujte podle pokynů. • Otestujte vaše UI. Proč je toto dobré znát? Jak je výše patrno, takovýto dokument se zaobírá dopodrobna principy návrhu, dobrými i špatnými zkušenostmi uživatelů, tím jak mají vypadat prvky GUI, tím co mají dělat prvky GUI, zkrátka opravdu vším, co je pro interakci dané platformy s uživatelem důležité. Je to souhrn mnohaleté kolektivní zkušenosti a jako takový může být zdrojem rad a zavedených postupů. HIG dokumenty poslouží při rozpoznávání, jaké prvky by měla obsahovat knihovna uživatelských prvků, jakým způsobem se chovají a jakých zásad by se měl držet návrh herního uživatelského rozhraní.

1.1.3

Prvky UI

Pro konkrétní představu, co všechno se pod takovým GUI skrývá, uvádím zde na základě HIG dokumentů, vlastní zkušenosti i prvků známých z jiných knihoven (konkrétně Swing, Jquery a WinForms), ucelený přehled prvků. Rozdělení jsem vytvořila dle povahy a funkce prvku, ale určitě je možné vytvořit i jiné rozdělení. Není ovšem tolik důležité, jestli je infobar v kategorii menu nebo jako textový výstup, neboť svým způsobem patří do obou2 . • Okna – Okno (window) 2

U těch prvků, které mají zažité české ekvivalenty je primárně uvádím v češtině, ty, které je nemají uvádím v angličtině s českým vysvětlujícím popiskem. Anglický výraz je použit i tam, kde sice existuje český ekvivalent, ale v praxi se nepoužívá.

22

1.1. Co to je uživatelské rozhraní a jaké jsou zásady jeho vytváření

Obrázek 1.1: Příklad specifikace checkboxu, tlačítka a menu v HIG Windows

– Modální okno (modal window) – Dialogové okno (dialog box) – Palette window (výběr barvy z palety) – Inspector window (zobrazení a změna parametrů daného objektu) – FileChooser (výběr souboru) • Vstupy a výstupy, formulářové prvky – Textový vstup ∗ ∗ ∗ ∗ ∗

Textové pole (textbox,textarea) Textový řádek (textfield) Adresní řádek (omnibox,address bar) Password field (pole pro zadání hesla) Combobox (kombinované pole)

– Ostatní vstup ∗ Tlačítko · Tlačítko (button) 23

1. Analýza · Přepínací tlačítko (toggle button) · Zaškrtávací pole (check box) · Přepínač (radio button) ∗ Slider ( posuvný výběr, často výběr od minima k maximu ) ∗ Číselník (Spinner) – Textový výstup ∗ Popisek (label) ∗ Kontextová nápověda (tooltip) ∗ Stavový řádek (status bar) ∗ Informační řádek (infobar) – Ostatní ∗ Ikona (icon) ∗ Progress bar (indikátor průběhu) ∗ Balónová nápověda (balloon help) • Menu a navigace – Menu ∗ Nabídka (menu) ∗ Místní nabídka, kontextové menu (context menu) ∗ Pie menu (kruhové menu ve tvaru koláče) ∗ Popup menu (vícevrstvý výběr) ∗ Lišta nabídek (menu bar) ∗ Panel nástrojů (toolbar) ∗ Pás karet (ribbon, tabbed pane) – Posuvník (scrollbar) – Další typy panelů ∗ Panel (tab) ∗ Scroll pane (panel s posuvníky) ∗ Split panel (panely s posuvnou přepážkou) – Zobrazení dat ∗ Strom (tree view) ∗ Mřížka (grid view) ∗ Seznam (list view) 24

1.1. Co to je uživatelské rozhraní a jaké jsou zásady jeho vytváření

1.1.4

Zásady tvorby UI

Uživatelské rozhraní - zásadami pro jeho tvorbu se zabývá nesčetně studií, knih, článků, vyučuje se jako samostatný předmět na vysokých školách a není snad vývojáře, který by se s ním nikdy nesetkal. Toto téma je velmi obsáhlé a stále se rozvíjející, především v nově nastupujících technologiích jako je ovládání počítače hlasem, gesty či pohyby očí. Zásad pro tvorbu je, přidáme-li i specifické oblasti, mnoho. Martin Dostál ve svém učebním textu(8) na základě knihy Designing the User Interface(5) sumarizoval osm základních pravidel, které mohou být použité všeobecně, tedy i v kontextu UI počítačových her, na něž se zaměřujeme především. Zde jsou3 : 1. Usilujte o konzistenci. Používejte konzistentní terminologii, dodržujte pravidla pro tvorbu rozhraní daného prostředí, směřujte k tvorbě stereotypů. 2. Respektujte širokou skupinu uživatelů. Autor aplikace si musí ujasnit, jaké skupiny uživatelů mohou jeho aplikaci používat (začátečníci, profesionální uživatelé, děti, zdravotně postižení . . . ) a podle toho tvořit rozhraní aplikace. 3. Poskytujte zpětnou vazbu. Uživatel potřebuje být přiměřeně informován o výsledcích práce s aplikací - zda akce proběhla úspěšně či nikoliv a proč. 4. Navigujte uživatele. Řada uživatelských úloh se sestává z posloupnosti více akcí. Rozdělte rozhraní akcí na jednoduché, logicky rozčleněné kroky, které respektují pracovní postup (workflow). 5. Předcházejte chybám. Uživatelské rozhraní by mělo minimalizovat možné chyby uživatele. 6. Umožněte uživateli se vrátit a buďte tolerantní k jeho chybám. 7. Vytvářejte předvídatelné uživatelské rozhraní. 8. Nepřetěžujte krátkodobou paměť uživatele, nabízejte přehlednost. Pro vývojáře je především tedy důležité umět se vcítit do role uživatele. Toto je samozřejmě poměrně těžké, protože uživatel a vývojář se nacházejí na opačných koncích pomyslného spektra znalosti daného systému. Při návrhu je dobré se neustále ptát, jestli tomu uživatel porozumí správně a také neopomenout testovací fázi. 3

Kráceno.

25

1. Analýza

1.2

Analýza herních UI

Z předešlých poznatků víme, jaké prvky by měla standardní knihovna uživatelských prvků obsahovat a jakých zásad se držet při vytváření UI. Ovšem doménou této práce je prostředí počítačových her, které má své určité specifikace a odchylky. Není účelem v knihovně implementovat prvky, které nenajdou uplatnění. Proto je důležité odhalit, jaké prvky by se neměly opomenout a naopak, které můžeme vynechat. K tomuto účelu slouží analýza herních UI. Kompletní analýzu lze najít jako přílohu C (Analýza herních UI) této práce, uvádím zde pouze podstatné části a na ukázku jednu z kategorií.

1.2.1

Výběr her

Při výběru her k analýze je žádoucí obsáhnout co největší spektrum typů herních UI a s tím spojené rozmanitosti. Dostatečně kvalitní vzorek nám pomůže odhalit, jaké prvky a jaká funkcionalita je pro budoucí knihovnu žádoucí. Jelikož se však na trhu nachází neuvěřitelné množství počítačových her, musíme provést určitou selekci. Pro získání výsledné testovací skupiny her bylo provedeno následující: 1. Základní kategorizace typů her dle žánrů a herních mechanismů. 2. Využití několika internetových portálů věnujících se počítačovým hrám (pc.hrej.cz/hry, games.tiscali.cz, www.lepsihry.cz). 3. Vyloučení her, které jsou starší dvou let (a nebyly nijak dále rozvíjeny). Toto omezení je hlavně proto, že účelem je vysledovat nejnovější tendence v herním GUI. 4. Vybrání několika zástupců od každého typu, protože nelze jednoznačně určit nejúspěšnější hry (výdělek, počet hráčů, hodnocení kritiků her,...) byly hry vybrány na základě různých metrik úspěšnosti např.: Call of Duty: Modern Warfare 3 – nejnovější pokračování legendární hry v žánru akčních her. 5. Zaměření především na 3D hry.

1.2.2

Sledované aspekty hry

U každé skupiny her byly sledovány tyto prvky: • hlavní herní obrazovka – rozvržení, komponenty, jaké prvky se zde vyskytují • herní menu – jak je členěno, jaké prvky používá • zajímavosti 26

1.2. Analýza herních UI

1.2.3 1.2.3.1

Ukázka analýzy ADVENTURA

Popis kategorie Adventura je druh počítačové hry, jejímž selling pointem (hlavním a propagovaným obsahem) je plnění různých úkolů, jde zpravidla o úkoly logické nebo hádanky v rámci jednotného příběhu. Hráč hraje za jednu postavu, zřídka za skupinu postav. Hry se vyznačují dostatkem času, který je zapotřebí právě pro logické řešení questů. Příběh hraje velikou roli. Vybraní zástupci 3D adventur • The book of unwritten tales (obr. 1.2) • Sam & Max : The Devil’s Playhouse: The Penal Zone (obr. 1.3) • Lost Horizon (obr. 1.4)

Obrázek 1.2: zdroj:pc.hrej.cz

Obrázek 1.3: zdroj:pc.hrej.cz

Obrázek 1.4: zdroj:pc.hrej.cz

Analýza kategorie Prvky GUI se přímo na hlavní herní obrazovce v adventurách vyskytují velmi sporadicky, pokud vůbec. Nejčastějším prvkem je ukazatel-přepínač postav. Výběr možností jednání postavy nebo interakce s předmětem je realizované pomocí výběrového menu, které bývá vyhotoveno nějakým zajímavým grafickým zpracováním. Dalším neopomenutelným prvkem GUI adventur je inventář postavy. Převažuje zde jednoduchost a přehlednost. Prvky: tlačítko, ikona, výběrové menu, inventář (posloupnost tlačítek) Zajímavost: 3D kruhové výběrové menu

1.2.4

ZÁVĚR ANALÝZY HER

Herní UI nejsou tolik bohaté na prvky jako běžné aplikace, o to víc je zde ovšem kladen důraz na grafické zpracování a originalitu. UI nemá pouze funkci komunikace mezi hráčem a hrou (i když toto je neméně důležité), ale zapojuje se do celé grafické koncepce hry. Každý vývojář nebo grafik bude chtít mít své GUI originální nebo, už třeba jenom kvůli autorským právům, alespoň trochu 27

1. Analýza jiné než ostatní. Navíc grafika hry a GUI musí být v souladu a to vylučuje změnu vzhledu uživatelem a pevně stanovuje definici pro tvůrce hry. Volba vzhledu prvků by měla být ponechána zcela na vývojářích hry. Nejdůležitějším prvkem je bezesporu tlačítko, které slouží jako základ všech ovládání, a které může nabývat různých tvarů a grafického vzezření. Dalšími důležitými prvky jsou různé ukazatele, ikony, popisky a také prvky zajišťující různá nastavení. Uplatní se zde především textová pole, popisky, zaškrtávací pole, výběry, spinnery apod. Nesmíme také opomenout prvek menu, který je pro každou hru vstupním bodem, a který bývá nejčastěji zcela jednoduchý. V obrazovce hry se také často setkáváme se zcela netradiční pojetím menu (kruhové, vícevrstvé, amorfní). Tohoto poznatku lze využít při návrhu knihovny. Horizontální menu, vertikální menu, kruhové menu, ty všechny vykazují shodné prvky, pouze se mění jejich rozvrstvení. Toto vede k implementování Layoutu, neboli třídy, která se bude starat o rozmístění prvků menu, ale funkcionalita a přístup bude veden uvnitř prvku menu. Hry, obzvláště ty 3D, jsou obecně velmi náročné na grafiku počítače. Po nastavení hry, vybrání hrdiny, lokace či jakýchkoliv jiných volbách se hra a její grafický obsah začne teprve nahrávat, nahrávání se také děje při změně různých lokací. Různé prodlevy jsou u her naprosto běžné, nabízí se proto prvek progressbar. Ovšem, jak je již výše zmíněno, grafika je na prvním místě a tak každá hra má svůj vlastní design progressbaru. Z povahy tohoto prvku vyplývá, že unifikovaná implementace by nebyla využita. Progressbar tedy nemusíme implementovat.

1.2.5

Shrnutí

Co tedy bude implementováno a co ne? 1. Nebudeme implementovat „Look and feel“4 podporu, naopak se budeme snažit o co nejjednodušší zadání vlastního grafického vzezření prvků. 2. Určitě je zapotřebí vytvořit prvky jako je tlačítko, menu, ikona, zaškrtávací pole, číselník (spinner), textové pole. 3. Pro menu vytvoříme třídu layout, která bude zodpovědná za rozmístění prvků. 4. Nebudeme implementovat progressbar. Co nám bude inspirací pro GUI Sepulcher? 1. Především komponenty z her typu strategie. 4 „Look and feel“ je jednotný a standardizovaný vzhled, který se uplatňuje pro všechny prvky.

28

1.3. XNA 4.0 2. Menu ponecháme co nejjednodušší, vhodné je pro uživatele zadání co nejméně parametrů a malý počet kliknutí vedoucích k začátku samotné hry.

1.3 1.3.1

XNA 4.0 Co to je XNA?

XNA Framework je soubor DLL, které slouží pro rychlý a intuitivní vývoj počítačových her. Jde ve své podstatě o nadstavbu nad DirectX, je postaven nad technologií .NET a je vyvíjen společností Microsoft. Ve třech hlavních jmenných prostorech (Microsoft.Xna.Game, Microsoft.Xna.Pipeline, Microsoft.Xna.Framework) nalezneme třídy umožňující nejen snadnou práci s 3D, audiem, videem ale i například se síťovými prvky (podpora multiplayeru) nebo práci se soubory (content pipeline, xml reprezentace dat, konfigurovatelné efekty). XNA se snaží být co nejvíce multiplatformní a tak principiálně je možné jej využít všude tam, kde je nainstalován .NET Framework Runtime, ve skutečnost bychom na toto ovšem neměli úplně spoléhat. Společně s XNA Frameworkem přichází XNA Game Studio, ve kterém je framework zahrnut a které je rozšířením vývojového prostředí Microsoft Visual Studio. Pro vývoj si lze zvolit jazyk C# nebo Visual C. Verze, kterých využívám, jsou XNA Framework 4.0, XNA Game Studio 4.0, které jsou postavené na Microsoft .NET Framework 4, IDE pro vývoj je Miscrosoft Visual Studio 2010 a jazyk C#. V těchto verzích je dnes možné vyvíjet pro Windows Phone 7, Xbox 360 a operační systémy Windows XP a výše(3). Příručka pro instalaci tohoto IDE, XNA Game Studia a všeho potřebného k vývoji her je, jak bylo zmíněno v úvodu, přílohou D této práce. 1.3.1.1

Výhody XNA

• Jednoduché, odstiňuje mnoho problémů s grafikou. • Content pipeline – jednotné zacházení s obsahem, převod na .xnb formát. • Možnost vyvíjet pro více platforem. • Zadarmo, a to i pro komerční účely. • Výborná dokumentace a množství příkladů přímo od firmy Microsoft(1). • Od verze 4.0. jsou zavedeny též tak zvané profily, které umožňují vývoj pro určitý typ zařízení a zajišťují plnou kompatibilitu s nimi. Jde o profil Reach, který je určen pro plnou kompatibilitu mezi Windows Phone 7, Xbox 360 a OS Windows a profil HiDef, který povoluje využití zcela 29

1. Analýza kompletní funkcionality API, která není ovšem dostupná například pro Windows Phone 7. 1.3.1.2

Nevýhody

• Omezení platformy. • Pro programování počítačových her náročných na správu paměti se nehodí.

1.3.2 1.3.2.1

Jak funguje XNA Princip herní smyčky

XNA je primárně určena pro vývoj her a využívá principu tzv. herní smyčky (obr.1.5). Jde o nekonečný cyklus překreslování obrazovky, kdy se neustále načítá vstup uživatele, kontrolují podmínky hry, aktualizují se objekty atd. Po vyhodnocení těchto podmínek se obrazovka patřičně překreslí a cyklus může pokračovat opět od začátku. Výhodou herní smyčky je to, že je vcelku jednoduchá na implementaci a snadno se s ní pracuje. Nevýhodou herní smyčky je to, že spotřebovává nadbytečně paměť v době, kdy by nemusela. Smyčka běží neustále i ve chvíli, kdy se ve hře nic neaktualizuje. Typickým příkladem takovéhoto „klidu“ může být, když si hráč čte deník své postavy, hra je zamrzlá a není zde přitom žádný uživatelský vstup. Nutno podotknout, že herní smyčka není jediný princip ve tvorbě her, jsou zde ještě další možnosti, například když se obrazovka překreslí v reakci na nějakou událost nebo také různé postupy pro vícevláknové hry. Vývojáři XNA se ale nejspíše snažili o jednoduchý nástroj a zvolili tak tuto klasickou a jednoduchou variantu.

1.3.3

Důležité třídy a metody

Jak již bylo výše zmíněno, XNA Framework se skládá ze tří jmenných prostorů (angl. namespace). Microsoft.Xna.Game obsahuje třídy pro hru samotnou, Microsoft.Xna.Pipeline a její třídy se starají o zpracování a nahrávání herního obsahu a Microsoft.Xna.Framework obsahuje třídy pro práci s grafikou, geometrií, audiem, zpracování uživatelských vstupů apod. Pro tvorbu knihovny a uživatelského rozhraní jsou důležité následující třídy. GraphicsDevice Přístup ke grafickému zařízení umožňuje třída GraphicsDeviceManager a třída GrapicsDevice pak reprezentuje grafické zařízení počítače (grafickou kartu či přímo GPU, apod.). Vše, co se má zobrazit na obrazovce, povede 30

1.3. XNA 4.0

Obrázek 1.5: Herní smyčka XNA, zdroj:http://domynation.com/

skrze tuto třídu. Dalo by se říct, že tato třída je jakýmsi pomyslným můstkem mezi XNA a samotným grafickým zařízením. Game Třída Game je zastřešující třídou celé hry. Poskytuje metody pro inicializaci, správu obsahu, řízení logiky a vykreslování. Na obrázku 1.5 můžeme vidět, jaké metody jsou postupně volány. Po zavolání metody Run() je provedena 31

1. Analýza inicializace GraphicsDevice a načten audiovizuální obsah (obrázky, zvuky, 3D modely) zaregistrovaných herních komponent. Poté se hra dostane do herní smyčky a jsou volány metody Update() pro obsluhu herní logiky a vstupů uživatele a metoda Draw(), která vykreslí připravený grafický obsah na obrazovku. Při ukončení hry je volána metoda Disposing(), která kaskádovitě ve všech komponentách vyčistí herní obsah. Ve třídě Game se může provádět mnoho dalších nastavení, inicializuje se zde například velikost okna nebo tzv. „fullsreen“ zobrazení, cesta k hernímu obsahu, registrují se služby atp. GameComponent, DrawableGameComponent Třída GameComponent reprezentuje nějakou námi vytvořenou komponentu hry, slouží pro zpřehlednění kódu, kterého je vzhledem k mnoha inicializacím, nahráváním obsahu, ale i samotné obsluhy logiky, čím dál tím více. Třída DrawableGameComponent je potomkem GameComponent a nabízí navíc funkcionalitu potřebnou k vykreslování. Tento mechanismus umožňuje modulárně přidávat a odebírat různé části hry, které spolu logicky jinak nesouvisí. Jako příklad bývá často uváděno právě oddělení GUI a hry samotné. Využití těchto tříd není podmínkou, vývojář má možnost napsat si vlastní logiku, hlídání načítání obsahu a vykreslování je potom zcela v jeho režii. SpriteBatch, SpriteFont Sprite je v počítačové grafice 2D bitmapa, na kterou se vykreslují jednoduché plošné obrázky. U starších her se pomocí několika spritů realizovala animace, například pohyb postav. V dnešní době se spíše využívají pro zobrazení score, počtu životů a dalších herních informací. V XNA jsou sprity vykreslovány přímo bez použití transformací, osvětlení a efektů definovaných pro ostatní objekty ve scéně(4). Použijeme je tedy všude tam, kde potřebujeme jednoduché plošné prvky, které nejsou ovlivněny tím, co se objevuje v samotné hře a jaké efekty se na ni uplatňují. Třída SpriteBach se používá k vykreslování spritů. Jak název napovídá, vykreslování probíhá v dávce. Pomocí této dávky vykreslíme několik spritů najednou, a to těch, které voláme mezi voláním metod spriteBach.Begin() a spriteBatch.End(). Toto řešení šetří čas pro přípravu grafického zařízení. Třída poskytuje metody DrawString(), která vykresluje text, a Draw(), která vykresluje obrázky. SpriteFont, Texture2D Pro grafický obsah knihovny se využívají třídy SpriteFont a Texture2D. SpriteFont je třída, která umožňuje namapovat font popsaný v XML souboru, jako bitmapovou texturu na sprite a Texture2D reprezentuje obrázek jako bitmapovou texturu. 32

1.3. XNA 4.0 ContentManager Pomocí třídy ContentManager se nahrává veškerý obsah pro použití ve hře. Může jít o textury, hudbu, zvuky, fonty, 3D modely nebo také efekty. Ve třídě Game je ContentManager již inicializován a lze se k němu dostat pomocí atributu Content. Nahrávání obsahu zprostředkovává generická metoda Load() viz. příklad níže. Texture2D texture = Content.Load("icon/logo_inverzni"); Keyboard, Mouse Třídy Keyboard a Mouse nám slouží pro zjišťování stavu uživatelského vstupu.

1.3.4

Shrnutí

XNA je samozřejmě mnohem komplexnější a nabízí mnohem více tříd pro všechny možné aspekty vývoje her. Pro vytvoření knihovny UI prvků je důležité znát, že XNA pracuje na základě principu herní smyčky, chování a vykreslování hry zajišťují metody Update() and Draw(), pro vykreslování 2D prvků se využívá třídy SpriteBach. Pro detailnější i podrobné seznámení s XNA dále doporučuji knihu Learning XNA 4.0(13) a oficiální dokumentaci na webových stránkách (1).

1.3.5

Stávající řešení GUI

XNA framework v sobě neobsahuje žádné prvky pro GUI. Protože je vývoj v XNA vcelku populární a stejný problém, jako jsem měla já, řeší více lidí, existují různá řešení této situace. Existuje několik projektů, ale jejich častým problémem je jejich přílišná složitost. Jejich tvůrci se snaží o simulaci oken a formulářů tak, jak je známe v aplikacích. Ve skutečnosti to, co vývojáři her často potřebují, je velmi jednoduché GUI. Hry nejsou o GUI, hry jsou o příběhu, o grafice, o nápadu a GUI je pouze prostředkem k této realizaci. Dalším a podstatným problémem stávajících řešení bývá to, že jsou vytvořeny pro nižší verzi XNA a jejich upgrade zatím není ke stažení. Nelze říct, že všechna řešení byla špatná, často ovšem ta dobrá bývají pod placenou licencí. Jejich přehled je zde. WinForms XNA lze standardně propojit s knihovnou WindowsForm, která zajišťuje aplikační GUI tak, jak je známe, tedy okna, formuláře atp. Pro jednoduchou hru je toto řešení trochu jako „jít s kanónem na vrabce“, navíc nasazení a provázání není zrovna nejjednodušší variantou. OrbUI, DigitalRune, Squid jsou komerčními řešeními, což je jejich podstatnou nevýhodou. Co se funkcionality týče, nejslibnějším hráčem v této 33

1. Analýza kategorii se zdá být DigitalRune. Nabízí vše, co by se dalo od takového frameworku očekávat, leč bohužel za úplatu. XNA Simple Gui,Nuclex Framework,XUI, Ruminate XUI je projekt pravděpodobně zatím v začátcích a nabízí omezenou funkcionalitu, ovšem výstup vypadá vcelku slibně a silnou stránkou je určitě i plná optimalizace pro XBox. Nuclex Framework a Ruminate, který vyšel teprve v březnu tohoto roku, jsou malá řešení, která se zatím vzhledově bohužel podobají začátkům formulářů. Awesomium Awseomium je zajímavý projekt, kde je vykreslování založeno na HTML, JS a CSS. Jde o vcelku robustní a komplexní řešení. Zajímavá je taktéž licence pro tento produkt, pro nekomerční účely je zdarma a pro firmy, které za minulý rok vydělaly méně jak 100 000 dolarů taktéž.

Obrázek 1.6: Ukázka jednoho z dostupných řešení NuclexGuiDemo, zdroj: https://devel.nuclex.org/framework/wiki/NuclexUserInterface

1.4

Volba jazyka

Jak bylo výše napsáno, pro vývoj jsem si vybrala jazyk C#. Jeho základními vlastnostmi jsou objektově orientovaný návrh (všechny třídy jsou potomky třídy Object, žádné globální proměnné nebo metody, jednonásobná dědičnost, zapouzdření, polymorfismus), syntaxe vycházející z jazyka C, silná typová kontrola, správa paměti pomocí garbage collectror. Zajímavost, kterou se například liší od jazyka Java, jsou delegáti. Delegát reprezentuje ukazatel na funkci. Pokud mu standardním přiřazením přidělíme název nějaké funkce, bude se tato funkce volat všude tam, kde se bude volat delegát. Delegátovi můžeme ovšem přiřadit funkcionalitu přímo. 34

1.4. Volba jazyka Vytvoření a použití delegáta 1. Přiřazení funkce: class TestDelegate{ public delegate void ButtonAction(); ButtonAction myAction; public TestDelegate(){ myAction = someAction; } public void someAction(){ System.Console.WriteLine("Something"); } } 2. Přiřazení přímo: class TestDelegate{ public delegate void ButtonAction(); ButtonAction myAction; public TestDelegate(){ myAction = delegate{ System.Console.WriteLine("Something"); } }

1.4.1

Konvence a pojmenování

Dodržování standardních konvencí pro daný jazyk je dobrou cestou k tomu, aby ti, kdo budou náš kód dále využívat, mu porozuměli a efektivně ho tak dále využili. Pro pojmenování artefaktů v jazyce C# se využívají v zásadě dvě typy konvencí, a to „velbloudí notace“ a „pascal notace“. „Velbloudí notace“ je taková notace, kdy první písmeno názvu je malé a další slova ve složenině začínají písmenem velkým. „Pacsal notace“ se poté liší pouze tím, že první písmeno je velké. „Velbloudí notaci“ využíváme v C# pouze u pojmenování parameterů. Pro zajímavost, dalšími možnými typy mohou být pojmenování pouze malými písmy (např. pojmenování balíčku v jazyce Java) nebo také notace s podtržítky (Pascal,C). Pro pojmenování .dll bylo využito konvence, která doporučuje pojmenování podle následující hierarchie. 35

1. Analýza První část (nebo části) definuje organizaci, pod kterou je knihovna vytvořena. V mém případě jsem tedy zvolila Cervebar.CtuFit. Další část názvu by měl být souhrnný název pro funkcionalitu jako celek. Celý název projektu knihovny je tedy Cervebar.CtuFit.XnaGuiElements. Pojmenování jmenných prostorů se poté řídí podobným způsobem, vždy tak, aby bylo co nejjasněji definováno to, co za funkcionalitu se pod tímto jmenným prostorem skrývá. Zde se využívá „Pascal konvence“. C# oproti jazyku Java využívá pro zapouzdření atributů tak zvaných vlastností (angl. property). Property lze vytvořit přímo za deklaraci atributu. Název property začíná velkým písmenem.

pulic String PropertyString {get;set;}

Osobně mi toto řešení příliš nevyhovuje, zvykla jsem si využívat get a set volání. V kombinaci s našeptáváním kódu v IDE je zřetelné, jaký atribut lze třídě nastavit, případně jaký z ní lze získat. Využití properties vede k jednoduššímu zápisu, nicméně klade větší požadavky pro programátora v pamatování si nastavitelných atributů třídy. Konvenci jsem nicméně v návrhu dodržela a v testovací fázi se ukázalo, že toto může někomu dělat podobné problémy. Jediným porušením konvencí, zbývá dodat, jsou velká písmena pro atributy výčtových typů. Toto jsme si zvolili týmově jako model pojmenování, na který jsme zvyklí. Toto naše strukturální ustanovení nezpřehledňuje čitelnost kódu. Struktura je někdy více než konvence(6).

1.5

Zásady vytváření API

Návrh je neuspořádaný proces (11). Na návrh softwaru neexistují žádná jasně daná a jediná správná pravidla. Naopak existuje mnoho různých i protichůdných návodů na to jak začít, s čím začít a čemu se nejvíce věnovat. Volba postupu návrhu je často záležitostí citu a osobních preferencí programátora.

1.5.1

Žádoucí vlastnosti návrhu

Požadavků na ty správné a žádoucí vlastnosti návrhu je mnoho. Z knihy Dokonalý kód(11) jsem vybrala pro návrh knihovny ty nejdůležitější5 a kterých jsem se snažila v průběhu návrhu knihovny držet. 5

Neuvádím celý výčet jednak z toho důvodu, že by to bylo dlouhé a jednak z toho, že některé vlastnosti nelze splnit. Například požadavek vysoké přenositelnosti je vzhledem k úzkému zaměření na framework XNA nedostižný.

36

1.5. Zásady vytváření API • Minimální složitost • Volné vazby • Rozšiřitelnost • Znovupoužitelnost • Užití nepříliš velkého množství tříd • Štíhlost • Rozvrstvení • Standardní techniky

1.5.2

Návrhové vzory

Návrhové vzory jsou doporučené postupy řešení často se vyskytujících úloh(12). Využitím návrhových vzorů je nejen splněno využívání standardních technik, ale také usnadňují porozumění kódu ostatním vývojářům. Návrhových vzorů je podle GoF 12, s dalším rozšířením od Rudolfa Pecinovského jich je 33. Zmíním z nich pouze čtyři a to ty, které jsem nakonec v návrhu dále skutečně realizovala. 1.5.2.1

Přepravka (Crate, Messenger)

Vzor přepravka využijeme všude tam, kde potřebujeme předat více nesourodých informací. V kódu to tedy znamená, že lze předat v jednom objektu jak řetězce, tak čísla, tak celé další objekty dohromady a jednotně. Přepravka je třída, která má pouze atributy a jeden konstruktor, který všechny tyto atributy nastaví. 1.5.2.2

Knihovní třída (Class Library)

Knihovní třída je vlastně jakousi přepravkou pro funkce. Z knihovní třídy nelze vytvořit instanci, její konstruktor je privátní a všechny metody statické. Tyto metody jsou často nějaké pomocné výpočty. Třída bývá deklarována často final nebo v případě C# sealed. 1.5.2.3

Strategie (Strategy)

Návrhový vzor strategie se využívá tam, kde je potřeba dynamické změny chování objektu. Základem je rozhraní, které realizují jednotlivé třídy podle toho, jakou strategii zastupují. Tímto způsobem je možné změnit algoritmus chování třídy „za pochodu“. Strategie se může například použít tam, kde má uživatel možnost ovlivnit pomocí nějaké volby celé chování aplikace nebo nějaké její části. 37

1. Analýza 1.5.2.4

Nulový prvek

Nulový prvek je taková třída, která jednoduše nic nedělá. Obsahuje prázdnou implementaci a využije se všude tam, kde by se muselo jinak neustále testovat na nulovost prvku.

1.5.3

Metodiky a metody návrhu

V průběhu mé práce jsem se snažila najít správný postup pro návrh knihovny. Narazila jsem při tom na různé metodiky návrhu. I když jsem nakonec nepoužila jednu konkrétní metodiku, využila jsem nakonec některých principů a metod v nich obsažených. Metodika je komplexní postup a návod pro vývoj softwarové aplikace, metoda je označení pro nějaký konkrétní postup(10). Existuje mnoho metodik návrhu softwaru, z tradičních je to RUP, vodopádový model, spirálový model, z těch agilních například extrémní programování, Crystal a další. Každá v sobě obsahuje zajímavé a různorodé metody jak dosáhnout správného cíle. A právě některých těchto metod lze využít při návrhu knihovny. Při vývoji knihovny bychom nejspíše neuplatnili přímo jednu vybranou metodologii. Tato práce přeci jenom není rozsáhlým informačním systémem, na kterém by pod tlakem pracovalo 10 programátorů, přesto poznatky z metodik (co jiného je metodika než zápis poznatků z praxe od zkušených programátorů) mohou být inspirativní a užitečné. Ke své práci jsem nakonec nejvíce čerpala z těchto dvou agilních metodik, i když některé principy jsou shodné i v jiných metodikách. Extrémní programování je metodika označována jako účinný, jednoduchý, lehký, flexibilní, předvídatelný a zábavný způsob vyvíjení softwaru(10). Z této metodiky jsem se asi nejvíce inspirovala následujícími aspekty vývoje. Úkolové karty - na základě úkolových karet jsem si vytvořila vlastní „TODO“ list (obr. 1.7 ), který jsem využívala po celou dobu návrhu a díky kterému jsem neztratila přehled o tom, co je potřeba dodělat a jakou to má prioritu. Zdrojový kód je základním nositelem informací - snažila jsem se najít takové názvy metod, atributů a tříd, aby bylo co nejvíce jasné, co se pod ním skrývá. Průběžné testování - pro průběžné testování jsem si mimo projektu Sepulcher vytvořila také testovací projekt, ve kterém jsem postupně přidávala nové prvky. Nástěnka - než byly vytvořeny jakékoliv diagramy, nakreslila jsem si prvek tak, jak by měl vypadat, na papír a k němu připisovala metody a atributy. Taktéž jsem si nakreslila možnou hierarchii prvků a 38

1.5. Zásady vytváření API postupem ji různě překreslovala. S těmito papíry se mi poté pracovalo mnohem lépe než s diagramy vytvořenými v nějakém editoru. Lean development je definován jako systematický přístup k indentifikování a eliminaci zdrojů plýtvání. Metodika je převzatá z výrobního odvětví(10)), přesto lze její základní myšlenku, a to odstranění všech zbytečností, důsledně, důkladně a definitvně, využít ve vývoji softwaru. Ve chvíli, kdy byla knihovna téměř v závěru vývoje, jsem si teprve přečetla principy této metodiky. Zkusila jsem se proto podívat na kód znovu a u každé metody či atributu jsem se zeptala, jestli tam jsou nezbytně nutné. Takto jsem nakonec odstranila mnoho kódu, který byl buď myšlen jako možné příští rozšíření nebo kódu, který byl jednoduše zapomenut. Velmi důsledné mazání všech nepotřebností tak přispívá k čitelnosti kódu.

Obrázek 1.7: Todo list k návrhu knihovny

1.5.3.1

Shrnutí

V návrhu je především důležité mít jasno v tom, co má být výsledkem. Cest, kterými se k němu dostat, je více. Každý člověk je jiný a budou mu tedy vyhovovat jiné postupy práce. Pokud člověk nemá dostatek zkušeností, je vhodné čerpat z různých publikací a článků zkušených programátorů a inspirovat se jimi. Ve vývoji softwaru, a dalo by se říci ve vývoji jakéhokoliv produktu, je důležité vytvořit si především nějaký systém. Je dobré vyzkoušet více postupů a ten, který se nakonec zdá nejvíce vyhovujícím, dále rozvíjet. Je také dobré nebát se od některých metod ustoupit v případě, kdy se nezdají být přínosem, ale spíše zátěží.

39

Kapitola

Návrh a realizace knihovny V následující kapitole se budu zabývat tím, jak je knihovna navržena. Při realizaci jsem se snažila postupovat v souladu s poznatky z minulých kapitol. Mým prvním úkolem bylo vytvořit knihovnu uživatelských prvků. Mým druhým úkolem bylo pomocí této knihovny vytvořit uživatelské rozhraní pro hru Sepulcher. Díky inspiraci z knihovny Swing a návrháře pro tuto knihovnu v IDE Netbeans jsem si uvědomila, že pokud bude realizace mého prvního úkolu důsledná, bude můj druhý úkol o to snazší. Při samotném způsobu a postupu návrhu jsem se tedy snažila najít vhodné metody, které by vedly k uspokojivému řešení. Nikde není napsáno, jak se vyvíjí knihovna uživatelských prvků, ovšem několik takových, a úspěšně využívaných, knihoven existuje. Inspiraci pro návrh jsem tedy také hledala v knihovně Swing pro programovací jazyk java, knihovně WinForms a na stránkách pro javascriptový framework JQuery. Především musím vyzdvihnout knihovnu Swing, která mi díky otevřenému kódu pomohla pochopit některé vazby a od jejíž hierarchie prvků jsem odvíjela hierarchii mé knihovny(9).

2.0.4

Jména a názvy

Snad nejtěžším a zároveň nejbanálněji vypadajícím úkolem programátora je cokoliv pojmenovat. Jména jsou v softwaru z 90% tím, co je činí čitelným(6). Vezmeme-li toto v potaz vyvstává nám při pojmenování značně těžká úloha. V souladu s objektově orientovaným návrhem a pojmenováváním objektů adekvátními jmény bylo vcelku jasné, že třída reprezentující tlačítko se bude jmenovat Button. Ovšem jak pojmenovat předky této třídy? Jak například pojmenovat společného předka pro tlačítko, popisek a panel? Snad nejvíce jsem zápasila se zcela základním názvem pro základní třídu knihovny. Container, Component, Item, Entity, Element, AbstractElement tyto všechny názvy se mi zdály v určité době adekvátní. Nakonec zvítězil 41

2

2. Návrh a realizace knihovny AbstractElement, tedy abstraktní prvek. Ovšem nelze zatajit, že kód byl několikrát refaktorován. Nutno ještě podotknout, že veškerý kód včetně komentářů píši v angličtině. Osobně si totiž myslím, že pokud nejde o edukační účely, je angličtina nepsaným standardem při psaní kódu.

2.1 2.1.1

Návrh tříd Vlastnosti a atributy tříd

Grafické uživatelské rozhraní (GUI) je takové rozhraní, kde jednotlivé části, říkáme objekty, jsou reprezentovány graficky (i jinak, třeba textově nebo zvukově) a uživatel s těmito objekty může manipulovat pomocí ukazovacího zařízení (myš, tablet, dotyková obrazovka . . . ). Činnostem, které lze s objekty vykonávat, říkáme akce(8). Tato definice GUI z práce Martina Dostála nám přibližuje samotný způsob návrhu knihovny. Je potřeba najít objekty, jejich atributy a akce, které lze s objekty vykonávat. Při návrhu nové třídy jsem využívala obyčejné tužky, papíru a pastelek. Prvek jsem si nakreslila a snažila se v něm najít atributy, odhalit podobu konstruktoru nebo specifických metod. Výhodou takovéhoto přístupu bylo i to, že si oči odpočinou od monitoru a mírní se tím únava.

Obrázek 2.1: Nákres třídy Spinner

2.1.2

Hierarchie tříd

Hierarchie tříd vznikla organicky. Při návrhu jsem využila postupu generalizace nebo také postup „shora dolů“, kde se nejprve definují bázové třídy a nekonkrétní návrhové prvky a postupně se přechází ke konkrétnějším aspektům návrhu(11). Na začátku prvním nejdůležitějším prvkem bylo tlačítko, druhým prvkem na řadě byl textový vstup. Bylo jasné, že prvky budou mít nějakého společného předka třídu, která bude abstraktní - AbstractElement. Dekompozicí a postupným odhalováním společných a různých vlastností (obr. 2.2) vznikla následující hierarchie dědičností tak, jako je tomu na obrázku 2.3.

42

2.1. Návrh tříd

Obrázek 2.2: Postup generalizace

43

2. Návrh a realizace knihovny

Obrázek 2.3: Hierarchie tříd

44

2.2. Realizace - jmenné prostory

2.2

Realizace - jmenné prostory

C# disponuje pro lepší orientaci a pro zamezení kolizí názvů tříd tak zvanými jmennými prostory. Není sice striktně určeno, že jmenný prostor musí odpovídat složce, ve které je umístěn, ovšem pro přehlednost je to myslím vhodné. Názvy jmenných prostorů proto odpovídají názvům složek. Podle daných konvencí jsem knihovnu vytvořila ve jmenném prostoru Cervebar.FitCtu.XnaGuiElements. Tento prostor je základním jmenným prostorem knihovny a jak je z obrázku 2.4 patrno, je dále rozdělen na tři další - Element, Render a Utils.

Obrázek 2.4: Jmenný prostor XnaGuiElements

2.2.1

Utils

Do složky Utils jsou vloženy všechny takové třídy, které jsou ostatním třídám v něčem užitečné, ale nejsou přímo reprezentanty nějaké domény6 . Patří sem tedy třída TextureCrate realizující návrhový vzor přepravka, pro jednodušší a především kratší předávání textur. Dále zde máme třídu TextureHelper, která je knihovní třídou pro různé pomocné metody s texturami, její konstruktor je privátní a všechny metody statické (obr. 2.5). 6

V angličtině utility znamená užitečnost. Utils je i v jiných projektech standardní složkou pro různé podpůrné třídy. Například Nette\Utils \Strings je třída ve frameworku Nette, sloužící pro práci s řetězci.

45

2. Návrh a realizace knihovny

Obrázek 2.5: Třída TextureCrate a TextureHelepr ze jmenného prostoru Utils

2.2.2

Elements

Složka Elements tvoří hlavní jmenný prostor knihovny (obr. 2.6). Dále se dělí na Base, Menu a Extended. V Base nalezneme jádro knihovny, tj. základní abstraktní třídy, dále jsou zde jmenné prostory pro třídy na ohraničení, rozmístění, přístup k prvkům a také využívané výčtové typy (obr. 2.7). V Menu nalezneme různá menu (aktuálně je tam pouze jedno, počítá se však v této oblasti s rozšířením) a v Extended jsou prvky, které jsou rozšířením základních prvků a nabízejí specializovanou funkcionalitu, jako je například specializované tlačítko pro pohyb panelu. Mohla by zde být například také komponenta pro zobrazení chatu ve hře, která je plánovaná jako další rozvoj knihovny.

Obrázek 2.6: Jmenný prostor Elements

2.2.2.1

AbstractElement

Třída AbstractElement je bázovou třídou všech prvků. Obsahuje všechny společné metody a atributy. Všechny prvky obsahují taktéž metody Move() 46

2.2. Realizace - jmenné prostory

Obrázek 2.7: Jmenný prostor Base

a Resize(), které umožňují manipulaci s prvkem při běhu programu, a jsou také, ve spojení s umisťováním prvků do panelu, užitečné při samotném psaní kódu. Všechny metody třídy jsou virtuální, tj. jsou překryvatelné, čehož se v následných třídách hojně využívá. Přímými potomky jsou třída Icon, která reprezentuje obrázek a je nejjednodušším prvkem celé knihovny, Panel a abstraktní třída WithTextElement. Metody, které obsahuje každý prvek Vykreslování - DrawElement(SpriteBatch spriteBatch), DrawTexture(), DrawBorder() Aktualizace - UpdateElement(GameTime gameTime), Enable(), Disable() Manipulace - Resize(), Move() Metoda Resize() zatím není zcela funkční u všech prvků. 2.2.2.2

Border

Každý prvek má okraje dané parametrem boundingRectangle. Jaké ty okraje budou závisí na tom, jaký typ realizace rozhraní Border se přiřadí do parametru border. Vykreslování okrajů je řešeno pomocí návrhového vzoru strategie (Strategy) a metoda DrawBorder() ve třídě AbstractElement provede pouze volání border.DrawBorder(rectangle boundingRectangle). Prvky mají primárně nastavený nulový okraj - třídu NoBorder, která je inspirována návrhovým vzorem nulovým prvek a jednoduše nevykreslí žádný okraj. Toto řešení nám umožňuje odstranit neustálé testování na nulovost okraje před vykreslením. 47

2. Návrh a realizace knihovny

Obrázek 2.8: Třída AbstractElement

Obrázek 2.9: Border 48

2.2. Realizace - jmenné prostory 2.2.2.3

WithTextElement

Třída WithTextElement je rodičovskou třídou pro všechny prvky, které obsahují textový obsah. Během prvního návrhu nebylo původně s touto třídou počítáno. Při implementaci jsem zjistila, že stejný kód (uchování fontu, nastavení textu apod.) opakuji v několika třídách. Tato třída tedy byla, jako jedna z posledních, doplněna a poskytla jednotný přístup k textu pro všechny prvky obsahující text. První název třídy byl TextElement, ten se ale ukázal být zavádějícím, protože například tlačítko není ve své podstatě textovým prvkem. Zvolila jsem proto možná trochu kostrbatější, avšak o to výmluvnější název.

Obrázek 2.10: Třída WithTextElement

2.2.2.4

Label

Třída Label reprezentuje jednoduchý popisek. Lze jej také využít pro textové výstupy k uživateli. Zajímavostí této třídy je volba pozice vykreslování. Třída Label obsahuje nastavitelnou pozici kotvy (angl. anchor) a strategii vykreslování textu vůči této pozici. Výhodné je například to, že pokud je nastaveno vykreslování na WRITE_CENTER, při každém nastavení textu se text automaticky vycentruje na zadanou pozici. Díky této vlastnosti se při zobrazování počtu životů v horní liště hry Sepulcher zobrazuje číslo vždy ve středu, i když je jednomístné nebo dvoumístné. 49

2. Návrh a realizace knihovny

Obrázek 2.11: Třída Label a výčtový typ LabelAnchor

2.2.2.5

AccessibleElement

Třída AccessibleElement je abstrakcí všech prvků, které nějakým způsobem reagují přímo na vstup uživatele. Obsahuje výčtový typ ElementState, který udává v jakém stavu se prvek nachází, například najede-li kurzor na prvek, stav prvku se přepne na ROLLOVER. Podle tohoto stavu se dále řídí podoba a chování prvku. AccessibleElement zároveň disponuje třídou TextureCrate, která v sobě obsahuje všechny typy textur pro různé stavy (textura pro najetí na prvek, textura pro stisknutý prvek, atd.). Prvek tedy může reagovat na stav změnou textury, která na něj upozorní uživatele. Důležité také je, jak se k tomuto vyhodnocení stavu dostat. Třída obsahuje rozhraní InputAccess, které dle zadané konkrétní realizace řídí a vyhodnocuje přístup. Potomci třídy AccessibleElement zpravidla rozšiřují metodu UpdateElement() tak, že po zavolání bázové metody base.UpdateElement()) přidávají specifickou reakci na výsledek stavu prvku. 2.2.2.6

InputAccess

Rozhraní InputAccess a třídy MouseAccess a ExternalAccess jsou taktéž realizací návrhového vzoru strategie. Využití tohoto návrhového vzoru se ve třídě AccessibleElement nejprve nejevilo jako dobrý nápad. První funkčnost zajišťoval výčet (enum), který měl pouze tři stavy. V kódu, kde se provádí výpočet, pak jen stačil pouze jednoduchý switch. Nevýhoda tohoto řešení se ukázala mnohem později, při tvorbě třídy Menu. Menu je v mnoha hrách řešeno velmi jednoduše, obsahuje pouze tlačítka, co je kamenem úrazu, je přístup k těmto tlačítkům. Mnoho her (především těch jednoduchých) neumožňuje hráči v obrazovce menu mít přístup k tlačítkům pomocí myši. Menu je řešeno jednoduše tak, že výběr se děje šipkami 50

2.2. Realizace - jmenné prostory

Obrázek 2.12: Třída AccessibleElement, výčtové typy HitStrategy a ElementState

a „odEntrováním“. První co nás napadne je přidat další položku výčtu a další položku switche. Knihovna je sice v prvním plánu tvořena pro PC verze XNA, proč si ale nevytvořit některé konstrukce, které nám mohou v budoucnu umožnit jednoduché rozšíření? Tak jsem vytvořila toto řešení, které může být do budoucna možností pro rozšíření přístupu i pro XBox. Návrh znamená kompromisy a priority(11). Toto řešení má nevýhodu ve vysoké provázanosti tříd, výhodou je zas kompletní oddělení logiky přístupu k prvku a možnost další rozšiřitelnosti. Při dalším rozšíření knihovny lze tímto způsobem například také vytvořit přístup ve formuláři, který bude řízen tabulátorem. Nicméně si myslím, že zde by bylo do budoucna vhodné popřemýšlet o celkovém zjednodušení a zvolnění vazeb mezi třídami. Zatím jsou vytvořeny dva typy přístupu MouseAccess, který je využit pro vstup počítačovou myší, a ExternalAccess, který pouze říká, že stav prvku je řízen zvenčí (tohoto přístupu se využívá v menu). 2.2.2.7

AbstractButton

Třída AbstractButton (obr. 2.14) je předkem všech různých typů tlačítek. Obsahuje definici delegáta ButtonAction. Uchovává v sobě akci fireAction, která je typu ButtonAction. Tato akce, pokud není nulová, je volána k vykonání. Přiřazení funkce do fireAction si potomci třídy řeší uvnitř, nelze tyto 51

2. Návrh a realizace knihovny

Obrázek 2.13: Realizace rozhraní InputAccess, třídy MouseAccess a ExternalAccess

hodnoty nastavit zvenčí. Z vnějšku lze pouze nastavit, jakých hodnot mohou nabývat.

Obrázek 2.14: Třída AbstractButton

52

2.2. Realizace - jmenné prostory 2.2.2.8

Button

Třída Button (obr. 2.15) reprezentuje tlačítko. Byla první třídou, která se měla implementovat. Původní myšlenkou byla „všesplňující“ třída, která by uměla zachytit všechny události a změny stavu (nelze zapřít, že inspirací byla třída JButton v knihovně Swing). V průběhu návrhu a také při implementaci rozhraní hry Sepulcher se ukázalo, že tato třída v sobě obsahuje mnoho zbytečného a kód k jejímu vytvoření se rychle zanášel mnoha řádky různých nastavení. Třída Button se nakonec vyvinula do co nejjednodušší podoby. Odstranila se nepotřebná volání funkcí, s vložením třídy WithTextElement do hierarchie tříd se ze třídy odstranily všechny položky týkající se textu, s uvědoměním, že i třída TextField může měnit textury v závislosti na stavu, se textury přesunuly do třídy AccessibleElement a zmizelo nastavování textur. Význam třídy Button pro tvorbu herního GUI je veliký. Jde o nejčastěji použitý prvek, od kterého se ovšem očekává často pouhé „click“, tedy spuštění nějaké akce (vyvolání kouzla, vypití lektvaru). Z toho hlediska jsem se rozhodla odklonit se od standardních implementací zachytávání událostí a ponechat funkcionalitu i kód tlačítka co možná nejjednodušší.

Obrázek 2.15: Třída Button

2.2.2.9

CheckBox

Třída CheckBox (obr. 2.16) podporuje funkcionalitu zaškrtávacího pole. Vykresluje dvě textury na sobě podle toho, jestli je prvek označen nebo ne. Vzhle53

2. Návrh a realizace knihovny dem ke stejné funkcionalitě lze třídu využít i jako radiobutton, kde se pouze vytvoří oválné textury. Třída disponuje dvěma delegáty typu ButtonAction, které lze vyvolat při zaškrtnutí nebo odškrtnutí pole.

Obrázek 2.16: Třída CheckBox

2.2.2.10

InputTextElement

Třída InputTextElement je rodičovskou třídou prvků, které nějakým způsobem zpracovávají textový vstup. Zajišťuje změnu stavu v případě fokusu na prvek (pokud má prvek fokus, lze do něj psát, i když nad ním není kurzor), obsahuje pole a metody vztahující se k vykreslování blikajícího kurzoru za textem, a odchytávání vstupu z klávesnice. Tato třída potřebuje předání GraphicsDevice, protože vykreslení kurzoru je řešeno jako jednobarevná textura o tloušťce jednoho pixelu a výšce zadaného fontu. Zajímavostí může být, že v prvních návrzích byl odkaz na GraphicsDevice přímo ve třídě AbstractElement a tudíž každý prvek musel mít v konstruktoru tento parametr. Prvky tak sice mohly mít defaultní a velmi jednoduchý 54

2.2. Realizace - jmenné prostory vzhled, ale ve chvíli, kdy jsem měla rovnou nastavené vlastní textury, bylo tento parametr naprosto zbytečný. Nastavení textur je tedy plně v režii vývojáře, jen u textových prvků je zde možnost automatického nastavení pozadí ( pro připomenutí je toto možné díky třídě TextureHelper jejíž metoda GetBlankTexture(GraphicsDevice,Color) vrací jednobarevnou texturu).

Obrázek 2.17: Třída InputTextElement

2.2.2.11

TextField

Třída Textfield je zatím nejjednodušší implementací textového vstupu. Pro účely implementace rozhraní hry nebylo složitějšího přístupu potřeba, protože všechny zadávané textové položky mají vcelku striktní omezení na délku vstupu a lokalizace vstupu je určena pouze na anglické znaky. 55

2. Návrh a realizace knihovny Dokáži si ovšem představit situace, kdy takovéto omezení nebude. Pro možnou další verzi knihovny se zde nabízí prostor v rozšíření funkcionality pomocí bufferu, společně s ním možnost přesunů v textu, smazání pomocí výběru atd.

Obrázek 2.18: Třída TextField

2.2.2.12

Panel

Třída Panel se využívá pro skupinové umisťování prvků. Panel může obsahovat jakýkoliv element, tedy i další panel, prvky se vykreslují v pořadí, ve kterém byly zadány. Nejdůležitější metodou třídy panel je metoda AddElement(element), ve které je voláno vložení prvku podle zvoleného layoutu. Panel, do kterého je vkládán jiný panel, je tomuto automaticky přiřazen jako rodičovský. Pokud by další přidaný prvek měl z panelu vyčnívat, rozšíří se výška nebo šířka panelu na optimální velikost. Panel, který je vložený, rovněž rozšíří taktéž rodičovský. 56

2.2. Realizace - jmenné prostory

Obrázek 2.19: Třída Panel

2.2.2.13

Layout

Layout neboli rozložení je řešeno podle návrhového vzoru stretegie. Aktuálně jsou vytvořeny tři základní typy layoutů. HorizontalLayout, VerticalLayout a FreeDesignLayout, který umožňuje jakékoliv rozmístění prvků v panelu a jejich jednotné posouvání. 2.2.2.14

Menu

Třída Menu je potomkem třídy Panel a je vysoce specializovaná. Do Menu lze přidat pouze tlačítka, tedy instance třídy Button. Po přidání je tlačítkům nastaven přístup zvenčí (ExternalAccess), a Menu teprve zpracovává uživatelský vstup a nastavuje, které tlačítko je aktivní. Každý layout má definované klávesy NextKey a PrevKey, které přenášejí focus na další prvek, čehož je využito pro výběr následujícího/předešlého tlačítka. Třída Menu obsahuje ča57

2. Návrh a realizace knihovny

Obrázek 2.20: Hierarchie Layout

sovač, který umožňuje plynulé přejíždění po prvcích, pokud je dlouze stisknuta klávesa pro posun v menu. 58

2.2. Realizace - jmenné prostory

Obrázek 2.21: Třída Menu

2.2.2.15

Spinner

Spinner neboli číselník je prvním čistě složeným prvkem - komponentou. Jde o panel, který obsahuje dvě tlačítka s přiřazenými akcemi přičítat/odečítat, a text zobrazující výsledek. Číselníku lze nastavit minimální i maximální hodnoty. Pokud se číselník dostane do těchto krajních hodnot, tlačítko se přepne do stavu disabled. 2.2.2.16

MoveButton

Třída MoveButton ze jmenného prostoru Extended je specializovaným rozšířením třídy Button. Umožňuje panelu, který je předán v konstruktoru, přesunutí. Přesouvat lze celý panel, včetně prvků uvnitř, právě pomocí akce chytni a táhni na toto tlačítko. 2.2.2.17

ToolTipText

Třída ToolTipText reprezentuje nápovědu. Konstruktor třídy přijímáAccessibleElement,tedy prvek, který může být ovlivněn uživatelským vstupem a kde se tedy předpokládá možný dotaz od uživatele. Atributem delay je určeno jak dlouho trvá než se nápověda nad prvkem objeví. 59

2. Návrh a realizace knihovny

Obrázek 2.22: Třída Spinner

2.2.3

Render

Všechny prvky v sobě obsahují metody UpdateElement() a DrawElement(), které korespondují s metodami Update() a Draw() ze třídy DrawableGameComponent. Pravděpodobně není nejvhodnější neustále přidávat do kódu na každý použitý prvek volání těchto metod, už jen při jednom formuláři by nám kód enormně nabobtnal. Přesto je ale někde zavolat musíme. Mým nabídnutým řešením je řešení pomocí rozhraní Renderer. Návrh je postaven na jednoduché myšlence „vykreslovače“, který prvkům u něj registrovaných řekne, kdy a za jakých okolností se mají aktualizovat a vykreslit. Jako nejjednodušší varianta je předpřipravena třída SimpleRenderer, která implementuje rozhraní Renderer, a všechny prvky aktualizuje/vykreslí přesně v tom pořadí, ve kterém byly přidány. Lze ovšem vytvořit mnohem sofistikovanější řešení, která budou zohledňo60

2.2. Realizace - jmenné prostory

Obrázek 2.23: Třída MoveButton

Obrázek 2.24: Třída ToolTipText

vat například překrytí prvků, aktualizovat pouze ty prvky, na kterých se nachází kurzor nebo zohledňovat různé preference pořadí prvků. V tomto směru se nabízí několikero optimalizací. Je také patrno, že „vykreslovač“ nemusí být ve hře pouze jeden, záleží tedy skutečně pouze na vývojáři, jak se rozhodne. Zároveň je třeba dodat, že toto řešení není nutnou podmínkou vykreslení prvků. Pokud vývojář například potřebuje pouze jedno tlačítko nemusí nutně vytvářet Renderer, stačí na prvek zavolat přímo metody UpdateElement() a DrawElement() ve standardních metodách herní komponenty. 61

2. Návrh a realizace knihovny

Obrázek 2.25: Class diagram Renderer

2.2.4

Komentáře a dokumentace

Důležitým prvkem návrhu jsou také komentáře a z nich vygenerovaná dokumentace. Má-li se knihovna doopravdy využívat nestačí pouze dobře a kvalitně navrhnout třídy, algoritmy a postupy. Je důležité také vše kvalitně a co nesrozumitelněji okomentovat a zdokumentovat. Snažila jsem se proto psát své komentáře jasně, stručně a čitelně. Kolikrát se mi stalo, že jsem se ke třídě a jeho algoritmu vracela a pokud nebyl správně okomentován, nebo nebyl okomentován vůbec trvalo mi o poznání déle znovu se v kódu zorientovat. Vypracovala jsem si tedy pravidla, kterými jsem se při komentování kódu řídila. 1. Komentovat hned. 2. Komentovat kódem. 3. Komentovat stručně. 62

2.3. Budoucí vývoj 4. Komentovat dělením na celky – V komentářích se mi osvědčilo používat číslované seznamy, které v dokumentaci vyhovují pravidlu stručnosti a v samotném kódu jsou zakomponované „kotvičky“ neboli zakomentované číslo, které odpovídá popisu jednoho celku kódu. 5. Seznámit se s automatickými nástroji IDE - vytváření komentářů lze mnohdy automatizovat. Osobně jsem využila modul Scharp Comments do IDE Visual studio, který barevně zvýrazňoval důležitost komentáře, obzvláště velké červené „TODO“ mi bylo velmi nápomocno.

2.3

Budoucí vývoj

Proces navrhování API má jeden důležitý mezník: první veřejná verze(14). Aktuálně je knihovna ve své úplně první verzi 1.0. Obsahuje základní prvky a principy pro prvky GUI, obsahuje také některé specializované prvky, které byly potřebné pro realizaci UI hry Sepulcher. Během návrhu a implementace jsem narazila na další možnosti a prvky, které by se mi líbily, aby je knihovna ještě obsahovala - nové typy okrajů, kruhový layout, pseudo3D menu atd. Je tedy stále co zdokonalovat a to je i mým úmyslem do budoucna.

63

Kapitola

Návrh a realizace uživatelského rozhraní Sepulcher Hra Sepulcher je zamýšlena v multiplayer módu, tedy tak, že ji hraje více hráčů po síti. Klientská část aplikace, která je také mým úkolem, tedy bez spuštěného serveru neposkytuje plnou funkcionalitu.7 Jak spustit hru a jak se ovládá, je v příloze F, design dokument pro tuto hru se nachází na přiloženém DVD, kde jsou všechny další podrobnosti ke hře a ze kterého vycházejí požadavky na funkcionalitu.

3.0.1

Požadavky

• hlavní menu - položky: multiplayer, credits, exit • multiplayer menu – volby: založit hru, připojit se ke hře, zpět – formulář: jméno hráče (max.8 znaků), výběr hrdiny, IP adresa serveru, jméno místnosti (max.8 znaků), počet hráčů (max.5, min.1) • credits - informace o tvůrcích hry • exit - ukončí hru • herní obrazovka - dle design dokumentu • aplikace poběží jako tenký klient 7

Projekt klientské části využívá částečně kódu, který byl vytvořen při semestrální práci v předmětu PHA. Kód tříd pro pohyb postav, přehrávání zvuků je prací mých kolegů. Konkrétně, kdo co tvořil je pod nabídkou CREDITS v hlavním menu hry.

65

3

3. Návrh a realizace uživatelského rozhraní Sepulcher

3.0.2

Náčrty vzhledu GUI

Obrázek 3.1: Náčrt 1

3.1

Obrazovky - Screen

Implementace herních obrazovek vychází z tutoriálu projektu GameStateManagement přímo od Microsoftu (7). Vytvořila jsem si vlastní třídu RenderScreen, která je potomkem třídy GameScreen z tohoto projektu a přebírá tak mnoho výhod již implementované funkcionality. Třída obsahuje Renderer a v překryté metodě Draw() volá vykreslování všech prvků v vložených při inicializaci do Rendereru. Třídy, které dále od RenderScreen dědí, reprezentují jednotlivé herní obrazovky a jediná metoda, kterou překrývají je inicializace komponent v nich obsažených. Další obrazovky využité v projektu jsou tak zvané „Pop up screen“, které slouží jako modální dialogy. Takováto obrazovka se například objeví při špatně zadaném formátu IP adresy serveru. 66

3.1. Obrazovky - Screen

Obrázek 3.2: Princip překrytí obrazovek v herní obrazovce

3.1.1

Specializované prvky GUI

Z hlediska využití návrhu knihovny je zajímavé rozšíření o vlastní komponentu. Pro výběr postavy hrdiny jsem potřebovala při výběru jiné postavy překreslit ikonu na vybraného hrdinu a zároveň při potvrzení vstupu do hry, také serveru sdělit, kterého hrdinu si hráč vybral. Vytvořila jsem tedy třídu ChooseHeroeComponent, která se o vše sama postará včetně načtení grafického obsahu. Pro takto specializované prvky a komponenty jsem vytvořila rozhraní IHasContent, které poskytuje jedinou metodu LoadContent(), tato metoda se volá ve chvíli, kdy se nahrává obsah, takže je zajištěno, že inicializace textur proběhne ve správný čas. Protože každá obrazovka má vlastní správu obsahu, předává se metodě parametr ContentManager. Pokud nějaká třída končí, uvolní se jí alokovaný obsah. Tímto je zajištěno uvolnění paměti v době, kdy obrazovka není zobrazována. Dalšími rozšířením knihovny o vlastní prvek je také třída SkillButton. 67

3. Návrh a realizace uživatelského rozhraní Sepulcher I ona se stará o načítání vlastních textur a kromě funkcionality tlačítka v sobě udržuje veškeré informace o dovednosti, kterou reprezentuje.

Obrázek 3.3: Hierarchie ChooseHeroeCompnent

3.2

Tenký klient

Hra Sepulcher má pouze multiplayer mód. Klientská část aplikace, která byla úkolem, bez spuštěného serveru neposkytuje plnou funkcionalitu, při nepřipojeném serveru se pro demonstraci zobrazí pouze herní UI a vypíše se příslušné hlášení. Pro komunikaci jsou důležité následující třídy. Třída ServerLogic řeší samotné navázání spojení a přijímání/odesílání příkazů přímo do streamu. Pokud je od serveru přijat příkaz pošle jej tato třída voláním metody AddCommand třídě GameLogic. Tato třída reprezentuje nejdůležitější funkcionalitu hry, vykresluje 3D obsah, v metodě Update zpracovává přijaté příkazy a přes třídu GameUI readuje na uživatelský vstup. Veškerá komunikace běží asynchronně.

68

3.2. Tenký klient

Obrázek 3.4: Komunikace server-klient

69

Kapitola

Testování 4.1

Statická analýza kódu a testování funkčnosti

Knihovnu jsem kompletně testovala během celé práce, vždy po přidání nového prvku jsem si v testovacím projektu, který je taktéž na přiloženém DVD, ověřovala celkovou funkcionalitu. Nejvíce kritické bylo přidávání prvků do panelu a jejich společné přemístění. Kvůli těmto testům vznikla třída MoveButton, která reprezentuje tlačítko s takovou funkčností, že po akci drag and drop se přesune celý panel, který byl u třídy zadán v konstruktoru. Pomocí něj jsem vyladila metodu Move() všech prvků. Na konci vývoje knihovny jsem provedla statickou analýzu kódu, kdy jsem se snažila odhalit všechny zdvojené a přebytečné atributy i metody. Během návrhu jsem využívala postupu generalizace, a při něm jsem často při tvorbě nového předka opomněla některým prvkům atributy odstranit, nebo ve třídách zbyly funkce, které dělaly totéž. Během statické analýzy jsem například odstranila ze všech entitních tříd text, textPosition, textColor a ponechala je pouze ve třídě WithTextelement.

4.2 4.2.1

Testovací scénáře Sepulcher Multiplayer menu

1. Vypsání chybového hlášení při zadání jména při použití speciálních znaků - OK 2. Vypsání chybového hlášení při zadání nesprávného formátu IP adresy OK 3. Vypsání chybového hlášení při zadání názvu místnosti při použití speciálních znaků - OK 71

4

4. Testování 4.2.1.1

Závěry testování

Při testování bylo zjištěno, že je výhodnější, než vypisovat chybové hlášení o překročení limitu textového pole, je uživateli neposkytnout možnost zadat více písmen. Do třídy TextField tak byla přidána možnost zadat maximální počet písmen v textovém poli. Stejně tak číselník má svá omezení jak horního, tak spodního limitu. Dále bylo odhaleno, že použití menu ve fromuláři v obrazovce pro multiplayer není tak vhodné. Menu má totiž pouze přístup z klávesnice, a to je pro uživatele, kteří ve formuláři využívají přístup pomocí myši matoucí. Menu bylo vyměněno za panel obsahující tlačítka s přístupem pomocí myši. Pro demonstraci menu bylo v hlavní nabídce ponecháno. Pro budoucí rozvoj by mohlo být vhodné vytvořit menu poskytující jak přístup pomocí šipek, tak pomocí myši.

4.2.2

Herní obrazovka

1. Vypsání chybového hlášení při chybovém spojení se serverem - OK 2. Vybrání a použití dovednosti - OK 3. Zobrazení inventáře - OK 4. Odchod ze hry - OK 4.2.2.1

Závěry testování

Vybráním dovednosti se dlaždice vybarví rozsahem dovednosti, vybarvení při nepoužití dovednosti zůstává. Zde by bylo vhodné dlaždice zpět vybarvit na chůzi. Toto je ale spíše než na UI požadavek pro budoucí vylepšení komunikace mezi klientem a serverem.

4.3

Testovací scénář Knihovna

Prvním velkým testem knihovny je vlastní implementace UI Sepulcher, během samotné implementace jsem nalezla a odstranila několik chyb. Cílová skupina: Cílovou skupinu pro testování knihovny tvoří programátoři, kteří mají znalosti OOP. Dobrým, ale ne nezbytně nutným, předpokladem je znalost jazyka C# a frameworku XNA.

4.3.1

Jednoduché rozhraní

Pokyny • Seznamte se s ukázkovým příkladem (příloha E) a vytvořte nový projekt. 72

4.3. Testovací scénář Knihovna • Cílem testu je vytvořit jednoduché herní rozhraní dle obrázku 4.1. • V tomto testu používejte dokumentaci pouze v případě, že si opravdu nevíte rady. Cílem je také zjistit, jak dostatečně průkazný je samotný kód.

Obrázek 4.1: Test 1: zadání

Dotazy • Bylo použití knihovny dostatečně srozumitelné, měli jste někde problém se rozhodnout? • Museli jste využít dokumentace? Pokud ano, v jakém případě. • Napište odhalené nedostatky, či funkce, které vám chyběly. • Další poznámky.

4.3.2

Vlastní komponenta

Pokyny • Seznamte se s dokumentací knihovny a vytvořte nový projekt. • Cílem testu je vytvořit vlastní komponentu, pomocí rozšiřování některých tříd knihovny. • Můžete využít zadání nové komponenty níže nebo si vymyslet komponentu vlastní. • Můžete plně využívat dokumentaci knihovny. 73

4. Testování Možné komponenty: • Zaškrtávací seznam podle obrázku 4.2. Komponenta může mít například metodu, která vrátí všechny zaškrtnuté položky. Mohou se zde také vybarvovat zeleně již odškrtnuté položky apod.

Obrázek 4.2: Test 2 komponenta: zaškrtávací seznam

• Komponenta pro výběr hrdiny pomocí posuvných tlačítek (obr. 4.3). Nahoře se zobrazí jméno hrdiny.

Obrázek 4.3: Test 2 komponenta: výběr hrdiny

Dotazy • Popište postup svého řešení a překážky, se kterými jste se setkali. • Napište odhalené nedostatky, či funkce které vám chyběly. • Napadlo vás nějaké další vylepšení? Sem s ním. • Další poznámky. 74

4.3. Testovací scénář Knihovna 4.3.2.1

Shrnutí

Knihovnu jsem nechala otestovat několika mými kolegy, kteří taktéž absolvovali předmět PHA. Vzhledem k nedostatku času absolvolali pouze první test. Závěry testování jsou shrnuty níže. • Názvy tříd jsou průkazné, pouze vytvoření RadioButtonu dělalo problém, neboť jde o tu samou funkcionalitu jako je ChceckBox. Řešením je dodatečná dokumentace třídy a vytvoření příkladu přímo na RadioButton. • Pokud se využívá panelu je problém s následným pozicováním prvků. Přidání a pozice prvku musí být v daném pořadí, a to se někdy projevilo jako problém, zvlášť když se použilo konstruktoru, který obsahoval pozice. Protože všechny třídy obsahují metodu Move řešením by mohlo být odstranění pozicovacích konstruktorů. To ovšem bez použití Panelu přinutí napsat ke každé nové třídě ještě řádek Move(). Proto je tato varianta prozatím zamítnuta. Problém je především v tom, že prvek sám o sobě neví jestli je zahrnut v panelu nebo ne, při budoucím rozvoji knihovny bude stát tato problematika dále za rozvážení. • CheckBox - často se zapomíná na přidání fontu, program poté vyhodí NullPointerException. Řešením je konstruktor přijímající text a font. Dalším matoucím prvkem byly konstruktory nepřijímající textury, které jsou ovšem potřebné. Na toto existují dvě řešení, buď stejně jako ve třídě TextField předávat GraphicsDevice nebo ponechat pouze konstruktory obsahující textury. Přiklonila jsem se k řešení s texturami. • Při testování byly odhaleny některé bugy: chyběla možnost nastavení ChceckBoxu jako selected a ve třídě TextField nebylo možno psát do pole pokud nebyl nastaven nějaký limit. Obě chyby jsou opraveny. • Dokumentace byla využita především pro zjišťování jaké metody a atributy jsou přístupné, což nebylo často hned jasné. Toto mi potvrzuje myšlenku, že pro příští verzi knihovny bude lepší nedržet se striktně konvencí C# a vytvořit get a set metody pro přístupné atributy. Toto jednoznačně určí, které mohou být nastaveny a které lze pouze získat. • V dalším rozšíření by mohl být prvek typu formulář.

75

Závěr Cílem této práce bylo vytvořit knihovnu grafických uživatelských prvků ve frameworku XNA a s její pomocí poté vytvořit uživatelské rozhraní ke hře Sepulcher. Tohoto bylo dosaženo. V průběhu práce jsem se postupně seznámila se zásadami tvorby uživatelského rozhraní a také se zásadami správného návrhu softwaru. Snažila jsem se získané poznatky uplatnit v praxi a svůj návrh jsem směřovala tak, aby bylo ovládání a používání jak rozhraní, tak samotné knihovny jednoduché a intuitivní. Snažila jsem se také o co nejmenší závislosti vlastního kódu na samotném kódu frameworku tak, aby případná další verze frameworku byla kompatibilní nebo aby nutné úpravy na vyšší verzi byly minimální. Knihovnu hodlám uvolnit včetně zdrojových kódů k volnému používání pro studenty ČVUT v předmětu Počítačové hry a animace, nebo jemu podobných. Věřím, že knihovna pomůže ušetřit čas a uvolní tak studentům ruce pro vylepšování efektů, 3D animací či dalších kreativní stránek návrhu počítačových her. Pro způsob používání knihovny jsem vytvořila kompletní dokumentaci a ke každému jednotlivému prvku existuje ukázkový kód v testovacím projektu. Jako ukázkový příklad vytvoření vlastní komponenty, ukázky možnosti využití dědění a kombinování vlastností tříd knihovny uvádím třídu Spinner.

Další rozvoj Hra Sepulcher je projekt, na kterém společně s mým kolegou Václavem Starým chceme dále pokračovat. Našim dalším krokem bude posílení našeho týmu o grafika, animátora, a další nadšence, kteří by se chtěli podílet na vývoji počítačové hry. Práce na takovémto projektu je stále dost a mě tak čeká ještě mnoho úkolů. Mimo práci s shadery nebo načítání parametrů postav z konfiguračních souborů, je to právě i další vylepšování knihovny uživatelských prvků a s její pomocí také vylepšování herního rozhraní naší hry. 77

Závěr V dalších verzích knihovny by se mělo objevit vylepšené textové pole, kde bych chtěla zakomponovat buffer na posouvání znaků a timer pro plynulé posouvání v poli, listbox, panel se scrollbarem, další typy layoutů, pseudo3D menu a další. Dále bych chtěla prvky rozšířit o možnost animace. Poslední metou rozšíření je vytvoření 3D ovládacích prvků.

Osobní přínos Jednou z mých motivací pro tuto práci bylo získání zkušeností při návrhu softwarové knihovny. Zkušeností v tomto směru jsem získala mnoho, a to nejen při návrhu knihovny, ale i softwaru obecně. Při studiu metodik a metod správného návrhu jsem narazila na spoustu užitečných rad ke všem možným softwarovým produktům. Zaujaly mě například některé nové agilní metodiky, z nichž jsem některé zásady při návrhu skutečně uplatnila. Zajímavým zjištěním pro mě byly také tak zvané HIG dokumenty, o kterých jsem před zahájením práce ani nevěděla, že existují. Další z motivací bylo rozšíření znalostí jazyka C# a frameworku XNA, což se doufám povedlo. Neposledním přínosem je také to, že jsme udělali veliký krok ve vývoji naší hry Sepulcher.

78

Literatura (1) APP HUB. [online], stav ze dne 7.5.2012. Dostupné z WWW: (2) Download center - download Windows User Experience Interaction Guidelines. [online], stav ze dne 7.5.2012. Dostupné z WWW: (3) Download center Microsoft XNA Game Studio 4.0. [online], stav ze dne 7.5.2012. Dostupné z WWW: (4) MSDN library - What is Sprite? [online], stav ze dne 7.5.2012. Dostupné z WWW: (5) Ben Shneiderman, C. P.: Designing the User Interface: Strategies for Effectivee. Human-Computer Interaction, Pearson Addison Wesley., čtvrté vydání, 2004. (6) C.Martin, R.: v Cistý kód. ComputerPress, a.s., Holandská 8, 63900, Brno, vydání první vydání, 2009, ISBN 978-80-251-2285-3. (7) Corporation, M.: GameStateMAnagement download page. (8) Dostál, M.: Základy tvorby učivatelského rozhraní. [online], stav ze dne 7.5.2012. Dostupné z WWW: (9) Falkhausen, M.: java.swing JComponents. (10) Kadlec, V.: Agilní programováni. ComputerPress, a.s., nám.28.dubna 48, 63500, Brno, vydání první vydání, 2004, ISBN 80-251-0342-0X. 79

Literatura (11) McConnell, S.: Dokonalý kód. ComputerPress, a.s., nám.28.dubna 48, 63500, Brno, vydání první vydání, 2005, ISBN 80-251-0849-X. (12) Pecinovský, R.: Návrhové vzory. ComputerPress, a.s., Holandská 8, 63900, Brno, vydání první vydání, 2007, ISBN 978-80-251-1582-4. (13) Reed, A.: Learning XNA 4.0. OReilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472., first edition vydání, 2010, ISBN 978-1-449-39462-2. (14) Tulach, J.: Practical API Design: Confesion of Java Framework Architect. Apress, 2008, ISBN 978-1-4302-0973-7.

80

Příloha

Seznam použitých zkratek UI User interface GUI Graphical user interface HIG Human Interface Guildelenes TODO XNA někdy se uvádí XNA is not an acronym, ve skutečnosti se tedy o žádnou zkratku nejedná 2D dvourozměrné 3D třírozměrné DLL Dynamic-Link Library XML Extensible Markup Language HTML Hypertext Markup Language JS JavaScript CSS Cascade Style Sheet RUP rational Unified Process XP Extrémní programování PHA Počítačové hry a animace IDE Integrated Development Environment

81

A

Příloha

Obsah přiloženého DVD

readme.txt.................................stručný popis obsahu DVD DesignDocumentSepulcher.pdf.........design dokument hry Sepulcher documentation ............................ adresář s dokumentací kódu exe ....................... adresář se spustitelnou formou implementace Sepulcher ........................................... hra Sepulcher library..................................................knihovna src impl...................................zdrojové kódy implementace library.............................knihovna a testovací projekt Sepulcher ........................................ hra Sepulcher BP_Cervenkova_Barbora_2012.tex . zdrojová forma práce ve formátu LATEX text ....................................................... text práce BP_Cervenkova_Barbora_2012.pdf ...... text práce ve formátu PDF 83

B

Příloha

Analýza herních UI C.1

Výběr her

Při výběru her k analýze je žádoucí obsáhnout co největší spektrum typů herních UI a s tím spojené rozmanitosti. Dostatečně kvalitní vzorek nám pomůže odhalit, jaké prvky a jaká funkcionalita je pro budoucí knihovnu žádoucí. Jelikož se však na trhu nachází neuvěřitelné množství počítačových her, musíme provést určitou selekci. Pro získání výsledné testovací skupiny her bylo provedeno následující: 1. Základní kategorizace typů her dle žánrů a herních mechanismů. 2. Využití několika internetových portálů věnujících se počítačovým hrám (pc.hrej.cz/hry, games.tiscali.cz, www.lepsihry.cz). 3. Vyloučení her, které jsou starší dvou let (a nebyly nijak dále rozvíjeny). Toto omezení je hlavně proto, že účelem je vysledovat nejnovější tendence v herním GUI. 4. Vybrání několika zástupců od každého typu, protože nelze jednoznačně určit nejúspěšnější hry (výdělek, počet hráčů, hodnocení kritiků her,...) byly hry vybrány na základě různých metrik úspěšnosti např.: Call of Duty: Modern Warfare 3 – nejnovější pokračování legendární hry v žánru akčních her. 5. Zaměření především na 3D hry.

C.2

Sledované aspekty hry

U každé skupiny her byly sledovány tyto prvky: • hlavní herní obrazovka – rozvržení, komponenty, jaké prvky se zde vyskytují 85

C

C. Analýza herních UI • herní menu – jak je členěno, jaké prvky používá • zajímavosti

C.3

Slovníček

Tak jako každá specifická skupina i hráčská komunita zavádí některé pojmy, které nemusí být člověku mimo tuto komunitu jasné. Pro jasné vymezení pojmů je zde malý slovníček klíčových slov. Většina jich je z angličtiny, v české mluvě hráčů se ovšem nepřekládají. Quest Dílčí úkol, který hráč v průběhu hry plní. Zpravidla slouží k posunutí v příběhu hry nebo také k získání nějakých dovedností postavy či užitečného předmětu. Boss Nepřítel nebo příšera ve hře, která se od ostatních běžných nepřátel a příšer odlišuje zpravidla větší obtížností v souboji. Může se jednat o vysoké hodnoty atributů potřebných pro souboj, nebo vlastní nějaké unikátní kouzlo, umí přivolávat posily atp. Bývá často na konci questu. Finální boss, hlavní boss Boss, jehož zabití či jiné zneškodnění vede zpravidla k vítězství ve hře. FPS neboli First person shooter je hra, která je z pohledu první osoby. Herní obrazovka se snaží o co největší realističnost - tedy jakoby se hráč díval vlastníma očima.

C.4 C.4.1

Hry ADVENTURA

Popis kategorie Adventura je druh počítačové hry, jejímž selling pointem (hlavním a propagovaným obsahem) je plnění různých úkolů, jde zpravidla o úkoly logické nebo hádanky v rámci jednotného příběhu. Hráč hraje za jednu postavu, zřídka za skupinu postav. Hry se vyznačují dostatkem času, který je zapotřebí právě pro logické řešení questů. Příběh hraje velikou roli. Vybraní zástupci 3D adventur • The book of unwritten tales • Sam & Max: The Devil’s Playhouse: The Penal Zone • Lost Horizon 86

C.4. Hry

Obrázek C.1: zdroj:pc.hrej.cz

Obrázek C.2: zdroj:pc.hrej.cz

Obrázek C.3: zdroj:pc.hrej.cz

Analýza kategorie Prvky GUI se přímo na hlavní herní obrazovce v adventurách vyskytují velmi sporadicky, pokud vůbec. Nejčastějším prvkem je ukazatel-přepínač postav. Výběr možností jednání postavy nebo interakce s předmětem je realizované pomocí výběrového menu, které bývá vyhotoveno nějakým zajímavým grafickým zpracováním. Dalším neopomenutelným prvkem GUI adventur je inventář postavy. Převažuje zde jednoduchost a přehlednost. Prvky: tlačítko, ikona, výběrové menu, inventář (posloupnost tlačítek) Zajímavost: 3D kruhové výběrové menu

C.4.2

ARKÁDA

Popis kategorie Arkáda se hraje zpravidla na kola, obtížnost kol se stupňuje či jinak mění (nový typ nepřátel ), na konci kola většinou čeká na hráče nějaký boss. Tento typ hry vyžaduje většinou rychlé ovládání pohybu postavy či předmětu (časté jsou například vesmírné lodě) pomocí kombinace kláves, myši nebo konzole. Tendence směřování hráče bývá často dopředná, málokdy zde najdeme postranní cesty, kterými by se muselo v prostoru hry vracet. Často existují módy pro podporu dvou a více hráčů, kteří hrají spolu nebo proti sobě na jednom počítači zároveň. Bývají velmi rozmanité. Vybraní zástupci 3D • Gatlin Gears • Worms Ultimate Mayhem8 • Flatout 3 8

Worms Ultimate Mayhem je nejnovější 3D zpracování legendární hry Worms, které se sice trochu vymyká definici arkády, ovšem tato hra by se vymykala asi jakékoliv definici, pokud by pro ni nebyl samostatný žánr. Vzhledem k některým podobným prvkům ji zařadíme k arkádám. K naší analýze je toto členění postačující.

87

C. Analýza herních UI

Obrázek C.4: Gatlin Gears, zdroj:www.ea.com

Obrázek C.5: Worms, zdroj:games.tiscali.cz

Obrázek C.6: Hra Flatout Zdroj:games.tiscali.cz

Analýza kategorie Arkády jsou velmi různorodé. Oproti adventurám více komunikují s uživatelem pomocí prvků GUI. Časté jsou různé ukazatele, zobrazování atributů, zobrazení času, v herních menu dominují všechny možné výběry a vstupní prvky. 88

C.4. Hry Prvky: tlačítko, výběrové menu, kruhový ukazatel rychlosti či úhlu, ukazatel podobný progress baru, lokační ukazatele Zajímavost: 2D kruhové výběrové menu, výběr levelů pomocí ikonového menu

C.4.3

STŘÍLEČKY

Popis kategorie Jak už název napovídá, jedná se o typy her, kde hráč třímá v ruce nějakou střelnou zbraň (vyjímečně nůž či pěsti) a většinou zachraňuje nejlépe celý svět. Hráč hru vnímá buď z pohledu první osoby nebo z pohledu třetí osoby. Vybraní zástupci 3D • Far Cry • Aliens: Colonial Marines

Obrázek C.7: Hra Far Cry, zdroj:games.tiscali.cz/far-cry-3-14177/galerie

Analýza kategorie Tyto hry zpravidla nemívají v hlavní obrazovce žádné gui prvky,stejně tak menu her je, jak můžeme vidět u hry Far Cry, velice prosté. Prvky: Menu, ikona, combobox, spinner Zajímavost: Grafické vyvedení menu hry Far Cry 89

C. Analýza herních UI

Obrázek C.8: Menu hry Far Cry, zdroj:www.bjorn3d.com/Material/ReviewImages/Far_ Cry

Obrázek C.9: Hra Aliens: Colonial Marines, zdroj:games.tiscali.cz/alienscolonial-marines-12259/galerie

C.4.4

STRATEGIE

Popis kategorie Strategie je takový typ her, kdy hráč něco buduje nebo vytváří, případně strategicky ničí. Zpravidla tyto činnosti zahrnují těžení či tvorbu surovin, zabírání nového území, výstavbu budov, tvorbu jednotek, obrana proti nepříteli. Existuje mnoho typů strategií. Za povšimnutí stojí, že do této kategorie, konkrétně do logických strategických her, spadá naše hra Sepulcher, jejíž GUI budeme s pomocí vzniklé knihovny vytvářet. 90

C.4. Hry Vybraní zástupci 3D • Might and Magic Heroes • Civilization

Obrázek C.10: Hra Might and Magic, zdroj:might-and-magic.ubi.com/heroes6/en-gb/media/screenshots

Obrázek C.11: Menu hry Might and Magic, magic.ubi.com/heroes-6/en-gb/media/screenshots

zdroj:might-and-

91

C. Analýza herních UI

Obrázek C.12: Menu hry Civilization, zdroj:www.civ4.com/images/22.jpg

Obrázek C.13: Menu hry Civilization, zdroj:www.civ4.com/images/22.jpg

Analýza kategorie Strategie jsou na prvky GUI velmi bohaté. Toto vyplývá již z povahy typu hry. Je možno vysledovat shodné rysy a to : horní lišta plná informací , spodní lišta plná různých informací a z toho plynoucí dominující použití tlačítka. Zajímavé 92

C.5. ZÁVĚR ANALÝZY HER (a důležité pro naši knihovnu) je, že i když se ve hrách objevují okna jejich funkcionalita je co nejjednodušší, většinou nabízí pouze akci zavřít. Prvky: tlačítko, ikona, výběrové menu, menu, okno se záložkami, listbox, posuvník inventář (posloupnost tlačítek). Zajímavost: Vícevrstvé kruhové menu.

C.5

ZÁVĚR ANALÝZY HER

Herní UI nejsou tolik bohaté na prvky jako běžné aplikace, o to víc je zde ovšem kladen důraz na grafické zpracování a originalitu. UI nemá pouze funkci komunikace mezi hráčem a hrou (i když toto je neméně důležité), ale zapojuje se do celé grafické koncepce hry. Každý vývojář nebo grafik bude chtít mít své GUI originální nebo, už třeba jenom kvůli autorským právům, alespoň trochu jiné než ostatní. Navíc grafika hry a GUI musí být v souladu, a to vylučuje změnu vzhledu uživatelem a pevně stanovuje definici pro tvůrce hry. Volba vzhledu prvků by měla být ponechána zcela na vývojářích hry. Nejdůležitějším prvkem je bezesporu tlačítko, které slouží jako základ všech ovládání, a které může nabývat různých tvarů a grafického vzezření. Dalšími důležitými prvky jsou různé ukazatele, ikony, popisky a také prvky zajišťující různá nastavení. Uplatní se zde především textová pole, popisky, zaškrtávací pole, výběry, spinnery apod. Nesmíme také opomenout prvek menu, který je pro každou hru vstupním bodem, a který bývá nejčastěji zcela jednoduchý. V obrazovce hry se také často setkáváme se zcela netradiční pojetím menu (kruhové, vícevrstvé, amorfní). Tohoto poznatku lze využít při návrhu knihovny. Horizontální menu, vertikální menu, kruhové menu, ty všechny vykazují shodné prvky, pouze se mění jejich rozvrstvení. Toto vede k implementování Layoutu, neboli třídy, která se bude starat o rozmístění prvků menu, ale funkcionalita a přístup bude veden uvnitř prvku menu. Hry, obzvláště ty 3D, jsou obecně velmi náročné na grafiku počítače. Po nastavení hry, vybrání hrdiny, lokace či jakýchkoliv jiných volbách se hra a její grafický obsah začne teprve nahrávat, nahrávání se také děje při změně různých lokací. Různé prodlevy jsou u her naprosto běžné, nabízí se proto prvek progressbar. Ovšem, jak je již výše zmíněno, grafika je na prvním místě a tak každá hra má svůj vlastní design progressbaru. Z povahy tohoto prvku vyplývá, že unifikovaná implementace by nebyla využita. Progressbar tedy nemusíme implementovat.

93

Příloha

D

Instalační příručka Instalace Visual Studia i XNA Game Studia je vcelku jednoduchá, stačí si z patřičných stránek stáhnout instalační soubory a řídit se podle pokynů. Pro to, aby XNA fungovalo správně je zapotřebí dobré grafické karty, viz. požadavky níže. 1. Požadavky • operační systém Windows Vista a výše, Service Pack 2.0 a výše • grafická karta:podpora Shader Model 1.1, DirectX 9.0c (ovšem lepší Shader Model 2.0) 2. Stáhnout a nainstalovat Visual Studio 2010. • Na stránkách http://www.microsoft.com/cze/msdn/vstudio/2010 lze stáhnout všechny verze jako trial (není open source). Osobně pracuji s verzí Professional, postačí ale i verze Express. • Další postup dle instalačních pokynů po spuštění staženého instalačního souboru. 3. Instalace XNA Game Studia • Stáhnout Microsoft XNA Game Studio 4.0 z http://www.microsoft. com/en-us/download/details.aspx?id=23714 • Další postup dle instalačních pokynů po spuštění staženého instalačního souboru. • Restartování Visual Studia, po dalším spuštění se objeví v nabídce nových projektů

95

Příloha

Příklad použití knihovny 1. Vytvoření nového projektu (obr. E.1)

Obrázek E.1: Nový projekt Game Studia 97

E

E. Příklad použití knihovny 2. Přidání reference na knihovnu

• Po pravé straně se nachází SolutionExplorer, stisknutím pravého tlačítka vyvoláme nabídku pro přidání projektu (obr. E.2).

Obrázek E.2: Přidání reference

• Ve složce, kde se nachází projekt knihovny vybereme soubor s příponou .csproj (obr. E.3). 98

Obrázek E.3: Vybrání projektu

• Ve vytvořeném projektu klikneme pravým tlačítkem na záložku Reference a přidáme referenci na přidaný projekt (obr. E.4, obr. E.5).

Obrázek E.4: Přidání reference v projektu 99

E. Příklad použití knihovny

Obrázek E.5: Přidání reference v projektu

3. Vytvoření a inicializace Renderer • Ve vytvořené třídě, která je potomkem třídy Game přidáme nový atribut Renderer renderer; • V metodě Initialize() vytvoříme instanci rendereru, v našem případě SipleRenderer. protected override void Initialize() { this.IsMouseVisible = true; renderer = new SimpleRender(GraphicsDevice); base.Initialize(); }

• Referenci na Renderer a stejně tak i na další třídy přidáme jednoduše poklepáním pravým tlačítkem na jméno třídy a výběrem Resolve nalezneme správný jmenný prostor (obr. E.6 ). 100

Obrázek E.6: Přidání reference na třídu Renderer

• V metodách Update a Draw přidáme volání těch samých metod na Renderer

protected override void Update(GameTime gameTime) { ... renderer.Update(gameTime); base.Update(gameTime); } protected override void Draw(GameTime gameTime) { ... renderer.Draw(gameTime); base.Draw(gameTime); } 4. Přidávání grafického obsahu do projektu (obr. E.7) • Veškerý grafický obsah se do projektu přidává pomocí projektu NázevNašehoProjektuContent, který se vytvořil společně s novým projektem. Přidání se děje podobně jako v celém Solution exploreru. Pravým tlačítkem Add -> Existing Item. 101

E. Příklad použití knihovny

Obrázek E.7: Přidání obrázků • V kódu se poté obsah nahraje pomocí properties Content, která je součástí třídy Game. Pozor, musí se zapsat celá cesta k obsahu a bez koncové přípony. Icon icon = new Icon(Content.Load("images\logo_inverzni")); 5. Příklad kódu inicializace prvků V prvním příkladě vytváříme velmi jednoduché UI. Panel obsahuje pouze ikonu a dvě tlačítka jejichž stiskem se mění text popisku nahoře. Panel je pohyblivý, stačí vzít za modré kolečko v rohu panelu a lze jej přemisťovat kamkoliv (obr. F.4). protected override void LoadContent() { Panel panel = new Panel(); panel.Layout = new VerticalLayout(10, VerticalLayout.Align.CENTER); panel.Border = new LineBorder(GraphicsDevice, Color.White); //MOVEBUTTON MoveButton mb = new MoveButton(20, 20, panel); mb.setAllTextures(Content.Load("button_move_NOTAFFECTED")); mb.HoverTexture = Content.Load("button_move_HOVER"); mb.PressedTexture = Content.Load("button_move_DOWN");

102

//ICON Icon icon = new Icon(Content.Load("logo_inverzni")); panel.AddElement(icon); //BUTTON 1 IN PANEL SpriteFont font=Content.Load<SpriteFont>("fonts/gamefont12"); Button b1 = new Button(100, 30,font,"Button 1"); b1.setAllTextures(Content.Load("button_long_NOTAFFECTED")); b1.HoverTexture = Content.Load("button_long_HOVER"); b1.PressedTexture = Content.Load("button_long_DOWN"); b1.ButtonAction_DOWN_LEFT = delegate{ ButtonAction("Pressed first button."); }; panel.AddElement(b1); //BUTTON 2 IN PANEL Button b2 = new Button(100, 30, font, "Button 2"); b2.setAllTextures(Content.Load("button_long_NOTAFFECTED")); b2.HoverTexture = Content.Load("button_long_HOVER"); b2.PressedTexture = Content.Load("button_long_DOWN"); b2.ButtonAction_DOWN_LEFT = delegate{ ButtonAction("Pressed second button."); }; panel.AddElement(b2); //INFO LABEL label = new Label("No action called.", font); //POSITIONING panel.Move(100, 50); mb.Move(panel.PositionX + panel.Width -10, panel.PositionY-mb.Height+10); //RENDER renderer.AddElement(panel); renderer.AddElement(mb); renderer.AddElement(label); } public void ButtonAction(String message){ label.Text = message; }

103

E. Příklad použití knihovny

Obrázek E.8: Grafický výstup příkladu, zdroj obrázku lva: grafický manuál ČVUT

104

Příloha

Uživatelská příručka hry Sepulcher F.1

Spuštění hry

Pro správný chod hry je zapotřebí mít spuštěný server. Na přiloženém DVD je připravený testovací server mého kolegy Václava Starého. Spustí se dávkovým souborem RUN.bat. V tomto souboru je potřeba změnit IP adresu. Port ponechte. Samotné spuštění hry se provede pomocí Sepulcher.exe. Pokud se ve formuláři zadá větší počet hráčů než jeden, čeká server na připojení tolika hráčů, kolik bylo zadáno. Na obrazovce se zobrazuje Loading....

F.2

Main menu

105

F

F. Uživatelská příručka hry Sepulcher

F.3

Multiplayer menu

F.4

Hra

F.4.1

Ovládání

• Escape otevře dialogové okno pro odchod ze hry. 106

F.4. Hra • Posun po mapě je umožněn šipkami. • Po výběru vlastnosti se lze znovu přepnout do chůze stisknutím pravého tlačítka myši (pozor nevybarví se dlaždice). • Stisknutí klávesy Enter ukončí kolo.

107