Semestrální práce

X36MMA

Téma:

BloF

(procházení virtuální 3D budovou skoly

Felu a implementace do Cave)

Pavel Holý

2. ročník

Obsah

Úvod

Inspirace

Dejvice 3D

Quake III Arena

IO Quake

Xreal

Hry současnosti

Vývoj

Aplikace pouzité při vývoji

Quake III Arena

GTK Radiant

3DS Max

Adobe Photoshop

MS Visual Studio

Postup a fáze vývoje

Jednoduchá mapa

Rozvoj jednoduché mapy

Ozivování mapy

Programování

Řesení problému

Co je Cave

Konkretizace problému

Řesení problému

Advanced solution

Problém v problému

Ukázka finálního kódu

Ukázka v praxi

Současný stav

Obrazárna

Budoucnost projektu

Vývoj mapy

Vývoj aplikace

Vyhledávání tříd

Simulace evakuace

Klasická střílečka

Dalsí experimenty

Závěr

Literatura a zdroje

1. Úvod

V průběhu semestru se na hlavních stránkách fakulty objevil odkaz na aplikaci, která obsahovala virtuální podobu budovy FELu včetně vyhledávání místností, jejíz název je Dejvice 3D. Tato aplikace byla velikým zdrojem inspirace pro tuto semestrální práci.

Rozhodl jsem se vyuzít několika jiz hotových věcí, které ulehčily mojí práci a vytvořit novou, lepsí aplikaci, která bude obsahovat lepsí model skoly a dalsí nové funkce.

Vedlejsím cílem této semestrální práce je nastudování enginu a vývojového prostředí, vytvoření postupu pro vývoj projektu, s cílem navázat bakalářskou práci.

Hlavním cílem je předevsím vytvoření základu modelu skoly a řesení problému implementace aplikace do Cave, případně řesení problémů souvisejících s realizací první fáze vývoje.

2. Inspirace

Při realizaci se naskytlo mnoho mozností, jak cíle realizovat, inspirací se staly mnohé z nich. Ale některé více nez jiné a konkrétní věci byly pouzity přímo pro vývoj, jako výchozí software, nebo jako zdroj informací apod.

2.1 Dejvice 3D

Hlavním motivem vytvoření BloF byla aplikace Dejvice 3D dvou studentů FEL. Původní myslenka byla tuto aplikaci vylepsi a zpřesnit model. Bohuzel toto se ukázalo jako nemozné z mnoha důvodů. Jádrem aplikace je jednoduchý engine, který je značně nedokonalý a spoustu věcí neumozňuje. Bylo tedy nutné pouzít něco lepsího, protoze přepisovaní tohoto enginu by trvalo spoustu času a hlavní cíle by to nesplnilo. Proto byl pouzit engine quake 3 (viz níze).

Dalsí myslenka byla do tohoto enginu převést jiz hotový model skoly a ten upravit do vlastností quake. Bohuzel tento model nebyl velmi dobře optimalizovaný a obsahoval spoustu nepřesností. Dokonce i spatné poměry nebyly moc vhodné pro quake engine a textury byly nepřílis kvalitní a v nepouzitelném formátu BMP a TGA. Také počet vertexů byl neoptimalizovaný z důvodu nedobré volby modeláře.

Následovala jediná mozná varianta, tedy vytvořit vlastní model za pouzití vývojových nástrojů, vytvořených přímo pro Quake. A pouzít modelu Dejvice 3D jako podklad i zdroj informací.

2.2 Quake III Arena

Kvalitně napsaná hra z roku 1999, která je fascinující svojí jednoduchostí a dokonalostí. Zajisté jiz dlouho není spičkou v oboru, ale poskytovala jiz tehdy volnost pro hráčskou a programátorskou scénu obohacovat tuto hru svými výtvory. Ale v roce 2005 její tvůrci uvolnili zdrojové kódy k samotné aplikaci a umoznili tak její libovolnou modifikaci a dalsí síření pod general public licence.

Pro tento projekt to byla výtečná volba. Tedy engine, který je vyzkousený a po letech zdokonalený je volně přístupný a dále siřitelný. A je zde moznost velice jednoduse tuto aplikaci modifikovat, jelikoz je napsána v C++ a je připravena pro MSVC, kde je velice jednoduse zbuildovatelná.

2.3 IOQuake

Po uvolnění zdrojového kódu k aplikaci se skupina nadsených programátorů amatérů rozhodla vyčistit kód quake, přidat základní bezpečnostní prvky a zjednodusit kód, jak jen je mozné.

