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

Rozšíření portálu Gamesites.cz Jiří Levý

Vedoucí práce: RNDr. Ondřej Suchý, Ph.D. 15. května 2014

Poděkování V první řadě bych chtěl poděkovat panu RNDr. Ondřejovi Suchému, Ph.D., který mi nesmírně pomohl při tvorbě bakalářské práce. Mimo jiné bych chtěl poděkovat za jeho přívětivý přístup a pohled na bakalářskou práci z jiné perspektivy. Dále bych chtěl poděkovat mé rodině, která mě plně podporovala ať již psychicky nebo finančně.

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 15. května 2014

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

České vysoké učení technické v Praze Fakulta informačních technologií © 2014 Jiří Levý. 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 Levý, Jiří. Rozšíření portálu Gamesites.cz. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

Abstract The ordering party of this thesis is the game portal Gamesites.cz. This bachelor thesis serves to players of multiplayer games. In the application, players group into clans which are associated with competitions. Basic types of competitions are league and tournament. A league is freely accessible to every player, while a tournament is for invited only. The clans will play a match against each other and store the result of the match into the application, which will count the score of each clan. Each league contains a list of clans ranked by the number of points they have won. Through this application, users can also book a server for a match. The whole application is controled from the administrator interface. Keywords Gamesites.cz, contest, game, web application

ix

Abstrakt Zadavatelem bakalářské práce je herní portál Gamesites.cz. Tato práce se zabývá tvorbou webové aplikace, která umožní hráčům multiplayerových her soupeřit v rámci soutěží. Základními typy soutěží jsou liga a turnaj. Liga je volně dostupná všem hráčům, kdežto turnaj je pouze pro pozvané. Hráči se sdružují do týmů, které mezi sebou odehrají utkání a výsledek vloží do aplikace, která přepočítá jejich aktuální skóre. Každá soutěž obsahuje výpis pořadí týmů podle počtu získaných bodů. Uživatelé též mají možnost prostřednictvím aplikace rezervovat server pro odehrání utkání. Celou aplikaci lze spravovat z administrátorského rozhraní. Klíčová slova Gamesites.cz, soutěž, hra, webová aplikace

x

Obsah Úvod

1

1 Specifikace bakalářské práce 1.1 Zadavatel . . . . . . . . . . . . . . 1.2 Účel aplikace z pohledu zadavatele 1.3 Specifikace zadání . . . . . . . . . . 1.4 Vymezení cílů . . . . . . . . . . . . 1.5 Nefunkční požadavky . . . . . . . . 1.6 Funkční požadavky . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3 3 4 5 6 6 6

2 Vybraná konkurenční řešení 2.1 Playzone . . . . . . . . . . 2.2 Undzwei . . . . . . . . . . 2.3 Shifters.eu . . . . . . . . . 2.4 Gamester . . . . . . . . . 2.5 Vyhodnocení . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

11 12 13 15 16 18

3 Analýza 3.1 Model požadavků . . . . . . . 3.2 Model případů užití . . . . . . 3.3 Analytický doménový model . 3.4 Komunikace s herními servery

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

19 19 22 32 37

. . . . .

4 Návrh aplikace 41 4.1 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3 Databázový model . . . . . . . . . . . . . . . . . . . . . . . 48 xi

5 Implementace 55 5.1 Popis aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2 Nestandardní části aplikace . . . . . . . . . . . . . . . . . . 57 6 Testování 59 6.1 Obecné testování aplikace . . . . . . . . . . . . . . . . . . . 59 6.2 Komunikace s herními servery . . . . . . . . . . . . . . . . . 59 Závěr

61

Literatura

63

A Screenshoty aplikace

67

B Obsah přiloženého CD

71

xii

Seznam obrázků 2.1 2.2 2.3 2.4

Screenshot Screenshot Screenshot Screenshot

portálu portálu portálu portálu

Playzone . Undzwei . Shifters . . Gamester

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

12 14 15 17

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14

Funkční a nefunkční požadavky . . . . . . . . . . . Model případů užití . . . . . . . . . . . . . . . . . . Účastníci případů užití . . . . . . . . . . . . . . . . Případy užití . . . . . . . . . . . . . . . . . . . . . Model případů užití — správa lig . . . . . . . . . . Model případů užití — správa turnajů . . . . . . . Model případů užití — správa administrátorů . . . Model případů užití — správa serverů . . . . . . . . Model případů užití — správa klanů . . . . . . . . Model případů užití — přihlašování do lig a turnajů Model případů užití — správa zápasů . . . . . . . . Model případů užití — správa zápasů . . . . . . . . Model případů užití — rezervace herních serverů . . Doménový model . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

20 23 24 25 26 26 27 28 29 30 31 31 32 33

4.1 4.2

Model architektury aplikace . . . . . . . . . . . . . . . . . . . . Databázový model . . . . . . . . . . . . . . . . . . . . . . . . .

46 49

5.1

Adresářová struktura aplikace . . . . . . . . . . . . . . . . . . .

57

6.1 6.2

Údaje před rezervací . . . . . . . . . . . . . . . . . . . . . . . . Údaje po rezervac . . . . . . . . . . . . . . . . . . . . . . . . . .

60 60

A.1 Správa administrátorů . . . . . . . . . . . . . . . . . . . . . . .

67

xiii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

A.2 Detail ligy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Výpis turnajů . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.4 Profil klanu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xiv

68 69 70

Úvod V současné době, kdy je internet v civilizovaném světě již samozřejmostí, se mnoho lidí upíná k virtuální realitě. Nezáleží přitom na pohlaví, věku či jiných fyzických i psychických dispozicích, neboť každý potřebuje občas relaxovat a právě virtuální realita je jednou z možností odpočinku. Zadavatel této bakalářské práce, herní portál Gamesites.cz, nás oslovil, abychom rozšířili jejich stávající webovou aplikaci o další funkcionalitu, konkrétně o možnost pořádání lig a turnajů v online hrách typu first-person action (akční hry z pohledu první osoby). Původně jsme měli pouze vytvořit knihovnu, která by se jednoduchým způsobem napojila na aplikaci. Po dalším jednání se zadavatelem ovšem došlo ke změně a výsledkem je samostatná webová aplikace, jež je dostupná na subdoméně ligy.gamesites.cz a je napojená na databázi uživatelů webových stránek zadavatele.

1

Kapitola

Specifikace bakalářské práce V této kapitole je podrobně rozepsáno zadání bakalářské práce. Kapitola popisuje řešený problém, vymezuje cíle projektu a uvádí funkční a nefunkční požadavky na implementovaný systém.

1.1

Zadavatel

Zadavatelem této bakalářské práce je portál Gamesites dostupný na webové adrese http://www.gamesites.cz/ [4]. Tento portál se zabývá počítačovými hrami a je určen pro hráče z celého světa, převážně však z České republiky a Slovenska. Slouží jako prostor pro sdružování hráčů multiplayerových her, za tímto účelem nabízí zadavatel vlastní herní servery pro hry, kterými se zabývá, a umožňuje hráčům tyto servery volně využívat. Každý se může na tyto servery připojit a hrát proti hráčům z celého světa. Mezi zástupce her se serverovou podporou patří Counter-Strike 1.6, Counter-Strike: Source, World of Warcraft, Team Fortress 2, Minecraft, Grand Theft Auto — San Andreas, Call of duty 4, Counter-Strike: Global Offensive. Pro naší práci implementujeme prozatím na přání zadavatele podporu pouze pro hru Counter-Strike 1.6 (podrobnosti o této hře lze nalézt na webové adrese http://store.steampowered.com/app/10/ [23]). Obecně portál obsahuje množství informací nejen o výše zmíněných hrách. Předkládá uživatelům spousty článků a novinek ze světa her, částečně tvoří obsah stránek i samotní uživatelé formou vlastních příspěvků. Pro návštěvníky webových stránek umožňuje hraní online her přímo v prohlížeči a v neposlední řadě se mohou zúčastnit vědomostních či dovednostních soutěží o zajímavé ceny. Na portálu si každý uživatel může založit vlastní uživatelský účet, čímž se vytvoří veřejný profil uživatele. Do profilu lze doplnit obrázek, nastavit 3

1

1. Specifikace bakalářské práce osobní informace, kontaktní údaje, oblíbené hry a zvolit, zda se tyto informace mají zobrazovat veřejně. Pro komunikace s ostatními hráči je k dispozici hned několik možností — uživatelé si mohou zasílat soukromé zprávy, chatovat pomocí živého chatu, přispívat do diskuzních fór nebo zveřejňovat příspěvky na nástěnku svého profilu. Ostatní uživatelé mohou příspěvky na nástěnce komentovat. Prostřednictvím portálu si uživatelé mohou vytvořit vlastní blog, do kterého lze přidávat libovolné články. Články mohou být převzaté či vlastnoručně napsané, poté jsou zveřejněny návštěvníkům, kteří je mohou hodnotit, komentovat a sdílet prostřednictvím sociálních sítí. Nejlepší z blogů jsou zadavatelem na základě uživatelského hodnocení odměňovány zajímavými cenami. V rámci svého profilu lze vytvářet a spravovat obrázkové galerie, které jsou rovněž přístupné všem návštěvníkům portálu. Zajímavou funkcí profilu je seznam přátel, což zjednodušuje sledování aktivity vybraných jedinců a jejich příspěvků na blogu či nástěnce. Další funkcí nástěnky je logování aktivit, kam se zapisují akce jako přidání obrázků do galerie, přidání komentáře k příspěvku ostatních uživatelů apod. Pro náročné uživatele portál nabízí VIP účet, který přináší nejrůznější výhody a rozšířená nastavení. VIP hráč má rezervovaný slot na serveru, takže se může připojit do hry i přes naplnění kapacity herního serveru, dále má oproti normálním uživatelům bonusy jako jsou zvětšený počet bodů života, rychlejší pohyb herního charakteru apod. (záleží na typu hry). Na webových stránkách má u jména nastaven příznak „VIP“ a na svém profilu může na pozadí nastavit obrázek, což oživí vzhled stránky s profilem uživatele (profily jsou často hráči sdíleny na sociálních sítích).

1.2

Účel aplikace z pohledu zadavatele

Portál postrádá jakýkoliv zápasový systém, nyní pouze umožňuje uživatelům hrát neorganizovaně. Největší konkurenti však podobnou funkcionalitu nabízejí, ať již pouze v omezené míře (pro vybrané hry) nebo s plnou podporou. Účelem této bakalářské práce tedy je vytvořit soutěžní systém pro výše zmíněné hry za účelem zlepšení konkurenceschopnosti portálu. V rámci bakalářské práce se budeme soustředit pouze na hru Counter-Strike 1.6, kterou na portálu hraje nejvíce uživatelů, a proto byla vybrána jako první pro nasazení systému. Další hry budou doplněny mimo rámec bakalářské práce, systém však již musí počítat s budoucím rozšířením. Nynější podpora více her by přesáhla rámec bakalářské práce. 4

1.3. Specifikace zadání Aplikace slouží hráčům akčních online multiplayerových first-person her. Hráči se v prostředí aplikace sdružují do klanů, které jsou součástí soutěží — lig a turnajů. Účelem systému je umožnit uživatelům soupeření v jejich oblíbených hrách v rámci organizovaných soutěží. Zadavatel plánuje do budoucna odměňovat klany na prvních příčkách vybraných soutěží věcnými dary, čímž zvýší motivaci hráčů. Záměrem je přilákat nové uživatele do stávajícího portálu a rozšířit tak uživatelskou komunitu a tím zvýšit svou atraktivitu pro zadavatele reklam.

1.3

Specifikace zadání

Aplikace je rozdělena do dvou základních částí — Backend a Frontend. Backend představuje administraci aplikace, do této sekce má přístup administrátor a systémový uživatel — osoba s rolí „admin“ a „superadmin“. Sekce Frontend je volně přístupná všem osobám, pro přístup do této sekce není nutné žádné zvláštní oprávnění. Pokud však není osoba přihlášena, nemá přístup k žádné akci a může pouze prohlížet obsah webové aplikace. Uživatel je osoba, která je registrována na stávajícím portálu zadavatele a zadá do systému téže přihlašovací údaje, díky čemůž získá identitu s rolí „uživatele“. Uživatelé se sdružují do týmů, které se nazývají klany. Klan je základní jednotkou pro účast v soutěžích, má svého vůdce, což je ve výchozím nastavení zakladatel klanu a může přidělovat jednotlivým členům oprávnění pro správu klanu. Liga je soutěž, která je volně přístupná všem klanům — do ligy se mohou přihlásit bez povolení administrátora. Turnaj je soutěž pouze pro pozvané, do turnaje musí být klan pozván administrátorem (správcem turnaje). Zápas je hlavní jednotkou soutěží, vždy se zápasu účastní dva klany — domácí a hosté. K domluvení zápasu slouží výzvy, které mezi sebou klany rozesílají a jejich přijetím je sjednán zápas. Zápasy jsou odehrávány na herních serverech, které má zadavatel pronajaté třetí stranou, ale utkání mohou probíhat i na serverech, které neposkytuje zadavatel — pro účel aplikace je důležité vložit výsledek zápasu. Výsledek zápasu je poté vyhodnocen a jsou vypočítány ukazatele rankingového skóre pro jednolivé soutěže. Podle těchto ukazatelů (zpravidla body) jsou klany v jednotlivých soutěžích řazeny do žebříčku. Při ukončení ligy vítězí klan s nejvyšším skóre. Klany si mohou zarezervovat server pro odehrání zápasu prostřednictvím aplikace. Rezervace je vždy určená na hodinu a musí být omezen počet rezervací, které klan může během dne vytvořit. Toto je nutné z důvodu eliminace blokování serverového času klany. Rezervace bude umožněna tak, 5

