Yeah, Bob Hund aren’t known anywhere beyond a small group. Best example I can give. 
The Soundtrack of our Lives are better though, wouldn’t you agree?
I’ve met both, fwiw. Anyway, …
I finally got around to getting a new website, so IF Gems has a home again now:
Vaughany, feel free to keep that copy on your website if you want to!
Thanks, I will, and I’ll edit the link to point back to your new website too.
Sorry, I was unclear. My point was that while it is a fair criticism, phrasing it in terms of “IF-hater” or “accessible to new players” glosses over the fact that these same criticisms appear (albeit with different terminology like “world model” or “hinting”) from players who are not at all newcomers to the medium, but rather the exact opposite. In this case, the theoretical IF novice’s review is making the exact same observations as the most diligent and IF reviewer on the internet. Again, I don’t want to be a scold about “review quality,” considering the number of released games out there. Just wanted to point out that we as a community, fixate on relatively shallow implementation details, often to the exclusion of all else. We review point and click adventure without getting hung up on “this object looked kinda important in the art but had no custom description,” or an exploration game getting dinged on “I was able to run REALLY far, but eventually I hit an invisible wall.”
First off, there are certainly bugs in A Long Drink, and every single reviewer, yourself included, who said that it was scoped too big for the time allotted was 100% right, and I will never argue with that. It’s also very true that it’s really hard in IF to differentiate a bug from intentional behavior from a narrow implementation.
This is absolutely something I want to bring up, especially about parser IF. I’ve seen reviews for years where new IF entries are reflexively compared to the best in breed from decades of work. “Good atmosphere, but not Anchorhead. Good puzzle, but not Threediopolis. Good NPC, but not Galatea. Good prose, but not Coloratura.” What message do we send for parser IF if it is essentially not enough to tell a good story, but you must literally push the medium out of what it’s capable of, but also follow all the conventions of the established orthodoxy?
Authors now have a choice between Twine, where even short and sweet games get positive attention and buzz, and Parsers, where for your trouble, you can expect a list of verbs and nouns you forgot after months of work. I don’t want to place blame at the feet of reviewers here, just that “try and think of everything a player would” and “let some friends mess with it” is not a regimented approach to writing prose OR software, and if it works out for you, you’re pretty lucky.
This is at the core of the problem with the way IF is currently “sold” to authors, especially Inform 7. This has been brought up before, but “don’t be scared if you can’t program, just write!” is incredibly misleading around the fact that you are writing software, and you need ways to test software that are rigorous and systematic. Setting 20 people loose to play around in a game unstructured isn’t QA or unit testing, it’s a tiny closed beta. The best you’ll get is the few IF old hands who’ll try to break things, and that’s an adversarial test that might produce slightly more data.
This is exactly what I’m talking about.
I take issue with this mainly due to the stuff written above. DOOM wasn’t written with unit tests, but the field of game testing can’t be built assuming everyone codes as well as John Carmack. Put another way, as a rule, people don’t write good software, good systems produce good software.
Here’s the thing, though: There is no substitute for user testing, and there are things you just can’t write software to test for. Consider the problem of objects in room descriptions not being present. How would you go about building a testing suite to ameliorate that issue?
A naive version of that might simply use an English dictionary to look for nouns in every room description, and then check if an object is present that corresponds to that noun. However, this approach is profoundly flawed. Here’s a room description from Terminator Chaser, with every noun bolded:
Now, how do you even begin to write an algorithm that can extract the signal from the noise, here? We start with all the nouns that refer to the same thing, or to various vague things that would be the same in-game object: Plants, bonsai, apple, trees, flowers. Then we have stuff, which refers to a thing that’s present, but it’s unclear whether the parser should accept that as such. Then we have the nouns for abstract things: system, purpose, fight, company, union, value. Sure, you could build a dictionary to differentiate between abstract and concrete nouns, but that distinction is actually totally contextual. For example, I have the word “systems” in that description as a vague abstract that a reasonable player wouldn’t expect to be able to refer to in the context of EXAMINE. But, of course, that selfsame room holds an object called the Life Support System. In the actual game, that thing isn’t scenery, but it could be; so how do you write a test suite that can differentiate between my usage of “system” to refer to a vague, not-visible thing, and a usage of “system” to refer to a specific, visible thing?
And then you have nouns like atmosphere that the player doesn’t expect to be able to EXAMINE, but perhaps (I realise now, too late) they might expect that SMELL ATMOSPHERE should work. Not even getting into issues of, how is it supposed to know that “reactor core” is one thing?
At best, we could have a sort of reminder/todo list that would highlight nouns that are “dangling” in room descriptions. If anything this would probably be worse than Aaron Reed’s practice of wrapping every (concrete, present) noun in [brackets] so that the compiler throws an error if an object doesn’t exist to represent it.
Ultimately, some problems can’t be automated away - it requires actual mental discipline, care, and time to ensure that the world model is consistent for players. On many levels this is not unlike writing regular fiction - if a character’s outfit is described as dark and conservative in one page, you don’t expect it to suddenly become a red cocktail dress with a plunging neckline the next. But you couldn’t write a tool that would automate checking for that inconsistency. I like TDD as much as the next Rubyist, and I do wish IF development systems had better testing tools (Maybe now that I have some free time I’ll write I7Spec), but I don’t think you could write a toolchain for I7 that would effectively safeguard against world model problems.
I have various thoughts, but in brief:
The average parser game is absolutely far more difficult to build, and much likelier to be buggy, than the average Twine game. I don’t think many people here would dispute this at all. Parser IF is not the easiest path to getting an interactive story out there in the world, or to gaining recognition for your work; in my view the only reason to do it is that you really, specifically want to make a piece that uses a parser.
Talking about testing tools for parser IF is cool and I am up for that. I regret that you had trouble with the I7 extension situation; my understanding is that there are people who are working on that, at this point.
I do share Sequitur’s feeling that some of these things cannot really be automated; when it comes to noun implementation depth, a lot depends on the skill of being able to look at a sentence and think, “right, what’s missing here? if I were the player, what would I type? which of those things isn’t covered? do I want to implement, or do I want to rephrase this text so the problem doesn’t even arise?” It is possible to gain some instincts around this with practice, and the Bracket Every Notable Thing approach is an attempt to systematize it, but ultimately this is still an expression of the “think like a player” advice that you called out as unhelpful.
I am also up for ceasing to review games when most of what I would have to say is potentially discouraging, as I’ve said.
Still, please don’t make more of an interview from 2004 than it deserves eleven years later. As I’ve already pointed out, that was a long time ago, a lot of my views have changed since then, and I’ve talked repeatedly and publicly about how and why they’ve changed. I would be less quick than I was at the time to even partially dismiss novice problems with the parser.
Finally, I disagree that implementation details qualify as “trivial” at the point where they break the game for the player.
The IF parser is probably the most finicky, context-dependant, obtuse UI system ever invented. When you set off to write a parser game, you’re basically taking on the task of making that work well, and it’s not particularly easy. The I7 world model and parser are the product of years of advancement in that field and even then they will only take you so far without fine tuning and help from the author. Consider that the Interstellar text adventure game, which presumably was developed for a not insignificant amount of money by a team of professionals, had a really clunky parser (I was a little mystified that they opted to hand-roll a parser in JavaScript, I wonder how aware of the state of the art in IF that team was).
Actually it seems like the text adventure was just written by the movie’s executive producer, which makes it seem more like a labor of love/lark.
I’ve heard the phrase “world model” quite a bit, and that’s part of my frustration as well. Does it mean the way Inform 7 turns code into objects and verbs? Does it mean the way the author intended the player to interact with the game? Is the entire issue that the default Inform7 message is “that object isn’t here” when it could just be “I saw nothing special about it”? You mentioned the difficulty of automatically finding nouns, but at the very least, maybe an extension that could assume mentioned nouns are scenery without descriptions maybe? Or a pre-compiler check similar to Lint that does this first?
I love parser IF. The alternatives now available are great, but I want to see more people get into writing parser work because selfishly, I want to play more parser games. The problems with I7 are myriad, and the extension situation barely covers their breadth, and many other threads discuss it far more completely than I can here.
Sorry, the only thing I wanted to make of it was that in it, you mentioned a criticism that novices have about parser IF. In my experience, it is also a criticism that people well-acquainted with IF still make today.
Indeed, though the point at which that happens is subjective enough that one could argue that it’s partially a case of managing player expectations rather than a purely objective measure of quality.
Strictly speaking, world model is the game’s internal representation of the story fiction, in terms of content and logic. To exemplify, consider a room where there’s a rope that lets you swing on it to another room. A game might just implement that as a special message when you GO from one room to another. Or you could fully implement the rope as an interactive object, allowing players to pick it up (And making them let go of it if they try to leave with it), tie objects to it, burn it, and so on. Even though the basic fiction is the same (The player character will swing on a rope to arrive at the next room), the latter has a substantially more complex and sophisticated world model.
To give another concrete example, Terminator Chaser implements a set of general rules about air flow, which governs whether a given room has atmospheric pressure or not; those rules are part of the world model for that game. Every object, rule, action, and parser behaviour is part of the world model.
If you’ve played a tabletop RPG, you can think of the world model as being analogous to the game’s rules. In parser IF, the fiction is what the player receives from the game, and the narrative constructed from that output. The world model is the underlying computational reality that the player is interacting with. One major point in parser IF is that it allows for fiction-model mismatch to happen very severely and easily, but that problem is by no means exclusive to parser IF. An example of fiction-model mismatch in a graphical game is finding an invisible wall at the edge of the level in a place that looks like a passage that you should be able to go through; or conversely, finding that a visible wall doesn’t actually have a collision box, so the player character can just clip right through it.
Fiction-model mismatch is a jarring, immersion-breaking experience that players find confusing at best, infuriating at worst. The player’s experience is fragilely contingent on them thinking about the game in terms of the fiction; which is to say, they’re not thinking in terms of game-object states but in terms of story actions taken by their player character (ideally and conventionally). So you can think of fiction-model mismatch as a sort of cousin to the problem that crops up in tabletop RPGs where players feel compelled by the game mechanics to behave in ways that are nonsensical in the fiction, and other forms of “immersion-breaking”. It’s a violation of the magic circle, essentially. If a game consistently and frequently causes this issue - especially if there’s some specific error that crops up again and again, or if every turn seemingly brings new issues - we say it has a broken, or flawed, or bad world model.
All of those things are examples of common fiction-model mismatch issues in IF:
- Objects being mentioned as present, which the player can’t examine or interact with.
- Objects not having the properties they’re implied to have (For example, not being able to see what’s inside a glass terrarium)
- Actions not producing results that are sensical (For example, being able to pick up and carry a person)
- Spatial relationships being obtusely established (For example, non-reciprocal room connections or room connections not being visible to the player at all)
- Text being generated which is absurd (For example, an NPC who’s somewhere else in the map talking to the player as though they were in the same room)
- Default library messages being left in place which contradict the fiction (Eg, player character is an invisible ghost, but X ME still leads to “as good looking as ever”).
- Text being outputted which contradicts the narrative viewpoint (Eg, text written in second-person present being written by a game that’s normally in third-person past)
The problem with trying to develop a linting tool of some kind to detect fiction-model mismatches is that this is a phenomenon that arises from a disconnect between the fiction and the world model. And you can’t write software to understand fiction, so you can’t write software to detect this mismatch. At best, you can write general rules to check for common mistakes, but almost every common mistake is a feature of some game or another. You can’t pick up NPCs… except in the game about Grognar the Barbarian with 18/00 Strength. You should be able to see inside glass containers… except when wearing the infrared goggles. Map connections should be reciprocal… except in the maze. NPCs shouldn’t be able to talk to you from across the map… unless the player character is a telepath.
Distinct from world model issues, but often lumped in together because works with one type of issue often have the other, are parsing problems. Parsing problems come in many forms:
- Actions not supporting common synonyms (Guess-the-verb)
- Objects not being referred to by all the same words the game itself uses (Guess-the-noun)
- Not enough variants of the same verb being implemented (Guess-the-preposition)
- Verbs not allowing a second noun when one might be expected (Eg, CUT CORD works but CUT CORD WITH SHEARS doesn’t)
- The converse situation, where using the verb with no second noun fails utterly (Eg, CUT CORD WITH SHEARS is implemented but CUT CORD doesn’t say “what do you want to cut the cord with?” or similar)
- Parser error messages that are uninformative (Eg, CUT CORD WITH SHEARS doesn’t work because the verb isn’t implemented with a second noun, but the message it produces is “You can’t see any such thing”, which is confusing in the extreme)
- The parser being obtuse about what the player means (“Do you mean taking the lemonade or the lemonade stand?”)
- Situations in which player commands can’t be disambiguated, or in which asking for disambiguation is meaningless (“Do you mean taking the ball, the ball, the ball, or the ball?”)
- Objects that are not described by their visible properties, especially in situations where disambiguation is involved (Eg, in a game with various coloured balls, TAKE RED BALL doesn’t work)
(Neither of these lists is exhaustive)
And again, you can’t meaningfully write a linting tool for parsing issues, because they’re contextual. Different games want different interpretations of the same verb. At best, you could get an integrated thesaurus which could find other variants of a given verb and automatically put them in as synonyms, but most of the issues I described above are not problems that can be automated away.
One technique that games have used, which is considered generally acceptable, is to set the standard library message to “You can’t see any such thing, or you don’t need to refer it to complete this game.” (Or something similar). This is fairly common, but there are two caveats. First, any guess-the-noun situation becomes much worse, because the player will be explicitly told, “this thing you’re trying to refer to isn’t important.” This can lead to amazing frustration when/if the player finds out that no, the thing IS important, it’s just missing a synonym. The second is that players will still find the world model inadequate and sparse if they see that message too often.
Tooling is great, but world model and parser issues can’t be solved purely by tooling. As with any instance where correctness has to be defined by the implementor, ensuring correctness is the implementor’s responsibility. Or: since we can’t produce a general definition of what correctness is in terms of parser or world model quality, it’s up to implementors to ensure correctness.
1 Like
Right, or having an object in an adventure game that looks important due to the way it’s colored/lit, but isn’t. My issue is that in the parser playing community sometimes seems to have a sense of entitlement about exactly what they should and should not be able to examine and interact with. Do we need every author to make every environment a sandbox because this is what players expect, rather than a passage? Is the alternative to demand that authors create spartan areas, for fear of disappointing these demands on scenery? Similarly, much has been written about “NPCs are hard, and parser players demand incredibly in-depth NPCs.” But why is that? Graphical games have invisible walls and mis-hinted objects, but these generally don’t take center stage in reviews. RPGs are chock full of NPCs who bark out stock phrases ad infinitum like “My village is the best one in all the kingdom!!” and yet this isn’t considered a fatal flaw in any reviews I’ve read. For goodness’ sake, more than one recent NPC writing guide in IF has concluded with “It’s too hard, here’s how you can get around the issue by making the NPC not bother talking to the player at all, or just hide them entirely.” I think that is a really backward state of affairs.
As a matter of best practices, is there a good way to screen and customize all the default library messages for such a scenario?
No, I meant in this case JUST for the nouns involved. Like compiler warnings saying “The following nouns have no object or empty scenery object associated with them.”
So there are plenty of types of bugs that automated tools can’t catch. My point is just that there are so few testing methodologies for parser IF, that authors are forced to waste time finding those that are.
The only thing a lint would easily pick up on IMO is missing scenery. Maybe you could hook it up to some Markov chain text generator and find verbs that people might commonly use with those nouns to go a step further. But I never meant there’s going to be one-size-fits-all bugfinding for IF. I just meant that there needs to be testing frameworks given how complex this stuff gets. Like you said, is everyone just supposed to do this by hand?
ETA: I was typing this while apparently Sequitur was typing their take; there’s some overlap, but it may be interesting which things we both pick up on and where we diverge, so I’m going to leave this as is.
The world model refers to what has been implemented in the game world – the objects, the rooms, the variables that describe the features of those things. The world model is the representation of that-which-is-true in the game at any given time. Inform’s default world model includes concepts like rooms that can be connected by doors, and containers, and supporters you can put stuff on, and people who can carry out actions. TADS 3 has, by default, a more complicated world model which includes things like “container that is permeable to light but not to sound.” All IF games add some things to the default world model of whatever system they’re using – whether that’s just a few custom objects or many newly-created additional kinds of thing. In a game with as much plot going on as yours has, the world model is probably also encoding information about things like “what scene is it right now?” and “what is allowed to happen during this scene?”
Inform uses the world model to determine what its responses to player behavior should be; but if the world model information doesn’t quite match up to what’s been implied by the narration, the player can get confused and lose faith that she’s interacting with a coherent system.
At the low end this is (as you imply) not really a big problem. Having a room description that says “It’s a cloudy day” and >X CLOUD responding “You can’t see that here” is a minor disjunction between world model and narration. The player’s drawn an assumption about what should be present, and checked on it, and the answer is that the author didn’t think that the clouds needed to be specifically implemented. And – despite the apparent nitpickiness of reviews – typically IF veterans will see that response and shrug and move on, thinking: right. Clouds not important. Next?
It’s more of a problem, though, when you’ve got a room description that names a number of concrete physical items and you explicitly tell the player to search the vicinity for clues, and one of those physical items is key to the story in some way, and the others are “you can’t see that here” things, or else have names that don’t match up with what they’re called in the room description, so that they might as well not be implemented as far as the player is concerned.
Now what’s happening is that you’re sending the player conflicting messages about goals and gameplay. On the one hand, the narrative and the design of the game are saying “you have to search stuff to make progress, so you should probably read the room description carefully and start checking out objects in this room” but when the player tries this on the obvious visible objects, she keeps getting “you can’t see that here”, which suggests that she’s doing the wrong kind of action or doing it to the wrong kind of object.
Is she doing the wrong thing? She’s not quite sure. The game could be buggy or lightly implemented, or it could be that she’s supposed to be doing something other than examining the nouns in the room description. Maybe she’s supposed to be wandering around or talking to NPCs or something else? If some concrete objects aren’t important and some other, very similar concrete objects are important, it’s very hard for the player to construct her own internal model of how your game works.
Another point of player expectation slippage in A Long Drink: the scene where you unbuckle your seatbelt. Unbuckling seat belts is a totally obvious thing to do in this situation, in normal-human-think, but there aren’t a lot of seat belt unbuckling scenes in IF, and there’s no default “unbuckle” verb in any IF system I know of. So the seasoned IF player will often try to translate the esoteric unbuckling action into another verb that does exist in the default lexicon – like, say, OPEN, or TAKE OFF.
By not accepting that kind of input – by requiring the player to use a specialized verb that most games do not have, during one of the first interactive scenes of the game – you’re sending a message that says “this is a game that has non-default elements in its world model. It expects you to think like a normal person, not like an IF player.” Adam Cadre’s game I-0 more or less does that and then follows through – you can interact with lots of odd objects in that game that a normal person would expect to find but that an IF player might not imagine would be implemented – but it does this by being extremely meticulous and consistent. If you communicate the “you need to try not-typical-IF-stuff” message to your player, then they are likely to be more demanding about your verb coverage, because you’ve sent the message that their usual toolkit of verbs may not suffice and they’ll be trying assorted situationally-dictated stuff.
There are some nuances to this craft rule. J. Robinson Wheeler is particularly good at pulling off the use of non-standard verbs without ballooning the world model detail too much, mostly because he encourages you to trust that in each individual instance the text is going to clearly hint what the desired action should be. Conversely, Treasures of a Slaver’s Kingdom explicitly gives the player a very small verb set and promises that those are the only verbs the player is ever going to need. As a general rule, the more you break out of standard vocabulary, the more important it is to be clear and consistent with your player about what additional nouns and verbs you’re asking them to consider.
Having Inform respond to unimplemented objects with “There’s nothing special about that” is not a good solution to anything I’ve just been talking about. It might seem like a good solution, and in fact at least older versions of the ADRIFT system did respond with “Nothing special” to commands it didn’t understand. The thing is, that solution actually contributes to the problem of building a misunderstanding in the player’s mind. There’s one ADRIFT game that I was otherwise really enjoying where I got totally stuck because I typed (something like) PUSH BUTTON and the game said “Nothing special” and I took this to mean “your action worked but it didn’t accomplish anything.” And after a lot of frustration and futility and needing hints, it turned out that I was supposed to be typing PRESS BUTTON, because no PUSH BUTTON phrase had been implemented. If I’d just gotten an “I don’t understand your command” response, that might have been slightly non-ideal, but at least I would have immediately experimented with some other verbs and gotten past that point on my own.
In other words, having the parser lie to the player about what is going on in the world model usually compounds the real problem; it doesn’t cover the author’s ass very effectively and it may make things a lot worse. You might imagine a player encountering a desk in your game and going through a sequence like “examine drawer / It looks normal. / examine drawer handle / It looks normal. / examine bottom of drawer / It looks normal.” … and concluding, “wow, the parts of this drawer are sure implemented in a lot of detail, maybe the drawer has a false bottom or something,” perhaps wasting a lot of time with it, when in fact there never was a drawer to start with.
In any case, what I’ve described so far is partly an implementation issue – filling in some details that you left out – but it’s also partly a design issue. The design stage is where you think about how much detail in general you want to support in your game, which verbs are going to be important and which are going to be not-so-important, how deep into a description you want your player to have to dig, and then how you’re going to teach the player about that. Any appearance of “established orthodoxy” aside, the answers to these questions do not have to be the same in every game. They’re often not the same even from one game to the next by the same author.
This is fundamentally the design challenge, most of the time, for most games (not just IF): teaching the player how your world works sufficiently for her to navigate it. Making a model world that is consistent, not necessarily with every other model world out there, but within itself, so that what the player learns while playing your game can be leveraged across the board. Hadean Lands has a world model that deals with scents and materials and alchemical recipes; it’s a very different world model from the time-manipulation world of Fifteen Minutes; but both attain a certain kind of internal consistency about what is implemented, and what level of item the player needs to pay attention to.
The more different your world model is from the default standard that players expect, the more establishing work you’ve got to do.
So in A Long Drink, I struggled a good bit with trying to figure out what I was supposed to be doing on a moment-to-moment, move-to-move basis because of these kinds of issues.
But what really made me feel at sea was that, at the same time I was uncertain about the intended small-scale interactions, I was also fighting to understand the larger narrative arc of the game, because it felt like the things that triggered cut-scene narration didn’t work entirely right either. When Val turned up, she acted like I should be expecting her, but I had no idea why. I didn’t understand why she was driving us to the particular cabin she was taking us to. When we arrived, she stood around in a strange, inert way for a while (so I concluded I wasn’t supposed to do anything with her) and then various things triggered big additional chunks of exposition. By the time I’d been through a couple of conversations that only partly made sense, I started to wonder whether I’d missed critical parts of the intended path of the game, whether there was something broken in however you’d modeled scenes and time advancement, whether there was information somewhere in the explorable environment that I was expected to have found already but hadn’t, whether the game had now slipped into an unwinnable mode…
Getting dynamic plot right, especially dynamic plot featuring moving NPCs and a lot of things that the player could do in different orders, is a legitimately Hard Thing requiring both design chops and technical skill. Even pro game designers often have to do a lot of frustrating work to get this right, using pro-level tools on AAA projects. So, again, I absolutely don’t mean to imply that this is something that you should have been able to do easily. There’s good reason why a lot of IF avoids stories with a lot of moving characters; also why something like Make It Good, which does pull this off, took Jon Ingold some obscene number of years to write. (Ten, was it? I forget. Lots.)
Nonetheless, in this case the net result for me was bewildering, and the consequence was that I wasn’t able to get far enough in the game to discover other aspects that I might have been able to comment on. Struggling with the implementation was pretty much my whole experience of the game.
Okay. People’s mileage varies; depending on your specific set of issues, perhaps you’d prefer TADS 3? Or Quest?
There’s a lot here about managing player expectations, but perhaps it’s a little clearer why I said what I did.
1 Like
And the thesaurus solution is far from trivial because, as you say, it’s so context-dependent. For example, if you’re examining Hercules’ shirtless pecs, you want EXAMINE CHEST and EXAMINE TORSO to be synonymous. If, on the other hand, the noun is a treasure chest, you certainly do not want OPEN CHEST and OPEN TORSO to be synonymous. So you could certainly write some kind of thesaurus app that provides TORSO as a synonym if it’s connected to a person but not if it’s a container, etc., etc., but at the end of the day it’s going to have to run everything it suggests by the author, weakening itself as an “automated” solution. Because it’s going to be wrong an awful lot.
On one level I don’t see this as a fatal problem - yes, IF as a prose-oriented genre has to be hand-crafted to a large degree. So does a poem or a novel. But that’s an authorship issue. As a player issue, yes it can be a serious problem, for all the reasons you described. If I’m reading a book and come across a word I don’t know, I can choose to look it up or not, but either way I can still progress with the book. In an IF game, if I can’t figure out the right word to supply, my forward progress stops. As literary media goes, that’s a problem unique to IF games.
The fundamental disconnect that parser IF creates, as I see it, is that when you give a player a text field and a keyboard, you’re giving them the impression that they can type absolutely anything - which they certainly can. But only a limited range of grammar and vocabulary will actually be understood, and while IF novices probably don’t have too much trouble grasping this conceptually, many of them are probably unprepared for how limited that vocabulary really is. (I say all this as a lover of parser IF, of course.) Understanding the limits of the game and genre is important. I imagine not too many people get mad at Skyrim for not being capable of something it never promised to be capable of. But IF, in a grand abstracted theoretical way, promises to respond to your will, as expressed by the words you type, while the reality is somewhat cruder.
Where am I going with this? I guess that the solution lies in bridging that expectation gap, which can be done in two ways - by expanding the range of input that your game, and/or IF systems as a whole, is capable of understanding, which is obvious but requires a lot of work and is a job that can pretty much never be 100% accomplished. But also by, erm, tempering the expectations of people who expect IF parsers to really understand natural language. That doesn’t exactly solve the guess-the-verb problem, but my approach to that is pretty much to just explicitly tell players what verb is used to do a certain thing. If I provide a phone, I say “the syntax to use the phone is CALL [PERSON]”. I think some authors fear that if they do this, they’re exposing the man behind the curtain, but I disagree because the range of possible actions, while limited, are just building blocks. A game like Skyrim’s the same way. You can swing your sword, you can block with your shield, you can run around, you can cast a spell. It’s not that many actions. But it adds up to something.
Re. testing: as a really general rule, there are a couple of things that I’ve found automation can do:
a) help you identify ways in which your assumptions about your world model are incorrect, often using simple hand-rolled testing commands. So for instance if I have a puzzle that needs to be solved with an object that has a long property and a skinny property, I can roll a testing command that will find me all the long skinny things in the game. That might sound trivial, but it starts to become more useful when you’ve got more complex parameters. Savoir-Faire is a game I wrote in which the magic system allows objects that share a certain number of properties to control one another, so it was really useful to auto-build lists of objects that were capable of being linked and then double-check that those lists made sense, that the objects that were supposed to seem similar to the player were being described in a way that suggested that fact, etc.
The same sort of process can be used to force-combine nouns and verbs. Here’s a post about using Object Response Tests, a testing extension that tries combinations of objects on combinations of verbs. Reading through its output for a large game can be overwhelming, so I tend to set it up to work in sections and do a few minutes of object response testing each day, interspersed with other tasks. Nonetheless, I found a lot of strange things in Counterfeit Monkey with ORT that got combed out before release as a result.
Here’s a post about rigging an automated test for Alabaster’s conversation tree. This primarily works if you’ve got some set of enumerated possibilities for the player, in contrast with something like Object Response Tests.
b) help you visualize some aspect of what your model is doing in a way that makes errors visually prominent. The Map Index is a built-in way of doing this for one aspect of the Inform world model, but there are lots of other things one can do.
Here’s a post about visualizing conversation. I find visualization tools in general a really useful way of double-checking that I’ve accomplished what I thought I was accomplishing.
c) re-run through pre-fabricated scripts to make sure that they’re still functioning as expected. The Skein and the test commands may be limited, but extensive use of test commands made Monkey finishable for me. One of the practices I’ve developed with Inform is to write new object behavior and a test for that object behavior at the same time: the test is a list of the commands that will expose all the newly built object behavior, and forcing myself to think through a sensible set of test commands often leads to better specification of the code to start with. Then I can use that test to immediately verify my work and also revisit in the future to make sure that nothing has interfered with the intended behavior in the mean time.
d) spell-check.
Here’s the testing discussion we had in discussion club.
There’s probably other stuff that’s possible, and I fully grant that this doesn’t cover everything one might want to do, but for whatever it’s worth.
So I just realized with some chagrin that perhaps 75% of my points in my last post are just echoes of points Emily Short made in this post that she posted in the Twiny Jam thread. I actually read that post years ago so I may have been unconsciously cribbing from it. Sorry!
But happily, the post mentions one of my favorite things about tinkering with I7 (or any IF platform you like), which is the way it enables simulated (to some degree) worlds whose state is malleable and can be made to respond to the player. Presumably, it’s a big part of the reason that we’re still making and playing games modeled after a format that was created for computers that didn’t have mouse pointers. I guess I should come to terms with the fact that my attachment to the parser is to a large degree sentimental, but I still love it.
The problem with calling the expectations of parser IF players unreasonable is that those expectations keep being met. You’ll note that almost none of the parsercomp games had pervasive parser or world model problems. People expect NPCs to be well-implemented because there actually is a decent number of games with well-implemented NPCs.
Honestly, if someone had a game with lots and lots of NPCs, and they decided to implement them according to the Bioware-esque convention that they all stand in one place all the time and are interacted with through conversation trees, I don’t think people would complain very much. They’d recognise the convention and play along if it was done correctly and consistently. A lot of things in the default world model of parser IF are conventions that don’t quite match up to reality or fiction, but which people play along with. There’s a difference between presenting something as a simplifying convention that makes the game easier to implement and play, and something being broken.
A Long Drink had NPCs that were, from what I could tell, supposed to move around, have some degree of autonomy, start scenes, show up and talk to the player of their own accord, and respond to an Ask/Tell conversation system. That set up a lot of expectations that weren’t met. If it had NPCs that stood in one place and talked to you through conversation trees, but that worked, it would have been much better.
I’ve explained at length in another thread the limited usefulness of that approach: Every room description will include nouns that aren’t concrete objects, or aren’t present, so the output from the tool would be mostly noise. You’d either ignore it, or have to go back and tell it to ignore half the nouns it finds. It makes more sense to simply bracket every noun.
This is one of my fundamental disagreements. In my experience, IF reviews, even by veterans, will mention this a lot, even in cases where it’s not important.
That’s fair enough, though I’m curious what the best practices is for implementing this. I’m not taking about bracketed nouns or lists of synonyms, but how to deal with multi word objects and rooms that will be globally scoped as a programmer. Some of the issues players encountered were because I had different sets of printed names, true names and synonyms, etc. for wine glass, glass shard, shattered glass, and so on. Inform’s “It’s so easy, it handles everything!” approach to natural language leads to some really weird interactions when it’s doing object resolution, and the workarounds I encountered. Is there a reasonable coding standard for Inform7 on how to gracefully handle this situation?
Yeah, I recognized this, and had a hard coded list of things I could think of that would act as valid input, it bypasses the entire verb system because I didn’t want to have to implement sensible ways a ton of one-off verbs needed with a one-off noun. I passed it to a bunch of friends and beta testers here, and implemented things they tried so that they’d work, too. I didn’t want this to be a serious puzzle, I wanted the literally first thing people thought of to work. The commands “unbuckle” and “unbuckle myself” which were in the error hint would also have worked. I’m less interested in defending the puzzle or my design than I am pointing out that several IF veterans, yourself included, encountered this and made specific assumptions about how it was implemented and why:
undo, remove, and unstrap would have worked as well, which my testers tried. I don’t know why I didn’t think of “take off,” but as you say, this may be a difference in expectation between player experience levels. There are some odd parser quirks and phrasings I think veterans are used to (“leave” comes to mind) that I didn’t anticipate.
Again, a matter of player expectations: a normal person does not know what “typical IF stuff” means, right? And the IF player does not always jump to “this game is implemented for a normal person” but often to “this game is not implemented.”
This is true, IF has a lot of entries that Break The Mold and remain internally consistent design-wise. But these are the exceptions, the Rules are long established and well-codified. I don’t think the idea that the parser playing community has certain (numerous) expectations is something I pulled out of thin air, the IF Theory Reader, Inform 7 book, body of reviews, and even the “How to win the IFComp” thread has plenty of truth in it.
I appreciate the design discussion, but the thing that makes me regret entering ParserComp is that I no longer seem like the right person to participate in the discussion. I don’t want it to be about “defensive parser game author forces critics to justify themselves over issues they brought up that were largely true.” I’ve seen and want to talk about trends, and the way we talk about parser games, and the expectations that a game will either advance the state of the medium or follow conventions (see also AltGames) in a way that other subgenres don’t, and I’ve wanted to for a long time. But now I can’t, without it being about my game.
When I mentioned automated testing, I meant, for instance, a good way to unit test NPCs. The standard advice these days is “NPCs are complex, avoid complexity.” I reject this completely. Complexity requires more rigorous testing. There has to be a happy medium in here that is between “NPC conveniently is too busy to talk to you” and “good luck implementing something that passes the Turing test.” That’s a false dichotomy, and I don’t see why parser IF is this medium that needs to be held to standards other games aren’t held to.
[/quote]
I don’t like Inform, but I like everything else a lot less. I thought about running screaming from I7, and then tried to think of what I would run to.
Could you perhaps give an example of how unit testing you’re thinking about would look like? The kind of unit testing I’m used to works by implementing tests for expected program behavior from a spec or from bug reports. The problems you’re describing seem to be specifically situations that the author has not anticipated beforehand so it’s hard to visualize what kind of testing system you’re looking for.