Svoje snazení dávají volně k dispozici a je mozno vyuzít jejich verze na tomto projektu, coz velmi zjednodusuje práci s kódem. A díky bezpečnostním prvkům se stává výsledek, ať jiz bude jakýkoli, stabilní a bezpečný proti útokům.

Značnou nevýhodou je v tomto případě neukončený vývoj, coz komplikuje připisování vlastních funkcí, které se budou muset přenáset mezi novými releasy. Ale výhody, které pouzití IOQuake přinásí, jsou značné. Hlavně zpřehlednění kódu a nové komentáře, které pomáhají pochopení jednotlivých částí kódu.

2.4 Xreal

Podobný projekt jako IOQuake. V tomto případě skupina německých programátorů začala silně modifikovat engine Quake s cílem konkurovat současným hrám. Tomu se snazí přiblízit implementováním částí kódu z Dooma 3, který je podobně stavěný jako Quake, ale obsahuje nové funkce. V Xrealu bylo přidáno například dynamické osvětlení a stíny, podpora nových modelů a fyzikálních enginů.

Bohuzel z Xrealu se stává nepouzitelná zálezitost díky nekompletnosti projektu. Bohuzel doslo k velmi zásadnímu přepsání kódu, který se tím stal značně nečitelný. Chybí také jakákoli dokumentace.

V současné době působí Xreal spíse jako rozestavěná budova a není zcela jasné, jak bude vypadat. Proto je velmi tězké pouzít ho jako základ pro projekt. Ale nelze vyloučit pouzití nějakých zajímavých funkcí, které byly do Quake přidány.

2.5 Hry součastnosti

Cílem je projekt dotáhnout do co nejinteraktivnějsí podoby. Je tedy třeba do něj zakomponovat co nejvíce prvků, které jsou pro současné hráče zajímavé. Graficky nelze konkurovat nejmodernějsím produktům, na kterých pracují veliké týmy lidí.

Často se nejoblíbenějsí hry nepysnily dobrou grafikou, ale spíse dobrými nápady a provedeními. Jedním z cílů je do aplikace zabudovat pravidla, která udělají z BloFu interaktivní zálezitost, nikoliv pouze prázdné procházení budovou skoly.

3. Vývoj

Kvůli časovému vytízení bylo třeba zvolit správný postup při vývoji BloFu. Důlezité bylo rozvrhnout vývoj do několika kroků, které mohou být postupně splněny. Je třeba vidět vývoj realisticky z pohledu schopností a časové náročnosti. Bohuzel kód není zcela jednoduchý na pochopení a práce s editory není z důvodu stáří programů přílis intuitivní, ale přesto se malé cíle zdají více nez reálné.

3.1 Aplikace pouzité při vývoji

Volba Quake enginu omezila i paletu jednotlivých aplikací, které jsou pouzitelné. Protoze samotný Quake má jistá omezení v tomto směru. Ke kazdé aplikaci zajisté existuje nějaká alternativa, ale i přes to si myslím ze zvolené aplikace vyhovují nejvíce pozadavkům projektu.

3.1.1 Quake III Arena

Pro vývoj je pouzita samotná aplikace, ale v konečné fázi nebude mít BloF s tímto produktem nic společného. Je pouze potřeba nedodělané věci nahradit jiz hotovými a vyzkouset tak funkčnost v průběhu vývoje, tím se setří čas a celý projekt je příjemnějsí na vývoj. Konkrétně při tvorbě prvních modelů map byly pouzity textury implementované do Quake, coz usetřilo čas potřebný na jejich tvorbu, kdyz jestě nebyly nezbytné. Také některé efekty a funkce byly pouzity pro dosavadní vývoj.

Pouzití Quake enginu má mnohé výhody, jako mnoho návodů a postupů, které jsou zveřejněny na internetu. Nebo moznost vyuzít spousty materiálů vytvořených v průběhu let, jako například modely lidí, textury, objekty apod.

Bohuzel s sebou nese i nevýhody, jednou z nich je zastaralost celé aplikace, která se promítá při práci s modely, ale i na výsledném produktu. Pro vykreslování je pouzito OpenGL, coz je minimálně skoda, protoze DitectX umozňuje pouzít velmi jednoduse mnohé efekty. Tento nedostatek lehce kompenzuje pouzitý IOQuake, který napojuje SDK ke kódu Quake a vyuzívá některé funkce DirectX 9.0. To ale na druhou stranu komplikuje vývoj, ale i přes to je to velký přínos.

