Programování textových her v TADS 3, část 7. – Závěr

Tak jsme dorazili do finále. Dnes nezbývá než uzavřít posledních pár témat, říci si několik tipů k tvorbě příběhu a… a zveřejnit kompletní zdrojové kódy první plnohodnotné české textové hry v TADS 3. Doufám, že se postaráte, aby nebyla poslední!

Kompletujeme hru

Intro

V prvním článku jsme se vrhli do programování jen s minimální definicí objektů gameMain a versionInfo. Každá správná hra by měla začít intrem, a tak v prvním jmenovaném objektu vytvoříme metodu showIntro() a v ní zobrazíme pár řádek na úvod. Ale opravdu jen dva, tři kratší odstavce – doporučuji nezaměnit intro s románem na pokračování. Protože píšeme interaktivní fikci, měli bychom uvést hráče do příběhu interaktivně během první části hry (prologu) a intro samotné by mělo jen navodit situaci na začátku hry. Ve versionInfo můžeme kromě názvu a popisu hry zadat i mnoho dalších vlastností ohledně hry i autora a měli bychom také vytvořit metody showAbout() a showCredit(), které reagují na příkaz >o hře a >autor.

Většina hráčů, kteří budou naší hru chtít vyzkoušet, nebude mít s jejím ovládáním žádné zkušenosti. Měli bychom na naše hráče myslet a naprogramovat příkaz >nápověda (můžeme se o něm zmínit rovnou v intru), který jim např. nabídne možnosti, jak zažádat o pomoc:

DefineSystemAction(Help)
    execSystemAction()
    {
        "Více informací získáte kdykoliv napsáním jednoho z následujících
            příkazů na příkazové řádce:

            \b<<aHref('o hře', 'O HŘE')>> -- jak hra vznikla a stručně o jejím
            ovládání
            \n<<aHref('autor', 'AUTOR')>> -- kdo hru vytvořil a poděkování
            \n<<aHref('rady', 'RADY')>> -- vestavěné rady a nápovědy k příběhu
            \n<<aHref('návod', 'NÁVOD')>> -- podrobný návod, jak hrát
            interaktivní fikci ";
    }
;

VerbRule(Help)
    ('ukaž' | 'ukázat' | 'zobraz' | 'zobrazit' | ) ('pomoc' | 'nápověda'
    | 'nápovědu' | 'náp') | ('pomož' | 'napověz' | 'pomoct') ( | 'mi')
    | 'help' : HelpAction
    verbPhrase = 'ukázat/ukazu{ješ}/ukázal{a} nápovědu'
;

Obecný návod, jak hrát interaktivní fikci, je už v TADSu vestavěný a jak vytvořit rady se podíváme hned teď.

Rady k příběhu

Dávat dobré rady v textovkách je ošidné. Pokud vyzradíme příliš mnoho, může to zkazit všechnu zábavu, ale někdy zase může být zaseknutí hráče na jednom puzzlu tak frustrující, že už bude chtít naservírovat celé řešení na podnose. Systém rad v TADSu se snaží zachovat rovnováhu tím, že se hráč sám rozhodne, jak silnou radu chce získat.

Témata nápověd rozdělíme pomocí HintMenu do obecných oblastí hry a v nich připravíme seznam otázek, které představují jednotlivé problémy, na které se může hráč snažit přijít. V každé otázce připravíme sérii nápověd, které bude hra jednu po druhé odkrývat. První nápovědy by měly být velice vágní a obecné, obvykle neprozradí nic konkrétního. Každá další však bude postupně odkrývat čím dál tím více informací, až k té poslední, která zpravidla prozradí přesné řešení.