1. Specifikace bakalářské práce že aplikace nastaví přístupové heslo pro připojení k hernímu serveru, které při vytvoření rezervace zadá uživatel.

1.4

Vymezení cílů

Cílem bakalářské práce je vytvoření webové aplikace napojené na databázi uživatelů herního portálu Gamesites.cz. Uživatelé se budou přihlašovat do systému pomocí svého účtu na stávajícím portálu zadavatele. Důležitou součástí webové aplikace je její propojení s herními servery pomocí scriptovacího jazyka PHP, čímž bude umožněno aplikaci kontrolovat dané herní servery. Zjištění možností komunikace aplikace s herními servery a volba implementace je součástí této práce. Aplikace umožní vytvářet soutěže pro vícero her, ovšem zaměříme se pouze na hru Counter-Strike 1.6 [23], a to z toho důvodu, že implementace rozhraní pro vícero her by byla nad rámec této práce. Mezi hráčskou komunitou je Counter-Strike 1.6 jednou z nejoblíbenějších her, a proto si zadavatel přeje primárně implementovat podporu pouze pro tuto hru. Stavba aplikace bude však navržená tak, aby bylo možné s minimálním úsilím přidat další hry.

1.5

Nefunkční požadavky

Nefunkční požadavky jsou takové požadavky, které nesouvisejí přímo s funkcemi aplikace, jsou to požadavky na systém, použité technologie a přenositelnost aplikace. Tyto požadavky jsou přímo určeny zadavatelem. Systém bude přístupný jako webová aplikace, kterou lze zobrazit v libovolném internetovém prohlížeči. Není nutné vytvářet žádnou optimalizaci pro přenosná zařízení jako jsou mobilní telefony či tablety. Vzhledem k plánované integraci se serverovým prostředím zadavatele je nutné aplikaci implementovat prostřednictvím PHP frameworku Nette (sekce 4.1.7). Ze stejného důvodu pro úschovu dat systém využívá relační databázi MySQL (sekce 4.1.6). Aplikace musí zvládat komunikaci s herními servery pomocí jazyka PHP, aby nebylo potřeba žádného dalšího nástroje než jsou výše zmíněné. PHP musí splňovat konvence verze 5.3, neboť zadavatelův server podporuje momentálně právě verzi PHP 5.3.

1.6

Funkční požadavky

Funkční požadavky na systém popisují jednotlivou funkcionalitu aplikace. Jsou to veškeré funkce, které musí aplikace umožňovat dle zadání. Tyto 6

1.6. Funkční požadavky požadavky jsou přímo určeny zadavatelem.

1.6.1

Administrátorské prostředí — Backend

Do tohoto prostředí má přístup pouze administrátor. Jedná se o uživatelský účet, který má přidělené vyšší oprávnění. Prostředí obsahuje administrátorské rozhraní pro ligy a turnaje, které má za úkol je zobrazovat, vytvářet, editovat a mazat. Také administrace serverů je důležitou součástí, neboť herní servery nejsou statickou záležitostí a je nutné mít možnost je spravovat. Servery bude možno též vytvářet, editovat a mazat.

1.6.2

Liga a turnaj

Liga obsahuje informace jako název, popis, začátek a konec, případně obrázek. Informace o začátku ligy určuje, kdy se liga zobrazí na frontendu pro hráče, což umožní správcům ligy předdefinovat soutěže předem či pozměnit jejich údaje před zveřejněním. Informace o konci ligy určuje, kdy bude liga ukončena, po ukončení ligy systém vyhodnotí výherce podle dosaženého rankingového skóre. Liga je vždy přiřazená k jedné z předdefinovaných her, tyto hry do budoucna doplní zadavatel — v počáteční fázi se bude jednat o hru Counter-Strike 1.6. Liga se zobrazí ve výpisu na frontendu jakmile aktuální datum a čas bude větší než informace o začátku, to znamená, že nebude mít žádný příznak viditelnosti a každá vytvořená liga bude veřejně přístupná pro uživatele. Editace ligy se projeví ihned, nebereme v úvahu žádné verzování údajů, ale editujeme přímo stávající údaje. Smazání ligy nebude trvalé, pouze bude tato liga skryta uživatelům. Veškerá data smazané ligy bude možné později dohledat v databázi z důvodu uchování historie a případnému sledování poklesu či nárustu aktivity uživatelů. Do ligy se mohou přidávat klany libovolně bez dohledu administrátora. Zobrazením detailu ligy na frontendu máme přístup k informacím o dané lize, což kromě výše zmíněných informací je také soupis klanů hrajících ligu, jejich rankingové skóre a statistiky zápasů. Turnaj je liga rozšířená o další informace a přísnější pravidla. Není veřejně přístupný pro účast uživatelů, klan musí být do turnaje pozván. Pozvat dané klany může pouze administrátor (správce turnaje). Systém pozvaným klanům zašle pozvánku do turnaje, jejímž přijetím se mohou do turnaje zapojit. Turnaj má také předem dané rozlosování zápasů, kde lze zvolit mezi schématem vyřazovacím (pavouk) nebo každý s každým (tabulka). Vyřazovací rozlosování zápasů bude provedeno automaticky, kde náhodně systém vybere z přihlášených klanů protivníky a vytvoří zápasového pavouka. Systém určí pouze rozlosování zápasů, ne jejich datum konání. Uskutečnění 7

1. Specifikace bakalářské práce zápasu bude tedy vždy na domluvě mezi danými klany, ovšem do předem určeného data musí zápas proběhnout, jinak administrátor zvolí vítěze kontumačně. Z toho vyplývá, že administrátor musí mít možnost kontrolovat manuálně výsledek zápasů.

1.6.3

Uživatel a klan

Nepřihlášený uživatel má možnost listovat jednotlivými ligami a turnaji v kategoriích dle příslušné hry, sledovat žebříčky klanů, výsledky zápasů, zobrazovat detaily klanu a podobně. Přihlášený uživatel má možnost vytvořit svůj klan a vybrat si spoluhráče, nebo se přidat k již existujícímu klanu formou pozvánek. Klan je základní jednotkou ligy i turnaje — do ligy se může přidat, do turnaje musí být pozván. Klan je v podstatě tým složený z několika hráčů. Každý klan je spojen právě s jednou soutěží, tyto klany se poté mohou účastnit i turnajů, do kterých jsou pozvány. Uživatel má možnost vytvořit nové klany, které může jako vlastník editovat, mazat, pozvat hráče do klanu nebo hráče vyloučit. Dále může měnit role jednotlivých členů klanu a tím i jejich oprávnění k úkonům, které mohou být vykonávány ve výchozím nastavení pouze z pozice vlastníka klanu. Uživatel v klanové roli „vůdce“ může vkládat výsledky zápasů či je potvrzovat, přijímat pozvánky do turnajů a zasílat či potvrzovat výzvy. Počet klanů pro jednoho uživatele není omezen, ovšem v rámci jedné soutěže může být uživatel členem pouze jednoho klanu.

1.6.4

Zápas

Liga i turnaj sestává ze zápasů, které musí být sjednány vždy mezi dvěma klany. Sjednání probíhá výzvou a následným přijetím výzvy. Zápas proběhne na některém ze serverů nabízených zadavatelem či na nějakém externím serveru, pokud budou oba klany souhlasit. Po utkání „vůdce“ klanu uloží výsledek do systému. Výsledek musí být „vůdcem“ druhého klanu potvrzen. Jako důkaz o pravdivosti výsledku se dokládají screenshoty skóre dosaženého v zápase, a to pořízené v polovině a na konci zápasu. Systém z výsledků zápasů počítá skóre, dle kterého je určeno pořadí klanů v dané soutěži. Množství odehraných zápasů klanu není nijak omezené, což znamená čím aktivnější klan je, tím větší má šanci umístit se na předních pozicích ligy. Pro zadavatele je značným přínosem, pokud systém hráče nutí odehrát co nejvíce zápasů za účelem zlepšení pozice v žebříčku. Liga má omezené trvání — datum ukončení ligy, po jejím ukončení vítězí klan s nejvyšším skóre. 8

1.6. Funkční požadavky

1.6.5

Herní server

Herní server je přidáván do systému za účelem nabídnutí prostoru pro konání zápasů. Administrátor zadá informace o serveru do systému, mezi které patří název, výchozí RCON heslo (heslo pro přístup k plnému ovládání konzole serveru ze vzdáleného klienta — Remote CONsole), adresa serveru (IP adresa serveru včetně portu ve tvaru 255.255.255.255:27015). Dále je server přiřazen k jedné z předdefinovaných her, které jsou dodány od zadavatele (zatím pouze Counter-Strike 1.6). Server je zobrazen v detailu soutěže dle hry, k níž byl přiřazen. Pokud tedy server přiřadíme k dané hře, musí být zobrazen ve všech soutěžích dané hry. V soutěžích jiných her se zobrazovat nebude. Server má svůj rezervační kalendář, kde si klany mohou server zamluvit na určitý datum a čas a nastavit si požadované heslo pro vstup na server, čímž bude umožněn vstup na server pouze danému klanu. Toto heslo poté klan předá soupeři například pomocí soukromé zprávy v rámci aplikace, externího komunikačního programu apod. Klan však může sjednat rezervaci na všech serverech dané hry dohromady pouze na hodinu denně — hodina je rezervační jednotka, server se vždy rezervuje na hodinu, a tak je umožňena klanům rezervace pouze jedné jednotky denně (požadavek zadavatele). Hlavním důvodem je spravedlivost při zamlouvání serverů, navíc si uživatelé rozmyslí, zda server v danou dobu opravdu využijí. Takto bude zmírněn dopad falešných rezervací a zbytečné blokování serveru.

9

Kapitola

Vybraná konkurenční řešení Obsahem této kapitoly je analýza veřejně přístupných webových portálů, které se zabývají obdobnou tematikou jako tato práce. Hlavním smyslem této analýzy je pohled na ostatní webové portály z pohledu uživatele, vytyčení jejich kladů a záporů a celkové zhodnocení, které nám pomůže s následnou analýzou požadavků, prohloubí nám pohled na problém a umožní nám vyvarovat se chyb, kterých se tato řešení dopustila. Jelikož se zaměřujeme prioritně na tuzemskou herní komunitu, byly vybrány nejznámější portály se stejnou cílovou skupinou zprostředkovávající obdobnou funkcionalitu. Problém nastává ve chvíli, kdy chceme zjistit něco o vnitřní logice či implementaci jednotlivých systémů. Protože se jedná o webové aplikace, není možné zjistit, co se skrývá za zobrazením jednotlivých stránek uživateli — jedná se o „know-how“ jednotlivých majitelů portálů. Z tohoto důvodu se budeme zabývat pouze uživatelským rozhraním a případy užití těchto vybraných serverů. Uživatelské rozhraní je pro nás pouze orientační hledisko hodnocení, neboť designem aplikace se nebudeme zabývat. Zadavatel si design vytvoří sám a ten bude posléze aplikován na naše řešení. Aby se však nemusela předělávat logika rozložení a akcí, musí být aplikace navržená tak, aby byla pružná a dala se přizpůsobit později aplikovanému designu. U konkurenčních řešení se tedy budeme zabývat konrétně uživatelským rozhraním — zda je webová prezentace jako taková přehledná, zda jsou vytipované akce (přehled soutěží, zapojení se do soutěže, filtrování soutěží apod.) bez většího úsilí vykonatelné. Dalším bodem této kapitoly bude rozbor obecné funkcionality portálů, což nám umožní převzít některé zajímavé funkce pro naší aplikaci. 11

2

2. Vybraná konkurenční řešení

2.1

Playzone

Portál Playzone [18] je velkým jménem v prostředí počítačových her. Majitelem serveru je společnost PLAYzone s.r.o.. Významně podporuje rozvoj online her v České republice a na Slovensku. Denně vydává články o novinkách z domácí i zahraniční hráčské scény, nabízí velké množství uživatelských funkcí jako blogy, fórum, sázkový systém, videa a další. Pro hráče nabízí několik desítek lig a turnajů a zprostředkovává desítky herních serverů. Také organizuje nejrůznější soutěže, turnaje a kvalifikace na prestižní světové soutěže a od roku 2011 je pořadatelem Mistrovství České republiky v počítačových hrách.

Obrázek 2.1: Snímek obrazovky herního portálu playzone.cz

2.1.1

Rozbor

Uživatelské rozhraní není až tak přátelské, jak by se dalo u takového serveru čekat. Množství reklam odvádí pozornost od konkrétního obsahu, částečně s ním splývá — viz obrázek 2.1. Uživatel musí ligy a turnaje složitě vyhledávat přes menu, které obsahuje nelogicky rozložené podsekce. Přihlášení do některé z lig či turnajů není vůbec jednoduchá záležitost, zobrazuje se zde množství funkcionalit schovaných za odkazy, ke kterým má přístup pouze přihlášený uživatel. Nepřihlášený uživatel tedy ani netuší, jaké funkce portál nabízí pro přihlášené uživatele. Stránky jsou z celkového pohledu zastaralé, kromě obměny reklam se od doby spuštění stránek (rok 2009) nic zásadního nezměnilo. Hlavním důvodem dle našeho názoru bude nejspíše obrovské množství záležitostí, kterými se portál zabývá. 12

