Diskuze o textových hrách

Poslední příspěvky

1
TXT / Re: TXT engine
« Poslední příspěvek od pedromagician kdy 30. Březen 2020 - 20:08 »
Chcel som to druhou castou zakoncit, ale asi bude rozumnejsie to este rozdelit :) Tak opat par poznamok k priestoru a objektom...

https://txt.pohroma.de/2020/03/30/pomsta-svet/
2
TXT / Re: TXT engine
« Poslední příspěvek od pedromagician kdy 30. Březen 2020 - 16:24 »
Tri mesiace ubehli a pokracovanie v nedohladne. Nie je to tak, ze by som sa na to vykaslal. Mam to rozrobene, ale popri tom sa udialo par veci. V podstate vznikol odlahceny port TXT na jednu nemenovanu 8bitovu platformu. Spolu s uverejnenim by mala byt aj kratsia hra. Bude nova verzia TXTed a aj samotny TXT. Je sa na co tesit, dufam  8)
3
Všeobecná diskuse / Re: Odkazy na textovky a o textovkách
« Poslední příspěvek od mop kdy 26. Březen 2020 - 15:19 »
https://www.root.cz/zpravicky/hlavne-nenapadne-nova-humorna-textova-free-adventure-hra/
Tak jsem to teď dohrál, je to docela krátké, ale poměrně vtipné. Škoda té češtiny bez diakritiky.
5
TADS / Re: Kroužící orel 2
« Poslední příspěvek od Kroužící orel kdy 18. Březen 2020 - 20:51 »
No tak to je paráda, s negací jsi vše krásně vysvětlil, jak vidno, přečíst si o ní něco v knížce je pěkné, ale opravdové využití je něco jiného, zvláště když neznám zákony Herr De Morgana, díky za ně. Pokud potřebuji prověřit, zda hráč nemá nůž nebo návnadu, musím využít OR, vše jasné. Jsem moc rád, že se právě tato chyba stala, protože se mi vryje do paměti víc, než kapitola o těchto zákonitostech pojednávající v různých příručkách.

Hmm, pomocí if(!moved) nic nevyřeším, musím se ptát, zda se pohnul předmět Orlí maso. Konstrukce if(!orliMaso.moved) je zcela funkční a situace funguje tak jak má, metoda makePresent pohnutí orlího masa způsobí a potíž je vyřešena. Na druhou stranu if(orliMaso.location != nil) využít nemohu, zde se vždy provede blok za else a dostávám hned hlášení "Orlí jáma už mi pomohla dostatečně, vzhůru za dalším dobrodružstvím. " stejně jak by již akce byla provedena.

Referenční manuál mě tady trochu mátl, když si rozkliknu LieOnAction , vidím hnedle v záhlaví informaci:
class LieOnAction :   TAction      // after macro expansion
a poté prohlížím Superclass Tree - LieOnAction tedy dědí od TAction a Resolver a právě zde jsem byl zmaten tím, že pod BasicProd a Resolver vidím uvedeno object, hmm, teď je mi po Tvé informaci jasné, že se jedná o speciální třídu, kterou manuál uvádí, ale tuhle informaci jsem přehlédl. Tady je to trochu jinak, než v Javě, kde pokud dobře chápu jasně vidím rozdíl mezi třídami a objekty, ve Tvém manuálu jsem se ale dočet, že rozdíl mezi nimi je v TADSu mnohem menší, na to si budu muset zvyknout. Nevadí, mám alespoň možnost porovnat obé, tyto jazyky tvořili zkušení programátoři a určitě sakra dobře věděli proč zvolili právě tento styl.

V tomto konkrétním případě mě tedy zajímá metoda dobjFor(LieOn) - method of Thing in thing.t[10072], kde vidím Tebou popsané preCond a verify, ještě jednou jsem si projel Tvůj manuál, vše je vysvětleno v sekci Akce s objekty na akci "sněz jahody", paráda. Já jsem chybně chápal dobjFor() jako metodu, jasně, jedná se o zkratku nebo jak píše Erik v Getting Started na straně 71 makro, tady jsem si o propertysets přečetl více. Míchání dvou druhů akcí dohromady tedy není možné, chápu to snad správně jako pokus využít metodu třídy z jiné třídy, která jí nemá definovanou (ovšem to je případ z Javy, zde se jedná o makro).

