Awesome! That would help :).
I've thought of other things that might make quest development nice. The biggest one--and I admit it's a very tall order--would be some sort of control-flow primitives. This might look like
"Events" : [
{
"If Block" : {
"Condition" : {
"Predicate" : "HasItem",
"Arguments" : ["Player" , "poem" ]
},
"True Event" : ..., # can be any event, including other if blocks
"False Event" : ... # likewise
}
]
My current solution for this (which I still haven't tested) involves spawning multiple NPCs, having each give the player a quest with different conditions, and then despawning the other NPCs (if that's possible). This will leave the incomplete quests hanging around, but that's fine.
Less drastic, but still very helpful, would be some documentation about the semantics of the various JSON objects. Even just BNF grammars, e.g.
<QUEST> ::= <QNAME>, <QID>, <QTYPE>, <QGIVER>, ..., (optional) <QEND_DIALOGUE>, ...
<QNAME> ::= "Name" : /.*/
<QID> ::= "ID" : <REFERENCE>
...
<REFERENCE> ::= /[a-zA-Z0-9]+/
...
<FLAG> ::= "Flag" : ( "Can_Enter_Power_Plant" | "Can_Enter_Ensis" | "Break_Prisoner_Inhibitor" | ... )
Again, I'm asking for a lot--completely understandable if this stuff is infeasible.