2.2. Undzwei Z hlediska funkcionality je určitě největším přínosem možnost založit si prostřednictvím portálu vlastní turnaj. Uživateli to umožňuje zahrát si své oblíbené hry s ostatními hráči i ve chvíli, kdy hra není tak rozšířená či jí již nahradila novější verze a obecně se turnaje nepořádají. Portál má kvůli nepřehlednému uživatelskému rozhraní mnoho funkcí schovaných až na konkrétních podstránkách, což uživateli neumožňuje jednoduchým způsobem naplno využít potenciál systému — systém nabízí mnoho funkcí, ale uživatel zjišťuje až po delší době používání, že je lze využívat. Mezi obtížně nalezitelné funkce patří například hledání soupeře pro zápas, zobrazení hráčů a týmů v síni slávy či samotné zapojení se do soutěže. Tyto akce jsou schovány až na konkrétní podstránce soutěže a běžný uživatel o nich nemusí vědět, pokud nebude pozorně zkoumat stránky.

2.1.2

Shrnutí poznatků

Portál Playzone je opravdu robustní, ubírá se cestou kvantity na úkor kvality. Uživatelské rozhraní je nepřehledné, ale funkcionalita je mimořádná. Hlavní výhodou je podpora uživatelů v rámci možnosti vytvoření vlastního turnaje. Změnou uživatelského rozhraní (designu) by server nejspíše získal mnohem více uživatelů, než má nyní.

2.2

Undzwei

Portál Undzwei.eu [22] je zástupcem slovenské pořadatelské scény, mezi hráči je i v tuzemsku velmi oblíbený. Pořádá již od roku 2003 množství lig a turnajů, do kterých se může zapojit každý. Jeho hlavní náplní je zprostředkování zápasů několika her, mezi něž patří i námi sledovaný CounterStrike 1.6. Tento web pořádá soutěže o hodnotné ceny, zejména počítačové komponenty, které dodávají sponzoři, čímž se stává pro herní komunitu zajímavějším.

2.2.1

Rozbor

Z hlediska uživatelského rozhraní jsou stránky celkem přehledné. Jednoduché menu má kvalitně rozřazené položky, podpoložky slouží jako samotný filtr pro hry, které nás zajímají. Značnou vadou menu je pouze to, že submenu je řešené javascriptem a nelze tedy sledovat cestu skrze menu. Toto by se dalo vyřešit pomocí „drobečkové navigace“ [1], kde je zachycena cesta z domovské stránky až na aktuální podstránku. Uživatelský panel je součástí rozložení stránky, nachází se přímo na očích a ovládání herních akcí je 13

2. Vybraná konkurenční řešení

Obrázek 2.2: Snímek obrazovky herního portálu undzwei.eu tedy jednoduchá záležitost (viz obrázek 2.2). Opět je zde patrné, že web je rozsáhlý a zabývá se vícero hrami najednou, čímž je pro uživatele obtížnější vyhledat požadované informace. Portál vlastní herní servery, na které je možné se připojit a hrát volně s ostatními hráči (jedná se o veřejné servery, kde hráči hrají proti sobě neorganizovaně všichni proti všem). Tyto servery však nelze rezervovat pro uskutečnění zápasu v soutěži, což je celkem nevýhodou, neboť hráči jsou nuceni sehnat prostor pro odehrání zápasu jinde. Kromě možnosti zapojit se do soupeření v hrách umožňuje portál také vkládat videa pořízená při zápasech. Obsahuje návody jak samotná videa pořizovat a vložená videa lze posléze hodnotit a filtrovat, takže si každý fanoušek přijde na své. Dále obsahuje jednoduchý chatovací prostor, kde hráči mohou v reálném čase diskutovat či hledat nové přátele a spoluhráče. Novinky z herního prostředí jsou formou článků předkládány jako seznam uživateli a jsou zobrazeny na každé stránce a podstránce kromě chatu (viz obrázek 2.2 — box s novinkami). Každý článek obsahuje u názvu ikonku hry a tak se uživatel ve výpisu lehce orientuje. Dále je zde stejným způsobem jako novinky zobrazen box pro hledání soupeřů, což umožňuje uživatelům rychlým způsobem sehnat protivníka pro zápas (viz obrázek 2.2 — box pro hledání soupeře). Dalším boxem na téměř každé stránce je seznam zajímavých zápasů, na které portál doporučuje se podívat pomocí připojení se k HLTV. HLTV (Half Life TV) [6] je speciální server, na kterém je uživatel pouze v modu diváka a může si vybírat pohledy ve hře hrajících hráčů nebo se volně pohybovat po mapě. Portál také umožňuje rozesílání zpráv mezi uživateli a přidávání se vzájemně do přátel. Každý uživatel si navíc na 14

2.3. Shifters.eu portálu může vytvořit svůj blog či galerii obrázků.

2.2.2

Shrnutí poznatků

Uživatelské rozhraní je až na drobné nedostatky celkem přehledné, s ohledem na to, že stránky obsahují velké množství informací a funkcionalit, které není vždy úplně jednoduché vytřídit. Z hlediska funkcionalit zde tvoří hlavní přínos box pro hledání soupeře, který je zobrazen téměř na každé stránce portálu. Další výhodou je uživatelský box, který je přehledný a umožňuje uživateli lépe se orientovat na stránce — jedná se o ovládací panel přihlášeného uživatele, který má k dispozici na každé stránce a usnadňuje správu klanů, zápasů, zpráv, svého účtu apod.

2.3

Shifters.eu

Portál Shifters.eu [21] patří mezi méně známé herní portály. Jeho hlavní náplní je zprostředkování soutěží uživatelům se zaměřením na ligy a turnaje v několika hrách. Mezi ně opět patří námi sledovaná hra Counter-Strike 1.6. Obecné informace o tomto portálu nejsou na webových stránkách k dohledání, podrobnější informace o portálu tedy není možné uvést.

Obrázek 2.3: Snímek obrazovky herního portálu shifters.eu

2.3.1

Rozbor

Na první pohled je uživatelské rozhraní čisté, jednoduché a přehledné. Hlavní menu je srozumitelné stejně jako podkategorie. Množství boxů v rozložení 15

2. Vybraná konkurenční řešení stránky logicky i vizuálně odděluje jednotlivé informace. Slabší částí je přehled turnajů, kde je rozdělení dle her pouze pomocí ikonky dané hry, což činí filtrování na zaměřenou hru obtížnější. Turnaje jsou seřazeny od aktuálních po minulé. Zajímavé je, že u lig tomu tak není. Výpis lig je totiž setříděn dle jednotlivých her a filtrování zde není zapotřebí. Nedostatkem je uživatelská sekce, která je přístupná pouze v menu pod položkou „portál“ (viz obrázek 2.3), uživatel tedy složitěji hledá, kde se má přihlásit či registrovat. Důležitým prvkem je opět box pro rychlé hledání soupeřů. Zajímavou funkcí je sázkový systém založený na virtuálním platidlu, který umožňuje sázet na zápasy soutěží pořádaných portálem. Dále obsahuje portál výpis aktuálních turnajů také v boxu, takže uživatel je schopen přehledně kontrolovat aktuální turnaje a případně se zapojit. Portál nabízí prostor pro odehrání soutěžních zápasů. Má pro tento účel vytvořené vlastní servery, kde je trvale nastavené heslo k serveru a také RCON heslo k administrátorské konzoli serveru (přes vzdálenou konzoli nelze změnit administrátorské heslo). Není zde však žádná možnost server rezervovat a spoléhá se na dohodu mezi jednolivými hráči. Pokud je server volný, lze jej na zápas využít.

2.3.2

Shrnutí poznatků

Uživatelské rozhraní je celkově přehledné, jednoduché až na uživatelskou sekci. Mezi funkční výhody portálu patří opět přehledný box pro hledání soupeře. Zajímavá je možnost sázení na zápasy. Nabídka herních serverů pro konání jednotlivých soutěžních zápasů rozhodně přidává portálu plusové body, nevýhodou je však, že servery nelze rezervovat.

2.4

Gamester

Portál Gamester [28] je dalším zástupcem méně známých portálů, zaměřuje se hlavně na hru Counter-Strike, pro kterou pořádá turnaje. Je podporován poskytovatelem internetového připojení AVONET [3], který zprostředkovává portálu hosting pro webové stránky i vlastní herní servery. Majitelem a hlavním programátorem portálu je jeden z hráčů hry Counter-Strike. Portál také formou článků zveřejňuje novinky ze světa her.

2.4.1

Rozbor

Stránky jsou jednoduché, přehledné, na uživatele působí velmi přirozeně. Menu je logicky dobře rozdělené, není zde žádné submenu a pro detailnější 16

2.4. Gamester

Obrázek 2.4: Snímek obrazovky herního portálu gamester.avonet.cz navigaci jsou prokliky přímo v obsahu stránky. Například na profil uživatele se lze dostat pouze z odkazu v obsahu stránky, což není vůbec na škodu, neboť ne vše by mělo být v menu. Veškerý obsah na stránkách je opticky rozdělen na jednotlivé boxy, které zjednodušují orientaci na stránce a třídí informace, které se poté lépe zpracovávají okem návštěvníka. Jednoduchou, strojovou grafiku prokládá několik efektů, čímž jsou stránky zajímavější pro uživatele. Příkladem může být zápatí stránek, kde obrázek přesahuje z jednoho boxu do druhého, což vytváří prostorový efekt. Dále jsou stránky oživeny množstvím obrázků vkládaných často jako hlavička článku. Funkcionalitou tento portál zaostává za ostatními. Pořádání turnajů není až tak časté, hráči musejí čekat na naplnění kapacity turnaje, než se může soupeřit. Portál zprostředkovává vlastní veřejné servery pro hru Counter-Strike a k nim umožňuje uživatelům zobrazovat statistiky. Výhodou je, že pro své turnaje Gamester poskytuje i serverový prostor, kde je možné odehrát zápasy. Tyto servery se ovládají pomocí nadstavby nad administrátorskou konzolí (AMX mod X), která umožňuje ovládat server přímo z herního chatu, tudíž není nutné znát přístupy k administrátorské konzoli — více podrobností v sekci 3.4.4.

2.4.2

Shrnutí poznatků

Jednoduchost a přehlednost stránek je dělají uživatelsky přívětivé. Zaměření na jednu konkrétní hru neodvádí pozornost a většina informací je k tématu. Výhodou je poskytování vlastních herních serverů a vedení podrobnějších 17

2. Vybraná konkurenční řešení statistik. Nevýhodou je nedostatek soutěží a nutnost čekání na zahájení soutěže. Portálu by jistě prospěla větší reklama, čímž by se stal známější a mohl rozšiřovat své působení.

2.5

Vyhodnocení

Hlavním účelem rozboru vybraných konkurenčních řešení bylo vytřídění jejich kladů a záporů tak, abychom se v naší aplikaci vyvarovali nedostatků a zároveň pokryli co největší množství funkcionalit, které nabízí konkurenční servery. Z hlediska uživatelského rozhraní je důležitá jednoduchost a přehlednost. Návrh uživatelského rozhraní není předmětem této bakalářské práce, ale je nutné již při základní tvorbě přemýšlet nad tím, jak by mohla aplikace v budoucnu vypadat. Je nutné navrhnout funkční bloky, které poté bude možné libovolně přemístit na základě designu dodaného zadavatelem. Dále je nutné navrhnout navigační menu, které musí být jednoduché a výstižné, nejlépe bez zanořeného submenu. Toto je umožněno díky zaměření na konkrétní službu, kterou chceme uživatelům poskytnout. Jelikož je náš systém tvořen pouze za účelem organizování soutěží, nebudeme brát v potaz funkce jako blog, novinky, videa, návody a podobné, ale zaměříme se pouze na využitelné v naší aplikaci. Častou záležitostí u analyzovaných webů byla možnost označit svůj tým jako hledající soupeře. Tento tým je poté zobrazen v boxu pro hledání soupeřů, který je umístěn na vždy viditelném místě. Uživateli to umožňuje rychle najít protivníka a odehrát s ním zápas. Také nabízení herních serverů pro odehrání zápasů jsme vyhodnotili jako velmi přívětivou funkcionalitu. Žebříčky a přehledy jednotlivých soutěží jsou samozřejmostí. Výhledově by bylo dobré hráčům umožnit vytvoření vlastního turnaje, čímž by se pravděpodobně zvedla aktivita uživatelů a portál by se stal i nepřímo propagovaným právě samotnými hráči, kteří hledají týmy pro svůj turnaj. Také sázkový systém za virtuální platidlo se jeví jako zajímavá funkce, v případě, kdy se ještě přidají nějaké sponzorské dary pro nejvyšší příčky v pořadí sázkařů, byl by o tuto funkcionalitu jistě zájem a hráči by tak sledovali i ostatní zápasy v turnaji, neboť by je zajímal výsledek. Případné nesrovnalosti v textu mohou být způsobeny faktem, že portály byly zkoumány v únoru roku 2014 a mohlo dojít ke změnám na jednotlivých portálech.

18

Kapitola

Analýza Kapitola popisuje obecnou analýzu aplikace, třídí doposud získané informace, analyzuje požadavky a jejich případný dopad na systém. Veškeré záležitosti jsou zpracovány grafickou formou v podobě modelů, které jsou následně popsány textovou formou. Z těchto modelů budeme později vycházet v návrhové části bakalářské práce.

3.1

