Forcing the parser to always ask which do you mean

Authoring Inform 7
7

So I tried a little hack, to make Inform think there’s a third apple in the room in order to force a choice. I thought I could be clever…

[code]“The Kitchen”

Include Room Description Control by Emily Short. [For the description-concealing rules.]
Include Single Paragraph Description by Emily Short. [I used this one for simplicity, but there are other options.]
Include Numbered Disambiguation Choices by Aaron Reed.

The kitchen is a room.

The player is in the kitchen.

An apple is a kind of container. Understand “apple” as an apple.

A worm is in the kitchen.

2 apples are in the kitchen.

To place the worm:
repeat with x running through apples:
if a random chance of 1 in 2 succeeds:
now the worm is in x;
if the worm is not in an apple:
place the worm;

When play begins:
place the worm.

Disambiguation-nevermind-device is a thing in the kitchen. It is fixed in place. The printed name is “never mind”. Understand “apple” as disambiguation-nevermind-device when the number of apples in the location is greater than 1.

Every turn:
now disambiguation-nevermind-device is in the location.

A description-concealing rule:
now disambiguation-nevermind-device is not marked for listing.

Instead of doing anything to disambiguation-nevermind-device, say “You decide against it.”[/code]

Then you get this:

kitchen
In the apple is worm. You also see here an apple.

take
What do you want to take?

take apple
Which do you mean, a 1) apple or 2) never mind?

2
You decide against it.

My guess is Inform won’t disambiguate two duplicates from the same kind, ever.

8

The wormy apple vs apple example is too simplified. I would be fine with someone having to type “get wormy apple” but I am not fine with someone having to type “the moon-rune engraved, +1 mithral dwarven claymore of holiness, with a silver, star-shaped hilt”.

The Numbered Disambiguation Choices won’t come into effect until/unless the parser can’t decide. Unfortunately, the parser DOES decide between these items unless the player were to type out the whole thing… and even then, I don’t know how to (or want to) turn things like “silver, star-shaped hilt” into a property. I’d rather parse that information in another way than making it a property value, but it itself is made up of multiple pieces like "silver, " and “star-shaped”, which could be a list of things like “golden”, “silver”, “steel” etc. and “moon-shaped”, “star-shaped”, “skull-shaped” etc. with lists that could be very long, and there could be more components from disparate considerations like “blood-soaked, chipped, golden, skull-shaped, ruby-encrusted hilt”.

I’m not saying I’ll necessarily have such long annoying names for everything, but it can happen, and I don’t ever want the player in a situation where he is unable to determine exactly which item he means because the parser thinks it knows which one.

I’m not sure why I’m getting pushback on figuring out how to do this as a programming problem, because the program issue exist. My entire application is too big to share, and is broken and disorganized with lots of other problems at any given time as I work on it… but, when I get it to a compilable state periodically and run it, I DO encounter situations where the parser is deciding what the player means, and I don’t want it to/consider it’s decision to decide it knows which one to be incorrect. I’m not sure why I have to defend it so hard and explain the entire premise of WHY I want a feature so badly, instead of asking the question on the premise of a practical solution to the problem I am having.

9

I think you’re confused about the way the parsing of property names works. If several properties “refer to” an item, the player only needs to type one of them for Inform to figure out which one they want. I believe it can also deal with multiple levels of disambiguation, so you can continue to specify one property at a time until only one object fits the given criteria. E.g.
[rant]> TAKE SWORD
Which do you mean, the red short sword, the red long sword, or the blue short sword?

RED
Which do you mean, the red short sword or the red long sword?
LONG
Taken.[/rant]

10

@Draconis: I’m not saying it can’t be done another way, and I understand that you can attach properties and that is the normal way of doing it in most applications. I’m trying to create what is, quite painfully obviously, a very different kind of game than most are used to with IF. I still think this engine can do it, and I want the text input parser, the save system, etc. so making my own thing is out of the question, but there is lots of specific code to write to rewire a lot of the basic premises of the game to make it possible. Memory limitations are one of the reasons I’m doing things the way I am in the first place anyway.

