I try to figure things out on my own but am having trouble – still learning but still learning, unfortunately.
What I want to do is look up in a table the row that corresponds to a variable.
One table looks like this:
Table of Elevated Telescope Descriptions
grid (a number) UA UB Description
1 “unicode Greek small letter pi” “unicode comet” “Cepheus”
The value in grid is arrived at by moving the telescope around via joystick – imagine a grid in which the player moves the view around to different descriptions.
I have the mechanism correct in changing the “location” of the view, for example:
check pushing down:
if powerbutton is switched off:
say “Nothing happens.” instead;
if noun is not joystick:
say “I don’t understand what you want me to push.” instead;
if totalgridvalue > 39:
say “The machine buzzes.” instead;
increase totalgridvalue by 10;
say “The machine issues a pleasant ping and the picture on the screen changes.”;
continue the action.
This works, totalgridvalue changes in the manner and value that it should. What I want to do is look up the row in the table that corresponds to the value of totalgridvalue.
Hopefully this makes sense. Thank you for your help!
I think you want to read the section of WWI on “Choosing Rows” in the chapter about “Tables”. The syntax there should let you pick a row based on the value of your variable. There is also a shortcut using the idea of a “corresponding entry” if you only want a paired value from th row instead of selecting the whole row.
FYI, the structure of your rule looks a little tangled. I think you might be better off breaking it into several more specific rules. Also, some of the logic (for successful actions) might be better moved to other rulebooks like carry out, report, or after. Check the chapters on action processing for more details.
For example, you might organize the rule like this:
[code]Check pushing down when the powerbutton is switched off:
say “Nothing happens.” instead.
Check pushing down when the noun is not the joystick:
say “I don’t understand what you want me to push.” instead.
Carry out pushing down:
if total gridvalue <= 39, increase totalgridvalue by 10.
After pushing down when totalgridvalue > 39:
say “The machine buzzes.”
Report pushing down:
say “The machine issues a pleasant ping and the picture on the screen changes.”[/code]
Note that, with the exception of the check rules, you don’t have to explicitly tell the action to stop or continue. Carry out, and report rules automatically continue unless otherwise noted; after rules automatically stop unless otherwise noted.
Can you answer this, for my own knowledge – is approaching it in this manner preferable because of processing time (speed) or memory usage, or will it just overall function better by using this coding instead? Hopefully that makes sense.
I can’t speak for Mike, but my take is that it’s more about code structure, simplicity, and the possibility of reuse.
Reality isn’t always as clean as the theory, but the idea is that check, carry out, and report rules define the default behavior of an action. Check tests the preconditions that must be true before the action can logically take place. Carry out performs the action itself by modifying the world model. Report produces output that notifies the player about what’s happened. In theory, one could grab those rules and transplant the action into a different game.
Before, after, and instead rules are used to describe exceptions to this general behavior for specific objects and situations.
So, e…g, if we wanted to prevent an actor from dropping an object that they’re not holding, that’s a general constraint on dropping, so we’d make it a check rule (if it didn’t already exist in the standard rules). If instead, we wanted to prevent a player from dropping a candy apple that they’ve picked up because it’s too sticky, that’s a candidate for a before or instead rule, because it has nothing to do with dropping in general but rather has to do with an exception concerning a specific object.
Now, if we changed our world model so that all things can be sticky or not sticky, then it might make sense to add a check rule for dropping sticky things.
See §12.21. (Guidelines on how to write rules about actions) for more about which kinds of rules to write in different situations.
Taking a shot in the dark here:
Are you saying “choose row [number] in the table”, when your table is sparse (some numbers don’t appear in it)? The “choose row [number]” phrase takes the Nth row from the top, regardless of what value is in the first column. “Choose the row with a [column] of [value]” is better in that case.
Thank you for this! The answers may be obvious to some, but the way I learn is by understanding the why. This was better than any description I’ve read in the included manual, the PDF, and the book that I purchase on Inform. Which sucks by the way, there are like two pages in the entire book on tables.
I think that I still suffer from old programmer’s syndrome, if it exists – what exists in my head is a vestige of how I learned to code, back with BASIC. The multiple ways to accomplish the same goal can be a little weird.