the display name is not the vocabulary name. The vocabulary name is based on the id of the object.
See section 8.7.2 of the documentation.
Yes, I eventually found that... It seems an unusual design choice.
Imagine if you walked into IKEA and asked for a "Poang bookshelf" because that's what's on the label, but the shop won't let you buy it unless you quote its hidden SAP stock code 40021303210312 ;-)
I'm okay with it reacting to the hidden ID, but NOT to react to the actual text that the user's been presented is a recipe for confusion.
>Look
You see a bookshelf
> Get Bookshelf
You don't see a bookshelf.
Thanks for getting back to me, it's much appreciated :)
The reason for this, and I'm choosing a strawman here, is that if I scanned to the words in the description, then it's quite difficult to ascertain what is an adjective and what is a noun, etc.
// What is the noun we can imply from the description? zzzz1 : object "a wonderful magical cloak of mystery";
Ah, cheers! Understood. As someone who studied AI and natural language parsing for four years, I can see what you mean. In *theory* it shouldn't matter.....
cave_win_device : object "The magical wand of Sauron"
evil_bad_buy : scenery "The evil wizard Sauron"
I can see if someone typed "get sauron" the parser might have difficulty. However, you could probably spend time coding a search tree prune a little on inbuilt commands like get and drop but I think the solution's already built in. I've seen the game say "which do you mean '1. thing_1 2. thing_2' . That works really well (I had two suits at one point).
I'd perhaps add a setting to the settings block to allow the game to react to any word (other than common prepositions and articles) in the displayed title. It'll be a rare occasion it fails, and when it does, the game already solves it perfectly :) :) :)
select_object_by_any_word_in_displayed_name = "true" or something similar... I'd perhaps go so far as to suggest making it default: on, but let people switch it off if they get into a bind and want to do it the hidden_id route.. :)
I had considered such a thing and perhaps I will add something like that in the future. It really depends on having a large dictionary of adjectives and articles. The low tech route is not so bad if you know it.
Going in the other direction, you can make it so that the id does not represent adjective or the noun by explicitly supplying noun="" and adjective="" next to the object.
Adjectives and nouns are grouped via the vocabulary section of the game defintiion file, so you could have:
spoon : scenery "an oak tree" noun="oak";
vocabulary {
: noun {aliases=[oak, tree, log, logs]}
}
... and it would associate the noun group with the object.
There is a risk of false positives for nouns that may have different contextual meaning, but generally speaking false positives will just result in a disambiguation list where they occur, so it's not so bad.
Anyway, it's correct that types of description could imply a noun (where there are two words and one of them is an article for example), but there are so many objects that two or more chained words in addition to an article that it's probably easier just to learn the general rule about the usage of ids than to second guess yourself if you have entered the description in the right format. the book is not closed here, but it's not low hanging fruit. Certain types of smartness are also forms of obfuscation.
Cool, glad it's got you thinking anyway, and thanks for the great answer, I'll have a look through the docs and see how it goes.
If I had the choice, I would just let the parser react to everything except "a" "an" "the" "of" "by" and "some" .. So if there are any objects, you can indicate them with any word in their description.
I haven't needed to use noun aliases. I was considering using some verb aliases the other day, but couldn't see a way to do it, so did the match string manually.
cheers, once again! You rock! :)
I was just thinking it this morning. I'm not sure. I think I've created a bit of a monster, and debugging the logic is proving a real challenge. I'm not sure I have enough time to work all the kinks out AND add the artwork (I'm not an artist!)... It's about 90% there, and I just need to debug all the story pathways....
I've done a lot of work on the logic today. My wife's back tonight, though, and I still haven't met the "graphics" minimum requirement of the Jam. I didn't see that I needed to have so many graphics, and the game is pretty huge. It'll take me a good few hours to find images and edit them to the requirements.
The logic is about 98% there now, but having run through the game down one of the plot 'legs', it's not really halloweeny enough. I need to add more creepiness :(
I don't think I'm gonna be able to do it, just not enough time unless I can catch a few hours tomorrow in the day.
N.
hehehe,
I'm trying to put more creepiness into the game... I've just been laughing so hard because I actually scared myself when I was testing it hahaha. But I'm still not sure it's creepy enough to be considered for the jam.
I've added another three or four images, but I'm still well short of the minimum requirement.. I think I need to add another 10 or 15 images to qualify. I'm looting my back-catalog of photos from the last 30 years :D haha. Damn, I took so many during the day, but daytime =/= creepy hehehe.
I've tested one of the plot lines to the end... four to go. I've also scripted the endings too, so each time you finish it you might get a slightly larger chunk of the whole story...
Even so, I'm not sure I can hit the 31st deadline... I'll try my best to get it to you before the COP tomorrow :)
N.