Dalsí nevýhodou je absence moderních prvků, jako například fyzikální engine. Fyzika jako takový je v Quake psána tzv. natvrdo, tedy vsechny úkazy jsou jednotlivě osetřeny v kódu a aplikovány na minimum objektů, v podstatě jen na to nejnutnějsí. Jedním z cílů tohoto projektu je tuto skutečnost minimálně kompenzovat.

Fatálním nedostatkem Quake je absence dynamických světel, které jsou v současné době bězné. Na druhou stranu tato skutečnost dělá z Quake velice hardwarově nenáročnou zálezitost, ale v současné době výkonných počítačů je to spíse na skodu. Hardwarová nenáročnost je u Quake vyhnána do takového extrému, ze aplikace je spustitelná i na PDA a časem i na ultravýkoných mobilních telefonech. Coz by nebylo spatné vyuzití například pro vyhledávání tříd, které je součástí finálního produktu.

Mnohé dalsí nedostatky řesí IOQuake, případně také Xreal, který vyřesil i dynamická světla. Projekt BloF je postaven tak, aby do něj bylo přeneseno co nejvíce těchto vlastností. Dalsí výhodou je přenositelnost aplikace mezi různými platformami a OS, coz je mozné vyuzít.

Ve své podstatě byla volba Quake pro tento projekt velmi dobrá, jelikoz nevyzaduje tolik pozornosti k zprovoznění a je zde spousta prostoru pro vlastní tvorbu. A také umozňuje implementaci do systému Cave, coz bylo hlavním cílem této semestrální práce, viz níze.

3.1.2 GTK Radiant

Pro své potřeby vytvořila vývojová firma ID Soft svůj vlastní modelářský software, který je silně přizpůsoben vývoji map pro enginy této firmy. Skrývá v sobě jednoduché funkce a ve své době velice intuitivní prostředí.

Postupem času byl tento software zdokonalen a pouzit i pro vývoj map k Doom 3 apod. Mapy ukládá jako modely do vlastní souborové struktury MAP, která muze být mnoha způsoby vyrendrována (upravena) na výslednou mapu, která je pak pouzívána samotnou aplikací.

Tento způsob práce s modelem mapy činí mapu zcela nezávislou na aplikaci, ve které je pouzívána, pokud ji daná aplikace podporuje. Je zde tedy moznost pouzít mapu vytvořenou pro BloF i pro jiné hry jako je Doom 3, Quake 4 apod.

Minimální provázání s hlavní aplikací je nezbytné, ale je vyřeseno velice sikovně pouzitím parametrů a funkcí, které s těmito parametry pracují. Je tedy mozné si vlastnosti editoru modifikovat a libovolně s označenými objekty v hlavní aplikaci pracovat.

Samotné uzivatelské rozhraní je rozporuplné, poněkud zastaralé a na první pohled neintuitivní, ale po pečlivém nastudování návodu, je více nez sikovné. Bohuzel není psané pro veřejnost, ale naopak čistě účelově. Základní funkce nejsou ani na tlačítkách na listě, ale pouze na klávesových zkratkách bez jejíz znalosti je práce s editorem nemozná.

Hlavní okno aplikace se skládá ze tří oken, v jednom je k dispozici 2D pohled na model mapy, který je vykreslen pouze obrysy. Tento pohled se dá přepínat na různé osy, coz je oproti například 3ds Maxu nezvyk. Ale díky tomu je místo na dalsí uzitečná okna. Jedno z opravdových vymozeností je okno, které simuluje výsledek ve hře. Tedy plnohodnotný 3D pohled na model mapy, kterou je mozno procházet. Navíc jsou jednotlivé části potazeny texturami, je tedy mozno si udělat rychle dojem, jaký bude mapa ve výsledku dělat. Proto není nutné tak často mapu renderovat (zkouset jí v samotné aplikaci) coz zajisté setří čas.

Poslední okno aplikace obsahuje náhled textur, které je mozno pouzít. Coz opět velice setří čas. V editoru je obsazena spousta uzitečných funkcí, ale vse je dokonale jednoduché a po přečtení návodu není problém vymodelovat jakoukoli mapu.

Velikou výhodou je moznost vkládání do modelu mapy externí modely z jiných editorů a to dělá z mocného nástroje nástroj jestě mocnějsí, zvládá základní formáty jako 3DS, ASE, OBJ apod. Je tedy mozné v jakémkoli bězně pouzívaném editoru vytvořit model a jednoduse ho importovat do vytvořené mapy.

