Ja si naopak myslim, ze naprogramovat BS byl obdivuhodny vykon, zejmena pri pohledu na moznosti, ktere maji vyvojari her dneska – v soucasnosti by se spousta kodu nahradila vhodnou knihovnou, ale to se samozrejme v dobach DOSu moc nemohlo a take pro P75 se muselo dost optimalizovat pri pozadovanem grafickem rezimu, takze dost dobra prace.
Moc pěkný článek, velice rád jsem si početl jak jste měli různé věci vyřešené a zatlačil slzu při vzpomínkách na vlastní poněkud patetické pokusy o podobné věci v DOSu :-). Vážně moc dobrá práce, na svou dobu je to vymyšlené velice hezky. Byl to velký projekt a bezesporu odvážný a úspěšný počin. Také oceňuji, že jste kódy otevřeli a pokud se mi někdy podaří utrhnout chvíli času, hrozně rád se do nich mrknu…
Těším se na další díl :-).
Je třeba zajímavý, že ten MUS nevznikl ani tak z důvodu úspory místa, ale z důvodu aby to zvládla CDROMka. Nezapomeňte, že v té době (uvažme rok 1996–7, tedy roky vývoje, ne 98, kdy se to dodělalo) většina her měla normální zvukovou stopu. CDRomky byly jedno, dvou, maximálně čtyřrychlostní. A jednoduchým výpočtem člověk došel k tomu, že na jednorychlostní CDROMce by to nedělalo nic, než hrálo, protože rychlost přenosu muziky by odpovídala době hraní. I na čtyřrychlostní CDROM bylo znatelné dotahování streamu. Komprese tam byla dvojí. Jednak to jelo v poloviční CD kvalitě (22KHz) a jednak ta komprese z 16-bit na 8-bit.
Podobně na tom bylo video. Díky tomu, že mé znalosti MPEGování jsou mizerné, tak se vymýšleny různé jiné způsoby, jak docílit toho, aby to na čtyřrychlostí CDROMce jelo bez sekání a ujíždění obrazu před zvukem (či obráceně)
Jinak jsme se snažili přidat zákazníkum ke hře spoustu hodnoty navíc, kromě popisů skoro všech formátů (včetně formátu mapy, či savegame, takže se to dalo dobře hákovat :-) tak i editor a spoustu utilit. To tehdy nebylo zvykem. Dneska se hry distrubuují nejen s editorem, ale někdy i se zdrojáky (tam kde se trochu ctí GPL licence).
Nedavno jsem neco takoveho hledal a dokonce jsem nasel(pro symbiany): http://www.clickgamer.com/moreinfo.htm?…
pěkně je to vidět například na Dungeon Masterovi, kdy nejrychlejším pohybem/animací je otevírání dveří – pozn. PT
Co se týče zmínky o DM, opět to není pravda. Dungeon Master je interně koncipován na 6FPS a nejrychlejším pohybem je běh s botami rychlosti, kdy je opravdu možné udělat šest kroků za vteřinu – viz speedruny na YouTube, například http://www.youtube.com/watch?… 7:00
Takže nejrychlejší pohyb v DM je běh s botami rychlosti.
Pred chvili jsem to zkousel (pravda, jen v DosBoxu, zapinat kvulu tomu 486 se mi nechtelo) a skutecne se pri animaci otevirani dveri pouziva dost vysoke fps, odhadem okolo 12–15, takze mi neni jasne, co zase neni pravda.
Ta hodnota cca 6 fps, o ktere se zminujete, je skutecne pouzita pri ukladani animaci, ale rekl bych, ze zrovna to otevirani dveri je animovano programove. Neni to vlastne nic jineho nez postupny presun tri bloku dat – prave a leve kridlo se postupne zmensuje, prostredni cast (vstup do dungeonu) zase zvetsuje, takze je zbytecne takovou jednoduchost ukladat do souboru.
Ulozil jsem si i video, muzu ho v pripade zajmu nekam povesit, je tam pekne videt i rozsynchronizovani obrazu (ale to muze byt nejaka bota v DosBoxu, v realu zadne problemy nejsou viditelne).
Dobrý den, „zase“ jsem psal proto, že nepřesností ohledně Dungeon Masteru jste se bohužel dopustil již několik (psal jsem to vždy k danému článku).
K těm dveřím – kontext článku byl o FPS při hraní, nikoliv o úvodních animacích, kterou jste teď zmínil. Ta byla u DM řešena opravdu relativně jemně. Ale protože v článku píšete, cituji „pěkně je to vidět například na Dungeon Masterovi, kdy nejrychlejším pohybem/animací je otevírání dveří – pozn. PT“, tak jsem se ozval, protože nejrychlejším pohybem (animací) vykreslování bludiště při běhu s botami rychlosti.
Dokopal jste mě k tomu, abych to udělal pořádně. Takže žádné emulace v DOSBoxu a odhady z nahraného videa, ale záznam jednotlivých obrázků obrázků spolu s časovým razítkem z každého vykresleného snímku hry přímo ze zdrojového kódu Atari verze (konkrétně ve funkci display() ve WinScreen.cpp). A přímo v bludišti během hry, ne v úvodní obrazovce.
Animace zavírání/otvírání dveří má celkem pět políček. První je úplně otvřeno, pátý je úplně zavřeno. Jsou tam tedy tři animované mezistavy. Každý tento mezistav (=jeden animační krok) je zobrazen přesně 4 snímky, pak je vystřídán dalším.
Běží-li nezatížená postava s botami rychlosti, pak jeden krok postavy trvá přesně 2 snímky, čili animace bludiště je 2× rychlejší než animace otvírání/zavírání dveří. Nezlobte se, vím, že jde o detail, ale když jsem viděl nepravdivé tvrzení, ozval jsem se. Nic to nemění na tom, že vaše články jsou extrémně čtivé a zajímavé.
PS: Zkusil jsem ten DOSBox a i v PC verzi jsou vnitřní animační kroky u dveří ve hře tři.
Aha, uz chapu, kde doslo k nedorozumeni. Ja jsem prave myslel maximalni pocet fps, ktery graficky subsystem v dane hre a danem rozliseni zvladne a uvodni animace v DM mi opravdu (bez presneho mereni) pripadla nejrychlejsi.
U uvodniho loga FTL, ktere jsem puvodne chtel uvest, si nejsem jisty, jestli to neni externe spusteny program s animaci vlozenou primo do exe, mozna to na STcku bude jinak.
Dvere a brany ve hre maji skutecne jen 5 fazi animace, to samozrejme vim :-), prave ted s detma DM opet prochazim (nekdy zapiname 486, nekdy pouze v DosBoxu).
Jinak diky za presne zmereni a muzu mit jeste otazku? Mam pocit, ze boty rychlosti se v celem dungeonu vyskytuji pouze jedenkrat, takze rychlopruchod celym DM za ~20 minut (pokud ma nekdo vsechny hadanky v hlave :-) je mozny jen s jednou postavou ze?
V DM jsou boty rychlosti opravdu čtvery, pro každého člena party jedny. Konkrétně za tyrkysovými dveřmi v sedmém patře (jak jsou tam čtvery dveře, ale vy máte jen jeden klíč). Potom jsou před vchodem do říše štírů v desátém patře za tajnou stěnou. Další jsou na konci jedenáctého patra za dvěma falešnými stěnami poblíž oka na stěně, kterému musíte ukázat lupu. Poslední najdete ve dvanáctém patře v pavoučím doupěti (Cowards will be hunted down and killed).
Musíte to napsat tak, aby se to pouštělo nebo aspoň instalovalo s originálním CD nebo s balíkem od Napoleóna. Klidně si při instalaci grafiku zvuky a další soubory překonvertujte do čeho chcete, tím se myslím licence neporuší, pokud to ve výsledku bude stejná hra.
Jinak beru to jako sázku. Když naprogramujete !stejnou! hru v javě za dva týdny, jsem ochoten Vám za práci zaplatit. Když ne, máte smůlu :-)
„Musíte to napsat tak, aby se to pouštělo nebo aspoň instalovalo s originálním CD nebo s balíkem od Napoleóna“ – A duvod je jaky?
Ad sazka: Myslim si, ze bych byl za dva tydny schopen hru naprogramovat(ciste herni engine, do ktereho se pak jenom nasypou herni data). Ovsem nepocitam do toho cas, ktery by byl nutny ke zkoumani puvodni verze tak, aby se pote skutecne jednalo o stejnou hru… V prvni rade ale musim dokoncit diplomku a tak se nebojim, ze by se sazka realizovala v nejblizsich tydnech:(
Jinak me ty clanky a zkouseni tech her(konecne se mi podarilo dohrat CSB:) navnadily k tomu udelat dungeon, ktery bude hratelny jak na PC v J2SE, tak v mobilu na J2ME. Zrejme se do toho asi v nejblizsi dobe dam, ale brany skeldalu se mi libi prave z toho duvodu, ze je to porad jeste ziva hra…
Tak nějak se programováním zabývám celý život a vím, jak dlouho se určité věci programují. Kdyby jste napsal 2 měsíce, tak Vám uvěřím, a to si myslím, že poslední týden nebudete spát. Problém není něco napsat, ale oživit, vychytat všechny bugy a ošetřit všechny možné situace, které mohou nastat a které na první pohled vidět nejsou. To nemáte jen chození bludištěm, to máte i systém kouzel, umělou inteligenci, triggery v mapě, jazyk pro psaní dialogů. Jenom převod do Windows mě po večerech a o víkendech zabral něco kolem měsíce a chyby se v tom hledaly následující půl roků. A to ta konverze byla pouhým nahrazením několika funkcí za jejich Windowsovské ekvivalenty. To nemusíte ve Windows řešit zvuky, grafiku (DirectX), vstupy a výstupy, nebo chráněný režim.
Možná, že v Javě existuje spoustu již připraveného kódu, ale že by tam byl připraven herní systém hry, to jsem si nevšiml. Možná že vývoj hry v Javě by netrval dva roky, ale třeba poloviční dobu. Rozhodně ne dva týdny (počítám 10–14 MD – manday)
„„Musíte to napsat tak, aby se to pouštělo nebo aspoň instalovalo s originálním CD nebo s balíkem od Napoleóna“ – A duvod je jaky?“
Autorský zákon. Vaše dílo by se mohlo pod názvem „Brány Skeldalu“ vydávat jen v případě, že by hra na 100% odpovídala původní hře. Pokud sem tam použijete jinou grafiku, nebo to bude vypadat jinak, nesmíte tomu říkat „Brány Skeldalu“ a nesmíte použít originální grafiku. Licence se týká právě jen hry (nápad, mapy,příběh) a grafiky a zvuků. Napsat vlastní binárku je jako byste napsal přehravač (interpret) těchto datových souborů, což v tuto chvíli můžete. Ale nesmíte originální data měnit a vydávat je pak jako Váš výtvor.
PS: Výjimkou je, pokud se s Napoleonem dohodnete jinak, ale to je čistě na Vás.
Tak se bez muceni priznam, ze jsem BS nidky poradne nehral(ve wine mi to delalo bordel a tak jsem jenom prosel zacatek a vybod jsem se na to) a mozna je to skutecne slozitejsi, nez jsem cekal(to znamena neco jako treba Dungeon Master 2). No kazdopadne se do toho zcela jiste za par tydnu pustim(spis ale zacnu na zelene louce…)
Nikoliv, to jen vyjadřuje okrajové podmíky. Když někdo něco řekne, že udělá za dva týdny, nevím, jestli mluví za sebe, nebo za firmu o 100 zaměstnancích. Naopak mám zkušenost, že člověkohodiny, nebo spíš člověkodny (hodiny jsou pro programátora pod rozlišovací schopností) jsou dobrým měřítkem složitosti úkolku, lepším, než cokoliv jiného.
Samozřejmě, všichni víme, že když jeden kopáč vykope jámu za hodinu, tak jich to 60 neudělá za minutu. Ovšem pokud budete kopat 60 jam, pak je se 60ti dělníky budete kopat skutečně hodinu. To je těch 60člověkohodin.