Marbles: Počátek

Projekt snů bych měl. Teda, jako, vím co to bude. A taky vím, jak rychle to udělám. Nezabere mi to víc jak dva týdny, je to přece úplně primitivní hra a navíc je všude plno tutoriálů. Plán je jasný, v práci si beru dovolenou a za 14 dní ze mě bude hrdý sólo vývojář s vlastním počinem na Google Play. Na tom se nic nemůže pokazit, ne?

Ano, opravdu jsem si v práci vzal na dva týdny dovolenou a opravdu jsem věřil, že to za tu chvilku musím stihnout. Hra to přece bude jednoduchá. Hráč bude mít za úkol ovládat kuličku po úzké dráze, ze které nesmí vypadnout. Cílem bude jen dojet co nejdál. Navíc jsem se rozhodl, že budu řešit hlavně programování a např. UI prvky nakoupím z Unity Asset Store. Hudbu taky vyřeším nákupem, nebo uprosím nějakého kamaráda. Snadný jako facka!

Game design document? Pche, na co.

Pokud si někdy přečtete něco o managementu herních projektů, nejspíš narazíte na doporučení si na začátku udělat tzv. Game Design Document (GDD). Ten má sloužit jako jediné místo pravdy. Jsou v něm popsány všechny rozhodující myšlenky určující váš projekt. Co vaše hra bude, jak bude vypadat, kdo je cílovka, použité technologie. A taky třeba, kdy to bude hotovo. Jen tak pro zajímavost, takhle v roce 1994 vypadal GDD pro původní Diablo.

Nooo, tuhle část jsem tak trochu přeskočil. Jednak jsem si řekl, že 14 denní projekt, jehož cílem je učit se nové věci, to úplně nevyžaduje. Nemám s tím zkušenosti a nejspíš bych tím zabil hromadu času. Navíc jsem se rozhodl si svoje nápady k projektu zapsat jinak. A to formou myšlenkové mapy. To mi totiž vyhovuje víc a přijde mi to zábavnější.

Co se týče samotných myšlenkových map, tak jsem postupně vyzkoušel několik nástrojů. U každého mi něco vadilo. Nakonec jsem skončil u aplikace Coggle, která mi tak nějak vyhovovala. Poslední dobou ale zvažuju, že bych na podobné věci zkusil něco jiného. Možná FigJam, Miro, nebo něco podobného.

Hlavní myšlenky jsem si tedy zapsal. V hlavě už se mi rodily akční scény jak po nocích programuju logiku hry, skládám dohromady UI a za 14 dní odpaluju šampáňo. V podstatě už jsem měl hotovo. Už to chybělo jen udělat. Takže stačilo jen pustit Unity, založit nový projekt a … hej, počkat!

Verzovat, či neverzovat? To je otázka.

Všude se říká: "Na začátku nic neřešte, prostě se do toho pusťte". Tak se dělají startupy. Tak se rozjíždějí úspěšné agilní projekty. Tak se hýbe světem. I přesto byly dvě věci, které jsem chtěl mít podchycené hned od začátku.

Ta první byl verzovací systém (VCS, Version Control System). A chtěl jsem jej mít nastavený hned od začátku, abych mohl vyvíjet bez strachu, že něco podělám. Nebo o něco přijdu. Taky protože jsem chtěl mít zaznamenanou celou historii změn. A taky protože to dnes považuji za nutnost u jakéhokoliv softwarového projektu, který autor myslí vážně.

Otázkou tedy nebylo, jestli verzovací systém použít, ale jaký. Já měl v tomhle od začátku jasno. Git. Ano, vím že to není nejlepší volba pro verzování binárních souborů. Ano, četl jsem různé články shrnující důvody, proč se tomuto VCS obloukem vyhnout v případě vývoje her. Ano, vím že i přímo Unity má svoje Unity Version Control (dříve PlasticSCM). Přesto to ale pro mně byla nejlepší volba.

Nejlepší to pro mně bylo, protože jej znám už drahně let a používám jej v podstatě denně. Vím, co od něj můžu čekat a jak řešit případné problémy. A v téhle fázi jsem se rozhodl naučit vyvíjet hry, ne používat nový verzovací systém.