I can’t have separate properties for every word of text. I’ll run out of memory from the use of properties just like I would for the use of things. I’m still not sure if I’ll run out of memory from dormant until used tables (from what I gather in another thread, I should be able to have 2 gigabytes of those), but if I do, I also should be able to store those tables outside the application in external files and refer to them that way. I can’t store objects or properties outside the application, and so I can’t have thousands of those… the application will not run after I have about 600 of them, no matter what memory allocation settings I adjust… there appears to be an upper limit, and my game will blow that upper limit out of the water like a nuclear bomb.

I need to have these descriptions be text-based, and then have the game parse the text and perform logic on what is in the text, and figure out how the item works based on this.

If I am wrong about all of the above, well, I’ve asked many times how I can go about making an application that can have the appearance of many thousands of things, and though people say it is possible, their examples of how don’t have the kinds of things I’m trying to create as the kinds of things in the example. I’m doing my best trying to work toward the application I am trying to make when the engine can’t handle what I’m trying to do by the normal operations of things. I know the normal operation of things would be to attach properties to every item, but what if… just WHAT IF, that approach doesn’t work, and is crashing the application…

Disambiguation Control was a major key to solving that dilemma for me, and all I’m asking is if there is another clever approach to solving it without that extension since it is not updated.

11

Tables can use just as much memory as properties or more, depending how you’re using them, and will often be slower (if you already have a pointer to the object you want, you can access the property directly rather than sorting through an enormous table with as many rows as you have objects). You shouldn’t need a separate property for every word of text; in your previous post you said the solution given wouldn’t work because you generally had many words per property. :stuck_out_tongue:

If you really want to cut out the object-name parser entirely you can do something like this.

After reading a command: let X be word number 1 in the player's command; change the text of the player's command to X.

This removes everything after the verb, so GET SWORD becomes just GET (prompting the game to ask what you want to get). But again, I’d be very frustrated if I were playing a parser game and it couldn’t recognize the names of objects it gave me. Something like this would be going to far IMO:
[rant]You can see a sword and a dagger here.

GET SWORD
Which do you mean, 1) the sword or 2) the dagger?
SWORD
You can’t see any such thing.[/rant]

I’d say conditional understanding would be a much better solution. No matter how the property is determined in the code, you should still allow it to be parsed.

12

If it is true that too much table data that is not being processed at initial runtime will make the application run out of memory/be unable to compile, that too many objects will make the application run out of memory/be unable to compile… I don’t see how having multiple properties will help me, because I have no way to store and retrieve the assignments of the properties. I can have all the properties in the world, but if I can’t explicitly create enough objects, and I can’t have enough tables to run logic against to change the properties of a smaller pool of objects…

Then this is impossible. I tried to ask the question before, is there a limit to the scope of a game made for IF. If no matter how I slice it, I am limited to 600 things or less, then yes, there is a severe scope cap. Is this impossible, or is it possible to have more than “600 things” (as far as how it is presented to the player). Remember, the values of these “things” have to be able to change (that’s why I’m trying to use tables, because I need to update, store, and retrieve the info). Just having “loose” “now the whatever of prop1 is whatever value” phrases won’t work, because that defeats the purpose of the prop in the first place… it can’t have multiple possible stored values, only the one, so it might as well not have been a prop to begin with.

… is it impossible to make an application in IF that has or simulates having more than 600 things (tens of thousands of things) the player can interact with?

13

I think it would help if you explained in full what you’re trying to do. You post a lot of questions which we answer but then apparently they won’t work in your big project. We need to get a grasp on the whole thing.

14

I thought I have explained it, multiple times in multiple threads where I have had responses from the same people. Let me try again, from the top and see if I can make it more organized to make some sense.

