While working on a terminal application i got sidetracked by terminal-run text adventures and happened to stumble over your project. I've been digging through your code and it i think it would be perfectly suited to run in the node ecosystem. i just have to add a frontend for the reminal (probably using Terminal-Kit and/or Ineuirer for the UI).

But I think parts your code could use some modernisation.

For example the creation of world objects is incredibly static and would benefit from modern JS/ES features. Using ES6 classes and/or async fractory functions and proper inheritance, Source Code could be made more maintainable and easier to expand, in addition to making the program run faster and more stable, all while making the API more powerfull and easier to use.
The current implementation of the World-Object could also be replaced with with a Model-View-Controller system, making it easier to maintain, as parts could be overhauled independantly of eachother, while also making implementation of new features simpler. For example runtime creation of objects is pretty much a given with MVC
I woulc also strongly reccomend to add integration into the NodeJS ecosystem, as it would not require direct alteration to your code, but would give you access to its powerfull tools like zero-config development-webserver applications, code linters and testing-environments.
As the NodeJS-JavaScript-runtime-environment is direcly based on the Googles V8-engine (used by all Chromium.based browsers e.g Chrome, Opera, MSEdge) it would also garantee maximum compatability with browser features (while FireFox (SpiderMonkey) and Safari (JavaScriptCore) use different engines, they are very much on par when it comes to the JS-runtime-environment back-end-wise).
The back-end needed for integration is minimal, requireing only a few lines of code that are ignored when not run with node. being node-ready also opens the door for thousands of developers to learn or contribute from/to this project and garantees easy access to the people using one of the various node-webservers who would like to implement this program on their webpage.

Questions:

what do you think of these proposals?
what (if any) things are you currently working on and what do you plan for the future of QuestJS?
would you be willing to integrate a backend for the NodeJS ecosysteminto you sourcecode?

I will certainly inform you when i finish a basic frontend for the terminal. And if you are up for it, i will file PullRequests for the mentioned changes once i finish them.

It has taken me a while to respond as you make a lot of points and I have had to think about it a bit. I better say from the outset, I am not a professional coder, and this was the first JavaScript project I had attempted (though I have done stuff in other languages). I have subsequently started a couple of other projects, one an editor for this, in NPM, so I am a little familiar with that environment.

For QuestJS I very much wanted a system that will produce a game that can be uploaded to textadverntures.co.uk or to your own web site and will just ran, so NPM was not right for that. You seem to be saying I could do both, and that is an intriguing idea, as it might help integration with the editor. Unit testing with NPM would also be great - I have some unit testing, but it is a little limited. If you can point me to how to integrate with NPM that would be great (or a piull request, even better).

I also wanted a system that was as easy as possible for non-coders to create their own games in, even without an editor, and this was a significant factor in several design systems. I did originally use the ES6 class system for world objects, with a hierarchy of classes for different types of objects - takeable objects, wearable objects, NPCs, etc. but abandoned that early in the development. The issue with runtime creation of objects is saving and loading them when the game is played, and I do not think using classes is going to help that. So my current thinking is no classes.

I am familiar with MVC. In a sense, io.js handles the view and parser.js (together with command.js and commands.js) kind of handles the controller side, though it is a little tenuous. If I could think of a way to improve that, I would! If you have suggestions, I would certainly be interested in hearing them.

At the moment I am working on the editor, and changes to QuestJS are mostly minor tweaks to support that. It is in a state where it handles everything I want it to. More specifically, I am looking to tidy-up the various msg functions and enhance scope so the parser can say an item is not available rather than not known if, for example, it is for sale.

I am indeed happy to add NPM integration, as long as it does not impact on running as a normal web page.

having spent considerable time looking through your code, i have to say it is fascinating (take this as a compliment, lol). I have never seen someone use so much brute-force-coding in JS. Much coud be optimised and made more dynamic to make it easier to change even core elements with plugins from the game-dev side. I have to say, that your coding style shows considerable skill and creativity. And the documentation in the code is great.

I have never done Web-stuff, so i'm having to learn on the go how to do a lot of these things.

Currently i'm working on configuring a bundler (i'm using rollup). The bundler will handle all the things necessary to make the program usable on Node and Browser ~~(we could even look at making it usable on Electron to use it as a standalone desktop-app. This could be very usefull for the editor)~~ EDIT: while writing this response i took a look at the Editor and saw that you are allready using Electron and React. I think it would be a good idea to use React in the main program too, I haven't worked with it yet, tho. So that might take a little time

Heads up

what i'm writing from here on out would invove major code changes, that i think would be very beneficial for development, potential Game-devs and the end user. Now all of this together will seem scary, as it is a lot, but it should be possible for all of them to be inplemented gradually. I really hope you stay open minded to these proposals, because we have an opportunity to make something really awesome here with the groundwork you layed
I don't doubt, that you posess the necessary skills for these.

We could provide this bundler-configuration as a package for use with the editor or write a simple one that could be standalone. The bundler will also transpile the code, so we can use all the modern JS-coding features(and even ES-next or Typescript if we want.) while keeping the bundle compatible with browsers and node.

Currently all i'm doing still very crude as i'm just throwing stuff together to make it work. This will have to be refined down the road, but getting it working has priority so we can kickstart compatible development.

It will depend on the size of the different frontends for Node and the web. If they are relatively small, we can put both in the bundle. Otherwise we will just provide two bundles, both able to run the same game without having to adjust anything. This way, games would essentially be full fletched Plugins of any complexity, from just adding a game script to adding entire new mechanics for your game.

