Co jsem se naučil

Obsah

Programování

Petr – Gemtree (Pokud bych dnes začínal, daleko více a důsledněji bych plánoval)

Každý nějak začínal a každý se musel od něčeho odpíchnout. Já jsem začínal na vizuálním programovacím nástroji Petr od společnosti Gemtree.


Pokud jste v programování naprostí zelenáči, ale vidíte v něm určitý hlubší smysl, rozhodně se vyplatí dát tomuto vizuálnímu nástroji šanci. Přestože se čistě jen s ním asi nedostanete mezi programátorskou elitu, rozhodně má smysl věnovat čas a úsilí naučit se s tímto nástrojem pracovat.

S programováním v tomto nástroji jsem začal ve svých 10ti letech na Vánoce v roce 1999, kdy jsem dostal CDčko s vizuálem, který vidíte tady na obrázcích, pod stromeček. Začal jsem tvořit metodou pokus omyl a stejně jako mnozí jiní, si dnes nedokážu absolutně představit, jak jsem u toho mohl se svým tehdejším přístupem vydržet. Možná proto se vyplácí začít co nejdříve, když jsme ještě děti.

Většinu tajů o programování, které jsem se v Petříkovi naučil, jsem objevil sám, ale tu úplně základní podstatu mi naštěstí vysvětlil můj táta, který prý kvůli tomu musel dost změnit alespoň dočasně způsob nahlížení na programování, jelikož on začínal s Assemblerem a svého nejvyššího skillu dosáhl v Pascalu. Vysvětlil mi, jak fungují větvicí příkazy (ve většině programovacích jazyků známé jako if a while) a taky, jak funguje přiřazování hodnot do proměnných a výrazy. Pokud bych to vzal hodně zjednodušeně, toto bylo vlastně všechno, co jsem potřeboval vědět a všechno ostatní jsem mohl vyzkoumat v tom nepřeberném množství dostupných příkazů jak pro řízení programu, tak i řízení sprajtů, vykreslování grafiky a později i 3D grafiky.

Pokusů vytvořit nějaké hry jsem absolvoval spoustu. Bohužel, vyšel mi jen jeden, kdy se mi podařilo udělat něco, co by se už při troše dobré vůle dalo nazvat hrou. Ta hra se jmenovala Friends, bohužel, přestože si úplně přesně pamatuji téměř každý detail z ní, nemám ji již k dispozici, protože skončila na některém z mých bývalých počítačů v některém ekodvoře. Pokud byste si chtěli udělat představu o tom, jak ta hra asi vypadala, tak se můžete podívat na Berušky od Anakreonu a představit si jakýsi hybrid mezi jedničkou a dvojkou. Byla ve 3D, ale byla jen na jedné vrstvě a měla v podstatě všechny logické prvky z jedničky kromě barevných klíčů.

Uvědomoval jsem si, že samotná znalost programování nestačí. Je třeba mít také cit pro grafiku a vidět, co je skryté.

Pokud bych dneska s tímto programovacím nástrojem znovu začínal a věděl, co vím nyní, hlavní rozdíl v přístupu, který bych měl, že bych si všechno daleko důsledněji plánoval, což by se projevilo především tak, že bych pravděpodobně tvořil daleko menší bloky kódu a snažil se mít jednotný standard (zásadně neříkám coding-standard, protože tady se o něco takového bohatě postaral vizuál) v nazývání proměnných a funkcí a také v předávání dat, protože můj největší kámen úrazu byl především v tom, že jsem dělal všechno bez řádného zamyšlení a přestože jsem si tam často natahal spousty příkazů, které třeba i fungovaly, tak jsem často ztratil niť a třeba druhý den jsem už nevěděl, co jsem dělal včera a absolutně se mi nechtělo pokračovat v něčem, co mi v ten okamžik přestalo dávat smysl. To se mi už naštěstí po těch letech podařilo náležitě zmapovat a vyvinout si techniky, díky kterým tento problém ustoupil na pozadí a už na něj téměř nenarážím.

PHP

Slýchal jsem to často a odmítal jsem si to přiznat, že vizuální drag&drop programování není zrovna zářná budoucnost, zvlášť, pokud bych se chtěl programováním živit. Výjimečně můžu říct, že mi v něčem velmi užitečném do života pomohla škola.


V deváté třídě na základní škole jsme se začali učit základy PHP a já jsem konečně opustil právě onu vizuální klikačku a začal jsem se s obrovským nadšením věnovat tvorbě dynamických webových stránek. Dokonce to bylo ještě předtím, než jsem vůbec tušil, že existuje nějaký free webhosting. Pořád jsem poslouchal, jak je provozování internetových stránek velice drahé (ona i pětistovka měsíčně pro mě tehdy byla téměř likvidační). Každopádně, náš pan učitel, který jako jediný z celého akademického personálu zřejmě věděl o počítačích i něco více než jen, jak se otevírá Word a Excel a jeho znalosti nebyly omezené na osnovu, kterou by si přečetl před hodinou, mě naučil základní princip, jak vlastně PHP funguje a že se tedy jedná o preprocesor, který upravuje zdrojový kód, co se posílá klientovi, když si chce zobrazit stránku. Proto tedy dynamické stránky.

Já jsem tehdy začal neskutečným způsobem hltat internetové stránky JakNaWeb.com (pozn. nejednalo se o JakPsatWeb.cz, ty jsem objevil až později). Bylo tam obrovské množství (alespoň na tehdejší dobu obrovské) tutoriálů, jak něco vytvořit v PHP a já jsem to všechno okamžitě zkoušel. Brzy jsem si vytyčil velký projekt, vytvořit něco jako BlueBoard.cz (tehdy na tom webu byla možnost vytvářet si interaktivní prvky jako ankety, komentáře, počítadla atd., které si mohl uživatel na svůj web vložit). Pro úplnost, nebyl to úplně můj nápad, podnět mi k tomu dal jiný tvůrce, který právě dělal něco podobného a pak jsme se kvůli tomu i trochu pohádali, protože mě (částečně oprávněně) nařkl z plagiátorství.

Tehdy jsem si poprvé náležitě uvědomil, co to znamená provozovat on-line aplikaci a jaké noční můry při laxním přístupu k práci způsobují neodhalené bugy a celkově řádně neotestovaná aplikace. A to jsem ještě neměl ani tušení, co přijde v budoucnu.

Tento svůj projekt jsem pojmenoval nejprve EagleBoard a když mi začali vyhrožovat, že zneužívám ochrannou známku přejmenoval jsem ho na FalconBoard (podotýkám, že to nemá nic společného ani s lodí Millenium Falcon ani s raketami Falcon od SpaceX, jelikož ani jedno jsem v té době neznal, psal se rok 2004). Nejprve jsem se pokusil obejít bez MySQL databáze, protože se mi úplně nechtělo se ji učit, tak jsem vše ukládal do souborů, které jsem generoval. Nebyl to ale žádný JSON. To je pro slečinky. Já jsem generoval živý PHP kód, který obsahoval hodnoty proměnných, a následně jsem jej pomocí příkazu include vkládal do stránky s editačním formulářem a také s výsledným interaktivním elementem. (takovou bezpečnostní díru nevymysleli ani v Microsoftu)

FalconBoard se mi podařilo dotáhnout do MVP a dokonce jeden můj spolužák, který si v té době taky dělal svoje webové stránky, jej použil. Fungovalo to dost bídně a já jsem nesmírně žářlil na konkurenci, ke které potom spolužák přešel.

HTML+CSS

Možná si říkáte, že je trochu zvláštní, že jsem se učil nejdříve PHP a teprve potom HTML. Ono to tak ale v podstatě bylo, protože HTML jsem sice znal, ale v době, kdy jsem se začal učit PHP, jsem v něm uměl jenom nadpisy a odkazy a třeba taková validace mi byla naprosto cizí.


