Ondřej Novák: dnes bych Brány Skeldalu napsal za dva měsíce

6. 10. 2009
Doba čtení: 13 minut

Sdílet

Ve druhé části rozhovoru s Ondřejem Novákem, programátorem hry Brány Skeldalu, si řekneme, jakým způsobem byl vytvořen zvukový subsystém, jak byla navržena umělá inteligence nepřátel, princip ukládání mapy dungeonu v operační paměti a v neposlední řadě se budeme zabývat také otevřením zdrojových kódů.

Obsah

1. Zvukový subsystém

2. Organizace map dungeonu

3. Řídicí logika hry a MapEdit

4. Umělá inteligence NPC postav

5. Otevření zdrojových kódů Bran Skeldalu

6. Portace na systém Microsoft Windows

7. Portace Bran Skeldalu na Linux

8. Chystají se další dobrodružství?

9. Odkazy na Internetu

1. Zvukový subsystém

PT: jaký jsi v Branách Skeldalu použil zvukový systém? Jednalo se o vlastní produkt nebo již připravenou knihovnu, například Midas (který byl v dobách DOSu poměrně oblíbený)?

ON: komplet vlastní. Uměl zpracovat 32 stop efektů a jednu stopu streamované hudby v pozadí (která se tedy nenačítala v přerušení, ale do speciálního bufferu se sem tam v „idle“ přihodil kus dat z disku). Mixování probíhalo v přerušení do připraveného zvukového bufferu, který pak načítal ovladač ať již přímo s využitím schopností zvukové karty (DMA – přímý přístup do paměti), nebo v jiném přerušení (Covox).

PT: které zvukové karty byly podporovány?

ON: Sound Blaster, Sound Blaster 2, Sound Blaster Pro, Sound Blaster 16, Gravis UltraSound (GUS), WSS (Windows Sound System, tehdy u nás dost častý lowend). COVOX a perličkou byl PC Speaker (samozřejmě se zde při přehrávání využívala pulsní šířková modulace – PWM).

PT: v diskusích k seriálu o architekturách počítačů jsi se zmiňoval o tom, že se zvuky a hudba (možná poněkud paradoxně) přehrávaly snadněji na kartách Sound Blaster než na GUSech. Bylo to způsobeno tím, že se v případě GUSů musely všechny samply nahrávat přímo do bufferů na zvukové kartě, kdežto Sound Blastery byly orientovány spíše na DMA přenos?

ON: mixování bylo od začátku navrženo softwarové, protože se s GUSem nepočítalo. Nicméně se objevili testeři, kteří měli GUSe a stěžovali si, že jim to nehraje. GUSe mi nakonec zapůjčil kamarád na jeden měsíc a tak jsem mohl napsat a odladit ovladač. A protože v té době už byl celý zvukový systém napsaný, bylo nutno prostě přizpůsobit GUSe existujícímu systému, nikoliv systém GUSovi. Zvukový systém se totiž sestavuje jako zvukový stream a tak jsem potřeboval pouze „aby to hrálo“. Mixovací rutinka měla k dispozici celou paměť a mohla v jeden okamžik začít mixovat kterýkoliv zvukový vzorek. Paměť GUSe byla omezená a znamenalo by to nějaký náročnější správce jeho paměti, který by hlídal co už je načtené a co není, kde je obsazeno a kde je volno. A to by věc zkomplikovalo.

PT: hudba se vždy přehrávala v navzorkované (samplované) podobě, nebo se využívala i FM syntéza, tj. buď OPL-2 nebo OPL-3?

ON: hudba byla (je) streamovaná a navzorkovaná (uložená ve formě samplů), přičemž je použita jednoduchá komprese, při které se šestnáctibitové vzorky ukládají jako osmibitové a to tak, že se ukládá rozdíl mezi sousedními vzorky. Rozdíly jsou přitom přepočítávány nelineárně. Je to dáno předgenerovanou převodní tabulkou tak, aby přenesený výkon byl zhruba stejný. Dekomprese je jednodušší, pouze se podle tabulky přičítají nebo odčítají hodnoty od předchozího vzorku. K tomu vznikl speciální formát MUS, jenž obsahuje tabulku a pak po blocích uložený zvuk ve dvou stopách prokládaně. Vlastní proces dekomprese se pak provádí do bufferu rezervovaného asi na čtyři sekundy hraní, který dokola prochází mixovací rutinka. Stav bufferu se pak programově cyklicky kontroluje, a když se uvolní dostatek místa, tak se tam „přihodí“ další blok. Důvodem komprese nebyla ani tak úspora místa, jako rychlost tehdejších CD-ROMek.

