Serious confusion about Javascript in Question

Hello everyone, apologies for the wall of text.

I've been messing around with Quest for a couple of weeks and I've accumulated a few questions about how the engine handles its internal Javascript. These questions led me down a bit of an interesting path.


How does Quest handle Scope?
It seems that functions and scripts created within Quest get a different runtime scope than functions linked with the JSkeyword. Outside functions do not have the same access to Quest-specific functions like OutputText. Typically these sorts of scoping problems wouldn't be much of an issue except that,

Are functions not first-class citizens in Quest?
This is the issue that has really given me frustration. It appears to be impossible to pass Quest engine functions as arguments or to inspect their behavior at runtime because at compile time anything other than a function call throws an error. When I realized that Quest even had a 'compile time'; i.e., that it was taking the stuff I wrote inside the quest editor or in the .aslx and using that to build whatever code it ran when actually playing the game I began to wonder,

Is this even Javascript???
At this point, I cloned the repo on Github and opened the project up in visual studio. Looking at the (frustratingly undocumented...) source I realized that Quest was, in fact, reading in line-by-line the 'code' written in the editor and breaking it up somehow. The Quest engine functions like OutputText were not even implemented in text as far as I could tell. The quest!Javascript compiler-thing seems to have no conception of functions itself, so I was unable to create functions inline at runtime (even with 'evals') or inspect and modify behavior at runtime with .__proto__. Even stuff like JS.function seem to be implemented by manually scanning for that specific keyword (see JSScript.cs).


I've just started with Quest and to be honest neither Javascript nor C# are my primary languages so it is entirely possible I've made a mistake here (and if so please correct me because I'd love to be wrong here), but if I haven't then I think it is a bit disingenuous for the developers of Quest to claim that it allows you to program in Javascript when in fact they have implemented their own language with only a tiny fraction of the power the real Javascript provides.

I have ideas for game systems I'd like to be able to prototype quickly; Quest initially stood out to me as a great tool for my experimentation. It does 90% of what I need an engine to do for my prototypes and offers a nice, well-designed interface. Everything else I've found in the text adventure engine space seems too poorly featured to really provide much of a boost over implementing everything myself. But I really need the capability to link in my own code which makes heavy use of Javascript's Object-Oriented and Functional capabilities and as far as I can tell that is flatly impossible in Quest as it stands.

Am I missing something obvious? Can anyone who works on the project or knows the codebase better point me in the direction I need to go?


This would be a question for Xanmag, mrangel, or KV.
Wait a bit please.


The OP seems to see the big picture. The JS interaction is mainly for printing text and the display settings. It's not quite the same as using HTML with JS.


the developers of Quest to claim that it allows you to program in Javascript

It actually says:

And you can go even further, by customising the user interface using HTML and Javascript, to get your game looking exactly how you want it.

There may be something referencing Javascript programming elsewhere, but this is the gist. I can definitely see how the wording could mislead someone, though.


As far as how Quest works with Javascript, perhaps someone else can elaborate. (I only went so far down that rabbit hole.)


There may be something referencing Javascript programming elsewhere, but this is the gist. I can definitely see how the wording could mislead someone, though.

Ahh, okay, I see now. The in-editor scripts are just referred to as 'scripts', not 'Javascript' and Javascript is only referred to in the custom interface sections.

Also, it occurred to me after I posted this that it is probably a security feature since Quest hosts a lot of user-generated content and allowing people to upload content that runs arbitrary JS on other people's browsers would be Very Bad.

I'm not sure how many others fall into the overlap between 'knowing enough programming to want the full features of a modern programming language instead of a very simple scripting system' and 'not reading the tutorials carefully enough to realize they never actually specify what language they're using' but it might be wise to put an aside for technically minded people somewhere near the start of the tutorials that they will likely be disappointed if they're expecting to do serious programming within Quest.

Thank you for pointing that out.


Quest is built up of a weird mixture of C++, HTML, and JavaScript. You can technically do anything you want. I don't know how it works. I suppose anyone with knowledge of the 3 languages could reverse engineer Quest quite easily, it's just a small program built in Visual Studio, it's just it would take a very, very long time to figure out.


As KV said, JavaScript is just for the user interface. The game itself is all done in ASLX, running on a C#/BASIC framework. You can modify the built in ASLX however you want on the desktop version, which should allow you to have your own world model or build your own parser.

ASLX does support objects (as "types"), with inheritance, but I would not describe is as fully object-orientated (Personally I would not say JS is either!).

And I agree about the lack of documentation of the source code!

Also, it occurred to me after I posted this that it is probably a security feature since Quest hosts a lot of user-generated content and allowing people to upload content that runs arbitrary JS on other people's browsers would be Very Bad.

Browsers do allow you to run arbitrary JS in people's browsers. Hopefully JS/browsers are designed to stop the bad stuff happening.


Thanks for the feedback, also

Browsers do allow you to run arbitrary JS in people's browsers. Hopefully JS/browsers are designed to stop the bad stuff happening.

If I put up code that does something bad (like run cryptomining or launching a XSS attack) then it is linked to my site and potentially (depending on the registrar and how sneaky I'm being) my name. But if I can upload my bad code to your site and get you to host it for me (and I've taken reasonable steps to anonymize my account) then anyone who interacts with that page gets the bad script and you take the blame while I take the mined bitcoins or stolen login details. So whether it was intentional or not, it was smart to not allow users to put arbitrary Javascript in their games.

Javascript isn't the leaky bug bucket that Flash was and browser security has gotten a lot better but lots of websites out there are still vulnerable to XSS. Might be worth checking into the JS for UI stuff to see if it's possible to run a crypto script or something in the background when a game loads.


Is this even Javascript???

From my experimentation, Quest has separate javascript environment that runs in-parallel to Quest's scripts.
JS.eval() calls work on the same global "environment", so if you run
JS.eval("var foo = new Array()") then
JS.eval("// do something with array foo") -> it will work
Also, from what I've seen, Quest seems to run on "embedded" browser, and javascript considers itself running on a webpage. However, things like HTML5's local storage don't work, probably because javascript interpreter is a bit old.


Nice explanation, myarichuck!

(I wish I'd have thought to provide all that information.)


Log in to post a reply.

Support

Forums