How did you decide which verbs to display upon the first character input? For example, 's' brings up a set of words, 'sw' brings up a different set. Just alphabetically displaying the first x matches?
I do a prefix match, then I sort them according to this:
- hard-coded list of common words have highest priority (look, take, man, woman, use etc...)
- any recently used words have the next highest priority (the more recent, the higher priority)
- anything in any currently loaded said string has the next highest pri
- then comes all the other words
From that sorted list, I display the first n that fit within a certain number of space on the screen.
I'm thinking about prioritizing verbs for the first word, and then deprioritizing them for subsequent words in a phrase too.
For clarification, do you mean loading portions of vocab from a text file or loading them from text resources? I've done something similar to this by putting all verbs in a text resource, nouns in a text resource, etc. I did this to augment the parser functionality, things like noun disabiguation. But that was a new game, not retrofitting an existing game (not even sure if doing something like that would be possible?).
I suppose a text resource *could* work, but that seems awkward. You could probably just extract the vocab resource to a folder and have your script code load it and work on that. I load the vocab resource and put it into a blob that is optimized for fast traversal (attached code)... it uses the minimum memory possible. But actually I think the vocab resource is laid out in a pretty similar way.
The problem is that - if implemented in game scripts - this would be loaded into the heap. So there goes a bunch of heap space. My 11KB vocab ends up being about 8k when I load it (I prune out short words). I guess you *could* use a text resource (which would go in hunk space), and maybe try to stick all words of one letter in an entry. But you'd want to do it in a compressed form, again. I guess you could have an offline tool that loads the vocab resource and copies the section for each letter directly into a text resource entry. I don't know if there is a limit on the size of entries in a text resource. In my case, all the s words (the most common letter to start with I think) fit into about 1000 bytes.
So if you did that, then at most you have all the data for a particular letter in heap space at once (since you'd have to load them into a buffer to start processing them).
Then comes the problem of sorting them (to provide the best words to the player) from script. There are over two hundred s words, so when you type 's' in my case, that's a 200 item sort. No problem for C# code on a modern computer, but I dunno how it would be in the Sierra interpreter running on DOSBox.
Actually, if the word priorities are from a fixed set of numbers, a bucket sort would be pretty fast.
Of course, at some point you're decompressing the strings to their full size also, and so that's going to use up more heap. Unless you can be clever and only decompress the final top n strings you present to the player.
It certainly would be an interesting challenge getting this to work.