Hmm, parser tedy nebude řvát, pokud metodu pojmenuji chybně, jasné, tady se jedná nikoliv o chybu v zápisu, ale v logice programu. Změna zápisu ifu vše vyřešila, jsem ale vděčný i za tuto informaci, teorii a nízkoúrovňovou logiku TADSu bych časem také rád pochopil, zdá se mi totiž, že OO jazyky jsou v této teorii o tom samém a jejich tvůrci se jen snaží přiohnout si je po svém, diskuze o tom "nej" jazyku jsou poté zcela zbytečné. Po Tvých informacích ještě více, než kdykoliv předtím vidím, že je opravdu jedno, jaký jazyk člověk zpočátku zvolí, TADS a Java se mi po praktickém využití každého z nich krásně spojí, musím jen co nejvíce programovat. A časem pochopím třeba i to, proč je Java tak ukecaná, ale díky tomu jednoduchá a čitelná pro čtení, proč se vývojáři jazyka C a následně C++ rozhodli pro své konstrukce nebo proč je Ada tak tvrdě striktní, ale např. pro mě ještě o chlup čitelnější, než zápis Javy. OOP bude možná přehlednější a pro budoucí rozšíření programu vhodnější, než strukturovaný zápis, to ale musím zjistit vlastní praxí, kdo ví a vše má svůj dobrý důvod.

Teď je drobet náročnější, že děti nejsou ve škole, takže na ranní vývojařinu mnoho času nezbývá, budu ale pokračovat jak budu moci, abych hru dokončil co nejdříve.
6
TADS / Re: Kroužící orel 2
« Poslední příspěvek od gaspoda kdy 8. Březen 2020 - 22:27 »
Pro úspěšný lov potřebuji mít v ruce nůž a návnadu. I přes můj kód však stačí mít jen jediný předmět, např. nůž

Ty tam máš podmínku:

Kód: [Vybrat]
  if(!navnada.isIn(me) && !nuz.isIn(me))
ale to není správně utvořená negace. Ty říkáš, že potřebuješ nůž A ZÁROVEŇ návnadu. Co je tedy opakem, kdy akci nedovolíš? Když nemáš nůž NEBO nemáš návnadu. Zapoměl jsi prohodit tu logickou spojku. Je to stejné, jako když řeknu, že půjdu ven, když budu mít čas A ZÁROVEŇ bude hezky. Čili nepůjdu ven, pokud buď nebudu mít čas, NEBO bude ošklivě. Říká se tomu DeMorganovy zákony a dají se zapsat jako !(A * B) = !A + !B či !(A + B) = !A * !B (hvězdička značí logický součin, tedy "a zároveň", plusko logický součet, tedy "nebo" a vykřičník je negace). Měl bys tedy napsat:

Kód: [Vybrat]
  if(!navnada.isIn(me) || !nuz.isIn(me))
a ještě se text opakuje, místo aby hra zobrazila blok uvedený v else. Předměty typu PresentLater se v pořádku objeví:

Ty tam říkáš:

Kód: [Vybrat]
  if(!moved)
Ale dej si pozor, koho se ptáš. Protože píšeš přímo vlastnost moved bez určení objektu, tak se ptáš objektu, ve kterém je napsaný if() a to jsou jámy, které se nikdy nepohnou. Možná bys měl testovat např. orliMaso.moved, potom to bude zabírat, dokud se maso nepohne, čili než ho sebereš. (Teď jsi nejsem jistý, jestli makePresent způsobí pohnutí masa, ale myslím, že ano - záleží, jestli chceš změnit text po objevení nebo až po sebrání a podle toho přizpůsobit podmínku. Můžeš také zkoušet testovat if(orliMaso.location != nil))

V referenční knihovně si vyhledám Akce a rozkliknu LieOnAction, pokud dobře chápu, zjišťuji, že se jedná o třídu dědící od tříd TAction a Action a také od BasicProd a Resolver

Ano, od TAction a BasicProd přímo a ty zase od Action a Resolver.

