Mystery House, Excavated: Blog post about how Mystery House works

I’ve posted a lengthy (LENGTHY!) blog post about what I learned about how Mystery House works while rebuilding it from scratch (see here).

I consider this to be an independent project from the coding part, so I hope there is no problem with separating it out into a new post like this. This analysis probably appeals to a slightly different crowd. This addresses all sorts of interesting questions like…

  • What fonts are those?
  • Did that spiderweb disappear when I opened the door?
  • What’s going on with the room items when I drop an object?

and contains tantalizing imagery like…

and…

7 Likes

Fantastic stuff. Enjoyed reading the article.

I didn’t quite understand the problem about the scenery drawing. However, it was common in early games to have two items in place of one. Say one for scenery and one for “gettable”, and swap them accordingly.

1 Like

Thanks for reading, and I appreciate your feedback.
I think I need to rewrite that section of the post; I haven’t quite succinctly explained my problem, I think.

The issue isn’t so much about how objects move from scenery to inventory. It is that there seems to be some other mechanism that can temporarily hide scenery objects, but how that is triggered is unclear.

For example, in the Dining Room there is a candle on the table. If we leave it alone and open the doors, the room image is updated but the candle remains. This is expected behavior and matches the extracted game logic.

The button and picture should be the same. In the extracted logic, “PRESS BUTTON” changes the room image, and that’s it. There is no explicit code to hide the button and picture, yet they do hide and reappear in original scenery position when “PRESS BUTTON” is pressed again.

So there is probably some game logic that is yet unextracted that handles this case, but I’ve yet to find it.

This sounds like a silly thing to focus on, but if I can find a concrete explanation for why the picture disappears/reappears then that could mean that “PRESS BUTTON” without removing the picture is NOT a bug, but an intentional part of the game design.

I see. that’s interesting. Are you sure there’s no feature to paint lines in black or something, so the picture can erase as well?

I’ve seen no evidence of that being available, as it runs counter to the method used to compress images (line drawing only) and I see no visual evidence of such drawing anywhere in the game (“MOVE CABINET” would surely have utilized the trick, I think).

One could absolutely imagine special cases to draw a black rectangle to obscure things in certain conditions. The problem here would be that the draw order would not allow for what we see. The room is drawn first, then the scenery object. If a black rectangle were obscuring the picture, we should see the picture come on screen then get obscured (running emulator at half-speed to watch draw order). That doesn’t happen, plus the rectangle would obscure room picture elements, given draw order and the position of the picture.

This talk made me realize I hadn’t tried something very obvious.

If I “PRESS BUTTON” before messing with the picture, then I should be able to “USE BUTTERKNIFE” on the picture anyway, even though the wall is open and the picture is not on screen. This does work.

Interestingly, if I then “TAKE PICTURE” I’m told “I DONT SEE IT HERE”

This means the picture object was either removed from the room by… some code… somewhere yet to be discovered? Or, perhaps there is a flag on objects for “is_hidden” that is toggled for the picture/button? Either way, there seems to be code that was included for this case alone.

<I think I’m wrong on this>

In either case, the fact that both picture AND button adhere to this rule says to me that Roberta intentionally allowed the button press as a short-cut for players.

I’m going through a memory dump and cataloging some new details on objects. Objects have a property that is one of three states. I think whatever mechanism hides the button and picture on “PRESS BUTTON” is actually just hiding all elements of the room with a 0 state (which seems to indicate “scenery state”). I still haven’t found the mechanism for this, but at least there is an explanation to explain objects in rooms better.