Most IF games have specific “puzzles” or sequences of actions, with one or few predefined courses to take for each, and “guess the verb/guess the noun” is as much a part of the game play as anything. The standard rules assume this kind of game, and more than in mechanics, even in output, as in the responses like “I beg your pardon?” or “(the apple) Taken.” or “the [container] (empty)”. I am trying to make a very different kind of game in how the player is presented with the world. If I am way off base and there are games that don’t behave this way, I’d love to be pointed in their direction, not just as a game maker, but as a player.

Kerkerkruip, for example, is a fun game, but it fits the mold of the “typical” IF game as described above, more or less. I may never finish what I am trying to do, and Kerkerkruip is a finished game people who made it can be proud of. I want to make sure that it is understood I am not disparaging that game, or any other game made that follows the genre norms. I am giving this preamble so that it is clear that I am making something a little different, and I have to establish what kinds of things I intend to differ from for that to make sense.

I am certain that the “language” of the code in this engine is capable of doing what I want, but it has become evident that, at least by doing things in the typical way this engine was set up for dealing with typical IF games, that memory and performance issues will prevent the game from reaching the scope I am aiming for. I don’t care if it takes me 20, 40, or 60 more years to complete, the kind of game I want to make is the kind of game I want to make… I just don’t want to have to write a parser, save system, file management system, etc., and I would like a delivery medium that is known, so I am trying to get it to fit my project into the IF engine.

I tinkered with writing my own engine from scratch in C# and javascript, and while it is technically feasible on an indefinite timeframe, it’s not really “fun” for me to write that part of the program, and I want to focus on functions that will manipulate the “game world” or else my whole hobby is going to be spent doing stuff I don’t like, so I abandoned that avenue and went back to trying Inform.

Now that the preamble is over, what am I trying to do exactly? I am trying to create a scalable framework in which a lot of conventions of “reality” (not necessarily “realism” but a contextual “reality”) are present in the game that are not in typical IF. I want this framework to provide the mechanisms to do this in a centralized, reusable, specific-thing agnostic manner, so that I can utilize this framework like an extension (possibly series of extensions) on which I build the game. What I’m trying to do is basically rewire a good portion of the standard rules, making a subset of standard rules for building the kind of games I want to build.

The kind of game I want to build is an open world game, but more than that, I want a richly populated and contextually sensitive world where “guess the verb/noun” is a thing of the past, and normal conventions of “reality” are present. So, a “person” is not just a single object, but has body parts which can be individually injured for various effects. The player has body parts, such that you can’t look at your own head. People react to events around them, and have context sensitive things to say or do based on how the world changes (if you take their stuff, they get angry, etc.). People are equipped with armor and clothing that can only overlap “slots” in logical ways. The reporting of actions is narrative in presentation, seamlessly placing the responses of what was done into a flowing paragraph. Time is moving forward for any action, there are no “free” actions… “examining” something has at least 2 (maybe 3) levels of examination detail, each which takes different amounts of time. I also want this world to have some of the conventions of other open-world games such that “loot” and “quests” have a hint of “randomness” such that it isn’t the same each time you play it. And more…

Now, all that sounds very complicated, and it very much is. I may indeed never achieve my goal, but that’s where I’m headed. Again, even if it doesn’t turn out quite as expansive and dynamic as I hope, and even if it takes me years and years, that’s what i am trying to do. Now, the key here is that in order to pull this off, a world like that needs LOTS of things. A person has to be made up of multiple “things” and there have to be many people, there have to be thousands (if not tens of thousands) of items or possible items, which have “random” properties and placements.These “things” are not necessarily Inform convention thing objects, but must present as things to the player. The whole point of my questions is trying to circumvent the limitations of the engine related to Inform things.