Model požadavků

Zde je uveden kompletní seznam požadavků na systém, požadavky jsou analyzovány a sekce slouží jako podklad pro model případů užití. Jednotlivé požadavky z kapitoly 1 (Specifikace bakalářské práce) jsou zde roztříděny dle logických celků. Dále jsou doplněny některé funkční požadavky, jenž vyplývají z rozboru konkurenčních řešení či z doposud zjištěných informací.

3.1.1

Nefunkční požadavky

N1 — Dostupnost přes internetový prohlížeč Systém je webová aplikace volně dostupná přes libovolný internetový prohlížeč. Pro obsluhu není potřeba žádný další nástroj. Není nutné optimalizovat webové stránky pro mobilní zařízení. N2 — PHP verze 5.3 Nejnovější stabilní verze jazyka PHP je 5.5. Avšak zadavatelův server doposud podporuje pouze verzi 5.3, tudíž je nutné dodržovat konvence starší verze PHP. Novější verze jsou zpětně kompatibilní, tudíž je důležité vyvarovat se pouze novinek, které přinesly verze 5.4 a 5.5. Přehled těchto novinek lze nalézt na oficiálních stránkách jazyka [16]. 19

3

3. Analýza

Obrázek 3.1: Přehled funkčních a nefunkčních požadavků na systém.

Patří mezi ně například možnost zkráceného zápisu pole, volání statických metod tříd pomocí proměnné, podpora tzv. Traits, které slouží jako náhrada vícenásobné dědičnosti v jazyce PHP, a mnoho dalších. N3 — Framework Nette Jelikož stávající systém zadavatele je vytvořen pomocí frameworku Nette, přeje si zadavatel vzhledem k plánované integraci využít tento framework i pro naší aplikaci. N4 — MySQL databáze Na serveru zadavatele běží databázový stroj MySQL. Zadavatel si jej přeje využít pro uchování dat, aby nemusely být použity žádné další nástroje. Dále kvůli sdílení databáze uživatelů se stávajícím systémem je vhodné využít stejnou technologii pro uchování dat. N5 — PHP komunikace s herními servery Aplikace má za úkol komunikovat s herními servery za účelem jejich rezervací. Vzhledem k výše zmíněným nefunkčním požadavkům si zadavatel opět žádá využít jazyka PHP pro komunikaci, aby nebylo zapotřebí využití dalších technologií. Požadovaný typ herního serveru je dán hrou, pro kterou budeme implementovat podporu (CounterStrike 1.6). Typy herních serverů a způsoby komunikace jsou popsány v sekci 3.4 (Komunikace s herními servery). 20

3.1. Model požadavků

3.1.2

Funkční požadavky

F1 — Správa lig Systém bude umožňovat správu lig. Výpis lig bude k dispozici v administrátorském prostředí aplikace i na frontendu. V administrátorském prostředí lze vytvářet, editovat a mazat ligy. Na frontendu lze ligami listovat, zobrazovat jejich detaily a veškeré související informace. F2 — Správa turnajů Podobně jako ligy budou spravovatelné turnaje. V administrátorském prostředí lze turnaje vytvářet, editovat, mazat a zobrazit jejich výpis. Frontend obsahuje opět možnost turnaji listovat a zobrazovat informace s turnaji související. F3 — Správa administrátorů Administrátorské prostředí bude obsahovat možnost delegování administrátorských práv uživatelům systému, kteří budou sloužit jako správci lig a turnajů. Spravovat uživatele a administrátory může pouze systémový účet — role superadmin. F4 — Správa serverů Systém umožňuje pomocí administrátorského prostředí zobrazovat, přidávat, editovat a mazat herní servery. U jednotlivých serverů je vždy určeno, k jaké hře patří. Na frontendu jsou poté servery nabízeny pro rezervační účely. F5 — Správa klanů Uživatel má možnost vytvářet, editovat a mazat své týmy (klany), nebo se připojit k cizím. Klan je vždy spojen právě s jednou soutěží, nelze vytvořit klan nepatřící do žádné soutěže a nelze klany napříč soutěžemi sdílet. Jediný případ sdílení klanu je v případě turnaje, kde se ovšem klan z ligy zduplikuje a kopie je přiřazena k turnaji. Klan nemůže změnit soutěž, ve které působí, každá liga má své nastavení (textová informace — počet účastníků zápasu, délka zápasu apod.), proto je nutné vytvořit klan nový, který bude vyhovovat těmto nastavením. Uživatel může být členem libovolného množství klanů, ale v rámci soutěže pouze jednoho, počet členů není omezen, ale zůčastnit se zápasu může pouze určitý počet členů dle nastavení soutěže. Každý klan má svůj profil veřejně zobrazitelný na frontendu, zde jsou uvedeny informace s klanem související. Klan bude možné označit jako hledající soupeře. Takto označený klan bude zobrazen na viditelném místě na frontendu v boxu Hledáme soupeře. 21

3. Analýza F6 — Přihlašování do lig a turnajů Do ligy se uživatel přihlásí vytvořením klanu či vstupem do některého z již vytvořených klanů v dané lize. Do turnaje se klan přihlásí pomocí potvrzení pozvánky, kterou obdrží od správce ligy. V administraci bude výpis všech klanů podle soutěží, klany bude možné pozvat do turnajů. F7 — Správa zápasů Klany mezi sebou soupeří prostřednictvím zápasů. Tyto zápasy musí být sjednány formou výzvy a jejího přijetí. Po odehrání zápasu vůdce klanu vloží výsledek do systému, který jej přepočítá a určí rankingové skóre. Vůdci klanů mohou proti výsledku podat protest, jenž bude zveřejněn v administraci a správce ligy může na základě protestu manuálně upravit výsledek. F8 — Systém zpráv mezi uživateli Uživatelé si mezi sebou mohou zasílat soukromé zprávy. Na frontendu bude mít každý uživatel přehled těchto zpráv a možnost zaslat novou zprávu či odpovědět na příchozí zprávu. F9 — Rezervování herních serverů Pro jednotlivé soutěže budou k dispozici servery pro odehrání zápasů. Tyto servery mohou klany rezervovat dle rezervačního kalendáře. Délka rezervace je jedna hodina a každému klanu je umožněno vytvořit rezervaci jednou denně. To z důvodu rovnoměrného rozdělení serverového času mezi uživateli. Rezervace je provedena nastavení přístupového hesla k serveru dle dané rezervace.

3.2

Model případů užití

V této části jsou namodelovány a popsány jednotlivé uživatelské role. Tyto role jsou následně využity v modelování jednotlivých funkcionalit systému. Funkcionality vychází přímo z modelu požadavků tak, aby byly pokryty všechny případy užití.

3.2.1

Účastníci

Tato část popisuje účastníky (uživatelské role), které budou v systému využívány (viz také obrázek 3.3). Obecně platí, že každý nepřihlášený uživatel má právo zobrazit frontendovou část aplikace. Má práva pouze pro zobrazování a k provedení dalších akcí se musí přihlásit a získat tak některou z níže popsaných uživatelských rolí. 22

3.2. Model případů užití

Obrázek 3.2: Uživatelské role a logické bloky případů užití.

Uživatel Role „uživatel“ je každý uživatel, který je registrovaný na stávajícím webu zadavatele a přihlásí se pomocí stejných přihlašovacích údajů do naší aplikace. Tato role je tedy nejnižší úrovní autentifikovaného uživatele. Má přístup k vykonávání veškerých akcí na frontendové části aplikace. Admin Role „admin“ je každý uživatel, kterému byla přidělena větší práva než přihlášeným uživatelům. Uživatel v této roli by mohl být nazván správcem, neboť jeho hlavní náplní je správa lig a turnajů. Tato role má veškerá práva jako role „uživatel“, navíc má přístup do administrace lig a turnajů, kde kromě správy soutěží řeší také protesty proti výsledkům zápasů. Superadmin Role „superadmin“ je jedinečná role v systému. Systém má předvytvořeného pouze tohoto uživatele. Tento uživatel slouží jako správce celého systému, jeho účelem je delegování uživatelů na role „admin“ a správa herních serverů.

3.2.2

Případy užití

Sekce popisuje jednotlivé funkčnosti systému rozdělené do logicky souvisejících bloků. Každý případ užití obsahuje popis dané funkcionality. 23

3. Analýza

Obrázek 3.3: Účastníci případů užití — jednotlivé role v systému.

Správa lig Blok popisuje funkcionalitu správy lig z administrátorského prostředí — viz také obrázek 3.5. Zobrazení lig Umožňuje zobrazovat tabulkový seznam jednotlivých lig. Editace ligy Umožňuje editovat údaje dříve vytvořených lig. Smazání ligy Umožňuje mazat vytvořené ligy. Vytvoření ligy Umožňuje vytvářet nové ligy. Správa turnajů Blok popisuje funkcionalitu správy turnajů z administrátorského prostředí. Turnaje jsou po stránce funkcionality komplikovanější než ligy, což je zřejmé z množství případů užití — viz také obrázek 3.6. Editace turnaje Umožňuje editovat dříve vytvořené turnaje. Pozvání klanu do turnaje Umožňuje zaslat pozvánku do turnaje libovolnému klanu, na základě které je klanu umožněn vstup do turnaje. Smazání turnaje Umožňuje mazat vytvořené turnaje. 24

3.2. Model případů užití

Obrázek 3.4: Jednotlivé případy užití aplikace zapouzdřené logickými bloky. Vytvoření turnaje Umožňuje vytvářet nové turnaje. Změna rozlosování turnaje Umožňuje změnit rozlosování zápasů v turnaji, pokud je turnaj vyřazovacího módu (pavouk). Zobrazení turnajů Umožňuje zobrazit tabulkový seznam jednotlivých turnajů. Správa administrátorů Blok popisuje funkcionalitu systému související s pověřováním uživatelů na správce lig a turnajů — viz také obrázek 3.7. Pověřen vykonávat tyto akce je pouze uživatel s rolí „superadmin“. 25

3. Analýza

Obrázek 3.5: Model případu užití — správa lig.

Obrázek 3.6: Model případu užití — správa turnajů. Přidání admin práv uživateli Umožňuje pověřit uživatele na správce lig a turnajů — role „admin“. Filtrování uživatelů Umožňuje filtrovat výpis uživatelů z důvodu snažšího dohledání konkrétního uživatele. Odebrání admin práv uživateli Umožňuje odebrat uživateli pověření správce lig a turnajů — roli „admin“. Zobrazení uživatelů Umožňuje zobrazit tabulkový výpis všech uživatelů registrova26

3.2. Model případů užití ných ve stávajícím systému zadavatele.

Obrázek 3.7: Model případu užití — správa administrátorů. Správa serverů Blok popisuje funkcionalitu systému spravovat herní servery z administrátorského prostředí — viz také obrázek 3.8. Pověřen vykonávat tyto akce je pouze uživatel s rolí „superadmin“. Přidání serveru Umožňuje přidat do systému herní server vložením údajů. Údaje jsou unikátní, není nutné vkládat herní servery kopií. Editace serveru Umožňuje editovat údaje herního serveru zadané při přidání nového herního serveru. Odebrání serveru Umožňuje ze systému odebrat herní server. Zobrazení serverů Umožňuje zobrazit tabulkový výpis herních serverů přidaných do systému. Správa klanů Blok popisuje funkcionalitu systému související se správou klanů — viz také obrázek 3.9. Jedná se o frontendové akce. Klan je vždy pevně spojen se soutěží. Nelze měnit soutěž, které je klan přiřazen. 27

3. Analýza

Obrázek 3.8: Model případu užití — správa serverů.

Zobrazení klanů Umožňuje zobrazit uživateli seznam klanů pro danou soutěž nebo seznam vlastních klanů. Editace klanu Umožňuje editovat údaje o klanu zadané při vytváření klanu. Pozvání hráče Umožňuje pozvat libovolného hráče do vytvořeného klanu, který poté reaguje přijetím nebo zamítnutím pozvánky. Dále umožňuje schválit či zamítnout žádost o vstup do klanu obdrženou od uživatelů. Smazání klanu Umožňuje smazat vytvořený klan. Vytvoření klanu do ligy Umožňuje vytvořit nový klan. Klan lze vytvořit pouze v rámci některé z lig, do turnaje je vytvořen automaticky duplikací existujícího klanu na základě pozvánky od administrátora a jejího přijetí. Zaslání žádosti o vstup Umožňuje hráči zaslat žádost o vstup do klanu. Tato žádost může být potvrzena či zamítnuta vůdcem klanu, což je součástí případu užití Pozvání hráče. Dále umožňuje reagovat na pozvánky obdržené od klanu. 28

3.2. Model případů užití

Obrázek 3.9: Model případu užití — správa klanů. Přihlašování do lig a turnajů Blok popisuje funkcionalitu systému související s přihlašováním klanů do lig a turnajů — viz také obrázek 3.10. Klan se vytváří přímo v rámci některé ligy, takže je vytvořením automaticky do ligy přihlášen. Pozvání klanů do turnaje Umožňuje správci ligy pozvat vybraný klan do vytvořeného turnaje. Přijetí pozvánky do turnaje Umožňuje klanu přidat se k danému turnaji. Zobrazení klanů Umožňuje v administračním prostředí zobrazit tabulkový výpis všech klanů, které mohou být následně pozvány do turnaje. Správa zápasů Blok popisuje funkcionalitu systému související se správou zápasů — viz také obrázek 3.11. Zápasy se primárně řeší ve frontendové části aplikace, avšak lze je v administrátorském prostředí kontrolovat. Podání protestu Umožňuje klanu podat protest proti výsledku zápasu z důvodu podvodu apod. Potvrzení výsledku Umožňuje klanu potvrdit výsledek zápasu vložený do systému. 29