Pro zajímavost: hudba je sice nasamplovaná, jak jsme si již řekli v předchozím odstavci, ale hudebník ji pravděpodobně stejně samploval na nějakém syntetizéru, nebo možná i přímo na počítači z MIDů, protože hodně lidí kritizovalo, že zní synteticky. Nicméně to je jen můj subjektivní dojem.

PT: jakým způsobem bylo vyřešeno přehrávání zvuků na PC Speakeru? Zmínil jsi se o pulsní šířkové modulaci, to znamená, že se používal známý trik s dvojicí časovačů (jeden pro generování „PWM signálu“, druhý pro časování jednotlivých vzorků):

ON: ano. Přehrávač pro PC Speaker byl dokonce tentýž jako na Covox (D/A převodník připojený na paralelní port). Pouze se přeprogramoval časovač a připojila se převodní tabulka z osmi na šest bitů a zbytek ovladače byl stejný. Takže se jakoby přehrávalo na Covox, ale posílalo se to na port 42. A protože byl k dispozici pouze jeden časovač, byl součástí přerušení i dělič, který jednou za 320 cyklů (50 Hz) zavolal původní obsluhu přerušení s povoleným přerušením, aby vlastní obsluha byla přerušitelná, a aby delší zpracování původní obsluhy nenarušovalo přehrávání. Takže v jeden okamžik může přerušení přerušit přerušovací rutinu. :-)

2. Organizace map dungeonu

PT: jaký byl způsob uložení map (dungeonu) v operační paměti? Jednalo se o běžné pole (což programátora pravděpodobně napadne jako první možnost) nebo nějaká sofistikovanější struktura?

ON: jak už jsem nadhodil v diskuzích (k předchozím dílům seriálku o čtverečkových dungeonech), použil jsem trochu jiný systém organizace map než pole (array). Jednalo se o orientovaný graf, ve kterém každé políčko mělo v zásadě čtyři (občas i pět) východů, tedy sever, jih, západ, východ (pátý směr viz další odstavec). Na každém tomhle směru bylo napsáno číslo políčka (sektoru), které se nacházelo v příslušném směru. Kdo někdy editoval MUDa (Multi User Dungeon), ví pravděpodobně o co se jedná; tady akorát sektorem není místnost, ale políčko. Editor si sám hlídal, aby byla logická návaznost jednotlivých políček, ale existovala zde možnost to sem tam ručně změnit a vytvořit nějaké efekty, jako jednosměrné chodby a podobně. Kdo se ztratil v Podzemí, určitě si takových zvláštností všiml.

Ten pátý východ býval dolů, tedy nějaká jáma; pokud tam někdo napsal nulu, tak vyrobil krásné DéTéčko (kdo nezná? DT – Death Trap). Na každém políčku v každém směru pak existoval záznam o primární stěně, tedy to, co se zobrazilo jako hlavní textura, a o sekundární stěně, což mohl být přepínač, klíčová dírka, bůh ví co ještě, a časem se tam dalo přiřadit prakticky cokoliv, například otevírané dveře. V případě, že to bylo vhodné, tak se místo primární stěny použila jen stěna sekundární, protože se třeba dala pozicovat (podívejte se, jak jsou udělané dveře na začátku hry v lese, když se otevírají k hráči). Pak tam byla obrovská hromada příznaků (flagů), přepínačů a definicí; například každá stěna mohla mít výklenek, do kterého se daly umísťovat předměty.

3. Řídicí logika hry a MapEdit

PT: použil jsi při programování řídicí logiky hry (AI – umělá inteligence atd.) nějaký skriptovací jazyk, třeba i vlastní?

