This post is to announce the pre-release of an updated version of my old IFComp 2002 game, “Photograph: A Portrait of Reflection”:
The reason for the update is that I recently encountered a fatal bug that made the game unfinishable while running it using Gargoyle/Bocfel. The cause was a programming error on my part that wasn’t picked up by the Inform compiler or available interpreters when I wrote the game. While Chris Spiegel has kindly offered to tweak Bocfel to accommodate my old game, I thought I’d revisit my code to see if I could fix it.
My problem was that I last touched the code of my only IF game over 20 years ago and, more importantly, that was the last time I’d done any significant coding at all.
Anyway, undaunted, I went in there and squashed the bug. Then buoyed by that success, I proceeded to revise the game to make some changes I’d planned for the comp release but never got around to - including providing an alternate ending for the story. Releasing “Photograph” in the comp with only one ending is something I’d always regretted.
While the changes to the game for this release are mostly minor, I can’t be certain my patented-but-now-rusty just-hammer-away-at-the-keyboard-until-everything-seems-to-work method of programming hasn’t caused further problems.
I therefore hope there are a few brave souls out there who are prepared to play through the new version of this ‘old school’ puzzle-light story-driven game and let me know of any major problems before I upload it to the IFArchive as the FINAL update. It’s an Inform 6 game that will take around 1½ to 2 hours to play through, and is fairly deeply implemented for a story-focused game.
I’ll look on it, but reading your history, I ask, what was, and what is now, your commenting strategy ?
I have many 20+years old WIPs (only a part “amnestied”) around, but for how I comment things around, reading the source (and comments…) generally is enough for putting back my hands on these codes…
Congrats on the re-master! I’ve played your game before and thought it was well-done. I think it has a good place in IF history, too; I recently wrote a history book about Interactive Fiction and mentioned it three times:
I very much enjoyed your book, particularly the emphasis on legacy through the early sections, and the more detailed analysis of the XYZZY winners.
You’ll find the story in the new version of ‘Photograph’ to be little changed from the one you played previously. It’s mostly a bug fix release, which also addresses some areas of clunky implementation, together with tweaks to some thematic elements, notably, of course, the ending.
Given how long it’s been since I’ve done any programming and that I was using a newer compiler, I thought it wise to try to get more eyes over the thing before signing off on it as a final release.
I’d certainly appreciate it if you do find time to give it a quick run through.
I was a self-taught programmer, and unfortunately forgot to teach myself the value putting “comments” in code. As a consequence the thing is almost comment free. Personally, I blame the teacher, not the student for this oversight.
Not that it probably made much difference. After 20 years of being a non-programmer, coming back to it was never going to be easy.
I just played through it (in about an hour and a half, like you said) and enjoyed it; I think it holds up very well, and if anything is more in vogue with current trends now than when it was released. I only found one thing that might be considered a bug (a single line break was missing). I’m uploading my transcript here (with comments indicated by a *):
I’ll spend some time going through your transcript to find areas where I should have handled things better. One example that springs to mind from a quick glance is that I should have provided timed reminders about the fire burning low at the end, in line with the other prompts towards the end of the story.
The ending you arrived at was the new one. The idea is that the path through the end of the game is the same, but with a random ending. I thought of providing more random endings to represent the different ways Jack’s life could have played-out from that moment at the waterfall, but having two possibilities that were different to the future he’d imagined for himself seemed enough. The problem I had with the single ending of the original comp entry is that it invited criticism of the game being “irredeemably fatalistic” or Jack being doomed by his very nature to repeat his mistakes. That was something I hadn’t intended. So it became important to also provide the possibility of an ending that undermined his conviction that he and Mel were destined to live a happy life together, but that still allowed for him to have a fulfilling life.
To arrive at the other ending you can just Undo at the end of the game and replay the last action, or replay from an earlier Saved game. The option to see the text of the alternate ending is also given on the final screen (added 29 Oct).
Thanks again for taking the time to revisit “Photograph”.
Just out of curiosity, would you mind elaborating on the original bug, and its fix?
It seems that the crash is caused by an attempt to use the @put_prop opcode with a property that is larger than two bytes (at address 0x12e23 in release 5.) Will the original game work as intended if that line is just patched out and replaced by @nop, or is there a better fix?
EDIT: To partly answer my own question, simply NOPing out the entire line seems to cause a disambiguation problem at the final action, but the game can still be completed.
The instruction that was generating the error was: photo.name="";
Removing it and recompiling allowed the game to be played to completion in Bocfel.
When I tried to work out why I’d written it I found unresolved disambiguation issues resulting from having two nearly identical objects, ‘photo’ and ‘brokenphoto’ in scope at the same time.
EDIT: I’ve fixed the disambiguation problem in the new version, although perhaps not elegantly.
This is a bad idea in I6 anyhow. The name property is supposed to contain dict words, not strings. Having the empty string in there will likely be harmless, but there’s a chance that it could be the same value as an existing dict word, and then you’d have a really tricky bug to track down.
Just as a quick note, the next Bocfel release will relax the requirement for @put_prop taking a 1- or 2-byte property. Larger properties are undefined per the standard, but almost all interpreters just treat values larger than 2 as 2, writing a word. So Bocfel will do the same.
The source of this particular bug (photo.name="") is something easy enough to write, and while newer Inform versions produce a runtime error, older ones seemingly didn’t; so it’s reasonable to think there are other games out there with similar, undiscovered bugs. This is my attempt at a proactive fix (plus it’ll get the original comp-version of “Photograph” working again).
