Last time, I wrote about a need to create an improved magic system based on the mechanics in Repeat the Ending. As a reminder, that system, which wound up being fairly complicated, was one of the first things I wrote in Inform 7. After I learned more about making parser games, I found many opportunities for improvement.
More than anything, I was bothered by all of the nouns involved. I had nouns for sources of magic in the world, and other nouns for magic “carried” by the player. There was a lot of shuffling behind the scenes to put a noun in the player’s inventory, while omitting it from the inventory output (printed via the *INVENTORY* or *I* commands). There’s a helpful example in the Inform 10 documentation. Code omitting a specific kind of thing from inventory is pretty straightforward. The canned texts associated with printing inventory can be found in the standard rules.
The print standard inventory rule is not listed in any rulebook.
Carry out taking inventory (this is the new print inventory rule):
now all things enclosed by the player are marked for listing;
now all magics are unmarked for listing;
if no things enclosed by the player are marked for listing:
say "[text of print empty inventory rule response (A)][line break]";
otherwise:
say "[text of print standard inventory rule response (A)]";
list the contents of the player, with newlines, indented, including contents, giving inventory information, with extra indentation, listing marked items only.
Now, this all worked OK. Having a source of magic in inventory is something we can check during action processing. I could and did build rules around that sort of thing. However, there was already a value assigned to the player for magic on-hand. I had nouns that I was tracking for some actions, and values in a table for very similar operations.
siphontype is a kind of value.
The siphontypes are defined by the Table of Diagnoses.
After defining this value, I committed to the player having a “siphontype.”
The Entropist is a person.
The Entropist has a siphontype.
The Entropist is tinert.
What did the table look like?
Table of Diagnoses
siphontype diagstring
tinert "descriptive text to be printed under specific conditions"
Functionally, both the “tinert” value and the absence of magic in the player’s inventory amount to the same thing. From a programming perspective, I was just making problems for myself by tracking multiple situations, sometimes simultaneously, for one effect.
if magic is not carried by the player:
vs
if the player is tinert:
What would it be like to get rid of the nouns? Some things are pretty simple.
Instead of gathering something aphotic when the player is not tinert:
say "failure message"
But what actually happens after a successful action, if the game isn’t moving nouns around? It’s actually simpler, because we just need to omit code pertaining to nouns:
Carry out gathering the exemplary magic:
say "feedback text";
now the thief is amped. [amped is a value in our table of magic states]
Expending the magic is simpler, too.
Carry out xyzzying the real headless statue when the player is amped:
say "With a gesture, you send the darkness crashing against the stone. It quivers, contracts, then disappears in a murk.";
now the real headless statue is nowhere;
now the headless statue scenery is nowhere;
now the player is tinert.
This seems… pretty easy. I can just assign values for all of this stuff. Everything just works! What could go wrong?
The biggest problem is that players might want to invoke a form of magic in their commands:
*XYZZY THE HEADLESS STATUE WITH THE CRASHING DARKNESS*
Only in this example, the “crashing darkness” is a thing in the world, not a thing the player has. Let’s consider the construction of the “investing” action in RTE:
investing it with is an action applying to two things.
Understand "invest [something] with [something]" as investing it with.
That second [something] is the invisible magic noun the player is “carrying.” I did it this way, back then, so that there wouldn’t be any scoping issues. Since the player carries the magic, it is always where the player is, and therefore in-scope. What if the player gets the magic in one room, then uses it in another? It’s just a bog-standard bit of action processing.
Still, this is redundant, isn’t it? A player can only use magic they have. They can’t use things that aren’t magic as if they were, and attempts to do so require more checks and feedback messages. On paper, it makes sense to just make an action that uses whatever magic is at hand.
xyzzying is an action applying to one thing.
We might even add some nice conveniences. For instance, if the player attempts to use magic that is nearby but not yet acquired:
Check xyzzying when the player is tinert:
if a magical thing is in the location:
let the target be a random magical thing in the location;
say "(first gathering the [target])";
try gathering the target;
continue the action;
…and so forth. There probably won’t ever be more than one magical thing in a location (they’re all immovable scenery or backdrops), so randomization should be harmless. Still, since this is a “check” rule, I can always intercede with “before” or “instead,” should a particular situation demand it.
Back to the problem of commands invoking sources of magic, particularly ones in other rooms. I think the only real reason I have to worry about this is because players of Repeat the Ending will be used to something else. Since I welcome return players, I should consider their experiences!
I could add a column of nouns to my table of magic types, linking nouns to states, then convert such commands into the “correct” syntax. Another possibility would be rejecting the command outright. Or as a compromise between the two, we could drop the noun-matching idea and just apply the action to the first noun. In any case, scope will likely come up. Out of the box, Inform doesn’t let players act upon or with things that are not within scope (“visible” or “touchable,” depending on how the action is defined). I can’t just have a player gather magic in one room, walk somewhere else, then try to use it as a noun. It probably won’t be there, unless the noun is a backdrop in multiple rooms.
Cracking open scope for something like this seems like overkill, when the command structure isn’t built around using these nouns anyway. What are the other options? I could treat them as mistakes. Mistakes don’t care about scoping when dealing with verbatim commands, but they do seem to care about scoping when it comes to kinds. Something like this…
understand "xyzzy [something] with [magic]" as a mistake ("error message").
…isn’t going to solve scoping problems, at least not so far as I can tell. Accounting for every possible command, well, that would be a lot of text! I think mistakes are out, as valuable as they are. But I’m not turning back. No nouns in inventory this time! I just need to come up with some good messaging/handling to turn players to the new, simplified grammar.
next.
Letting the player down easy.

Leave a comment