3. Analýza

Obrázek 3.10: Model případu užití — přihlašování do lig a turnajů.

Přijetí výzvy Umožňuje klanu přijmout výzvu k zápasu, čímž se vytvoří samotný zápas. Upravení výsledku zápasu Umožňuje správci lig a turnajů manuálně upravit výsledek zápasu (např. na základě protestu). Vložení výsledku Umožňuje klanu vložit výsledek sjednaného zápasu do systému. Vyhodnocení protestu Umožňuje správci lig a turnajů vyhodnotit protest, který byl podán proti výsledku zápasu. Vyzvání klanu Umožňuje klanu zaslat výzvu k uskutečnění zápasu jinému klanu z ligy. Zobrazení zápasů Umožňuje správci lig a turnajů zobrazit seznam sjednaných zápasů v administrátorském prostředí. Systém zpráv mezi uživateli Blok popisuje funkcionalitu systému související se zasíláním soukromých zpráv mezi uživateli — viz také obrázek 3.12. Zasílání odpovědí na zprávy Umožňuje uživateli odeslat odpověď na obdrženou zprávu. Zaslání zprávy Umožňuje uživateli odeslat zprávu libovolnému uživateli systému. 30

3.2. Model případů užití

Obrázek 3.11: Model případu užití — správa zápasů. Zobrazení zpráv Umožňuje uživateli zobrazit zprávy obdržené od ostatních uživatelů.

Obrázek 3.12: Model případu užití — systém zpráv mezi uživateli.

Rezervace herních serverů Blok popisuje funkcionalitu systému související s rezervacemi herních serverů pro uskutečnění zápasu — viz také obrázek 3.13. 31

3. Analýza Odebrání rezervace serveru Umožňuje odebrat vytvořenou rezervaci herního serveru ze systému. Rezervace odebráním bude zrušena. Vytvoření rezervace serveru Umožňuje vytvořit novou rezervaci herního serveru, zvolit datum, čas a heslo pro rezervaci. Zobrazení rezervací Umožňuje zobrazit vytvořené rezervace. Zobrazení serverů Umožňuje zobrazit seznam serverů, které mohou být rezervovány.

Obrázek 3.13: Model případu užití — rezervace herních serverů.

3.3

Analytický doménový model

Analytický doménový model (obrázek 3.14) obsahuje entity (třídy), které se vyskytují v aplikaci. Tento model slouží pro následný návrh databáze i samotné aplikace. Zachycuje vztahy mezi jednotlivými entitami a popisuje jejich atributy. Třídy jsou detailně popsány, aby bylo zřejmé, jaké informace a objekty je nutné v aplikaci uchovávat.

3.3.1

Popis entit

Uzivatel Entita reprezentuje uživatele stávajícího portálu zadavatele. Obsahuje 32

Obrázek 3.14: Analytický doménový model zachycující entity aplikace.

3.3. Analytický doménový model

33

3. Analýza informace o uživateli včetně přihlašovacích údajů, které jsou pro nás podstatné. Admin Entita slouží pro uchování uživatelů delegovaných na správce lig a turnajů. Atributy posledni_prihlaseni

Popis Datum a čas poslední aktivity správce lig a turnajů.

Zprava Entita reprezentuje komunikace mezi uživateli pomocí zasílání zpráv. Dvojí vazba je zde z důvodu odesílatele a adresáta, odesílatel i adresát jsou zástupci entity „Uzivatel“. Atributy text predmet datum precteno

Popis Text zaslané zprávy. Předmět zaslané zprávy. Datum a čas zaslání zprávy. Příznak, zda byla zpráva přečtena.

Zadost Entita reprezentuje žádost uživatele o vstup do klanu. Zároveň však má za úkol uchovat pozvánku k připojení do klanu zaslanou uživateli. Aplikace bude vnitřně řešit typ žádosti (zda se jedná o pozvánku či žádost). Atributy zprava odpoved datum

Popis Text zaslané žádosti nebo pozvánky. Odpověď na zaslanou žádost nebo pozvánku. Datum a čas zaslání žádosti.

Klan Entita reprezentuje jednotlivé klany v aplikaci. Tato entita je vždy spojená s entitou „Soutez“. Slouží pro spojení uživatelů do klanu. Pomocí této třídy se může uživatel přihlásit do ligy, turnaje nebo zarezervovat server. Entita má vždy svého majitele — uživatele, který klan vytvořil. Tyto informace budou uchovány ve spojové tabulce mezi klanem a uživatelem. Entita také uchovává dosažené skóre klanu v dané lize. 34

3.3. Analytický doménový model Atributy nazev obrazek popis datum_vytvoreni pocet_vyher pocet_remiz pocet_proher ziskane_body

Popis Název klanu, který bude zobrazen na profilu i ve výpisech. Obrázek klanu, který v případě vyplnění bude zobrazen na profilu klanu. Textový popis klanu, obecné informace. Datum a čas, kdy byl klan vytvořen. Počítadlo výher v lize, které je klan přiřazen. Počítadlo remíz v lize, které je klan přiřazen. Počítadlo proher v lize, které je klan přiřazen. Rankingové skóre, kterého klan v dané lize dosáhl.

Hra Entita reprezentuje jednotlivé hry zadané do aplikace. Pro tyto hry bude funkční soutěžní systém. Atributy nazev modul

Popis Název, pod kterým se hra bude zobrazovat Název souboru, který umožňuje komunikaci s herním serverem dané hry.

Server Entita reprezentuje herní servery vložené do aplikace. Vždy se vztahuje k jedné hře. Atributy nazev adresa port rcon

Popis Název herního serveru. IP adresa herního serveru, přes kterou se lze na server připojit. Port herního serveru, pod kterým se lze na server připojit. Heslo pro vzdálený přístup k serveru a jeho ovládání.

Rezervace Entita reprezentuje rezervaci herního serveru daným klanem. Je vždy spojená s jedním serverem a jedním klanem. Klan může rezervovat 35

3. Analýza serverový čas v omezené míře, systém pomocí entity bude kontrolovat, zda je klan oprávněn rezervovat daný server. Atributy datum hodina heslo

Popis Datum rezervace herního serveru. Hodina, na kterou je herní server zarezervován. Heslo, které bude nastaveno hernímu serveru. Toto heslo bude znát pouze klan, který vytvořil rezervaci.

Soutez Entita reprezentuje soutěž mezi klany. Je spojená se všemi klany, které jsou do soutěže přihlášeny. Obsahuje obecné informace o lize. Další entitou, se kterou spolupracuje, je „Zapas“. Do ligy lze klan vytvořit přímo, do turnaje pouze na základě pozvánky. Systém přijetím pozvánky sám vytvoří nový klan a přidá jej do turnaje. Atributy nazev popis obrazek datum_zacatku datum_konce datum_vytvoreni typ

Popis Název, pod kterým bude soutěž zveřejněna. Textový popis soutěže obsahující obecné informace, pravidla apod. Obrázek, který bude zobrazen v detailu soutěže. Datum a čas, od kdy je soutěž aktivní. Datum a čas, do kdy je soutěž aktivní. Datum a čas, kdy byla soutěž vytvořena. Typ určije, zda se jedná o ligu, turnaj každý s každým či vyřazovací turnaj.

Zapas Entita reprezentuje zápas vždy dvou klanů dané soutěže. Obsahuje informace o utkání. Zároveň má na starost výzvy k zápasům mezi klany. 36

3.4. Komunikace s herními servery Atributy vyzva odpoved dalsi_zapas

skore_h skore_d zprava_h zprava_d screenshot1 screenshot2 datum

3.4

Popis Zpráva výzvy klanu k zápasu. Odpověď na výzvu klanu k zápasu. Pokud je dané rozlosování (jedná se o vyřazovací turnaj), obsahuje další zápas, který bude hrát klan v případě výhry. Aplikace pevně vytvoří celého pavouka turnaje a bude poté propojovat zápasy pomocí tohoto atributu. Skóre zápasu pro hostující tým. Skóre zápasu pro domácí tým. Zpráva k zápasu od hostujícího týmu. Zpráva k zápasu od domácího týmu. Obrázek pro zachycení výsledku v první polovině zápasu. Obrázek pro zachycení výsledku v druhé polovině zápasu. Datum a čas vložení výsledku zápasu.

Komunikace s herními servery

Herní servery slouží jako prostor pro hraní multiplayerových online her — více hráčů hraje zároveň přes internet na stejném místě. Středem zájmu naší aplikace jsou herní servery hry Counter-Strike 1.6, neboť podporu právě pro tuto hru budeme dle přání zadavatele implementovat s nasazením systému (sekce 1.4). Kapitola popisuje smysl herních serverů a analyzuje dostupné prostředky pro komunikaci s nimi.

3.4.1

Half-Life Dedicated Server

Aplikace herního serveru hry Counter-Strike 1.6 se nazývá Half-Life Dedicated Server (dále HLDS) [26], slouží pro vytvoření dedikovaného (vyhrazeného) serveru pro hry založené na Goldsource herním enginu (softwarový framework pro vývoj video her) [24]. Goldsource (známý také jako GoldSrc) je značně upravená verze Quake enginu, na kterém jsou postaveny hry typu Half-Life — jedná se o hry Half-Life (a její rozšíření), Counter-Strike, Day of Defeat, Deathmatch Classic, Counter-Strike: Condition Zero a Ricochet. Tyto hry jsou vytvořeny za účelem online hraní více hráčů najednou, proto je nutné se pro hraní připojit k některému z herních serverů. 37

3. Analýza

3.4.2

Source RCON protocol

Source RCON protocol je protokol založený na TCP/IP (Transmission Control Protocol/Internet Protocol). Slouží mimo jiné pro komunikaci s herními servery HLDS. Umožňuje vzdálený přístup ke konzoli herního serveru a tím jeho vzdálené ovládání („remote console“, RCON) bez přímého přístupu ke stroji, na kterém běží. Konzole serveru je zpravidla chráněná heslem (RCON password), aby nebylo možné zneužít server. Komunikace pomocí tohoto protokolu je popsána na paketové úrovni na webových stránkách pro vývojářskou komunitu kolem softwaru firmy Valve [27]. Nebudeme jej podrobně popisovat, neboť implementace protokolu není součástí této bakalářské práce.

3.4.3

Dostupné prostředky

Na stránkách vývojové komunity firmy Valve jsou k dispozici knihovny pro práci s výše zmíněným Source RCON protokolem (sekce 3.4.2) v nejrůznějších programovacích jazycích. Pro nás jsou zajímavé knihovny jazyka PHP (sekce 4.1.5) dle přání zadavatele (sekce 3.1.1). Jedná se o následující knihovny: Steam Condenser Jedná se o multi-jazykovou knihovnu pro komunikaci s herními servery typu Source a GoldSrc [25]. Momentálně je implementována v jazyce JAVA, PHP, Ruby, C# a Objective-C. Knihovna je robustní — implementace je rozdělena do více souborů a složek, vytváří pro komunikaci objekt reprezentující server. Pro naše účely má zbytečně složitou implementaci, proto jsme využití této knihovny vyloučili. Source RCON class Tato třída je napsána jednoduchým způsobem — obsahuje 105 řádků kódu [32]. Slouží pouze pro autentifikaci na serveru a zasílání příkazů. Přesně této funkcionality chceme v rámci naší aplikace docílit. Záměrem původně bylo využít tuto třídu pro komunikace s herními servery nebo se touto třídou alespoň inspirovat, případně doplnit námi požadovanou funkcionalitu. Při podrobnějším zkoumání jsme však zjistili, že je třída zastaralá a jejím prostřednictvím není komunikace s herními servery možná. PHP Source Query Knihovna PHP Source Query [33] byla vytvořena za účelem dotazování herních serverů, které využívají Source RCON protokol, je vy38

3.4. Komunikace s herními servery tvořena objektovým způsobem v jazyce PHP, a proto našim požadavkům vyhovuje. Při podrobnějším zkoumání se nám úspěšně podařilo komunikovat s herním serverem, proto jsme se rozhodli využít tuto knihovnu a další již nezkoumat.

3.4.4

Amx mod X

AMX mod X [2] je univerzální rozšíření pro herní servery typu Half-Life Dedicated Server. Je zaměřený na administraci serveru bez nutnosti přístupu k ovládací konzoli serveru. Může být snadno modifikován, což umožňuje uživatelům vytvářet vlastní rozšíření her. Tato rozšíření mohou mít formu administrativní služby (přidání nových administrátorských příkazů), generovat statistiky serveru, představovat zábavné doplňky či měnit samotnou podstatu hry. Rozšíření založených na AMX módu je celá řada, kromě rozšířené administrace bez nutnosti přístupu k ovládací konzoli serveru lze například modifikovat hru na „zombie“ mód, kde se s herních charakterů stávají zombie, „paintball“ mód, který modifikuje hru tak, že se střílí z paintballových zbraní apod.

39

Kapitola

Návrh aplikace Tato kapitola se zabývá návrhem samotné aplikace. Vychází z analytické části této práce (kapitola 3). Cílem této části bakalářské práce je zvolit vhodný návrhový vzor, určit rozdělení zdrojových kódů do souborů a složek a vytipování využitých souborů (tříd). Dalším bodem je návrh databáze aplikace.

