Compare to `bevy_mod_scripting`

[soraxas]

Hi this looks interesting! especially of being able to query/write dynamic system in bevy!

I want to understand how does this currently compares to https://github.com/makspll/bevy_mod_scripting?

Obviously, instead of supporting scripting language construct (lua / rhai), wasvy support wasm api for functionality. But in terms of performance and feature wise, is wasvy attempting to achieve similar goal?

I also saw that wasvy is using json to pass data back-and-forth; maybe there would be a more efficient way to avoid serialization/serialization across language boundary?

[MarcGuiselin]

Thank you! I can't speak for the other contributor, but my goal is to have an experience snappier than the dioxus-powered hot-reloading added to Bevy 0.17 with near-native speeds.

Wasvy is my second attempt at building a modding system for Bevy (For my custom browser). The first featured a custom wasm bridge with zero-copy component reading/writing: https://github.com/MarcGuiselin/bevy_harmonize but came with a ton of added complexity and made some compromises in regards to wasm security. It was clear that it was possible to make a near-native speed wasm-based modding framework for Bevy, but I was making the prototype waaaay more complex than necessary and I burned out in the process of making it.

With Wasvy I took a step back and collaborated with @EngoDev to keep things simpler and make a wasi based api that could work for other languages, not just rust.

I want to understand how does this currently compares to https://github.com/makspll/bevy_mod_scripting?

Well they overlap a bit, but not completely. And mod-scripting is getting heavily reworked if I'm not mistaken so things might change.

Unlike mod-scripting's lua mods, writing mods in WASM enables writing mods in almost any language including rust. And WASI offers a simple interface to interact with the filesystem, rng, system clocks and more basically for free, the game just needs to give the mods access via ModloaderPlugin::add_functionality.

I'm working on creating a library so writing a rust mod is identical to writing one in Bevy. Whereas in mod-scripting you have to learn and adapt to the lua based api.

But mod-scripting is probably much faster and less resource intensive as a nature of lua requiring so little overhead to run. There are tons of optimizations that we have left to make our wasm based implementation fast. But we're prioritizing on finalizing the api and cli before making that happen.

It's also much easier to get started with mod-scripting since wasvy requires a bit of setup and (writing wit and copying wasm to the game's assets directory) to getting a mod running. These will be automated via https://github.com/wasvy-org/wasvy-cli, but I havn't even started building that yet 😅

Lastly there's many basic things we don't support yet. Such as despawning entities, accessing resources, creating assets, and more. It's a lot of small things. I hope to get these all working Q1 of this year for bevy 0.18.

I also saw that wasvy is using json to pass data back-and-forth; maybe there would be a more efficient way to avoid serialization/serialization across language boundary?

I'm not fond of the json based serialization either. I argued for a vector instead of string based format like protobuf, but json serves our purposes for now and has wider ecosystem support. And some things like initializing the wasm instances each frame contribute much more to making Wasvy inefficient than serialization. But it's counter-productive to work on optimization before we get the other parts stable. DX is more important for me right now.

The way I see this working in the future is keeping json support for mods, and have a high-speed alternative for rust/c that writes to/from a zero-copy format so mods don't have any serialization to do. The only overhead will be a single mandatory data copy between game and wasm memory (unlike my previous attempt which let the mod write/read directly from Bevy's storage vecs mapped to wasm memories which is obviously unsafe).

@EngoDev Was working on a low-level binding that avoided serialization altogether and parsed wit types directly to/from bevy reflect, discussed a bit here: #1 (comment) but I don't know what the status of that is or if he's open to start working on it again. Do you have any updates for us Shalev?

[EngoDev]

@MarcGuiselin covered everything very well 👑

I used JSON for serialization because that was the easiest thing to do and I wanted to get a prototype out. As Marc said I'm experimenting with an alternative way to do it that feels more native (no matter what language you use for your mod) and allow wasvy to extract away all the pain of moving the data between the host and the guest so mod authors can focus only on writing their logic and mod without boilerplate.

I have been quite busy with work as of late but I hope to land it soon 🤞🏻

If you have further questions (or want to contribute) all are welcome here :)

[soraxas]

@MarcGuiselin Thank you for the incredibly detailed write-up, this was very helpful and appreciate the effort!

Unlike mod-scripting's lua mods, writing mods in WASM enables writing mods in almost any language including rust.

Achieving something snappier makes a lot of sense, and yes using wasm leaves dev to either use compiled language to achieve near native spped, or also being able to use scripting language to enable quick prototyping. Which is why this approach looks so interesting!

Wasvy is my second attempt at building a modding system for Bevy (For my custom browser). The first featured a custom wasm bridge with zero-copy component reading/writing: https://github.com/MarcGuiselin/bevy_harmonize but came with ...

The zero-copy approach was clearly powerful, but i guess it needs unsafe code? It's a shame that it wasn't possible.

Lastly there's many basic things we don't support yet. Such as despawning entities, accessing resources, creating assets, and more. It's a lot of small things. I hope to get these all working Q1 of this year for bevy 0.18.

Yeah that make sense, and that probably will require being able to sends the intent + components/resources to insert into the world via commands or exclusive world. I've been working on doing that spawns + manipulate bevy world entities via network call; but that requires me writing lots of DSL to wrap bevy datatype, and hence that's how i came across wasvy while i was searching. More than happy to help on developing wasvy if it fits my needs!

The way I see this working in the future is keeping json support for mods, and have a high-speed alternative for rust/c that writes to/from a zero-copy format...

Totally understand the decision to start with JSON despite its inefficiencies. The ecosystem support and ease of debugging are hard to beat early on.

unlike my previous attempt which let the mod write/read directly from Bevy's storage vecs mapped to wasm memories which is obviously unsafe

Yeah it'd be hard to do it in safe rust; was your last approach with memmap?

I have been quite busy with work as of late but I hope to land it soon 🤞🏻

If you have further questions (or want to contribute) all are welcome here :)

Amazing @EngoDev! Sounds good and more than happy to!

[MarcGuiselin]

Shalev's approach makes a ton of sense, and theoretically we can get amazing performance with that without relying on unsafe. Thanks for sharing, and looking forward to seeing that!

The zero-copy approach was clearly powerful, but i guess it needs unsafe code?

That and many more issues. I have documented some here: MarcGuiselin/bevy_harmonize#2

was your last approach with memmap?

See this thread for more specifics: #wasmtime > Implementing the LinearMemory trait for ECS data @ 💬

I've been working on doing that spawns + manipulate bevy world entities via network call; but that requires me writing lots of DSL to wrap bevy datatype, and hence that's how i came across wasvy while i was searching.

Cool! Then we're both here for a similar reason haha, two years ago I was designing an entire custom api for modding my document previewing application built with Bevy. It's a bit silly thinking about it now but, for my use-case, just using Bevy's api directly is obviously way more powerful haha.

Hopefully one day I can actually demo my project! I'd love to see what you're building too someday.

More than happy to help on developing wasvy if it fits my needs!

That'd be amazing! Well there's no shortage of things to work on for sure, and please let us know about any integration issues you have.