I am talking about providing scripting capabilities at runtime. I am interested in your thoughts/suggestions regarding the subject and wanted to share the results of my frankensteinian experiments. Also I have no idea if anybody else has done something like this, nor am I sure there isn't some obvious solution.

I've started experimenting because: 1. Giving scripting possibilities to users is nice for modding and tools. 2. I use a DSL for dialogs and such which needs to interact with GDScript. 3. Godot only gives you Expression, which is very limited

My approach: 1. Tokenize the text 2. Copy the GDScript grammar as far as sensible (there is a reference in the docs) in a Recursive Descent Parser. Then for each statement we can figure out if it is an assignmentstatement, or an if-statement etc. 3. For expressions I use Expression.parse(...) Expression.execute() and assemble the available variables from the current scope, this gives me integration with GDScript 4. You can register vars (including nodes) and Funcrefs from GDscript to be able to use them in the embedded scripting language 5. Do a bunch of hacky stuff to make things work as expected, e.g. x[0][0] = 4 is not easy to do, and I automatically insert '.call_func' for funcrefs so I can write 'f()' instead of 'f.call_func()'

Results: 1. I think there should be a Node for this. Also safety needs to be taken into consideration. Providing Assignment and Declaration besides Expression might be enough. 2. What I've done is doable, it works good enough for the simple stuff I need it for, I can do loops, if-branches, declare and assign variables, call functions. Due to hacks it's far from bulletproof though.

There is a language server, I think, that runs on a layer below GDScript. This is what the visual scripting editor uses (it doesn't translate to GDScript). So I would recommend looking at the C++ code to see how that works. You might even be able to just embed a visual editor in your game using the same code. This would have to be in C++, I think, cause it's not exposed in GDScript. But I don't think it would be a lot of work. Or you can see how it functions and wire a DSL to use the same base code.

Interacting with GDScript is not too difficult. I can use Expression to call functions.

The hard part is the parsing. My logic is if I am doing an embedded scripting language in Godot, it should be as close as possible to GDScript. Using Expression is a nice trick to get a huge part of the language correct. But with everything else I can potentially mess up the implementation and error messages and tooling aren't going to be great.

So I am reimplementing a bunch of stuff GDScript already does and does better. A clean solution would require modifying the engine. That seems like a job for somebody more competent than me (also I will be waiting for Godot 4.0 before trying to figure out how the GDScript Parser works).

I think embedded scripting is super cool and something Godot should offer a native solution for. When you start thinking about it there are tons of potential applications and we could create super flexible systems. Imagine scripting as a puzzle mechanic, or educational coding with visual feedback. People could share scripts for generating certain types of buildings or dungeons in-game like some sort of magic spells. More mundanely, whenever you need any type of logic for modding a script gives the greatest amount of flexibility. Be it something as simple as an healing item that when health is full prints "health is full" and does not get used.

You probably can't do embedded GDScript 1:1 but get very close. When a function is registered in script it should probably be deregistered at the end of it. Access to personal data or file access needs to be regulated, tight control over what a script can an cannot do is needed as a defense against malicious scripts.

I have created a Parser Node one can register some external functions and variables to, and then throw code at. I think that's a good approach. In-game Code Editor Screenshot

Okay, I see what you are saying. Yes, what I was suggesting is more advanced and would require modifying the engine code in C++. I think if you keep the supported features limited, your idea should work okay.

a year later