4.1

Technologie

Volba technologií je prvním krokem v návrhu aplikace. Na základě zvolených technologií lze poté vhodně zvolit softwarovou architekturu aplikace a navrhnout jednotlivé třídy, jejich provázání a vytipovat jejich metody. Některé technologie jsou přímo určeny nefunkčními požadavky (sekce 3.1.1), tato sekce popisuje využité technologie a důvody jejich využití pro implementaci naší aplikace. Mezi základní používané technologie patří jazyk PHP (sekce 4.1.5), jenž je v dnešní době nejvíce rozšířený pro tvorbu webových stránek. Slouží ke zpracování uživatelských požadavků jako jsou práce s formuláři, vyhledávání, výpis dat z databáze apod. Nadstavbou nad samotným jazykem PHP je framework Nette (sekce 4.1.7) obsahující mnoho předpřipravených funkcí a programovacích principů. Pro tvorbu webových stránek je využit značkovací jazyk HTML (sekce 4.1.1), jejich vzhled je uzpůsoben konkrétním požadavkům pomocí CSS kaskádových stylů (sekce 4.1.2). Dynamičnost webu zajišťuje scriptovací jazyk javascript (sekce 4.1.3), který je vykonáván prohlížečem na straně klienta. Jelikož design aplikace není předmětem této práce, je využit frontendový framework Twitter Bootstrap (sekce 4.1.4). Pro uchování dat je na základě nefunkčních požadavků (sekce 3.1.1) zvolena relační databáze MySQL (sekce 4.1.6). 41

4

4. Návrh aplikace

4.1.1

HTML

HTML (HyperText Markup Language) je značkovací jazyk slouřící pro tvorbu WWW (World Wide Web) stránek publikovaných na internetu [31]. Obsahuje množství tagů a jejich atributů, které určují význam v sobě obsaženého textu. Pevně daná pravidla pro zápis dokumentu určují způsob zápisu jednotlivých prvků tak, aby jednotlivé prohlížeče byly schopné zobrazit soubor v grafické podobě. Tento jazyk je nezbytným základem pro tvorbu webových publikací a proto je využit i v naší aplikaci.

4.1.2

CSS

K přizpůsobení vzhledu webových stránek slouží kaskádové styly (CSS) [19]. Umožňují jednotlivým elementům z HTML přidat styly, které upravují jejich zobrazení při publikování. O aplikování kaskádových stylů na jednotlivé elementy se stará prohlížeč webových stránek. Mezi prohlížeči různých výrobců jsou rozdíly v interpretaci jednotlivých stylů a tvůrce stylů musí dbát na správnost požadovaného zobrazení napříč různými prohlížeči. CSS je úzce spjato s HTML a jedná se o další základní nástroj pro tvorbu webových publikací, proto je využití v naší aplikaci samozřejmostí.

4.1.3

Javascript a jQuery

Javascript je scriptovací objektový jazyk vykonávaný přímo v prohlížeči webových stránek uživatele [20]. Účelem využití tohoto nástroje je přímá interakce s uživatelem bez nutnosti zasílání nového požadavku na server. Veškerá dynamičnost stránek po jejich načtení je umožněna právě tímto nástrojem (např. pohyblivé obrázky či prvky v dokumentu, rozbalovací menu, modální okna, vyskakovací zprávy apod.). Javascript je silným nástrojem pro tvorbu webových stránek. Ovšem stránky musí být připraveny tak, aby ke své funkci javascript nevyžadovaly, podporu javascriptu lze v prohlížeči vypnout. Veškeré webové prezentace by tedy měly být vytvořeny tak, aby nebyly na javascriptu závislé. Nadstavbou nad javascriptem je hojně používaná knihovna jQuery [8], která obsahuje množství zabudovaných funkcí, zpřehledňuje zdrojové kódy a ulehčuje programátorům práci. Účelem jQuery je hromadění standardních funkcí a fragmentů kódu na jednom místě tak, aby běžné rutinní záležitosti nemusely být opětovně programovány. Na této knihovně je postaveno nepřeberné množství komerčních i volně šiřitelných pluginů, jejichž využití dělá webové stránky uživatelsky přívětivé a moderní. Knihovna také pamatuje na kompatibilitu mezi různými webovými prohlížeči, není tedy nutné 42

4.1. Technologie přizpůsobovat scripty jednotlivým prohlížečům. Podrobnosti lze nalézt na oficiální webové stránce knihovny.

4.1.4

Twitter Bootstrap

Populárním nástrojem pro tvorbu webových aplikací je Twitter Bootstrap, jedná se o frontendový framework, který umožňuje vytvořit přehledný, responzivní (přizpůsobitelný různým zařízením a rozlišením) design pro webové aplikace. Obsahuje sadu předdefinovaných kaskádových stylů, které lze aplikovat na HTML elementy. Součástí tohoto frameworku jsou také připravené javascripty pro nejrůznější účely (vyjížděcí menu, bublinové nápovědy, modální okna apod.), také pro vzhled aplikace jsou připraveny základní grafické prvky jako ikony, tlačítka atd. Pro snadné využití slouží přehledná dokumentace na webových stránkách projektu [7], kde se lze dočíst podrobnosti o tomto nástroji. Zadavatel neměl žádné požadavky na vzhled aplikace. Jeho záměrem do budoucna je vytvořit vlastní design a sjednotit jej se stávající aplikací. U stávající aplikace zadavatele navíc momentálně probíhá rozsáhlá změna vzhledu — kompletní redesign. Z tohoto důvodu jsme konkrétní grafické podobě nevěnovali pozornost a využili nástroj Twitter Bootstrap.

4.1.5

PHP

Scriptovací jazyk PHP [17] je rozšířený nástroj pro tvorbu webových aplikací. Jedná se o objektově orientovaný jazyk vykonávaný na serveru, kde se provede logika a algoritmy na základě uživatelské akce, následně uživateli je předložena výstupní webová stránka. Mezi největší výhody tohoto nástroje patří multiplatformnost — není závislý na použitém operačním systému, dále výborná podpora v podobě nadstaveb nad čistým PHP — frameworky jako Nette, Zend, Symphony apod. Rozšířenost tohoto jazyka pomáhá programátorům zjednodušit práci při tvorbě aplikací, v rámci internetu lze dohledat nepřeberné množství návodů, ukázek kódu, hotových knihoven a doplňků.

4.1.6

MySQL

Existují různé databázové stroje a každý z nich má specifický dotazovací jazyk. Protože server zadavatele používá databázový stroj MySQL, je jedním z požadavků jeho využití (sekce 3.1.1). MySQL je open-source relační databázový stroj, jenž je využíván převážně u webových aplikací. Pro vytváření dotazů využívá SQL (Structured Query Language) jazyk, který umožňuje 43

4. Návrh aplikace vykonávat dotazy typu výběr, vkládání, upravování, mazání, agregování a mnoho dalších. Výhodou relačních databázových strojů oproti jiným řešením (např. objektová databáze) je jednoduchá implementace, levný provoz a spravovatelnost, nevýhodou je nutnost mapování objektů na tabulky v relační databázi — toto nám zařídí Nette framework (sekce 4.1.7). Principem relační databáze je reprezentace entit a jejich vazeb formou tabulek, reprezentace atributů formou sloupců v jednotlivých tabulkách. Dotazy typu výběr vrátí vždy požadované řádky dotazované tabulky dle zadaných kritérií — filtrace výsledků porovnáním dat se sloupci v tabulce. Systém primárních a cizích klíčů slouží k identifikaci jednotlivých řádků v tabulkách a jejich propojení, primární klíč pro řádek v rámci tabulky musí být unikátní. Podrobnější informace lze nalézt na webových stránkách MySQL [15].

4.1.7

Nette

Pro webovou aplikaci byl využit na základě požadavků zadavatele (sekce 3.1.1) scriptovací jazyk PHP, konkrétně nadstavba nad tímto jazykem — Nette framework, což je objektově orientovaný PHP framework. Autorem původní verze je David Grudl, dnes je součástí týmu, který framework spravuje a vyvíjí (Nette foundation). V České Republice je velmi oblíbený, zejména díky kvalitní dokumentaci a rozsáhlé komunitě. Většina pluginů pro Nette pochází právě z řad programátorské komunity kolem frameworku. Fórum frameworku kromě zveřejňování novinek a volné diskuze slouží také k řešení problémů, na které programátoři narazili při programování. Diskuze nad problémem nabízí kromě jeho řešení také zpětnou vazbu pro tvůrce, kteří pravidelně vydávají nové verze frameworku a zohledňují již řešené problémy. Nette klade důraz na bezpečnost. Usnadňuje tvorbu bezpečné webové aplikace i autorům bez znalostí o bezpečnosti. Například databázová vrstva escapováním parametrů eliminuje bezpečnostní chybu při útoku SQL Injection — útok, kdy jsou dotazovaná data podvržena a vykoná se dotaz na databázi s parametrem, který představuje další dotaz (nejčastěji pomocí union). Šablonovací systém escapováním výpisu proměnných eliminuje vznik bezpečnostní chyby aplikace při útoku XSS (Cross-site scripting), při kterém útočník vloží do vstupu škodlivý kód, který aplikace vypíše na výstupu a tím jej vykoná. Znatelnou výhodou pro programátory jsou ladící nástroje napomáhající při vývoji aplikací, ať již nástroje obsažené v základní konfiguraci frameworku nebo doplňky, které se dají doinstalovat. Mezi tyto nástroje patří například laděnka [11], která zachytí chyby v aplikaci a s podrobnostmi je vypíše programátorovi na obrazovku. 44

4.1. Technologie Šablonovací systém latte, který slouží k vytváření HTML šablon, je další předností Nette frameworku. Obsahuje vlastní makra PHP kódů, která nám umožňují vykonávat jednoduché operace bez psaní PHP kódu přímo do šablony. Tyto makra nám umožňují procházet prvky v poli, vytvářet podmínky a cykly, vypisovat proměnné atd. Dále jsou zde připravené helpery pro práci s datem, čísly, řetězci apod. Helper je implementované makro pro volání PHP funkce, které předáme nějaký parametr a funkce nám vrátí parametr pozměněný. Například helper truncate ořeže vypisovaný text (vstupní parametr) na požadovaný počet znaků, doplní k textu trojtečku a takto upravený text vrátí, což způsobí sjednocení všech textů na maximální velikost a nenaruší design aplikace. Samozřejmostí je podpora moderních technologií jako AJAX (Asynchronous Javascript and XML) nebo SEO (Search engine optimization), na které je již celé řešení frameworku připravené. Například pro využití AJAXu v celé aplikaci stačí doplnit k odkazům třídu „ajax“. Tyto akce jsou poté provedeny pomocí asynchronní komunikace se serverem. SEO optimalizace slouží pro upřednostnění stránek při vyhledávání pomocí internetových vyhledávačů. Framework nabízí sofistikovaný systém odkazování, k čemuž využívá vlastní router (třída starající se o tvorbu odkazů a volání správných souborů na základě požadavku), který nám dovoluje jakkoliv modifikovat tvar URL adresy jednotlivých stránek — důležitý prvek při SEO optimalizaci. Databázová vrstva (\Nette\Database) zapouzdřuje komunikaci s relační databází MySQL a obsahuje řadu tříd pro práci s databází. Objekty musí být namapovány na relační databázi a obráceně (sekce 4.1.6), k čemuž se využivá mapper — Nette Database již toto mapování zajišťuje. Mapování je důležité z důvodu rozdílné reprezentace dat. V relační databázi jsou data uchována formou tabulek narozdíl od aplikace, kde se jedná o objekty a jejich atributy. Přiřazení tabulky databáze k objektu se nazývá mapování. Výsledkem dotazů na databázi je podle typu dotazu nejčastěji počet ovlivněných záznamů a instance třídy \Nette\Database\Table\Selection nebo \Nette\Database\Table\ActiveRow. Databázová vrstva v Nette frameworku je založena na knihovně NotORM [29] vytvořené Jakubem Vránou. NotORM klade důraz na jednoduchou práci s databází a relacemi mezi tabulkami. Důležité třídy databázové vrstvy Nette lze nalézt v seznamu tříd [10]. Jedná se o: \Nette\Database\Table\Selection Třída \Nette\Database\Table\Selection [9] reprezentuje filtrovatelnou tabulku, voláním jejích metod lze filtrovat řádky tabulky a vybrat konkrétní výsledek. Také obsahuje agregační a iterační funkce pro 45

4. Návrh aplikace lepší práci s výsledkem. Každý řádek při iteraci výsledku je instancí \Nette\Database\Table\ActiveRow. \Nette\Database\Table\ActiveRow Třída \Nette\Database\Table\ActiveRow [30] reprezentuje samotný řádek tabulky databáze. Obsahuje metody pro jednoduchou modifikaci řádku, což velmi usnadňuje práci. Pro smazání řádku stačí zavolat metodu delete(), pro upravení metodu update(array \$data). K jednotlivým sloupečkům tabulky lze přistupovat pomocí objektového přístupu ($row->column) nebo přístupu přes pole ($row[’column’]). Nette je moderní objektově orientovaný PHP framework s mnohými přednostmi. Umožňuje rychlou implementaci jednoduchých i složitých webových aplikací a obsahuje mnoho předpřipravených nástrojů pro jejich tvorbu, čímž usnadňuje programátorům práci. Popis celého frameworku by přesáhl rozsah této práce, proto pro bližší informace navštivte webové stránky frameworku (viz [14]).

