You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of the potential plan for scripting includes allowing WebAssembly modules to interact with the Bones ECS directly for maximum performance ( #489 (reply in thread) ), but the lack of a linking standard for WebAssembly means that there may be challenges to make this work in the context of Bevy/Winit. There may be a middleground we can implement in the shorter-term, though, that would still be suitable for awesome mods.
We might be able to take one or more scripting languages that have a Rust implementation ( Lua, Python, Ruby, Rhai, Tao, Koto, Rune, WASM or others ) and implement bindings to the Bones ECS in those languages.
This wouldn't allow us to write high-performance ( shared memory ) mods in Rust, C, or AssemblyScript like we would prefer, but for the other languages, they might actually end up more performant on non-web platforms, because they aren't running in WASM. And we could still support WASM mods, it just wouldn't be zero-copy with shared memory like I was initially thinking for maximum performance.
We'd still have to test it to see what kind of performance we get in practice, but, if we found a language that was nice and stable enough for us to dedicate to and had good performance, we might even be able to migrate some of the core items to scripts, with the intent of making them easier to mod and act as tutorials for new modders.
This would help reduce the barrier to contribution, which is currently relatively high because of the need to install the Rust compiler, especially on windows which requires additional setup involving Visual Studio, and wait for a large game to compile and re-compile.
My biggest two hesitations would be ( from the Piccolo readme ):
Most of the stdlib is not implemented, io, os, package, string, table, utf8, debug, and most top-level functions are unimplemented.
That, and the fact that Lua isn't statically typed.
There is teal, though, which looks easy enough to integrate. And Lua is just so ubiquitous in the modding community, we'd probably make a lot of people happy if we supported it. You can hardly bring up scripting in a game on GitHub without somebody mentioning Lua. :D
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Part of the potential plan for scripting includes allowing WebAssembly modules to interact with the Bones ECS directly for maximum performance ( #489 (reply in thread) ), but the lack of a linking standard for WebAssembly means that there may be challenges to make this work in the context of Bevy/Winit. There may be a middleground we can implement in the shorter-term, though, that would still be suitable for awesome mods.
We might be able to take one or more scripting languages that have a Rust implementation ( Lua, Python, Ruby, Rhai, Tao, Koto, Rune, WASM or others ) and implement bindings to the Bones ECS in those languages.
This wouldn't allow us to write high-performance ( shared memory ) mods in Rust, C, or AssemblyScript like we would prefer, but for the other languages, they might actually end up more performant on non-web platforms, because they aren't running in WASM. And we could still support WASM mods, it just wouldn't be zero-copy with shared memory like I was initially thinking for maximum performance.
We'd still have to test it to see what kind of performance we get in practice, but, if we found a language that was nice and stable enough for us to dedicate to and had good performance, we might even be able to migrate some of the core items to scripts, with the intent of making them easier to mod and act as tutorials for new modders.
This would help reduce the barrier to contribution, which is currently relatively high because of the need to install the Rust compiler, especially on windows which requires additional setup involving Visual Studio, and wait for a large game to compile and re-compile.
All reactions