Aby se zabránilo příliš brzkému vyzrazení potenciálních zápletek, jsou jednotlivá témata aktivovaná až v momentě, kdy se k danému problému hráč dostane. K tomu slouží sada vlastností openWhen… a closeWhen…, mají několik variant a lze je i kombinovat. Základem je vlastnost openWhenTrue, do které přiřadíme jakýkoliv logicky ohodnotitelný výraz. Pokud je splněn, téma se zpřístupní. Zobrazení nápověd se často podmiňuje stavem hry zaznamenaným pomocí makra gReveal, o kterém jsme si říkali v předminulém článku. Místo openWhenTrue = gRevealed(‚název‚) můžeme napsat zkráceně openWhenRevealed = ‚název‚. Podobných zkratek je více, např. pokud nás zajímá, zda hráč už prozkoumal nějaký objekt, stačí použít openWhenDescribed = objekt. Všechny možnosti fungují i v opačné variantě, za všechny jmenujme closeWhenAchieved, které uzavře téma po splnění nějakého úkolu a přidělení bodů. A o tom hned v následující kapitole.

+ HintMenu 'Nehoda lodi';
++ Goal 'Jak mám zabránit srážce?'
    [
        'Co se to vlastně na lodi porouchalo? ',
        'Porouchala se automatická navigace a vede loď do srážky. Co ji zkusit
            vypnout? ',
        'Či přesněji řečeno, co zkusit vypnout autopilota? ',
        'Ovládání autopilota najdeš nejspíše v pilotní kabině. ',
        'Prohlédl sis dobře palubní desku? ',
        'Prozkoumal jsi tlačítka na palubní desce? ',
        'V kokpitu zadej příkaz STISKNI TLAČÍTKO AUTOPILOTA. '
    ]
    openWhenRevealed = 'hint-collision'
    closeWhenTrue = gRevealed('autopilot-frozen') || gRevealed('ship-landed')
;

++ Goal 'Jak to, že autopilot nejde vypnout?'
    [
        'Je nějaký zaseknutý, budeš muset najít jinou cestu. ',
        'Zkoušel ses dozvědět více informací o lodi, ve které letíš? ',
        'V takovýchto lodích bývají servisní manuály. ',
        'Hledal jsi důkladně? Hledej někde, kde by ho měl pilot při ruce. ',
        'Prozkoumal jsi v kokpitu palubní desku? ',
        'Ve štěrbině na palubní desce je zasunutý manuál. Zadej příkaz VEM
            MANUÁL a potom PŘEČTI MANUÁL. '
    ]
    openWhenRevealed = 'autopilot-frozen'
    closeWhenTrue = manual.moved
    closeWhenRevealed = 'ship-landed'
;

++ Goal 'Jak otevřu podlahový panel ve společenské místnosti?'
    [
        'Prozkoumal jsi ho důkladně? ',
        'Všiml sis otočných zámků? ',
        'Zkusil jsi je otočit? ',
        'Zadej příkaz OTOČ ZÁMKY nebo ODEMKNI ZÁMKY. '
    ]
    openWhenDescribed = lrFloor
    closeWhenAchieved = lrPanelLock.achievement
;

Bodování

Řešení puzzlů bylo od počátku žánru natolik neodmyslitelnou součástí textových adventur, že když se na počátku devadesátých let objevily příběhy interaktivní fikce zcela bez hlavolamů, založené jen na objevování příběhu, detailní scenérii a interakci s postavami, vyvolaly mírný šok. Dnes mají takové příběhy v žánru pevné místo a je jen na vás, kterým směrem se vydáte. Jestli si hlavolamy nedokážete odmyslet a smýšlíte o svém projektu především jako o hře, budete pravděpodobně chtít hráče odměňovat body za postup, za každý dosažený úspěch.

I když bychom se mohli spokojit s pouhým přičítáním bodů do proměnné, většina her dosažené úspěchy pojmenovává a na příkaz >detailní skóre vypíše přehledný rozpis, kolik bodů za jaký úspěch hráč dosáhl. Pro každý potenciální úspěch vytvoříme objekt Achievement a prostřednictvím šablony zadáme počet bodů a popisek. Jakmile hráč metu dosáhne, zavoláme na objektu metodu awardPointsOnce(). Metoda zaručuje, že přidělíme body jen jednou, kdyby hráč v ukázce níže součástky z modulu zase vyndal a pak znovu vložil, už se přidělení bodů nezopakuje. Přesto pokud bychom chtěli u některého úspěchu přidělovat body opakovaně, můžeme místo toho zavolat metodu awardPoints(), která kontrolu vynechává. V tom případě by bylo vhodné nastavit vlastnost maxPoints, aby bylo jasné, kolik bodů může hráč na daném úspěchu získat. TADS totiž automaticky počítá a ukazuje maximální skóre.