4.2

Architektura

Obrázek 4.1: Model MVP architektury a rozdělení tříd. Návrhové vzory se obecně využívají za účelem určení postupů při tvorbě aplikace, pomáhají zpřehlednit zdrojové kódy aplikace a usnadňují její vývoj a správu. Proto je volba návrhového vzoru důležitou součástí této práce. Vzhledem k využití Nette Frameworku (sekce 4.1.7) nebudeme uvažovat mnoho návrhových vzorů, neboť nám již některé framework sám nabízí. 46

4.2. Architektura Na nás je pouze do jaké míry návrhový vzor frameworku využijeme nebo modifikujeme. Framework Nette je založen na návrhovém vzoru MVC (model-viewcontroller). Jedná se o softwarovou architekturu rozdělující aplikaci do tří vsrstev — datový model, uživatelské rozhraní a řídící logiku. Model má za úkol zprostředkovat přístup k datům a manipulaci s nimi. View (pohled) zajišťuje převod dat do formy, která bude předložena uživateli. Controller (řadič) zpracovává uživatelské akce a události a zajišťuje změny v modelu nebo pohledu. Nette framework však využívá méně známý vzor MVP (modelview-presenter) [13], kde ve zjednodušeném smyslu lze říci, že presenter plní roli controlleru z MVC vzoru. Přiblížení MVP vzoru v Nette: • Model nemá vědět o existenci view a presenterů, jeho úkolem je pouze práce s daty. Modelem v Nette je vše, co souvisí s daty, jejich parsováním, algoritmy apod. • View o modelu vědět může a nemusí. Pasivní view o modelu neví a data mu jsou předkládána pomocí presenteru. View však může využívat model a přistupovat k datům pomocí modelu přímo voláním jeho metod, záleží na zvolené koncepci. View v Nette jsou šablony vytvořené v šablonovacím systému Latte (sekce 4.1.7). • Presenter je prostředníkem mezi view a modelem. Realizuje uživatelské akce — změna view, změna stavu, příkaz pro model. Změna view změní aktuálně zobrazený pohled, změna stavu znamená interakci v rámci aktuálního view, příkaz pro model slouží pro práci s daty. V ideálním případě by se činnost modelů měla omezit na práci s daty (databází), logika ve view by se měla omezit na iterace a podmínky. Presenter by se měl starat pouze o volání tříd z modelu a předávání dat view. Model je obecný pojem a zajisté bude rozdělen do více tříd, pro naše účely bude využito repozitářů a fasád [5]. Repozitář je třída zapouzdřující připojení k databázi, má za úkol pouze práci s daty na úrovni získání, editace, vkládání a mazání dat. Repozitářů by mělo být tolik, kolik je v aplikaci entit. Pokud ovšem některé entity spolu úzce souvisí, lze práci s jejich daty spojit do jednoho souboru a dělit tedy repozitáře do logických celků. Fasáda je třída vytvářející rozhraní pro vrstvu model. Presenter má přístup k fasádě a využívá její metody. Fasáda jako taková slouží k sjednocení více logických tříd do jednotného rozhraní a umožňuje nám vytvořit subsystém. V naší aplikaci vrstva fasád bude sloužit jako prostředník mezi presen47

4. Návrh aplikace terem a repozitářem, čímž se oddělí práce s daty (repozitář) od algoritmů a složitějšího zpracování dat (fasády) a následně bude využito rozhraní této fasády pro předání dat šablonám (presenter). V aplikaci je dále uplatněn návrhový vzor Dependency Injection (zkráceně DI — injektování závislostí) [12]. DI slouží pro snížení závislostí mezi objekty jednotlivých tříd aplikace. Odebírá třídám zodpovědnost za získávání objektů, třídy nemusejí vytvářet instance objektů, které potřebují ke své činnosti. DI zajišťuje předání potřebných objektů třídě při vytvoření. Smysl návrhového vzoru injektování závislostí lze neformálně shrnout jednou prostou větou: „Cokoliv potřebuji pro svou funkci mi musí být předáno.“ Znamená to tedy, že pokud třída potřebuje další závislosti (jiné třídy, připojení k databázi, cesta k adresáři apod.) pro svou plnou funkcionalitu, musí třídě být předány tím, kdo ji chce využít. Závislosti jsou předány zpravidla při vytváření objektů a jsou v rámci objektu přístupné po celou dobu jeho existence.

4.3

Databázový model

Databázový model byl vytvořen na základě analytického doménového modelu — sekce 3.3. K vyhotovení byl použit nástroj MySQL Workbench, který umožňuje přímé propojení s databázovým strojem a model lze tedy převést rovnou do databáze. Obrázek 4.2 (strana 49) zachycuje veškeré databázové tabulky, které jsou pro naší aplikaci potřeba, jejich vazby, vlastní i cizí klíče a datové typy jednotlivých sloupců.

4.3.1

Popis jednotlivých tabulek a jejich atributů

users Tabulka uživatelů portálu Gamesites. Pro vývojové účely je ve stejné databázi jako naše aplikace. Atributy není podstatné popisovat, neboť jsou dány zadavatelem. Pro nás má význam primární klíč a název uživatele, zašifrované heslo a email. Atributy id name pass email

48

Popis Primární klíč tabulky. Jméno hráče v rámci aplikace. Zašifrované heslo v rámci aplikace. Email hráče.

Obrázek 4.2: Databázový model zachycující strukturu databáze.

4.3. Databázový model

49

4. Návrh aplikace message Tabulka uchovává veškeré soukromé zprávy zaslané mezi uživateli. Atributy id text subject date isReaded from to reply

Popis Primární klíč tabulky. Text zaslané zprávy. Předmět zaslané zprávy. Datum zaslání zprávy. Příznak, zda byla zpráva přečtena. Cizí klíč do tabulky users. Odesílatel zprávy. Cizí klíč do tabulky users. Adresát zprávy. Cizí klíč do message. Identifikátor, na jakou zprávu jsme odpovídali.

request Tabulka uchovává žádosti uživatelů o vstup do klanů a zároveň pozvání uživatele do klanu. Podle atributů userMessage a clanMessage se rozhodne, zda se jedná o žádost či pozvánku — vyplněný sloupec userMessage znamená, že se jedná o žádost, pokud je clanMessage prázdný a naopak. Pokud je vyplněn atribut contest_id, jedná se o pozvánku do turnaje. Atributy id userMessage clanMessage date state isClosed

users_id clan_id contest_id

50

Popis Primární klíč tabulky. Text uživatele — žádosti nebo odpovědi na pozvánku. Text klanu — pozvánky nebo odpovědi na žádost. Datum zaslání žádosti/pozvánky. Příznak, jak byla žádost vyřízena. Příznak, zda je požadavek vyřízen. Uživatel reagoval na pozvánku, vůdce klanu reagoval na žádost. Cizí klíč identifikující uživatele pro vstup do klanu. Cizí klíč identifikující klan, do kterého má uživatel vstoupit. Cizí klíč turnaje. Identifikátor, zda se jedná o pozvánku do turnaje.

4.3. Databázový model clan Tabulka klanů v systému. Uchovává kromě obecných údajů i rankingové skóre daného klanu v soutěži. Klan je vždy přiřazen některé soutěži. Atributy id name image description created countWin countLose countDraw point deleted contest_id findingEnemy

Popis Primární klíč tabulky. Název klanu. Jméno souboru — obrázku klanu. Popis klanu. Datum a čas vytvoření klanu. Počet vyhraných zápasů klanu v lize. Počet prohraných zápasů klanu v lize. Počet remizovaných zápasů klanu v lize. Počet dosažených bodů klanu v lize. Příznak smazání klanu. Cizí klíč identifikující soutěž, které je klan přiřazen. Příznak, zda klan hledá soupeře.

contest Tabulka reprezentuje veškeré soutěže v aplikaci. O typu soutěže rozhoduje atribut „type“. Atributy id name description image created from to type deleted admin_id game_id

Popis Primární klíč tabulky. Název soutěže. Popis soutěže. Obrázek soutěže. Datum vytvoření soutěže. Datum začátku soutěže — datum zobrazení na frontendu. Datum ukončení soutěže. Příznak určující typ soutěže — liga, turnaj, vyřazovací turnaj. Příznak smazání soutěže. Cizí klíč identifikující uživatele, který soutěž vytvořil. Cizí klíč identifikující hru, které je soutěž přiřazena. 51

4. Návrh aplikace users_clan Spojová tabulka mezi tabulkami users a clan. Slouží kromě vazby také k určení role uživatele v klanu. Tyto role jsou typu enum a mohou nabývat hodnot „member“ (člen klanu), „leader“ (vůdce klanu), „owner“ (zakladatel klanu). admin Tabulka slouží pro přiřazení role „admin“ uživatelům, čímž se stanou správci lig a turnajů. match Tabulka uchovává informace o všech odehraných zápasech v systému. Zápas je vždy přiřazen některé soutěži. Atributy id home away hScore aScore hComment aComment screen1 screen2 closed accepted date invitation reaction contest_id

52

Popis Primární klíč tabulky. Cizí klíč identifikující domácí klan zápasu. Cizí klíč identifikující hostující klan zápasu. Dosažené skóre domácího klanu. Dosažené skóre hostujícího klanu. Poznámka k výsledku od domácího klanu. Poznámka k výsledku od hostujícího klanu. Screenshot stavu skóre v polovině zápasu. Screenshot stavu skóre na konci zápasu. Příznak uzavření zápasu. Příznak přijetí výzvy klanem. Datum vložení výsledku zápasu. Text zaslané výzvy. Text zaslané odpovědi na výzvu. Cizí klíč identifikující soutěž, které je zápas přiřazen.

4.3. Databázový model reservation Tabulka reprezentuje jednotlivé rezervace herních serverů vykonané klany. Atributy id date day hour password isPast server_id clan_id

Popis Primární klíč tabulky. Datum vytvoření rezervace. Den rezervování serveru. Hodina rezervování serveru. Heslo, které bude serveru nastaveno pro rezervaci. Příznak, zda byla rezervace vykonána. Cizí klíč identifikující server, který má být rezervován. Cizí klíč identifikující klan, který vytvořil rezervaci.

server Tabulka uchovává informace o herních serverech, které jsou vloženy do aplikace. Atributy id name address port rcon game_id

Popis Primární klíč tabulky. Název serveru. IP adresa serveru. Port serveru. Přístupové heslo pro vzdálenou správu serveru. Cizí klíč identifikující hru, které je server přiřazen.

game Tabulka reprezentující jednotlivé hry, které systém podporuje. Atributy id name modul

Popis Primární klíč tabulky. Název hry. Název modulu pro ovládání herních serverů dané hry.

53

Kapitola

Implementace Kapitola popisuje způsob implementace a adresářovou strukturu systému. Dále uvádí příklady vybraných zdrojových kódů a popisuje nestandardní části aplikace. Aplikace byla vytvořena na základě návrhové části této práce (kapitola 4). Návrh systému nám poskytl veškeré podklady pro přímou implementaci bez nutnosti řešení problémů. Většina implementace zahrnovala vytvoření CRUD akcí (Create, Read, Update, Delete) pro jednotlivé databázové tabulky, těchto akcí bylo poté využito pro práci s daty.

5.1

Popis aplikace

Architektura aplikace byla vytvořena podle navrhnutého vzoru MVP s využitím fasád a repozitářů (obrázek 4.1, strana 46). Abstraktní třída BaseRepository poskytuje univerzální CRUD metody pro práci s daty. Každý další repozitář je potomkem této třídy, proto může využívat jeho metod. Repozitáři je přiřazen název databázové tabulky (jako parametr konstruktoru), pro kterou se tyto obecné CRUD metody volají. Základní CRUD metody v BaseRepository: findAll() Metoda vrátí všechny záznamy v tabulce přiřazené repozitáři. findById($id) Metoda vrátí záznam z tabulky přiřazené repozitáři, kde je primární klíč roven vstupnímu parametru. Pokud záznam neexistuje, vrátí hodnotu FALSE. create($data) Metoda vloží nový záznam do tabulky přiřazené repozitáři. Data pro vložení jsou vstupním parametrem této metody. Návratovou hodnotou je nově vložený záznam tabulky. 55

5

5. Implementace update($id, $data) Metoda upraví záznam v tabulce, kde je primární klíč roven vstupnímu parametru $id. Nová data určuje parametr $data. Návratovou hodnotou je počet ovlivněných záznamů. delete($id, $data) Metoda odstraní záznam z tabulky, kde je primární klíč roven vstupnímu parametru $id. Návratovou hodnotou je počet ovlivněných záznamů. getTable($tableName) Privátní metoda repozitáře, která umožňuje přistupovat k jiným tabulkám, než k tabulce přiřazené repozitáři. Vrátí tabulku s názvem podle vstupního parametru. Jednotlivé repozitáře jsou předány fasádě, která zapouzdřuje jejich metody. Fasády pro naší aplikaci byly vytvořeny dvě — BackendFacade pro administraci a FrontFacade pro frontendovou část aplikace. Fasády umožňují k základním CRUD metodám repozitářů doplnit další parametry pro získávání dat, připravují data do patřičného formátu pro vložení nebo editaci záznamu. Takto lze například získat data, která nemají nastavený příznak „smazáno“. Ukázka zdrojového kódu 5.1 demonstruje vyhledání soutěže pro frontend podle primárního klíče, která nemá nastavený příznak smazáno a má být podle data zobrazení zobrazena. Zdrojový kód 5.1: Zapouzdření metody repozitáře metodou fasády. public function getContestById ( $id ) { return $this - > co ntestR eposi tory -> findAll () -> where ( ’ id ’ , $id ) -> where ( ’ deleted ’ , 0) -> where ( ’ from < ’ , new \ DateTime () ) -> fetch () ; }