I would also suggest moving the project to fully fleged Typescript down the line, as it would make the code more maintainable. But i'm still learning Typescript, so this would take some time.

About making it simple to create games without a dedicated editor

I really like this point. As we could create a solid framework with wich you can create games using simple JavaScript and JSON that can simply be plugged in and run. We can easily provide type annotations and code-doc, which modern code-editors like VS-code will automatically use to show information about functions and usage as you code. In fact: if you change your documentation annotation, to the common standard, it will allready do that: instead of:

// @DOC
// [documentation]
// @UNDOC`

use:

/**
 * [documentation]
 */

This way you can also provide detailed description of function propertes using @property [desription] that will be parsed, shown and highligtet by modern editors. This way your program can double as a framework for learning and teaching basic JS in an interesting way, as the result would be a Game.

postscript

Again, I know this is a lot.but this does not have to be done all at once. I'll keep working on getting the bundler to work. Should not take much longer. I appologise for how much it is, i just get really excited by how much potential this project has.

8 Pull-Request has been filed.

It converts the project to a bundle fully executable by HTML. The PR contains the details.

I am only responding to a bit of your comments. Also, it will come across as a bit negative, but only because I want to emphasise the issues here!

"I have never seen someone use so much brute-force-coding in JS. Much coud be optimised and made more dynamic to make it easier to change even core elements with plugins from the game-dev side."

I would be interested to see what you can come up with. If you go into the project and open page-eg.html you will find the example game. type "test" and it will run through some tests. See how much you can optimise and still have that complete without errors. You may find it is more complicated than you thought - or you might not, in which case excellent!

"I think it would be a good idea to use React in the main program too, I haven't worked with it yet, tho. So that might take a little time"

A big issue with React is its error messages are not helpful. With straight JavaScript, it tells me the line number and what the issue is 90% of the time, and that is a HUGE plus for a system that will be available to non-coders to use. My experience in React is that it catches the errrors itself, then points you to a line in the React library, which is not helpful at all (I am conscious of the fact that authors will be coming to me to solve there problems, so trouble-shooting has to easy!). There may be a way around, catching errors earlier perhaps, so I am not ruling it out, but...

"I really like this point. As we could create a solid framework with wich you can create games using simple JavaScript and JSON that can simply be plugged in and run."

I did think about authors writing JSON, but there are times they may need to write code too, so not that simple. An option would be to do it as a mixture, but I am not sure there is a great advantage to JSON over JavaScript - and I find the fact that your last entry cannot have a comma very annoying!

"It converts the project to a bundle fully executable by HTML."

How do I do that?

I am only responding to a bit of your comments. Also, it will come across as a bit negative, but only because I want to emphasise the issues here!

i have to say it doesn't make that impression. just soundls like you want to be careful

I would be interested to see what you can come up with. If you go into the project and open page-eg.html you will find the example game. type "test" and it will run through some tests. See how much you can optimise and still have that complete without errors. You may find it is more complicated than you thought - or you might not, in which case excellent!

I haven't looked much at the tests yet. i'll see what i can do.

A big issue with React is its error messages are not helpful. With straight JavaScript, it tells me the line number and what the issue is 90% of the time, and that is a HUGE plus for a system that will be available to non-coders to use. My experience in React is that it catches the errrors itself, then points you to a line in the React library, which is not helpful at all (I am conscious of the fact that authors will be coming to me to solve there problems, so trouble-shooting has to easy!). There may be a way around, catching errors earlier perhaps, so I am not ruling it out, but...

understandable. just wanted to throw that in.

I did think about authors writing JSON, but there are times they may need to write code too, so not that simple. An option would be to do it as a mixture, but I am not sure there is a great advantage to JSON over JavaScript - and I find the fact that your last entry cannot have a comma very annoying!

I was thinking about using a mixture. JSON would be great for storing data to dis or to send to someone (that's what it was created for after all). It could be used to save and share gamestates for examle. and as JSON is a strict subset of JS it can seemlessly integrate. and it's easier on the eyes compared to other readable data formats like XML.
But you are right, it's rather annoying to write. There are a few langage extentions to JSON that are trying to adress this issue:

multiple versions of JSON that allow JS-style comments to be used
JSON5: a more modern variant that allows things like JS-style comments, trailing Commas, single quote and multyline strings with escape characters, hex-numbers and trailing or leading decimal points and stuff like that. i've used it a bit before and it makes JSON quite a bit more functional while making it even easier to use.
it's also open source, widely used and well maintained

How do I do that?

i left instructions and explanations in these files: in the PR: (links to the files on my repo)

rollup.config.js: the configuration used by the rollup-bundler plugin. I included a comment that explains how to use it. But as mentioned in the PR, it does still need some adjustments (working on creating a downloadable package right now) and some extra script in the HTML.
index.html: the HTML to launch the the bundled game. it's a little messy at the time. this will be fixed, just needs some helper skrips i hadn't time to write yet. you can give it a try by just downloading the dist/ folder and serving that with a web server. then just open the url of the server in your browser.

I am closing this as I do not think it is going anywhere. In principle the ideas are good, but there are issues (including requiring multiple inheritance, which is currently faked using templates; and wanting to keep it as simple as possible to start creating, which precludes NPM).

ThePix / QuestJS

About a possible Future of QuestJS and its modernisation and optimisation #7