So this brings us to what has been discussed in this thread. How can I solve for these issues. I am getting very close to having a better, more consolidated framework for “item substitution,” or “props,” as I like to call them. It isn’t ready to share yet, but it is getting there. It uses a system of tables and properties to dynamically change a limited selection of rooms, people, and things by changing their properties. So, the limited number of things can look like they are “infinite” things. I am deeply concerned now that Draconis has stated that tables will end up taking up as much memory as objects… it’s easy to test 600 objects, because you can put a line like “100 props are in the void,” in 6 or more times. To create unique tables, I have to manually come up with 600 or more names for tables, so that’s hard to test and I haven’t… so, I ask, after all this incredibly long post, is what I am trying to do feasible under even the best of circumstances (I don’t mean am I personally capable of finishing it in my lifetime, but rather is the engine actually capable of a game expansive enough that “600 things” is far, far fewer things than are necessary).

And finally, how does this relate to the original topic of this thread? Well, I was asking a question about how to do something that is needed for my game. The more narrative responses of the game, coupled with the complex and random item generation and properties, makes it so situations WILL happen where the standard parser is going to decide it knows what to choose for the player when in fact, it is wrong that there aren’t disambiguations left to consider. People not understanding the kind of game I am trying to make lead them to tell me to do things differently, but not understanding the full scope of what I am doing, their suggestions are either wrong for what I am doing OR (and I am willing to concede this graciously) I am doing things wrong BUT the answers people are giving are incomplete to account for all the variables I am dealing with.

15

I’m confused about one thing now–you say you want to completely eliminate guess-the-verb but still use the standard parser. People have been trying to do that for years but (imo) have never entirely succeeded. What is your plan for that?

More on-topic, I think the best thing to do here would be to use multiple gblorbs for different areas and pass data between them using external files. For the most part things from one region wouldn’t travel to another (e.g. very few NPCs would be willing to follow you that far away), so you could fully implement them using the Standard Library and not need to worry about their possible interactions with things from the other regions. Perhaps there are mountains between Informland and the nearby Tadopolis, so the journey is difficult and you can’t reasonably bring more than 10 things with you. You would only need 10 blank props in each place, which are filled in with the details from the external files. And so on.

16

Now THAT is interesting. I’ve thought about that, but my search fu is horrible with Inform and I couldn’t figure out what was possible with multiple files in that manner. If you don’t mind, I’d like to start a new topic about that instead of continuing it here.

Edit: As for the guess the verb/noun issue, again, I may not achieve all my goals. However, the idea I have is to internally expand most verbs to understand many words, and to make the narrative world OUT OF nouns, so that when you see “there are [trees]” here or “there is [an altar]” here, there actually is. I hate it when I am playing a game and the room description is full of texts or scenery that can’t be interacted with, but sound like they are things you should be able to interact with. I end up typing things like “look altar,” “look crack” (in wall), etc. and going nuts. I don’t want to add anything that sounds like an actionable noun to the room descriptions unless it actually is one.

17

Let’s back up.

Correct.

Not correct. You can always force the parser to think that items are distinguishable, even if the difference is hidden from the player. That was the point of my original answer:

An apple is a kind of container. Understand "apple" as an apple.
The printed name of an apple is usually "apple".

The apple1 is an apple in the Kitchen.
The apple2 is an apple in the Kitchen.

In this example, the parser will never auto-choose one of the apples. It will always ask a disambiguation question. But the player will not see the “apple1”, “apple2” labels.

For this toy example, the player is screwed, because the parser will ask “Which do you mean, the apple or the apple?” But if you add Numbered Disambiguation, the player can cope. If you start adding visible distinctions to the objects, you can make a playable game this way.

18

Interesting, and not to say ambitious, ambition. Fundamentally, you are asking : "How do I manage, in memory, a potentially infinite number of objects, and their various conditions. As well as : How do I enable the player to disambiguate between these things in a world where objects may have similarities.

Simple answer is, I think, you can’t. Within the boundaries of the world you’re creating you’re going to have a memory limitation, and you will have a cap on how many objects you can create.

Assuming you are creating the world dynamically, and each ‘object’ in the world has a number of parameters - then you’re going to need to either limit the number of objects (whatever - people, swords, cats) or create and destroy them dynamically, or create them algorithmically or do some sort of clever file swapping stuff.

