Quest Engine Question

jjaquinta
I have a question about the Quest Engine itself. I.e. the code used to run quests. Not sure this is the right forum, but none other seemed to suit it better.

Is the quest engine alone available in library form? I.e. some sort of API, free of any GUI that can be programmatically called. Say, for example, I wanted to implement a REST service interface to a quest or an old school telnet interface. That's the level of API I am looking for.
I read in the documentation that it's organized into layers and modules. If someone can point me further at the specific layer or module that will meet this need that would be great.

Thanks,

Jo

jaynabonne
All the source is available here:

https://github.com/textadventures/quest

That should give you a good idea of how the source is structured, and it would be the best place to start if you wanted to extract some of the code out into something you could call.

jjaquinta
OK. I take it, then, the answer is "no", there isn't a API to the quest engine.

Next question. I'd also like to instrument the source so that, for any state in game play, you can interrogate it and find out the span of possible answers. I.e. anything someone could say to the engine that it would parse and act upon successfully. Another feature that might overlap with that, is to be able to give it some text input, and for it to say if it would do something. Not to actual do it, just to say if it is something that parses correctly and results in an action.
Is there someone familiar with the source code who can give a rough estimate on the level of effort necessary to add that to the code?

Cheers,

Jo

jaynabonne
I suppose it depends on your definitions of things like "successfully" and "results in an action" (for your two questions, respectively).

For the first, you can query all the currently available commands and verbs. For each, you could probably generate strings as the inverse of the regular expressions, combined with knowledge of which objects and exits are currently available. For the verbs, you can then look to each object and see if it supports that verb. That would give you a list of all possible syntactically valid commands at that point.

But then... take a command like "take". There is additional logic within the "take" command once it executes which looks at things like if the object can be taken, whether it already has been taken, whether it exceeds the weight limits, etc. So if your definition of "act upon successfully" is that the command input actually passes all internal checks and moves forward to change the game state, then you would need to write parallel code for all the commands, so that once you have determined they're syntactically valid (i.e. valid command/object combination), you could then determine whether all the various logic paths through the commands themselves result in something you consider successful.

I would not consider that a trivial task.

If you definition of "successful" simply means (as you say) that the input "parses correctly and results in an action", then you could skip the command-logic part. Running the input would parse successfully, match and execute a command, and possibly then have the action of printing "You can't take that."

The same problems exist if you're attacking it the other way (e.g. given a string, will it...?). Again, if you just want to know if it parses, you could run it through the Quest parse code and see if you end up with a valid command and resolved objects. But if your criteria is beyond "is it a valid command" and is looking more toward "does this do something (useful) when run", where "(useful)" is something you're defining, then you'd have to look, again, at all the code paths through the various commands and see if the input would result in what you're looking for.

I hope I'm not being either too vague or seem too picky. The problem is that I *think* I know what you might be doing but I'm not sure (perhaps instead of using the parser, you want to give the player a list of all possible command? Or perhaps allow some sort of auto-completion as they type? Or... I could probably think of other options.)

So to sum up: if you just want to know if a command parses successfully and would result in a command being called with parameters, then that's straightforward to do. If you want to know, beyond that, whether a command with those parameters "succeeds" according to some criteria, then you'd have to write code that matches the criteria you desire.

jjaquinta
That's perfect. I'm just looking for a general level of effort. That answers my question.
I'm trying to gauge the difficulty in font-ending a question with a speech to text service.
If you happen to know ahead of time the exact bounds of the grammar being recognized, then you can substantially improve the STT quality. So if, for a given game-state, I know ALL possible legal commands, I can do that and give a high quality of service.
As a fallback, once the STT service parses some audio, it can give multiple results, each with a certain level of confidence. If I can "try them out" against the engine without actually executing the command, then I have the chance to further filter the list by valid and invalid options. Once more, increasing the quality of service.
Sounds like the minimum viable proof of concept would be to separate out the non-GUI core engine code and create a service level API. Then see if I can isolate out the parsing element of that and expose it separately. That, and, learn C#. :) I don't suppose someone has done a Java version?

Thanks,

Jo

jaynabonne
Not of Quest, no. :) But there may be another IF engine written in Java.

The Pixie
I do not think there is a mainsteam IF engine in Java, which is kind of odd given its ubiquity. C# is based on Java, which might help.

If you happen to know ahead of time the exact bounds of the grammar being recognized, then you can substantially improve the STT quality. So if, for a given game-state, I know ALL possible legal commands, I can do that and give a high quality of service.
As a fallback, once the STT service parses some audio, it can give multiple results, each with a certain level of confidence. If I can "try them out" against the engine without actually executing the command, then I have the chance to further filter the list by valid and invalid options. Once more, increasing the quality of service.


I am not sure if I understand you completely, but I think Quest does this to some degree anyway. The game-state includes what items are present and what room you are in, and Quest does filter commands on that basis (especially the former).

george
jaynabonne wrote:Not of Quest, no. :) But there may be another IF engine written in Java.


https://github.com/komoku/aetheria :)

The Pixie
jjaquinta wrote:I'm trying to gauge the difficulty in font-ending a question with a speech to text service.
If you happen to know ahead of time the exact bounds of the grammar being recognized, then you can substantially improve the STT quality. So if, for a given game-state, I know ALL possible legal commands, I can do that and give a high quality of service.
As a fallback, once the STT service parses some audio, it can give multiple results, each with a certain level of confidence. If I can "try them out" against the engine without actually executing the command, then I have the chance to further filter the list by valid and invalid options. Once more, increasing the quality of service.

A good place to start might be the language files:
C:\Program Files (x86)\Quest 5\Core\Languages\English.aslx

That defines everything the basic Quest engine expects.

jaynabonne
Another consideration is that game authors can create their own verbs and commands with their own semantic definition of "success" (e.g. "open door"). It would not be possible to anticipate and account for those kinds of commands, which would probably leave you only able to tell if something is at least parseable (without knowing if it's possible - sorry, couldn't resist).

This topic is now closed. Topics are closed after 60 days of inactivity.

Support

Forums