Kdo sleduje tyto stránky pravidelně, jistě zaznamenal, že procento zkonvertovaných levelů Quadraxu Definitive se velmi rychle zhouplo na 100%. To znamená, že všech 500 levelů všech Quadraxů je zpracováno! Jak je to možné!? Je to především tím, že jsem totálně přehodnotil tvorbu převodního programu datových souborů levelů. U Quadraxu III a IV to ještě bylo jednoduché, tyto hry neobsahují mnoho aktivních prvků, ale už u Quadraxu V jsem se začal potýkat s tím, jak správně konvertovat nové funkcionality, jako jsou křehké kvádry, přenašeče, velké posuvné stěny atp. s vědomím,toho, že v dalších a dalších Quadraxech těchto ativních prvků jen přibývá. Nakonec jsem se rozhodl pro naprosto opačný postup - místo toho, abych konvertovací nástroj postupně doplňoval o nové a nové prvky (tak, jak se Quadraxy a jejich aktivní elementy postupně vyvíjely), rozhodl jsem se vytvořit konvertor přímo pro Quadrax VIII. Moje Quadraxy jsou totiž datově zpětně stoprocentně kompatibilní, a tak jsem si mohl být jist, že když napíši dobře převaděč dat z QVIII do QD, bude zpětně fungovat i na jakýkoliv starší Quadrax.

A jak je výše popsáno, tak se i stalo. Po dokončení konverze levelů z QIV jsem rozšířil převaděč dat tak, že dokázal plně zkonvertovat levely z QVIII včetně všech jeho objektů. No a jak bylo toto hotovo, stačilo převaděč pustit zpětně na levely Quadraxů VIII, VII, VI a V. A kupodivu, všechny data byly správně zkonvertovány do formátu enginu QN/QD.

Nicméně to, že daný level je stoprocentně skonvertován do enginu QD ještě nezaručuje jeho správnou hratelnost v QD. Přes vše výše uvedené musím každý jeden level odehrát v původním Quadraxu a poté v enginu QD. Od Quadraxu V většinou následuje složitý postup vyladění levelu tak, aby tak, jak byl zamýšlen původně, fungoval i v enginu QD.

Quadrax Definitive by měl být takový můj Magnum opus. A proto se snažím každý level z původních Quadraxů poctivě otestovat a případně opravit chyby, které po těch mnoha letech vyplynuly na povrch. V quadraxu Definitive je nyní více jak 10% levelů úplně nových (jsou nahrazeny ty levely, které měly od hráčů špatné reference či levely opakující se - "opravné" kdy v dalších Quadraxech byly použity "nedokonalé" levely z předchozích dílů se snahou je opravit). Nicméně více jak 20% levelů (tj.každý pátý!) bylo z původních Quadraxů v QD opraveno - byly pokud možno odstraněny možnosti neplánovaných řešení. (Tedy, snad...)

Jak už bylo řečeno, levely jsou sice zkonvertovány, ale zbývá je dokončit tak, aby byly hratelné (či opravit) a pak hlavně vytvořit jejich novou grafickou podobu. A to pro každý jeden level trvá v průměru 3 dny. Takže zbývajících 360 levelů (QV - QVIII) bude trvat dokončit ještě cca 3 roky. A to v případě, že si nevezmu žádnou dovolenou... Uff...

Jak si jistě každý všiml, epizoda 5 je opravdu temná - a teď to myslím z té grafické stránky. Proto jistě každého potěší, že v epizodě 6 se z tmavého podpalubí, osvětlovaného sporadicky medúzami, vydáme do prosluněné Nevadské pouště. Co ovšem může hráče trochu vyděsit je to, jelikož je to venkovní prostor, že se zde opět střídá den a noc.

Ale než začnete obracet oči v sloup, je třeba říct, že jsem se poučil z kritických názorů na epizodu 1 a na rozdíl od ní má epizoda 6 zcela jinak nastaveny parametry. Noci jsou kratší jak v E1 a den je naopak o hodně delší. Především jsem ale zcela přepracoval parametry shaderů, takže i o půlnoci je level (především jeho popředí) dostatečně jasný a přehledný - což můžete vidět na následujícím screenshotu a porovnat ho s tím v galerii, který je naopak pořízen v pravé poledne. Navíc v poušti nečekejte žádné lijáky nebo bouřky, takže nehrozí z epizody 1 ne příliš oblíbená kombinace "půlnoční bouřka"... ;-)