fixedComponents: PresentLater, Thing
    'původ opravené nové náhradní zesilovače součástky/součástka/díl/díly/
        VIZ-54/VIZ54/VIZ/pouzdra' 'opravené součástky' *3
    "Jsou to tři výkonové integrované zesilovače VIZ-54 v keramicko-kovových
        pouzdrech s otvorem na přišroubování k chladiči. Všechny vypadají nově a
        hezky se lesknou. "

    dobjFor(AttachTo) asDobjFor(PutIn)
    dobjFor(PutIn)
    {
        action()
        {
            if(gIobj == secondModule) achievement.awardPointsOnce();
        }
    }
    achievement: Achievement { +1 "opravení modulu" }

    isPlural = true
    gcName = 'opravených součástek, opraveným součástkám, opravené součástky,
        opravevných součástkách, opravenými součástkami'
    gcVocab = 'opravených opraveným opravenými nových novým novými náhradních
        náhradním náhradními zesilovačů zesilovačům zesilovačích zesilovači
        součástek/součástkám/součástkách/součástkami/součástce/součástku/
        součástkou/dílu/dílem/dílů/dílům/dílech/pouzder/pouzdrům/pouzdrech/
        pouzdry'
;

Konec hry

V celém seriálu jsme ještě ani jednou nezabili hráče, pojďme to napravit :-) Hru ukončíte příkazem finishGameMsg, který zobrazí hlášku a nabídne menu konce hry. Např. finishGameMsg(ftDeath, [finishOptionUndo]) První parametr určuje hlášku oznamující konec, místo ftDeath můžeme použít ftFailure, ftGameOver a konečně i ftVictory nebo můžeme zadat vlastní textový řetězec. Druhý parametr je seznam voleb v menu, hráč má vždy na výběr konec hry, restart nebo načíst uloženou pozici, navíc můžeme přidat:

• finishOptionAmusing nabídne hráči zábavné věci, které mohl ve hře minout a může se k nim chtít vrátit a vyzkoušet je. Text samozřejmě musíme dodat, stačí modifikovat objekt finishOptionAmusing a definovat metodu doOption(). V ní text zobrazíme a vrátíme true, aby se hra opět vrátila do menu.
• finishOptionCredits nabídne zobrazit informace o autorovi hry, které jsme si připravili ve versionInfo objektu, když jsme mluvili o intru.
• finishOptionFullScore nabídne přehled získaných bodů a za co byly uděleny.
• finishGameScore také nabídne hráči zobrazení skóre, ale jen součtu bodů bez detailního rozpisu.
• finishOptionUndo nabídne odvolat poslední tah, což se hodí zejména u neúspěšného konce hry.

Kromě toho můžete vyrobit i jiné volby, které nejsou v základní výbavě. V naší hře jsme nabízeli doslov, stačí vytvořit objekt třídy FinishOption a zadat kromě doOption ještě pár vlastností.

Hraní ve webovém prohlížeči

TADS i Inform kompilují zdrojový kód hry do bajtkódu, který se spouští v tzv. interpretru. Interpret můžeme ideově přirovnat ke čtečce e-knížek či prohlížeči PDF souborů. Technicky vzato je to virtuální počítač. Oba systémy se drží tradice už od dob společnosti Infocom, která své hry takto vydávala, aby je mohla snadno přenést na různé počítačové platformy (na každý další počítač stačilo přenést jen interpret). Inform dokonce umí překládat do originálního formátu Z-machine, ve kterém byl publikován Zork a další legendární hry, v praxi se ale používá spíš Glulx, který není omezen limitem 64 KB.

TADS ovšem má svůj vlastní binární formát – svůj vlastní návrh architektury virtuálního stroje se svou vlastní instrukční sadou a především s mnohem bohatšími vestavěnými funkcemi. Na rozdíl od Glulx, které spíše jen odstraňuje limity historického formátu a jinak ho moc nemění, stále se jedná o dost primitivní virtuální stroj, T3VM je mnohem modernější a komplikovanější, podobá se spíše virtuálnímu stroji Javy (podobnost čistě náhodná, autoři JavaVM od TADSu téměř určitě neopisovali).

