Forcing the parser to always ask which do you mean

[Dannii]

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

[matt_weiner (matt w)]

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

[matt_weiner (matt w)]

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.

[dootdoot]

@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).

[matt_weiner (matt w)]

@dootdoot

@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!

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.

[dootdoot]

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.