Jak si mohli pozorní hráči všimnout, publikoval jsem screenshot z epizody v Titaniku. Z něj je jasné, že převážná část epizody se bude odehrávat v útrobách tohoto potopeného parníku.

Bohužel, přestože je Titanik velmi známý, množství dobových fotografií které by zachycovaly jeho strojní vybavení a podpalubí je vskutku mizivé. Například neexistuje slušná fotka parních strojů, které tuto loď poháněly. Jediná dostupná (a solidní) je z konstrukční haly, kde se parní stroje stavěly, a na ní je samotný stroj obestavěn lešením a navíc vyfocen v ne příliš použitelné perspektivě:

Nicméně, protože jsem v této epizodě chtěl mít - co se týče grafiky - co nejvíce autentických prvků, a protože jiná použitelná fotka parních strojů pro Titanik neexistuje, nezbylo mi, než se ponořit do retušování této jediné použitelné fotografie.

Takže jsem odstranil lešení a zbylé místa ručně dokreslil dle nejlepšího svědomí a vědomí tak, aby odpovídaly originální konstrukci. Také jsem pochopitelně opravil perspektivu, aby se výsledný grafický objekt dal použít jako doplňující prvek v levelu "Strojovna", kde jsou poté umístěny dva tyto parní stroje, tak jak byly umístěny na Titaniku - což můžete vidět na screenshotu z epizody ale i zde v deníku vývojáře, kde ukážu parní stroj Titaniku z čelního pohledu po veškerých retuších, které zabraly cca 2 dny:

No, a takto si hraji téměř s každým grafickým prvkem pro epizodu 5. Dá se tak říct, že co se týče strojního vybavení, (resp doprovodných grafických prvků v levelech) bude vše založeno na skutečnosti a veškeré vybavení bude odpovídat skutečnému Titaniku, tak jak s ním poprvé (a naposled) v roce 1912 vyplul.

Vzhledem k tomu, že epizodu 3 mám kompletně hotovou (a nyní už jen čekám na její otestování, napsání příběhu, přeložení příběhu a nápověd + korektury), začal jsem se naplno věnovat epizodě 4.

Podmořský svět je celkem výzva. Tentokráte jsem chtěl udělat grafiku tak, aby to skutečně vypadalo jako "pod vodou". Tedy nikoliv jako v QVI, kde sice taktéž byla podvodní epizoda v Atlantidě, ale prostě to jako pod vodou nevypadalo. Rozhodl jsem se tedy pro epizodu 4 napsat speciální shader, který nejen že snižuje kontrast a dává obrazu namodralý nádech, ale především přidává efekt "vlnění vody". Ladění tohoto vlnového shaderu mi zabralo celkem dost času, aby výsledný efekt nebyl příliš rušivý (z některých verzí se dělalo dokonce špatně od žaludku!) ale přesto patrný. Uvidím, co na současnou verzi řekne hlavní tester Nightmare, tedy až dotestuje epizodu 3, což bude ještě nějakou chvíli trvat.

Ale i po dokončení výše popsaného shaderu mi prostředí připadalo strašně "chudé". Zasloužil se o to i onen zmiňovaný snížený kontrast - vypadá to sice více reálně, ale na druhou stranu méně pestře. Celému prostředí chyběly nějaké prvky, které by jednotlivé levely "oživovaly". Bylo jasné co to do podmořského světa chce přidat - ryby! Ovšem kdybych tušil, jak moc si s tímto nápadem naběhnu, asi bych se na to vyprd už na začátku. ;-)