S rozvojem internetu se může zdát, že vyžadovat instalaci speciálního programu pro hraní textové hry je anachronismus a řada lidí se domnívala, že by textové hry dosáhly na širší publikum, kdyby je bylo možné hrát přímo ve webovém prohlížeči na stránce autora. Pro formáty odvozené od Z-machine vznikly interpretry naprogramované v JavaScriptu, které bytekód hry spouští přímo v prohlížeči hráče. Stejné řešení pro TADS ale nepřicházelo moc do úvahy, jednak by bylo mnohem pracnější ho vytvořit a je pravděpodobné, že by ani moc dobře nefungovalo kvůli problému s výkonností.

Mike Roberts proto přišel s řešením, které mnohé překvapilo. Do TADSu doplnil podporu pro HTTP komunikaci a nad ní vystavěl kompletní klient-server architekturu a webové uživatelské rozhraní. To běží v prohlížeči a posílá na server příkazy hráče, kde jsou vyhodnoceny a zpátky se do prohlížeče vracejí pokyny, co zobrazit. Sice se nedá vzít hra zkompilovaná pro normální interpretr a spustit jí webově, u většiny běžných her ale není potřeba dělat nic víc, než je znovu přeložit pro webové prostředí, a o to se postará několik voleb v Makefile. Vlastní hostování hry je také technicky složitější, nestačí běžný webhosting, ale je potřeba mít vlastní server, kde je pro každého hráče spuštěna instance interpretru, který komunikuje s webovým prohlížečem. Komunita však takové servery pro veřejnost provozuje, takže stačí hru nahrát na IFDB a na své stránky si umístit prostý odkaz na spuštění.

Protože toto řešení kvůli své technické složitosti vyvolalo řadu nedorozumění, uvědomme si jeden z hlavních důvodů, proč Mike toto řešení zvolil. Zatímco klasický interpret TADSu má podporu HTML značek na úrovni HTML ver. 3.2, hra spuštěná ve skutečném webovém prohlížeči bude mít přístup ke všem nejnovějším současným i budoucím technologiím, kterými prohlížeče disponují. Můžeme tak hru obohatit o nejnovější přírůstky v HTML5, pokročilé kaskádové styly, skripty, animace, rastrovou i vektorovou grafiku, zvuky, videa a cokoliv dalšího si vymyslíme. Celý frontend si nese hra s sebou, takže ho můžeme libovolně upravit a přeprogramovat. Hlavní cenou, kterou za to platíme, je nutnost hrát online a nemožnost tyto speciality přenést do hry pro běžný interpret.

Tipy pro tvorbu vlastní hry

V celém našem seriálu jsme se zatím soustředili jen na programování a technické aspekty, proto si na závěr dovolme trochu odstup a soustřeďme se chvíli na design textových adventur.

Osnova

Máte bezvadný nápad na novou převratnou hru? Za každou cenu odolejte pokušení sednout k vývojovému prostředí a začít bušit kód! Nejprve je potřeba si celou hru rozmyslet, abyste věděli, k čemu směřuje a jak se bude příběh vyvíjet, protože jinak riskujete, že budete muset předělávat už hotové části, až zjistíte, že něco v pozdější části příběhu nesedí a ovlivňuje už hotové věci. Škrtnout v osnově je mnohem snazší, než zahodit kus naprogramovaného kódu.

Když jsme programovali Základnu, tak jsme promýšlení příběhu věnovali hodně času, mnohem více, než jsme původně plánovali. Začali jsme se scházet v půli letních prázdnin a mysleli si, že do konce září máme příběh vymyšlený a budeme mít půl roku na programování. Chyba lávky! Příběh stále neseděl, stále jsme nevěděli, co bude ta nekalá činnost, která se na asteroidu odehrává. Chtěli jsme, aby to dávalo smysl, aby byl důvod, proč zrovna na asteroidu a aby tajemství na konci mohl hráč využít ve svůj prospěch. To byl důležitý požadavek, tak nějak to spojilo nitky příběhu dohromady. A ani spousta dalších maličkostí stále neseděla, třeba jak hráč přistihne kapitána s velitelem při odklízení bedny, vždyť nejsou hloupí, nebudou ji úmyslně stěhovat před jeho zraky. Proto jsme poslali hráče ven neplánovaně podruhé, jako že napoprvé vyndal nesprávný modul.