To s sebou nese rizika, jako například lehkou nekompatibilitu. Model je sice vlozen a vykreslen, ale pro hru nemá odpovídající vlastnosti, konkrétně lze modelem procházet a dokonce skrz něj střílet. Tohle Quake samozřejmě jednoduse řesí a to díky technice klipování, coz v jednoduchosti znamená vytvořit kolem vlozeného modelu objekt, který bude průhledný, ale bude ve hře mít odpovídající vlastnosti.

Celkově je práce s GTK Radiantem velkým usnadnění při vývoji BloFu. Je třeba naplno vyuzít jeho potenciál, hlavně v oblasti dopisování nových vlastností daných objektů a vlastních funkcí.

3.1.3 Autodesk 3DS MAX

Profesionální modelovací software, který umozňuje tvorbu libovoných modelů mnoha technikami, je tou nejlepsí volbou na doplnění Radiantu.

Umoznuje modelovat cokoli a výsledné modely jsou za pouzití i těch nejslozitějsích modelovacích technik exportovány do velice čitelného a přehledného ASE formátu, se kterým se Quake velice jednoduse poradí.

Výhodou je ze Quake zvládne importovat i animace, které dokáze ve hře pouzívat. Je tedy nezbytností, aby tyto vlastnosti byly co nejvíce pouzity v tomto projektu.

Mnohé problémy mohou nastat v přílisné slozitosti modelů, které pak budou zpomalovat celou aplikaci, ale díky optimalizaci modelů při překládání mapy se tento jev minimalizuje. Dalsí nepříjemností je klipování, coz můze u některých obvzlástě slozitých modelů přidělávat práci. Neméně důlezité je měřítko, které se vůči mapě tezko odhaduje, a pozdějsí scalování můze model zcela znehodnotit.

U externího modelovacího softwaru je značný prostor pro jiné produkty. 3DS Max nemusí být zdaleka jedinou volbou. Stejný účel by splnila u Maya, Blender případně MilkShape a mnohé jiné. Pro předchozí zkusenosti nejlépe vyhovuje Max.

V modelovacím softwaru se nejedná pouze o editaci a tvorbu doplňků do mapy, ale také samotných postav hráčů, které je třeba upravit pro vlastní potřebu. Stejně tak jakékoli objekty, které jsou ve hře pouzity je třeba modifikovat v externím editoru, protoze Radiant slouzí výhradně k modelování map. Pro takovéto potřeby není vybaven nezbytnými funkcemi.

3.1.4 Adobe Photoshop

Jediná mozná volba pro práci s obrázky, tedy texturami v tomto projektu. Je zcela nezbytné aby výsledné textury měly co nejvyssí kvalitu a co nejmensí velikost z důvodu rychlejsího načítání do paměti.

Drtivá vetsina textur rp BloF je děladná z fotek, které jsou vyfoceny přímo na skole. V photoshopu jsou pak fotky editovány a textury z nich vyrobeny. Pro účely BloFu i dalsích her je třeba, aby textury navazovaly ve vsech směrech samy na sebe, aby se daly kopírovat vedle sebe a nebyly patrné přechody.

To je samo o sobě velmi tezký úkol z důvodu nerovnoměrného nasvícení objektů ve skole. Na několika centimetrech se navícení objektů velmi znatelně mění a to pak znemozňuje plynulé navazování.

Z tohoto důvodu je pouzit Photoshop, který má v sobě zabudovány funkce, které zjednodusují práci s texturami a výsledek velmi kvalitně komprimují.

Konečná textura je pak pouze načtena Radiantem a přeřazena patřičnému objektu. Quake také jako jedna z prvních her své doby přisel s technologií mutlitexturování, coz je realizování pomocí skriptů (viz níze).

3.1.5 Microsoft Visual Studio

Vůbec nejdůlezitějsí aplikací ve vývoji je právě Visual studio, ve kterém je celá aplikace napsána. Je tedy více nez jednoduché jí modifikovat a to zcela libovolně.

Projekt do visual studia se skládá z dílčích podprojektů, které jsou následující: quake - jako samotná aplikace, tedy exe soubor, renderer - který se stará o vyktreslování, qagame - pravidla pro server ve formě dll, cgame - pravidla pro klienta, ui - user interface a botlib - tedy knihovna obsahující vse pro boty (počítačem ovládané postavy).