První pokusy se statickými sprity byly totiž naprosto katastrofální. Po několika pokusech mi bylo jasné, že ryby prostě MUSÍ být kompletně animované, aby nevypadaly jak mrtvé plastové modely. A protože jsem se rozhodl, že jednou z ryb (respektive paryb, aby mě zoologové neobvinili z neznalosti ;-)) musí být ikona podmořského nebezpečí - Carcharodon carcharias, aneb velký bílý žralok, tak tady jsem si naběhl už podruhé. Najít na webu kvalitní záběry, použitelné pro vytvoření animace pro QN bylo prostě nemožné. Rozhodl jsem se tedy jít na to tou nejsložitější cestou - vytvoření 3D modelu a jeho rozanimování.

Kdybych měl tvořit onen 3D model sám, epizody 4 byste se asi nedočkali. Naštěstí volně dostupných 3D modelů žraloka bílého je k dispozici celkem dost, takže po chvilce hledání se mi podařilo nalézt poměrně slušně vytvořený model a importovat ho do Blenderu:

To ovšem byla ta nejjednodušší část práce. To zásadní bylo daný 3D model "rozhýbat", tedy animovat jej. Nebudu zde popisovat celý můj týdenní boj s tím, naučit se v Blenderu pomocí animační kostry věrohodně rozpohybovat 3D model. Ač vypadá pohyb žraloka vcelku jednoduše, velmi brzy jsem zjistil, že zase tak jednoduchý ten pohyb celého parybího těla není. Moje první pokusy vypadaly, jako kdyby byl žralok postihnut celkovou obrnou, a o věrohodnosti jeho pohybu by musel pochybovat i ten, kdo nikdy neviděl film Čelisti. ;-)

V dalších a dalších dnech, které jsem strávil především sledováním videí na youtube a studováním anatomie rybího těla a žraločích pohybů jsem konečně dospěl k alespoň nějak kompromisně použitelnému výsledku. Není ani to zdaleka dokonalé, ale lépe to asi nezvládnu - na post animátora v Pixaru pro filmy typu Hledá se Nemo atp. by mě asi nevzali. ;-) Screenshot z tvorby animace 3D modelu pomocí jednoduché animační kostry naleznete na obrázku níže:

Poté, co jsem dokončil animaci, zbývalo už jen zvolit správné nasvícení. Tak, jako všechny animace od Quadraxu X výše, pro pohyb zleva doprava a naopak jsou použity dvě sady rozdílných animací s odpovídajícím nasvícením a ne pouhé zrcadlově otočené animace. Poté už jsem jen vyrenderoval finální animační sprity, sloučil je do skupinových bitmap a importoval je do enginu QN. Tam jsem ještě musel vytvořit algoritmy pro vertikální i horizontální pohyb spritů (což jsou vlastně jen modifikované sinusoidy) a hurá! Konečně se pod hladinou něco pohybovalo!

Trošku oříšek byl zvolit správné měřítko. Vzhledem k tomu, že ve světě Quadraxu nemůže být pro některé (hlavně malé) objekty použito odpovídající realistické měřítko a objekty musí být zvětšené, zde jsem narazil na opačný problém. Ve skutečné majestátní délce (tj. odpovídající cca 6m) zabíraly bitmapy všech dvě stě čtyřiceti framů animace (celkem 120 framů pro každý levý/pravý model) neúnosně velký prostor ve videopaměti. Po zmenšení velikosti o třetinu (tj. na cca 4m měřítkové délky) sice už bylo paměťově vše v pořádku, ale žralok prostě vypadal malý a ta tam byla jeho důstojnost a majestátnost. Se skřípěním zubů jsem tedy snížil snímkovou frekvenci animace žraloka z 30 fps na 15 fps. Tím jsem uspořil polovinu animačních spritů a tím i polovinu obsazení videopaměti pro tuto jednou konkrétní animaci. Je pravda, že 15 fps už je nedostačujících a výsledný pohyb může v některých okamžicích vypadat mírně trhaně, ale je to kompromis kvůli tomu, aby hra byla stále hratelná i na slabších strojích.