Nakonec vznikl 45 stránkový dokument se spoustou informací, mapou, poznámkami k lokacím a důležitým předmětům atd., nástřelem mechanismu rozhovoru na konci hry i odhadovaným walkthrough. Samotná osnova, která vystihovala kostru příběhu, události, které se stanou, a jakým způsobem bude hráč motivován pátrat, jak bude celá hra zasynchronizovaná, aby hráč něco nevynechal, ale ani nepředběhl a přitom měl stále pocit, že se rozhoduje sám, měla čtyři stránky. I když nemusíte hru předem naplánovat do posledního detailu, leccos se dá vymyslet v průběhu implementace, důrazně doporučuji sestavit alespoň osnovu, která naplánuje celkovou dějovou linii.

Struktura příběhu

Většina textových adventur je poměrně konvenčně rozdělena na tři části. V první části byste měli uvést hráče do děje. Je potřeba seznámit hráče s prostředím, ve kterém se hra odehrává, představit hlavní postavy, jejich cíle i motivaci a vybudovat atmosféru hry. První část by měla být poměrně krátká a puzzly snadné. Vůbec nevadí, když je úvod lineární, ve druhé části je dost času hru rozvětvit. Hlavně ale musí být začátek rychlý a strhnout pozornost hráče. Musí se stát něco, co ho zaujme a zavdá na obsah střední části hry, co ho motivuje, aby se chtěl dozvědět více, aby chtěl hrát dál.

Druhá část hry tvoří rozsahem i stráveným časem největší díl. Hráč už je motivovaný, a proto dostane mnohem více prostoru a svobody. Zpřístupní se mu většina lokací na mapě, vyjasní se dílčí úkoly a bude moci sám pátrat po tom, co ho zaujalo a o čem se chce dozvědět více. Struktura puzzlů by se měla rozvětvit, aby v každém okamžiku mohl pracovat na více problémech současně. Když se zasekne v jedné větvi, může chvíli pracovat na jiném problému. Také bude moci komunikovat s postavami ve hře a poodhalí jejich nitro. V neposlední řadě naznačíme, kam hra směřuje a o čem bude závěr.

Třetí část hru uzavírá. Je potřeba spojit všechny nitky, vysvětlit, co bylo utajeno, a hlavně poslat na hráče hlavní monstrum. Ať už je to postava záporáka, příšera či přírodní katastrofa, zkrátka to, k čemu hra celou dobu směřovala, musí to být výzva. Snažte se vytvořit naléhavou situaci, vytvořte časový limit (bomba tiká, letadlo padá,…), hráči musí tuhnout krev v žilách! Nechte ale poslední puzzly relativně snadné, hráč prošel peklem, aby se sem dostal, tak si zaslouží rychlé rozuzlení, zde už se nesmí zaseknout.

Objevování příběhu

Ve statické fikci je příběh zjednodušeně řečeno sérií událostí, které se stanou. Aplikovat obdobný postup na interaktivní fikci je ale problematické, protože by to předpokládalo, že hráči znají úmysl autora a že v každém okamžiku vědí, co se má stát dál. A to samozřejmě nevědí – co přijde autorovi, jako logický vývoj, nemusí přijít hráči. Vždy lze vymyslet spoustu různých možností, jak by mohl příběh pokračovat, a nechat hráče uhodnout, co by měl dělat dál, je frustrující. Do určité míry lze problém obejít tím, že hráčům sdělíme, co mají dělat, mohou např. dostat úkol od nějaké postavy atp., ale v takové hře se budou hráči cítit jako na kolejích, a to není dobře. Hráči nechtějí slepě následovat scénář, ale chtějí mít svobodu počínání, chtějí mít pocit, že oni jsou rozhodující silou v příběhu.