Ze stejných důvodů jsem se rozhodl pro GitLab jako úložiště Git repozitářů. Opět jej znám už značnou dobu a od začátku mi byl sympatičtější než např. GitHub. Také jej denně používám v práci a na jiné projekty. A v téhle fázi projektu jsem měl i jasnou představu, jak si chci nastavit pracovní workflow a že mi GitLab poslouží i na rozplánování potřebných kroků, kterými chci dorazit k cíli. Krásně mi k tomu poslouží jeho Issues, Milestones a skoro výchozí Issue Board. Jako bonus využiju jeho Snippets ke sdílení částí kódů zde na webu.

Protože ale nejsem masochista, nechtěl jsem řešit ovládání Gitu z příkazové řádky. Hledal jsem tedy nějakého GUI klienta, který by mi tu práci trochu zpříjemnil. Zároveň jsem nechtěl využívat Git rozhraní ve Visual Studiu, protože mi přišlo otravné startovat IDE pro commit změn udělaných např. v Blenderu. Hledal jsem tedy nějakou malou appku, ideálně zdarma. Ze začátku jsem skončil u Gitahead, ale po nějaké době mi začaly některé věc vadit. Taky byl ukončen jeho vývoj, takže jsem v průběhu času začal hledat náhradu. Nakonec jsem skončil u desktopového klienta GitHubu. Toho používám spokojeně dodnes.

Testovat, či netestovat? ... ehm?!

Takže, verzovací systém bych měl. Založil jsem nový projekt v Gitlabu, stáhl k sobě kopii repozitáře a nainstaloval do něj nový Unity projekt. A hurá do vývoje! Teď už mě nic nemohlo zastavit!

No, né tak úplně. Byla tu přece ještě jedna věc, kterou jsem se rozhodl udělat hned na začátku, než se pustím do psaní kódů. A to, nastavit si testovací prostředí. Další věc, o které se v tutoriálech moc nemluví. Aspoň dokud nehledáte ty zaměřené na testování. Ano, vím že v začátcích si člověk rád řekne, že testování dořeší později. Ale podle mě bylo lepší to vyřešit hned na začátku. Protože kdybych netestoval, tak by to bylo jako psát to v JavaScriptu. Mohl bych jen doufat, že to dělá co jsem chtěl.

Taky bych mohl ze začátku všechno testovat ručně. A asi bych se i radoval z každé povedené věci. Ale já už dříve zjistil, že je pro mě více uspokojující dívat se na průběh automatických testů, než něco tisíckrát dokola proklikávat stejným způsobem.

Aby to testování ale opravdu k něčemu bylo, tak bylo potřeba jej trochu automatizovat. Abych testy nemusel pouštět pokaždé ručně. Protože jedna věc je nastavit si testy v Unity, ale druhá věc je zajistit, abych na ně nezapomněl. Reálně jsem je od začátku pouštěl, a stále pouštím, i ručně než pošlu změny do Gitu. Ale automatizace je dobrá pojistka. Taková bezpečností brzda ve vlaku.

Gitlab CI/CD

A naštěstí, to bylo něco, co jsem vůbec nemusel vymýšlet. Protože to už někdo vymyslel přede mnou. Ostatně jako většinu věcí. Rozhodl jsem se k tomu využít komunitního projektu GameCI zaměřeného přesně na tyto věci. GameCI poskytuje nastavení pro GitLab k automatizaci testů a buildu her na různé platformy.

Nastavení a první spuštění vyžadovalo nějaké kroky přímo v GitLabu. Asi aby to nebylo moc jednoduché. Po získání licence Unity (ano, i verze zdarma má licenci) a jejím zadání do GitLabu, už ale všechno fungovalo krásně a působilo jen radost. Navíc, celý proces byl dobře popsaný v dokumentaci.

Nicméně, po nakonfigurování jsem udělal ještě další drobné změny. V .gitattributes jsem si hlavně zkontroloval, abych všechny soubory související s grafikou, multimédii apod. ukládal do Git Large File Storage (LFS). Na zdrojáky je totiž Git super. Na obrázky už tak moc ne. Dále jsem si upravil .gitignore, aby odpovídal struktuře mého projektu. A taky abych neukládal do repozitáře zbytečné soubory, např. záložní soubory Blenderu.