ON: kdo tvořil dobrodružství v MapEditu ví, že je tam trochu chaos. Nejprve vznikly takzvané Akce, což byl přímo do editoru integrovaný systém zasílání zpráv a generování událostí v mapě. Následně se možnosti rozšířily na takzvané Multiakce, kam bylo možné přímo v editoru mapy vepsat nějaký jednoduchý skript. Ten se ale přímo na místě překládal, nebyl tam textový (programátorský) editor, jen dialogová okénka s formuláři. No a nakonec vznikl vlastní dialogový skript pro popis dialogů mezi postavami a NPC (non-player characters – postavy řízené počítačem). Dialogový skript se překládá do bajtkódu a následně pak interpretuje. Podobně vypadá i skript popisu kouzel. Překlad do bajtkódu byl hloupý, jen jednoduchá transformace tokenů na čísla.

4. Umělá inteligence NPC postav

PT: jakým způsobem byla v Branách Skeldalu naprogramována umělá inteligence počítačem řízených postav (NPC)? Například ve sklepení hry Dungeon Master II se skrývala jedna poměrně „inteligentní“ potvůrka, která se snažila hráče nalákat do jedné chodby s pastí a pokud se jí to podařilo, tak past sama spustila.

ON: umělá inteligence byla jednoduchá. Potvůrka, pokud chodila, tak chodila tak, že počítala východy (z políčka). Pokud se počet východů změnil, mohla se rozhodnout, že změní směr. V případě, že zaslechla zvuk, otočila se v jeho směru. Ale pozor: záleželo na tom, kudy zvuk přišel bludištěm, ne absolutně, protože zvuk se šířil po chodbách. Takže se potvůrka mohla otočit i jiným směrem, než ve kterém se nacházel zdroj zvuku. Časem se do celého systému zapojily takzvané specprocs, což byly kusy kódu přímo zakompilované v programu a označené číslem. Tento kód pak mohl ovlivňovat rozhodování potvůrky na každém políčku. Například tam byla specproc, která způsobovala, že driáda si držela od hráče odstup. Nebo že si potvůrky uměly otevřít dveře. Že uměly při boji čarovat různá kouzla, nebo přednostně útočily na slabší postavy, nebo hlídaly určitou místnost, atd. Výběr specproc se nacházel v editoru. Při soubojích uměly NPC hledat cestu v grafu a tak dokázaly hráče obklíčit. Některé potvůrky uměly z boje zdrhnout, pokud se jim tato funkce povolila.

PT: navazuji ještě na otázku o umělé inteligenci NPC. Kdyby tedy tvůrce nových příběhů potřeboval vytvořit nějakou „inteligentní“ NPC, která má určitý speciální úkol, musel by vytvořit nové funkce přímo v céčku pro ovlivnění jejího chování?

ON: těch možností, co udělat s příšerkou, má tvůrce víc, může např. příšerce říct, aby se vydala do určitého místa a příšerka si sama najde cestu bludištěm. Může na podlahu bludiště malovat (neviditelné) šipky a příšerky je následují. Může některé části bludiště učinit pro příšerky neprůchozí, nebo může generovat zvukové události a tím ovlivňovat jejich pohyb. Ale pokud by šlo o nějakou hodně speciální akci, tak ano, muselo se sáhnout do kódu a napsat na to specproc, která by se pak volala skoro při každém pohybu nebo plánování nestvůry. Občas to šlo obejít pomocí kouzel, kdy příšerka jakoby čarovala kouzlo bez grafických efektů, které se pak nějak na postavách projevilo (ve hře existuje jedno kouzlo, které při vyvolání odhodí družinu o políčko dál od kouzelníka, takže by se to dalo udělat třeba takto).

5. Otevření zdrojových kódů Bran Skeldalu

PT: jaké důvody vlastně vedly firmu Napoleon Games k tomu, že otevřela její zdrojové kódy?

