This isn’t really a request for a hint, since I’ve already finished the game, but I have a lingering question. I ended up scoring 395/400 points, and naturally wondered why. However, according to the Invisiclues, all of the points are for tasks necessary to win the game. So it seems impossible to win the game with fewer than 400 points.
Anyway, my question is: has anyone had this experience with Enchanter, or have some other insight regarding the scoring that I’m missing? Or will this question nag me for the rest of my life?
Hm. Well, according to the invisiclues, the only task worth exactly five points is casting KREBF on the shredded scroll: everything else is worth more. And as you said, you need to do that to win.
Huh, I just looked at a points list and it looks like there’s only one action worth five points, and I’m pretty sure it’s necessary to winning the game. Do you have any saves you can go back to to indicate how many points you had at different parts of the game, say before the final confrontation? And where did you get the game file you played, in case it was nonstandard?
Oh, hmm. I’m looking at the source code, and I think the invisiclues are actually wrong about that one. You get five points for opening the egg, and ten points for repairing the scroll.
And you can in fact miss these points and still finish the game: you get the points for using REZROV on the egg or opening it with the mechanisms, but don’t get the points if you just smash it open to take the scroll.
I’m guessing that’s what happened. And you can, in fact, win the game that way—as I suspect you did.
Yeah, I didn’t know this before today! Another fun fact: because original-recipe ZIL didn’t allow changing the printed name of things, breaking the egg actually replaces it with a separate object, called SCRAMBLED-EGG. Fixing it does the opposite.
A bit off-topic but that’s not entirely true. There is nothing in ZIL that prevents you from replacing the routine that prints the name of objects with another, more flexible one. Below is an example that lets you specify a property SDESCFCN that prints the name with a routine. This example toys around with the adjective on the map but you could easily modify it to print a game-specific name instead (and as illustrated also change the synonyms and adjectives on the object). This isn’t beyond Blanks and Leblings capabilities but I guess it’s easier to use the method they used when you have objects to spare…
True; I should say, it’s within the capabilities of the Z-machine (and the programming language), but not within the capabilities of Infocom’s library.
A historical note on this, for others reading: in the design of the Z-machine, the printed name of an object is stored differently from any other string. It’s actually stored as part of the object itself! Instead of being a pointer to a string in ROM (like any other text associated with an object is), there are a few characters of text stored in the structure of the object in RAM.
This has no major* advantages and several disadvantages: the printed name takes up valuable RAM and cuts down on the number of objects you can use, but also needs a special opcode to print it (since it’s not a standard string), and can’t be modified (since there are no opcodes to do so). So Inform does it differently: it adds a “printed name” property to every object, which acts just like any other property and holds a pointer to a string in ROM. Instead of calling the special object-name-printing opcode, the Inform library just looks up that property, follows the pointer, and prints the result as a string. The characters in the object’s structure are just left unused.
This is why Inform lets you change the printed name of something in play, while ZIL (at least with Infocom’s library) does not. Which is actually a major source of bugs in early Infocom games, like the “boat of holding” in Zork: the inflated boat and uninflated boat are different objects (since they need different printed names), so you can cause all sorts of problems by putting things in the inflated boat and then deflating it.
* To be fair, Infocom games were much less RAM-demanding than I7 games. And there were a few advantages: having the printed name of an object stored in a specific place instead of leaving it up to the library means the interpreter can access the name with certainty. This was important in early Z-machine versions where the interpreter managed the status line, before version 4 made that the game’s job: it needed to be able to figure out the name of the location and such.
A semi-major advantage was that a property table lookup is kind of slow when you’re running on a 6502. The game had to do lots of property lookups, but printing object names was a common case, so avoiding one lookup per object name might have sounded like a good optimization.
