Interpreter doesn't look after actions

[drewish]

Per your reference guide

• look -- Redisplays the description of the current room, the obvious exits and any visible items. This is done automatically whenever the player moves (with the goto action), gets an item from the current room, or drops an item. So far as I can tell, it need only be done
  explicitly when changing the value of the darkness flag.

But https://github.com/MikeTaylor/scottkit/blob/master/lib/scottkit/play.rb#L395 just updates the position. It seems that get and put are also missing the behavior of triggering a look.

One related thing that might be nice would be having some constants to link the numeric opcode to the more readable action.

[MikeTaylor]

I'll ignore the second part of this (symbolic constants for numeric opcodes), but feel free to file that ss its own issue: I'd like to keep issues atomic.

On redisplaying: this is slightly tricks. The code for ScottFree forces a redraw after 12 different op-codes:

• 52 -- Get item . Checks if you can carry it first
• 53 -- Drops item
• 54 -- Moves to room
• 55 -- Item is removed from the game (put in room 0)
• 59 -- The same as 55 (it seems - I'm cautious about this)
• 62 -- Item put in room
• 69 -- Refill lamp (?)
• 72 -- Swap item and item locations
• 74 -- Take item - no check is done too see if it can be carried.
• 75 -- Put item with item - Not certain seems to do this
• 80 -- Swap location with current location-swap flag
• 87 -- Swap current location value with backup location-swap value

(Although they don't always do this: for example, opcode 74 only forces a redraw if the item in question was in the same room as the player.)

But that works well in ScottFree because it uses a split-screen format where the description is always at the top, and a redundant redraw is harmless. (In fact, it could simply redraw after every single action, and it would be fine.)

In ScottKit, that would not work so well: in its conversational style, you really don't want a redescription of the room after (for example) every get or drop.

Also: I inspected the code for Adventureland and found that every goto (there are 15 of them) is followed by an explicit look.

So I think that, ScottFree behaviour to the contrary notwithstanding, the right thing is for a redescription never to be triggered automatically, and that the bug here is in the documentation. Does that seem right to you?

[MikeTaylor]

Hmm, but by the time of The Count (the fifth of Adams's games) things have got more complicated: some gotos, but not all, are followed by an explicit look.

i'm not completely sure yet what the right way is to handle this so that it works both for split-screen players like ScottFree and conversational ones like ScottKit. (Also: I have a vague plan to make a split-screen display driver for ScottKit at some point, so I will want to make sure that whatever decisions I make now won't make that more difficult when I come to it.)

Your thoughts are welcome.

[MikeTaylor]

OK, I think I have it. I need a "does the location need redescribing?" flag, which starts out false at the beginning of each turn. The various opcodes mentioned above will set it true (at least, under the right conditions -- as with 74 only setting the flag if the taken object was in the present location). After all the actions and occurrences have been processed, I need to redescribe the location if the flag is set.

Now here is the extra twist: the flag is actually tri-state. It can remain false, of course; or it can become "somewhat true" if, for example, you pick up or drop an object; or "completely true" if you move to another location. Why this distinction: in a ScottFree-like player where the description is always visible, it needs to be updated when the flag is even somewhat true; but in conversational players like ScottKit in its present form, you only want to bother the human with a redescription if the flag is completely true.

If that sounds right to you, I will file separate issue for this; and close the present one having only modified the documentation remove the lie that goto, get and drop imply look.

[drewish]

Your tristate flag makes sense to me. The issue I’d run into was using a locked door “open door” which used goto wasn’t triggering the look so it wasn’t clear I’d entered the room or what actions were available. I’d manually added look calls but that didn’t seem to work. It was late so I didn’t look into that aspect.

For someone who’s never messed with IF, I have enjoyed this quite a bit.

[MikeTaylor]

Manually adding look certainly should work! As I noted in an earlier comment, it's what Adventureland does all the time: for example --

action GO TRE when here tree
	goto swamp
	look

(So does the game I've been working on, a port of my 1982 VIC-20 BASIC game Nosferatu.)

Anyway, I'm delighted you're enjoying this. Let me know how you proceed!

[drewish]

So this not looking after goto is still a problem. Here's an example game:

room alley "*I'm in an alley next to an office. The door is locked. Perhaps I should knock?"

action knock door
  when at alley
    print "Someone opens door to let me into the office."
    goto office

room office "boring office"
  exit north alley

action look: look

And a play through:

ScottKit, a Scott Adams game toolkit in Ruby.
(C) 2010-2017 Mike Taylor <mike@miketaylor.org.uk>
Distributed under the GNU GPL version 2 license,

I'm in an alley next to an office. The door is locked. Perhaps I should knock?

Tell me what to do ? knock door
Someone opens door to let me into the office.
Tell me what to do ? look

I'm in a boring office
Obvious exits: North.

Tell me what to do ? 

[drewish]

Well re-reading the thread maybe the bug is that it's still documented as triggering a look after a goto?

[MikeTaylor]

Oh! Stupid of me not to have fixed the documentation!

I'll do that now (and in general feel free to send PRs if you find mistakes in the docs.)

But, yes, down the line I do plan to fix this properly along the lines discussed higher up. It's just not reached the top of my list yet. (For now, do like Scott Adams did in Adventureland and just put an explicit look in your actions after a goto.)

[MikeTaylor]

Fixed the doc. Code fix some time in the future.

[ahope1]

On redisplaying: this is slightly tricks. The code for ScottFree forces a redraw after 12 different op-codes:

• 52 -- Get item . Checks if you can carry it first
• 53 -- Drops item
• 54 -- Moves to room
• 55 -- Item is removed from the game (put in room 0)
• 59 -- The same as 55 (it seems - I'm cautious about this)
• 62 -- Item put in room
• 69 -- Refill lamp (?)
• 72 -- Swap item and item locations
• 74 -- Take item - no check is done too see if it can be carried.
• 75 -- Put item with item - Not certain seems to do this
• 80 -- Swap location with current location-swap flag
• 87 -- Swap current location value with backup location-swap value

I think ScottFree has missed out an opcode (for which to force a redraw) there -- namely, opcode 63: "63 -- FINI -- Indicate to the player that the game is over and inquire if he wants to play again" [src].

More details at IntFiction.