Celý tak mohutný projekt, který obsahuje přes 4000 samostatných souborů je velice tězké pochopit a začít modifikovat. To bohuzel zabírá mnoho času, ale paradoxně ho také setří, protoze mnoho věcí, které budou vy výsledném produktu je v Quake jiz napsáno a je třeba pouze správně zasahovat do určitých míst kódu.

Velikou výhodou je přítomnost mnoha komentářů, které setří práci. Na internetu je k dispozici také mnoho návodů a tutoriálů, které práci s kódem vemi usnadňují.

Překonat takové mnozství řádek je velký úkol, ale moznosti jeho vyuzití a rozsíření jsou skoro neomezené a umozňují volnost, které je třeba v projektu vyuzít.

3.2 Postup a fáze vývoje

Je nezbytná vhodná volba postupu při vývoji tak rozsáhlého projektu. Je vhodné začít jednoduchými věcmi, ty postupně propojovat a přecházet k věcem slozitějsím, aby bylo mozno dovést projekt do finální podoby co nejdříve a flexibilně, podle potřeby.

3.2.1 Jednoduchá mapa

Nejprve je třeba začít s původním Quake, a do něj přidělávat postupně věci, které vy výsledku nahradí celou původní aplikaci. První jednudochou věcí je přidání vlatní mapy, která je vytvořena v Radiantu.

Bylo potřeba si vyzkouset samotné překládání mapy pro Quake a zvládnutí práce s editorem. K tomu jsou nastěstí dokonce i oficiální manuály. Takze tato fáze zabrala pouze několik dní studia manuálu.

K vytvoření jednoduché mapy byly pouzity původní textury z Quake. Pro tu nejjednodusí mapu stačí 4 stěny, světlo a startovní pozice hráče. Tato místnost můze při testování způsobovat lehkou klaustrofóbii.

Pro rozvoj mapy bylo nutné ji rozsířit a přidat více místností a průchody osadit dveřmi, na které uz byla pouzita první zabudovaná funkce door, která se stará o otevírání dveří v přitomnosti hráče.

3.2.2 Rozvoj jednoduché mapy

Při přecházení ke slozitějsím částem mapy je třeba sáhnout k vlastní tvorbě textur a s tím souvisí natahování textur na objekty, coz je zcela nezbytná věc. Defaultně jsou textury ve velmi nízkém rozlisení z historických důvodů a je třeba je scalovat a shiftovat tak, aby se dosáhlo co nejlepsího vzhledu. Nastěstí není velikost a kvalita textur omezená, coz je pro tento projekt veliká výhoda a mohou tak být pouzity fotorealistické textury o velkých rozliseních.

Dalsí fází zesloziťování mapy je vyuzití dalsích zabudovaných funkcí, mezi podstatné patří train a rotate, které pohybují danými objekty podle nastavení. K dispozici jsou i jiné, ale otázkou je jejich vyuzití v tomto projektu.

Součástí editoru je i jednoduché modelování a pouzívání oblých objektů, které je velice intuitivní.

Dalsím krokem uz je pouze vytváření základů budovy skoly. V tomto případě je rozumné začít jedním patrem a k němu postupně přídělávat dalsí a vytvořit tak postupně celou budovu.

3.2.3 Ozivování mapy

Mapa muze být velice jednoduse doplněna externímy objekty. Jedná se konkrétně o doplňky jako je například hasicí přístroj, kelímek od automatu a podobné detaily, které vsak dodávají realističtějsí vzhled.

Dalsí silným nástrojem na ozivení mapy je zabudované skriptování vlastností shaderů. To znamená dopisování vlastností jednotlivých textur. Touto metodou je realizováno multitexturování, průhlednosti textur, jejich rozmazávání apod. Lze tak jednoduse vytvořit okno s efektem lesku, či lesk na podlaze. Ke skriptování se pouzívá několika přednastavených funkcí podle návodu, ale je moznost tyto funkce měnit a přidávat.

3.2.4 Programování

Po vytvoření mapy je třeba se začít zabývat samotnou aplikací, jelikoz výsledným produktem nebude bezmyslenkovitá a "jatka co do mnozství krve překonávající" střílečka, ale aplikace, která simuluje zivot na skole umozňující vyhledávání tříd a případně simulaci evakuace.

Je tedy třeba modifikovat jádro aplikace a přidat nové funkce a uzivatelké prostředí přetvořit na něco mírnějsího. To obnásí přepsání mnoha řádek kódu a vytvoření nových obrázků a textur pro menu.