Samozřejmě, že mořská fauna nemůže být tvořena pouze žraloky - naopak, tito majestátní predátoři vodního světa jsou celkem vzácní (a to i co se týče zobrazení ve hře). Naštěstí, vyzbrojen znalostmi z animace žraloka, nedělalo mi už posléze větší problém v Blenderu udělat animace více druhů ryb. Ovšem zde jsem narazil na další problém - aby QN zůstal co se týče potřeby množství grafické paměti v rozumných mezích, musel jsem omezit počet jejich druhů, neboť každá jedna rybka má 60 animačních spritů a tomu odpovídající bitmapu která zabírá místo ve videopaměti. Nicméně i s pouhými pár rybkami je nyní prostředí podvodních levelů daleko živější, protože "pořáde se tam něco hýbe". ;-) Takže doufám, že prostředí nebude pro hráče až tak nudné, jako by to bylo bez podmořského života.

A na závěr tu mám jako bonus vyrenderovaný obrázek žraloka. Takto velkého a v této perspektivě ho ve hře totiž nikdy neuvidíte - tam je vidět víceméně jen z profilu a plavající zleva doprava či naopak a pochopitelně v daleko menším měřítku.

Při hledání hudby pro epizodu 3 mě napadla zajímavá myšlenka. Co takhle vytvořit epizodě 3 mírný nostalgický nádech a použít jako začátek hudebního mixu skladbu z ledových levelů původního Quadraxu 1?

Nápad jednoduchý, provedení už nikoliv. Technická kvalita originální hudby (resp. samplů) pro ledové levely z Q1 je poplatná době vzniku hry - tedy roku 1996. V dnešní době by už ovšem málokdo zkousl šumící 8 bitové samply a tak jsem přikročil ke kompletnímu remasteru skladby. V programu OpenMPT jsem extrahoval jednotlivé samply a nahradil je jejich 16 bitovou obdobou. Snažil jsem se najít co možná nejpodobnější hudební nástroje, aby zvuk nových samplů přesně odpovídal těm původním. Často jsem se tak nevyhnul ani značným úpravám nových saplů, či jejich nové tvorbě na syntezátoru. Nahrazení starých samplů novými (a jemná zvuková finalizace těch nových) tak trvalo několik dní.

Ale výsledek, myslím si, stojí za to. Hudba je k nerozeznání od originálu, nicméně díky 16bit samplům je zvuk daleko čistší, jasnější a má větší rozsah výšek i hloubek. Do partitury jsem pochopitelně nijak nesahal, takže skladba je stále složena pouze ze čtyř stop a pamětníkům tak dá vzpomenout na zážitky u prvního Quadraxu. ;-)

Anketa na fóru mě inspirovala, takže jakmile jsem začal pracovat na třetí epizodě, o jejím prostředí bylo rozhodnuto - budou to ledové jeskyně. A to také proto, že takovéto prostředí se doposud v žádném mém Quadraxu nevyskytlo. Byly tu sice zimní levely, ale pouze externí. Epizoda 3 se bude však blížit spíše původnímu pojetí těchto levelů v Quadraxu 1 a půjde o uzavřené "indoor" levely v jeskyních.

V rámci tvorby vizuální stránky jsem spustil DOSBox a odehrál všechny ledové levely v původním Quadraxu, abych nasál jejich atmosféru a pokusil se tak udělat levely obdobné. Zároveň jsem si vždy udělal z každého levelu screenshot, abych mohl porovnat barevnou paletu a použít ji k tvorbě vlastních levelů. Jak se mi to zatím daří můžete ostatně posoudit z návrhu prvního levelu pro epizodu 3 a zároveň to porovnat s jedním z levelů z původního Quadraxu:

Epizoda 3 - designový návrh levelu



Level z Quadraxu 1

Do vydání hry zbývají už jen necelé tři týdny. Proto mě při testování polilo horko když jsem zjistil, že ve struktuře statistik uživatelských dat levelu mám dvě proměnné, které uchovávají časový údaj v milisekundách, definovány pouze jako 32 bitové! Programátoři už asi začínají tušit, odkud vítr vane. Pro ty ostatní to zde vysvětlím. 32 bitová proměnná může nabývat celočíselného kladného rozsahu 0 - 4294967295. Takže maximální hodnota, kterou může tato proměnná obsahovat, je právě těch 4294967295 milisekund. Což je cca 50 dnů. Takže pokud by někdo řešil jeden level déle jak právě těch 50 dnů čistého času, došlo by k "přetečení" této hodnoty a začala by se počítat znovu od nuly!