(které jsou však označeny jako objekty, i když po rozkliknutí jako třídy

Třídy poznáš, že zpravidla začínají velkým písmenkem a objekty malým. Nicméně klíčové slovo "object", které v manuálu vidíš napsané poblíž BasicProd a Resolver neznamená, že BasicProd je objekt, je to třída, ale dědí od speciální třídy nazvané "object", což je označení, že třída nemá žádné předky v knihovně, od kterých by dědila vlastnosti.


Citace
   An object must always have at least one superclass, but you can use the special class name "object" if you want a generic object that is not based on another object that your program defines.

V sumáři vlastností a metod třídy LieOnAction vidím několik akcí xxx dobj xxx (snad se vyjadřuji přesně), nikoliv však akci s názvem dobjFor
(LieOn), kterou potřebuji použít.

V prvé řadě dobjFor(LieOn) bys měl hledat na herním objektu (potomku Thing), kde se definuje chování akce. Třída LieOnAction se přímo o konkrétní chování nestará, všechny akční třídy jsou součastí parseru, starají se o rozpoznání akce v příkazu hráče a pro samotné vykonání pak zavolají preCond, verify, check a nakonec action na herním objektu.

Zde mě zaráží, že jsem nedohledal žádné propojení s třídou LieOnAction, tady něco chápu špatně.

Potřebuji pracovat s věcmi v inventáři, takže se juknu blíže na aplikaci této metody ve spojení s třídou Thing a dostávám předpis:

Kód: [Vybrat]
    dobjFor(LieOn)
    {
        preCond = [touchObj]
        verify() { illogical(&cannotLieOnMsg); }
    }

Já se však ve svém kódu snažím využít nikoliv preCond a verify (mohu je chápat jako atributy metody?),

Zápis s dobjFor() samo o sobě ještě není ani metoda, ani vlastnost, ale taková zkratka v zápisu, aby vypadal více hierarchicky a méně se opakovalo psaní. Říká se tomu propertyset a je to specialita TADSu. To, co takhle napíšeš, tak se změní na metodu (verify, action,...) či vlastnost (preCond) tak, že se název zkombinuje z obou částí:

Kód: [Vybrat]
    preCondDobjLieOn = [touchObj]
    verifyDobjLieOn() { illogical(&cannotLieOnMsg); }

Ale jinak ano, teď už hledáš na správném místě. V těchto místech se skrývá chování, které chceš ovlivnit.

ale verify, check a action společně s podmínkou začínající příkazem if a končící else, nakonec se snažím
umožnit hráči nejen si s potřebnými předměty lehnout do jámy, ale také při položení obou věcí dosáhnout
téhož pomocí dobjFor(PutIn) asDobjFor(LieOn).

Tak to ale pozor, o jakou akci se jedná. Když se snažíš jednu akci přesměrovat na jinou, nesmíš míchat různé druhy akcí dohromady. Jednak bys nemohl přesměrovávat akci, co žádné objekty nebere na akci, co bere jen přímý objekt a podobně akci, co bere přímý objekt na akci, která používá přímý i nepřímý objekt. To není kompatibilní. Ve tvém příadě LieOn je akce, kde hráč ulehá na objekt a to není kompatibilní s akcí, kdy objekt se položí na jiný objekt. I když nemůžeš použít asDobjFor, tak můžeš obě možnosti naprogramovat velmi podobně, ale zvlášť.

Pokud dobře chápu, potřebuji rozšířit funkcionalitu metody dobjFor(LieOn) tak, abych mohl využít atributů
verify, check a action. Je nepříjemné, že můj zápis hra nebere jako chybu (syntaktická to pro kompilátor
není, sémantická však ano, pokud dobře rozumím, i tak je chování zvláštní, neměl by TADS při překladu zařvat,
že se snažím volat neexistující atributy?).

Neměl by řvát, je to obráceně. Ty je nevoláš, ty je vytváříš (a máš možnost vytvořit jakoukoliv metodu či proměnnou chceš), volá je akce v knihovně. A nebo pokud se spleteš a nepojmenuješ metodu správně nebo z jiného důvodu ji nikdo nechce, tak ji holt nikdo nezavolá.

Zde se ale už dostáváme dost do teorie a možná většina tvých problémů zmizí, když vyřešíš ty drobné chybky v logice ifů zmíněné na začástku
mé odpovědi.

Něco mi holt uniká, nechápu zatím propojení mezi třídou LieOnAction a metodou dobjFor(LieOn), tuším, že zde
takové propojení bude např. přes třídu Thing a její metody.

Ze strany akční třídy se spouští vykonání akce, např. kdyby sis našel ve třídě TAction metodu verifyAction(), tak tam uvidíš, jak zde akce volá tu verifyDobjLieOn tvé jámy. Ale pointa je, že kód LieOnAction bys ani neměl číst, to jsou ty nízkoúrovňové věci, které sice tvoří jádro zpracování, ale jako autor hry tu nic užitečného nenajdeš.
7
TADS / Re: Kroužící orel 2
« Poslední příspěvek od Kroužící orel kdy 25. Únor 2020 - 21:45 »
Orlí jámy a využití akce dobjFor(LieOn)

Na hře stále pracuji, mám hotovo cca 70 procent, takže jsem byl s rychlejším dokončením přeci jen přílišný optimista.
Je ale jasné, že se někde seknu, zatím jsem na většinu programátorských nástrah přišel. Už několik dní se ale pachtím s
akcí dobjFor(LieOn) a jak vidno, potřebuji si ujasnit věci, které se snažím aplikovat ne tak jak autoři při tvorbě jazyka předpokládali.
V příloze zasílám aktuální situaci s několika potřebnými místnostmi.

Ve hře se nachází orlí jámy určené na lov těchto dravců, potřebuji, aby hra reagovala na příkaz "lehni si do jámy" s tím,
že pokud má hráč nůž a návnadu, akce se provede a po zpracování opeřence získám nové předměty.


Pokud nemám v ruce žádný předmět, vše je OK a vyskočí hláška, kterou potřebuji:


>lehni si do jámy
Orla musím nejen na něco chytit, ale také mít šikovný předmět na zpracování masa a peří, nic nesmí zůstat nevyužito.


Pro úspěšný lov potřebuji mít v ruce nůž a návnadu. I přes můj kód však stačí mít jen jediný předmět, např. nůž a ještě
se text opakuje, místo aby hra zobrazila blok uvedený v else. Předměty typu PresentLater se v pořádku objeví:


>inv
Neseš nůž a na sobě máš bederní roušku, opasek, orlí medicínu a mokasíny.

>lehni si do jámy
Takže Ty se opravdu nebojíš lovu orlů...

>lehni si do jámy
Takže Ty se opravdu nebojíš lovu orlů...

>roz
Jihozápadní hranice prérie (ležíš na jámách)
Na jámách je orlí maso, orlí perutě, orlí pera a orlí letky.



Nejde mi jen o vyřešení problému, ale pochopení toho, co dělám špatně, přeci jen z Pecinovského Javy využívám IDE typu BlueJ, kde krásně graficky vidím provázanost tříd, objektů a volaných metod, zde mi není jasné následující:

V referenční knihovně si vyhledám Akce a rozkliknu LieOnAction, pokud dobře chápu, zjišťuji, že se jedná o třídu dědící od tříd TAction a Action a také od BasicProd a Resolver (které jsou však označeny jako objekty, i když po rozkliknutí jako třídy, zde se asi bude jednat o ten minimální rozdíl mezi třídou a objektem, který uvádíš ve svém manuálu). V sumáři vlastností a metod třídy LieOnAction vidím několik akcí xxx dobj xxx (snad se vyjadřuji přesně), nikoliv však akci s názvem dobjFor(LieOn), kterou potřebuji použít. Dobrá, vyhledám si všechny metody s názvem dobjFor(LieOn) (zde netuším, zda mohu akci typu dobj nebo iobj chápat jako metodu?) a vidím:
 
dobjFor(LieOn) - method of ComplexContainer in extras.t[207]
dobjFor(LieOn) - method of Thing in thing.t[10072]
dobjFor(LieOn) - method of Room in travel.t[4617]
dobjFor(LieOn) - method of NestedRoomFloor in travel.t[5161]
dobjFor(LieOn) - method of Floor in travel.t[5336]
dobjFor(LieOn) - method of BasicChair in travel.t[6440]
dobjFor(LieOn) - method of NominalPlatform in travel.t[6730]

Zde mě zaráží, že jsem nedohledal žádné propojení s třídou LieOnAction, tady něco chápu špatně. Potřebuji pracovat s věcmi v inventáři, takže se juknu blíže na aplikaci této metody ve spojení s třídou Thing a dostávám předpis:

    dobjFor(LieOn)
    {
        preCond = [touchObj]
        verify() { illogical(&cannotLieOnMsg); }
    }

Já se však ve svém kódu snažím využít nikoliv preCond a verify (mohu je chápat jako atributy metody?), ale verify, check a action společně s podmínkou začínající příkazem if a končící else, nakonec se snažím umožnit hráči nejen si s potřebnými předměty lehnout do jámy, ale také při položení obou věcí dosáhnout téhož pomocí dobjFor(PutIn) asDobjFor(LieOn).

Pokud dobře chápu, potřebuji rozšířit funkcionalitu metody dobjFor(LieOn) tak, abych mohl využít atributů verify, check a action. Je nepříjemné, že můj zápis hra nebere jako chybu (syntaktická to pro kompilátor není, sémantická však ano, pokud dobře rozumím, i tak je chování zvláštní, neměl by TADS při překladu zařvat, že se snažím volat neexistující atributy?).

Něco mi holt uniká, nechápu zatím propojení mezi třídou LieOnAction a metodou dobjFor(LieOn), tuším, že zde takové propojení bude např. přes třídu Thing a její metody.

Tohle ale pro další tvorbu musím pochopit, jinak na netriviálních akcích ztroskotám. Je mi jasné, že jsem se u Exoteru ptal na každou prkotinu, protože bez chápání výše uvedeného jsem se dál prostě nemohl dostat a jen zkoušel, zda nějaký zápis projde či nikoliv (a podobně jako zde se mi to např. s hořící pochodní podařilo, hru kompilátor přeložil, ale chovala se jinak, než jsem zamýšlel).


Moc se omlouvám za sakra dlouhou zprávu, snažil jsem se vyjádřit co nejpodrobněji. Mohu poprosit o objasnění - nejde jen o vyřešení problému, ale hlavně o postup a vysvětlení, co dělám špatně? Je mi jasné, že až mi tyto věci docvaknou, bude už šumák, jaký jazyk pro tvorbu použiji (samozřejmě budu-li se pohybovat v rámci OOP, pokud se nemýlím), protože stále více vidím, že princip programování je u všech těchto jazyků podobný. Pecinovského "Architektura nejdříve" a využití návrhových vzorů a UML bude parádní pro vymýšlení jak mám funkcionalitu programu navrhnout, šikovná metodika, např. programování řízené testy a právě pochopení propojení třída - objekt - metody mi umožní program konkrétně zapsat. Tak vývojařinu v současné době chápu, pokud se mýlím, nevadí, člověk se stále učí.

Zatím se loučí

Orel
8
Všeobecná diskuse / Sinclair a listingy
« Poslední příspěvek od panprase kdy 23. Únor 2020 - 19:15 »
Tuhle jsem řešil situaci, nebo zvědavost, nazvěme to jak chcete, chtěl jsem vidět jak vypadá listing Indiana Jonese 3 od božského Františka. Náhoda tomu chtěla a našel jsem způsob jak se do hry dostat, supr, tak se to povedlo a zmínil jsem se o tom na sociální síti a že bych chtěl vidět listing Nemesis II - mimochodem, jedna hodně pěkných textovek pro Sinclaira. No a Martin Malý se toho nějak chytil a udělal tool, co nám ukáže basic, když mu předhodíte SNAP.

https://www.asm80.com/tools/index.html?fbclid=IwAR2LVlKVRMfLW5VKUNBdAfwHNoRPumsOSmp_CHDnfU8oW8I7imzxSWNFCbM#/sna2bas

Hlavně jsem chtěl tedy vědět, proč ataristi nikdy neukradli Jonese 3 a jeho engine. Ono by to nebylo zas tak problém to přepsat, tedy až na to, že to musíte asi napsat jinak, ten Atari Basic děsně limituje.
9
Nové textové hry / Re: Senobyzal
« Poslední příspěvek od panprase kdy 23. Únor 2020 - 19:07 »
No zatím sem to jen tak zkoušel, vypadá to celkem nadějně, tak snad se v tom nebudu muset rejpat jako v Egetonu.
10
Nové textové hry / Re: Senobyzal
« Poslední příspěvek od pedromagician kdy 23. Únor 2020 - 19:05 »
Ooooo. Vzhľadom na to že sa posledný viac ako mesiac vŕtam v Atarku tak mi to príde vhod. Vyskúšam :-)

Odoslané pomocou Tapatalku