Add support for non compiling scripting language

[qarmin]

What problem does this solve or what need does it fill?

Currently Bevy require to have on computer rustc compiler to be able compile and use game which user created.

What solution would you like?

Adding new interpreted language will allow to run games without needing to compile anything.

Such language is really great to create fuzzers or tests

Engines like Godot or Unreal Engine have their own scripting languages GDScript and Unreal Verse(still WIP) which doesn't require compiling and works on almost any computer out of box.

Other engines use e.g. Python or Lua but this greatly increase its size since additional software must be present inside game engine to properly parse and execute code written in this languages

[TheRawMeatball]

Adding an first party scripting language is officially a non-goal. However, there are plans for making it possible to tightly integrate scripting languages in third party modules.

[adsick]

Rhai is an interesting one, but probably not ideal scripting language. I myself will try to use it to program separate systems in runtime (mostly for prototyping purposes, but maybe also for "games about programming") I didn't tried Rhai+Bevy yet, but Rhai alone seems nice.

[mockersf]

Currently Bevy require to have on computer rustc compiler to be able compile and use game which user created.

This is not completely true, you can distribute a binary of your game that you compiled, and then anyone can play it without having rustc.

That said, it really depends on what you want to be able to script:

• Calling a user defined script with a predefined interface from a system defined in rust should be easy. For example, in a system with a Query<(&ComponentA, &mut ComponentB)>, pass every value of ComponentA to a script then modify ComponentB according to what the script return.
• having a script being able to run any query or execute commands is quite harder and not very possible for now

[Zizico2]

Adding an first party scripting language is officially a non-goal. However, there are plans for making it possible to tightly integrate scripting languages in third party modules.

Can I ask why this is the case? I assume you see the value in a scripting language. I understand if your motivation is to not force bevy users to use any specific language.

Some research around using wasm could be the answer here. Our friends over at swc are currently developing a plugin system using wasm (Wasmer I believe).

This could be a good way to provide a first party solution for scripting. Maybe even a first party language since it would be as easy to integrate any language that supports wasm.

[TheRawMeatball]

Can I ask why this is the case?

Scripting languages create a strict barrier between the engine and game code, which can be undesirable. https://bevyengine.org/news/introducing-bevy/#why-build-bevy see the "Turtles all the way down" section for the official statement.

On another note, wasm is definitely considered as a possiblity for modding and scripting.

[coderedart]

Just thought i would mention a few use-cases in support of this issue.

1. expose a dev-tools like console in game to change variables or whatever.
2. separate game logic and engine code.
3. allow modders to get into your game and extend it. a plugin system more or less.
4. let non-programmer team mates to adjust the game as they see fit easily. lua/python for example are much easier for them to adjust compared to a rust codebase.
5. extend bevy's plugin ecosystem.

for example, with godot, they have gd-native to write libraries to load at runtime or compile time from gdscript. they can afford that because C has a stable ABI.

meanwhile, bevy uses rust features heavily like Traits and most of them are not ABI Safe, so exposing bevy to any scripting lang would be a pain. bevy is just not designed with the use case of FFI.

godot doesn't really need to expose a "modding" interface. games can just load godot scenes as well as gdscripts from random folders at runtime. mods are as easy and safe as putting into a folder.

any kind of runtime modding support with Bevy is much much harder.

having first class support for scripting langauge is a huge benefit for being "accessible" to a lot of people. modders, devs and users.

[makspll]

+1 @coderedart I think personally for me, the biggest argument for scripting is the ability to create a moddable game, I can't really see a way to achieve that without exposing some sort of sandboxed interpreted language.

[coderedart]

https://github.com/bevyengine/bevy/issues/4474 is going to help move this forward.

[StarLederer]

You can probably implement interpreted language support for user generated content with the help of something like boa. I don't think an interpreted language should become part of the engine. I have used jint in Unity before, it took ~5 C# files to implement a little framework where people could use JavaScript to interact with a tiny API. Admittedly, the project would grow much more if the API actually did things other than updating object positions, but I would leave this out of the engine

[makspll]

I agree the language shouldn't be part of the engine, but facilities for enabling one should be provided

[alice-i-cecile]

There's an up-and-coming third party crate for scripting here: https://github.com/makspll/bevy_mod_scripting