Takže co teď s tím? Rozvrtávat a předělávat celou strukturu uživatelských dat nepřipadlo takto krátce před vydáním hry v úvahu. Naštěstí jsem ale měl ve struktuře definovánu jednu "rezervní" 32 bitovou proměnnou, která zatím nebyla použita. Takže jsem se ji rozhodl použít pro rozšíření rozsahu oněch dvou časových 32bit hodnot tak, že tuto rezervovanou proměnnou "rozpůlím" a každou z těchto půlek přidám k těm dvěma 32bit proměnným. U obou časových proměnných tak dostanu k dispozici 48 bitový rozsah, což už je IMHO dostatečné, neboť 48 bitová proměnná má maximální celočíselnou kladnou hodnotu 281474976710655. Toto číslo v milisekundách reprezentuje cca 8925 let. Samozřejmě, že tím nebylo zabráněno přetečení a počítání znovu od nuly. Ale pouze v případě, že někdo bude řešit jeden level déle jak cca devět tisíciletí ;-) Což, jaksi, nepředpokládám... ;-)

Možná někoho napadne, jak je to se zobrazováním celkového času stráveného ve hře, který se taktéž měří v milisekundách, neboť tato hodnota může dosáhnout více jak padesáti dnů velmi lehce. Tady je třeba říct, že toto je bez problémů, neboť už od dob prvních Quadraxů, které toto počítaly, jsem tyto sumární časové proměnné definoval vždy jako 64 bitové, a k chybě (přetečení) by došlo pouze v případě, že byste Quadrax hráli déle než cca 585 miliónů let... ;-)

Tak jsem pořád dumal jak ještě zjednodušit publikaci nejlepších výsledků pro hráče a výsledek dumání byl jasný - nejjednodušší a nejrychlejší řešení bude, pokud si budou moci hráči svoje rekordy nahrávat na tyto stránky sami! Zasedl jsem tedy k počítači, oprášil znalosti PHP a vytvořil formulář a zpracující skript, který dovede nahrávat do databáze na webu aktuální výsledky daného hráče a jeho uživatelského účtu ze hry!

Na stránce rekordů je nyní vpravo nahoře (v nadpisu) tlačítko Zaslat uživatelská data. Kliknutím na něj se dostanete na formulář pro odeslání zpracovaného souboru dat (to je ten soubor, který vytvoříte pomocí programu QN userfiles packer, což je obdoba stejného programu co byl v QX a má i úplně stejné ovládání). Nicméně první zaslání tohoto souboru musíte provést mě na můj email, stejně jako to bylo u Quadraxu X - na rozdíl od QX ale stačí, když tento soubor pošlete jen jednou. Já vám obratem v databázi vytvořím účet, vygeneruji heslo a toto heslo vám zašlu mailem zpět. Heslo potom slouží k vašemu vlastnímu nahrávání dat! Takže jakmile obdržíte mailem heslo, můžete si aktualizovat data nejlepších výsledků zcela sami! Postup je jednoduchý a vždy stejný:

• Pomocí programu QN userfiles packer vytvoříte vždy aktuální soubor uživatelských dat a uložíte si jej na disk.
• Dále už pokračujete podle kroků na stránce formuláře pro zasílání dat, kde v kroku 2 vyberete právě ten soubor, který jste před chvílí vytvořili.

Je to skutečně jednoduché. Nezapomeňte mi však v prvním mailu, ve kterém budete zasílat ten první soubor uživatelských dat, napsat pod jakým nickem chcete být v tabulce uvedeni a také jmého vašeho účtu ve hře, abych vše mohl zadat do databáze! Pokud nejste starý matador, který se účastnil klání i v Quadraxu X, sdělte mi v mailu také vaši národnost a pohlaví, pokud chcete mít tyto údaje v tabulce rekordů uvedeny u svého nicku.