Je mozno zachovat předchozí věci, které souvisejí spíse s nastavením aplikace a vykreslováním, jelikoz v součastném zpracování Quake je toto vyřeseno vskutku geniálně.

Těmito zásahy vzniká mnozství problémů. Oproti tvorbě mapy je toto zálezitost, která není nijak osetřena tvůrci a není nikde popsána, tedy zde je místo pro vlastní myslenky a přínos tohoto projektu. Jako zadání jsem zvolil problém implementace Quake jakozto modifikované aplikace, která je stále spíse Quake nez BloF, do tzv. Cave (viz níze). Konkrétně se jedná o modifikaci kódu, která umozní spustění na slozité soustavě, kterou Cave disponuje.

K současnému stavu vývoje je nutno jestě zmínit současný stav, směr a budousnost projektu (viz kap.4), ale to je spíse důsledek vyřesení problému s Cavem.

4. Řesení problému

Hlavní náplní této semestrální práce bylo vyřesení problému implementace Quake (potazmo BloFu) do systému Cave

4.1 Co je Cave

Cave je multimediální místnost, která má na třech stěnách promítaný obraz ze tří propojených PC, kam se uzivatel postaví a má dojem virtuální reality. Toho je docíleno tzv. stereo promítáním a je tak navozen dojem 3D vidění.

Pro cave byla vytvořena speciální knihovna, která je částečně kompatibilní s mapami pro Quake, ale potlačuje jakékoli funkce aplikace a omezuje se na pouhé procházení a to bez moznosti pohledu nahoru a dolů. Coz je velmi omezující a pro plnou funkčnost BloFu je nezbytné, aby tento problém byl na Cave vyřesen.

4.2 Konkretizace problému

Quake sám o sobě má funkci vykreslování do sterea, a to díky přímému pouzívání OpenGL, tedy pokud karta Stereo podporuje. Dokonce je v Quake i funkce ovládající hloubku vykreslovaní sterea, které se tak dá velice jednoduse ovládat.

Problémem je absence různých pohledů z hlediska jednoho hráče (neboli jedné kamery). Je třeba s postavou hráče v této situaci kalkulovat jako s kamerou , která se pohybuje po mapě. Přední obraz v Cavu je bez problémů, je 3D a vykresluje pohled hráče směrem dopředu, ale ostatní stěny jsou prázdné.

Hráč nemá moznost se podívat doleva nebo doprava ani ve hře, coz je velmi omezující faktor, oproti například leteckým simulátorům. Dalsí problém je, ze ostatní projektory jsou ovládány jinými počítači a je třeba nějak řesit synchronizaci a projekci té samé mapy.

4.3 Řesení problému

Řesení je třeba hledat co nejjednodussí s vyuzitím dalsích vlastností, které Quake má. Problém synchronizace Quake umozňuje řesit velice jednoduse - pomocí tzv. síťové hry, resp. propojení totozných aplikací přes lokální síť. Ve hře toto funguje jako propojení 3 nezávislých hráčů do jedné mapy, kde by normálně hráli proti sobě. Ale pro potřeby Cavu je zde nastěstí jestě jedna funkce, která se nazývá spectate. Ta umozňuje hráči, který je připojen do nějaké hry, sledovat přesné pohyby hráče, kterého sleduje.

Tím je vyřeseno promítání stejné mapy a synchronizace, která se provádí jednoduchou komunikací typu klient - server. Po pouzití tohoto triku by ale výsledek byl následovní - na kazdé stěně by se promítalo to, co vidí jeden hráč, ale pohledem před sebe, coz je spatně. Je tedy nutno postraním počítačům říct, aby otočily pohled o 90 stupňů za pouzití stejné aplikace.

4.4 Advanced solution

Kvůli spolupráci po síti je třeba zachovat stejný build na vsech PC. Je tedy nějak potřeba ovládat jednotlivé pohledy parametrem. Proto byla v kódu vytvořena proměnná cg_FelCave. Ta funguje jako měnič pohledů. S hodnotou 0 je aktivován pohled popředu, s hodnotou 1 doprava, a 2 doleva.

Samotná změna v kódu tak jednoduchá není a vyzaduje dokonalou znalost systému řízení přerusení od mysi a příslusné reakce. Nutnou znalostí je také soustava proměnných a funkcí, které řídí zobrazování. Výsledek se můze zdát velmi jednoduchý, ale taková změna kódu vyzadovala spoustu testování.

4.5 Problém v problému