V našem systému třída UserManager implementuje metody rozhraní \Nette\Security\IAuthenticator a slouží k autentizaci, přihlášení a odhlášení uživatelů. Při integraci se serverovým prostředím zadavatele komunikuje tato třída jako jediná s databází aplikace zadavatele, ke které má přístupová práva pouze pro čtení. Z tohoto důvodu není možná registrace uživatele přímo v našem projektu. Protože jsou hesla uživatelských účtů v databázi zadavatele uchovávány pouze jako otisk, byla vytvořena třída 56

5.2. Nestandardní části aplikace www .................................... kořenový adresář web serveru app .................. zdrojové soubory aplikace s veškerou logikou AdminModule ..................... modul administrace aplikace config ........................... konfigurační soubor aplikace model .......................... model z MPC modelu aplikace presenters ................. presenter z MVP modelu aplikace router........................................router aplikace templates ............... view šablony z MVP modelu aplikace bootstrap.php ..............zaváděcí script Nette frameworku log...............................log vyjímek a chybových hlášek temp .................................... cache a dočasné soubory vendor........................................načítané knihovny helpers...............................vlastní pomocné funkce nette ..................... zdrojové soubory Nette frameworku others...............................ostatní využité knihovny www ..................................... cache a dočasné soubory adminer ................. grafické rozhraní pro správu databáze css .............................. soubory s kaskádovými styly files..................adresář pro uživatelský upload souborů fonts ..................... fonty a ikony pro Twitter Bootstrap images...............................obrázky designu aplikace js ................................................ javascripty plugins.......................................jQuery pluginy index.php .............................. vstupní bod aplikace Obrázek 5.1: Adresářová struktura aplikace (soubory kurzívou). Passwords, která je připravená pro převod hesel z plain textu na jejich otisk. Požadavkem zadavatele byla realizace aplikace v PHP frameworku Nette (sekce 3.1.1). Při použití Nette je dobrou praxí rozdělení souborů do předem dané adresářové struktury, kterou popisuje obrázek 5.1.

5.2

Nestandardní části aplikace

Nestadardní částí při implementaci bakalářské práce bylo propojení webové aplikace s herními servery pomocí jazyka PHP. V analytické části jsme pro komunikaci zvolili knihovnu SourceQuery [33], která je implementována jednoduchým objektovým způsobem a umožňuje veškerou potřebnou 57

5. Implementace funkcionalitu pro naše účely. S využitím této knihovny se nám podařilo implementovat script, který komunikuje s herními servery pomocí PHP. Pro komunikaci s herními servery slouží třída ServerControl, která obsahuje pouze metodu reserveServers() (ukázka zdrojového kódu 5.2). Tato metoda je připravená pro pravidelné volání v hodinovém intervalu tak, aby byla schopná nastavit přístupové heslo k serveru na základě rezervace. Metoda při zavolání nejprve pomocí serverového repozitáře získá všechny dostupné servery, následně vytvoří objekt třídy SourceQuery. Jednotlivé servery jsou iterovány a pro každý server je získána aktuální rezervace, která má být provedena (pokud rezervace nemá být provedena, pokračujeme v iteraci). Pomocí objektu třídy SourceQuery se následně připojíme k hernímu serveru (metoda Connect(adresa, port, timeout, typ_serveru)) a nastavíme RCON heslo pro vzdálený přístup k ovládací konzoli herního serveru (metoda SetRconPassword(heslo)). Nyní můžeme zasílat příkazy hernímu serveru (metoda Rcon(příkaz)), zašleme tedy požadavek na změnu přístupového hesla. Dotaz na aktuálně nastavené heslo slouží pouze k testovacím účelům. Důležité je po odeslání příkazu na změnu hesla metodou Disconnect() zrušit připojení k serveru, aby mohlo být otevřeno nové pro následující server. Ukázku skriptu v praxi nalezneme v sekci testování (sekce 6.2). Zdrojový kód 5.2: Komunikace s herními servery pomocí knihovny SourceQuery. public function reserveServers () { $servers = $this - > serverRepository - > findAll () ; $sq = new \ SourceQuery () ; foreach ( $servers as $s ) { $r = $this - > g e t A c t u a l R e s e r v a t i o n ( $s ) ; if (! $r ) { continue ;} $sq - > Connect ( $s - > address , $s - > port , 1 , SourceQuery :: GOLDSOURCE ) ; $sq - > SetRconPassword ( $s - > rcon ) ; $sq - > Rcon ( ’ sv_password " ’ . $r - > password . ’" ’) ; $res = $sq - > Rcon ( ’ sv_password ’) ; echo " <pre > " . $res . " " ; $sq - > Disconnect () ; $r - > update ( array ( ’ isPast ’ = > TRUE ) ) ; } }

58

Kapitola

Testování V této kapitole je popsán způsob testování jednotlivých funkcionalit výsledné webové aplikace. Dále je zde uvedeno, jakým způsobem bylo provedeno testování komunikace mezi herními servery a aplikací. Hlavním úkolem testování bylo ověřit, zda systém splňuje veškeré případy užití popsané v sekci 3.2.2.

6.1

Obecné testování aplikace

Pro pohodlné testování aplikace byl vytvořen script pro inicializaci, který vytvoří systémového uživatele a 30 uživatelských účtů — script je dostupný přes url adresu \init. Aplikace byla testována ve třech iteracích. Každá iterace představuje přihlášení uživatele v jedné z uživatelských rolí (sekce 3.2.1). Pro každou iteraci byly vykonány akce popsané v případech užití dle daného účastníka. Výsledek testování byl úspěšný, podařilo se vykonat veškeré případy užití popsané v sekci 3.2.2. Podrobné testování aplikace s vytvořením případů testování nemělo pro naše účely smysl, neboť systém není natolik složitý, aby se vyplatilo vytvoření jednotlivých případů testování — byly by totožné s případy užití, proto bylo testování provedeno tímto způsobem.

6.2

Komunikace s herními servery

Pro testování komunikace s herními servery byl využit herní server vytvořený na lokálním stoji. Tento server byl spuštěn s výchozími údaji, které byly vloženy do aplikace. Poté pomocí uživatelského účtu byl server zarezervován, bylo nastaveno heslo pro přístup. Tyto akce dokumentuje obrázek 6.1. 59

6

6. Testování

Obrázek 6.1: Zachycení údajů před zavoláním rezervačního scriptu. Následně byla zavolána metoda pro rezervaci herních serverů, která vrátila následující text: "sv_password" is "test_heslo_bp". Zkontrolováním aplikace serveru jsme potvrdili, že komunikace s herními servery je funkční — viz také obrázek 6.2.

Obrázek 6.2: Zachycení údajů po vykonání rezervačního scriptu.

60

Závěr Vytvoření webové aplikace pro pořádání soutěží mezi hráči akčních multiplayerových her v rámci této bakalářské práce bylo úspěšné. Aplikace je spravována z administrátorského rozhraní. Uživatelé mohou zobrazovat soutěže, žebříčky soutěží, zápasy, profily klanů apod. Zadání práce bylo bez výhrad splněno, systém je však připraven na rozšíření o další funkcionality, o kterých se v nejbližší době bude jednat se zadavatelem. Práce na projektu budou pokračovat i nad rámec bakalářské práce a to přímo pro zadavatele. Výsledkem bakalářské práce je aplikace, která splňuje veškeré požadavky zadavatele a může být nasazena jako přidružený portál k stávajícímu portálu Gamesites.cz. V počáteční fázi bude hlavním účelem aplikace získat zpětnou vazbu od uživatelů, kteří systém využijí. Na základě těchto poznatků se bude jednat o dalších změnách v aplikaci. Proběhne změna celkového vzhledu (redesign) dle požadavků zadavatele. Do budoucna budou také přidány další herní platformy.

61

Literatura [1] Adaptic, s. r. o.: Co je Drobečková navigace. 2014. Dostupné z: http: //www.adaptic.cz/znalosti/slovnicek/drobeckova-navigace/ [2] AMX Mod X Dev Team: AMX Mod X. 2014. Dostupné z: http:// www.amxmodx.org/about.php [3] AVONET, s.r.o.: AVONET - internet | data | hlas. 2014. Dostupné z: http://avonet.cz/ [4] Blažek, M.: Gamesites.cz. www.gamesites.cz

2014.

Dostupné

[5] devbook.cz: Facade (fasáda). 2014. //www.devbook.cz/facade-navrhovy-vzor

Dostupné

z:

http:// z:

http:

[6] GameData, Inc.: Half Life TV : HLTV Instructions. 2009. Dostupné z: http://www.counter-strike.com/faqs/hltv/ [7] GitHub, Inc: Getting started. 2014. //getbootstrap.com/getting-started/

Dostupné

z:

http:

[8] The jQuery Foundation: jQuery. 2014. Dostupné z: http:// jquery.com/ [9] Nette Foundation: Class Selection | Nette Framework 2.0.14 API. 2012. Dostupné z: http://api.nette.org/2.0.14/ Nette.Database.Table.Selection.html [10] Nette Foundation: Class Table | Nette Framework 2.0.14 API. 2012. Dostupné z: http://api.nette.org/2.0.14/namespaceNette.Database.Table.html 63

Literatura [11] Nette Foundation: Debugování a zpracování chyb. 2014. Dostupné z: http://doc.nette.org/cs/2.1/debugging [12] Nette Foundation: Dependency Injection | Nette Framework. 2014. Dostupné z: http://doc.nette.org/en/2.1/dependency-injection [13] Nette Foundation: Model-View-Presenter (MVP) | Nette Framework. 2014. Dostupné z: http://doc.nette.org/cs/0.9/modelview-presenter [14] Nette Foundation: Nette Framework. 2014. Dostupné z: http:// nette.org [15] Oracle Corporation and/or its affiliates: MySQL :: The world’s most popular open source database. 2014. Dostupné z: http:// www.mysql.com/ [16] The PHP Group: PHP 5 ChangeLog. 2014. Dostupné z: http:// www.php.net/ChangeLog-5.php [17] The PHP Group: PHP: Hypertext Preprocessor. 2014. Dostupné z: http://www.php.net/ [18] PLAYzone.cz: PLAYzone.cz. 2014. //www.playzone.cz/o-playzonecz

Dostupné

z:

http:

[19] Refsnes Data: CSS Introduction. 2014. Dostupné z: http:// www.w3schools.com/css/css_intro.asp [20] Refsnes Data: JavaScript Introduction. 2014. Dostupné z: http:// www.w3schools.com/js/js_intro.asp [21] SHIFTERS.eu: Shifters.eu » Game Portál & League. 2014. Dostupné z: http://www.shifters.eu/ [22] Undzwei developer team: Undzwei. 2014. Dostupné z: http:// www.undzwei.eu/ [23] Valve Corporation: Counter-Strike. 2014. Dostupné z: http:// store.steampowered.com/app/10/ [24] Valve Developer Community: Goldsource. 2013. Dostupné z: https: //developer.valvesoftware.com/wiki/GoldSrc [25] Valve Developer Community: Steam Condenser. 2013. Dostupné z: https://developer.valvesoftware.com/wiki/Steam_Condenser 64

Literatura [26] Valve Developer Community: Half-Life Dedicated Server. 2014. Dostupné z: https://developer.valvesoftware.com/wiki/HalfLife_Dedicated_Server [27] Valve Developer Community: Source RCON Protocol. 2014. Dostupné z: https://developer.valvesoftware.com/wiki/RCON [28] Vilčinský, P.: Gamester.cz. gamester.avonet.cz/

2006.

Dostupné

z:

http://

[29] Vrána, J.: NotORM - PHP library for simple working with data in the database. 2010. Dostupné z: http://www.notorm.com/ [30] Vrána, J.: Class Nette | Nette Framework 2.0.14 API. 2012. Dostupné z: http://api.nette.org/2.0.14/ Nette.Database.Table.ActiveRow.html [31] W3C: HTML/ - Web Education Community Group. 2014. Dostupné z: http://www.w3.org/community/webed/wiki/HTML/ [32] Wynter, S.: Source RCON Class. 2004. Dostupné z: http:// fremnet.net/article/199/source-rcon-class [33] xPaw: PHP Source Query Class. 2012. Dostupné z: https:// github.com/xPaw/PHP-Source-Query-Class

65

Příloha

Screenshoty aplikace

Obrázek A.1: Ukázka výpisu uživatelů v administraci.

67

A

A. Screenshoty aplikace

Obrázek A.2: Ukázka detailu vybrané ligy.

68

Obrázek A.3: Ukázka výpisu turnajů na frontendu.

69

A. Screenshoty aplikace

Obrázek A.4: Ukázka profilu vlastního klanu včetně ovládacích prvků.

70

Příloha

Obsah přiloženého CD

root readme.txt.............................stručný popis obsahu CD install.txt..................................instalační příručka src impl..............................zdrojové kódy implementace sql......................zakládací script pro MySQL databázi thesis.................zdrojová forma práce ve formátu LATEX utils ............. potřebné nástroje pro běh aplikace ve Windows webServ ............................. webový server s databází hlds .................................... testovací herní server text..................................................text práce thesis.pdf........................text práce ve formátu PDF 71

B