Let’s look at these two pieces of code. First piece:
A piercing rule:
say "FAIL!" instead.
A piercing rule:
Now, the manual section 18.10 says
and it also says:
So these two pieces of code should be identical. Right? But they are not. If I consider the piercing rules, and then have an “if rule failed” clause, the clause will fire when the second piece of code is used but not when the first piece of code is used.
This leaves me confused. Is there an explanation for this phenomenon?
That makes me nervous since whether an NPC’s Check rule ends with rule fails or rule succeeds determines whether the Unsuccessful Attempt rules fire. A bare rtrue isn’t setting the success/fail value one way or the other.
Here’s another really useful heuristic based on how Inform works. I asked this in another thread but I’ll ask here as well: are any of these little design notes or design considerations documented anywhere? It sounds like the manual may not always be the best place to go for this kind of thing.
Interesting; I didn’t even see that Inform was in beta. Is the “Writing with Inform” or the “Recipe Book” manuals that come with Inform 7 not meant to be the equivalent of the older “Inform Designer’s Manual”? I think it still might benefit people for those who know the design heuristics to write them down in one central place. That central place can be updated if something changes as a result of moving from beta to general release. Maybe a wiki page or even a sticky forum thread?
Graham Nelson’s chapter in the IF Theory book seems to indicate that I7 is actually no longer in public beta, having “graduated” a few build ago. Still, I think that the primary development thrust remains on the software rather than on a complete retooling documentation, which as others have said will likely wait until the pace of addition of new features has slowed.
Given Inform 7’s emphasis on executable documentation within the manual, I would think it would actually be smarter to have an acceptance-based development approach, where the documentation guides the development of the software features. Then the documentation always serves as a true test, both feature and regression. It seems like this is sort of done but not as a full design process. So documentation should definitely come first but I also don’t really know the makeup of Inform’s development team. If the team has any understanding of agile practices, that would probably be the way to go.