Poznámka pro hráče ze zahraničí - pokud se vám při pokusu o odeslání souboru zobrazí stránka, že přístup byl zamítnut, jedná se o blokaci vašeho IP ze strany provozovatele serveru (webzdarma). S tím nemohu bohužel vůbec nic dělat. V takovém případě mi tedy posílejte soubory vytvořené pomocí programu QN userfiles packer mailem, stejně jako u QX. Nahrání dat pak provedu manuálně já sám.

Tak nakonec mi to nedalo. Tak dlouho jsem si hrál s pixel shadery, až jsem se rozhodl, že celý renderovací engine Quadraxu Neverending předělám pro jejich použití. A co to vlastně znamená? To znamená, že denní cyklus (střídání dne a noci, jak jsem to nakousl v příspěvku z 24.6.2016) v QN nakonec přece jen bude!

Při hře se tedy bude cyklicky střídat den a noc, včetně naprosto plynulých přechodů (stmívání/svítání). Trvání jednoho cyklu (tj. imaginárních 24 hodin ve hře) jsem nakonec, po spolupráci a konzultací s testerem, zvolil na dobu cca třiceti minut reálného času. To znamená, že pokud budete level hrát půl hodiny, dojde k celému vystřídání všech denních dob. Kratší cyklus by už působil rušivě, delší naopak nezáživně. Nutno podotknout, že tester (Nightmare) už má v tomto režimu odehraných spoustu hodin a tento třicetiminutový denní cyklus hodnotí jako optimální. Hráči se však nemusí obávat toho, že by půlku této doby strávili v tmavém "nočním režimu". Doba trvání dne je totiž mnohem delší, jak doba trvání noci! Plný slunečný den trvá cca 65% celého cyklu, stmívání a svítání zabere 25% a na noc tak zbývá pouze 10%, tzn., že plnohodnotné noční prostředí tvá pouhé 3 minuty reálného času. Opět dlužno podotknout, že tyto hodnoty byly zvoleny a odladěny po dlouhodobém testování. Pro ty, jenž na QN netrpělivě čekají je dobrou zprávou i to, že implementace této vymoženosti nijak neposune dobu vydání hry, neboť jsem tento systém do hry přidal přímo v průběhu dosavadního testování epizody 1.

Tímto to ovšem nekončí! Jelikož se shadery jdou dělat skutečně psí kusy, rozhodl jsem se do QN zařadit ještě další věc, která existovala už v QVIII, přesto ale v QX nebyla použita. Ti, co obě hry dohráli už určitě tuší. A pokud tuší "počasí", tak tuší správně! V epizodě 1 QN si tedy budete moci užít jak slunečných, tak zamračených či deštivých dní. Pochopitelně v rozumné míře! Nepochybuji, že nikdo nějak zvlášť nemiluje propršený den a tak je v QN poměr hezkého/špatného počasí zhruba 6/1 (tj. prší maximálně jeden den v týdnu). A proč mluvím o počasí (což je spíše částicový efekt) ve spojitosti se shadery? Protože právě shadery umožňují to, aby krásný slunečný den přešel plynule v pošmournou přeháňku či zamračenou bouřku a zpět. Efekty počasí tak dostanou nové grády a opět se přiblíží realistickému zobrazení. Třešničkou na dortu pak už zůstávají různé další efekty související s počasím či denní dobou (a nebo na vzájemné kombinaci obého) jako jsou občasná duha po dešti, sluneční paprsky při svítání atd, atd.

Hráče, kteří vlastní ne zrovna nejnovější počítač teď určitě napadlo něco takovéhoto: "No, to je všechno pěkné, střídání dne/noci, počasí, efekty, ale zvládne toto vše můj starý PC?" Nebudu tady nic zastírat, QN si už na počítačích, které patří spíše do muzea informačních technologií než na stůl, nezahrajete. Ale upřímně - máme tady druhou dekádu jednadvacátého století. Pokud někdo používá počítač ze století minulého, nesmí se na mě zlobit za to, že QN už na takovýchto prehistorických (byť archeologicky jistě cenných) vykopávkách nepoběží. Na druhou stranu, ve hře použité pixel shadery 2.0 zvládne v pohodě i deset let stará grafická karta a systém s Windows XP a DirectX 9.0c. Takže zase tak "strašné" to s hardwarovými nároky hry není.

