Adventure -- Repris

6 posts in thread

• Kristoffer Eriksson <5357> · Text 2100 · w8 · inlagg

  1986-07-16 00:57

  Ärende: Adventure -- Repris

  (Text 2113) 1986-07-14 17.58.02 Mikael Hovmöller <4688> Mottagare: ABC80 Kommentar till text: 2051 av Kristoffer Eriksson <5357> Ärende: Adventure Hmmm, det har inte hänt så mycket med mitt 'språk'. Jag har nämligen varit på landet i en månad, och då ville inte datorn funka... Om jag hinner, kanske jag försöker någon gång, men det verkar inte så nu... (Dessutom kom jag in på gymnasium i Danderyd, så då hinner jag nog inte något...) Jag kan inte riktigt se fördelen med SPELARE och LÄGE, det blir MYCKET längre, och inte enklare... Break istf Stop kanske, men NEXT och CONTINUE är tvärtom, den ska inte fortsätta med nästa vilkor, utan bryta eller stanna. Då är nästan Stop att föredra eftersom det (nästan) är samma sak... Meningen med det här programmet är dels att det ska vara lätt att skriva egna adventures, men även att kompilatorn ska vara (hyfsat) lättilverkad, så att man med lätthet kör samma adventurefil på både ABC, PC och LEK-64. Därför är inte idén med AND, OR osv speciellt lyckad, det försvårar kompilatorn utan att ge några större förändringar. Idén med ständiga texter som definieras i samband med rumstexten var mycket bra! Varför man absolut måste trycka in något mellan sak 5 och 6 kan jag inte för mitt liv begripa. Den som MÅSTE göra det kan gärna lida lite... Enligt tidigare resonemang har vi kommit fram till att man lägger saker i tex rum 7, inte i hallen! Om man då definierar rum 7 som 'skräp' och lägger en sak där, så blir det samma sak som att gömma den. Visst kan man lika gärna skriva -1 och -2 som 255 resp 254 om man nu föredrar det... (Däremot inte -1 och 0, då första rummet är 0!) Undrar om jag någonsin orkar börja på detta... Detta var tänkt att svara på alla frågor, men pga avsaknad av printer kanske någon fattas. Repetera i så fall!
  • Kristoffer Eriksson <5357> · Text 2103 · w8 · kommentar

    1986-07-16 01:45

    Ärende: Adventure

    Nu har jag säkert glöm det mesta, mn jag gör väl mitt bästa att svara: Jag vill kunna behandla spelaren som vilket föremål som helst om jag får lust, så är man inte så beroende av alla dessa specialformer av instruktionerna, som refererar till det speciella föremålet spelaren. Det kan vara praktiskt att ha den linjen öppen om någon ny instruktion läggs till vid något tillfälle, så slipper man dela upp den på ett par, tre olika nästan lika instruktioner. Hur uttrycker du LÄGE(<sak>,<plats>) om saken inte är spelaren och platsen inte är den plats spelarenär på? Jag kan acceptera dina kortare former för samma sak, som platssparande synonymer, men jag tycker alltihop ska vila på ensund och generell grund (=datastruktur). Haka inte upp dig så på hur lång en viss instruktion blir. Det viktiga med ett högnivåspråk är ju att det är a) Lättläst, och b) Lättändrat, annars kan man ju lika gärna skriva direkt i målspråket (BASIC i det här fallet, Assembler oftast annars). NEXT och CONTINUE kan tolkas som "NEXT COMMAND" och "CONTINUE WITH NEXT COMMAND", för det är väl vad de ska uträtta? De ska ju inte stoppa programmet helt som STOP i BASIC. I C betyder CONTINUE "CONTINUE WITH NEXT ITERATION". Nå, det här är inget viktigt tyckr jag. Man ska inte låta användaren lida! Då använder han något annat program. Jag brukar gå in för att allt användaren kan få för sig att göra faktiskt ska gå att göra. Ett nytt rum mellan rum 5 och 6 skulle t ex kunna motiveras av att det blir en ny passage mellan dessa rum. Ett nytt föremål mellan nr 5 och 6 kan bero på t ex att föremål 1-5 är skatter, och jag vill sortera in en ny skatt bland de andra, så det blir lättöverskådligt. Plats 0 som ett verkligt rum gilar jag inte till 100% Fast om du nu måste begränsa platsnumren till 256 (varför??) så kanske du behöver den också... Om du för ett ögonblick kan sluta tänka i bytes och bits, så är ju normal numreringsordning från nr ett, samtidigt som talen 255 och 256 inte på något sätt är speciella. Därför yrkar jag på att de inte heller ska utgöra special-rum, eller övre rumsnrgränsen. Frågan om du besvarat allt: Tja, allt var ju inte formulerat som frågor så jag vet inte om du missat något. Du kommenterade inte likheten mellan detta adventurespråk och BASIC, och inte möjligheten av att inte göra någon princpiell skillnad på föremål och platser.
    • Mikael Hovmöller <4688> · Text 2104 · w8 · kommentar

      1986-07-16 12:45

      Ärende: Adventure

      1. Msub(sak,plats) motsvarar ditt Läge(sak,plats)! 2. Det är lika bra att begränsa rummen till 254! Detta har två anledningar: 1. Man ska inte göra ett spel där mer tid lagts på många rum än på handlingen! Det blir bara tråkigt att spela. 2. Programmet ska kunna köras på en ABC80, och då har man inte vidare mycket minne. Dessutom sparar man en byte varje gång ett rum används! 3. Ok, tolkar man NEXT och CONTINUE som du beskriver kan det lika gärna heta det! Jag tänker på mitt STOP som 'sluta exekvera/kompilera verbdefinitione', och det är raka motsatsen mot'fortsätt'! Men, som sagt, det har ingen betydelse, bara man bestämmer sig! 4. Ang likhet med basic: Visst blir några delar lika, men det kan tom vara en fördel! (Lättare att lära sig, tex!) Däremot så sparar med med mitt 'språk' enormt mycket arbete dels vid definiering av de andra sakerna, dels slipper man göra de tidsödande verben, dels får man ett kompatibelt språk som kan köras på alla datorer. De tre fördelarna tycker jag mer än väl kompenserar att man kan skriva 'nästan likadant i BASIC'! 5. Angående numrering av rum och saker: allt beror på hur avancerad 'kompilatorn' blir. Eftersom det antagligen kommer att bli en hel del rum i ett adventure, så är det inte så smart att kalla dem med namn! De 'lablarna' blir väll 'Hall1','Hall2','Hall3' osv och då är man tillbaka till siffrorna! Rummen är därför lika enkelt att ha som siffror. Däremot är sakerna bättre att kalla vid namn. 6. Det finns en nackdel med att ha saker i andra saker, och det är att man inte kan ha alla saker i alla andra saker, och det är kämpigt att definiera upp alla möjliga/omöjliga kombinationer! Dessutom måste sakerna skrivas ut olika, tex så här: Du är.... Här finns: en säck (normalt) Du är... Här finns: en garderob I garderoben ligger en säck (Här måste man ha en särskild text för att visa var säcken finns) Dessutom finns en tredje kombination: säcken i en stängd garderob... Och sen kan man ha tex en bok i en öppen säck i en stängd garderob! Att göra en kompilator som klarar allt detta är KOMPLICERAT, och dessutom måste det ske helt korrekt, annars är det inget vidare kul att spela. (Fast visst vore det FANTASTISKT roligt om man orkade!) Hmmm, var det allt tro? M.v.h. Micke
      • Kristoffer Eriksson <5357> · Text 2113 · w8 · kommentar

        1986-07-18 01:24

        Ärende: Adventure

        1. Då är ju "Läge" en betydligt mer betydlig benämning på den instruktionen, och inte ett dugg längre. Om det ska vara engelska så föreslår jag någon av Position, Pos, Where, Location, Loc. Och om du ändå har en instruktion för detta, vad var det då du protesterade mot förut? 2. Spar bytes gör ju bara om du läser in koden i en sträng i en tolk, för heltal tar ju alltid två byte i Basic, även om du håller dig inom talområdet för en byte. (Funderar du på portabiliteten nu, så tänk också på att många Basicar inte klarar längre strängar än 255 tecken, så det blir otympligt) Har du däremot kompilerat äventyret till ett Basicprogram (och alltså inte till en kod som tolkas av ett Basicprogram), så spelar ju storleken på rumsnumren ingen roll alls, eftersom du inte behöver lagra en massa rumsnr i datorns minne. (Det kanske du inte behöver i en tolk heller. Rumsnr kan användas som index i en adresstabell i stället.) Det är förstås lämpligt att lägga ned mer arbete på handlingen än ett stort antal rum, men för den sakens skull behöver man ju inte omöjliggöra höga rumsnr. Ska man införa begränsningar tycker jag man ska ha mycket goda skäl till det. Och de finns heller ingen anledning att hindra större spel för dem som har större maskiner. Om föremål numreras i samma serie som rummen går det åt fler nummer. 4. Jag håller med om att det inte gör något att det går att översätta språket till Basic ganska rakt av. Men det negativa jag som jag ursprungligen ville framföra med denna jämförelse var nog att det (då?) var så kryptiska kommandon och så mycket siffror man fick hålla reda på själv, att det inte vore mycket svårare att skriva det i Basic direkt. Som sagt, ett högnivåspråk (dvs annat än assembler) måste göra någon nytta också. 5. Det läs knappast kosta något extra att tillåta namn på rummen, om man ändå tillåter det på föremålen. Särskilt inte om de ligger i samma nummerserie. I punkt 1, skrev du dessutom att de INTE skulle vara så mycket rum. Jag skulle i alla fall föredra att referera till rummen som Hall1, Hall2, Kök, Sovrum, Skog1, Skog2, Skog3, Trollskog, osv, än som en enda härva av nummer. Men har man datahjärna är man ju inte tvungen att utnyttja namnen. 6. Om du nu inte vill hålla reda på objektens aktuella attribut (som "Öppen", "Stäng", "Full"(?)) så finns det ju alltid flaggor att ta till för de objekt som kan användas så. Man får åtminstone definiera varje rum som "Ihåligt" eller "Massivt" (förutom Öppen, stängd...). Rum är förstås default ihåliga och ställen man kan gå till, fast det senare bestäms nog mest av om det finns någon väg dit eller ej. Det som är så bra är att om du väljer att inte implementera ihåliga saker och liknande nu, så finns det med rätt datastruktur inga hinder att i en handvändning göra det senare. För att fixa utskriften av vad som finns "Här", får du skanna av alla objekt och följa "inuti-kedjan" för att se om det som ligger ytterst är detsamma som "Här". Eller så håller du reda på både plats och "yttersta plats" för varje föremål. Eller så har du en länkad lista från varje objekt till de objekt som finns inuti, i stället för tvärtom. Komplicerat vid första anblicken, men när man hittat den rätta metoden för ett problem, är det inte längre så komplicerat. (Inte med en bra metod) (Beklagar indragningen av styckena. Tänkte inte på den saken när jag skrev texten i ordbehandlingen.)
        • Mikael Hovmöller <4688> · Text 2114 · w8 · kommentar

          1986-07-18 01:52

          Ärende: Adventure

          Hua! Helt oläsligt för oss stackare som kör med 40tkn... Nåväl, har hämtat hem texten nu, och kommenterar senare. En kommentar direkt dock: sista punkten om hur allting ligger placerat verkar komplicerat av två skäl, dels är programmet svårare att gör på detta vis, dels blir det MYCKET definieringar! (Fast jag kanske kommer på en lösning när jag tittar på det hemma.) Ang att spara bytes: jag har tänkt att kompilatorn gör en kod som p programmet som kör spelet kastar rätt in i minnet, och sedan kompilerar 'vid behov'. Kompilatorns kod består alltså av en (STOR) mängd siffror, varav vissa är bokstäver. Dessa bytes lagras då direkt i minnet, och sedan tittar exekvatorn (vad i h-e heter det?) på dem. (Hmmm, det blev rätt så obegripligt, men det blir bättre sen! (. Förhoppningsvis... .)) M.v.h. Micke Ps. Förtydligande: 'bokstäver' (rad 14) ska vara 'ASCII-värden för bokstäver'. Ds
          • Kristoffer Eriksson <5357> · Text 2122 · w8 · kommentar

            1986-07-19 00:02

            Ärende: Adventure

            Hur blir det mycket definitioner? (Definitioner är väl roliga?) Du får inte rygga undan för en liten gnutta krångel, som inte bör vara något krångel när det är löst. Vilket krångel är fotfarande olöst? (. Eller du kanske inte är tillräckligt duktig för detta? .) Dessutom kräver jag inte att du ska införa alla finesser på en gång, bara att en datastruktur väljs som gör det möjligt att bygga på med finesserna senare, utan allt för mycket besvär. - Kompilerakoden vid behov??? Vadå till? Maskinkod? Inbyggt i tolken? Exekvatorer brukar kallas "tolk", eller interpreter på engelska. En sådan tolkar koden. Ska du använda tolk-varianten så finns det ingen speciell fördel med likheten till BASIC, som du drog fram som ett plus förut. Men mig gör det inget.