ThePix / QuestJS

A major re-write of Quest that is written in JavaScript and will run in the browser.
MIT License
66 stars 12 forks source link

Framework Development and Security #99

Open sablesoft opened 11 months ago

sablesoft commented 11 months ago

I really like your framework. In terms of ideas and possibilities. As for the implementation, we can find fault with everything and always, so we won’t talk about it now. Because now I wanted to talk about something else.

I had a few ideas related to questjs. One of them is to package this library as a modern npm module so that it can be easily and conveniently installed. And I did it. I made my package with the MIT license and with the latest version of questjs 1.4.0, and also added vue components to this package to display the game on the screen. I had to really mess around and modify the source code a little, but I did it. However, in the end I abandoned the idea of ​​making full-fledged reactivity due to the specifics of the source code. But that's not what we're talking about now either.

My other idea was to try and make a platform that would use this package to run games in the browser, but also allow users to create their own games through a web interface. No, I don't like the idea of doing something like Quest 5 again. To be honest, all those endless windows submenus terrifies me. My idea was much simpler - to add a codemirror code editor to the user interface, for example. For starters, just highlight the syntax, then check it with jslint. And save these user files on the backend. It's very easy to do this. But here complex questions began, in which I am not strong at all ...

Security. Yes, it's about this. The problem is that if anyone can register on the platform and write their own javascript files that will connect to the QuestJs module, then potentially no player is protected from the fact that something unfriendly will happen to his browser. After all, potentially some author of such text adventures may turn out not to be a good master of the game, but a bad attacker who will do his dark deeds through his games.

How to prevent it? How do you keep the power, simplicity, and flexibility of this QuestJs idea while still being as secure as possible for the platform and for the browsers of the users running the code?

sablesoft commented 11 months ago

P.S: I seriously ask these questions, because I have other ideas about questjs. For example, I tried to add my custom field "keywords" to game objects. I then filled this field with, as you might guess, keywords describing each game object I created. And then... I connected to the backend of my site Open API with gpt-3.5-turbo model...)))

In short, with a little tweaking to begin with, I tried to replace the static descriptions of the rooms with the dynamic responses of this language model. I played around with different query options, choosing the most optimal set. It turned out that if you send clear instructions in the request, as well as keywords that describe the room, as well as its current contents, as well as the current time of day, weather conditions, lighting, current mood and state of the player, as well as a couple of previous events, then the output we have... a meaningful text description that is fully consistent with the game situation and at the same time it is unique every time!

Then I tried various response formats - one short sentence, one paragraph of several sentences, a long description of several paragraphs ... It turned out just amazing! Of course, I didn't stop there. I asked the language model to come up with rooms, objects and characters and their keywords for me. And it worked out, as expected. But the latest experiences don't matter if you can't connect them to a dynamic data store, be it a database or files on a hard drive.

Therefore, I want to make a user interface so that authors can create their game worlds through it, and not through a code editor. It is much more convenient when you can display a list of all your game objects in the form of a table, sort and filter it by object type, search by name, and so on. But all this is currently quite difficult to implement due to the specifics of this framework.

I really like the flexibility and extensibility of questjs game objects. Yes, in a matter of minutes, I can add any properties and any of my custom handler functions to any object. But, if you make a user interface for this, then: 1) How to guarantee the safety of the code for the players, assuming there are many other authors? 2) And in general, how to implement the creation of game objects through the interface? Through a connected code editor? Then say goodbye to tables with sorting, searching and filtering. Through json objects? Then you need to develop factory methods, which, moreover, are most likely to encounter the use of 'eval()' for functions and classes, which again is a minus of security.

In general, at the moment I have a lot of questions, and I just wanted to share them. It turns out that the flexibility and power of this framework at the same time is a factor that does not allow it to massively populize, not only due to the need to learn javascript, but also due to the security and complexity of implementing any user interface.

But we will find solutions, I'm sure. Good night.

sablesoft commented 11 months ago

Yes, I also tried to localize a test game on this framework into another language. And it turned out to be very problematic. Yes, there is a lang-en file here, but in fact it does not contain everything that needs to be translated. A lot of text lines are scattered throughout the library. And in order to translate all this, you need to edit the library code, replace all these lines with variables and collect them in one place.

But this is not the whole problem with localization. I see that the framework implements the grammar of the English language very seriously and thoroughly, and this is really worthy of respect. But at the same time, it adds even more complexity to translate into another language. Because it's not just a set of text strings that need to be translated into another language. This is a whole system of mechanics that creates strings according to grammatical rules of one specific language - English.

In this regard, I simply abandoned the idea of classical localization to hell. And then the idea again came to mind to use api and the power of language models. And it works. We don't need to localize our games. We need to keep making games in English. This framework is fully specialized for this language. All that needs to be done is to add a library that will process input and output according to the user's chosen language. If it's other than English, a request is made to the AI text model and it 1) translates the user's request to the English for game system 2) translates the game system's English response to display to the user with his language.