Matematické okénko ke hře Xonix, kterou jsem publikoval před pár dny. Tato hra je, z matematického hlediska, poměrně dost zajímavá. Troufám si říct, že nikdo na světě nemůže odehrát stejnou hru, jako kdokoliv jiný. Vezměme si na pomoc a vysvětlení už zmiňovanou matematiku a také statistiku: Počet možných situací, ve kterých může začínat level 1 je přesně 7 792 800. (487 050 možných xy souřadnic kuličky * 4 možné prvotní směry pohybu kuličky * 4 možné prvotní směry pohybu černého čtverečku). Jakmile se do hry zapojí i hráč, je počet možných dalších různých situací na obrazovce z praktického hlediska nekonečný. (Je to tak velké číslo, že nemá žádný smysl.) U levelu 2 je už počet možných startovních pozic v levelu 15 181 932 960 000 - ano, přes patnáct biliónů. A level 3 (tedy s pouhými třemi kuličkami) může začínat celkem 29 577 441 792 672 000 000 různými startovními pozicemi!

Jistě pochopíte, že u dalších levelů je zbytečné uvádět přesná čísla (např. u levelu 10 je to cca 3,15061e+63 startovních možností, tj. číslo které má 64 číslic!) Ze statistického hlediska je tedy nemožné, aby byly dvě hry, byť jen u jednoho levelu, stejné. Samozřejmě, znalci můžou namítnout, že generátor náhodných čísel v PC má k opravdovému generátoru náhodných čísel poměrně daleko. Ale přesto je statisticky jisté, že nikdy nikdo nebude hrát ten samý level, jako kdokoliv jiný nebo i on sám.

Další zajímavostí je pohyb kuliček samotných. Vzhledem k tomu, že se pohybují v konečné množině bodů přesně úhlopříčně, je každý pohyb kuličky, ať už v jakkoliv složitém ohraničeném prostoru, vždy konečný. A to buďto cyklicky a nebo "kyvadlově". (Kyvadlově je to v případě, že se v určitém okamžiku kulička odrazí přesně na druhou stranu svého původního pohybu - tedy při přesném nárazu do konvexního nebo konkávního rohu). U pohybu v malých a relativně jednoduchých plochách (čtvercových či obdélníkových) je to občas dobře pozorovatelné i pouhým okem.

A takto bych mohl pokračovat ještě hodně dlouho. Nicméně nebudu tady hráče unavovat dalšími matematickými analýzami. Myslím, že to, co bylo uvedeno, prozatím stačí... ;-)

Poslední týden jsem si trochu hrál s Pixel shadery a nápadem jejich případné implementace do QN. Umožňovalo by to poměrně hodně zajímavé věci, z nichž asi nejdůležitější by byla možnost dynamické změny denní doby v externích lokacích. Provedl jsem několik testů, které dopadly, z hlediska vizuálních dojmů, nad očekávání dobře. Na následujících obrázcích uvidíte změny pozadí v různých denních dobách (ve hře by pochopitelně ke změně obrazu docházelo naprosto plynule a neznatelně):

Ve dne



Večer/svítání



V noci

Samozřejmě, že dle aktuální denní doby by se barevně měnil celý level a ne jen pozadí - takže za dne by vypadal stejně jako je na screenshotu v galerii a v noci by vypadal obdobně, jako epizoda 3 v QX.

* - Viz 26.7.2016

Mám trochu obavu, že deník vývojáře bude na těchto stránkách spíše stručnější. O čem taky psát, že? Engine pro QN je, až na pár změn a vylepšení, převzatý z QX, kvalita grafiky jednotlivých levelů záleží především na "nakreslení" každého levelu v externím grafickém editoru atp. Takže si tu probereme alespoň tu nejvýznačnější změnu a tou je dynamické nahrávání textur a animací.

