I'll post some information on v5.0 soon. It's a complete rewrite and (I think) it's shaping up rather nicely... it's still quite a long way from completion though!

In Quest 5, how much of the Quest library is implemented in VB and how much is implemented in Quest?

Have you taken the time to study compiler design?

There is no VB code for Quest 5 games. The core engine is written in C#, and provides handling of objects and properties, plus script commands and expressions. There is a standard core library implemented in ASL5 which provides the default basic Quest functionality - so all the standard verbs, code for displaying room descriptions etc. is written in ASL itself.

It doesn't compile games exactly, but scripts are loaded when the game starts into various class instances, so they are not "interpreted" as such once the game is running (you could in theory create games using pure C#). Expressions are handled using the FLEE library which compiles them to .net code in the background.

Anyway this is kind of more detail than I wanted to go into right now... I'll set up a dedicated Quest 5.0 forum in the near future and hopefully there will be a very early, hand-coding-only, no-visual-editor, no-support-for-existing-Quest-games version available early in the new year.

So Quest 5 directly generates .NET bytecode, which is run directly by the player? What sort of steps are used to keep an author from writing a trojaned game? Even ignoring security issues, it's very difficult to add UNDO to such a system. (Other IF languages handle UNDO at a level above the VM level.)

What sort of games are you writing as sample Quest code?

Script commands don't generate .net IL code directly. They just map to .net objects - there is an IScript interface which all script command implement. An ASL5 script command like

msg ("Hello there " + player.name)

could be represented in C# by something like

new MsgScript(new Expression<string>("\"Hello there \" + player.name"))

FLEE compiles the expression to .net IL, but the MsgScript is just an object with an IScript interface.

So essentially we're still not compiling script commands, just interpreting, but without the overhead of "actually" interpreting while the game is running.

We implement object properties at a level above .net properties. "Undo" is built in right from the beginning.

Will the specification at least document the exact behavior of such code as
msg <first $func1(#var1#)$, then $func2(#var2#)$>
or the equivalent?

And again, what sorts of complex things are you doing in your example games for Quest 5?

Will the specification at least document the exact behavior of such code as
msg <first $func1(#var1#)$, then $func2(#var2#)$>
or the equivalent?

Quest 5.0 doesn't do in-lining - to write the above you'd write something like:

msg ("first " + func1(var1) + " then " + func2(var2))

The logic determining how the expression is evaluated is entirely within FLEE: http://www.codeplex.com/Flee/

And again, what sorts of complex things are you doing in your example games for Quest 5?

Depends what you mean by "complex". But currently Quest 5 does some "simple" things that Quest 4 can't do, such as undo, manipulating lists, and using local variables. The core library is written in ASL itself and supports fairly basic functionality at the moment - no more complex than Quest 4 can handle, but the fact that it's written in ASL means it will be easily extensible to do things that are hard in Quest 4. For example, dealing sensibly with objects that are out of reach of the player, and implementing light sources - these will be built-in to the Quest 5 core library, and implemented in ASL.

By "complex things", I mean as the player would view them.
For example, how much of Museum of Inform ( http://ifarchive.org/if-archive/infocom ... Museum.inf ) could you do?

How much do you have working right now?

(It looks like you're still treating expressions as a special case of the .asl parser, which doesn't fill me with confidence.)

Well from that point of view there's not much "complex" that is in the core library yet. It will eventually let you do more complex things than Quest 4, but for the initial release anyway it probably won't do all the things Inform can do. You'll be able to edit or replace the core library though, so at least you won't be stuck with anything hard-coded as you are with Quest 4.

Expressions aren't special cases - they are everywhere in ASL. Here are some examples:

foreach (obj, GetObjectsInScope("Visible")) {
  msg ("You can see: " + obj.name)
}

if ((a and b) or (c and d) or (somenumber * 3 > somethingelse)) { .... }

foreach (obj, somelist + anotherlist + SomeFunctionReturningAList(AnotherFunction(blah + foo))) { .... }

MyCustomFunction(a, b, c+d)

player.parent = GetRandomRoom(GetNearbyRooms(player.parent))

someobject.take => {
  msg ("Blah blah")
  someobject.counter = someobject.counter + someotherobject.someproperty
}

This looks really cool, Alex. Can't wait. Will spend more time creating a custom library than I will writing stories, that's for sure.

Let me rephrase what I was saying about special cases:

For the code you just posted, which portions are passed to FLEE?

Also:
How much of the program do you have working at this point?

What would the distribution format for one of those look like?

Expressions passed to FLEE in bold below:

foreach (obj, GetObjectsInScope("Visible")) {
msg ("You can see: " + obj.name)
}

if ((a and b) or (c and d) or (somenumber * 3 > somethingelse)) { .... }

foreach (obj, somelist + anotherlist + SomeFunctionReturningAList(AnotherFunction(blah + foo))) { .... }

MyCustomFunction(a, b, c+d)

player.parent = GetRandomRoom(GetNearbyRooms(player.parent))

someobject.take => {
msg ("Blah blah")
someobject.counter = someobject.counter + someotherobject.someproperty
}

As for how much currently works, all of the above code would work, if you'd defined the various functions. It is the core library itself which needs developing at this stage, and so far I have that supporting fairly basic functionality (take, drop, printing room descriptions, fairly simple object scopes - taking into account open containers, but not handling transparency or surfaces yet).

The file format is called ASLX and looks a bit like this:

<asl version="500">
  <include ref="English.aslx"/>
  <include ref="Core.aslx"/>

  <game name="Test ASLX Game"/>

  <function name="myfunction" parameters="something, blah" type="string">
    return (something + blah)
  </function>

  <object name="lounge">
    <start/>
    <object name="sofa">
      <prefix>a</prefix>
      <look>Just a sofa.</look>
      <take type="script">
         msg ("Test: " + myfunction("one", "two"))
      </take>
    </object>

    <exit name="east" to="hall"/>
  </object>

  <object name="hall">
    <exit name="east" to="kitchen"/>
    <exit name="west" to="lounge"/>
  </object>

  <object name="kitchen">
    <object name="sink">
      <look>Just an ordinary sink</look>
    </object>

    <exit name="west" to="hall"/>
  </object>

</asl>

By "distribution format", I meant the file that ultimately gets run by the interpreter. (That is, a format like .z5 or .gam.)

I expect "include" statements and the like to be in the "development format" (like .inf or .t).

It will be a similar system to the current version of Quest. Those "include" statements in the example are standard Quest libraries, so you'll be able to ship just the .aslx if that's all you're using.

There will be something like the .cas format for Quest 5 but it will probably be just a compressed and encrypted .aslx with the libraries included - it's not something I've thought too much about yet.

For distribution formats, it's best to put everything together. If the person playing the game has a different version of the Quest libraries, the game will run differently.

I admit this looks very interesting, and I have been waiting to see what Quest 5.0 can do. I do have a question though.

"I'll set up a dedicated Quest 5.0 forum in the near future and hopefully there will be a very early, hand-coding-only, no-visual-editor, no-support-for-existing-Quest-games version available early in the new year."

What exactly does no visual editor mean? Am I going to have to learn C#? Also, what does no-support-for-existing-Quest-games mean? Does it mean a game created with Quest 4.1.1. won't work with 5.0?

I was just talking about the first preview version which will be available early in the new year. We're still a long way from having a finished product, and the visual editor and component for loading older Quest games will come later.

So a game for Quest 4.x will work with Quest 5.0, just not in the initial preview version.

Ah, ok then. Thanks Alex for clearing that up for me.