Proto autoři vyvinuli jiný přístup k tvorbě zápletky. V interaktivní fikci je příběh činností hráče často objevován, místo aby byl utvářen. Mnoho her se např. točí kolem odhalování tajemství z minulosti, hráč se pohybuje a rozhlíží po scéně a nachází stopy k tomu, co se kdysi stalo. Samotná činnost hráče zajímavá není, ale odkrývající se tajemství už ano. Stejná věc může fungovat i v přítomnosti, kdy motorem příběhu je někdo jiný v pozadí. Hráč sám příběh neutváří, ale reaguje na to, co se děje kolem něj.

Snahou je mít co nejvíce autorského vlivu na vývoj příběhu a při tom maximálně zachovat pocit hráče, že je součástí příběhu a volí si, jakým způsobem ho objevuje. Jestliže se události staly v minulosti, hráče ani nenapadne, že by je chtěl ovlivnit. Jestliže se události odehrávají v přítomnosti, hráč může chtít do vývoje zasáhnout, ale i když autor musí hráči umožnit, aby se pokusil zvrátit vývoj událostí, nemusí ho nechat uspět. Trik je v propojení událostí v příběhu s tempem, ve kterém hráč poznává a objevuje zápletku, aby doslova v momentě, kdy „detektiv objeví, kdo je vrah“, příběh vyvrcholil závěrečnou konfrontací.

Jak na puzzly

Pokud se rozhodnete vytvořit pravověrnou hru plnou puzzlů, dejte si pozor, aby byly všechny férové. Řešení puzzlu by mělo mít motivaci – něco ve hře by mělo hráče přivést na správnou myšlenku, není dobré se spoléhat na externí znalosti. Do určité míry může řešení záviset na všeobecných znalostech, ale dvakrát si rozmyslete, zda to, co je k vyřešení potřeba vědět, je skutečně všeobecná znalost. Také se vyhýbejte zabíjení hráče bez varování. Vůbec nejhorší jsou hlavolamy, které nedávají hráči smysl ani po vyřešení nebo pro jejichž vyřešení musí hráč vědět něco, co zjistí jedině tak, že alespoň jednou zemře. Na čem puzzly založit?

Nejjednodušší je použít objekt způsobem, pro který je určen. Třeba je ve sklepě prasklá žárovka, a tak ji hráč vymění, aby si mohl posvítit. Můžete ale využít i druhotnou vlastnost objektu, třeba žárovku jako zdroj tepla k vyvolání neviditelného inkoustu. Buďte ale konsistentní, hráč si musí popálit prsty, pokud na ni sáhne a je zapnutá.

Dalším běžným hlavolamem je ukrytí potřebného objektu, jako klíče od dveří atp. Musíte si ale dát pozor, aby hráč věděl, že klíč může nalézt, že zamčené dveře nejsou jen dekorací a aby měl nějaké vodítko, jak klíč najít. Můžete ho např. ukrýt pod květináč a hráči říci, že je květináč trochu nakřivo.

V řadě klasických textových her měl každý předmět jediné využití. Jakmile jste ho na něco použili, mohli jste ho odložit a zapomenout na něj. Můžete toho využít a obrátit očekávání – vytvořte předmět, který se ve hře použije vícekrát a pokaždé jiným způsobem.

Dalším běžným problémem je vyrobení nového objektu ze základních surovin, jako třeba pazourku z kamene a klacku nebo namíchání lektvaru podle receptu. Pokud je potřeba, může hráči napovědět některá postava nebo může najít potřebné informace v knížce.

Stroje a mechanismy jsou velice vděčné. Můžete je popsat vizuálně, ale neříci, k čemu slouží a nechat hráče stroj vyzkoušet a přijít mu na klub pomocí experimentování. K dispozici máte řadu ovládacích prvků, jako jsou páky, tlačítka apod. Stroje a mechanismy vůbec dokáží být velice mocné, mohou třeba ovlivňovat věci v jiných lokacích atp. Jeden z nejsložitějších objektů, jehož obtížnost naprogramování je přímo pověstná, je realisticky se chovající lano.

