jamiebrynes7 / spatialos-sdk-rs

Rust integration of the SpatialOS C API bindings
Apache License 2.0
21 stars 6 forks source link

Brainstorming: Amethyst and Specs + SpatialOS #107

Open johnpmayer opened 5 years ago

johnpmayer commented 5 years ago

Amethyst is a game engine for rust which uses Specs as its entity-component-system implementation. Rather than trying to build a GDK, I'm exploring what it would take to integrate specs with the SDK provided by this repository.

As a first step, I'm going to try and accomplish this without any code-generation, just wrapping the spatial-generated components with a newtype struct that implements specs Component trait. Then, I'll implement generic component reader/writer Systems which interact with a mutex-protected WorkerConnection as a world resource.

Assuming that all of that goes well (and I'll share my results) the natural next step would be to auto-generate some implementations. Looks like this has been talked about in #83. Generating the systems isn't a big deal, but due to Rust's restriction that implementations for third-party traits must live alongside type definitions, the implementation of specs::Component for demo::Rotate would have to be part of the spatial codegen process.

At a high level, it would be nice to do something like

cargo spatial codegen --plugin specs

though I'm not sure how the custom generation code would be provided to the spatial cargo component.

How about using a build.rs file instead of a cargo component? That would require (and maybe this is already possible but not "first class") exposing the code generation as a library.

jamiebrynes7 commented 4 years ago

Hey! Sorry for the delayed response to this - my GitHub notifications are all kinds of messed up 😕

@samsnyder did a little experiment integrating Specs and this project. You can see the branch here https://github.com/jamiebrynes7/spatialos-sdk-rs/tree/feature/specs-integration although I'm really not sure what the state of it is!

I personally don't know enough about Specs to offer a useful opinion about your planned integration, but I'd love to hear more about it 😄


Custom code generation

Plugins are a neat idea. I wonder if we could use WASM to dynamically load and execute the plugins. Instead of having a flag --plugin, it could be part of the Spatial.toml specification:

[codegen]
schema_paths = ["./schema"]
plugins = [ "<url>/<filepath>" ]

When you say using a build.rs file, do you mean the crate where my code generation output goes would have a build.rs that looks something like:

fn main() {
    let code_generator = SpatialCodegen::new()
        .schema_path("../schema")
        .plugin(SpatialSpecsCodegen::new());

    let generated_code = code_generator.generate().expect("Failed to generate");
    generated_code.write_to_file(PathBuf::from("generated.rs")).expect("Failed to write generated code to file.");
}

(Very similar to bindgen)

I'll open an issue regarding code gen plugins/custom code gen, as it feels like a large issue that will need some careful consideration. --> https://github.com/jamiebrynes7/spatialos-sdk-rs/issues/117

That would require (and maybe this is already possible but not "first class") exposing the code generation as a library

This is kind of already a thing, in fact that's how cargo-spatial does it. 😉 However, there would definitely be work required to build a nice user API and make writing plugins/extensions nice.

samsnyder commented 4 years ago

Hey!

That branch Jamie linked is just small changes needed for my specs integration. The actual project is https://github.com/samsnyder/spatialos-specs.

I did get it working but I am not maintaining it so I am not sure of the current state. Hopefully you will find it useful to try or look at though!