Kromě toho, a toto hlavně, jsem si upravil nastavení pro GitLab CI pipeliny. Zde jsem si dovolil udělat větší změnu proti originálu. Smazal jsem všechny části související s buildem na různé platformy. V téhle fázi jsem potřeboval jen automaticky pouštět testy při každém pushi do GitLabu. Nic víc, nic míň. A proto jsem tam nic jiného nenechal a doplním to tam, až na to přijde řada. Můj .gitlab-ci.yaml tedy vypadal takto:

Unity Test Framework

GitLab jsem tedy měl nakonfigurován. Jenže neměl co spouštět. Zatím! Dalším krokem tedy bylo nastavení testů přímo v Unity. Mezi balíčky jsem tedy aktivoval Test Framework a pustil se do toho.

Projekt jsem měl zatím ve výchozím stavu, takže jsem napřed udělal čistku všech nepotřebných souborů. Založil jsem novou scénu a pojmenoval ji Tests. Následně jsem si založil strukturu složek pro testy. Ve složce Assets jsem tedy vytvořil novou složku Tests. V té jsem následně vytvořil další dvě složky pro testy, ale tentokrát jsem je zakládal pomocí volby Create -> Testing -> Tests Assembly folder z kontextové nabídky. Ty jsem pojmenoval EditMode a PlayMode.

Složky odpovídají dvěma druhům testů, které lze v Unity Test Frameworku spustit. Pokud bych měl tyto dva druhy testů přirovnat k běžně známé testovací pyramidě, tak bych Edit Mode testy dal na úroveň unit testů. Play Mode testy bych pak přirovnal k těm integračním.

Tím, že jsem složky vytvářel pomocí kontextové volby Tests Assembly folder jsem docílil toho, že se mi ve složkách rovnou vytvořily i tzv. Assembly definice. To je vám tuze náramná věc. Ve výchozím stavu, jsou v Unity projektu všechny skripty v jedné velké hromadě. Assembly definice umožňují tuto hromadu dělit na menší části, chcete-li hromádky.

To má pak svoje výhody, jako např. že když upravíte nějaký skript, tak se nemusí překompilovat úplně všechny ostatní skripty. Ale jen ty ve stejné hromádce. Při každém updatu to pak může snížit dopad změn. Má to samozřejmě i své nevýhody, jako např. že skripty v jedné hromádce nevědí automaticky o skriptech v jiných hromádkách. S tím si ale bude muset poradit mé budoucí já.

Hotovo. Jakože to úvodní nastavení.

Tím jsem měl, prozatím, nachystáno! Projekt byl založen. Ty nejdůležitější věci jsem měl nastaveny. Když jsem poslal změny do GitLabu, tak mi ukazoval úspěšný průchod testy. Samozřejmě, protože tam ještě reálně žádné testy nebyly. Ale to nevadí! Všechno fungovalo jak jsem zamýšlel. Zbytek už bude brnkačka. Plácal jsem se po ramenou, jako když jsem před 28 lety vybil první patro podzemí pod katedrálou v Tristamu. Radost jako mistr světa, netušíc že tam někde dole je Butcher.

Zatím to zabralo jen chvilku, zhruba 4 hoďky, a všechno šlo podle plánu. Před sebou jsem měl pořád 14 dní volna a skálopevně věřil, že se to všechno snadno povede. Commity jsem tedy zamergoval do hlavní větve a pustil se do vývoje. Založil první prototyp hráče, začal psát první skripty, vytvořil první game objekty, prefaby atd. O tom se ale více rozepíšu zase někdy příště.

A co vy, jaké byly vaše úvodní kroky u prvního projektu? A jaké by byly dnes? Děláte game design dokumenty, nebo jsou vám bližší mind mapy? Verzujete a testujete od začátku? Dovedli byste fungovat bez toho? A jaké k tomu všemu používáte nástroje? Klidně se rozepište do komentářů k článku na sockách, rád tam o tom pokecám.