O co konkrétně jde a jak to funguje? V Quadraxu X se veškeré potřebné textury, animace ap. nahrávaly do paměti rovnou při startu hry. Jelikož se jednalo zhruba o 200MB grafických dat, nahrávání pár sekund trvalo. (To je i odpověď pro ty, kteří si myslí, že úvodní obrazovka "Loading" s procentuelním ukazatelem je jen grafickou ozdůbkou - není. ;-)) Nicméně po startu hry měla tato k dispozici kompletní grafiku i animace všech levelů, a tak spuštění každého levelu mohlo být poměrně snadné a engine se nemusel o nic starat, neboť veškeré potřebné textury a animace měl už nahrány v paměti.

V Quadraxu Neverending jsem na to však musel jít jinak. Vzhledem k tomu, že počet levelů a epizod je prakticky neomezený, nemohl jsem použít stejný přístup jako v QX, neboť by to, přidáváním dalších a dalších epizod a přidáváním dalších a dalších textur a animací vedlo k neustálému a neakceptovatelnému bobtnání paměťových nároků hry. Quadrax Neverending na to jde proto jinak. Při svém startu nahrává pouze nejnutnější grafiku - menu hry ap. Spuštění QN je tak bleskurychlé (zhruba 4x rychlejší jak u QX). Ovšem jak už každý tuší, když se někde čas ušetří, jinde zase musí přibýt - a tento čas přibývá při spuštění nového levelu, při němž si engine hry "zkontroluje" co vše je v daném levelu použito a nahraje tedy jen ty textury a animace, které jsou použity v daném levelu. Pokud jsou v paměti obsaženy i grafická data z levelu, který byl hrán předtím, engine tyto data prohlédne, nepotřebné zahodí a potřebné zanechá. Vysvětlím to podrobněji na animacích. Pokud se po čerstvém startu hry spustí nějaký level, kde je dejme tomu deset animací, engine těchto deset animací nahraje do grafické paměti při prvním spuštění levelu. Pokud bude hráč level hrát, tyto animace zůstávají stále v paměti a tak případný restart levelu či loading je stejně rychlý jako u QX. Pokud však hráč level dohraje (nebo z něj jednoduše odejde do menu) a spustí se level další, engine provede kontrolu a nahrání animací. Z předchozího levelu je stále v paměti uloženo oněch deset animací. Dejme tomu, že v novém levelu je animací patnáct, z čehož ale osm je stejného typu jako v předchozím levelu a sedm je jiných. Engine tedy v prvním kroku prohlédne co má vlastně už uloženo v paměti a těch osm, které byly použity i v předchozím levelu, ponechá. Dvě animace "zahodí" (uvolní z paměti). A donahraje zbývajících sedm nových animací. Jak jste si mohli všimnout, přestože v novém levelu je o třetinu více animací než v tom předchozím, engine při jeho startu bude nahrávat jen těch sedm "nových" a spuštění nového levelu bude tedy rychlejší, než prvotní spuštění toho prvního. A stejně to funguje při spouštění dalších a dalších levelů. V grafické paměti tak zůstávají pouze a jen ty data, která jsou potřebná pro ten který konkrétní level. Díky tomuto dynamickému systému nahrávání dat tak může mít QN jen nepatrně větší grafické paměťové nároky jako QX! (O tom, proč má QN větší paměťové nároky než QX, když má tak úžasnou správu grafické paměti, si povíme zase někdy příště.)

Ale nebojte se, že by nahrávání potřebných dat nějak výrazněji zpomalovalo start nového levelu. Jak už bylo řečeno v odstavci výše, nahrávají se jenom ty data, která jsou pro level skutečně potřeba a to ještě jen v tom případě, pokud už nejsou v paměti. Prodleva při spuštění nového levelu v QN je tak zhruba jen o 100 - 500 milisekund (čili maximálně o půl sekundy) delší než při spouštění levelu u QX. Troufnu si říct, že kdybych tady o tom nepsal, tak by si toho nikdo z hráčů ani nevšimnul. ;-)

© 2000-2024