brandondyer64 / bevy_wasm

Mod Bevy games with WASM

Brandon Dyer

Hi, I'm Brandon (he/him). I build lots of things here on my GitHub. I'm a professional software engineer with a passion for systems, frontend, and graphics programming.

I work at Disney as a Software Engineer working on their streaming platform in Rust.

I'm a huge fan of Rust and am working towards making it my primary language, both on the frontend and backend. I love SCRUM and Agile development, I speak Epseranto, and I use the Dvorak keyboard layout.

Longmont Colorado 🇺🇸 US

bevy_wasm's Issues

Bevy features instead of individual crates

Right now, all of the necessary bevy crates are imported individually.

bevy_app = "0.9"
bevy_ecs = "0.9"
bevy_log = "0.9"

Instead, this should be done through Bevy's features.

features = ["app", "ecs", "log"]

Optional JIT

Just-in-time (JIT) compiling is not available or not allowed on some platforms. This can be a major blocker for many games.
JIT, through cranelift, should either be optional or disabled entirely.

Dependency graph

Allow mods to request the existence of other mods.

This may be out of the scope of bevy_wasm as different games will have different needs

Time should be global

Currently, ffi::get_time_since_startup() returns the time since the MOD loaded, not the time since the GAME started.

This makes it virtually impossible to coordinate mods.

Bevy 0.10

Wasm files should be assets

Currently, loading .wasm files is left to the user. All of the example files show using include_bytes!().

Ideally, these files should be treated the same as any other Bevy asset.

`trace!` and `console_trace`

It might be a good idea to add support for using a trace! macro inside of mods.

Load from url

Allow loading mods from a url

Dual licensing

The bevy_wasm code should be dual licensed as either MIT and Apache-2.0 (at your option). This is to be consistent with the licensing of Bevy.

Browser support

It should be possible to use bevy_wasm in a game running in a browser.

Given that bevy_wasm_sys defines its own ffi, wasm-bindgen might not be necessary.

Use semver

Instead of using a custom Version struct, use the one in semver

TypeUUID for shared resources

Shared resources should use TypeUUID for discrimination instead of a string representation.

Parallel mod ticking

Currently, mods are ticked in series. It should be relatively trivial to tick them in parallel.
See Query::par_for_each

`println!` and `panic!` support

Currently, mods made using target wasm32-unknown-unknown cannot call println!. We could use wasm32-wasi instead, but this drastically increases binary size.

Perhaps some kind of #![no_std] support could be added, or a trick for making wasi binaries smaller.

Switch to Wasmer?

Do some more research on the differences between Wasmer and Wasmtime. They both have pros and cons.

With the intention of bevy_wasm being used on low-end hardware, determine whether or not it should use Wasmer instead of Wasmtime.

Alternatively, give the developer the choice through feature flags.

Custom connection struct in favor of event writers

Currently, communication is handled through Bevy's EventReader and EventWriter. What I'd like is some kind of ModConnection struct instead that maps directly to the ffi calls rather than overly abstracting them.

Current:

fn system(in: EventReader<In>, out: EventWriter<Out>)

Proposed:

fn system(conn: ModConnection<In, Out>)

Perhaps a standardized Protocol type could be established that would hold these more obtuse types.
i.e.

fn system(conn: ModConnection<MyProtocol>)