I would argue that you need to create an objects table that hold the dynamically created object properties

Sort of:
OName OType OProp1 OProp2 OProp3 OProp4 HP Condition…
Bob Man Long Nosed – – 43 asleep
Sword sword short diamond-encrusted – – – Poor
(Just an example, but you get the idea)
And, rather than 600 tables, this gets created during the game. Or something.

Just my tuppenoth. Interesting programming exercise.

19

[quote="McTavish"Sort of:
OName OType OProp1 OProp2 OProp3 OProp4 HP Condition…
Bob Man Long Nosed – – 43 asleep
Sword sword short diamond-encrusted – – – Poor
(Just an example, but you get the idea)
And, rather than 600 tables, this gets created during the game. Or something.[/quote]
That’s sort of what the game already does. Extensions allow you to add to the relevant table at run-time.

Small note: you might also want to make everything privately-named, which will mean that the parser won’t recognize “apple1” or “apple2” as valid names for the apples.

20

@zarf: I don’t want to beat a dead horse. I know I can supply ways to disambiguate, but the problem was that I keep running into limitations that make it difficult or impossible to use those normal conventions you are asking me to use in such a large application. I think I have to transition my focus to that for the time being, and come back to the disambiguation issue later. Not being able to even build the world large enough is a more fundamental problem, and the course of this discussion has made that extra clear.

@Draconis: I’ll take the tip about privately naming things.

@McTavish: As for creating and destroying things, I’ve looked into destroying things/deallocating memory, but as far as I can tell, you can’t do this with Inform 7. I don’t know I6 at all, and part of what is intriguing about this project is doing it as much in Inform 7 as possible. If the core engine is written in I6, that premise is lost. I know there is an extension to create objects in I7 (Dynamic Objects does this right?), but as far as I know there is no way to destroy them and get the memory back.

Even if there were, I still need to store the records of the object when I were to destroy it so that I can recreate it again later with any modified parameter values that happened to it during the course of play… otherwise, nothing can ever change, and ends up always reverting to the initial values when recreated. I’m really not sure how to deal with this problem except to store information in a table or data file of some sort, so instead of creating/destroying, I’m using “props” as a limited set of persistent objects that are being updated with different properties read from tables. I’m still confused as to if this will actually help with the memory limitation or not as it is hard to create the test scenario without first attempting to write an actual, large game with hundreds of data records.

Also, I don’t really need “infinite” space, but I didn’t realize that the application would break down at 600 things. I keep using that number, because that is the number it keeps breaking down at for me. I just need a lot more things, not completely unlimited things. The cap I’m running into is just too restrictive for what I am trying to do. I’m hoping I can figure out how to use external file references from the resources zarf posted in my other thread, but I haven’t had much time to look at them yet.

21

Yes there are lots of games, especially more recent ones, which try to avoid guess the noun/verb. Though I’m not sure why you bring up guess the noun/verb… it has nothing to do with the presence of lack of simulation details, it’s all about synonyms.

That’s fine and a decent goal to aim for. I will say though that when you get to the final game you will need to embrace kinds. You can keep the central library generic and use placeholder kinds while you test it, but it would be a mistake to keep things generic in the final game.

As I think you know, it would be wise to dynamically create and destroy these items in the background when the player moves, just as 3D MMORPGs do.

I think I said this before, but I’d strongly recommend using rules rather than tables. You could have a “creating a person rule” which then creates the body parts and clothes etc. Then you can have “creating Alexander the Great” which will set specific properties, rather than the random ones the generic rule sets.

I think it is best to still use kinds. Don’t use a single generic prop kind for everything. Have a kind for body parts, and then subkinds for all the parts you want to have. Have a kind for clothes and sub kinds for all the kinds of clothing. When you need to create a part you can pick an offstage one and then change its properties, or create one dynamically if you’ve run out.

Yes this is a common idea. Most authors decide to have less specific things mention in descriptions that simulate everything, but I don’t think either option is intrinsically better.

Now to the problem at hand, how are you trying to store the information in “doom-rune engraved, +1 mithral dwarven claymore of destruction, with a golden, skull-shaped hilt”? Is that the full name of the thing? Are some of them texts? Kinds of value?

And I don’t know why you think 600 objects is the maximum. Kerkerkruip has 81 rooms and 524 things. I’m not sure how many properties we have, but it has 773 property functions, which are used for checking either single or combined properties in descriptions, but we probably have scores if not hundreds of properties in total.

22

I haven’t had time to read through this thread yet, but I posted an attempted patch to Disambiguation Control in the other thread.

23

Having read through the thread now, have you tried adding “Understand the printed name property as describing a thing”? That might be enough to force disambiguation when the props all have different printed names.

24

@matt w: Thanks for working on the extension! I’ll give it a shot when work allows. I also do know about understanding the printed name, but the printed names become so complex, and include punctuation like commas in my game. It’s OK though, as with Disambiguation Control working, the interface makes sense to me how I am setting it up, so thank you again!

@Dannii: Guessing the verb isn’t only about synonyms, but about guessing what actions would apply to a situation. I do intend to use understand phrases to help with it, but I’m more interested in making the world more intuitively like the real world, making the game more about character skill than about player skill. Nouns are actually probably more of the issue than verbs in this sense, where I aim to make nouns obvious, and make the description of the world out of nouns. I even intend for there to be a feature (toggleable) where the kind of a noun in the noun name is bolded or highlighted in some way if it is something that can be interacted with. Of course, there can still be hidden things and puzzles, but once a thing is presented to the player as interactive, I want it to be obvious what that is.

This brings us to the next point, in that “kinds” are too restrictive since they cannot be changed. So, I’ve created my own property called “category,” which internally to my rules and functions operates like a “kind” to distinguish behaviors etc.

I would love to be able to create and destroy objects, but as far as I can still tell after all the posting I’ve done here, there is no way to destroy an object. If you mean to “recycle” the props, I am doing that each time the player moves indeed. I don’t plan to have 5000 actual props active at a time, I was just exploring the mechanics of this issue. I intend to have about 100 props, 10 dummies, and 10 dynamic rooms, and shift the game around as the player moves.

Finally though… I am most baffled by the use of rules alone to do this. A rule has a static set of parameters, as far as I can tell. The reason I am using tables is that a “thing” (as understood by a human player) can change. When the prop is recycled, destroyed, whatever you want to call it, it either reverts to a default state, or perhaps “becomes” some other thing, inheriting new property values to look like something else to the player. If I use the rule to set that state, wouldn’t it always end up having the same state each time it is put back on stage? I need things to be able to change over time, to store data like current durability, enchantments added by the player, items that may be inside or on the object or room or other relationships between things…

Please point me in the right direction if this kind of information can be stored without tables, and without storing it directly on an object (as the whole point is that that is not a viable avenue).

25

Well, in this case my idea wasn’t so much that we’d actually be understanding printed names that the player typed, as that with that line included our props wouldn’t be considered “exact duplicates” by the parser, so they’d disambiguate.

26

It works! Thank you for updating that matt w. I tried it out and it works.

So, the title of this thread, the initial conversation about asking which do you mean, might be a little misleading. If a player does type in enough information to target the item desired, the game doesn’t ask which do you mean, but now, the way I have it rigged, there is no possibility under any circumstance that a player can’t target what they want, and the interface offers help to figure out what things there are, such as simply being able to type “take” (with no noun) and this will present the player with a list of all things that are takeable (as known to the PC), etc.

Thanks again, to Jon Ingold and matt w for the extension!

As for the other stuff that went way off topic to explain why I needed the thing in the topic, I’m still not there yet in understanding the best way to approach it, but I am still plugging along on my table and prop substitution system to do it at this point.