As discussed in #24 and #25, the turn counter is off-by-1 at the end of the game, because normally the turn count is output before it is incremented, so turns_function outputs TURN_COUNT+1.

This pull request makes the game increment the turn counter before running the command handler, so that turns_function no longer needs to increment the value it outputs, so that both the value displayed by TURNS command, and the value displayed at the end of the game, are correct.

I also simplified the JP_HL function, I think this version works but it's possible I misunderstood something about its operation and have subtly broken something - happy to be proven wrong on that one. I'm not a Z80 assembly language expert.

I'm also not sure if you'll be happy with pushing hl, incrementing the TURN_COUNT, and then popping hl. You might consider it inelegant? It was the simplest thing I could think of, but again I'd be happy to be shown something better.

For the purpose of this bug I'm considering only the TRAPDOOR, however a similar process applies to the TORCH - we pretend we have state "TORCH ON" vs. "TORCH OFF", but instead have two objects "TORCH" which is unlit, and "TORCH-LIT" which has text saying "We're on".

At the moment we have two items in the game:

• TRAPDOOR
• TRAPDOOR-OPEN

When the appropriate action is carried out we remove TRAPDOOR from the world, and replace it with TRAPDOOR-OPEN. Doing the switch in reverse is difficult because if we tried to handle:

>CLOSE TRAPDOOR

We'd then use our find-object-by-name code and find TRAPDOOR, and never find TRAPDOOR-OPEN.

So we either need to rename the items, dynamically, allow aliases, or handle things in a different way. What we could do is remove TRAPDOOR-OPEN and instead use a state-flag to determine the state. This would be clean and easy:

• Each item does have a "STATE" flag.
  • We can decide "STATE: 0 == closed".
  • We can decide "STATE: 1 == opened".

The only problem with this approach is the description of the item. We do have an examine function pointer so we can use a dedicated "examine_trapdoor" function:

• if state == 0 : show "this is a trapdoor .."
• if state == 1 : show "this is an open trapdoor .."

The place where this falls down is the "LOOK" handler, which will not call the examine handler, so it will always show " the contents of the items description attribute.

Either we add a function "LOOK_fn" to call, or we have to manually update the pointer to make the appearance dynamic. I think the latter is possible, but it might be a pain to code.

Updating the pointers will add extra logic to the "use_xxx_fn" but in some ways that has to be easier than swapping locations and duplicating objects?

Cool game, thanks for making this!

I noticed a couple of typos while playing, which I've fixed here.

I also noticed that the turn count displayed after the end of the game seems to be off-by-1. The fastest speedrun I've found is "down; examine desk; get meteor; up" which I think you'll agree is 4 turns, but the game says I played 5 turns. I had a quick look and it looks like the turn count is incremented at the end of your turn, but turns_function adds 1 to it before displaying it, because the "TURNS" command displays it before it's incremented. Maybe we should move the check for whether you've won or died to at the end of the turn, but right before TURN_COUNT is incremented?

I should use the IX/IY registers to point to our object table, as this would make fetching items from it much simpler.

It'd be a lot of code-churn for little benefit, but with the aims of clarity it might be worthwhile. I'll make this wishlist on that basis.

Since I've been on a nostalgia trip recently why not port this "game" to the ZX Spectrum?

• We compile via pasmo which can generate appropriate images.
• Most of our code is pure assembly, our operating system interface is pretty much:
  • Read input.
  • Output string content.

It shouldn't be hard to move that over ..

I watched a volunteer play, and that was educational.

Some commands entered (which did not work as expected) included:

• [x] LOOK AT DOG
• [ ] PET THE DOG
• [x] READ THE BOOK
• [x] OPEN THE DOOR
  • (TRAPDOOR was meant)
• [x] SWITCH ON GENERATOR
• [x] TURN ON GENERATOR
• [x] EXAMINE ROOM
• [x] LIGHT THE TORCH
• [x] SLEEP
• [x] WAIT
• [x] LOOK AT BASKET

Other random comments:

• [x] Spelling: The boat is approaching - not "an approach ship"
• [x] Spelling: "I did not understnad that" -> "understand"
• [x] We agreed that invalid commands should not increase the turn-count.
• [x] The player did not even attempt to move, take, get, or carry the generator. She said "It was too big!". So it needs to be noted that this is both small and portable.

We need to implement custom behaviour:

• when an item is picked up. (e.g. RUG).
• when an item is used (e.g. MIRROR, and GENERATOR).

With those we can implement the rug/trapdoor puzzle, and setup a victory condition which makes the game "complete".

The GRUE could escape, if the trapdoor is left open.

Traditionally they're creatures of darkness, but covid-related mutations have been known to drive them out into ~scarier~ sunnier environments.

We have added a logical "invisible" state to the trapdoor. All of our objects are already allowed to be invisible, but they tend to be things that can't be interacted with, or fake-invisible so that you can access them if you know about them.

The trapdoor must be really invisible though, so it can only be opened/closed once discovered.

Add the third state, and use it appropriately. This closes #33.

We had accidentally left a pop hl instruction in-place as part of our state-update. That meant turning the torch off popped off the correct return-address, and gave us undefined behaviour.

This closes #34.

I think this is related to #33, and is caused by the cleanup we made when we used flag-states rather than duplicate objects (27eda49890919ae091123ec4d32d974dc413bba8).

Anyway:

• use torch
• use torch

Torch goes on, then when you turn it off you drop into undefined behaviour. (Missing ret?)

I'm writing this down not because I'm committing to making the change, but because it has been on my mind for a couple of days.

We started our implementation with the obvious commands "GET", "TAKE", "DROP". Each item in the item-table has pointers for those basic-functions. Later we added space for overriding the default behaviour. So TAKE RUG does something distinct from the generic take_command handler, which just looks up the appropriate object and stores it in the inventory.

After a while we augmented our command-table with synonyms. So for example these three commands both invoke the same use_command:

• READ BOOK
• USE TORCH
• OPEN TRAPDOOR

However this doesn't always make sense. Because "READ" is mapped to "USE" it is now possible to:

• READ GENERATOR
  • You win. (If you're in the right location, etc, etc).

It does make sense to have more commands than USE. However it doesn't make sense for those to be global. So perhaps our item-structure should change from this:

        DEFW item_3_name  ; torch
        DEFW item_3_desc
        DEFW item_3_long
        DEFB 0,0          ; No take function
        DEFB 0,0          ; No drop function
        DEFB 0,0          ; No examine function
        DEFW use_torch_fn ; USE TORCH
        DEFB 0            ; item state
        DEFB 1            ; this item can be picked up
        DEFB 0x00         ; top-floor

To something like this:

        DEFW item_3_name  ; torch
        DEFW item_3_desc
        DEFW item_3_long
        DEFB 5, "LIGHT", light_torch_fn
        DEFB 3, "USE", light_torch_fn
        DEFB 0xff

i.e. Rather than have the actions be global READ, LIGHT, CALL, DIAL, PHONE, we should scope the commands to the objects.

This feels logical, correct, and good. The downside is that we'd have to make a hell of a lot of updates to change it. The only real addition would be that we could say:

• PET DOG
• KILL GRUE

Without also allowing KILL BOOK, and PET TORCH. Which realistically? Nobody is going to type. I think.

There is still going to be duplication, because I guess we'll have EXAMINE xx and TAKE xxx for essentially all objects. That's why in my updated structure I still have name, description, and extended description. I guess I'll also need to keep the location field. And state.