last time, on Let’s Make IF…
These past few days haven’t been very eventful. That’s good! It means that a lot of the up-front work for printing variable texts has paid off. I’ve been able to focus on text instead. I also implemented a lot of cat behavior (a kind of action named “performing cat behavior” in-code). I think we are ready to close the books on Act I.
Should I be thinking of descriptive names for the acts? The scene index (if you’ve been copying source into your own IDE, have a look for yourself) would be more readable, so my answer is probably “yes.” I’ll add it to my to-do list.
the end of act I.
Act I is already finished, technically. I wrote the descriptive text for examining the box yesterday. Now, I need to go back through, checking responses for everything.
For more comfortable reading, I’ll do a test release that I can read in a standalone interpreter. You can use my gargoyle config file if you’d like to check it out (you may need to change the “zoom”, mine is high at 2.5). For some reason, it’s just easier for me to read the text as text in Gargoyle or Lectrote. I think that’s because when I’m using the IDE I am looking at it from a technical perspective, i.e., does it work?
It’s easier for me to pick up on things this way. I’m looking for things like this:
The stage was cluttered with strange shapes, and they all seemed to glob together in the dim, gloomy light.
What’s the problem here?
understand "weirdness/piles" as the prologue clutter.
That’s right! I need to add “shapes” as a synonym for the clutter. This is the kind of thing that’s easily missed in the flow of coding and writing. I’m able to pick up on quite a few things this way. I also have some things that have no description. That’s bad! The documentation has something whipped up for checking all items for descriptions:
understand "desc" as a mistake("[VERDESC]")
To say VERDESC:
repeat with item running through things:
if description of the item is "":
say "[one of][or][lb][stopping][item] has no description[dot]".
I’ve made some minor tweaks. I don’t want it to run when play begins, so I made a “mistake” that would execute it. Mistakes are great for debug stuff! Sorry about the word salad before the “[item] has no description” bit. Inform 7 spacing is hard to manage (don’t let any *EXPERT* tell you different), but it matters enough to me that I always make the effort. Output as of right now:
>desc
aisle has no description.
My human boy, D has no description.
bright orange traffic cone has no description.
exit doors has no description.
bag has no description.
color has no description.
miznian hardwood has no description.
The docs mention Object Response Tests by Juhana Leinonen. I haven’t checked it out yet, but I mean to. That extension covers a bunch of standard commands, which is bound to be handy. But what about all of my cat behaviors? Right now, it’s printing a lot of empty text. I could get rid of that by making generic “report” rules. But do I want that? This will do the job for now.
understand "vercat" as a mistake("[VERCAT]").
To say VERCAT:
repeat with item running through things:
if the item is touchable:
say "[one of][or][lb][stopping][bt][item]:[rt][lb]";
say "smelling: [run paragraph on]";
try smelling the item;
say line break;
say "biting: [run paragraph on]";
try biting the item;
say line break;
say "pushing: [run paragraph on]";
try pushing [pawing] the item;
say line break;
say "hissing: [run paragraph on]";
try hissing at the item;
say line break;
say "listening: [run paragraph on]";
try listening to the item;
say line break;
say "marking: [run paragraph on]";
try marking the item;
say line break;
say "[rt]meowing: [run paragraph on]";
try meowing at the item.
I wanted to limit this tool to checking touchable things. We’d get a lot of garbage output otherwise because almost everything is “visible.”
Between these tools, I should be able to chase down missing implementation and output in a systematic way.
but wait, there’s more.
Speaking of keeping track of things, I’ve decided I want to track certain types of actions. I don’t want to explain too much here (if I talk about every design choice, you won’t play the finished game <3), but we can look at the method. I’ll start with a recipe from the documentation, “Bosch [#219].” That example starts with a very big rule:
after doing something:
I like it! For one thing, using this approach means that I will have to take the relevant actions all the way through action processing. “Instead,” that old beginner’s favorite, shuts down action processing, so “after rules never fire. Taking this approach means that I have to let actions take their course. That’s best, in the long run. “Instead” can prove to be very limiting once your game reaches a certain level of complexity. Eventually, many authors will need the multiple points of entry that a full turn of play provides, even if that isn’t obvious at first. I will tone this rule down a little, but not because I dislike the scope. I just want to leave room if I want such an all-encompassing rule later. Dialing it down:
after performing cat behavior:
There. I already have a kind whipped up for this sort of thing, so I’ll just slot it in. Reading the example code, it looks like I’ll need a table.
Table of Feline Actions
relevant action turn stamp index
scratching the exit doors -1 (a number)
meowing at the bag -1 --
Mine looks a little different, doesn’t it? I’ve removed the “value” column because this isn’t a Zork-inspired scoring system. I’ve added an “index” column because it’s easier to enter the twin dashes as I go, rather than adding them later. Theoretically, I could use it to return the table to its original order after a sort. I doubt I’ll ever need it, but there’s no harm in including it.
Back to our rule:
After performing cat behavior:
repeat through Table of Feline Actions:
let the listed action be the relevant action entry;
if the current action is the listed action:
if turn stamp entry is less than 0:
now the turn stamp entry is the turn count;
continue the action.
There are few differences between my rule and the one in the example. I use a “let” assertion to make the actual gist of the rule more obvious. I also tree it out for readability (the example has the action check and the turn stamp check in a single statement).
What’s happening? Every time cat behavior is performed, an “after” rule will check that action against a table. If there is a match, it will check the turn stamp entry, and update it if the current entry is “-1.” Just to have a number, I’ll create a new number, “cat index,” and use the rule to increment it when cat behavior is performed (just the once, when the turn stamp is -1).
There! I’ve got a number to use for my own insidious purposes.
next.
Act II begins! It’s a very short sequence, with only two important actions. I’ll have to allow for some exploration along the way, of course.
top expert 