ON: to nevím, to se zeptej Napoleon Games :-). Ale po tom, co se Jindra Rohlík rozhodl uvolnit hru jako freeware (souběžně s jeho projektem Mutant), tak už to bylo jen na mně, jestli dám souhlas zveřejnit zdrojáky (autorství zdrojových kódů mi samozřejmě zůstalo), což pro mne nebyl problém. Vlastně prvotní impuls byl ode mne, chtělo to jen čas. Moje představa byla, že se tím tak trochu celého projektu zbavím a nechám to na fanoušcích. Všimni si, že se jedná jen o zdrojové kódy, nejedná se tedy o zdrojová data, grafiku, mapy, dialogy – na to všechno má firma Napoleon Games stále copyright a může si zvolit vlastní licenční model.

6. Portace na systém Microsoft Windows

PT: významným krokem byla portace Bran Skeldalu na operační systémy Windows, což mj. umožňuje i snadnou instalaci této hry na současných operačních systémech firmy Microsoft (resp. minimálně do verze Windows XP). Jednalo se o velký zásah do hry nebo jen minoritní úpravy?

ON: ze zdrojáků hry se vykostilo hodně, celý ten „nad DOSem“ postavený framework se nahradil „nad Windowsem“ postaveným frameworkem. Místo zvukového engine se napsalo rozhraní pro DirectSound, místo grafického systému se použil DirectX, místo čtení klávesnice/myši pomocí BIOSu se čtou zprávy Windows. Některé části původně naprogramované v assembleru se přepsaly do céčka. Ale na druhou stranu, hodně velká část zdrojových kódů zůstala v originální podobě, takže se nejedná pouze o nějaký „zavaděč“, ale spíš o adaptaci.

PT: zajímavý „deník“ celé konverze můžete najít na stránce Jak se předělává hra do Windows.

7. Portace Bran Skeldalu na Linux

PT: pro čtenáře Rootu bude pravděpodobně zajímavé, že se chystá port Bran Skeldalu na operační systém Linux. Předpokládám, že bylo či bude nutné přepsat celý grafický a zvukový systém – jsou tyto zásahy do aplikace pro programátory složité, tj. lze je dělat bez obavy, že se „rozbije“ zcela jiná část hry?

ON: já se přiznám, že v tomhle směru nemám informace, protože se tohoto vývoje přímo neúčastním. Pouze jen spravuji repositář na SourceForge, ale nechávám současnému vývojáři volnou ruku a věřím, že se to nijak nerozbije (a v SVN je naštěstí historie změn). Takže se musíš zeptat tam. Vypadá to, že vývojář Linux portu má nějakou verzi, která snad jde spustit, četl jsem tamní tracker, takže se našli i lidé, co to vyzkoušeli. Ale jestli to je ve stavu k nasazení, nevím. Do Downloadu to ještě nedal. Ten člověk to píše v SDL, takže nyní bude celý ten Windows framework znovu „vykosťovat“ a nahrazovat ho SDL frameworkem.

PT: kdyby měl někdo ze čtenářů tohoto článku zájem se na dalším vývoji podílet (programátoři, grafici, „režiséři“ příběhů), koho by měl kontaktovat?

ON: je fakt, že dlouhou dobu ležely zdrojáky na SourceForge ladem než se toho někdo chytil. Já jsem za to rád, pomůže to určitě vývoji i na další platformy, třeba se dočkáme Bran Skeldalu i na mobilech. Těžko říct, ale pokud někdo zvládne dobře přenositelnost kódu, pak už to nebude problém. Všichni mohou přispět na diskuzních fórech hry, ať již na SourceForge sourceforge.net/pro­jects/skeldal/ nebo na stránkách Windows Patche (na jeho „dočasné“ adrese skeldal.vylet­nici.net/, protože doménu jinak.cz jsem bohužel musel opustit a novou jsem zatím nerozběhal).

Pánové jeskyně … tvůrci dobrodružství… jsou stále žádáni, dobrých příběhů není nikdy dost a pokud by někdo zároveň uměl malovat, tak obohatit hru novou grafikou by bylo určitě skvělé. Akorát tou jedinou odměnou, kterou z toho ten autor bude mít, bude hřejivý pocit u srdíčka a kladná hodnocení na komunitních diskuzních fórech a třeba nějaký zájem dalších specializovaných médií. Například současný aktivní pán jeskyně Ondřej Fabián se dostal až na českou Wikipedii (přesněji, zmínka o jeho dobrodružství v článku cs.wikipedia.or­g/wiki/Brány_Skel­dalu).