In addition, this can be done simultaneously with the generation of dynamic messages, such as descriptions of objects, actions, events, and so on. You just need to add an instruction in which language the response should be returned to the system message.

In general, there are a lot of ideas, but first I want to deal with other complex issues that I described a little higher.

ThePix commented 11 months ago

Hi, sablesoft

You make a lot of interesting points that will require some thinking about...

With regards to localisation, I suspect the root cause is the complexity of English. I have had put so many rules in to cope with that that changing to another language would be a huge job. If there are specific issues with English specific code outside of the language file, do let me know. It is all to easy to just not realise the issues there.

With regards to using a library like Vue, I am not sure there are sufficient benefits. Doing so will add a level of complexity to people who are just starting out. At the moment, they just download a zip file, decompress, and start editing. Once NPM is involved you are having to install stuff from the command line, and have to worry about versions, etc. I say this is part from my experience trying to build an editor (which would be with Node.JS, NPM etc).

With regards to security, this is an issue discussed here (and I now realise the page was not listed): https://github.com/ThePix/QuestJS/wiki/A-Note-About-Web-Page-Security

sablesoft commented 11 months ago

If there are specific issues with English specific code outside of the language file, do let me know.

Sure

At the moment, they just download a zip file, decompress, and start editing.

I understand it. But my ideas need a backend and interaction with it. So I just did it for my own convenience. In any case, I think it would be better to have separate view files that are used in one way or another to generate the page's html, instead of generating html bit by bit from different places using javascript. I think it hinders development. It is much more convenient when logic and view are clearly separated. And it does not affect the user experience. The user can still download the archive and edit the game files.

I say this is part from my experience trying to build an editor (which would be with Node.JS, NPM etc).

Yes, the topic of the editor is intriguing and I would like to talk more about it. What ideas did you have about it? How do you imagine it? A simple javascript code editor? Or something else? Ready to offer you my help. Personally, I would like to do something more structured, as I already wrote - with the ability to conveniently search for objects, as well as sorting, filtering, and so on. But how to do this without losing the functionality of the framework so far I can’t figure it out.

ThePix commented 11 months ago

The embryonic editor can be found here: https://github.com/ThePix/QEdit

I was hoping to integrate Blockly as a code editor. It can handle JavaScript, so in theory should be easy, but I could not work out how to embed it in the editor.

sablesoft commented 11 months ago

It can handle JavaScript, so in theory should be easy, but I could not work out how to embed it in the editor.

The tool is powerful and beautiful, but... I don't quite know how to do it either. For example, let's take the tutorial for commands from your wiki. We create a console command "Charge". In principle, it is not difficult to make a custom block for creating a Cmd class. Let's call this custom block - "Сmd". But! Further along the tutorial, you need to add a custom attribute with name "charge" to each object that should respond to this command. Moreover, the value of this attribute must be a Boolean function. It turns out that you need to create a custom block, something like a "checkCommand", which will have the name of the command in the parameters ("command"), as well as the check function ("boolFunction") with all its logic in the form of nested mosaic blocks... Yes, I understand that this is an ideal option to avoid possible errors from users. But they still will! So, isn't it too difficult? And this is just one example. And how many more are there? Wouldn't it be easier to use a regular code editor like CodeMirror? Just attach some js lint to this editor, plus pre-run these files in the node.js vm sandbox to make sure everything works before saving.

Hmm... It turns out that in order to use this visual editor, we need to: 1) Convert all the mechanics of creating a game one way or another into configuration objects in json format 2) Write factory methods that will read these configuration json and create game objects based on them.

It turns out that before implementing such a visual editor, we must first develop this configuration json system. Or any other configuration format. One way or another, this is essentially a kind of QuestJS DSL. In general, first need to create a library that will contain factories that can create all the necessary game objects based on such configurations. At this stage, instead of the usual code, the user can write an array of configuration objects in json format, for example, and this should work just like normal code for him. And only after that we can safely convert these working configurations into visual editor blocks.

Basically... this is exactly what I was thinking - if we can create such a DSL to configure all objects in json format, then it is very easy to store all this in a database - each game object separately, and then sort, filter, edit and delete individually and so on. Even without a visual editor. A regular json editor and some wiki page with a detailed description of this configuration syntax will suffice. And even better - write a JSON Scheme so that this code editor highlights all the errors, and also suggests possible options. Connecting a json schema validation to modern browser-based code editors is not too difficult.

ThePix commented 11 months ago

It would only be the script attribute of the command that would need the Blockly editor. The user would select New command, and get presented with a dialogue with the standard attributes. They can type in the name, regex, etc.

But many of your points remain. How will it know what variables are applicable? The factory method is still required to create the blank command (though I think I had done that).