Samozřejmě nejde ještě zdaleka o finální variantu, zdi budou ručně "dotesány", přibude světlo od loučí a ohňů (v tmavých chodbách, což je prosvětlí) atd. Ale myslím, že je jasně vidět, že rozdíl mezi nestínovanou a stínovanou
verzí je značný. Takže toto je jeden z nejzákladnějších tipů - nebojte se stínování!
9.11.2015
Dokončil jsem veškeré kontroly a testování kódu a definitivně uzavřel produkční verzi hry. Tím také končí tento malý seriál z vývoje Quadraxu X. Vývoj hry trval celkem dva roky - byla to fuška, ale zábavná!
Nyní už je pouze na vás - na hráčích, abyste posoudili nakolik se mi dílo podařilo a nakolik bude tento Quadrax důstojným nástupcem svých předchůdců.
30.9.2015
Do enginu hry jsem přidal možnost ovládat pohyb postaviček nejen pomocí kurzorových kláves, ale také pomocí kláves W, A, S, D. Klávesu pro zobrazení audio panelu v levelu jsem proto přestěhoval z A na U.
29.9.2015
Jak už bylo uvedeno v novinkách zbývá pouhých cca 10 levelů na dotestování a hra bude prakticky hotová. Stále se však při testování odhalují drobné bugy v chování některých objektů. Většinou jsou objeveny
při nestandardních nebo velice raritních pokusech o manipulaci s objekty, ale občas se nějaká chyba projeví i při situacích víceméně standardních. Těch chyb už není mnoho a nejsou nijak kritické,
přesto usilovně pracuji na co nejlepším odladění enginu hry. Proto i po dotestování všech levelů bude ještě chvíli probíhat testování enginu aby bylo zaručeno, že hra bude co možná nejvíc bezproblémová a nebudou
ji kazit hloupé chyby. Přesto všechno napsat program o cca třiceti tisících řádcích není možné bez jediné chyby (programátoři vědí) a tak bych byl rád, aby všichni hráči byli shovívaví a v případě, že na nějakou
evidentní chybu přece jen narazí, tak mi dali vědět. Přece jen jde o naprosto nový engine, který nemá z předchozími Quadraxy vůbec nic společného...
15.8.2015
Keyboard ghosting, aneb problémy s klávesnicí.
Vzhledem k tomu, že jsem musel na vývojovém PC obměnit svoji cca dvacet let starou klávesnici za novou, dlouho jsem vybíral vhodný typ. Bohužel jsem si neuvědomil, že ideální kancelářská klávesnice (vhodná pro programování)
se nerovná ideální herní klávesnice, a tak jsem se při testování Quadraxu poprvé setkal s nepříjemným jevem, zvaným keyboard ghosting. O co jde? Asi nejlépe vysvětleno je to na následující stránce:
http://www.microsoft.com/appliedsciences/antighostingexplained.mspx (anglicky). Pro ty, co nevládnou angličtinou, se pokusím o zjednodušený
výklad: Jde o to, že signály kláves (jejich stisknutí) jsou snímány v určité matici (což je způsob, jakým jsou jednotlivé klávesy vzájemně "zadrátovány" - tj. elektricky propojeny). A v případě stisknutí více jak dvou kláves současně závisí na typu a tvaru této matice, jestli budou všechny tři klávesy správně detekovány jako stisknuté,
či jestli bude stisk třetí klávesy ignorován. Toto je pouze a jen hardwarový problém konkrétní matice dané klávesnice a nedá se NIJAK odstranit! No a u své nové klávesnice jsem zjistil, že při stisknutí a držení kurzorových šipek
doleva + nahoru už klávesnice neregistruje stisknutí mezerníku - což způsobuje např. to, že když postavička vylézá doleva nahoru a má ve své cestě páčku, nedokáže ji přepnout "za chůze" pomocí mezerníku, pokud jsou trvale drženy ony kurzorové šipky.
Znovu opakuji, a zdůrazňuji, že keyboard ghosting je hardwarová "chyba" té které konkrétní klávesnice - způsobu elektrického propojení jednotlivých kláves - a absolutně nezáleží na operačním systému či počítači!!! (A už vůbec ne na programu.)
Doporučuji si vyzkoušet, jakým typem ghostingu trpí právě vaše klávesnice - stačí k tomu jakýkoliv program na testování klávesnice, například postačí i trial verze PassMark KeyboardTest
(http://www.passmark.com/products/keytest.htm) - tímto programem můžete snadno zjistit, jaké kombinace tří kláves vaše klávesnice "neumí".
Dokonce i na výše zmiňované stránce microsoftu (http://www.microsoft.com/appliedsciences/antighostingexplained.mspx)
je miniaplikace, (hned pod nadpisem článku) která umožňuje testovat klávesnici. Nejspíš zjistíte, že kombinaci šipka nahoru + šipka vlevo + mezerník (nebo šipka dolů + šipka vpravo + mezerník) vaše klávesnice taktéž neumí... :-/
Je nějaké řešení? Samozřejmě - výměna klávesnice za takovou, která má takzvaný Anti-ghosting; většinou se jedná o specializované herní klávesnice, které umí registrovat větší počet kláves stisknutých současně (od šesti až v extrému po více jak dvacet kláves).
A nebo použít nějakou hodně starou klávesnici (která ještě nemá windows klávesy), protože tyto staré klávesnice paradoxně na ghosting trpí daleko méně jak ty "moderní".
Takže pokud se ve hře setkáte s podobným problémem (nereagování nějaké třetí klávesy při stisknutí a držení nějakých dvou předchozích), uvědomte si, že to NENÍ chyba hry, ale jedná se o keyboard ghosting vaší konkrétní klávesnice
a jediná cesta jak se ho zbavit je použít klávesnici která má Anti-ghosting, nebo takovou, která má ghosting jinak rozložený (závisí na matici snímání kláves).
2.7.2015
Jak je všem jistě známo, v džungli žije hodně hmyzu. Je tak žádoucí, aby i po tropických levelech v Quadraxu občas něco lezlo nebo létalo. Udělat ale animaci nějakých brouků není jen tak. Ono sesynchronizovat šest nohou
dá už něco práce. Naštěstí se mi na internetu podařilo najít tuto poměrně pěknou animaci lezoucího broučka:
Nic mi tedy už nebránilo udělat z něj animaci pro Quadrax. Stačilo vymaskovat bílý podklad animace a samotného brouka pak patřičně dobarvit a nastínovat. Ovšem, stejně jak u netopýrů (popsáno níže) nastala otázka, jak velký by brouk
měl být, aby bylo vůbec něco vidět. Je snad každému jasné, že kdybych měl zachovat správný poměr velikosti brouka a postaviček, tak by to nemělo valný smysl. Ono lezoucího pixelu by si nikdo ani nevšiml.
Takže jsem provedl několik pokusů s různými velikostmi brouka (tak, aby třeba ještě byly vidět jeho nohy) a nakonec jsem se rozhodl pro tu správnou. Je sice pravda, že v reálném světě by takový brouk měřil cca padesát centimetrů,
;-) ale mluvíme tady o chrámech zkoušek, a tam se určitě může vyskytovat i enormě velký hmyz, ne? ;-)
28.6.2015
V závislosti na předchozím příspěvku pokračuje vylepšování grafiky - a nyní to není nic menšího jak dynamické osvětlování postav! O co se vlastně jedná? Postavičky v levelu, stejně jako všechny ostatní objekty,
jsou vykreslovány ze své zdrojové textury, kde jsou uloženy všechny jejich animace. Tato textura má ale svoji danou barevnost a jas, takže objekty v celém levelu jsou vždy stejně barevné/jasné, jak ve zdrojové textuře.
Ale u postaviček mi vadilo, že ať už se pohybují na přímém slunci či v nejtemnější chodbě podzemí, tak mají pořád stejný jas. (Zvláště v některých temných koutech chodeb postavičky doslova "zářily").
Dlouho jsem přemýšlel, jak tyto drobnou pihu na grafice odstranit - a nenapadlo mě nic jednoduššího, jak udělat kompletní dynamické osvětlení postavy v závislosti na světelných podmínkách místa jejího výskytu.
Takže nyní budou postavičky osvětlované světlem (a stínované stíny) přesně dle aktuálních světelných podmínek. Nebudu vás tady unavovat popisem řešení programátorské části - snad jen drobnost, že tato vymoženost je trochu náročnější
na výkon počítače, neboť jen samotný výpočet dynamického osvětlení tří postav každou sekundu provede cca 432000 (ano, skoro půl milionu) výpočetních operací, ale díky optimalizaci kódu by toto nemělo na současných procesorech
a grafikách dělat větší problém. A jak to vypadá v praxi? Nejlépe to ukážou následující obrázky. Na obrázku níže je jedna a ta samá postavička ve čtyřech pozicích a je vždy dynamicky osvětlena scénou:
Ve výřezu levelu výše možná není vše úplně patrné, tak ještě obrázek rozdílu jasu mezi postavičkou zcela vlevo a zcela vpravo:
Takže nyní už budou postavy osvětlené vždy tak, jak to odpovídá světelným podmínkám. Nutno ovšem podotknout, že se vlastně nejedná o pravé dynamické osvětlování (plně 3D) ale je použita pomocná "shadows map" vytvořená
specificky pro každý jeden level. Naštěstí tyto mapy mají minimální velikost (pro všechny levely komplet je to méně jak 1MB) a tak nijak kriticky nezvětšují množství grafických dat hry. Takže to je k dynamickému
osvětlování postav asi tak vše, pokud máte nějaké dotazy, ptejte se na fóru.
30.4.2015
Jak už jsem napsal v novinkách, grafika je kompletně "hotová". Ale při procházení všech levelů a hodnocení jejich grafických kvalit jsem občas nebyl spokojen se svojí dřívější prací a zároveň mě napadaly různé další
metody a postupy, jak levely graficky ještě více vylepšit a dotvořit. Takže jsem se rozhodl některé tyto nápady realizovat a začal jsem tedy znovu s epizodou 1.
Co se mi nelíbilo, tak že kvádry zdí jsou sice pěkné, občas i různě částečně rozbořené, ale stále se mi celá scéna (i přes různé stínování)) zdála taková "plochá". Rozhodl jsem se tedy, že vyzkouším, jak by vypadalo
vyrobit drobné stínování různých kvádrů zdi tak, aby to vypadalo, že každý kámen je mírně v jiné hloubce, či z pohledu roviny obrazovky nakřivo atp. Principielně velmi jednoduchým přidáním drobných stínů na hrany některých
kvádrů jsem docílil daleko lepší plastičnosti scény. Výsledek tohoto malého pokusu se mi natolik líbil, že jsem se rozhodl takto upravit celou kapitolu 1 a 3.
Jak taková úprava vypadá v praxi můžete vidět na následujím výřezu z screenshotu z jednoho z levelů první epizody.
Po najetí kurzorem myši na obrázek se zobrazí přidané stínování, když myš z obrázku sundáte,
zobrazí se původní obrázek bez úprav. (Pozn: při prvním najetí myši na obrázek může chvilku trvat, než se ze serveru načte druhá varianta obrázku). Takto můžete, pohým posouváním myši přes obrázek, posoudit vzhled obou verzí:
Myslím si, že druhá verze je daleko lepší, protože když se toto provede (rozumně) v celém levelu, je tento daleko plastičtější a zdi se reálněji přibližují vzhledu tisíc let starých chrámů. No, takže teď už mě to čeká provést ve zbývajích
levelech (tam, kde to má smysl). A už mě pochopitelně napadla další spousta úprav a vylepšení v dalších epizodách, takže si teď dávám prakticky "druhé kolo" grafické práce, kdy projedu jednotlivé epizody a levely
dotvořím do dokonalejší podoby.
7.4.2015
Dnes tak trochu ukážu, jak se vytváří některé grafické objekty pro hru. Pro epizodu 8 jsem potřeboval nějaké středověké sochy a zříceniny. Na webu se sice dá najít spousta různých obrázků, ale jejich použitelnost pro Quadrax je mizivá.
Minimálně bez pořádné úpravy, kterou si tady teď popíšeme. Dejme tomu, že máme nějaký obrázek zříceniny, jako je třeba tento:
Při prvním pohledu se takovýto obrázek pro použití naprosto nehodí. Slabý kontrast zdiva, naprosto nevhodné nasvícení (zezadu), špatná perspektiva. Ale dosti pochybování, dáme se do práce.
Jako první je třeba opravit perspektivu - to se provede snadno, deformačními nástroji. Pak následuje vyříznutí samotné budovy z pozadí, sesazení perpesktivně nesouhlasných částí (rozřezáním obrázku na několik částí a zpětným
složením s odpovídajícími posuny). Poté je třeba se rozhodnout, jak bude obrázek orientován, já jsem se, vzhledem k umístění zříceniny v pravé horní části levelu rozhodl pro zrcadlové otočení. Pak ještě zvýšit kontrast
(a snížit saturaci) aby vyniklo zdivo.
Další krok ja ta nejsložitější a časově nejnáročnější část - vyrobit "falešné" stínování objektu tak, aby odpovídalo jeho umístění v levelu. Pomocí různých výběrových nástrojů
a pomocí změny jasu a kontrastu se jednotlivé drobné části obrázku (rámy oken, sloupy, střechy věží atp.) zatmaví či zesvětlí tak, aby to +- odpovídalo úhlům paprsků definujícím osvětlení v daném levelu. Toto je opravdu piplačka
a na výše uvedeném obrázku mě zabrala skoro tři hodiny. No a jako poslední už zbývá jen dodělat celkové stínování zdí, opravit různé pixelové nesrovnalosti a doladit barevné tónování dle levelu.
A po této, celkem cca čtyřhodinové práci pak máme k dispozici objekt, který už se dá použít jako designové zpestření levelu. Nutno říct, že různých takovýchto objektů (samozřejmě ne vždy tak velkých) je ve hře stovky
a s každým muselo být více či méně provedeno to, co je popsáno u této budovy. Jak potom vypadá výsledek v levelu se můžete podívat na výřezu ze screenshotu levelu zde:
29.3.2015
Dost jsem se teď natrápil se základní grafikou pro epizodu 9. Ne a ne nalézt nějaký vhodný obrázek, který by byl použitelný jako pozadí pro jeskyně uvnitř činného vulkánu. Po několika týdnech jsem hledání vzdal a rozhodl se,
že použiji podklad pro epizodu 2 (podzemní jeskyně chrámů) a patřičně ho upravím. Což se i stalo, jak budete už brzy moci vidět v galerii. Nicméně jen samotné barevné úpravy mi nestačily. Chtěl jsem, aby místo jezera
vody na dně jeskyně bylo jezero žhavé lávy. Vyklíčoval jsem tedy vodu a vyrobil texturu lávy. S výsledkem jsem však nebyl pranic spokojený, protože statická "láva" prostě vypadala divně.
Rozhodl jsem se tedy, že lávu na dně jeskyně udělám animovanou. Naštěstí jsem na YouTube našel celkem dost návodů, jak na to. V trial verzi Adobe After Efect (mimochodem další z programů, které jsem se musel
alespoň základně naučit ovládat) jsem udělal animovanou texturu lávy. Ale narazil jsem na další problém. I po lichoběžníkovém perspektivním zobrazení textury byla tato prostě "plochá" a nevypadalo to dobře.
Na řadu tedy přišlo zúročit moje, zatím krátké, zkušenosti s Blenderem a celou animaci udělat ve 3D. V AAE jsem cyklickou animaci textury 2048x2048x30Frames vyexportoval jako bezztrátovou videosekvenci. V Blenderu jsem vytvořil
obyčejný čtvercový plane, a pomocí subdivision jej rozdělil na cca 16641 vertexů. Jako texturu jsem pak použil ono vyexportované video z AAE. Pomocí modifikátoru displace jsem pak docílil (po nastavení správných hodnot) plastičnost
povrchu lávy v závislosti na její "teplotě". Poté už stačilo nastavit kameru do správné pozice (aby měl povrch lávy správnou perspektivu, odpovídající původnímu jezeru v jeskyni) a vyrenderovat finální sekvenci třiceti obrázků animace.
Ale to nebyl všem problémům konec. Přece jen, 30 snímků je zatraceně málo. (Více jich být nemohlo, kvůli objemnosti výsledné textury animace). Pohyb lávy byl viditelně trhaný, a když jsem zvýšil framerate,
tak byl zase nepřirozeně rychlý. Potřeboval jsem aby byl pohyb povrchu lávy pomalý, klidný a plynulý. Prostudoval jsem na YT několik desítek videí se záznamy skutečného magmatu a lávy, abych byl schopen alespoň
základně napodobit lávovou (spíše magmatickou) řeku. Pomohl jsem si tedy starým dobrým trikem alphablendingu jednotlivých snímků. Přechod z každého jednoho snímku animace na druhý není "skokový",
ale je enginem hry rozložen do 51 snímků plynulého přechodu z jednoho frame na druhý (v kroku po 16ti milisekundách). Získal jsem tím jakoby 1530 snímků celé animace při zachování 60 FPS!
Výsledek předčil mé očekávání a konečně jsem byl spokojený.
Takže až se dostanete do poslední epizody QX a uvidíte na dně jeskyně líně se převalovat lávovou řeku, budete mít alespoň základní představu, jak náročné bylo takto jednoduchou animaci vytvořit. ;-)
9.2.2015
Jak už bylo řečeno níže, stále pracuji na animacích a seznamuji se s Blenderem (neplést s Benderem z Futuramy! ;-)). Vzhledem k tomu, že jsem se už něco málo (snad) i naučil, napadlo mě, že by nebylo od věci zkusit vytvořit pro hru
kraťounké animované logo Alfaline, jako intro na začátek. No, a tak jsem se pustil do práce. Ovšem to jsem si ale dal! Týden jsem potil krev a proklínal se za ten nápad, ale nakonec se zadařilo a dílo bylo hotovo. Zbývalo
jen vyrenderovat finální sekvenci full HD snímků. A tady jsem poznal, že můj vývojový PC je už opravdu zastaralý, i když jsem za něj před pěti lety vysolil hříšné peníze. Výsledné renderování celkem primitivního 12-ti sekundového
"filmečku" o pouhých 360-ti snímcích trvalo cca 48 hodin! To je pouhých 7,5 snímku za hodinu! Prostě to bylo pooomaaalééé. Ale co už. Po vyrenderování filmu ještě přišlo na řadu jeho ozvučení. Nezdá se to, ale také to není nic
jednoduchého (viz níže). Až bylo vše hotovo, tak už zbývalo jen rozhodnout, jak výsledné "video" v kvalitě 1080p (full HD) zobrazit ve hře. Prozkoumal jsem knihovny všech standardních i nestandardních video kodeků, ale žádný
z nich mi nevyhovoval, ať už z důvodů velikosti, nestability, či složité implementace. Po mnoha a mnoha hodinách marného pátrání jsem se nakonec (jako už mnohokrát) rozhodl, že si naprogramuji vlastní, jednoduchý a rychlý
MJPEG zobrazovací modul přímo vestavěný do enginu hry. Jediné, co jsem použil "cizí" byla knihovna pro rychlou dekompresi JPEG dat za pomocí sad procesorových instrukcí MMX/SSE/SSE2 (kvůli rychlosti, při 30FPS v 1920x1080
je nekomprimovaný datový tok do videokarty cca 2Gb/sec!)
Vše se nakonec podařilo na výbornou. Video je pěkně plynulé i na poměrně zastaralých PC (běhá svižně i na mém osm let starém notebooku) a paměťové nároky pro přehrávání jsou minimální (vystačí si s cca 10MB operační paměti).
Přesto se může stát, že na některých opravdu historických počítačích se bude sekat - nicméně na nich asi nepojede plynule ani samotná hra, která má oproti tomuto videu dvojnásobné FPS (60)! ;-)
A jak vypadá taková tvorba 3D animace? Nabízím zde k shlédnutí dva screenshoty z Blenderu, na prvním je tvorba wireframe modelu nápisu Alfaline (teda jen lfaline, neboť A je vytvořeno separátně zcela jinak) a na druhém je ukázka,
jak vypadá postrenderová kompozice obrazu včetně filtrů a efektů scén (celá animace je složena ze tří nezávislých scén, jak je na obrázku vidět). Po kliknutí na obrázky se tyto otevřou v novém okně v plné velikosti:
Na dalším obrázku pak můžete vidět seznam zvukových stop, které jsou použity pro tvorbu krátkého 12 sec. hudebního podkresu k výše uvedenému animovanému logu:
15.11.2014
Vzhledem k tomu, že statická grafika pro první tři epizody je prakticky hotová, začal jsem pracovat na animacích. Jako první jsem si zvolil animaci vlající vlajky (hinduistická vlajka). V Blenderu poměrně hračka,
hlavně díky spoustě návodů "jak na to" na internetu. Co ovšem hračka není, je udělat animaci cyklickou, tj. tak, aby poslední frame animace plynule navazoval na ten první. Po mnoha pokusech se ale nakonec podařilo a vlajka vypadá
skutečně hodně realisticky (také má tato animace přes sto! animačních políček).
Jako další přišlo na řadu oživení podzemí chrámů. Moc jsem chtěl, aby po úrovních poletovali čas od času netopýři. Ovšem nápad stvořit vlastního animovaného netopýra v Blenderu jsem zavrhl hned ze začátku.
Bylo by to strašně pracné, trvalo by to spoustu dní a navíc moje znalosti práce v Blenderu na takto složitý animační 3D model prozatím naprosto nestačí. Navíc když jsem shlédnul některé z již existujících 3D animací
letu netopýrů, byl jsem až překvapen, jak "strojově" se dané modely hýbou a to přesto, že animátoři, co je dělali, mají jistě daleko více zkušeností, jako já. Rozhodl jsem se tedy jít snažší cestou a to převedením
videa letu netopýra do jednotlivých animačních políček.
To jsem však ještě ale netušil, jak obtížné bude najít na webu kvalitní video, kde bude netopýr zachycen bočním pohledem v letu (ve zpomaleném záběru). No, nakonec se podařilo i to a našel jsem TOTO
video, které bylo optimální. Pak už jsem jen rozložil video na jednotlivé framy, vybral ty, které se hodí pro cyklickou animaci, izoloval netopýra od pozadí, provedl vlastní obarvení do realistických barev
a zmenšil na velikost odpovídajicí +- rozměrovým dispozicím měřítka hry. (Proč píšu +-? Protože kdybych měl netopýra zmenšit tak, aby vzhledem k rozměrům postav odpovídalo měřítko jeho velikosti, tak by daný netopýr měl tak 1x1 pixel
- což, jak každý uzná, je nesmysl.)
Animaci netopýra o rozměrech cca 30x30 pixelů jsem tedy měl hotovou. Ovšem následovalo vytvoření výpočtu pro simulaci letu jeho dráhy. Jak jistě každý ví, netopýři létají trochu jiným stylem jak ptáci a tak prostý rovný "přelet"
přes obrazovku (který u ptáků v oblacích vypadá přirozeně) tady nepřipadal v úvahu. Nakonec se mi podařilo vytvořit funkci, která se víceméně snaží simulovat nepravidelný let netopýra. Jde v podstatě o náhodně modulovanou sinusoidu
přičemž správnou volbou náhodných parametrů v určitých bodech křivky jsem dosáhl celkem realistického zobrazení trajektorie letu. Pro zájemce zde uvádím kompletní výpis části programu, která se stará o výpočet dráhy letu
netopýrů. Zdrojový kód si v novém okně zobrazíte kliknutím ZDE. V této ukázce nejsou pochopitelně obsaženy další procedury a funkce, které kód volá, jako například
inicializace úvodních parametrů pro proměnné letu atp. Navíc bude tato ukázka kódu srozumitelná pouze pro ty, kteří se o programování zajímají a pokud ještě rozumí i matematice, tak jim bude jasná i metodika výpočtu.
Pro ty ostatní musí holt stačit, že toto opravdu zajišťuje jakýž takýž dojem letu opravdových netopýrů. ;-)
To je pro dnešek vše, jdu se učit Blender, animací bude potřeba ještě mnoho...
12.11.2014
Jak už jsem napsal v novinkách, první tři epizody jsou takřka ve finálním stádiu grafické podoby. Ovšem to je dáno, mimo jiné, i množstvím použité doplňkové grafiky. Pro tyto
epizody je vytvořeno celkem přes tisíc(!!!) unikátních grafických prvků! Z toho cca prvních tři sta jsou stromy, rostliny, tráva, liány a jiná zeleň, zbytek pak jsou různé budovy, sochy, vázy, mísy, kostry, provazy, řetězy atp.
Ovšem to se bavíme pouze o statických grafických prvcích. Neméně důležité jsou animované prvky! A tady je hlavní zádrhel. Se statickou grafikou si poradit umím, ovšem animace, to je něco jiného. Protože už jsem se vzdal
naděje, že se najde nějaký schpný grafik který by chtěl na hře spolupracovat, rozhodl jsem se, že se pokusím o vlastní tvorbu pokročilejších animací. Za tímto účelem jsem si nainstaloval 3D animační probram Blender
(http://www.blender.org/)
a pomalu se jej začínám učit. Vzhledem ke složitosti jeho ovládání a k neskutečné komplexnosti celého tohoto programu ovšem bude vývoj animací trvat poměrně dlouho a nebude jich ani zdaleka tolik, kolik bych chtěl a kolik jsem
si při započetí tvorby QX představoval. Ono totiž, co někomu, kdo už v Blenderu nějaký ten pátek pracuje, trvá hodinku, tak mě trvá několik dní. Tvorba i jednoduchých animací tak zabere mnohem více času, než jak by to trvalo
s grafikem, který daný software plně ovládá a má s ním dlouholeté zkušenosti.
Nicméně, jak už jsem řekl, grafik není a tak to musím udělat já. Pro začátek jsem si vybral pár jednoduchých animací, ke kterým naštěstí existuje na webu i dost tutoriálů. Takže se můžete těšit na vlajky vlající ve větru, realističtější
tryskání vody z fontán a spoustu dalších drobných animací. Doufám, že se postupem času naučím Blender dostatečně na to, abych vytvořil i další a sofistikovanější animace pro ostatní epizody hry. Bude to sice chvíli trvat, ale rozhodl
jsem se, že nechci z grafické podoby hry příliš slevit a tak holt nezbývá nic jiného, jak čekat. Snad to bude stát za to!
29.9.2014
Ještě o jedné věci zde vůbec nepadla řeč, a tou je datová velikost celé hry. Bohužel, full HD rozlišení a to, že každý level má svůj vlastní "nakreslený" obrázek, si vybere svoji daň ve formě značného nabobtnání dat hry.
Provedl jsem několik základních jednoduchých výpočtů a interpolací a vyšlo mi, že celá hra bude mít cca 600 - 700 MB. Přičemž z toho 250 MB zabere jen hudba (nyní nově ve formátu Ogg Vorbis) a zbylých 350 - 450 MB
zabere grafika. (Samotná data úrovní a programovou část je možné téměř zanedbat, nezaberou více jak 10 MB) Je to především proto, že z důvodu maximální kvality grafiky nepoužívám pro jednotlivé textury JPEG kompresi, ale bezztrátovou PNG.
A protože grafický základ levelu je složený ze třech vrstev (pozadí, mezipozadí a popředí) tak přesto, že obrázek pozadí je společný vždy pro celou epizodu, tak obrázky mezipozadí a popředí (které jsou vždy pro daný level jedinečné)
mají dohromady cca 3 - 4 MB na level. K tomu je třeba připočíst textury animačních framů objektů, obrazovek ve hře ap. (asi 100 MB). Problémem je, že PNG je už sám o sobě komprimovaný formát (a OGG také),
a tak se při přípravě instalačního balíku už dále tyto data příliš nekomprimují. Z tohoto důvodu bude mít instalační soubor téměř stejnou velikost, jakou pak zabere celá hra na hard disku. A to je těch zmiňovaných 600 - 700 MB.
Samozřejmě, že při velikosti dnešních pevných disků nebo i flešek je tato velikost hry zanedbatelná. Jediný problém bych viděl při stahování celého instalačního balíku, kdy bude dost záležet na stabilitě serveru,
aby se celá instalace stáhla v pořádku a svižně. Jak už je, bohužel, známo, zrovna servery WZ, kde běží tyto stránky, však neoplývají ani stabilitou, ani rychlostí, takže instalaci asi navíc hodím na některé veřejné úložiště. ;-)
No, ale je asi teď trochu předčasné se bavit o instalaci, když skoro po roce od započetí prací hra není ani v polovině vývoje...
23.9.2014
Jak už bylo řečeno, Quadrax X bude obsahovat, stejně jako původní Quadrax 1, teleporty kamenů. Ale oproti svým původním vzorům budou mít jednu novou a zásadní funkci navíc - vstupní teleport kvádrů se bude dát vypnout/zapnout
pomocí páčky/plošinky. To umožní budovat ještě zajímavější a komplexnější levely, se zajímavou funkcionalitou. Každý, kdo dohrál QVIII si jistě pamatuje na úrověň nazvanou "Megatromatron". No a v desítce bude něco obdobného,
ale trošku šílenějšího. Právě vzhledem k možnosti zapínání a vypínání teleportů se dají dráhy pohybů kamenů větvit (či slučovat) a tak díky tomu může být level Megatromatron opravdu zajímavý. A ptotože si myslím, že
celkový princip celého "stroje" nepůjde odhalit ani v případě, že by člověk věděl co přesně má každá plošinka za funkci a jaké jsou vazby mezi jednotlivými objekty a teleporty, rozhodl jsem se zde zveřejnit celý finální návrh
této speciální úrovně, která v maximální míře ukazuje možnosti enginu QX, především mnoha jeho technických objektů:
Po kliknutí na obrázek se tento zobrazí v plné velikosti v novém okně
Hezké, ne? ;-) Samozřejmě, že žádný z hráčů nemusí být zděšen z obrovské spousty plošinek ap. protože 99,9% vazeb mezi objekty jen zajišťuje správnou a synchronizovanou činnost celého Megatromatronu tak,
aby veškeré objekty byly stále v pohybu a pořád se něco dělo. Pozornější si jistě všimnou, že úkolem hráče bude jen naplnit úvodní zásobník stroje kvádry (ve správné kombinaci) a po naplnění celého zásobníku se
celý Megatromatron automaticky spustí. To, jestli poběží správně a dlouho záleží už jen na tom, zda hráč zvolí správnou vstupní kombinaci kamenů (nápověda snad pomůže).
Ještě musím podotknout, že celý návrh a testování Megatromatronu trval cca 16 hodin čistého času, než všechny sekce pracovaly tak, jak mají a v žádné části levelu nedošlo k zaseknutí některého z mechanismů v důsledku
kolize kvádrů (např dva kvádry zaráz na pásu atp).
Věřím, že běžný hráč stráví v této úrovni daleko méně času, než jsem strávil já její tvorbou. (Opravdu to není tak složité, jak to vypadá). Jakmile odhalí funkční závislost vstupní sekce na chod celého stroje,
je už finální řešení pouze otázka času, tj. počkat si, až celý Megatromatron provede celý svůj pracovní cyklus. Samozřejmě, pokud se v průběhu práce stroj v nějaké své části "zasekne" či nedoběhne do konce,
byla to pouze špatně zvolena vstupní kombinace kvádrů... ;-)
14.9.2014
Tak konečně (už jsem se na to dlouho chystal) jsem do hry zabudoval i panel pro nastavení hlasitosti audia - respektive nastavení hlasitosti hudby a zvukových efektů.
Stejně jako u předchozích Quadraxů není tento panel přístupný přímo z menu, ale dá se vyvolat pouze při hraní levelu pomocí klávesy "A" (Jako Audio).
Ovšem na rozdíl od minulých dílů je už ovládání tohoto panelu plně "myšoidní" ;-), takže se oběma tahovými "potenciometry" hlasitosti šoupe nahoru a dolů pomocí myši.
Nastavená hlasitost se po uzavření panelu (buďto opětovným stiskem "A" nebo klávesou Escape) automaticky uloží a je platná pro celou hru (tedy i pro hlavní herní menu atp.)
Vzhledem k tomu, že ne všem můžou vyhovovat mnou vybrané mixy skladeb pro jednotlivé epizody, případně se jim při týdnech a měsících strávených v jedné epizodě "ohrají"
(i když QX bude obsahovat celkem přes 4 hodiny hudby a jedna smyčka pro epizodu má v průměru 25 minut),
tak je zde pochopitelně možnost stáhnout hlasitost hudby ve hře na minimum a pustit si v PC cokoliv svého, co bude hráči "sedět" ke hraní. ;-)
6.9.2014
Vzhledem k tomu, že jsem v minulé době pracoval na konstrukci a testování levelů pro epizodu 5, která se odehrává ve staré podzemní továrně a vzhledem k tomu, že do levelů jsem zapracoval některé nejzdařilejší
pointy z původního Quadraxu 1 (samozřejmě modifikované a přizpůsobené pro prostředí QX), pocítil jsem chybějící přepínač pro možnost přepínání pouze mezi dvěmi postavami. (Některé tyto části levelů jsou totiž jen pro dvě postavy,
zatímco třetí postava si sólo řeší svůj separátní díl levelu). Proto jsem ho do testovací verze naprogramoval a jevil se mi natolik užitečným, že bude i v ostré verzi hry. Oproti původnímu "switch mode" z předchozích Quadraxů
je však jeho ovládání zjednodušeno a ovládá se pouze jednou jedinou klávesou, "Q". Navíc po zkušenostech se zmatky v předchozích dílech je tento přepínač při startu nebo restartu levelu vždy defaultně vypnutý.
Ale pokud si jej zapnete a hru uložíte do saveslotu, tak při nahrání ze saveslotu bude tento přepíneč přesně v takovém stavu, jako byl ve hře v okamžiku uložení.
Dále jsem do hry implantoval obdobu "Shift Push mode" z předchozích Q, akorát tentokráte je tato funkcionalita vázána na klávesu Ctrl, které je lépe dostupná jak pro pravou, tak pro levou ruku. Tento mód, kdy postavy můžou tlačit
kvádr pouze se stisknutým (levým nebo pravým) Ctrl se zapíná a vypíná jednoduše, stisknutím levého i pravého Ctrl zároveň.
Samozřejmě, že jak "Ctrl push mode", tak i "Tab mode" jsou indikovány u animace srdce v pravém dolním rohu. Doufám, že tyto funkcionality přijdou k duhu zejména těm, kteří si na ně v předchozích Quadraxech zvykli a u desítky
by je pochopitelně postrádali.
1.9.2014
Všechny hlavní bugy jsou snad opraveny. Když už jsem byl v tom programování, tak jsem zároveň vylepšil a zpřesnil zapisování statistik levelů, aby data více odpovídaly reálnému hraní hry.
Hlavně jsem ale napsal jednoduchý prográmek, který umí potřebné soubory dat uživatelských účtů hry zabalit do jednoho zkomprimovaného souboru a ten uložit na disk.
Odpadne tak hledání souborů (v QX jsou data uživatelských účtů ve více souborech) v adresářích hry - jednoduše se spustí tento prográmek a ten dané soubory zpracuje (zkomprimuje do jednoho archívu, neboť
díky rozsáhlým statistickým datům levelů jsou soubory dost velké) a uživateli nabídne uložení tohoto komprimovaného archivu kamkoliv na disk
(defaultně je nabízena složka "Dokumenty" aktuálního uživatele Windows). Daný soubor pak už stačí přiložit klasicky jako přílohu mailu a je to. Jednoduché, na tři kliknutí myši.
Společně s ošetřením problémů s UAC tak bude zasílání dat daleko komfortnější než u předchozích Quadraxů. Tedy samozřejmě v případě, že hráč bude chtít svoje výsledky poslat a zapsat
do tabulky hráčů, že... ;-)
26.8.2014
Plný sil po dovolené, jal jsem se tvořit další a další levely. Začal jsem navrhovat i levely pro epizodu 5, která se odehrává ve staré továrně (technické levely, obdobně jako v QVIII).
Ale ouha! Jakmile jsem začal pořádně testovat různé interakce mezi objekty, začal na mě vyskakovat jeden bug za druhým, jako čertíci z krabičky. Bugy byly logického typu (tedy takové, že nevedly k pádu programu,
ale způsobovaly chybné chování některých objektů). Chyby se týkaly výbušných a magnetických kvádrů a jejich vzájemné interference. Vzhledem k tomu, že v předchozích Quadraxech nebyly tyto chyby zcela odstraněny, začal jsem "hon na logické chyby".
Abych trochu vysvětlil, o co se vlastně jedná, je třeba přejít k názorné ukázce. Dejme tomu, že máme dva výtahy těsně vedle sebe, které jsou vertikálně vzdálené jedno logické pole.
V obou těchto výtazích je výbušný (nebo magnetický) kvádr a výtahy zatím stojí. Teď nastane situace, že se oba výtahy ZÁROVEŇ rozjedou (např. sepnutím páčky/plošinky, která ovládá oba výtahy) - a to vzájemně opačným směrem tak, aby se minuly.
Na následujících dvou obrázcích je jasně vidět, jak to myslím. Na prvním jsou výtahy stojící a šipky ukazují jejich budoucí směr pohybu po jejich zapnutí, na druhém jsou výtahy přesně v půlce cesty jedním logickým polem (mřížkou).
(Pro lepší názornost je na obrázcích průsvitně zobrazen rastr logické mřížky.)
Je jasné, že oba výbušné kameny jsou sice přesně vedle sebe, ale výtahy nejsou zarovnány k logické mřížce. Samozřejmě, pokud by se jednalo jen o výbušné kvádry, nebylo by nic jednoduššího, než je nechat explodovat
v této pozici a výtahy by poté pokračovaly svou cestu dál prázdné. Diametrálně odlišná situace však nastává v případě kvádrů magnetických. Pokud by se zmagnetovaly přesně v okamžiku, jaký je zobrazen
na druhém obrázku, výtahy by zůstaly "zaseknuté" mimo logickou mřížku a postavy či jiné kameny by se tak nedostaly na jejich střechu. I v případě, že by engine byl udělán tak, že by se na střechu dostat/dopadnout šlo,
(nebo magnetický by se mohl zmagnetovat a zastavit o jiný, který je mimo rastr) celá logická koncepce Quadraxu by šla do háje - už by nebyl "quadratický".
Nejde totiž jen o interakci kvádrů v dvou míjejících se výtazích, ale o spoustu dalších. Namátkou třeba (vždy jde o vzájemné interakce výbušných či magnetických):
- Výtah s kamenem jede nahoru/dolů a vedle něj padá další kámen stejného typu,
- jeřáb zvedá kámen a přitom vedle padá jiný,
- jeřáb zvedá kámen a vedle zvedaného jede dolů výtah se stejným kamenem,
- atp.
Možných kombinací, kdy se vedle sebe ocitnou dva (či více) kvádrů, které na sebe mají reagovat (zmagnetovat, vybuchnout) je spousty. A ve valné většině z nich nejsou kvádry zrovna v přesné pozici logické mřížky.
Ve starších Quadraxech bylo toto řešeno poměrně nedokonale a jistě spousta z vás zažilo situaci, že se dva výbušné či magnetické kvádry "minuly", aniž na sebe zareagovaly. Například předevčírem mi dokonce na toto téma napsal
Dušan mail. Jako kdyby věděl, že toto zrovna už několik dní intezivně řeším... ;-)
Jediné smysluplné řešní, aby k výše nastíněným skutečnostem nedocházelo (tj. aby nedocházelo k míjení kvádrů bez jejich logické reakce a také aby ta reakce nenastala mimo logickou síť), bylo nutné napsat spoustu nového kódu,
který se snaží řešit obdobné situace. V zásadě jde o to, že pokud výtah/jeřáb veze výbušný či magnetický kvádr, musí se neustále "dívat" kolem sebe (respektive těsně na levo a na pravo od vertikální dráhy kamene), jestli vedle
nepadá (nejede ve výtahu, na jeřábu, atp.) jiný kvádr, který by měl reagovat s tím, který se aktuálně veze/nese. Pokud takový kámen zjistí a vypočte, že by k reakci kamenů došlo mimo logickou mřížku, upraví se chování samotného výtahu
či jeřábu a také se nastaví vedlejšímu objektu informace, že jej čeká interakce s jiným kamenem. Celý tento sofistikovaný predikční systém pak zajistí, aby k vzájemné reakci kamenů došlo přesně v zarovnání logického rastru hry.
Když opět použiju obrázkový příklad výše, tak po zapnutí páčky ten z výtahů (ještě než se rozjede), který ve vyhodnocování interakcí přijde na řadu jako první, zjistí, že vedle by jel výtah se stejným kamenem ale potkali
by se tak, že by kameny vedle sebe byly v tom okamžiku mimo logickou mřížku. Jednoduše tedy druhému výtahu dočasně "zakáže jízdu" na dobu 500ms (tolik trvá výtahu ujet jednu logickou kostku) a pak už se bez obav
vydá směrem svého pohybu, neboť ví, že druhý výtah na něj (nuceně) počká. Obdobně (jen trochu složitěji) je to řešeno s padajícími kameny, jeřáby atp.
Strávil jsem vývojem a laděním těchto kontrolních algoritmů neskutečně času. Snad jsem ale vychytal všechny možné případy a kombinace, které mohou v herním enginu nastat. To ovšem ověří až čas a pak také hráči. Doufám,
že vše bude OK, ale přesto - pokud se stane to, že na sebe dva kameny prostě nezareagují, bude to v 99% případů při jejich vertikálním opozičním pohybu - prostě nastala situace, kdy i nový predikční algoritmus
selhal a nedokázal jeden z kamenů zastavit včas tak, aby druhý mohl doputovat přesně vedle něj...
25.6.2014
Vzhledem k diskusi zde na fóru jsem se rozhodl do hry implementovat tu vlastnost chůze postaviček, že na laně může na jednom místě stát pouze jedna postava a postavy se pochopitelně nemůžou na laně míjet.
Ač jsem si myslel, že implementace bude jednoduchá, opak byl pravdou. Až třetí úprava kódu konečně fungovala tak, jak jsem si představoval. Následovalo přetestování všech dosavadních levelů, kde se zatím provazy vyskytují, a to
jak mnou, tak testerem. Zatím se zdá, že implementace této nové vychytávky proběhla v pořádku a nevnesla do kódu žádné chyby. Vzhledem k tomu, že levely s provazy se dále ve hře vyskytují poměrně často (díky všem pravidlům platným pro
provazy umožňují tyto levely zatím neviděné a unikátní pointy) tak jednak je důkladné otestování nezbytné a druhak se vše tím pádem ještě několikrát otestuje při samotném vývoji levelů a jejich testování. Upřímě ale říkám,
že se máte na co těšit a jistě mě bude spousta hráčů proklínat. ;-)
11.4.2014
Jelikož Quadrax X bude uchovávat o hře (a o hráči) daleko více informací o řešení jednotlivých levelů, než všechny předchozí verze dohromady, bylo by posílání uživatelských souborů poměrně složité a soubory datově objemné.
Pro komfortní zasílání informací jsem proto napsal jednoduchý podpůrný program (utilitu), která většinu těchto věcí udělá sama. Po spuštění jednoduše automaticky zabalí a zazipuje všechny uživatelské soubory do jednoho balíku a ten poté
uloží na disk tam, kam si uživatel vybere (defaultně se bude nabízet složka "dokumenty" daného uživatele). Tento soubor pak už jen uživatel pošle mailem (tak jako dosud). Uživatel už tedy nebude muset pátrat ve složkách hry a hledat
soubory dat, vše za něj udělá tento program sám. Je to další uživatelské zpříjemnění práce s hrou pro ty, kteří zasílají svoje data do rekordů.
2.4.2014
Implementace bezpečnostních prvků a protokolů probíhá nad očekávání dobře, vypadá to, že vše zabere méně času, než jsem původně předpokládal. Zároveň pracuji na mírné úpravě dat hry - rozšířil jsem například
statistiky jednotlivých levelů. Nyní obsahují i údaj, kolikrát byl daný level celkově spuštěn a kolik spuštění (nebo restartů - restart je brán jako nové spuštění levelu) levelu bylo potřeba do prvního vyřešení daného levelu.
Společně s ostatními statistickými údaji o krocích a časech v levelu tak bude velmi snadné zjistit, zda-li některý hráč nepodvádí - pokud bude mít u nějakého opravdu těžkého levelu např. počet spuštění výrazně nižší,
než je průměr u ostatních hráčů (v extrémním případě např. jen jedno spuštění levelu a hned jeho úspěšné vyřešení) bude nad slunce jasné, že level buďto hrál podle nějaké nápovědy (ať už od jiného hráče, nebo kdekoliv jinde zjištěné),
nebo si jej "natrénoval" někde jinde (na jiném PC atp.). To bude platit i v případě, že někdo hraje pod dvěma uživatelskými účty, jedním "tréninkovým" a druhým "ostrým". Takovéto případy budu řešit idividuálně.
Jak budu zacházet s těmito spornými daty ještě nevím. Je jasné, že u evidentních podvodů zřejmě nebudu tyto data daného hráče vůbec publikovat, při pochybnosti u jednotlivých levelů bude záležet na více skutečnostech
a komunikaci s hráčem.
S výše uvedeným také souvisí bohužel i to, že Quadrax X nepůjde už tak jednoduše hrát "paralelně" jedním hráčem na více počítačích zároveň (nebude fungovat běžné zkopírování celé hry či jen některých jejích souborů na jiný PC).
Pokud někdo takto bude chtít hrát, bude to samozřejmě možné - ale bude muset hru regulérně instalovat na oba počítače a to co uhraje na jednom PC, bude muset odehrát i na tom druhém. Při zasílání dat rekordů tuto skutečnost
bude muset zmínit a při zapisování dat do rekordů poslat vždy oba soubory uživatelských dat (z obou PC).
Možná se toto všechno může pro někoho zdát příliš omezující - ale pokud jste poctivý hráč, žádný problém to pro vás nebude. Prostě hrajte pod jedním založeným účtem (nezakládejte si žádné "tréninkové") a hotovo. Jediné omezení bude
to výše zmiňované hraní na dvou PC a to v nutnosti odehrát daný level na obou počítačích.
Všechny tyto věci mají zajistit to, aby celkové výsledky jednotlivých hráčů byly co možná nejvíce poctivé a korektní. Všichni, kdo se okolo Quadraxu už nějakou dobu pohybují ví, že v minulosti se stalo nemálo případů,
kdy dosažené výsledky některého z hráčů nebyly dosaženy úplně "čistým způsobem". Tak snad tyto výše zmíněné metody zabrání nejhorším excesům a podvodům ve výsledcích.
30.3.2014
Nyní něco z paranoidního koutku. Vzhledem ke skutečnostem, které se v nedávné době staly, jsem se rozhodl do testovací verze zabudovat velké množství bezpečnostních kontrol a ochran. Ať už jde o omezený počet spuštění programu, vazbu
na konkrétní PC, nebo jiné bezpečnostní mechanismy (které tu pochopitelně nebudu prozrazovat), tak asi hlavní a nejdůležitější věcí na nové testovací verzi bude to, že nebude fungovat bez online připojení k serveru Quadraxu.
Testovací verze bude totiž přes internet zasílat data o hlavních činnostech, co konkrétní tester ve hře dělá, přímo na server. Logovat se budou zejména činnosti jako spuštění či ukončení hry, spuštění, restart či ukončení levelu,
a v případě úspěšného dokončení levelu též i jeho čas a kroky. Všechny tyto logy (i s časovým razítkem) budou ukládány do databáze a budou se dát velmi lehce zobrazit. Pokud nebude připojení k internetu k dispozici, či v průběhu
hraní hry "spadne spojení", hra se automaticky ukončí. (S tím, že tyto věci budu taktéž moci snadno dohledat v databázi - pokud například bude zalogováno spuštění hry, ale už nebude existovat párový záznam o jejím vypnutí,
bude jasné, že v průběhu hraní hry došlo k odpojení internetového připojení).
Tímto budu mít celkem dobrý přehled o veškeré činnosti testera/ú ve hře. A nejen já. Zjednodušená tabulka s jednotlivými logy daného testera bude veřejně přístupná všem hráčům, přímo na těchto stránkách.
(Samozřejmě bez zobrazení kroků a časů v levelech a dalších citlivých dat). Takže každý bude moci vidět, jak si daný tester momentálně vede.
Další z výhod online komunikace hry se serverem bude, že v případě mých pochybností o činnosti testera budu moci konkrétní hru dálkově "zablokovat" - pokud hra při po svém startu a připojení k severu na něm nalezne
blokační záznam pro tuto kopii, automaticky se ukončí s patřičnou hláškou. Atp., atp...
Proč je tento text ale tady, v deníku vývojáře a ne v novinkách? No, protože se musím v C++ naučit obsluhovat https protokol a spoustu dalších věcí, se kterými nemám zrovna v C++ příliš zkušeností. Bude to tedy chvíli trvat,
než bude nová testovací verze hotová. Než do ní zabuduji veškeré plánované kontrolní a ochranné mechanismy a než je řádně otestuji, zabere to zhruba měsíc.
Říkáte si, že je to zbytečné? To jsem si dříve myslel taky a spoléhal na důvěru. Bohužel, z naivního pohledu na svět jsem už vyléčen a chci mít dohled na tím, co a kde právě konkrétní testovací verze hry dělá...
Samozřejmě, že všechny tyto věci budou pouze v testovací verzi - ostrá verze hry nebude nic takového (doufám) potřebovat a bude fungovat naprosto stejně, jako jakákoliv předchozí verze Quadraxu.
26.2.2014
Přišel čas věnovat se také trochu zvukové stránce hry. To je věc, které se změny dotkly zatím nejméně. A ani nebylo moc potřeba. Většina zvuků není třeba nijak měnit, jen byly případně upraveny pro synchronizaci
s jinou rychlostí pohybu objektů v novém enginu. Ale přeci jen zde jsou také nějaké změny. Například kroky postav zní rozdílně dle povrchu, po kterém postava jde. Na kamenech/zdech jsou to klasické kroky, tak jak je každý zná.
Ale například při chůzi po laně (jedna z novinek QX) by klapání podrážek znělo divně. A tak bylo nutno vytvořit pár nových samplů pro chůzi po různých površích. Samozřejmostí jsou nové zvuky pro nové objekty
(jako jsou např teleporty kamenů ap.)
Ale asi největší změnou bude, že základní zvuky (kroky, přepínání páček, plošinek atp.) budou modifikovány v závislosti na tom, kde se jaký level bude odehrávat. Takže v levelech "pod širým nebem" budou zvuky stejné,
na jaké jsou všichni zvyklí, ale například v levelech odehrávajících se v obří jeskyni/podzemí/velkých opuštěných halách ap. budou mít zvuky ozvěnu dle daného prostředí. Věřím, že to ještě více podpoří
(mimo dobře zvolené hudby) tu správnou atmosféru té které epizody.
Také probíhají ladící práce na enginu - odchytávám bugy a sem tam přidám nějakou novou vlastnost (například možnost spuštění pouze jedné instance programu ap.) Jde už ale jen o malé a drobné úpravy a opravy,
které na výslednou velikost kódu mají jen malý vliv. Hlavní ladění a odchytávání chyb začne až po spuštění testování levelů. A málem bych zapomněl - přidal jsem jednu důležitou vlastnost chování pohybu postav,
která více odpovídá realističnosti - a to, že postavy na žebříku se nemohou "přelézat". Pokud tedy nějaká postava leze po žebříku a druhá za ní, nemůže tu první přelézt tak, jak tomu bylo ve všech mých předchozích
Quadraxech, ale musí pěkně počkat, než ta první postava z žebříku odstoupí. ;-)
13.2.2014
Dnes něco z programátorsky - statistického soudku.
Jelikož celý program je prakticky hotový a už se budou pouze dolaďovat různé drobnosti, zkusil jsem udělat takovou malou statistiku jak takový prográmek vlastně vypadá. Takže zdrojový kód Quadraxu deset skrývá tyto informace:
- Počet řádků - 24 245
- Počet znaků - 987 852
- Počet podmínek if - 2 932
- Počet cyklů for - 509
- Počet podmínek switch - 38
- Počet funkcí a metod - 121
Toto si ale především "užijí" pouze ti, co se trochu zajímají o programování - ti si z toho mohou udělat nějaký obrázek...
Pro ty ostatní je důležitá jen informace, že engine hry je hotový a teď se konečně začne pracovat na levelech, grafice, hudbě a ostatních "podružnostech". Samozřejmě že se v deníku vývojáře i nadále dočtete
zajímavosti z vývoje hry...
12.2.2014
Vytvořeny všechny potřebné funkce pro ukládání a načítání hry. Vzhledem k tomu, že jsem dopředu chytře navrhl struktury dat (a počítal s tím už předem - a ne abych to pracně dodělával jako v QIV), byla to celkem brnkačka.
Engine hry je tím tedy téměř hotov a nyní se konečně můžu pustit do samotné tvorby levelů a samozřejmě, také začne testování, které bude tentokráte doufám důkladnější, jak u QVIII. ;-)
6.2.2014
Trocha povídání o grafice aneb jak se tvoří grafická podoba levelů hry.
Grafické zobrazování levelů v QX je naprosto odlišné jak v předchozích dílech. Každý level je v podstatě složen z několika vrstev, které jsou postupně přes sebe skládány na obrazovku, až do jednoho výsledného obrázku.
Celkový obrázek je tvořen těmito devíti vrstvami:
- Pohyblivé (aktivní) dynamické pozadí (např. obloha v demo levelu).
- Pevné statické pozadí.
- Pozadí staveb v levelu. (Kamenné zdivo, skála ap.)
- Stavby - tj. to, po čem se chodí.
- Pohyblivé stěny, propadla ap.
- Objekty levelu (tj. všechny aktivní objekty jako postavy, průchody, kvádry, páčky atp.). Jednotlivé objekty jsou vykreslovány v takovém pořadí, aby jejich vzájemné překrývání bylo logické, tzn nejdříve se vykreslují
průchody, pak všechny kvádry a potom teprve všechny páčky - aby byly viditelné (těch pravidel pro pořadí vykreslování objektů je pochopitelně více.)
- Overlay stěny (novinka v QX) jako například posuvné mžíže atp.
- Efektová vrstva (opět novinka v QX, nechte se překvapit).
- Vrstva zobrazení nápovědy, menu, informačních panelů ap.
Toto vše se musí složit do jednoho obrázku za méně jak pět milisekund - z toho je jasné, že grafická karta, která má toto na starosti, rozhodně v QX nezahálí. QX využívá 3D režim a každá z vrstev je prakticky texturou,
které jsou za využití alphablendingu skládány přes sebe. Je využito ortografického režimu zobrazení scény, takže vše na sebe pěkně pasuje.
Co je ale potřeba nakreslit, aby level vypadal tak pěkně, jako na ukázce v galerii? Pro každou epizodu (tj. 10 epizod) je třeba vytvořit obrázky vrstev 1 a 2. To je ta jednodušší část. Vrstvy 6 - 9 jsou vytvářeny automaticky enginem hry,
a berou si obrázky (sprity) objektů z textur, které jsou společné pro celou hru. Takže tady se také nemusíme starat o obrázek samotného levelu. (Samozřejmě, že všechny objekty jsem musel nejprve nakreslit a případně rozkreslit
včetně animovaných spritů jako například pohyby postav, jak je popsáno v deníku ze dne 26.1.2014 níže.) Ale jedinečnost každého levelu v epizodě je dána právě vrstvami 3 - 5. Dá se říct, že vrstvy 4 a 5 se tvoří jako jedna a teprve při nahrávání levelu
si engine "vypíchne" potřebné textury pohyblivých zdí do samostatné vrstvy č.5. Takže jsme se dostali k tomu, že pro každý level je potřeba vytvořit v zásadě dvě vrstvy. Vrstvu pozadí staveb (3) a vrstvu staveb samotných(4+5,
pro zjednodušení ji nadále budu nazývat pouze vrstvou 4 - včetně posuvných zdí a propadel).
Editor levelů ve hře obsahuje jednoduchý grafický systém (editor) pro počáteční tvorbu vrstvy 4. Obsahuje zásobu základních stavebních kamenů (čtvercových, obdélníkových, různě zkosených či zakulacených ap.) ve všech barevných
a materiálových variacích, co jsou ve hře použity. Pro upřesnění, je to zhruba tři a půl tisíce základních stavebních prvků, které jsem musel nakreslit (resp. hodně z nich mě ještě čeká). Jednoduše, pomocí myši, se tedy "naklikají" potřebné zdi, dveře, propadla atp. To je ale vše, co editor obrázků ve hře umožňuje. Ale to by bylo žalostně málo!
A tady už přichází ke slovu pokročilé grafické programy jako je Gimp či Photoshop. Otevře se v něm editorem vytvořený obrázek vrstvy pro daný level a začne mravenčí práce. Do vrstvy se přidají všechny ostatní statické
obrázky (sochy, velké kamenné stavby, nádoby a jiné drobné objekty jako kostry aj., liány, stromy, atp.) Zároveň se může upravit i samotná podoba kamenných zdí - některé kvádry se posunou, natočí, přidají se odrolené rohy,
praskliny atp. Dále je možno dodělat stíny některých objektů vrhaných na zdi, pro zvýšení plastičnosti působení levelu - v ukázce v galerii jsou to stíny soch v popředí chrámu vlevo, a stíny velkého stromu a sochy vpravo.
Zároveň je ovšem třeba pracovat i na vrstvě č.3. Tam, kde nechceme aby v "chodbách" bylo vidět základní pozadí (tj. vrstvy 1+2), vytvoříme různé zdivo, skálu apod. Zároveň provedeme správné stínování, dle polohy zdí vrstvy 4 tak,
aby v rozích bylo tmavěji ap. Dále provedeme nasvícení zdiva tam, kde budou umístěny louče, hořet ohně nebo kde bude zdivo osvětleno dením světlem - opět pro zvýšení realističnosti vzhledu. Tuto vrstvu tvoříme pod
vrstvou 4, která ji bude i ve hře překrývat. No a až máme po několika hodinách obě vrstvy hotové, uloží se jako PNG obrázky do patřičného adresáře hry, odkud si je hra nahrává.
Protože jsem v průběhu vývoje zjistil, že je zbytečné, aby engine v každém obrázku (tj. každých 16ms) na sebe skládal vrstvy 2, 3 a 4 (neboť ty se v průbehu hry nijak nemění) upravil jsem engine tak, že před startem levelu si načte
tyto tři vrstvy a smíchá je do jedné jediné, kterou pak vykresluje v jednom kroku. Tuto vytvořenou "dočasnou" vrstvu si hra ukládá na disk, aby v případě restaru levelu (nebo vypnutí a zapnutí hry a hraní stejného levelu)
nebylo potřeba dělat znovu míchání vrstev. Jen podotknu, že k zmíněnému míchání těchto vrstev se nepoužívá grafická karta, ale dělám to vlastní funkcí. Pro výpočet alphablendingu jednotlivých pixelů používám klasickou výpočetní funkci,
jejiž princip je obecně znám a každý, kdo se trochu zajímá o počítačovou grafiku, jí nebude překvapen. Ve zkráceném zápisu je to:
Takže, to by bylo ve zkratce asi vše k tomu, jak vzniká obrázek jednoho levelu. Jen dodám, že zatím co samotnou strukturu tohoto levelu a prvotní vytvoření vrstvy 4 jsem měl hotové asi za hodinu (je to první level ve hře, takže
je opravdu velmi jednoduchý) tak na výsledné grafické podobě vrstev 3 a 4 jsem pracoval cca deset hodin. Uvědomuji si, že je to trošku nepoměr - hráčům bude trvat "vyřešení" tohoto levelu maximálně pár minut (2 - 3 minuty)
a asi ani nebudou "mít čas" ocenit moji mnohahodinovou práci na grafické podobě tohoto levelu. :-/ K výše uvedenému se váže i to, aby si všichni uvědomili, (zvláště ti jedinci, kteří si pořád říkají: "Kdy už to sakra bude a co mu na tom proboha
trvá tak dlouho?"), jak je tvorba hry náročná. A to jde o nejjednodušší level ve hře! Když vezmu v úvahu, že vymyšlení pointy a vytvoření struktury a všech objektů složitějších levelů trvá minimálně 5 - 10 hodin na jeden level
(a to nepočítám čas na testování!) a k tomu se připočte dalších 10 - 15 hodin na tvorbu grafické podoby levelu, vychází to průměrně na +- 20 hodin práce na jednom levelu. Quadraxu sice věnuji veškerý volný čas, ale i tak,
dejme tomu, že na něm budu pracovat každý den (včetně sobot a nedělí) cca 5 hodin denně, tak jednoduchým výpočtem dojdeme ke 400 dnům potřebným na vytvoření všech levelů. Bez testování a následných úprav...
No, a to jsme do toho ještě vůbec nezapočítali programování enginu hry, tvorbu hudby a zvuků, vymýšlení příběhu a psaní deníku a další spoustě různých drobností, co se musí na hře dělat.
Tak co, jak vám připadá časová náročnost tvorby takové "jednoduché" hry teď? ;-)
5.2.2014
No, testovací demoverzi mám zdárně za sebou a vypadá to, že nikdo neobjevil v enginu žádnou závažnou chybu či padavost hry. To je dobré. Ale musím pracovat intenzivně dále, ať je co nejdříve možné vytvořit
testovací verzi a začít konečně testovat jednotlivé levely. Teprve pak nastane to správné martyrium s tvorbou levelů a jejich laděním a testováním.
Takže jsem se vrhl na systém uživatelských účtů. Jeho ovládání bude úplně stejné jako v předchozích Quadraxech, neshledal jsem na něm nic špatného. Co je však pochopitelně zcela nové je vnitřní práce programu s daty
uživatele. Rozhodl jsem se, že uživatelům se nebudou ukládat pouze základní data, jako nejlepší kroky/čas, ale každý uživatelský účet bude mít podrobnější statistiku. Co tedy bude uživatelský účet obsahovat za data?
Tady je máte přehledně seřazené.
Uživatelský účet bude obsahovat informace o:
- nejlepších (rekordních) krocích/času každého levelu,
- krocích a času levelu dosažených při prvním úspěšném vyřešení toho kterého levelu,
- všech krocích a času strávených v daném levelu než byl level poprvé úspěšně vyřešen,
- absolutně všech krocích a času strávených kdy v daném levelu (tj. i po vyřešení - při následném vylepšování kroků),
- součtu všech nejlepších kroků a časů vyřešených levelů,
- součtu absolutně všech kroků udělaných ve hře.
Tato statistika bude pochopitelně viditelná i uživateli samotnému - na stránce nejlepších výsledků ve hře se, po najetí myší na řádek daného levelu, zobrazí u kurzoru myši okno s detailní statistikou levelu.
Hráč tak bude mít celkem dobrý přehled, který level mu dal nejvíce zabrat než ho vyřešil, případně který je jeho nejoblíbenější při vylepšování apod.
Samozřejmě, že struktura uživatelských dat se mírně nafoukla, aby bylo možné všechny tyto údaje uchovávat. Ale není to naštěstí nic tragického, jde jen o pár kilobajtů paměti a místa na disku. Ještě je otázkou,
zda tyto údaje zobrazovat i na stránce rekordů zde na webu - to si ještě rozmyslím jestli (a jak) to implementovat... ;-)
26.1.2014
Uff, byla to fuška a zápřah. Předešlých čtrnáct dnů jsem věnoval Quadraxu snad i více času, než by bylo zdrávo. Denně jsem naspal tak maximálně 4-6 hodin, a naprosto veškerý volný čas spolkla tvorba animace pohybů postav.
Ale dá se říct, že úsilí nebylo marné... Skoro všechny animace pro postavu (zatím jen pro jednu) už mám téměř hotové! V konečném výsledku dělá celkový počet animačních spritů více jak 1200!!! Ano, čtete správně,
jednotlivých animačních okének je hodně přes tisícovku! Kdo tomu nevěří, má možnost si jednotlivé sprity spočítat na obrázku, viz níže... ;-)
Dávat sem celou bitmapu animací by kvůli její velikosti (2048x2048px) moc nešlo, tak zde alespoň ukážu její kopii, zmenšenou na cca 33% původní velikosti. Je pravda, že tam toho není moc k vidění, protože po tomto zmenšení se z postav
stali skuteční pišišvoři, ale pro představu o obsáhlosti a množství animací to stačí. Kochejte se zde:
Je jich skutečně dost, co říkáte? ;-) Navíc tentokráte jsou pohyby vlevo a vpravo "logicky správné". Pro vysvětlení - v Quadraxech III - VIII byly všechny animace pohybů postav vlevo udělány pouhým zrcadlovým otočením animací
pro pohyb vpravo. Velmi snadno to bylo poznat na nelogickém nošení brašny na boku postavy - brašna byla stále viditelná, jako by si ji postava pořád přehazovala z pravého boku na levý. ;-) V Quadraxu X byly všechny stranové animace
vytvořeny separátně - takže pokud jde postava doprava, má brašnu na pravém boku (a ta je viditelná) ale pokud jde doleva, je vše správně (brašnu má stále na pravém boku). Taktéž stínování postavy kompletně odpovídá. Toto vše bylo
možné hlavně proto, že všechny animace jsem nejprve vytvořil v 3D a pro to, jestli to bude animace pohybu vpravo/vlevo, pak stačilo pouze přepnout pohled kamery na postavu a vygenerovat jednotlivé bitmapy animace.
Animací je tak obrovský počet zejména proto, že téměř všechny jsou vytvořeny pro 60fps - tzn. pro jednu sekundu animace bylo potřeba vytvořit 60 obrázků. Pouze některé méně důležité animace při kterých se postava nehýbe z místa
(otáčení postavy ap.) mají "pouhých" 30fps... ;-) Teď už zbývá jen dodělat některé animace různých smrtí postav, a po přebarvení košile na další dvě barvy (pro další dvě postavy) bude ta nejtěžší grafická část práce hotova.
15.1.2014
Jelikož základ enginu je prakticky hotový (tedy co se týče schopnosti hrát level - jinak v něm chybí ještě spousta věcí), bylo zapotřebí pustit se do samotné grafiky hry. A začal jsem hned tím nejzákladnějším (a zároveň nejobtížnějším),
tj. tvorbou animace postav. Původně jsem myslel, že animace provedu stejně jako u QIII - tedy natočím se na kameru a z výsledného videa vyrobím jednotlivé framy animace. Bohužel to však nebylo možné z mnoha důvodů - mj. hlavně pro
vysoký framerate hry (60fps vs 24 fps u kamer). Chvíli jsem váhal co a jak, ale nakonec jsem se ohodlal a rozhodl se, že veškeré pohyby postav udělám pomocí počítačové animace (CGI). Stáhl jsem si několik programů na reálnou animaci
lidské postavy a různě je zkoušel. No a nakonec jsem jeden z nich zvolil a začal se v něm učit. Jelikož jsem neměl absolutně žádné zkušenosti s prací v 3D animačních programech, byl to ze začátku trochu porod. Ani moc nepomáhal
manuál k programu, neboť měl přes tisíc(!!!) stran - to než bych nastydoval, tak by se psal příští rok. Ale metodou pokus/omyl jsem nakonec zvládl všechny potřebné funkce programu a mohl začít s tvorbou animací.
Ze začátku to šlo hodně těžko - mnou vytvořené postavy se pohybovaly jakkoliv jinak, než tak, jak jsem potřeboval. Jejich chůze připomínala v lepším případě potácení zombií, v tom horším postava vypadal, jako kdyby měla jít na velkou
a nestihla to... ;-) Ale nakonec se dílo jakž takž podařilo, a i když nejsem s výsledkem úplně spokojený, lepší už to asi nebude. Na to, abych si najal animátory z Pixaru, mi chybí na kontě pár miliónů dolarů, takže vše musím oddřít sám. ;-)
Na následujícím obrázku můžete vidět animační set postavy pro běžnou chůzi vpravo. Je vytvořen pro přehrávání v režimu 60 fps, tzn. že každý jeden obrázek animace trvá ve hře pouhých 0,016 s! (Šestnáct milisekund!):
Z výše uvedeného obrázku si ale málokdo dokáže představit, jak ta animace vypadá ve skutečnosti. A protože jsem dobrák od kosti, věnoval jsem pár hodin tomu, abych vám připravil animovaný GIF, který alespoň přibližně ukazuje
celý cyklus animace. Samotný obrázek níže nemusí ukazovat animaci v reálné rychlosti (neboť formát GIF tak přesné časování neumí) a dle prohlížeče může být oproti skutečnosti zpomalený nebo thraný :-( ...
Takže slíbený obrázek animace běžné chůze postavy vpravo pro Quadrax X je zde:
No, nakonec to snad není až tak špatné, ne? V reálné rychlosti to vypadá jako celkem přirozená chůze. Na to, že s 3D animačním programem pracuji cca 14 dní to IMHO ujde... ;-)
24.12.2013
Editor je takřka hotov. Má už vše, co je potřeba pro tvorbu jednotlivých levelů, umisťování a manipulaci s objekty včetně nastavování jejich parametrů a propojování linků aktivních objektů.
Také už je hotovo cca 80% všech funkcí, zajišťující logiku chování jednotlivých objektů, takže nyní začíná fáze testování editoru a těchto funkcí - tj. jestli spolu objekty navzájem reagují tak, jak by měly,
jestli někde nedochází k nelogickému/chybnému chování objektů atp. Toto bude mravenčí práce, musím vždy vymyslet všechny možné situace a kombinace objektů, které mohou nastat a pak je v editoru vyzkoušet,
jestli se vše chová tak, jak má. Na následujícím obrázku pak můžete vidět jeden takovýto testovací level. (Nehledejte v něm nějaký smysl! Ten level slouží pouze k testování chování objektů). Po kliknutí
na obrázek se tento otevře v novém okně/záložce v plném rozlišení:
Poznámka - jistě jste si všimli, že grafická prezentace některých objektů je poněkud prostá - je to pochopitelně tím, že tyto objekty ještě nemají vytvořenu žádnou grafickou podobu a tak jsou prozatím reprezentovány
pouze jednobarevnými maskami jejich tvaru. Pečlivější z vás si dokonce všimnou i toho, že některé objekty jsou dočasně vytvořeny pouhým zvětšením jejich předobrazu z QVIII o 30% (postavy, některé kvádry ap.).
Je holt potřeba začít pořádně makat i na grafice hry...
30.11.2013
Protože sebelepší program bez grafiky je jen program, co zpracovává nějaká data, je třeba nyní trochu pohnout právě s grafikou. Jelikož pro QX se nedá použít téměř vůbec nic z předchozích Quadraxů, nezbývá, než vše udělat znovu.
Samozřejmě, že určité markanty daných objektů zůstavají a někdy dokonce bude objekt vypadat hodně podobně jako v předchozích díle, přestože je zcela nový. Vše snad bude jasné z následujícího příkladu, včetně grafické ukázky a srovnání.
Vzhledem k tomu, že ve starých Quadraxech byl jeden logický "sektor" hry čtverec o délce strany 20px a v QX je to 30px, jsou všechny objekty QX o cca 33% větší a tím pádem můžou být i daleko podrobnější.
Jako příklad zde uvedu tvorbu nové grafické podoby průchodu, který měl původní rozměry 3x3 logické čtverce (tj. 60x60 pixelů, 3600px celkem) a nově má sice také 3x3 čtverce, ale graficky má 90x90px (tj 8100px, tedy více jak 2x větší plochu!).
Na následujícím obrázku máte možnost srovnat původní kamenný průchod z předchozích dílů (vlevo) a nově nakreslený průchod:
Nic moc rozdíl, řekne si někdo, že? Ale po zvětšení obou obrázků už je jasné, že původní průchod pouze zůstal vzorem pro rozmístění kamenů (pro grafiky - byla použita pouze interpolovaná a upravená maska "malty" mezi kameny),
ale samotná textura kamenů i vnitřku chodby jsou zcela nové. Můžete to porovnat na obrázku níže, kde jsou oba průchody srovnány na stejnou velikost a zvětšeny na 200%:
Zde už je jasně poznat, že nová grafika je daleko jemnější a podrobnější, jak stará. No a takto se musí znovu vytvořit úplně vše. Kameny, výtahy, jeřáby atd, atd...
22.11.2013
Vývoj editoru pokračuje bez větších problémů. A zároveň (pro testování objektů editorem vytvořených) bylo třeba už začít tvořit i jádro hry. Vzhledem k tomu, že vše se píše zcela nově, nebude kód takový slepenec jako dříve.
Dá se říct, že základní jádro je jednoduchá primitivní smyčka, postupně volající všechny potřebné funkce - tj. jako první funkce, co se starají o logiku chování objektů a poté, co je vše spočítáno, se volají grafické rutiny pro vykreslení
celé scény, tj dynamické pozadí, statické pozadí a objekty samotné. Pokud by někoho opravdu zajímalo, jak vypadá třeba takový kousíček kódu, který je jádrem volán a který
se v tomto případě stará o logiku a výpočty pohybů posuvných stěn (jeden ze základních prvků Quadraxu), tak ukázku funkce která zajišťuje pohyby stěn si zobrazí po kliknutí na odkaz ZDE.
Samozřejmě, jde jen o ukázku jedné malé funkce a nejsou tam zobrazeny funkce následné (tj. testovací, čtecí a zapisovací fce, které se v ní používají), které tato funkce volá (to by ta ukázka neměla cca 500 řádků, ale trochu více ;-)).
Takovýchto funkcí, jako je v ukázce výše, obsahuje kód hry pochopitelně spoustu, dá se říct, že každý druh aktivního objektu (ať je to kámen, páčka, výtah, jeřáb ap.) má takovouto svoji funkci, která zajišťuje jeho správné chování
v prostředí Quadraxu. Samostatnou kapitolou jsou pak funkce pro zajišťování pohybu postav a testování jejich interakcí s ostatními objekty. Ty ještě nejsou napsané, neboť ještě ani neexistují žádné animace postav,
což bude asi nejnáročnější grafická činnost, která mě čeká.
11.11.2013
Tak pro dnešek něco málo grafiky. Vývoj editoru probíhá zdárně, ale pro jeho testování už bylo potřeba začít tvořit i nějakou tu grafiku pro objekty. A jako první jsem pochopitelně začal tím, co je v Quadraxu nejzásadnější objekt - tedy kameny (kvádry).
Nechci vám tady ovšem ukazovat obyčejné kameny, ale podělím se o tvorbu jedné ze základních animací. Celá hra, ač běží ve 3D módu grafiky, je stále klasická 2D. Tzn, že všechny animace jsou tvořeny jednotlivými, po sobě jdoucímí
obrázky (tzv. sprity). Je to stejný princip, jako u klasického animovaného filmu - políčko po políčku se mění sprite (obrázek) animace a ve výsledku vznikne dojem plynulého pohybu/změny objektu.
Někteří lidé ani netuší, co všechno stojí i za tak drobnou a "nedůležitou" animací jako je například rozpad křehkého kamene, která ve hře trvá necelou sekundu. Takže jak vlastně taková animace rozpadu křehkého kamene v grafickém editoru
(Pozn. - Pro veškerou práci s grafikou využívám freewarové programy jako jsou Gimp, Blender ap.) vzniká? Projdeme si to hezky v bodech:
- Jako první se vezme za vzor nějaký z již vytvořených kamenů.
- Poté se do něj nakreslí "praskliny" a hrany prasklin se zplastiční některým z efektů emboss ap. Tím získáme základní sprite křehkého kamene, který bude zobrazován ve hře.
- Dále je třeba vymyslet a navrhnout, jak se vlastně kámen a jeho jednotlivé části bude rozpadat a hroutit.
- Poté se kámen rozdělí na zhruba dvacet dílů (vrstev) podle toho, na jaké kusy se bude rozpadat.
- Uděláme si šestnáct kopií z předchozího bodu pro 16 framů animace - tím získáme celkem 320 vrstev (dílů) v šestnácti skupinách, ve kterých se musíme vyznat.
- A nyní přichází ta nejsložitější a nejzdlouhavější část práce - v každém framu animace musíme postupně pootočit/posunout každý z těch 20-ti dílků tak, aby ve finále vznikl dojem plynulého pohybu.
- Jedná se o stejný princip, jako se používá ve stop-motion animaci. Vždy kontrolujeme následující a předchozí frame animace, jestli na sebe pěkně navazují.
- Při animaci hroucení jednotlivých částí kamene nesmíme pochopitelně zapomenout umazávat překrývající se části kousků.
- V pokročilejší fázi rozpadu kamene také kreslíme do velkých rozpadajících se kusů nově vznikající praskliny a případně kus rozdělíme na další dvě vrstvy a každou pak animujeme separátně
- Až máme vše hotovo, ještě doladíme poslední fáze rozpadu zmenšením a rozpraskáním posledních zbytků kusů kamenů, co zbyly.
- Ve finále pak máme projekt se zhruba 400 vrstvami - z nichž každá z nich je jeden z kousků původního kamene, animovaná tak aby vznikl dojem plynulého rozpadu a zhroucení kamene.
- Všechny vrstvy sloučíme do jedné - je třeba průběžně kontrolovat alphablending a antialiasing hran, aby vše bylo OK.
- No a nakonec získáme jeden obrázek, který se použije jako bitmapový zdroj pro engine hry, kdy v případě potřeby rozpadu kamene se tato animace spustí.
No a na následném obrázku můžete vidět výsledek celé výše popsané práce:
Ve hře trvá tato animace, jak už jsem zmínil, necelou sekundu. Ale její tvorba zabrala několik hodin usilovné práce. A to jde o jednu jedinou animaci, ve hře je jich pochopitelně několik set. Takže teď už si možná dokážete
představit, jak jsou tyto věci časově náročné na tvorbu, a proč nemůže být Quadrax X hotov během chvilky... ;-) A to jsem ještě nezmínil drobnost, že i tato animace musí mít několik barevných variant (mechem porostlý kámen ap.) ale
ty už v zásadě vychází z této zdrojové animace.
6.11.2013
Vývoj enginu zatím probíhá bezproblémově, naučení se práce s D3DX bylo poměrně lehké a až na pár malých zádrhelů proběhlo OK. Základní kostra programu, zajišťující zobrazování grafiky, zpracování událostí myši a klávesnice atp.,
je tedy takřka hotová. Přesto je to jen maličký kousek výsledného kódu, do kterého se musí nyní napsat samotný "Quadrax". Samozřejmě, že bych rád hned začal programovat jádro hry, ale předtím se musí udělat ještě spousty nudné,
ale nutné práce. Především je to navržení veškerých datových struktur potřebných pro hru. Původní datové struktury pro Quadrax III jsem kdysi vymyslel velmi dobře, neboť prakticky beze změn ustály vývoj hry až do dílu osm.
Ale v desítce bude vše jinak a tak to chce i nové, dostatečně robustní, formáty dat. Naštěstí není množství informací o objektech hry nějak extra velké (ale ani malé!), takže návrh struktur nezabere zase tak moc času.
Co ale zabere času hodně, bude Editor. Původní editor v předchozích dílech byla taková z nouze ctnost a nebyl to, pravda, zrovna nejlepší kousek software. Nový editor pro QX bude zcela jiný, daleko příjemnější na obsluhu a hlavně práci
s objekty - jednotlivé objekty, umístěné na hrací ploše se budou dát libovolně posouvat, měnit jim všechny atributa atp. Také tvorba základních "zdí" bude o něco lehčí a více uživatelsky přívětivá. Takže prioritou je nyní
naprogramování robustního, funkčního a dobře ovladatelného editoru, ve kterém se budou dát lehce tvořit levely pro hru. Teprve poté přijde na řadu samotný herní engine, který bude s objekty pracovat a to bude teprve ono jádro Quadraxu,
jehož vývoj zabere asi nejdelší dobu (mimo tvorby grafiky).
Mimo práce na editoru jsem ještě na hotovo udělal základní navigaci mezi jednotlivými stránkami hry, naprogramoval zobrazování deníku a vytvořil pro něj grafiku. Hotový deník, i s první stránkou příběhu,
tak můžete shlédnout v galerii.
1.11.2013
Zde budou uváděny technické podrobnosti z vývoje hry a psaní zdrojového kódu programu, jakožto i ukázky kódu a také ukázky grafiky. Jelikož jsem se rozhodl naprogramovat kód hry zcela znovu,
bylo třeba najít odpovídající vývojové prostředí. Historické "Microsoft Developer Studio 97", ve kterém probíhal vývoj všech předchozích Quadraxů, pochopitelně nepadalo do úvahy a po mírných peripetiích
jsem za mírný bakšiš zakoupil Microsoft Visual Studio 2008. Pravda, není to také úplně nejnovější verze, ale umožnuje už vývoj programu pro současné operační systémy s podporou vícejádrových procesorů atp.
Jak tedy bude hra po programové stránce vypadat? Bude pochopitelně opět napsána v jazyce C++ s tím, že veškeré grafické procedury budou využívat knihovny D3D9 a hra bude běžet v "3D módu". Tím valnou většinu
práce s grafikou obstará grafická karta a procesoru zbude dostatek času na výpočty herní logiky. Možná se někdo pousměje nad tím, jakou že to vyspělou herní logiku a herní engine takto "primitivní" hra potřebuje,
ale je třeba se zamyslet nad několika věcmi. Hra poběží v 60fps. To znamená, že na kompletní výpočet konfliktů a interakcí všech objektů ve hře v každém tiku hry má program pouze cca 15 milisekund.
Za těchto patnáct milisekund musí tedy herní engine provést spoustu výpočtů možných kolizí a vzájemných interakcí všech aktivních objektů hry, vypočítat jejich nové stavy, pozice na obrazovce, jejich
grafické vlastnosti a styly a poté, až je se vším hotov, to předat grafické kartě, která ještě musí stačit vše uložit správně do backbufferu předtím, než se provede refresh (flip) obrazové paměti.
Program musí taktéž mezitím obsluhovat zvukový subsystém hry, spouštět a ukončovat synchronizovaně samply, nastavovat jim hlasitost, ovládat thread hudby atp. Herní engine Quadraxu není zrovna jednoduchý,
protože možných interakcí mezi objekty jsou tisíce. Na těch patnáct milisekund je toho celkem dost...
Vzhledem k tomu, že hra poběží pod D3D9, musím se naučit s tímto systémem pracovat - což znamená naučit se pár věcí, jak se správně D3D9 obsluhuje, jaké jsou jeho limity, a hlavně využít všech možností
optimalizace pro moderní 3D grafické karty. Také je důležité zajistit, aby hra byla kompatibilní s co možná nejširším spektrem PC a jejich grafik, což u D3D není zcela triviální a samozřejmé.
(Což každý hráč moderních her zná - občas se stane, že hra prostě neběhá tak, jak by měla. ;-))
Takže držte palce, ať vývoj Quadraxu X probíhá bezproblémově, a ať je jeho kompatibilata a stabilita minimálně taková, jakou měly předchozí díly, které byly schopné fungovat od Win95 až po Win8...
© 2000-2015 
|