PT: co verze pro mobilní zařízení?

ON: už jsem napsal výše, pokud se zvládne přenositelnost (multiplatformost) celého zdrojáku, tak bych si dokázal verzi pro mobil představit. Ale raději to svěřím někomu, kdo se mobily hlouběji zabývá.

PT: při možnostech dnešních programových knihoven – podpora grafiky (žádné komplikace s n-grafickými režimy, přepočtem barev či zvětšováním/zmen­šováním textur), podpora zvuku (mixování), možnosti použít již hotové interpretry mnoha skriptovacích jazyků atd. – kolik času by podle tvého názoru zabralo naprogramování srovnatelného dungeonu dnes? Myslím tím pouze vlastní program, ne vytvoření grafiky, zvuků či děje.

ON: za dva měsíce v JavaScriptu. I se soubojovým systémem. Ale možná jsem trošku optimista, protože si myslím, že ty knihovny by člověku ušetřily tak 50% času, takže stejně by se s tím člověk mazlil půl roku až rok. Tedy pokud to má být hra a nikoliv jen technologické demo. Mimochodem, technologické demo, bez editoru, jen chození bludištěm pouze v C mi zabralo ty dva měsíce i s knihovnami, ovšem bez nestvůr, předmětů, jen základní chození. Ale ukázalo to tehdy Jindrovi, že napsat to v hicoloru (grafickém režimu s patnácti či šestnáctibitovou hloubkou) na tehdejší dobu není úplně nereálná představa.

8. Chystají se další dobrodružství?

PT: na této stránce jsi popisoval možnou technologii, kterou by bylo možné použít v další verzi Bran Skeldalu. Zamýšlel jsi se, stručně řečeno, nad vytvořením klasického čtverečkového dungeonu, ovšem vykreslovaného s využitím současných grafických akcelerátorů, včetně možnosti volného pohybu, hraní „po webu“ s možností sdílet vytvořené úrovně ve složitějších herních světech atd. (více informací laskavý čtenář najde na zmíněné stránce). Jedná se o tvoji vizi do budoucnosti, nebo už existuje například nějaké technologické demo?

ON: rozhodně bych to nenazýval novou verzí Bran Skeldalu, protože to není můj název. Zatím tomu obecně říkám „dungeon“. Byl to jen nápad, který má ale trochu hlubší kořeny. Začalo to vizí 3D MUDu (pracovní název Elinora MUD), následovalo to několika nápady o jakémsi „svobodném virtuálním světě“, který by bylo možné vytvořit pouze nahráním souborů na libovolný hosting a následně propojit ve větší svět pomocí URL odkazů (něco jako výzva proti Second Lifu, který jde přesně v opačném duchu, kdy člověk veškeré své výtvory dává dobrovolně cizí firmě a ještě jí za to platí!), ale protože jsou to stále velice komplikované projekty, tak pořád hledám nějaké téma, kde by se spousta těchto nápadů mohla uplatnit a zužitkovat. Takže zatím žádná technologická dema, pouze nápady a vize, některé rozpracované, jiné méně, pokud by o tom někdo chtěl diskutovat… tak mi dejte vědět.

bitcoin_skoleni

PT: mockrát ti děkuji za rozhovor a mnoho zajímavých informací!

9. Odkazy na Internetu

  1. Brány Skeldalu
    http://www.napoleongames.cz/main.php?…
  2. Brány Skeldalu 2: Pátý Učedník
    http://www.napoleongames.cz/main.php?…
  3. Wikipedia: Brány Skeldalu
    http://cs.wikipedia.org/…ány_Skeldalu
  4. Brány Skeldalu: novinky
    http://skeldal.vyletnici.net/main.php
  5. The Gates of Skeldal – Sources of the legendary game
     http://sourceforge.net/…cts/skeldal/
  6. Jak se předělává hra do Windows
    http://skeldal.vyletnici.net/main.php?…

Autor článku

Vystudoval VUT FIT a v současné době pracuje na projektech vytvářených v jazycích Python a Go.