Pohled kamerou je dokonalé přirovnání k tomu, jak Quake opravdu funguje. Pro pohledy rovné bez naklonění, je vse bez problémů. Ty se vsak objevují při pohledu nahoru a dolů, jelikoz kamera se při těchto pohledech naklání a tím se rozjízdí i jednotlivé úhly naklonění v otočených pohledech. To způsobuje nepříjemný efekt překrývání a vzniku slepých míst při kombinaci vsech tří pohledů.

Řesení se nabízí jediné. Převést proces, který v otočených pohledech, naklání pohledem, aby s ním namísto toho rotoval adekvátně k naklánění předního pohledu.

V reálu je takovéto řesení jednoduché, ale v kódu by se mohlo jednat o desítky řádků, které by navíc mohly být zbytečné.

Cílem bylo vymyslet geniální řesení, které by bylo krátké a jednoduché. Nastěstí v tom vysel Quake vstříc a díky systému na jakém funguje stačilo pár drobných úprav na správných místech. Konkrétně slo o zvýsení úhlu, ze kterého se kamera dívá na scénu a natočení tohoto pohledu. Také se jednalo o změnu kopírování vektorů, které jsou výsledkem vstupu mysi, na jiné operace s kamerou, nez jaké byly původně.

To celé je aplikováno jako závislé na hodnotě proměnné cg.felCave.

4.6 Ukázka finálního kódu

if( cg.felCave>0)

}

else

VectorCopy( ps->viewangles, cg.refdefViewAngles );

Raději bez zdlouhavých komentářů, samotné získávání Yaw, Roll a Pitch je velmi slozité a samotné přehazování bylo otázkou nastudování jak přesně fungují. Některé operace jako přičítání 30˚ k úhlu náklonu byly otázkou testování a původ spatné hodnoty zůstává nevysvětlen.

4.7 Ukázka v praxi

Screenshoty z testování řesení problému v praxi, na projektu BloF na jednom PC, který simuloval server s pohledem dopředu a pohledem do strany jako připojený klient.

5. Současný stav

V současné době je projekt v pokročilé fázi a tězký start má jiz zdárně za sebou. Je vytvořen kvalitní základ mapy, na kterou je aplikováno hodně efektů a je do ní vlozeno mnozství externích objektů.

V kódu aplikace proběhlo pár minoritních změn, ale vse je připraveno k plnohodnotnému rozvoji. Zatím největsí úspěch je zdárné dokončení implementace do Cave. Řesení bylo vyzkouseno a aplikace je tak připravena na pouzití.

5.1 Obrazárna

Na úspěchy dosazené při modelování map nejlépe poukazují následující obrázky. Zároveň také srovnávají realitu a model skoly v naprosté otevřenosti a upřímnosti.

Pohled na chodbu

Kose na tříděný odpad

Pohled na schodistě

Detail schodistě

6. Budoucnost projektu

Finální koncepce celého projektu jestě není zcela jasná. Jelikoz mozností je mnoho a je velmi tězké odhadnout časovou náročnost jednotlivých konceptů. Zatím je vse ve fázi promýslení. Je třeba jednoznačně určit cíle, coz se týká vsech fází vývoje.

6.1 Vývoj mapy

V mapách jsou cíle poměrně jasné, tedy dokončit budovu skoly co nejvěrohodněji s co nejvíce místnostmi. Otázkou je kde přestat, ale díky měnící se podobě skoly je toto poměrně nekonečný proces. Hlavním cílem je dodělat základ budovy, hlavní chodby a posluchárny, tedy vse co je podstatné pro aplikaci, která s modelem bude pracovat.

6.2 Vývoj aplikace

V aplikaci je finální cíl dosti nejasný, protoze projekt Quake je velmi rozsáhlý a přidávat do něj nové věci se dá takřka kdekoli. Otázkou je, co bude největsím přínosem pro projekt. Zda se soustředit na vývoj nových funkcí, jako implementace fyziky či dynamických světel, nebo na funkce z pohledu uzivatele, tedy třeba napojení aplikace na internetovou databázi, či přidělat autoupdate apod.

Dalsí mozností je se soustředit na výsledek, který uzivatel opravdu bude vyuzívat, tedy finální aplikaci. V této oblasti je minimálně jasné, co projekt zahrne, ale sám projekt je koncipován jako soubor více mozností vyuzití modelu.

6.2.1 Vyhledávání tříd

