Apparently Rust isn't going to have an easy time supporting the multi-memory thing while targeting WASM, as far as I've found so far.

I think there's still another option, but I need to do a little bit more research.

It would depend on whether Wasmoon let's you tweak it's heap.

With Rust we can do a custom global allocator to do what we need I think.

But I still need to verify, and make sure similar workarounds are possible for AssemblyScript, and possibly Wasmoon.

Yeah, still looking into it, but I think there's a way to make Rust and AssemblyScript work, we can use a custom global allocator for Rust, and we can use a custom runtime for AssemblyScript.

Wasmoon would need something similar. Maybe like patching

malloc

, or something like that.

That might mean re-compiling it, but not a huge deal if it worked.

Absolute worst case: there is a project that compiles WASM to lua.....

Actually, for non-web supported mods, we could probably support native lua, with no WASM involved. Because we'll be trying to create a super simple ECS that could easily be interacted with over a C API ( I think ).

What i meant is that if, in the worst case that you can't get it to work the normal way you should be able to compile it to lua and just reuse the same lua VM for all of them. That, as far as I know should allow them all to share memory and easily call into each other, etc

Like I said, worst case

I would assume that that gives a similar kind of safety as running WASM normally as WASM shouldn't have a way to call the Io/os functions from lua directly

But i might be wrong in that

Again, absolute worst case But it might be an option to quickly setup a prototype of the whole idea if setting it properly is complicated/has a lot of obstacles

Yeah, I think compiling WASM to Lua won't be easier in this case, because we have a couple of good WASM runtimes in Rust that should work fine, but we'll see what happens once we start experimentation.

Ooh, it looks like wasmer already has an abstraction for running WASM inside a browser, which could be quite handy for getting this to work in the browser.

We could build our own abstraction, but this takes care of it for us, I think!

It looks like a lot of the potential options for sharing WASM memory or linking are pretty unstandarized/unstable, or unimplemented, so it will take a little more looking around to see if we can make that work. The sharing of memory was the essential piece for maximum performance mods. Without it I think we should still be able to do the design fundamentally, but I've still got to do more research.

Gotcha. Since this is a more ambitious ‘next-gen’ design, it’s quite possible that we will have to resign ourselves to waiting for certain WASM features to stabilize until we can confidently make the switch.

The moddability story is very appealing, but it’s worth keeping in mind that simply being an open source game already makes us radically more moddable than the average game, including duck game.

To add onto this, without considering the possibility of upstreaming changes -- there's not a lot of meaningful difference between forking and modding

yes and no Rust is not a language that lends itself easy to get people to hook into unlike say, Java and .NET. For Java, no better example exists than Minecraft were some mods have basically gone ahead and rewrite the entire game if you load them, either in how it works from a gameplay perspective or in the name of performance. There have even been mods that replaced the entire chunk system with a 3D chunk system. .NET has https://github.com/pardeike/Harmony which allows you to do similar things Does being open source help? Yes, obviously, but the language is sadly working against you at the same time

For now it'll be something that I'll be doing research into on the side, and I may find a way to make it work, despite missing features, or maybe find a slower but still effective stand-in solution.

Even without mods, the determinism and snapshot performance is still a big motivation for WASM, so we might be able to just get that in as an improvement for that current situation, and then work on modding as an extra step on top of that once we find a route for it.

> Rust is not a language that lends itself easy to get people to hook into unlike say, Java and .NET. I'd personally argue that whether or not this may be true in general, with Bevy's API it's not really the case - in fact I think with Bevy (or just ECS) it's really convenient to start hooking into the game to mod functionality

though that might be true in principle from what I've seen so far it looks like the ECS's (or at the very least ECS systems made in Rust) really like knowing the types they need to work with due to pretty heavy use of generics. Which is not the case when mods are involved I would also argue that in Java and .NET world people can probably just replace the entire ECS system for as long as the API stays compatible in some way, shape or form (based on seeing what people did with Minecraft Java)

I'm wanting to get a handle on automating our release pipeline for Jumpy and I'm realizing that now is probably a good time to split out separate crates, such as the matchmaker, the ECS, the QUIC networking plugin, etc.