Port of Sand-dancer in Dialog

I purposely did not implement the setting-specific error messages. That felt gratuitous to me.

I’m bummed about Dialog aam vs. z8 differences.

I do a lot of automated testing, but it uses the Dialog debugger, not dumb frotz or whatnot.

I think I added logic to omit that when you are in the truck.

Do you have a convenient list breaking down “unimplemented-but-planned” vs. “unimplemented-and-wontfix”? Might save some effort on our part.

My intention is to implement everything BUT the setting-specific error messages.

There will certainly be other differences; there are things like not grinding out the cigarette butt int he truck that I added, and I jumped around a bit on different versions of SD (for I7) so there’s a few vestigial things in there, exercises from different chapters of the book, that may be implemented.

So I’m finding this helpful, and I’m looking for things that are broken first, and then things that undermine the narrative second.

knock knock

I don’t understand why that works in the I7 version; is “knock” supposed to be a synonym for “examine”?

I think you missed the point I was trying to make, which was that the original tells you how many cigs are left at the end of the smoke, but your version does not. (I have to examine the pack to get that intel.)

`knock knock`

I don’t understand why that works in the I7 version; is “knock” supposed to be a synonym for “examine”?

Beats me! It just seemed like an obvious “I’m an obnoxious text adventure player” thing to do, if one has a character with a name that is also a common verb, to try to verb that noun.

I also ran into this one recently. It’s a bug in the library: “Get out” is parsed as both [leave] and [leave #truck], and those actions are printed in the same way. This will be fixed in the next release.

Meanwhile, this workaround may do the trick:

(understand [get out] as [leave])
        (just)
2 Likes

Yes, that works. Thanks!

Just pushed a fix that starts to warn you the your are low, on last, out of cigs after the first couple.

It’s thematic to me that you don’t get an exact count early on; it fits with Knock’s character that he’d only notice once he was starting to run out.

Fine by me!

Just for the record, though, this original (I caught you saying that there are different variants, different ways to implement it based on the book or whatever) literally gives the cigarette count after each one:

>light cigarette

You pull out a cigarette and flick it into life. Thoughts tumble through your head.

Well, you're still stuck here. It's dark outside the beam of your headlights. Maybe you could start by looking around the area, seeing if maybe there's a phone or something.

And you still haven't quit smoking. You've got five cigs left.

>eat photo

You ain't that hungry, amigo.

>smoke cigarettes

You pull out a cigarette and flick it into life. Thoughts tumble through your head.

Well, you're still stuck here. It's dark outside the beam of your headlights. Maybe you could start by looking around the area, seeing if maybe there's a phone or something.

And you still haven't quit smoking. You've got four cigs left.
1 Like

Yes, I’ve diverted a little from trying to make a perfect clone of I7 Sand-dancer. It’s turned into a bit of a variant, a riff on the original. I think Aaron would be more than ok with that!

I think you could take a transcript from the I7 game and largely feed it into the Dialog version unchanged (outside of a few random elements in the games) and get to the same point (barring any bugs or the kinds of missing grammar you’ve already spotted).

2 Likes

I started the story. I was not aware of Reed’s story, so it was all new to me. Nice job. Smooth, compelling, and rich in detail. I like the ‘brood’ concept. I tried to ‘trick’ it to push its boundaries, but to no avail. Good job. One typo: at base of tower “on of three legs”.
-Falsoon

1 Like

Modern IF is pretty fast; here’s my tests for the game running:

~/workspaces/dialog/sanddancer-dialog > dgt test -b
               base-of-tower ... ✓       147.800631ms
                       chase ... ✓       147.642689ms
  control-center-via-courage ... ✓       137.863802ms
 control-center-via-strength ... ✓       139.889862ms
                coyote/brave ... ✓       137.438607ms
           coyote/edge-cases ... ✓       140.939274ms
                   coyote/no ... ✓       135.108112ms
               coyote/strong ... ✓        139.13157ms
          coyote/yes-no-pack ... ✓       138.870794ms
          fight/attack-brave ... ✓       139.577554ms
         fight/attack-strong ... ✓       142.339364ms
                fight/coward ... ✓       142.344168ms
            fight/edge-cases ... ✓       141.706488ms
              get-flashlight ... ✓       148.873432ms
                 leave-truck ... ✓       142.148225ms
                    memories ... ✓        139.14955ms
                     no-undo ... ✓       159.722895ms
                 open-desert ... ✓        139.08734ms
          pursuit/first-time ... ✓        138.97324ms
      pursuit/lost-and-found ... ✓       157.536642ms
               rabbits-offer ... ✓       143.721484ms
                  radio-chat ... ✓       145.489433ms
sand-dancer/complete-freedom ... ✓       150.434377ms
   sand-dancer/courage-honor ... ✓       148.730094ms
 sand-dancer/strength-spirit ... ✓       155.857223ms
          smoking/smoke-verb ... ✓       148.822373ms
           smoking/until-out ... ✓        145.98471ms
                  temptation ... ✓       160.903602ms
                     waiting ... ✓       138.123023ms

OK

Each test is a new process that starts up the dialog debugger and executes a series of commands; the startup time obviously dominates the timing because there’s not much variation between test script executions, even though some scripts are much longer than others.

Thanks. I’ve fixed that, plus a few other things.

I read that as “modern supercomputers are pretty fast.” :slight_smile:

It would probably be easier to see some daylight on those timings by running them on the worstest machine that’s also still capable of compiling Dialog (disused stock Amiga 3000UX, perhaps?) but I grant that there’s probably not too much to be gained from doing that.

I’ve managed to compile dialogc and dgdialog on a 21-year old laptop with a Mobile Celeron 400Mhz processor running a very very very very old version of Ubuntu. (It was the oldest/slowest thing I could find in the house that I felt had a reasonable chance of getting this far.) But your dgt tool says it’s too esoteric for that kind of environment.

Can you set me up with a different way to run your timing suite?

1 Like

Don’t really have a solution for you, dgt is useful to me (on a Mac), but I have zero cycles to make it work on Windows or a 21 year old laptop. Sorry.

I have an old Dell Inspiron that was purchased in 2007. I managed to upgrade it to Win 7 a number of years ago. It is a very backup computer that contains a Core 2 Duo processor. It compiles Dialog and TADS 3 fine but struggles with Inform 7. With Inform 7 I have to disable the virus protection to prevent time outs.

1 Like

I’ve fixed a number of bugs identified here, and created version 2, which is now on the web.

1 Like

I’ve deployed v3 with more changes. I expect to do a bit more. It’s very satisfying to make incremental improvements at this point, mostly about getting rid of default responses and such.

1 Like