Jedna ze základních funkcí v BloFu by měla být vyhledání pozadované třídy, jako to bylo u aplikace Dejvice 3D. To můze být uzitečné pro nové studenty Fel, kteří si nejen prohlédnou budovu skoly a v té se zorientují, ale také si budou moct dopředu najít třídu, aniz by museli hledat na mapkách skoly. Díky simulaci reality si tak budou moci zapamatovat okolí a nebudou bloudit budovou a obtězovat profesory a studenty dotazy na lokaci tříd.

Pro implementaci takové funkce bude třeba se zaměřit na importování slozitých datových struktur do Quake. A také bude třeba zanést body do mapy a udělat z nich graf, ve kterém bude mozno vyhledávat nejkratsí cestu ke zvolené třídě (bodu). To s sebou nese pozadavek na znalosti, které by měli studenti probírat v průběhu 4. semestru, coz je značná výhoda.

Samotný výpočetní algorytmus by mohl být jako nezávislé vlákno na hlavní aplikaci, do kterého by se posílaly pozadavky na nalezení bodu na mapě, a které by vracelo trasu vůči aktuální poloze. Tím by se dala cesta dynamicky měnit, podle změny polohy na tu v dané chvíli nejefektivnějsí.

Mozná je i varianta, ze by postava sama dosla nejkratsí cestou k vyhledávané třídě, tedy něco jako autopilot, který by se po cestě dal kdykoli vypnout a zapnout.

6.2.2 Simulace evakuace

Zajímavá myslenka je implementovat do BloFu evakuační plány skoly a hlavní postavu dát do situace, která vyzaduje nouzový únik a rychlé jednání. Okolní postavy, jejiz inteligence by musela být dopsána, by reagovaly nahodile a hlavní postava by se musela rozhodovat podle jejich chování a podle znalostí bezpečnostních řádů.

Po ukončení akce by se chování postavy vyhodnotilo a bylo by odesláno do skolní databáze a student by musel projít bezpečnostním skolením.

Jedna z variant by obsahovala skolení přímo ve hře formou interaktviních tutoriálů. A výstupním testem by byla právě simulace skutečné krizové situace.

Zde by byl prostor pro libovolné programátorské experimentování, například systém síření ohně a jeho postup mezi různými povrchy. Také umělá inteligence dalsích postav by musela být napsána, v Quake je sice inteligence protivníků, kteří se snazí zabíjet co nejvíc a únik před ohněm jim je zcela lhostejný. Avsak dala by se zde pouzít celá řada napsaných funkcí a různých algorytmů pro boty.

6.2.3 Klasická "střílečka"

Pro studenty bohuzel bude pravděpodbně bezmyslenkovitá akčně-brutální řezba, která se podobá masovému vybíjení kuřat z chovu, kde byl nalezen virus ptačí chřipky. Samotná koncepce Quake nemusí být v BloFu vynechána, coz řesí základ této střílečky. Je zde tedy mozná hra po síti proti lidským oponentům, ale i proti počítačem řízeným protivníkům.

Zde je samozřejmě také prostor k rozvoji, ale tato větev je slepá, jelikoz BloF asi bude velmi tězko konkurovat moderním masovým vybíječkám s ultramoderní grafikou.

6.2.4 Dalsí experimenty

Na dalsí mozných variacích se pracuje, repsektive na jejich návrzích. Jak bylo jiz zmíněno, BloF je koncipován tak, ze by mohl obsahovat vsechny výse zmíněné moznosti a jestě mnohem víc a právě zde je prosto pro dalsí studenty, kteří budou chtít vyuzít model a velmi podajného kódu Quake 3.

7. Závěr

Já osobně vkládám do projektu velké naděje a chtěl bych ho odevzdat jako bakalářskou práci. Bohuzel rozsáhlost tohoto projektu převysuje schopnosti a časové moznosti jednoho člověka, proto je nezbytná spolupráce více lidí. Ti si ale práci mohou rozděli mezi jednotlivé části vývoje, nebo mezi jednotlivé módy aplikace.

Moznosti jsou opravdu skoro neomezené, ale je nutno vidět i jejich reálnost a splnitelnost. Rád bych tento projekt dotáhl co nejdál. A chtěl bych, aby z něj mělo uzitek co nejvíce lidí, případně aby se nasel někdo, kdo na projekt naváze.

Novinky a vývoj je mozné sledovat na stránkách projektu - www.blof.ic.cz

8. Literatura a zdroje

www.idsoftware.com

Manuál ke GTK Radiant

www.quakedev.com

fps.brainerd.net

www.qeradiant.com

tutorials.moddb.com

code3arena.planetquake.gamespy.com

a mnohé dalsí.