Error running Zork spanish in Iplayif.com

Authoring Inform 7
1

Hi guys, I need some help for the spanish community.

When running Zork, the translation I made to spanish in Inform 7, it freezes after the first room when goint n or s. It’s like the game load something big in that moment.

Any idea what could happen? It doesn’t happen on the interpreters or lightly.

Here is the link:

iplayif.com/?story=http%3A//medi … ork.gblorb

Thank you,

2

It’s not loading anything; it’s doing something very slow. I see the delay in all my interpreters. It’s less than a second in Gargoyle (git), so you might not notice it, but it’s doing way more work than any single command in Zork should.

I tried it out in a profiler. The “n” command takes over 44 million CPU cycles. For comparison, start-of-game takes 230000 and “i” takes 85000.

3

On my computer the first “n” takes about 30 seconds on Parchment, but moving around after that is fast. Do you use pathfinding anywhere? ("…best route from…") IIRC doing pathfinding for the first time is really slow but the results are cached so you’ll see the slowdown only once.

4

So, the problem is in the source code of Dan Menezes. Here is the source code in english with the changes I made to run it in Inform 7 (build 6G60):

http://media.textadventures.co.uk/games/t3ceAeL0VUGF22Ec1LLvyg/source.txt

Could be the problem these lines that I added at the end?

Use MAX_STATIC_DATA of 500000.
Use MAX_VERBSPACE of 5000.

Can you check the source code and give ideas about what went wrong?

Note: I didn’t use pathfinding but it has to be something related with that.

Thank you!

5

No.

6

Okay, I’ve looked at the Zork code you linked. (Compiled under 6G60.) It has the same slow behavior.

The problem is pathfinding, as Juhana guessed. It’s this line:

if the number of moves from the location to the bad place is 1 and the brick is off-stage, foo;

This has to do a pathfinding exploration of the entire map (the first time it’s checked).

(This is in the big “every turn” rule, which does a great many things. One of the things is the timer for a room collapsing after you set off the explosive brick.)

Here’s a simple way to improve it:

if the brick is off-stage and the number of moves from the location to the bad place is 1, foo;

By just reversing the clauses of the “and” test, we delay checking the map until after the brick has exploded! This will be just as slow, but it happens later in the game.

But it’s not necessary to measure the exact number of steps from point A to point B. You just care if they’re one room apart. So use a much faster test:

if the brick is off-stage and the location is adjacent to the bad place, foo;
7

There’s a second place that uses route-finding:

To decide what direction is the way through (frame - a door):
        let far side be the other side of frame;
        let way be the best route from the location to the far side, using even locked doors;
        if way is a direction, decide on the way;
        decide on inside.

This gets used in the description of the massive wooden door (the one with the placemat/key puzzle):

The initial appearance of the massive wooden door is  "On the [way through the massive wooden door] side of the room is a massive wooden door..."

This is really a waste of effort. The massive door doesn’t change direction. You could simplify it by simply checking the location:

The initial appearance of the massive wooden door is  "On the [if the location is Tiny Room]north[else]south[end if] side of the room is a massive wooden door..."

This might not work right for the case of peering through a crystal ball. (When “location” is not the room being described.) But it looks like the crystal-ball-peering case only shows the room description, not objects, so the initial appearance won’t appear.

(If you wanted to get the direction right in that case, you should special-case it rather than relying on a “best route from…” test.)

8

Awesome Zarf! Thank you for taking your time to solve this!