01 Oct, 2013, Kelvin wrote in the 1st comment:
Votes: 0
I'm curious to see what algorithms people are using to take a user's input and match it to an object in the same room. Anybody using something other than a cobbling of simple substring matching?

for example:
Quote
Contents:
A Rubberblock
A Red block
> look block
A Red Block

Haven't got around to refining it, but seems like I'm going to need to take word boundaries in the object names into account to get the best results.
01 Oct, 2013, Idealiad wrote in the 2nd comment:
Votes: 0
I don't know, I guess a 'rubberblock' might commonly have a 'block' keyword defined, in which case you might match the first one. If there are no keywords would you expect 'block' to match rubberblock before 'red block'? I might not.
01 Oct, 2013, Skol wrote in the 3rd comment:
Votes: 0
I'm with Idealiad, did you have another approach Kelvin?
Most of my 'object' interactivity work has been with parsing input, more along the lines of making it more 'human approach'. IE rather than code of 'look block' it would scan for and ignore/choose based off of things like 'look at my block', it ignores 'at' and knows 'my' means in inventory or equipped (not room), and then looks at 'that' block.

But, things like taking a substring, I've never gone into, relying more on builders to have the keywords defined in ways that make more sense.
- Dave.
01 Oct, 2013, lurker_veteran wrote in the 4th comment:
Votes: 0
I'm toying with the idea of using user input as a set of prefixes for object's name and adjectives.
Quote
Contents:
A rubberblock
A red block
A red table
> look block
A red block
>look bl
A red block
> look r t
A red table
>look red
What do you want to look at?
1. A red block
2. A red table

A rubberblock won't be matched by 'block' though.
01 Oct, 2013, Kelvin wrote in the 5th comment:
Votes: 0
In my case, I don't think I'd want block to match rubberblock. Doing a straight substring match could lead to some weirdness if the input matches multiple objects.
Quote
Baggage
Age
> l age
Baggage

Yuck. I think the way I'd prevent this is making sure that the match either occurs at the beginning of the candidate object's name, or immediately proceeding a space.

Unless there was an existing algorithm or two that could do this even better/more gracefully…
01 Oct, 2013, Idealiad wrote in the 6th comment:
Votes: 0
It might be confusing for users (and incompatible with most mud clients) but the fuzzy matching functionality that's in many code editors these days might be kind of cool for this sort of thing.
01 Oct, 2013, Kelvin wrote in the 7th comment:
Votes: 0
I was actually using fuzzy matching via fuzzywuzzy: https://github.com/seatgeek/fuzzywuzzy

I can't really articulate what I was seeing correctly because I don't have much background in the algorithmic side of it, but it seems like the algorithms it has in there would be more appropriate for stuff like searching multiple objects and trying to find the best (but not necessarily correct) match out of all possibilities.

A really fun example was that in a room that just had me (a player object named Snagglepants) and an object named "Test Station", "look sta" matched me (Snagglepants) with a higher score than the station. I can't remember which of the algorithms I was using, but after writing a set of tests to compare my desires against what I was getting, each one failed in different unacceptable ways.

In the end, I think I want to just emulate MUX/MUSH behavior (the substring + word boundary approach), but wanted to see if anyone else had solved this in an elegant manner.
01 Oct, 2013, quixadhal wrote in the 8th comment:
Votes: 0
Sounds like a variation on the soundex algorithm.

Soundex can be useful for finding help topics and whatnot, but it also gives plenty of false positives and thus is best used to offer choices where timing will never be an issue.
09 Oct, 2013, Nathan wrote in the 9th comment:
Votes: 0
Any time you have two things whose object names contain the string to be matched a substring you have an issues. You might expect, reasonably that
if your input is "red" and there is a "big red table" and a "red table" in the room, that the latter ("red table") would be gotten since the string occurs earlier
in it's name.

The approach you mention (the substring + word boundary approach) seems like it's reasonably intuitive and that would be why it has been used.

In the case of the block, checking against a type of thing might make sense. Suppose I type "look block", then I could logically expect to get the first thing
that IS A block. If the game knows that both "A Rubberblock" and "A Red Block" are of type block, then I'd expect to get whichever it got to first. The game can't know
what you're thinking and won't respond as you desire unless you give it all the details. If the game implemented view and you could only see "A rubberblock", then of
course you'd get that one, because you can't "see" the other one.

It seems safe to use "the substring + word boundary approach", provided that the keyword can be matched against any part of any of the distinct substrings of the input. Really, unless "a rubberblock" is a special kind of block then it should be named "a rubber block" since both red and rubber describe an attribute of the block.
0.0/9