I've set up the repository here: https://github.com/textadventures/questkit

I've checked in the sample file format, together with what the generated JavaScript for that file would be.

Next step, write enough of the JavaScript framework so that small sample game works.

Then, write the converter/"compiler".

Then flesh out all the rest of the features and it's done. Simple as that

An initial thought (and I'm sure I'll have more): the goal I had with my response library was to try to unify things, so that you could treat everything the same, whether it be a room description, a command processor, conversation/dialogue or async actions. I realize that the current Quest model is being redone in a JS format, but I'd like to throw in the possibility of doing some unification - assuming I can come up with a reasonable plan.

Things you might like a command to do:
- run script
- output text
- set variables
- other?

I think a first step would the first two. For example, the sample file starts off with this:

command:
pattern: say #text#
script:
	function(text) {
		msg ("You say '" + text + "', but nobody replies.");
	}

This command really is just outputting some text. It would be great if you could just do something like:

command:
pattern: say #text#
text: You say {text}, but nobody replies.

You might to have both text and script:

command:
pattern: take #object#
text: You take {object}.
script:
	function(object) {
		setParent(object,  "player");
	}

A room description might want script as well:

location: lounge
description: 
        text: This is quite a plain lounge with an old beige carpet and peeling wallpaper.
        script: 
	function(object) {
		// set some flag or start a timer or something.
	}
south: kitchen

I realize that there might be a question of order. I know for my code, I just picked one. (e.g. text came first, then scripts, then state setting, etc). But I think if we could incorporate some generalizing ideas into this, where all the game responses (whatever they may be - descriptions, command handling, object descriptions, etc) are all handled the same way, then it could make life easier for people who don't know how to script very well and just want simple things to happen.

If you wanted to go beyond that, you could pick up some other ideas I had like setting variables, etc.

command:
pattern: push elevator button
text: The elevator button lights up. (Some sort of conditional here?)
sets: elevator.called

And then other code would key off of that. Anything to make common things not so "scripty". lol

...although I do have to tell myself that this is the "low-level" code, and people would be seeing a higher level interface (blocky, etc) that could have such macro functions handled in a uniform way.

I wonder if at this level, the "script" blocks could be simplified by having implied parameters and getting rid of the JS preamble and closing brace,...?

command:
pattern: say #text#
script:
    msg ("You say '" + text + "', but nobody replies.");

Just to return to my initial thought, though (sorry for all of this), I would still like to see a consistency across the board: for the room description, I want to "do this". For a command, I want to "do this". When the player examines an object, I want to "do this".

Where "do this" is the same in all cases, whatever that is (text, script, etc). But done uniformly, so that if a game author wants to start out with text but then move to something more advanced, they're not switching paradigms or suddenly doing something completely different, where all they learned so far needs to be thrown away (as it is now with the text/script switch for descriptions, for example). If that makes sense.

I like this idea. At the moment, Quest has attributes which can be either text or script - but in QuestKit, scripts aren't attributes, so there's nothing to stop us using both at the same time.

I don't think that it makes sense.
Take Jays example:

command:
pattern: take #object#
text: You take {object}.
script:
   function(object) {
      setParent(object,  "player");
   }

What will you do first ? Printing the text? But in the script you decide not to take the item because it's too heavy. Yes, this all works for simple games and average Quest users, but is this our destination?

Then you don't specify any text, and the script handles it all - just the same as now.

Then you could do it completely with script.. and I see that Jay wrote this in his post, too. Sorry