I’ve been reviewing some old code, and I’ve found a lot of ways to touch things up and a large game go faster.
The big one is probably getting rid of a pile of “instead” rules I had.
The other one I was thinking of is changing “if person X is visible” to “if person X is in location of player”. From what I remember of Inform code (at least up until recently), the “visible” code can get pretty complicated and slow.
Does anyone have any metrics/anecdotal evidence on if changing from “visible” to “in location of player” would speed a game up meaningfully?
Obviously this won’t work as well with carried items or items in containers, but for the vast majority, it seems doable. I’m just wondering if it’s worth doing at all.
Isn’t “visible” one of those words that mean something completely different than what you’d expect in Inform 7? I got in the habit of using “touchable” or “is enclosed by the location”.
Dunno if those are any more optimization-friendly tho.
In most contexts “visible” in Inform 7 means what I think it would mean–the player can see it, which is to say that it’s in scope. So that includes things in transparent closed containers, things in the next room that got put in scope manually, etc.
The place where it means something completely counterintuitive is in action definitions–“applying to one thing” means applying to one touchable thing, so it’s more specific than “applying to one visible thing,” when it seems like it should be less specific. And here “visible” means “anything that you could manage to refer to in the command” so it’s completely general.
Anyway! I do think that people have said that visibility checks are really computationally expensive but I don’t have any personal experience with it. The one thing is that “in the location” means directly in the location, no containers or supporters, so for some cases you might want to use Hanon’s “enclosed by the location.” Or define an adjective for “location of X is the location.” I’m not sure how fast location checks are compared to “enclosed by” and “in” checks.
It seems to me that the big thing is making sure that none of the edge cases that apply to visibility apply here. Like, if you’re using this for people, and no people are ever going to be in containers or on supporters, that’s a lot of stuff you don’t need to worry about. If you’ve got enterable openable opaque containers in the game, then there’s a lot of visibility that won’t be captured by checking what’s in the location (when the player is in the closed opaque container most stuff in the location won’t be visible)–but you probably don’t have enterable opaque closed containers.
Yeah FWIW IIRC while doing Cragne Manor we asked zarf what took the most clock cycles & he said visibility checks were significant & everything else was fairly trivial to roughly the same degree.
Thanks all! I don’t have a lot of opaque containers. “Enclosed” seems more what I’d want in some cases than “visible” since in a few cases something may be on something else.
I suppose I could, to save keystrokes, put in
definition: a thing (called th) is encl:
if th is enclosed by location of player, yes;
no;
I already do this for moot items e.g. ones removed from play because you’re done with it. (You all probably are aware of this, but in case newer writers aren’t, it’s handy. to have the opposite of “off-stage.”)
to moot (x - a thing): move x to DoneRoom;
to decide whether (x - a thing) is moot:
if x is in DoneRoom, yes;
no;
I wrote a small bit of code to see if there were any differences. It can obviously be more descriptive, but for those who are interested…
to visibility-test:
repeat with Q running through things:
say "[Q]. v=[whether or not Q is visible] e=[whether or not Q is enclosed by the location] t=[whether or not Q is touchable] n=[whether or not Q is near].";
Anyway, your views are appreciated. When I do my nontrivial code reviews, it always seems the organization lets something else pop out that should’ve been obvious before.
Since replacing “visible” on a mass scale is valid with little apparent drawback, this will be fun to try.
I had a little trouble recently understanding the fine distinction between enclosure and containment, so I wrote some test code to see how they worked.
“Enclosure Study” by Greg Frost
Use American dialect and the serial comma.
Laboratory is a room. The description of Laboratory is “This is your laboratory. It [italic type]encloses[roman type] [a list of things enclosed by the location]. However, it only [italic type]contains[roman type] [a list of things contained by the location].”
The workbench is a fixed in place supporter in Laboratory.
The lab coat is worn by the player.
The sack is a portable open container on the workbench.
The cupboard is an open container in Laboratory. “Next to the workbench is an open cupboard.”
Instead of examining the player, say “You enclose [the list of things enclosed by the player]. You contain [the list of things contained by the player]. You are carrying [the list of things carried by the player]. You are wearing [the list of things worn by the player].”
Test me with “x me / take sack / x me / put lab coat in sack / x me”.