Pondering how the script editor in Quest 6 might work. Currently, there's a lot of server-side C# code to handle editable scripts. My thinking for the Quest 6 editor is that as much as possible should be done on the client-side.

One approach would be to rewrite the script editor in client-side JavaScript. This would then look and feel pretty much the same as the current script editor, although it would be a good deal quicker.

Another approach would be to use something like Blockly: https://code.google.com/p/blockly/

It is open source and gives a Scratch-style script editor. It could be adapted to output Quest ASL script, or perhaps even better, could simply output JavaScript directly.

One drawback is that the conversion from Blockly to JS (or any other language) is one-way. Blockly cannot create a visual representation of existing JavaScript code. How big a problem do you think this would be? It would mean that existing "library" code couldn't be viewed visually, and if you switched to Code View and edited a script, you wouldn't be able to go back to the visual view.

My opinion is that these don't seem like very big issues to me - if you're minded to change the libary code, or tinker in code view, that suggests you're comfortable looking at code anyway, so you don't need the visual blocks.

The advantage of using Blockly is the much quicker development time - I won't need to reinvent the wheel, and can just plug it in - and it uses what seems to be now quite an established way of editing scripts visually, as a lot of schools use Scratch so this style will be familiar to many users of the visual editor.

If we can also go direct to JS from the visual editor, we don't actually need much of a converter at all - all scripts would be written in JS in the first place. We could use the converter to do the initial conversion of the core library from ASLX, or it might be a better idea to do this manually so we get cleaner JavaScript code which will fit better into a JavaScript way of doing things.

It could also make Quest 6 more of a serious tool for learning programming, as people would be learning a "real" language for scripting.

What do you think?

Hmmm, this is a philosophical question. Where do you want to go? If you want to bring Quest into schools, it is the right way. But then I think you will get lots of primitive games submitted to the Quest homepage (more than now). If you want to become Quest a professional tool, blocky is too childish
On the other hand, if you save time with this blockly editor you could add a better code view editor, too? Something open source with syntax highlighting, syntax check, code suggestion and advanced functions (search and replace)? Switching between the two editors should not be necessary, in simple mode you see blocky, in advanced mode you get an texteditor.

We're already taking Quest into schools and it's already used by many young people. The product we're taking to schools is activelit.com though - a private shared area that each school can set up. So this shouldn't bring a big(ger) flood of primitive games to the website.

If scripts are all JavaScript, then this helps Quest become more of a professional tool - essentially it becomes a JavaScript framework for writing text adventures. Yes, in the editor you could turn off Blockly entirely for an "advanced" view. We could include an open source JavaScript editor with syntax highlighting and other functions e.g. http://codemirror.net/

In any case I don't see that Blockly is necessarily any more childish than the current script editor. It's more colourful, yes, but the colours actually help you to determine what kind of "block" each thing is - green for commands, purple for expressions, blue for raw values etc.

I've played with it a little bit now, and my response is mixed.

On the pro side, I like the visual nature of it. If I may say, I find the Quest GUI editor to be hard to use to actually visualize large pieces of code. I'm not sure why that is. It just seems cluttered to me, and hard to pick out the nice structure you can get in a code view. Blockly solves that in spades. I haven't written a large chunk of code in it yet, but it really organizes things well visually. The indents are nice. The items are compact. You can scan the code from top to bottom and just *see* what it's doing,

I also really like how it makes code more spatial. I tend to think about code that way myself, and I've often wondered how it would be to have blocks you could move around. Lego Mindstorms had a programming UI similar to this.

So I like it as an interface.

The mixed: I was playing with the "Graph" demo (http://blockly-demo.appspot.com/blockly ... ml?lang=en), and I had an interesting experience. I wanted to graph "y = sin(180*x)". So I dragged the sin block onto the "y=" block. Then I had to tell myself that the next block would not be 180 - it would be the "something op something" block, which I then dragged the 180 and x into. It's not a big leap, and perhaps after a while it will feel like second nature to people. I just wonder how easy it would be for non-programmer/non-mathematics types to work that out.

Also, for more advanced things, they did the best they could. Again, it might become second nature how parameters are done (for example), but I was able to map what I wanted to Blockly given that I knew what I wanted. It's hard for me to know how neophytes would take that.

The cons: I've been looking at the JavaScript code that two of the demo apps spit out (all found here: http://blockly-demo.appspot.com/blockly/apps/index.html), and I'm not impressed. The "Block Factory" one seems to generate JavaScript code on top of a Blockly Language class library. That doesn't seem too efficient. The "Code" app generates more straightforward JavaScript, but it creates global variables for everything, which seems really dangerous to me, especially if this will be used by less expert coders. I didn't see a way to create local variables. Even procedure parameters needlessly generated global variables. I don't know how much control you have over the generated JS, but I think what I've seen would be unacceptable.

The other con is a bit of inflexibility in the interface. Code can often be malleable, on the large scale. (If people are just creating room description scripts, this might not be as pertinent.) The evilness can be seen by the fact that they have a different construct for a procedure that returns a value and one that does not. What happens if you decide half-way through that you do indeed want a return value? In Quest and other languages, you just do it around what you currently have. In Blockly, you'd have to rip out the guts and put into the other construct.

Also, I wondered what happened if you needed to change parameters, especially if you are already calling the procedure. Adding a parameter is ok - a new "socket" appears on the blocks for the added parameter. If you remove a parameter, it actually disconnects all the orphaned parameters from any existing calls and leaves them floating. If you accidentally remove a parameter and add it back, you'd have to manually reattach all the params.

All in all, I think it's promising. I'd want to play with it a bit more. I think the JS generation could be a big problem if it uses globals like that. It's going to be nothing but headaches to not have scoped variables. I also don't see any support for data structures, which is key for larger code development (even the Quest SDK).

One more thought (I stopped the previous one as the editor gets really slow with longer passages).

I see there is an XML intermediate format. I went in and played around with the XML in one of the Code runs I did, and it immediately generated new JS and Python code. It also updated the Blockly blocks. Perhaps you could use that intermediate format as the native format rather than JS. That way, manual changes could be done and still reflected in the Blockly blocks. The XML is ugly as heck though.

Interesting points Jay. Blockly is open source so there should be complete flexibility - presuming I can get my head around the code (and I haven't looked into it much yet).

I think I'll need to play with a bit more and do a bit of prototyping to see if it will be suitable.

Even if it turns out not to be suitable, it's certainly inspiration for how the Quest 6 script editor could look. Also I think the ideas of having the script editor output JavaScript directly, and not worrying too much about directly-edited scripts being editable by the visual editor, are worth bearing in mind for whatever we decide upon.

To state it a bit more strongly - if Quest had an interface like Blockly, I'd be tempted to use it. It's actually quite fun, but it works as well.