Jedny z nejvíce uspokojujících puzzlů jsou ty, které spočívají v interakci s postavami. Když hráč vyzraje nad jinou postavou, bude si to zaručeně pamatovat déle, než když vyzraje nad mechanismem.

K už dost obtížným puzzlům patří ty, které jsou závislé na časování, tj. kdy je potřeba provést určité akce v přesně definovaném okamžiku, aby se něco stalo, zvláště pokud se takový puzzle rozkládá přes více lokací.

V minulosti byly velice oblíbená bludiště, některé hry se dokonce předháněly ve vyčíslení počtu lokací, které ve hře jsou, ale v dnešní době už jsou za zenitem, v moderní hře byste se jim měli spíše vyhnout, těžko přinesou něco nového.

Navádění hráčů

Textové hry jsou dnes už pozapomenuté a jejich ovládání nemusí být pro nováčka vůbec snadné. Když jsme tvořili naší hru, tak naší cílovou skupinou byly děti, které nikdy nic podobného neviděly. Proto jsme naprogramovali trochu delší začátek, ve kterém byl integrovaný tutoriál, který postupně (a po malých dávkách) ovládání vysvětlil. I když nepůjdete tak daleko, jako my, existuje několik technik, kterými můžete pomáhat navádět hráče správným směrem.

Nezkušení hráči typicky nebudou rozumět poněkud zjednodušenému modelu světa v textové hře a budou hodně oscilovat mezi úrovněmi detailů ve hře. Zatímco v jednu chvíli vymyslí desítky příkazů, jak použít podávátko, protože je nenapadne pouhé >vem kartu, v jiném okamžiku zadají příkaz >oprav vesmírnou loď. Hodně času je důležité věnovat testování a pokud je hra určena začátečníkům, tak si za testery vzít podobné začátečníky. Pokud uvidíte, že hráči mají tendenci zadat podobný příkaz, který je orientovaný na výsledek, zachyťte ho a vysvětlete jim, že musí popsat, jak toho chtějí dosáhnout.

Snažte se omezit počet neobvyklých sloves, která jsou důležitá pro dohrání hry. Za obvyklá slovesa považuji ta, která představují běžné použití objektu, tj. která se ve většině českých her realizují příkazem >použij. Když už máte ve hře neobvyklá slovesa, napovězte je hráči, naučte ho takové akce používat. Buď můžete sloveso zapracovat přímo do popisu předmětu jako součást vyprávění, nebo můžete doplnit do hry tip, který přímo řekne příklad použití. V naší hře jsme např. o stetoskopu napsali: „Lékařská pomůcka k naslouchání slabých zvuků uvnitř pacienta. Stačí si ho nasadit a pak přiložit k tomu, co chceš poslouchat.“

Hráči mají také tendenci trávit čas tím, co jim poskytuje zajímavé reakce. Tuto psychologii můžete využít k navádění hráčů správným směrem. Důležité objekty, které posouvají hru, naprogramujte do větší hloubky. Barvitě je popište a smysluplně reagujte na nejrůznější akce, aby přitahovaly pozornost. Naopak chcete-li aby o něco hráč ztratil zájem, používejte stručné a nezajímavé popisy a odpovědi na akce dělejte nudné a opakující se.

Konzistence

Model světa v textové hře je velice zjednodušený a jeho standardní chování, jak ho implementuje knihovna, není nijak zajímavé. To, co posouvá hru dál a co ji činí zajímavou, jsou specificky naprogramované reakce, které jsou unikátní pro danou hru. Jak má ale hráč přijít na tu správnou akci v kombinaci se správnými předměty? Příkazová řádka, která maskuje své limity a předstírá, že hráč může zadat cokoliv ho napadne, vůbec nepomáhá. Interaktivní fikce nemá žádná vtištěná pravidla chování akcí a objektů nad rámec nejzákladnějšího ovládání – to zajímavé je právě to unikátní, co vymyslel autor hry. A tak je zcela na autorovi, aby zajistil konzistentní a pochopitelné chování svého herního světa, aby hráč nebyl vystaven nahodilému hádání či čtení mysli. Proto je potřeba:

• Speciální chování objektů mít konzistentní v celé hře. Např. pokud máte ve hře dveře, které je potřeba prorazit sekyrkou, mělo by být možné sekyrkou zničit i jiné dveře či jiné věci, u kterých to lze rozumně předpokládat a zároveň by mělo jít dveře zničit nebo alespoň poškodit i něčím jiným, co má podobné vlastnosti, jako sekyrka.
• Pokud používáte neobvyklé příkazy mimo těch úplně nejběžnějších, představte je hráči co nejdříve a používejte je v celém průběhu hry, aby si na ně hráč zvykl a nezapomněl na ně.
• Snažte se udržet konsistentní úroveň detailů. V hrách je běžné, že složitější objekty jsou složené z několika samostatně prozkoumatelných detailů a někdy i na několik úrovní zanoření. Jestliže schováte důležité informace hlouběji do popisu některého detailu, pak musíte do podobné úrovně detailů implementovat i další objekty ve hře, aby si hráč na úroveň detailů zvykl a nic nepřehlédl.

Například v naší hře jsme chtěli udělat puzzle s robotem v místnosti, do které hráč nemá přístup. Chtěli jsme, aby si hráč všiml robota na obrazovce kamerového systému a ovládl ho namířením tabletu na jeho obraz. Proto jsme už na začátku hry řekli hráči o možnosti ovládat elektronické přístroje namířením tabletu a dali si práci a naprogramovali reakce na namíření tabletu na kde co počínaje palubní deskou, běžeckým pásem, mikrovlnkou atd., aby na to hráč nezapomněl, aby hra konzistentně dávala najevo, že na takovou akci umí reagovat. A nakonec to celé byla vlastně příprava, aby hráč v rozhodující chvíli uměl namířit laserem na přijíždějící vozítko.

Testování

O nutnosti otestovat hru na živých hráčích jsme se už krátce zmínili výše. Vidět svou hru na živých hráčích velice pomůže s vychytáním nekonzistencí v příběhu a s doladěním obtížnosti. Ostatní vidí hru jinak, než autor, který od ní nemá odstup. Úplně ideální je vyžádat si od testerů i celý přepis jejich sezení, abyste viděli, co zkoušeli a kam se jejich myšlenky ubíraly.

Teď bych se ale chtěl zmínit spíše o softwarovém testování, které je poslední dobou docela často mezi programátory skloňované. Textová hra totiž má tu výhodu, že se dá testovat velice snadno a dost komplexně. Během vývoje Základny na asteroidu jsem vytvořil sadu příkazů potřebných pro průchod hrou, které zkoušely spoustu různých věcí mnoha různými způsoby, a jednoduchým skriptem jsem vždy nechal zobrazit rozdíl od posledního průběhu hry, který budeme považovat za zkontrolovaný. Tak se daly velice snadno odhalit jakékoliv změny a chyby.

Pamatujte, že zvládnutí hry po technické stránce není bonus, ale základní předpoklad, aby hru někdo vůbec hrál.

Kam dál

Tvorba textových adventur je zajímavá aktivita vyžadující rozmanité schopnosti. Chcete-li do tvorby proniknout, určitě si zahrajte pár kvalitních her zahraničních autorů. V seriálu jsem se snažil ukázat úvod do problematiky, abyste získali představu o způsobu a možnostech programování v TADS 3, ale myslíte-li to vážně, budete muset jít mnohem více do hloubky. Pro začátek nabízím několik užitečných odkazů:

• Rozcestník oficiální dokumentace TADS 3
• Whizzard’s Guide to Text Adventure Authorship
• The Craft of the Adventure
• Tips on Designing your Game
• Brass Lantern

Celý seriál čerpal ukázky ze hry Základna na asteroidu, kterou jsme naprogramovali jako soutěžní hru pro naši dětskou šifrovací hru. Mezi dětmi, kterým byla hra určena, ale i mezi lidmi z komunity příznivců textových her je spousta chytrých a zvídavých lidí, které zajímá programování a pro ně nyní přinášíme kompletní zdrojové kódy naší hry, aby je mohli >prozkoumat.

Další díly seriálu

• Úvod
• Lokace
• Předměty
• Kontejnery
• Akce
• NPC postavy
• Závěr