Ve škole jsme se začali s několika spolužáky předhánět v tom, kdo má lepší webové stránky a já jsem rozhodně nechtěl zůstat pozadu. Jeden spolužák nás však všechny trumfnul způsobem, který jsem dlouho nechápal, dokud mi o pár let později nedošlo, že mě zmátla terminologie. On totiž prohlásil, že pro layout stránek nepoužívá tabulky ale pouze CSSka. Tak jsem si říkal. Tehdy jsem si to vyložil, že vůbec nepoužívá HTML elementy ale pouze texty. Když jsem jednou procházel stránky JakPsatWeb.cz, tak se mi podařilo najít ukázku, jak se používají div a span elementy, tak se mi podařilo jakousi takousi replikaci jeho stylu, ale stejně jsem to nechápal. On argumentoval tím, že pokud prohlížeč nepodporuje tabulky, tak se stránka strukturovaná pomocí tabulky vůbec nezobrazí. Pokud prohlížeč nepodporuje CSS, tak se na stránce zobrazí jen holý text, což je pořád lepší, protože uživatel něco uvidí. No, byl to v té době velký problém, když se nezávisle na sobě ve velkých korporacích vyvíjely tři různé prohlížeče (Internet Explorer, Netscape Navigator a Mozilla Firefox, každý se snažil uzdmout si co největší část uživatelské základny a každý zobrazoval identický kód úplně jinak. Já opravdu děkuji Bohu za to, že tento problém je už dneska naprosto minoritní a standardní elementy a styly podporují všechny prohlížeče stejně (a to je jich dneska víc).

Konec deváté třídy, kterou jsem mimochodem korunoval obrovským úspěchem, že jsem tehdy vytvořil prezentaci na téma tvorba internetových stránek (ve Flashi) a odprezentoval ji způsobem, nad kterým všem zůstával rozum stát, „Jak mohl ten plachý chlapec s rozvinutou sociální fóbií tak úžasně mluvit?“. Ano, když něčemu rozumím a žiju tím, dokážu o tom velmi pěkně mluvit, což je velký kontrast oproti tomu, když se pohybuji v oblastech nebo situacích, které jsou mi nepříjemné.

Nechtěl jsem se spokojit s málem a rozhodl se rovnou porazit tehdejšího leadera ve světě webových her, WebGame.cz.

Rovnou říkám, nepodařilo se mi to. Je mi však velice líto, že dnes už tato hra není v módě, protože je to nejen nostalgie ohledně zážitků, které jsem s ní měl, ale přes značné obavy ze závislosti na neustálém kontrolování, zda se nestalo něco nového, je to naprostá banalita oproti dnešním sociálním sítím, kde se navíc velmi často nehraje fér a používají se těžké podpásovky. O tom ale až někdy jindy.

Můj první pokus byla hra, která se jmenovala prostě a jednoduše That's life. Když se dříve zmíněný spolužák díval na její UI, tak se smíchem poznamenal: „Tyjo, zatím je kolem nás dostatek neobydlené půdy, takže nemusíme válčit. Kde já jsem už tohle viděl?“ Ano. Kopíroval jsem svůj vzor až příliš. Neuvědomoval jsem si však dvě velice důležité věci. Moje programátorské schopnosti, ač jsem ovládal všechny techniky potřebné k vytvoření takové hry, zdaleka pro takový cíl nestačily. Neuvědomoval jsem si, že je zapotřebí víc než jenom naťukat nějaké uživatelské rozhranní a k tomu nějaké zpracování formulářů. Je potřeba naučit se nad tím strategicky uvažovat, což je takový trochu až abstraktní pojem a je poměrně nesdělitelný pro někoho, kdo toto strategické uvažování nemá.

Skutečně nevím, co bych poradil svému mladšímu já, pokud bych chtěl zpětně svůj vývoj a krystalizaci nějak urychlit. Zkušenosti, především ty špatné, ze kterých máme možnost se poučit, jsou zkrátka nesdělitelné. Člověk si je musí zažít.

Druhý pokus, který jsem dotáhl do jakési fáze realizace byla hra s názvem Arrakis Life, která měla být kombinace WebGame a Duny Online. Konkrétní detaily návrhu, které jsme tehdy dali dohromady, si již přesně nepamatuji. Vím jen, že jsem si pro tuto hru vytvořil pozadí v Terragenu, kde byl žlutý kopec. Vzpomínám si, že jsme se bavili o tom, že můj návrh je velmi nevyvážený, protože pokud by se proti stíhačkám bránily všechny pozemní jednotky, tak šance na úspěšný útok je velice nízká, protože je-li základem mít vyváženou armádu, neletecké jednotky oproti těm leteckým budou vždy převažovat. A pak jsme se ještě pohádali, že databáze MySQL je opravdu jediná správná cesta a ukládání dat do souborů je nebezpečná zhýralost. Zpětně si připadám jak převlékač kabátů, protože jsem MySQL taky dlouho bojkotoval, jak jsem uvedl dříve.

JavaScript

Přestože jsem nedokončil ani jednu vysokou školu, nemůžu říct, že by studium na nich bylo zcela zbytečné. Přestože jsem tušil, že to asi nedám a do výuky jsem chodil s krajním odporem, nějaké věci se ke mně přece jen dostaly a jsem za ně rád.


JavaScript pro mě byl několik let noční můra, protože několik prvních skriptů mi nefungovalo a nebyl jsem absolutně schopen přijít na to proč. Vždy mi s tím musel někdo poradit a já jsem nechápal, jakto, že to ostatním funguje a mně ne. Potom ale nastala zásadní změna, kdy pan profesor na VŠ začal mluvit o anonymních funkcích. Přibližně ve stejnou dobu jsem se dozvěděl o lambda výrazech, které pro mě byly tehdy ještě naprostá španělská vesnice a nechápal jsem jejich význam. Jakmile jsem se ale dozvěděl o anonymních funkcích v JavaScriptu, začalo mi to být najednou jasné. A současně s tím jsem se dozvěděl a hlavně pochopil systém vnoření, které vyřešilo několik mých problémů, se kterými jsem se do té doby v JS potýkal.

To úplně nejdůležitější, co jsem se ale naučil, byla knihovna JQuery, která je sice již z dnešního pohledu zastaralá a rozhodně bych ji nikomu nedoporučil používat, protože se bez ní spolehlivě obejdeme, ale v té době to pro mě byla revoluce. Najednou jsem nemusel řešit takové antipattern věci jako this.parent.parent.parent.getElementsByClassName("label")[0].innerHTML.... Prakticky všechno se dalo zařídit naprosto elegantně a v kódu jsem se neztrácel. Teda přesněji, neztrácel jsem se v něm tak brzo jako dřív.

A s těmito technologickými dovednostmi se mi podařilo získat svoji první zakázku. Jestli můžu někomu něco doporučit, nikdy neobchodujte s příbuznými a s kamarády. Všichni známe přísloví v nouzi poznáš přítele, ale neméně důležité je, že dobré účty dělají dobré přátele. To druhé zde bylo těžce porušené a stálo mě to málem blázinec. A to si nedělám legraci.

Jeden kamarád (dnes již bývalý) mě oslovil, že by chtěl udělat informační systém pro svoji firmu, která se zabývá řízením týmu obchodníků. (Řekněme si to narovinu, jednalo se o MLM.) Já jsem s nadšením souhlasil a věřil jsem, že po patnácti letech všelijakých pokusů a učení se konečně bude moje práce užitečná i zaplacená. Na obojí jsem si musel ještě několik let počkat, ale bez tohoto kroku by to pravděpodobně nenastalo.

Ač jsou vzpomínky na tuto dobu jedny z nejhorších v mém životě, dokonale se tu prokázalo, že „co tě nezabije, to tě posílí“.

Vrhnul jsem se do realizace s obrovským nadšením doslova po hlavě. Po měsíci implementace se mi podařilo dotáhnout jakž takž použitelnou první funkční verzi systému včetně nařezané grafiky od designera. Jenže, v aplikaci byla obrovská spousta chyb, o kterých jsem ani netušil, že můžou nastat. Dnes už legenda, o které mluvím často, byl tam formulář pro vyhodnocení výsledku schůzky s potenciálním klientem. Hodnocení mělo být na stupnici od jedné do desíti, na což tam bylo deset radioboxů. Jenže ony ten výsledek ukládaly špatně. Nejdřív jsem si myslel, že to ti uživatelé prostě špatně vyplnili a odmítal jsem se tím zabývat. Potom ale začaly chodit výsledky schůzky s hodnotou 11, 12 a více. To už se obhájit nedalo. Tak jsem se do toho kódu podíval, tehdy s nesnesitelným odporem, protože jsem se tím již zabývat nechtěl, a zjistil jsem, že do toho hodnocení se ukládá ve skutečnosti ID klienta. To byl ten můj slavný mysql_fetch_row, který jsem potom sdílel na HovnoKod.cz. Počet takových stupidních chyb, které se mi podařilo během vývoje udělat, šel do stovek, já jsem se potácel téměř na hranici šílenství a když jsem uviděl v helpdesku nový požadavek, připadal měl jsem pocit jako kdyby mě přišli zatknout a odvést do vězení.

Nette

Byl nejvyšší čas si uvědomit, že aplikace se prostě mají dělit do více částí a nemá se míchat logika frontendu a backendu a i ty by se měly dělit na příjem a posílání dat a na jejich zpracování.


Zadavatel toho informačního systému se mě zeptal, jestli je práce na něm opravdu tak neudržitelná, jak vypadám já. Řekl jsem mu, že skutečně nevím, jak to dál spravovat, když je to totální chaos. Tak se mě zeptal, jestli znám nějaký jiný způsob, jak to vytvářet. Řekl jsem mu, že na VŠ nám říkali o frameworku Nette, tak se mě zeptal, jestli bych ho k nemohl použít pro lepší tvorbu. Dohodli jsme se, že to zkusím. Mě se opět zmocnilo nadšení a začal jsem aplikaci implementovat v Nette. No, implementovat. Začal jsem přepisovat jednotlivé funkce do metod jednoho obřího objektu. Opět bez rozmyslu a nějakého reálného plánu. Nemá asi smysl to dál protahovat a řeknu rovnou, že za chvíli jsem na tom byl úplně stejně jako předtím. Framework jsem všelijak ohýbal, protože jsem nepochopil podstatu mnoha jeho funkcí. Například zpracování formulářů byla kapitola sama o sobě.

Připadalo mi, že jediný způsob, jak aplikaci spravit, je napsat ji celou odznova. Jenže to u tak rozsáhlé už prostě nebylo možné.

Tedy tento informační systém se dočkal celkem tří funkčních verzí z celkem šesti rozpracovaných. Jestli jsem se během těch tří let práce, za kterou jsem ani nedostal zaplaceno, něco naučil, tak jsou to dvě věci. První jsem tady už dříve zmiňoval, že je třeba mít skutečně naplánovaný a ustanovený systém práce, abych byl nejen schopen udržet si v aplikaci pořádek, ale také, aby byla aplikace škálovatelná. Pravděpodobně neexistuje jakákoli aplikace, která by sloužila k evidenci nebo prodeji čehokoli, aby ji nebylo potřeba v průběhu provozu měnit nebo rozšiřovat. A ta druhá věc je, že je třeba na vše mít sepsanou smlouvu a trvat na jejím dodržení z obou stran. A nebavíme se tady o rámcové smlouvě o díle ale doslova o kontraktech s platbou za úkon. Právníci přece taky nedostávají paušál za celý soudní případ. Účtují si za úkony. Já jsem sice stále o dost levnější než běžný právník (věřte, že s tím mám zkušenosti), ale dlouhou dobu jsem mimo jiné díky této „spolupráci“ záviděl „astronomické“ platy uklízečkám.

Doufal jsem a naštěstí se to ukázalo jako dobré, že když jsem si takto vylámal zuby na svém prvním reálně používaném projektu, tak by mě mohl někdo zaměstnat za nějakých lepších podmínek. To se mi naštěstí podařilo, i když to stále nebylo ono. Našel jsem si práci na pozici, která sice nesla název programátor ale s platem kodéra, který neměl možnost dělat jakákoli rozhodnutí, ale nesl jsem zodpovědnost za finální funkčnost projektů. Ty mi byly postupně přidělené čtyři. První dva byly e-shopy, které byly postavené na identické šabloně a dokonce jsem byl svědkem hromadného kopírování funkčního kódu z jednoho projektu do druhého, který se pak pouze napojil na jinou databázi se stejnou strukturou a jinými daty. Samozřejmě, neobešlo se to bez problémů a chyb, které jsme řešili, jako například, proč se nám v e-shopu přidalo do košíku s domácími žárovkami grilovací koření. Odpověď je obecně jednoduchá. Neklonujte projekty, protože nikdy nevíte, jakou záludnost si přenesete z jednoho do druhého. To je skoro horší než malware.

Vue

Toužil jsem tvořit weby, které by vypadaly opravdu dobře a taky by dobře fungovaly. Kolega mi dal tip zkusit VueJS. Dlouhou dobu předtím i potom jsem zažil v životě takovou euforii jako když jsem si vyzkoušel Vue na jsfiddle.net. Sice jsem to s tím nadšením přehnal, když jsem prohlásil, že tohle řeší všechny moje problémy, ale byl to opravdu obrovský skok vpřed.


Okamžitě jsem chtěl všechny svoje projekty dělat ve Vue. Snad nikdy v mém životě se neprojevilo výrazněji přísloví Nekřič hop, dokud nepřeskočíš. Velmi důležitou, i když ne nezbytnou, součástí práce ve Vue je buildovací nástroj. Chtěl jsem použít Webpack. Ten však měl jednu zásadní slabinu, která se projevila v naprosto absurdní situaci. Zahájil jsem práci na projektu ve Vue a zadavatel rozhodl, že na projektu budeme pracovat dva, přičemž druhý kolega byl především grafik a HTML kód většinou kopíroval z ukázkových souborů na Githubu nebo jinde po internetu. Budiž mu prominuto, jako grafik a návrhář byl na jedničku a toto si ani on sám nepřál. Problém však byl v tom, že on začal do toho projektu míchat další technologie, které jsem tam už nechtěl, například zmíněné JQuery a korunu tomu nasadil ve chvíli, kdy začal upravovat WebPackem vygenerovaný zdroják, protože ten, který jsem mu poslal na úpravy, údajně nefungoval. Nefungoval proto, že on neměl kompilátor.

Krušný přechod na SPA aplikace, které jsou dnes tak elegantní a spolehlivé, měl ještě jednu zásadní vadu na kráse. Když jsem začal přepracovávat do Vue dříve zmíněný informační systém pro obchodníky, narazil jsem na problém, že všechna data se musela předávat skrze velice košatý strom vnořených komponent. Tehdy jsem ještě netušil, že existuje něco jako store a že by bylo rozhodně dobré jej použít.

Tuto práci jsem nakonec vzdal a svému v tu chvíli již bývalému kamarádovi jsem řekl, že na mě tři roky parazitoval, že nikdy nedodržel, co on mi slíbil (a že toho bylo, od plateb, přes společné s. r. o. až po připojení se do kruhu milionářů), že jeho způsob zadávání práce byl srovnatelný s šikanou, byl schopný se mi ozvat ve tři hodiny v noci, že něco nefunguje a když jsem mu ve čtyři hodiny volal, že jsem chybu neobjevil, telefon mi nebral a o dva dny později se mě ptal, jestli jsem to spravil. A taky že mě neskutečně štvalo jeho permanentní projevování bohorovnosti. Nakonec jsem řekl: „Jako chápu, že jsem se nezachoval vždy úplně nejlíp, ale...“ On se podíval na svoje nové Rolexky a řekl: „Takže... 43 minut ti trvalo, než jsi uznal svoji vlastní chybu...“ Odešel jsem tehdy z toho setkání a před očima jsem měl totálně prázdno a vlastně jsem ani nevěděl, co mám dělat dál, protože de facto jsem v tu chvíli vyšel z vězení, na které jsem si tak trochu zvykl (Stockholmský syndrom) a nevěděl jsem, co dělat na svobodě. Naštěstí jsem se vzpamatoval a začal jsem pracovat pro někoho normálnějšího. Jak jsem říkal, jestli skutečně platí, co tě nezabije, to tě posílí, možná právě tohle bylo potřeba, abych se dostal tam, kde jsem nyní.

React (Už se mi nechce psát kód ručně, potřebuji generátor)

Přestože jsem Vue uměl již poměrně dobře a dodnes s ním rád pracuji, přecejen jsem vnímal, že potřebuji dohnat mainstream a naučit se pracovat s technologiemi, které používají velcí hráči. A nejen to. Naučil jsem se, že co lze automatizovat, to chci automatizovat.


Můj první tutoriál na výuku ReactJS, který jsem zhlédl, bylo čiré utrpení. Potom, co jsem znal Vue, mi přišlo nadmíru absurdní vkládat elementy přímo do kódu. Připomnělo mi to tu moji improvizaci, co jsem sdílel na HovnoKod.cz. Říkal jsem si ale, že to nevzdám, protože to je přece moje budoucnost a nechci ji zahodit. Druhý problém, který nastal, že jsem nechápal, proč mi to nefunguje a dát dohromady funkční stack mi ze začátku připadalo jako nadlidský úkol. To už mám naštěstí za sebou a npx to jistí.

Co mě ale znervóznilo o hodně víc, že jsem stále ještě neměl best practice ohledně data store. Nejprve jsem to chtěl řešit pomocí globální proměnné, což je ta největší blbost, to opravdu nikdy nedělejte. Potom se mi podařilo objevit knihovnu Redux, což v té době byly React + Redux téměř nerozlučná dvojice. Systém ukládání dat pomocí Reduxu se mi podařilo celkem pochopit. Tam jsem až takový problém s učením neměl. Co mi ale dělalo mnohem větší starost, že mi připadalo, že musím psát neustále dokola obrovské množství kódu, nemůžu dát CTRL+C, CTRL+V a je to strašně neefektivní. Dnes už vím, že to je systém kontroly v jednotlivých fázích zpracování uživatelských požadavků a každá jedna část má na starosti bezproblémový tok a případně konverzi oběma směry dat.

Díky tomu, že mi React + Redux připadaly tak předimenzované, ale přesto jsem se rozhodl vytvořit v nich poměrně rozsáhlý projekt (ze kterého ale nakonec stejně sešlo), jsem začal vymýšlet, jak si to zjednodušit. Základní myšlenka, kterou jsem nosil v hlavě dlouho, byla, že mnoho struktur a zápisů se v kódu opakuje, ale není možné je jen tak kopírovat. A to byla moje prvotní myšlenka na vytvoření Automatizovaného programovacího systému (APS).

Co takhle, kdybych ty zdrojáky generoval a sám zapisoval přímo pouze změny v těchto souborech?

Problémem byla datová struktura. Předpokládal jsem, že bude hodně velká a nepůjde dělit. První, co mě napadlo, byl JSON. Ten je jednoduchý, umím s ním pracovat a lze neomezeně strukturovat. Můj první pokus generovat kód podle šablon společně s vloženými daty, nebyl úplně špatný, ale pro uspokojivý výsledek to nestačilo, protože jsem neměl skutečnou kontrolu nad tím, jestli jsem něco nezapomněl. Tento zdroják totiž nekontroloval smysluplnost.

Druhý pokus jsem uskutečnil s dříve podceňovaným, ale v tu chvíli, jak se ukázalo, velice zajímavým a užitečným XML. To bylo možné také téměř nekonečně strukturovat a současně se mi dařilo velmi udržovat si v mnou napsaném kódu určitý přehled. Narazil jsem však na problém, že ani sebelepší návrh nemusí vždy stačit a je možné požadovat něco netypického. To bylo ve skutečnosti v této podobě jednodušší, než by se na první pohled zdálo. Jelikož tyto soubory se generují na pokyn v šabloně, ale současně se na ně na jiných místech šablony odkazuje, proč to neudělat tak, že dotyčný soubor se generovat nebude? To bylo jednoduché a svérazné řešení. Kontrolu, zda se generují všechny požadované soubory, jsem neprováděl, protože jsem věděl, že pokud by nějaký chyběl, projeví se to ve výsledné aplikaci prakticky okamžitě, takže není třeba se touto otázkou zabývat. No a pak jednoduše specifický soubor napíšu ručně. Na tom nevidím nic špatného, protože moje iniciativa a snaha přemýšlet nad podobou jednoho specifického souboru byla stále vysoko nad sepisováním mnoha téměř identických souborů.

I z datových struktur v XML však nakonec sešlo a já jsem už zoufale hledal nějaký další způsob. Vyzkoušel jsem ještě YAML, ale ten dopadl obdobně, to ani nemá smysl nějak zvlášť rozepisovat. Co jsem ale ještě vyzkoušel, bylo vytváření stromové struktury v programu SimpleMind. Tento program má jednu úžasnou výhodu, že stromovou strukturu dokáže exportovat jako textový soubor a jednotlivé uzly seřadí přesně podle pořadí ve vizuálu a jednotlivé úrovně vyznačí tabelátorem. Díky tomu nebyl téměř žádný problém výsledný text rozprarsovat a vygenerovat dané zdrojáky podle hodnot jednotlivých uzlů i jejich pozic v myšlenkové mapě.

Takto se mi podařilo například naprogramovat celou jednu aplikaci téměř čistě na mobilu během procházky v lese. Tím jsem chtěl právě vyzkoušet, jaký extrém dokáže tento systém zvládnout. Já totiž obecně velmi nerad sedím v kanceláři na jednom místě několik hodin v kuse. Moje produktivita tak velmi brzy klesá pod neúnosnou hranici. Proto jsem hledal způsob, jak pracovat na mobilu. Tento systém však stále neměl plnou kontrolu nad smysluplností datové struktury a současně jsem taky nemohl testovat, zda jsem neudělal nějakou chybu, což byla zase škoda. Chtěl jsem si ten generátor předělat, aby fungoval online a nejlépe, aby se gitoval. K tomu jsem se nakonec nedostal, protože jsem zažil syndrom vyhoření a nechtěl jsem v jednu chvíli o další práci programátora ani slyšet.

Potřeboval jsem přijít na jiné myšlenky, tak jsem dočasně přešel na práci kurýra a vozil jsem jídlo. Přestože to byla práce často velmi nepohodlná a nezřídka dost nudná, dokázal jsem si vyčistit hlavu a přišel jsem s novým, v té chvíli již ultimátním nápadem. Já nebudu používat datovou strukturu ale rovnou samotné příkazy pro generování. Zdroják budu psát v PHP a použiji fluid režim. Ten mi umožní nejen navazovat jedním příkazem na druhý, ale IDE mi umožní také specifikovat, jaké další kroky následují. Problém s kontrolou smysluplnosti byl tím pádem vyřešen. Ale kompletně celý systém jsem v tu chvíli ještě zmáknutý neměl. Potřeboval jsem se naučit správně přemýšlet nad tvorbou generátoru, který by smysluplně pokrýval celý problém. To jsem vyřešil pomocí čtyřvrstvého datového modelu.

  1. Šablony – Každý typ souboru, a ve většině projektů jich bylo přibližně pět typů, měl přesně danou strukturu. Třída měla svoje metody, atributy a předka, komponenta měla svůj obsah a vnořené komponenty atd. Vytvořil jsem si soubory .latte, které zcela jasně vyžadovaly hodnoty, které jsem měl pomocí vyšší vrstvy dodávat.
  2. Data – Pole nebo objekt obsahující hodnoty, které šablona požaduje. Nebyly nějak rozsáhlé a ke každému typu souboru se ukládaly zvlášť. Díky jsem se zbavil rozsáhlých špagety kódů definujících kompletní strukturu aplikace bez kontroly smysluplnosti.
  3. Integrace – Nad touto vrstvou jsem si lámal hlavu nejvíce, než jsem si uvědomil jeden úplně základní princip. Tvrdím-li, že se data v jednotlivých zdrojácích často opakují, a nelze je prostě okopírovat, musí tam být změny, které se současně projevují ve více souborech najednou. A to byl klíč k řešení problému. Začal jsem si tvořit metody, které generovaly jednotlivé hodnoty do šablon s důrazem na to, abych jakékoli dvě různé hodnoty stejného významu musel zapsat pouze jednou a ony se potom propsaly do jednotlivých zdrojáků v neměnné podobě. Díky tomu globálně odpadl problém s překlepy v názvech proměnných a funkcí.
  4. Struktura – Když jsem měl tedy propojené generování jednotlivých dat tak, aby zůstala propojená, bylo potřeba tohle všechno zastřešit, abych mohl psát zdroják pro generování aplikace tak, aby byl skutečně smysluplný. Vytvořil jsem si proto velkou soustavu PHP tříd, kde každá znamenala de facto inteligentní uzel ve stromové struktuře a současně obsahovala metody, které v této struktuře mohly následovat jako další uzly, přičemž každá metoda vrátila objekt třídy, která obsahovala opět další metody použitelné v dalším kroku. Asi nejlépe to uvidíte na příkladném příkazu.
$template->element('button')
         ->label('Vytvořit rezervaci')
         ->onClick('postBooking', 'booking.data')
         ->post('/booking', 'booking', 'BookingService', 'insert');

Pokud bych tento příkaz použil samostatně, tak by vygeneroval přibližně následující zdrojáky.

Template.jsx

export default () => (<button onClick="() => postBooking(this.state.booking.data)">Vytvořit rezervaci</button>)

postBooking.js

export default (booking) => axios.post('/booking', booking)

routes.php

$app->post('/booking', function($request, $response) => {
    return $response->withJson($this->bookingService->insert($request->data));
});

BookingService.php

Ten jsem si napsal sám. Většinou jsem použil Pure SQL.

Celé je to samozřejmě zjednodušené. Jednak si to už přesně nepamatuji a taky to nemám jak otestovat, abych měl jistotu, že jsem skutečně na nic nezapomněl. Můžete ale vidět, že tyto čtyři řádky byly schopné vytvořit komplexní funkcionalitu, která spolu souvisí a současně zůstat velmi přehledné, což vedlo k tomu, že jsem mohl mít všechno podstatné na jednom místě a změny bylo možné provádět velmi snadno.

A proč tento systém nepoužívám?

Ty důvody jsou ve skutečnosti dva. Ten první zjevný byl, že přišel ChatGPT, který v podstatě dokáže tohle všechno lépe, bez potřeby dalšího programování a ještě se v tom zlepšuje. Já sám v Brně uprostřed Evropy s jedním notebookem prostě neporazím tým několika desítek nebo i stovek špičkových programátorů v Sillicon Valley. A druhý důvod, proč jsem od tohoto systému upustil, byl ten, že jsem si konečně po mnoha letech uvědomil, že je nakonec přece jen nadbytečný. Nějaké generování šablon se určitě hodí, ale to hlavní, co jsem postrádal a co jsem se snažil získat tímto systémem, byl přehled nad aplikací. V současné době pracuji tak, že používám program SimpleMind, do kterého si zapisuji názvy komponent do struktury entity aplikace, na které se odkazují. Nemám potom problém dotrackovat, když potřebuji něco přidat, změnit nebo opravit.

Za sebe můžu zcela zodpovědně prohlásit, že přes všechna ta úskalí, nebo možná spíš právě díky nim jsem se do dnešních dní dostal na úroveň, kdy se můžu skutečně označit za programátora analytika a nikoli programátora kodéra a této schopnosti analyticky a také strategicky uvažovat, si nesmírně cením.

Herní enginy

Gamemaker

Bylo pro mě docela hořké zjištění, že pro tvorbu her není nezbytný jen programátorský skill ale také skill grafický. I obyčejná textová adventura musí vypadat dobře, jinak má pramalou šanci na úspěch.


Když jsem se v době, kdy jsem byl plně ponořený do tvorby v Petříkovi, začal zajímat i o jiné možnosti tvorby her, velmi rychle mi přišel do ruky Gamemaker. V rychlosti jsem porovnal jeho možnosti a přišel mi naprosto primitivní a jednoúčelový, protože se v něm z mého prvního pohledu daly vytvářet jen asi čtyři typy her. Klikačky typu legendárního Capture the Clown, plošinovky, které však v Petříkovi byly daleko složitější, což jsem uvítal, potom střílečky v pohledu shora a nějaké další, viděl jsem třeba izometrické bludiště. V tomto jsem se pravda nejen mýlil ale současně tyto uvedené typy pokrývají poměrně širokou škálu nejrůznějších her, z nichž spousta z nich mohou být velmi dobré.

Nějaké pokusy jsem v něm uskutečnil, ale nic z toho nebylo ani na ukázku, natož na reálnou publikaci. Teprve po mnoha letech, v roce 2024 jsem se rozhodl, že dám GameMakeru opět šanci se hrou, která bude vycházet z možností, o kterých vím, že v GameMakeru jsou možné a jsou i již vnitřně implementované. Současně s tím jsem byl připravený, že si sám vytvořím grafiku v profesionálním nástroji a způsobem, kde mě nikdo nemůže obvinit z plagiátorství ani jiného kopírování. Prostě jsem si ji nakreslil kompletně sám v Kritě (viz níže).

Žádný engine není všelék, i když ho dokonale ovládáte. Ani žádné AI nedokáže splnit příkaz typu: „Vytvoř dobrou hru.“ Dobrou hru musíte vymyslet a naplánovat do posledního detailu.

Dnes vím, že GameMaker je zkrátka téměř univerzální herní engine určený pro 2D hry. 3D jsem v něm nezkoušel a ani nemám tu potřebu, jelikož pro 3D hry jsou tu jiné daleko propracovanější enginy. Představoval však jeden z mých zásadních milníků v kariéře Indian vývojáře, jelikož právě v něm se mi podařilo publikovat svoji první hru, kterou jsem opravdu dotáhl do konce.

Unity

Přestože Unity nemá poslední dobou dobrou reputaci a hráči i tvůrci na něj ukazují prstem, u mě má nesmazatelnou zásluhu v oblasti tvorby her. Byl to totiž první engine, ve kterém se mi podařilo v dospělém věku vytvořit aplikaci, která vypadala skutečně jako hra, přestože jsem ji nedokončil.


Nesl jsem si to s sebou dlouhou řadu let jako nikdy nezahojenou jizvu z mládí. Potom, co mi přestal fungovat Petřík, protože jsem dostal nový počítač a licenční disketa byla vadná, nemohl jsem již dál tvořit hry, které jsem chtěl a to mě strašně bolelo. Opravdu jsem potom nesmírně toužil, ale neviděl jsem žádnou alternativu. GameMaker byl sice zdarma, ale ten v té době moje požadavky nesplňoval. Dlouho jsem si myslel, že tvorba her je otázkou jednak softwaru za desítky až stovky tisíc a především hardwaru, který bych ani v běžném obchodě nesehnal a rovněž by stál obrovské jmění. Někdy v roce 2018, kdy vyšlo Kingdom Come Deliverance, jsem viděl nějaké let's playe a zůstal jsem v němém úžasu, jak nádherná hra to je. Nedalo mi to a zkusil jsem tu nejjednodušší věc, co v danou chvíli šla, šel jsem na Google a vyhledal jsem tam (tuším) "tvorba počítačových her". Vyjelo mi několik odkazů a pak mi to došlo. Pro tvorbu her se v dnešní době používají enginy. Ve skutečnosti je nesmysl používat samotné knihovny OpenGL a jim podobné, jak jsme se to učili ve škole.

Okamžitě jsem šel na Youtube a tam si vyjel nějaké tutoriály na Unity. Hned se mi na něm ale jedna věc nelíbila. V jednom tutoriálu autor předváděl, jak úplně základní herní koncept FPS včetně překážek, jak udělat, aby se ruka pistolníka neotáčela přesně s kamerou ale s drobným zpožděním a nakonec, jak udělat něco jako cut scénu. Bylo to takové jednoduché, ale strašně se mi nelíbilo, že jsem viděl, že autor používá v podstatě jenom hotové knihovny funkcionalit.

Myslel jsem si, že každá funkcionalita hry je tak strašně složitá, že je potřeba na ni obsáhlá knihovna a současně, že když budu cokoli potřebova udělat třeba jenom trošku jinak, tak mám smůlu, protože jakýmkoli zásahem do jakékoli knihovny bych všechno rozbil.

Chtěl jsem si vyzkoušet alespoň tady tento základ, ale postavil se mi do cesty málo výkonný hardware. Tedy, málo výkonný... ano, měl jsem MacBook pro, který jsem používal na programování webových stránek a celkově on-line aplikací. Unity jsem v něm sice rozjel, ale všechno bylo strašně pomalé a sekalo se to. Nebylo to poprvé ani naposledy, kdy jsem těžce litoval, že jsem byl takový egoista a „strašně nutně“ jsem potřeboval notebook s jablkem. Už ho nemám a další si rozhodně koupit neplánuji.

Když jsem si potom pořídil nový počítač, na kterém jsem si konečně mohl zahrát Kingdom Come, u kterého jsem pak strávil zhruba týden téměř nepřetržitě, řekl jsem si, že zkusím i to Unity. Fungovalo výborně i plynule a nepadalo. Na základě podobného tutoriálu jsem vytvořil jednoduchou FPC běhačku, kde bylo možné šoupat bednami ale ne ve stylu Sokobana, zcela volně. Když jsem ale chtěl nějakou bednu jakoby vzít do ruky, nevěděl jsem, jak to udělám a opět jsem to vzdal, protože jsem si stále myslel, že je to strašně složité a musel bych kvůli tomu provádět obrovskou řadu výpočtů, které by nemusely být úplně spolehlivé. V Petříkovi to tak totiž bylo. Pozice kamery, úhel natočení, na základě toho 3D přímka výhledu, dále rozsah, ve kterém se bude sledovat, jestli je v cestě nějaký objekt a pokud ano, je třeba to nějak zaregistrovat, aby bylo možné reagovat na kliknutí. Tohle všechno se mi honilo v hlavě, když jsem přemýšlel, jak to udělat. Netušil jsem, že Unity, i když mě to mohlo napadnout, už má tohle všechno vyřešené a funguje to spolehlivě.

Pár měsíců jsem v hlavě nosil nápad na hru, která by byla podobná GTAčku s tím, že by to bylo malé město, zamýšlel jsem i, že by to byla část reálného města, které mám velice rád a hráč by tam byl v roli běžného občana, který bude mít co do činění s mafií. Jak originální... Čemu jsem ale věnoval zvláštní pozornost, bylo řízení auta. To jsem chtěl udělat jiné, než je klasika. Plyn a brzda na tři klávesy, čímž by se ovlivňovala síla sešlápnutí pedálu, volantem by se točilo pomocí myši a pomocí malíčku by se sešlapávala spojka, což by samozřejmě byla mechanika navíc, kterou by bylo potřeba zmáknout. A současně by tam byl atribut „driving skill“, který by určoval, jak plynule postava hráče ty pedály mačká, což by mělo za následek různou plynulost jízdy. K tomuto konceptu jsem došel potom, co jsem slyšel Daniela Vávru mluvit o tom, jak detailně navrhoval auta do Mafie. To vše bylo v době, kdy jsem ještě netušil, zda je vůbec pro mě jako pro běžného smrtelníka vůbec možné tvořit hry.

Pak jsem si ale jednou řekl, že na to prostě přijdu, i kdyby mě to mělo stát týden googlení. Ve skutečnosti to byly ani ne dva dny.

Na podzim 2022, kdy jsem opět začal přemýšlet nad tím, jak by se to dalo udělat a strašně mě odrazovala představa, že je všechno strašně náročné a je k tomu potřeba obrovského talentu a specializace, jsem si řekl, že těch her je dneska tolik, že to přece nemůžou produkovat jenom AAA studia. Tak jsem se rozhodl, že se pokusím naučit vytvářet hry v Unity tím způsobem, že postahuji všechny assety, přečtu si důkladně, co s nimi autoři zamýšleli a dám z toho dohromady něco smysluplného.

Tak jsem odpoledne přišel z práce a začal jsem vyhledávat, jak se tvoří do Unity postavy, které vypadají jako lidé a jestli existuje nějaký způsob, jak jim dodat animační pohyb, aniž bych musel použít Motion capture nebo je animovat ručně pomocí klíčových snímků. Objevil jsem aplikaci Character creator, kterou jsem si i přes její cenu velmi rychle zakoupil. Pro animace jsem objevil server Mixamo.com. Chvíli jsem tápal a stále se mi do hlavy vkrádala myšlenka, že přece tyto dvě aplikace nejsou kompatibilní a stejně nepůjdou propojit.

V momentě, kdy jsem uviděl, jak mi na obrazovce pochoduje postavička, kterou jsem sám vytvořil, všechny moje obavy vzaly za své a dopamin mi vystřelil do výšky jako snad nikdy v životě.

Viděl jsem, že to vlastně není tak těžké a začal jsem s vytřeštěnýma očima hledat, co dalšího se dá v tom Unity dělat. Postavu jsem rozpohyboval, aby reagovala na WASD klávesy a potom také, aby nastoupila do auta, když k němu přijde. Sice to všechno glitchovalo jak o život, ale já jsem věřil tomu, že to už je potřeba jen doladit. Záhy mi však začalo vadit, že je jen málo volně dostupných assetů, které by za něco stály, tak jsem si začal tvořit vlastní. Už jsem věděl, jak fungují, tak se z toho stal můj nový koníček.

Začal jsem tvořit hru Kossai, která vycházela z toho mého nápadu popsaného výše. Je paradoxní, že zatímco jsem si užíval tvorbu vlastních assetů, jízdu autem jsem z této hry vyškrtnul, protože jsem si říkal, že na auta je to město moc malé. Nebylo inspirováno žádným existujícím městem, bylo to v podstatě poskládané trochu jako v SimCity. Hru jsem nedokončil, ale její koncept mám na stole stále a ten čeká na svoji realizaci, o které věřím, že jednou opravdu nastane.

Unreal Engine 5

Musel jsem najít sílu zahodit projekt, na kterém jsem pracoval několik měsíců a začít odznova a lépe, protože jsem narazil na skleněný strop. S příslibem daleko lepší grafiky za cenu úplně nového konceptu práce jsem se rozhodl přejít na Unreal Engine 5.


Postavy z Character creatoru se v Unity značně deformovaly, teda především jejich textury. Zkusil jsem si, jestli by se v Unreal Engine 4 vykreslovaly lépe. Výsledek mě potěšil i zklamal zároveň. Potěšilo mě, že se vykreslila skutečně pěkně beze ztráty kvality, zklamalo mě, že tohle Unity nedává a že budu muset přejít na Unreal. Dost mě šokovalo, že koncept Unrealu je dost odlišný od Unity. Kolegovi, který moji práci průběžně sledoval, jsem řekl: „V Unity se věší skripty na objekty, v Unrealu se věší objekty na skripty.“ To bylo moje shrnutí prvních dojmů z Unrealu.

Můj druhý dojem byl naprosto fenomenální světelné efekty. V editačním režimu jsem pohyboval Sluncem (ještěže mě za to zlatá rybka neposlala do lahve od octa) a nemohl jsem se nabažit těch nádherných barev, které dopadaly na budovu, kterou jsem si vymodeloval v Blenderu (viz níže). S obrovským nadšením jsem se vrhl do tvorby hry, u které jsem si nasadil takovou nevyřčenou laťku, že chci, aby byla lepší než Hobo: Tough life, což je hra, která se mi velice líbila, ale měla zjevné nedostatky, což je škoda.

Proplétal jsem všelijak ty nesčetné blueprinty a bylo pro mě obrovským uspokojením vidět, když něco skutečně funguje tak, jak jsem zamýšlel. Bohužel se mi nepodařilo nainstalovat si Unreal v modifikaci, abych mohl tvořit a používat i samotný kód C++, což jsem chtěl, protože vůči drag&drop konceptu mám dost zásadní výhrady, přestože jsem na něm vyrostl. Používal jsem animace z Mixamo.com nejen pro chůzi ale také běhání, tancování, jedna moje postava se modlila a jiná zase upadla po ráně pěstí. Dialogy jsem chtěl nejprve řešit pomocí titulků, které by se objevovaly nad hlavou postavy. Později jsem ale zjistil, že existují AI nástroje pro konverzi hlasu, jsem proto připravený dát do hry i dabing. A konečně, objevil jsem cenově dostupné řešení Motion capture, díky kterému jsem se do hry rozhodl dát i cut scény.

S tímto vybavením a znalostmi jsem zjistil, že mi skutečně nic nebrání, vyrobit všechny hry, které mám v plánu a jejichž nápady si již dokonce řadu let hýčkám v mysli a v srdci. Jediné, co k tomu potřebuji a co mi nikdo jen tak nedá, je čas. Věřím ale, že i toho se mi dostane a nakonec vše zvládnu.

Přesto jsem se však v létě 2024 rozhodl vyzkoušet ještě jednu zásadní změnu. Během jednoho rozhovoru s Danielem Vávrou padlo, že Unreal sice vykresluje nádherné scenerie, které jsou ale pro hru nepoužitelné, protože požadují extrémní výpočetní výkon. Naopak vyzdvihl CRY engine a jeho zásadní výhodu oproti Unrealu, že zvládá daleko lépe složitou a detailní 3D grafiku za cenu složitější implementace a vzdání se některých věcí, které jsou v Unrealu samozřejmostí, například LOD. Já jsem se však rozhodl tuto možnost vyzkoušet. Zatím jsem neuskutečnil...

Grafika

Blender

Už v době, kdy jsem programoval v Petříkovi, jsem chtěl dělat 3D grafiku. Nesmírně mě okouzlily hry 13 duchů a Turbo Cars od Miroslava Němečka. Tehdy jsem však nejen, že neuměl udělat nic pořádně, ale neměl jsem ani k dispozici nějaký rozumný software.


V roce 2004 mi jeden spolužák přihrál na DVDčku dva pro mě zcela zásadní programy. Adobe After Effects a 3D studio Max. V obou jsem se začal velmi intenzivně učit pracovat a k mému údivu mi obojí šlo na tu dobu překvapivě dobře. Tyto dva programy plus film Star Wars Epizoda 3 - Nebezpečně nebezpečné nebezpečí, což byla unikátní parodie, která byla vydána ještě předtím než vyšla premiéra originálu, pro mě byly podněty k tomu, že jsem začal filmovat. Programovat hry jsem v té době nemohl, protože Petříka jsem již neměl a jiné způsoby tvorby her jsem neznal. Videa mi ale začala docela jít. Natočil jsem několik filmů, jejichž úroveň byla dílo od díla lepší, přestože dnes bych se pod ně nejspíše nepodepsal. Určité střípky z těchto videí jsou stále aktuální. Tato videa dodnes naleznete na Vimeo.com.

Koupil jsem si, nebo spíš moje máma mi tehdy koupila Berušky II od Anakreonu, o kterých jsem se tady už zmiňoval. Tato hra byla skvělá, až na jednu věc, byla zabugovaná. Já jsem si vyměnil pár e-mailů s tvůrci. Příčinu chyby se nám zjistit nepodařilo, ale jen ze zvědavosti jsem se zeptal, v čem tu hru tvořili. Odpověď byla Microsoft Visual C++ a Blender. Chtěl jsem si Blender vyzkoušet, protože byl (a dodnes je) zcela zdarma a tak skvělá hra jako Berušky, pokud ji udělali v Blenderu, tak bych neměl zůstat pozadu. Dostal jsem však těžkou ránu mezi oči. Připadal jsem si jako kdyby letitému tvůrci ve Photoshopu předhodili GIMP. Zkoušel jsem, co se v tom dá dělat. Něco málo se mi i podařilo, ale pořád to bylo těžce pod úrovní toho, co jsem dokázal v 3Ds MAX. Nevím, zda to bylo možné už tehdy, ale jednu věc jsem udělal opravdu špatně, že jsem si více nepozjišťoval, co a jak v Blenderu opravdu funguje. Třeba jsem byl naprosto zoufalý v tom, že jsou na kouli vidět polygony, přestože v 3D studiu se ta koule jevila jako dokonale hladká, přestože těch polygonů nebylo potřeba zdaleka tolik. Dnes už vím, že to byla otázka jednoho přepínače, pouze nevím, zda tam byl už tehdy nebo ho doplnili až později.

Říkal jsem si, že to prostě nemůže být tak neprůstřelné, jak se to v tu chvíli zdálo, tak jsem si zaplatil kurz na Udemy.com.

Tento kurz nebyl vůbec špatný a asi nebude od věci, když si ho znovu projdu, protože autor je rozhodně profíkem. Bohužel se mi však ani po tomto kurzu nepodařilo práci v Blenderu uchopit na použitelné úrovni. Dnes už vím, že důvodem nebyly chybějící skills ale chybějící plán postupu a nápady.

V době, kdy jsem začínal aktivně tvořit v Unity a kdy jsem psal, jak mi dopamin vystřelil jako nikdy v životě, jsem si uvědomil, že tvorba assetů, především 3D modelů se v tuto chvíli jeví jako zásadní. Rozhodl jsem se proto dát Blenderu ještě šanci. K mému překvapení jsem objevil video, které můj pohled na něj zcela změnilo. V tom videu bylo ukázáno, jak tvořit v Blenderu domečky skoro tak jednoduše jako v The Sims. Prostě táhnout zdi pomocí Extrude nejlépe po jednom metru. Já jsem to tak udělal a ve svojí prozíravosti jsem udělal navíc to, že pokud nějaká zeď měla končit v rohu, udělal jsem vytažení pouze o 90 cm a pak ještě navíc o 10 cm, přičemž následující vytažení bylo v pravém úhlu. Můj první domeček byl samozřejmě úplně strašný. Zdi byly tři metry vysoké, což by nevadilo, ale vchod neměl horní rám a když jsem chtěl přidat patro, vůbec jsem nemyslel na to, kde by měly být schody. Uvědomil jsem si však, že záleží skutečně na každém polygonu, což se mi s přibývající praxí stále znovu a znovu potvrzuje, přestože se pohybuji již v tisících až desítkách tisíc polygonů.

Vymodeloval jsem si jeden malý domeček s jedním obývacím pokojem a koupelnou. Ten jsem potom v Unity nakopíroval asi padesátkrát do dvou čtvrtí, ve kterých se měla odehrávat moje hra. Přemýšlel jsem, jak ty domečky vybavím. Stahovat nábytek z internetu se mi nechtělo, tak jsem si zajel do Ikea Showroomu v Brně, kde jsem si nafotil každou židličku, každý stůl i každý stojánek na tužky, který se mi nějak zalíbil s tím, že si je vymodeluji. Několik týdnů následně se mi dařilo vymodelovat třeba tři až čtyři kusy nábytku denně, na což jsem byl náležitě hrdý a strašně mě to bavilo. Potom ale nastal obrovský šok. Ten nábytek se do toho domu nevešel, protože měl špatně navržené rozměry, které nebyly kompatibilní. A násilným škálováním bych ztratil proporce, které jsem měl připravené pro užívání nábytku lidmi.

Byl jsem z toho v šoku, ale nechtěl jsem to vzdát, tak jsem si řekl, že se teda pokusím vymodelovat si nějaké jiné domy, které již budou rozměrově odpovídat. Nechtělo se mi ale dělat jen tak nějaké. Najednou se mě zmocnila potřeba vytvářet krásné věci.

Několik dní jsem spekuloval nad tím, co bych tak mohl zkusit a procházel jsem i různá města v ČR přes street view. A pak jsem na to kápnul. Zajedu si do Jihlavy, tam jsou moc pěkné domečky, které si nafotím a vymodeluji. Už ani nevím, jak mě to přesně napadlo, protože do té doby jsem tam znal je Bránu matky Boží, ale možná jsem chtěl taky udělat jakousi nepsanou radost Dušanovi Majerovi, kterého již léta sleduji na Stream.cz i dnes na FamePlay.tv.

Do Jihlavy jsem se vydal. Ten den bylo zataženo a trochu i mlha, ale doufal jsem, že můj celkový záměr to nezkazí. Když jsem vystoupil z auta na Náměstí T.G. Masaryka. myslel jsem, že mi upadnou prsty na rukou, jaká byla zima, se kterou jsem nepočítal. To se naštěstí po nějaké chvíli srovnalo a já jsem začal fotit domy v Benešově ulici. Ani jsem do té doby netušil, že Muzeum Vysočiny Jihlava je právě tam. Nafotil jsem si asi 20 domečků, které jsem pak následně začal modelovat. Hodně jsem se ale zamýšlel nad otázkou, jaký je vlastně rozdíl mezi gotikou a renesancí. Trošku jsem si zapátral na internetu a nalezl jsem z těch několika zdrojů stručnou odpověď: Gotika je zaměřená na Boha, renesance je zaměřená na člověka. A tehdy jsem si řekl: “Právě tento vnitřní konflikt ve mně nyní probíhá. To je neuvěřitelně příhodné.„ Skutečnost je taková, že asi ne kvůli tomuto výletu, ale díky této otázce jsem se právě v té době dal na cestu víry a stal se křesťanem. Na tohle téma bych také dokázal mluvit hodiny a hodiny, ale to není předmětem tohoto už tak dlouhého článku. Když jsem se vrátil zpátky domů, začal jsem opět modelovat. První, co jsem si vzal na paškál, byl úřad, který můžete vidět na jednom z těchto obrázků. Schválně jej srovnejte s originálem. Jak jsem byl zvyklý vytvářet tři modely denně, tento mi trval zhruba tři dny a začínal jsem již být netrpělivý, že to trvá strašně dlouho, ale rozhodně toho nelituji. Výsledek mě naprosto ohromil. A všechny další domečky jsem chtěl dělat tímto stylem, na čemž trvám dodneška.

S ohledem na to, že jsem se dal na cestu víry, byl pro mě zcela přirozený krok zakomponovat ji i do her. Využil jsem toho, že se považuji za člověka, který se dokáže hodně vžít do myšlenek a pocitů druhých lidí a taky jsem věděl, jaký byl můj život víry předtím, téměř bych řekl křižácký. Zcela logický následující krok byl umístit do hry nějaký kostel. Přemýšlel jsem, jaký bych tam mohl dát a napadl mě jeden, se kterým mám výjimečnou zkušenost. Dřevěný kostelík v Blansku. Tam se vdávala moje sestra a takovou svatbu jsem snad nikdy předtím nezažil. Velmi jsme se u toho bavili a se sympatickým panem farářem byla velká legrace. Tak jsem se prostě a jednoduše vydal jeden den do Blanska, abych si kostelík nafotil a taky změřil. K tomu jsem si pořídil odměřovací kolečko. Výsledek posuďte sami. Modelování mi trvalo zhruba tři dny. A náměstí, na které jsem ve hře umístil kostelík, jsem pojmenoval po onom faráři, který oddával moji sestru. Bohužel, tento design dokument jsem nakonec skartoval a tato hra bude úplně jiná. Tento kostelík tam však bude, jen na úplně jiném místě.

Jednou jsem se takto vydal na výlet s tím, že si prostě odpočinu. Jel jsem do Ostravy. Chtěl jsem si prohlédnout důl Petr Bezruč, ten, který má nad krásnou kovanou branou nápis Petr, něco červenýho, Bezruč. Důl jsem viděl, ale po cestě jsem natrefil na něco, co mě doslova okouzlilo. Slezskoostravská radnice, která byla v mých očích doslova a do písmene uměleckým dílem. Jakmile jsem ji viděl, okamžitě jsem věděl, že takovou stavbu chci do hry také. Udělal jsem si pár fotek a co jsem nezachytil, s tím mi pomohl Google maps a Google Street View. Výsledek můžete vidět na obrázku. Jen není dokončená a pro finální verzi hry ji budu chtít vybavit i zevnitř.

A konečně, navštívil jsem Náměstí Zachariáše z Hradce v Telči, kompletně jsem si jej nafotil a změřil a začal jsem stavět domečky z něj. Část, kterou jsem zatím udělal, můžete rovněž vidět na obrázcích.

Vážení přátelé, co říci závěrem... že v modelování staveb jsem se docela našel. Mám v plánu vytvořit celé město, které by mělo být následně součástí hry Kossai. Návrh jsem již několikrát přepisoval a možná se to ještě v budoucnu několikrát stane, ale skutečně tuto hru chci vytvořit. Představuje totiž pro mě osobně ten úplně nejlepší způsob vyjádření mého vnitřního světa, který nosím v hlavě doslova od dětství a který bych chtěl předat ostatním.

Co se chci v budoucnu naučit

Krita a grafický tablet

Setkal jsem se v životě mnohokrát s názorem, že grafikou se tvůrci her snaží dohnat absenci mechanik a celkového smyslu. Není to pravda. Právě grafika dává hrám smysl. Ohání-li se někdo tím, že legendární Digger má mizernou grafiku a přesto je legendární, tak ne. Grafiku měl na tehdejší dobu minimálně nadprůměrnou a animace byly taky dost exkluzivní. A s absencí současných nástrojů to muselo borcům z Windmill software dát obrovskou práci.


Právě z výše uvedených důvodů jsem se rozhodl, že přestože jsem minimálně v Česku docela unikát, který propadal z výtvarné výchovy, musím zvládnout i kreslení na grafickém tabletu. V podstatě jsem si vymezil tři obecné cíle.

  1. UX design – tedy mřížkový návrh aplikace nebo webu
  2. Prostředí do hry – jelikož nechci žádné assety stahovat, chci si tvořit kompletní prostředí, jak menu tak u 2D her i kompletní grafiku ručně
  3. Umění – nesmírně obdivuji tvůrce, kteří dokážou nakreslit za pomocí několika čar obrázek, který vypadá dobře. To zatím neumím, ale chtěl bych se to naučit. Od toho se potom dá odpíchnout mnohem dál.

Koupil jsem si proto podruhé v životě grafický tablet. Ten první jsem kdysi dávno zamítl s tím, že se s ním absolutně nedá pracovat, protože nedokážu zkoordinovat ruku, když se na ni nedívám. Řekl jsem si, že tentokrát to zvládnu a zvládl jsem. Poměrně rychle jsem přestal vnímat rozdíl v pohledu na ruku a na monitor s obrázkem. Není to však ani v nejmenším všelék. Kreslení na grafickém tabletu vyžaduje trénink a pečlivost a v tom se chci rozhodně zlepšovat.

Svoji první hru Adventure Arkanoid, konkrétně její demoverzi jsem kompletně nakreslil v Kritě, a nejen to, nejsou tam téměř žádné multiplikované prvky. Všechno je nakreslené samostatně bez kopírování. Skutečně, každý kamínek je ruční práce. Sice pravda optimalizovaná, že to vždycky bylo na výběr masky, pár čmrknutí a další výběr, což jsem měl ještě zjednodušené pomocí klávesových zkratek, ale je to poctivá práce.

Fullscreen